Development Blog

One of the nice things about traditional roguelikes is you can play a game at any pace you like. Turn-based action means you can stop and contemplate your next move as long as you like, but at the same time instant feedback from actions means you can string them together as fast as you can type.

Unfortunately this advantage of instant feedback also implies the game is missing out on one of the more atmospheric methods of presenting the game world through something other than text and gameplay: action animations.

Modern graphical 2D roguelikes tend to use at least some quick animations, but even that slows the game down, and they’re often not worth the cost in player wait time--especially once they are familiar to the point of boring. The DCSS tiles approach (as one example) of everything still resolving more or less instantaneously and leaving the text to provide the most of the details is much more engaging than seeing a little sprites pop up over every single actor and/or target in turn, making it easy to quickly dispatch lesser threats while avoiding boring repetition.

In the earliest CRPGs encounters and actions were always quick to play out, but at the time that was the only choice due to hardware limitations. With today’s graphical capabilities, it’s understandable that businesses will rely on eye candy to maximize their profit, even if it does get boring after a while. After all, only rarely do games sell based on lasting appeal; strong sales are based on screenshots, trailers, and first impressions. This is one reason a game with that solid traditional roguelike feel is unlikely to ever evolve beyond the indie segment.

Animation in Cogmind

Cogmind subscribes to the minimalist approach in that movement and nearly every other action in the game is resolved quickly enough to be considered simultaneous for all units (from the player’s point of view), despite being a turn-based game. At the same time, the desire to attract a wider audience means we should look for ways to give it a more general visual appeal.

GUI animations help a lot in this regard, and while ubiquitous, they’re always fast to make sure they don’t slow the player down in any way. Some of the animations can be seen in various previous posts, such as here and here (relevant .gifs copied below).

Opening item info is more or less instantaneous, but this looks far better than if it all simply “appeared” (gif is missing some frames, but you get the idea).

Opening item info context help. All animations are also accompanied by sound effects, enhancing the immersion.

The part of the gameplay itself most worth slowing down a bit to take advantage of the ASCII particle effect engine is weapon effects and explosions. Once polished and accompanied by sound effects, these contribute significantly to the atmosphere.

There is a bit of a dilemma even there, though, since seasoned players of traditional roguelikes will soon complain about too much slowdown during firefights (some 7DRL players did precisely that). The game’s focus on ranged combat would be one reason this is a more acute problem with Cogmind, as projectiles actually have to trace their way to targets. The likely solution in this case will be to speed up animations for any gunfire that isn’t spectacular (or at least interesting) while allowing sufficient time for the more impressive and possibly less frequent effects. One useful feature of slower projectiles is the slight amount of tension created as you see one flying towards its target and don’t quite know yet whether it will hit, though that’s not reason enough to slow them all down.

This is an even bigger issue with the new Cogmind, since the addition of allies and multiple factions means you can now come across (or initiate) larger fights more often. As you can see in the .gif showing allied combatants in an earlier post, it could be quite tedious when simply trying to maneuver around an ongoing conflict, having to stop every couple steps while others fire their shots in turn. (I must say the Cogmind I was using there was very slow though, so under normal circumstances they wouldn’t get to fire quite so much.) Seeing as those are unimpressive pew-pew lasers, they’ll be sped up when it’s time to playtest.

Another solution, this one rooted in gameplay design, would be to reduce the number of shots required to kill things (or increase base accuracy), but those changes would leave too little room for variation in weapon, enemy and encounter design, so they’ll likely remain roughly the same.

In summary, there’s a difficult balance to control between animation and flexible pacing.

Exploring this idea further into the guts of the game, it turns out it’s not just a design dilemma--it’s also going to be the biggest technical issue to solve, which is why I brought this topic up in the first place.

Technicalities

Having established that we want combat animations, and that we also want allies and other factions, a bit of a conflict arises… With large maps and plenty of places and robots not in your general vicinity, there could be fighting going on that you can neither see nor hear, and that certainly shouldn’t slow you down while it plays out.

This implies the game now needs two ways of handling combat: In one, visible combat actions are handled normally with real-time animation, and in the other all the gunfire and explosions must be carried out instantaneously.

The question then becomes how to easily determine what is and is not visible/audible, and write a whole new system for handling anything that needs to be played out instantly.

This is not nearly as easy as it first seems. Since all animatable events are processed through their own state machine, earlier states would need to predict future states to determine if any part of the action is known to the player. Thus each individual part of these state machines needs to broken up and externalized to become capable of performing all parts of the action at once, if deemed necessary, after making all the appropriate predictions. (Aside from being a pain to code, this is going to mess up the elegant state machine architecture :(

One common solution for handling non-local events like this is to simply simulate any actions not in view and apply the results. That’s not an option here because there’s simply too much necessary detail in the combat effects that would be impossible (and undesirable) to simulate, not to mention the difficulty of doing so while keeping things advancing on a proper time scale as you go about your business. Maps aren’t that large, anyway (no larger than 200×200), so simulation isn’t required--It’s a solution more suited for games with massive continuous maps.

My notes on the subject have been re-worked a couple times over the past month, ballooning significantly each time with exceptions and special cases to think about. The final solution will no doubt have to cut some corners, but hopefully these will still be transparent to the player.

The good news is this is the last bit of internal nonsense to deal with before finally entering the “make a game” stage! Almost time for the real fun to start…

Origins

If you’re wondering why the system was designed like this in the first place such that it could cause this problem: The engine was originally built for an X-COM remake, which uses small maps on which entire factions take their actions in turn. In that kind of environment you can generally hear most of what’s going on, if not see it, and even the silent parts while waiting for opposing factions to do their thing are a great source of tension. In Cogmind, as a lone player character it would just slow you down and be annoying. The 7DRL prototype didn’t suffer from this problem since you were the only enemy that could provoke combat!

Addendum 1/12/14

Today I implemented the solution and after some preliminary testing it seems to be working nicely. You can walk along just fine while large-scale battles rage on elsewhere on the map. I also managed to hack it into the existing state machine with minimal collateral damage, and only used one of those much maligned “goto” statements in the process ;)

At the most basic level there are only two types of animation in the game: shots and explosions. They’re now filtered more or less using the same method:

1. If the origin is visible or audible the entire shot/explosion is animated normally.
2. Else if any part of the LOF to point of impact (or final AOE for explosions) will be visible, the entire shot/explosion is animated normally.
3. Else instantly apply the shot’s effects at the point of impact (or explosion’s effects to all objects and terrain within the area of effect).

Because it’s not possible to know in advance (i.e. at the time of shooting/explosion) whether a final effect will audible until that effect is fully applied (the process is too complex to predict everything beyond the LOF/AOE state), the game will also pause action for as long as it takes to play any resulting audible sounds such as impacts and destruction. This means you’ll still be able to hear nearby combat that may not be visible, and if there are numerous sounds from sequential turns they won’t all be mixed together in a jumble of noise.

There’s still some more testing and tweaking to do, but at least the solution took a lot less time to implement than it did to mull over the possibilities.