From Prototype to Full Game

I often look back on the time it’s taken Cogmind to reach this stage and ask myself “why the #!@^# is it not done yet?!” (That’s actually me standing in a corridor between a Potion of Speed Coding and Trap of Feature Creep.) More recently I’ve also been wondering if the investment is worth it--think about it: I’ve already put in more than five times the amount of work that went into the 7DRL (including post-release updates) and the game still isn’t released. I’m perhaps not the best judge of my own work, but is the result really five times better? In any case, as a game the 7DRL was obviously a lot less than it could be. It lacked polish. And polish is what takes time.

While at some point the law of diminishing returns will inevitably kick in, Cogmind development still has yet to even cover all the core features, much less reach out into completely unnecessary territory. Since it’s about time for a general progress update anyway, here’s a quick look at Cogmind in the context of what it takes to turn a jam game into a polished product.

7DRL vs. Full Game

Seven-day roguelikes are great for prototyping, since the restrictive time limit ideally forces you to focus on a single core mechanic. Where commercial indie games are concerned, those most likely to be financially successful (defined as turning a profit…) will just stop there--polish a core mechanic and release.

For a (very) short time that was my intention, to simply polish up the Cogmind 7DRL and be done with it. That… would’ve been done by now ;)

But no.

Then I started thinking that a true roguelike also needs more. “This is already a fun, solid foundation to build on… what if we added X, Y, and Z?” More systems! More options! When properly combined in a procedural world these will multiply against each other to produce an exponentially deeper experience.

The thing about polish is that you obviously want the core game to have the highest quality possible, but that means every added feature or element must reach the same level of polish, otherwise a lack of consistency ruins the entire thing. Applying and maintaining consistent aesthetics and gameplay throughout a major project is a project in itself, manageable as a one-man independent operation only because roguelikes defer a good chunk of the experience to the player’s imagination (thereby reducing visual asset requirements).

Scope

So what exactly happened to explode the amount of work necessary to turn what was a pretty feature- and content-complete 7DRL into the expanded game described in the new design doc?

Let’s examine the new scope across three main areas:

World

The 7DRL was organized as a straight dungeon dive (although technically up, not down), passing through ten floors before completion. While the world retains that same central complex, there are now many alternate branching paths. You’ll still be able to go straight up to the surface, but that may not always be the best route depending on your situation.

A sample path through the world of Cogmind, highlighting the central area organized similarly to the 7DRL while also showing potential outlying branches. Each rectangle represents a separate map. (There are more areas generated in a given world than shown here--this is just one possible path, since taking one path means you lose access to others.)

Individual map size is also increased. Those which were mostly 100×100 in the 7DRL now range from 100×100 to 200×200.

A sample mid-level factory map layout--see how the size has quadrupled since the 7DRL, naturally along with significant algorithm improvements (still more to add).

We need lots of new content to fill this extra space, so in addition to unique themes and gameplay purposes for the new maps, they’re also occupied with new robots and even factions. (Really it’s the other way around--the added space was required to fit all the planned content.)

There will be a more in-depth discussion of the world later on “when it’s ready,” in traditional roguelikedev fashion ;)

Mechanics

At the prototype level Cogmind already came with a variety of items, that being instrumental to the core mechanic of building and rebuilding yourself throughout the game. However, the 7DRL is very obviously just shoot/avoid enemies -> attach parts -> rinse and repeat. Sure there are plenty of possibilities and considerations given the large number of parts to choose from, but it all boils down to combat (or fleeing from combat).

The prototype is the core mechanic, where it would be quite easy to add just a few more systems for a result that is greater than the sum of its parts. “Easy” taken in the design sense, not implementation (which takes forever, hence this post). Hacking was a logical choice, adding a whole new dimension to the game that integrates well with all its elements from combat to intelligence gathering and story. Even a range of new combat features found their way into the game, like melee weapons. Then of course there’s the collection of parts related to these new mechanics. And on top of that each part needs its own art and sound, neither of which existed in the 7DRL. Now that took a huge chunk of time.

NPCs and allies are another big addition, fleshing out the story and gameplay though requiring support for dialogue and orders.

Interface

In terms of visuals the 7DRL may seem relatively polished, which can be attributed to importing the existing X@COM code base (which had already been in development for nine months at that point).

Now that we’ve doubled the available width of text windows we have plenty more room to work with, as well as many more windows and UI components related to the new mechanics. These in turn need their own behavior logic and animation scripts consistent with the rest of the interface.

Improving accessibility is a big part of turning a prototype into a full game, thus the entire interface had to be updated or redesigned to make every interaction possible via both mouse and keyboard, sometimes even through a variety of different methods. Heck, there’s even drag and drop. The latest enhancements in particular have focused on visual action feedback, something largely missing from the prototype. I’ll be posted about those soon. (As a side note, one major/common accessibility feature not supported is key remapping. The input system isn’t set up for it, something I hope to resolve one day.)

Progress Update

Despite the significant increase in scope beyond the prototype, this is not me succumbing to feature creep ;). The added mechanics and content are things I think the game needs to satisfy the player’s desire for variety, depth and, more importantly for a roguelike, longevity.

So where are we now?

Cogmind Development Snapshot: Sep. 30, 2014

Put simply, the three main components remaining are

• Robot AI. There is an AI, but it’s pretty simple and doesn’t know how to handle any of the new robot types requiring special behavior.
• Hacking. Machine hacking is complete as a system but there is no content yet, and robot hacking has yet to be added at all.
• Maps. Parameters for the core maps are more or less done, but we’re still missing basic event scripting, prefabs, and then designs for other maps.

According to the roadmap, the above list combined with various odd items here and there will require 21 weeks of dev time.

The good news is that all features have been on target in terms of planned development time. The bad news is I only have about eight weeks of pure dev time left this year. Family reasons will be keeping me away from my dev machine the rest of the time. I’m partially making up for it by heavily prioritizing anything that must be in a first release while resisting urges to do anything non-essential (these features would be candidates for post-release updates). Unfortunately no amount of shifting priorities will get the game to a state where I can run a Kickstarter campaign that can finish before the end of the year (a requirement to work with my U.S. partner). Too bad since it would definitely help raise more funds to make Cogmind a better game. Skipping that phase isn’t without its advantages, so we’ll just make the best of it!

An Empirical Look

Besides listing features, we can also measure progress in numbers. It’s been a while since we last looked at lines of code:

Cogmind LOC: 55,632.

As of September 30th Cogmind has 55,632 lines of code, compared to 20k in the 7DRL (remember that much of the code was reused from previous projects) and 35k in February earlier this year. In addition to this there’s about 6,000 lines of scripts that define game objects, animations and sound effect behavior.

Time-wise progress has been pretty steady. Below you can see that aside from a few wider shelves where I was busy with something else, Cogmind is under regular development. In recent months you’ll see a lot of tiny ridges, created as I began concentrating development into weekdays and using weekends (the ridges) for other activities.

Cumulative development time from July 2013 to September 2014.

That’s certainly not all coding! There are many other aspects of development, all of which are included in the above graph: I divide my time records into Design, Code, Art, Audio, Content, Web, Community, and Business. We’ll wait until there’s more data to talk about that.

Instead, here’s Cogmind in numbers*:

• 55,632 lines of code
• 6,142 lines of script
• 100 source files
• 749 game files
• 26 font bitmaps
• 620 audio samples
• 634 pieces of ASCII art
• 636 items
• 82 item special effects
• 56 explosions
• 116 robot definitions
• 15 AI behavior modes
• 10 NPCs
• 23 map themes
• 146 machines
• 265 stats recorded for score/morgue file
• 50 game options
• 269 recognized input signatures
• zero main menu (you’ve never seen one because Cogmind doesn’t have one)

*(set randomly chosen, numbers subject to change--the general trend being to revise them upward :D)