Looking at some of the backup archives I've written up for when I had finished working on something and had a stable bit of code to save, I can see some of the milestones I've passed:
- 12/16/10, 11:53pm, "New ObjNav Scheme Mostly In"
I created "nav(igation)" objects that are contained inside of other objects to facilitate identifying that a plot of land is on a planet, that planet is in a solar system, and that solar system is in a universe. Each one has a swapmap associated with them.
An intended secondary function of the nav objects is that they're able to compact the contacts of their swapmap and uncache them when nobody's around, thereby saving memory space to facilitate a large universe. I've a long way to go before that functionality is tested and working, but a bit of foresight helps.
- 12/17/10, 5:50pm - "Rudimentary Universe Navigation Up"
I took the time to create the necessary 4.0x skin controls to flit around the whole universe to see where everything was, thereby verifying these nav objects work in such a way that they can identify their relation to eachother.
- 12/17/11, 10:20pm - "Universe Populates With Systems Now"
I didn't used to have a "universe" nav object, I just had solar systems linked together by wormholes. The "universe" object swapmap changed that. I figured it'd be a lot easier on the players' brains if they could actually see the solar systems on a map and the wormholes navigated directionally instead of at random.
Funny enough, as the universe nav object resides in a null location, a global variable is the tack the holds the universe up. If that global variable were to lose association, I suspect the whole universe would be devoured by the garbage collector.
- 12/18/10, 5:00pm - "Map Constructions From Templates Done"
I've a map full of templates and every time the game loads up it saves the individual templates to swapmap chunks in order to keep them on hand for use later in instancing new maps.
One of the cool features of this mechanism are special objects that are executed upon chunk utilization, each generating random elements to make those maps unique from the other maps generated from that template.
- 12/22/10, 4:33pm - "Human Spawning In Cryoship And Player Moved There"
So now I had placed my first ship in the universe, a "cryoship" from a concept I mentioned before. The player could be moved there. The player could spawn a "human" creature mob there... that was about it, but considering everything was procedurally generated, it was a pretty cool milestone to pass.
- 12/22/10, 7:57pm - "Removed Mob Player"
For a long time, my game architecture involved having a mob known as mob/player who keeps track of all the player's statistics while the player actually controls something different.
After discovering the EDGE_PERSPECTIVE perspective settings and the flexibility of verbs that comes with simply reassigning a key, I decided to do that instead. It did make things a lot simpler, and you'd think player-unique attributes could just be stored on some global variable list with an appropriate datum on it.
- 12/22/10, 11:21pm - "Significant Creature Control GUI Added"
I added the means to see all of a creature's states, behaviors, and characteristics. Finally, a good GUI for actually making my critters do something of significance.
- 12/23/10, 8:00pm - "Multiple Unit Command And View Added"
In perhaps the largest reversion for this week, I reversed yesterday's decision and was back to having a mob/player again. I figured if I had to have some database around to keep track of a player's statistics, I might as well have something that reliably can be found to have the player's key on it. I kept EDGE_PERSPECTIVE, which was more efficient than manually forcing a player to stay within a swapmap's bounds, and I suppose if I need verb access that badly there's other verb src settings that will get the job done.
A simple but cool idea I had bouncing around in my head was to disable BYOND's normal view restriction and just manually blot out every turf in the player's view that the creatures under their control can't currently see. Worked like a charm, although there's much to be done to improve efficiency of it.
- 12/24/10, 1:24am - "Rudimentary Combat Engine Complete"
Put two critters in a room that hate each other, and they'll now try to finish eachother off. Hey, for some game concepts, this is the whole game, although I've bigger plans...
It was an interesting milestone to hit because I had built an AI that did things differently than a simple "if it's in view(), get over there and kill it" routine. I actually evaluate a number of various states that determine whether attacking is the right course of action, decide on the best weapon for the job, utilize A* pathing to reach the foe. These "creature" mobs actually continually reevaluate things and decide which behavior is most important before enacting it.
Having verified this AI engine works, I can now add a whole lot of tweaking to flesh out the sheer variety of behaviors and states considered, or I could rip it out entirely and replace it with something a bit more streamlined. Yet another decision in the pile.
My current solution has been to code in such a way that absolutely everything I want to be able to do is supported. That way, technically, that code is still useful regardless of what I decide. For example, my multiple mob control code works just fine as a single character game if you only have a single mob to control. If I can come to no decisions about the specific kind of experience I want, I may well end up with a game that does all the options I'm thinking of, but I know that a focused experience is better.