Official development blog

Tutorials and Help: Easing Players into the Game

With a generally lower barrier to add content compared to other games, roguelikes have a tendency to be packed with features and mechanics, and while that doesn’t characterize every roguelike out there (notably 7DRLs and other quick hobby projects), there is an important need to help new players overcome the initial barriers to learning a new roguelike. At least if we want those new players to stick around long enough to learn what’s so fun about it :)

Many roguelikes do borrow a portion of their paradigms from prior games in the genre, be they common keyboard commands or ASCII meanings, and that helps lessen the burden to some degree, but there will always be plenty more to learn. So the question is how do we teach it?

Traditionally roguelikes would come with an explanatory text file, and probably a ‘?’ page/window in the game itself, but little to nothing else. Even today some roguelikes still leave it at that. But game design has evolved quite a lot since the early days of roguelikes, and players are familiar with (and often come to expect) many more help-oriented systems, so we’re seeing an increasing number of roguelikes that incorporate them, especially after migrating away from terminal displays and grid-based, ASCII-only graphics.

Some players are more forgiving than others, and will slog through a slow and difficult learning process in the hope there is an interesting and fun game on the other side, but with easy access to a large and growing selection of games these days, player attention spans and willingness for punishment have declined significantly. To reach the most potential fans possible, new roguelikes need lower barriers to entry so that those who might enjoy the game--but not learning it--make it through that first stage.

That was my starting point for designing Cogmind’s help-oriented features, and here I’ll be discussing the most important ones.


First off, the easiest way to help a player is to make it so they don’t actually need help in the first place :P. Obviously that won’t work for all cases, but as a principle should be applied anywhere feasible. This is most easily applied to input, making important actions easy, intuitive, and accessible based on what players expect: Click on self to open status window. / Click somewhere to move there. / Click on an enemy to aim (shows a targeting line), click again to fire. / Right-click on an object for more information. / Drag item from the inventory to equipment list to attach them. / Drag them from the HUD to the map to drop them… Notice the common theme here is that these all involve the mouse. Full mouse support is a must for accessibility. Players can transition to partial or full keyboard use with time, once they have a grasp of the new mechanics and other components to learn. Why force them to learn everything at once if they don’t want to?


Drag-drop example.

For players who do eventually learn to use only the keyboard (or do it right off), which right now is 26% of Cogmind players, because the mechanics don’t have much overlap with other roguelikes there isn’t a whole lot of existing experience to invoke there. In fact, I can list them all here easily: ‘?’ for help, numpad/hjkl/arrows for movement, ‘f’ for fire, and ‘.’ for wait. That’s it. The rest are unique, and there are a ton of them, but in most cases there is a pattern, or they start with the letter of what they represent, which aids the learning process.

To teach any commands that the player hasn’t figured out on their own there are two separate ‘?’ pages, one for beginners and one for experts. This is to avoid overwhelming new players with a page full of commands they won’t need right away anyway (or at all if they’re using just the mouse); instead the basic commands page provides the minimum amount of commands and information a mouse user needs to use and understand the entire interface. By comparison the advanced commands page is packed with every command in the game, including duplicates (some actions are possible via multiple different keys).


Basic commands.



Advanced commands.

Also notice that window-specific commands are displayed in their relative windows, and certain parts of the interface (for example the top-right HUD area) have descriptions explaining each piece of data.

But input is generally the lesser fraction of what a player has to learn. Mechanics are the bigger issue!


Some mechanics can and will be understood naturally through regular play, but even in these cases it’s possible to speed up the learning process, not to mention the need to teach other mechanics and stats might be too opaque or unclear without additional explanation.

The old go-to in that case would be the manual. Cogmind includes a text manual that fully explains all mechanics and UI features, weighing in at 8,000 words. But to make it easier to reference and put it where players are most likely to need it, the manual can be opened within the game itself in an interactive form.


In-game manual example.

Manuals are good when players have a lot of free time and would just like to browse or even thoroughly read through the manual for information they might not already know, and if the topics are arranged sensibly they can also make it easy to seek out information on a given topic in order to answer a specific question. But honestly specific questions are best handled at the point where they’re asked, and that means context help.

In Cogmind this is how the stats are handled, because the status page, robot info page, and item info page are all a combination of data and graphs, the meanings or implications of which won’t always be obvious to the player, and making them search through the manual each time they need to learn something is a terrible and frustrating requirement. So simply clicking on any stat provides an explanation (or for non-mouse users, pressing Up/Down and hitting Enter on an entry).


Context help example.

In general the way to head off player uncertainty is to ensure that obtaining information is as intuitive, automatic, or direct as possible. Thus another way the UI works to help the player:


Automated map labels, which help players learn the ASCII (or the ASCII-like minimalist tiles) for objects, and even if they forget them, labels are still always available to speed up the recognition process!


The player’s first contact with the interface and mechanics is of course extremely important, so many games these days start out with a tutorial (or at least make it optional and recommend it). I was originally loath to provide a tutorial at all, because I didn’t want to include immersion-breaking elements (like there’s no main/start menu), especially not right at the beginning. But from an audience-building perspective that would be a massive mistake.

So eventually I came up with an “immersive tutorial” that teaches the basics by introducing them step by step in a few short connected rooms. And these rooms are a plausible place for the game to start, so it doesn’t feel out of place.

The tutorial map, basically an alternative version of the first floor of the game that leads normally into the rest of the game, is only shown three times for each player, the first three times they play. I decided to have it repeat more than once so a new player isn’t suddenly thrown into a new and unfamiliar starting area the second time they play (this being a roguelike, the “second run” will probably come pretty quickly :P).

Also, it’s a very short tutorial anyway, and the second and third time through it doesn’t even include the tutorial messages, so it loses even that little bit of tutorial feel. “Tutorial messages” appear in the message log, hot pink and blinking and with a special beep, and still people sometimes miss them after the first few as they’re eager to explore. Oh well.

While the better alternative, modal tutorial messages, are great for forcing players to pay attention, they’re very intrusive and really ruin the immersion I’m trying to create, so I decided against that approach pretty quickly. (It’s a bit of design conflict between accessibility and the theme, which honestly plays out in many more areas than just this one, and is really annoying :P)

Anyway, each tutorial message is only shown once, and most of the important ones are context-triggered, for example telling you to drag-drop an item you just picked up in order to equip it, and they work in tandem with the tutorial map based on how it’s laid out.

A lot of thought went into the layout of the tutorial map which, unlike much of the rest of the procedurally generated world, is completely static. It’s only four rooms total, and the idea is that the player encounters elements in a very specific order, without simultaneously seeing other elements that would distract them from what it is they’re supposed to be learning at that time (despite how small the area is).


Tutorial map layout with explanation (click for full size).

In those four rooms the player learns pretty much everything they need to have a good time, which is the best way to start any roguelike :D. Sure there is plenty more to learn, but that can all come with time. Also, for comparison check out the regular non-tutorial start area:


Standard Cogmind starting area. There are only two rooms, where the player starts with more options for gear--all in the immediate vicinity--and then can head over to the next room and leave right away.

Independent of the tutorial map, later in the game as new elements are encountered, there are some tutorial messages to explain features that might be incredibly important but not necessarily obvious--for example bumping into machine control panels to interact with them. At various timed points there are also other more general non-context reminders, telling the player about the manual, or how to save and exit, etc.


Turn counts on which time-based tutorial messages are shown.


Sometimes players like to seek help outside the game, and that’s where having a community comes in handy.

Letting individual groups of players spring up in their own forum threads wherever they may be is nice, and that will happen regardless, but it’s still worth having dedicated forums these days, so I did that and love the community interaction it brings. When players ask questions in a public forum dedicated to a single game, the answer can in turn help anyone else who comes looking for similar help.

I set up /r/Cogmind for a similar purpose, but Reddit is a pretty terrible format for a long-term community that can benefit from preservation of information and more convenient search functionality, so it’s more of a communication channel than a great source of help.

In either case, though, communities have advantage of providing a type of help that isn’t usually provided by the game: strategies. This is something a manual won’t cover, and while in Cogmind there are NPCs who give tips for survival, that can only cover a small portion of the potential useful advice… So player guides are another valuable form of third-party help :)

Many roguelikes of significant size and following also end up with a wiki. In my case rather than wait for someone to create one on some free site with ads and that we don’t have as much control over, shortly after releasing I set one up on my site. It’s almost entirely run by players.

Hopefully all these features (and who knows maybe more to come?) will be enough when Cogmind reaches the hands of even more players in the future!

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


  1. Quadko
    Posted July 28, 2016 at 1:42 am | Permalink

    I appreciate the thought and features to make the game easier to pick up. I’ve got a bunch of games I’m excited about but haven’t gotten up the learning curve that have been on my list for years now. And one, my first PC game, Star Fleet I, that I used to know how to play as a teen but have lost it in the years between.

    So thanks, and good luck! Do what you can!

    And tangential technical question: how do you run the animations? Do you have a display timer you key animations to, separate from the world timer, or how did you handle that? I haven’t found a design I really like for animating in a turn-based game world, any basic recommendations?

    • Kyzrati
      Posted July 28, 2016 at 9:00 am | Permalink

      I use the common input(), update(), render() approach (sample code). Being a turn-based game, game logic doesn’t require a real-time timer, but the animations naturally have to obey one. Unfortunately there are problems with my own solution because the game logic is actually partially tied into the animations themselves (at least the combat animations). This is not a very common way of doing it (to my knowledge, pretty much all games decouple animations from logic). I also do hackish things like reset the timer at various points to avoid bugs and glitches, so it doesn’t even match up to the program timer itself… I basically bend time to my will, mwuahaha :P

      You can read more about animation solutions in Cogmind and other roguelikes in this FAQ.

    • Posted July 28, 2016 at 7:10 pm | Permalink

      I asked Kyzrati more or less the same question on twitter a few hours ago :D

      I am working on a roguelike / strategy game and have managed to keep the game’s presentation separated from the game’s logic so far.

      Basically none of the objects in my game know anything about drawing themselves. I have a WorldPainter class which iterates over the map and determines how a tile needs to be drawn. It looks something like this:

      local function selectTileSprite( tile )
      if tile:isOccupied() then
      -- Draw character

      if not tile:getInventory():isEmpty() then
      -- Draw item icons

      if tile:hasWorldObject() then
      -- Draw world object


      To keep this fast even on large maps I mark tiles that need to be updated with a boolean flag and make heavy use of spritebatches. That’s basically how I draw the map and everything on it. Besides that I also have an OverlayPainter for things like movement paths and other UI elements.

      For animations (shooting, explosions) I have a different class called ParticleLayer. For example if a character shoots his or her gun the projectile will send a notification (currently using a Messenger pattern) to anybody who cares.

      Messenger.publish( 'PROJECTILE_MOVED', projectile );

      The ParticleLayer listens for certain events and creates animations and particles for them. It’s still pretty rough around the edges and nowhere near the quality of Cogmind or X@Com, but it seems to work fine so far.

      Since the game doesn’t even know about the ParticleLayer it doesn’t wait for animations to finish. That’s not a big problem though as animations are tied to actual game events which take care of timing the turns. I guess once I implement larger explosion animations and stuff like that I will at least have to add a way to make the game wait for the animations to finish (but I’ll think about that once I get to that point).

      • Kyzrati
        Posted July 28, 2016 at 7:32 pm | Permalink

        Yeah that’s one of the main things that baffled me at the start, with regard to the logic not caring about the animations, so, for example, you shoot and the target has to wait for the projectile to reach it before the effect can be shown, but how is it notified? So I have the projectile directly notify what it actually hits after the fact, and in my case projectiles themselves don’t actually even know if they will hit their target, or what they will hit--they just fly along a given trajectory. (This works fine unless you want to enable the common roguelike option to enter commands as fast as possible to interrupt animations, so my alternative approach was to just make most animations quite fast, and the player will generally need/want to see them carried out real quickly anyway to understand what’s happening. I actually wrote about this a couple years ago.)

        This approach gets even more complicated with sound (have you thought of sfx yet?!), because if you cannot hear nor see a given animation, then it shouldn’t play out at all right? That enables things to happen elsewhere on the map without slowing you down, so I had to develop a parallel system that checks whether it’s likely something will be heard at all, and if not then it runs a separate simulation to get the results instantly.

      • Quadko
        Posted July 28, 2016 at 10:52 pm | Permalink

        Cool, thanks for the tips and discussions. I’m looking forward to reading the animation FAQ. :)

        • Quadko
          Posted August 4, 2016 at 1:53 am | Permalink

          …And I really enjoyed the animation FAQ, thanks for writing that up and pointing me to it. Interesting to read about the pragmatic approach you took and the results you are getting. Cool!

          • Kyzrati
            Posted August 4, 2016 at 9:53 am | Permalink

            Haha, “pragmatic” is such a positive way to look at it… :P

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>