Official development blog

Animation vs. Pacing: A Dilemma of Modern Roguelikes

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).

cogmind_item_info_cycling

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).

 

cogmind_help_open

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.

This entry was posted in Internal and tagged , , , . Bookmark the permalink. Trackbacks are closed, but you can post a comment.

6 Comments

  1. Someone64
    Posted January 12, 2014 at 8:32 pm | Permalink

    Of course, the simple solution is to give the player the option to change animation speeds any time. Possibly even to the point of allowing them to turn them off completely. That way, when they get tired of it, they can just go straight to the options and be over with it.

    • Kyzrati
      Posted January 12, 2014 at 9:21 pm | Permalink

      Of course, leave it to Someone to remind me of such an obvious solution :)

      True, though increasing the speed won’t always work well depending on the visual style, and becomes an even bigger problem once you add sound into the mix since animation-associated sound effects will turn action sequences into a complete cacophony.

      In any case, this was a pretty poorly written post since I was kinda rambling about a topic which happens to be only tangentially related to what I was working on: The ability to ignore some actions while animating others. The speed of those you do see, while important, is far less an issue than the need to instantly apply the results of anything you don’t see (or hear, for that matter) without causing so much as a blip in the game’s progress.

      I implemented the solution today and plan to update the original post soon.

      As for the ability to adjust the speed of what you can see, I’ll look into that if and when the complaints start rolling in!

      • Someone64
        Posted January 13, 2014 at 3:35 pm | Permalink

        I guess that is a problem. You think audio speed up is out of the question? I mean, without any pitch change. That migth still make it a little strange though.

        • Kyzrati
          Posted January 13, 2014 at 5:18 pm | Permalink

          Things do change quite a bit once you add sound into a roguelike where many events can be occurring at any given moment. But hey, I like to push boundaries ;) We’ll see how it turns out in play and work from there. I’d prefer to not adjust the speed of the sound samples; some tests today did show that it’s kind of fun when there’s a battle around the corner and you hear bursts of gunfire played in rapid succession since there’s no animation involved and the game switches to basing its processing delay on the sounds themselves. The fact that you can’t move during that time may be annoying, though it’s also atmospheric so it should appeal to a certain sub-segment of roguelike fans (hopefully that’s not shrinking the fanbase too much… but maybe we’ll attract some new blood as well).

          After your comment I was thinking about the possibility of adjustable animation speeds for gunfire and it should be fairly easy to implement, though it would change the appearance of the animations a good deal since they’re procedural scripts that rely heavily on time to determine their effects. It wouldn’t, however, affect any of the simpler ones and may be an option that some players would prefer if it’s all about speed.

  2. PrzybyL
    Posted February 8, 2014 at 2:55 am | Permalink

    Hi,

    How You create this awsome quantum rifle ascii art ? Any generator ? By Yourself ? Please
    answer this art rocks !

    • Kyzrati
      Posted February 8, 2014 at 5:24 am | Permalink

      Thanks! I drew it myself using my freely available ASCII image editor REXPaint. Try it out! (I just released a new version, though I haven’t made the official announcement yet because I’m waiting for fan art from a certain artist to put in the post.)

      I wish there was a generator--that would make it a lot easier to do art for the rather large number of items. I was considering creating a generator that works by combining hand-made “pieces”, but the results wouldn’t look unique enough and it’s easy to lose the visual “flow” through each piece. So instead the art is being drawn from scratch in REXPaint. In the future I’ll be doing one or more posts dedicated to the method and style behind the art, so stay tuned!

      If you want to see more, so far I’ve been posting a few more examples on Twitter and Reddit.

Post a Comment

Your email is never published nor shared. Only the anti-spam entry is required. See here for the privacy policy.

You may use these HTML tags and attributes <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>