October 27th, 2013

Design draft 2, as I’m calling it now, was finished this week. For readers at home, “draft 1” is the build that we had at the end of last year. I’ve reduced it to 30 things that need to get done to have it implemented. That leaves roughly two days per thing to get draft 2 playable this year. It’s going to be rough since several items on the list are almost certainly going to take more than two days. Please enjoy watching this blog document my drift towards going further and further off the schedule.

Looking over the finished product, it’s nice to observe how much of it is directly derived from tests of the first draft. Some small sense of validation that the unending tunnel of development was not a waste. The other thing that I like about it is that all of the pressing questions from the previous draft are answered in this. I had no idea what we were going to do with status effects last time, this one clearly outlines their purpose and how to deal with them. If it all works together well enough, we can finally start honing what is there instead of shooting wide and throwing most of it away.

On the programming side of things nothing terribly exciting happened. The location finder was updated to use the same method of finding a location as the node generator does to validate its generation constraints. Not strictly necessary, but it’s a logical place to re-use code and it allows the location finder to easily take advantage of new node features like tags. The distance finder is also a little smarter in this version, optimizing for furthest or nearest node as desired when a node isn’t within the range.

October 20th, 2013

This was a strong week for design. I wouldn’t describe the first draft of design as done but… the foundation for it certainly is. I would describe the current draft as a big glob of thought processes that need to be extracted into a simpler format. It feels really good to start on what looks like the very first step towards genuine completion of the game. Up until now the project has been dogged by, “will probably change this later” which created a crushing feeling of creating an endless stack of work. Being able to sit down and say, “THIS is going to be how it is” is relieving, even knowing that much of it could end up changing later (but probably won’t!).

The design process has been a little lower level than how I usually work at this stage (but is honestly how any designer probably should work at every stage). I sat down and isolated a primary chunk of the game (in this case, the map and objects on it). I then asked: how does each object affect a player’s thought process in deciding what to do in a turn? The goal being to create interesting decisions each turn where the player’s selection would have ramifications on future turns, allowing for both long-term and immediate consequences. This lead to some interesting discoveries falling out of the process, such as it being more interesting if you make the rewards for an action more explicit (as then the player gets to weigh risk vs. reward, rather than simply picking which risk he’s more comfortable with based on the current situation).

From there it was all about going down the list of game elements, listing out the various ideas for them that we’ve come up with over the years, and weighing the effects of each on player decision making and balance. In many cases it hinged on one style of system invalidating another style of system for a different game element, making the ideal choice fairly obvious in the context of the complete game.

Of course the best thing to come out of this process is that I’ve finally settled on what needs to be changed for the battle system. It’s sort of amusing to consider the evolution of the idea. Early this year it all started with an idea of “to make a minimal turn battle interesting, then each single action needs to have multiple consequences). This started out with an incredibly complicated system that could probably be spun out into its own entire game, which basically made every action have 4-5+ consequences associated with it. It was a cool system, but it had many flaws, including that making a quality AI for it would be too much work and it wouldn’t be as fun to fight as a player (even beyond that, it was simply too big of a game to fit within the rest of the game). Then towards the middle of the year I came up with a system that only had 2-3 consequences associated with it. This remained the leading system for a long time, but I still wasn’t sold on it. Only this week did I finally reduce it to a system where every action has 1 additional consequence to it. And it’s almost certainly perfect. It achieves exactly what we need: adding mind games to player vs player battles, and rewarding pattern recognition in monster battles. The funny thing is that I didn’t really realize what each iteration of the system was actually tweaking until after the fact.

October 13th, 2013

The final touches on nodes continues to roll along smoothly. The next week or two might be the last, the only major thing is to add quest actions/objectives for them. Though quite a bit still remains to be refined in the system. The process of adding new functionality to multiple pieces of older code was mercifully not that bad. Far from perfect. I have a lot to say about the flaws of the current code base and what I need to do to raise the quality. It’s mostly that certain pieces expect far too much work to be done on the end of who’s calling them, rather than themselves. But today isn’t the day for it.

What I’m really starting to think about these days is constructing the final design document. The design doc that brings the whole thing together, takes every component into account and ties it together as a proper game. The omega design doc. The more I think about it, the more it’s clear that this design doc won’t be made in a single sitting in a game-less vacuum. More than likely it will be constructed over several drafts. Each subsequent draft will be derived from the results of prototyping parts of the last. It won’t be long before the time to write the first draft is upon me. Starting with a simple but strong core will likely be the direction for it.

October 6th, 2013

Node generation was smoothly wrapped up this week. There might be performance issues at a later date or something, but I’m not too worried. With that out of the way this week looks to be about adding some new system stuff to handle desired node features. Since they involve delving into some code that I haven’t looked at for over a year, things could get gnarly. After that I get to build some sample objects and begin testing to see how the node system has turned out. After that the “map revision” stage will be drawing to a close with the addition of the trap system. I’m happy with how things are turning out (the generation system I discussed last week in particular), but my anticipation to see how this is going to come together is sky high.

Of course that means the battle revisions are the next big thing on the horizon. After how the zone generation system turned into a waste of 2-3 months of development time, I’m going to be a whole lot more careful about not rushing straight to implementation. If code hours need to be spent somewhere, there’s plenty of work to be done on things unrelated to the core game. Truth be told, I still don’t have a completely solid plan for the battle changes. I do have a text file with pages and pages of different ideas for it, but nothing that feels right yet. Sadly most of the ideas I have gravitate towards character build customization rather than the battles themselves.

But let’s be real for a second. I’m not building two different games and mashing them together here. The two modes have to work together to form one sensible whole. That means one mode might have to be simpler than it otherwise could be in order to give the other mode the room it needs to breathe. The chaotic way we’ve ended up building this game just happens to have landed on me building up more of the map mode than I have the battle mode.

The deeper I get into finalizing the design of the map stuff, the clearer it’s going to be as to what the battle mode needs to bring to the table. Despite already having built most of the map system, I still don’t know where I’m going with it exactly. I know the fundamentals: players get to choose something different to do based on where they are on the map. That unlocks a whole world of possibilities from the number of options it presents to players. Lots of movement order planning, flavor to exploration, resource contesting, and so on. But I still need to nail down the specifics of it all: are players contesting resources for how they get to build their battle character, or are they merely contesting resources that expand their battle options? Stuff like that. It’s going to be much easier to figure out what battles are as I begin to finalize it. Battles will then start to inform the map stuff. Having parts of the system available to experiment and test with will make finding the game much easier than pure theory, as crazy as it may sound to build major parts of a game while having no idea how they all connect.