Official development blog

UI Feedback: Map Dynamics 2.0

A while back I mentioned a design initiative based on the concept of “map dynamics,” aimed at increasing player focus on the map area as opposed to the message log or other windows. After the initial spate of related features and animations, this part of development was put on hold as the rest of the game took shape.

With much of the game complete, and development inching ever closer to needing a more polished-looking dynamic interface before reaching out to the average gamer, it was about time to revisit this topic since we could now identify all the necessary features and implement them in a consistent manner all at once.

Before now we didn’t have a dedicated system for handling the large number of UI animations that would layer over the map area, as it’s tough to design a system without knowing the full extent of what you need it to handle. The resulting implementation (i.e. code-wise) is less flexible than I’d like it to be, but on the outside it looks cool and the style is consistent throughout. (At this point I’m happy to sacrifice code quality if it’ll get results, but I’ll stop myself wherever it threatens to screw me over in the future).

Might as well pick up where we left off in February.

I went back to the “explosion prediction” feature and added brackets that show the explosion’s maximum theoretical area of effect, just for reference since you can already see the more important shades of color representing damage falloff and obstacle blocking.


Explosion Prediction System 2.0 (I predict… you’re all going to die. I was right!)

There was more pure “fluff” animation I wanted to add to the UI for missiles and explosions, but that was cut as a feature unnecessary for 1.0. Almost every other animation on the list was implemented, because they offer meaningful feedback or other information to the player.

Object Identification

No, I’m not talking about the “ID minigame” (subsystem) present in many roguelikes. More basic than that, the first step before you can take each action in a game is to identify what’s what in the environment around you. Although proponents of tile-based games might argue otherwise, this isn’t an issue unique to ASCII roguelikes. Sure objects are represented by letters instead of images, but the devil is in the details and you really need to know exactly what you’re up against (enemies) and what tools are available (items). Images don’t convey that information perfectly until you’ve learned what the game tells you they are, which is no different from an ASCII interface!

I remember holding the Alt key in Diablo 2 (sort of a roguelike, yeah?) to instantly see names for all items on the ground. That sure saves a lot of time and makes sense in any game where loot is plentiful (Diablo, Cogmind…)


You can now call up labels for all items on the map, even those outside your field of vision in areas that you’ve visited before.


Item labels.

This is great for both surveying all items in view, and locating some item elsewhere on the map that you may not have cared for earlier but now really need and can’t recall where you saw it. Of course, depending on why this hypothetical item was there in the first place, it may be gone when you arrive! Remember that recyclers clean up after a battle, or if they find items strewn about where they’re not supposed to be (e.g. your stash).

In the 7DRL you would know this item was already gone, because (no one ever mentioned it, but) back then you could technically see doors being opened/closed, walls being destroyed/repaired, and items being dropped/picked up outside your field of vision as long as you had been to that area of the map before. It just wasn’t very noticeable under the green overlay; plus you probably wouldn’t expect the game to be so lenient in that regard. For the prototype I never had time to code a solution to properly record and conceal everything. As part of this latest update, explored areas of the map no longer automatically reflect changes since you’ve been there. They remain as you last saw them, including even labels for items that no longer exist.

With these and other labels below you can also see additional benefits from having a separate font for text and map (an idea I’ve discussed before): More label content fits in a smaller area, and the narrower font helps naturally distinguish label information from the rest of the map, an important necessity in ASCII roguelikes since the map consists of mostly alphanumeric glyphs as well. You’ll notice that to reinforce that difference I’ve opted to use a style which inverts foreground and background colors.


Labels on Demand™ are also available for the other most common map object: robots. Hostile and allied robot labels are activated separately. They display the robot class (not full name), and are color-coded by that robot’s remaining core integrity (from green to red).


Robot labels (hostiles).

Disarmed combat robots will be labeled instead with gray, so you know they are no longer a threat.

Notice that with all labels they automatically attempt to reorient themselves to avoid covering each other or important features (other similar objects):


Auto-orienting labels organizing themselves into the most visible arrangement possible.

Where there’s a really huge cluster of items/robots some overlap will be unavoidable, in which case there’s always the original scan window as a fallback for identifying objects. Plus that gives you more detailed information, anyway.


The whole point of the game is to move forward, so finding map exits is a very high priority. Finding the right exit is even more important since they don’t all lead to the same place and you won’t always want to immediately head through the first exit you find. Thus exit labels are fairly important and useful to have access to.

Calling up labels for exits will pinpoint their location as well as display the name of the destination, if known. Unknown exits appear labeled with question marks:


Exit labels.

While there’s nothing stopping you from entering an unknown exit (except FEAR! =p), you will often want to do a bit of hacking to figure out where exits lead.

Because Cogmind maps are quite large compared to the average dungeon roguelike, it’s very likely that exits will be out of the map view area. Thus when you activate exit labels, they will identify even those previously discovered which are now off screen--if you can’t see a label it will show an alternate label (simply the name of the exit) at the edge of the view in the direction of that exit. These labels automatically reorient themselves along the map edge as you shift the view.


Shifting the map to seek off-screen exits.


We can take this system one step further by automating label displays where it makes sense.

Now when you spot a new hostile robot for the first time it will automatically be labeled directly on the map (with its full name rather than the class designation shown for manual labels).

All newly spotted items are labeled as well--it is AMAZING how useful this is compared to the 7DRL where you had to mouse over each item to identify it. Using look mode via the keyboard to tab between visible items was/is pretty fast, but “fast” can’t really compare to “instant” ;). Simply by walking into a new room you can tell if it contains anything you want.


Auto-labeling items and robots. For the grand finale I blow them all to pieces.

Unlike manually accessed labels which only display one type of object at a time (either robot or item), as you move around automatic labels of either kind might appear, so you’ll notice they use a different color scheme to avoid confusion. While robots are labeled green to red by remaining integrity, common items are gray, prototypes are white, and anything outside your current field of vision is blue. (There’s a fourth classification with its own color, but that one’s a secret.)

Auto-labels for threats and items are individually toggleable in the options menu, if you don’t want them.

Auto-labeling of exits is accompanied by a recognizable beep that should stand out from the other interface noise, since exits are so important, though the larger label size will make it pretty apparent:


Finding and approaching an exit.

Input Scheme

We’re kinda running out of keys on the keyboard--how are we supposed to control manual labels?

First of all I freed up the numbers. They were originally used to access information about inventory objects, but that was actually a minor inconsistency in the input scheme I’ve been wanting to change anyway. Inventory item information is now Shift-#, which corresponds nicely to the Shift-a~z used for attached part information.

Press a number 1~4 to label hostiles, allies, items, or exits. Pressing the same number again, or Esc, will deactivate the labels immediately if you don’t want to wait two seconds for them to expire and disappear on their own.

We’re also running out of UI space, so a new solution was required for mouse support. Fortunately object label buttons fit nicely, both physically and conceptually, in the existing scan window. The buttons need not be always visible, so simply hovering the cursor over what is normally an informational scan window switches its contents to a list of buttons that can be clicked to call up labels (or cancel them if you click again).


Using the mouse to access labels.

Note that if there are no objects of the desired type to label, a message is shown to that effect at the top of the map view.

While keyboard look mode won’t be as useful anymore given that you can display map-wide labels instantly, it also auto-labels any object the cursor passes over. The name and details also appear in the scan window as usual, but it’s nice to not have to move your eyes away from the map.


Object auto-labels in keyboard “examine mode.” At the end of the recording I’m using hotkeys to automatically cycle between robots/items rather than shifting the cursor via movement keys.

Side note: I wonder how many players will actually use pure keyboard mode? Or whether anyone besides myself used it to play the 7DRL?


The labels introduced above are all useful both in and out of combat. We also have a collection of new labels that provide combat-specific feedback.

After a certain (adjustable) delay on entering targeting mode, the map displays the chance to hit each hostile robot in FOV.


Automatic hit% labels in target mode.

Where combat is concerned, the results of an attack are the most important feedback element, one that wasn’t too obvious in the 7DRL. Back then I did add a “calculations” window in which you could see the values used in the attack formula along with precise results.


The calculations window showing more specific attack results. (That armor I happen to be using for testing so I don’t get hurt =p). The level of detail shown is adjustable in the options. Content is also scrollable just like other log/message windows.

That window still exists (above), but we can make the most important information much easier to obtain through more on-map auto-labels for attack effects. If an attack damages a target’s core (not a part), the map will flash that robot’s remaining core integrity (as a percent). Destroyed parts are also named, and there’s an indicator when a core is temporarily disabled (some electromagnetic attacks).


Attack effect auto-labels, Cogmind’s version of the “floating numbers” you see in many games.

The system was originally also showing white numbers for EM-caused system corruption, but I decided to remove that for now since I think it works better as an unknown factor.

Combat labels are entirely optional because some players may consider them too intrusive. Attack effect descriptions do get in the way of enjoying the particle effects.

Being Spotted

Just because you can see another robot does not necessarily mean it has already seen you, but this information was never communicated in any way in the 7DRL. Now whenever you see a robot that has started tracking you, the space it occupies will glow for a bit.


Spotted by several hostiles on entering a corridor.

Technically a hostile robot may have started tracking you before you saw it, if it got your location from another robot or simply has a greater sight range, but it doesn’t glow until entering your FOV so you know it sees you. In case you missed the glow or aren’t sure, this information is now reflected in the scan window with a red ‘!’.


This robot has spotted and is currently tracking you.

Now that we have a more reliable way of knowing whether you’ve been spotted, I’d like to eventually add ECM mechanics that can temporarily prevent robots from noticing you even when you’re in their FOV. This would make melee approaches more interesting and provide another tool for the stealth-oriented build. There is already a set of ECM parts, but they only work to escape detection after being spotted and tracked rather than avoid detection in the first place. [New ECM mechanics are for much later, since we’re beyond the point of adding unplanned features until at least the first release.]

The next post will examine more feedback features (and UI animations!), especially as it relates to utility parts.

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


  1. kripto
    Posted November 14, 2014 at 9:47 am | Permalink

    Don’t worry about keybord-only, I find the idea of playing classic roguelikes with a mouse is absurd to me, and if the keyboard controls are as good as they seem to be it won’t be an issue.

    • Kyzrati
      Posted November 14, 2014 at 10:04 am | Permalink

      Excellent! Lots of people played the 7DRL, but I’d never heard of anyone using pure keyboard input (although I did hear some using *mostly* keyboard and liking the scheme). It really is fast, and the controls should be intuitive--plus there are letters on screen for almost everything except the most basic actions which you’ll be using all the time from the start anyway (‘g’ for get, ‘f’ for fire, ‘<' for stairs, movement keys--keypad, vi, or arrows...). Thanks for mentioning you'd be into it :)

  2. Phil
    Posted November 14, 2014 at 8:48 pm | Permalink

    Hi Kyzrati,

    as a graphics designer and roguelike player your blogposts are really interesting. You’ve probably thought about it (might even have implemented it) but here’s a suggestion: Can you combine scan window and the new label view? If you open the scan window and select an item, the selected item is highlighted both in the scan window and via label.

    As I said, you probably already thought of that. Keep on rockin’, can’t wait to pay and play!

    • Kyzrati
      Posted November 14, 2014 at 10:33 pm | Permalink

      Hey Phil, glad you’re enjoying the blog! I’ll try to keep it interesting for you ;). I like graphic design and solving usability problems, plus I’m an efficiency nut, so exploring and writing about these kinds of topics is a lot of fun.

      Normally when you hover the cursor over an object, the scan window shows its name and information about it. If I’m understanding you right, what you’re suggesting is that when that information is shown, the item is also labeled on the map (so basically, labels appear when hovering). This already happens in keyboard-based examine mode (as shown in one of the gifs above), but it only works because you’re in a special mode where the purpose is to examine objects. If the same behavior were applied to the cursor in general, you’d end up seeing way too many annoying labels during normal play, as quite often there are lots of items littered across the map. (As you can probably tell from some of the gameplay gifs, Cogmind has far more items than most roguelikes, and you won’t be picking them all up.)

      Perhaps this feature could be implemented with a delay (i.e., hold the cursor stationary over an object for a moment to see the label), but that seems to defeat the purpose of getting the information more quickly than you could by glancing at the scan window.

      Please tell me if I’ve completely misunderstood what you’re saying here!

      By the way, there is no other way (or need to) “select an item” so to say. If you right-click on it, the full info window is opened.

      • Phil
        Posted November 14, 2014 at 11:19 pm | Permalink

        Well my thought was this: Say you had cleared a map and there are a lot of items on the map. You’re looking for ammo. You could use label on demand but there would be a lot of overlap and you’d have to manually scan for ammo. The fallback (as you said) would be the classic scan window. Depending on the sorting (by alphabet for example) it would be much easier to find the ammo and hovering over the ammo in the scan view would highlight the corresponding label on the main map.

        English is not my first language, not sure if I’m expressing myself well. Also, again, my idea might be idiotic or already implemented or obsolete! ;)

        • Kyzrati
          Posted November 15, 2014 at 8:49 am | Permalink

          Ah, thank you for the clarification and usage scenario.

          Having a map full of items later on is definitely an issue, not really because of overlap (which doesn’t happen too often because labels for a single object can go in any of six directions, and automatically avoid each other where possible), but because there are so many of them it can be hard to visually scan for what you want.

          As such, I think that particular problem deserves its own separate solution: a search feature. Some way to call up a text box in which you enter a full or partial item name and it can take you to that item (or highlight them all on the map if more than one), or perhaps a more effective implementation would be a separate window that simply lists all known items on the map, and from there you can click on one to zoom in on it.

          The implementation is pretty involved for that one feature alone, so it’s something I’d probably add later once the game is already released. But now that you mention it I should write it into the design doc because it’s not yet formally recorded anywhere. Thanks a lot for bringing it up!

          And your English is fine. I couldn’t tell it’s not your first language :)

        • Kyzrati
          Posted November 19, 2014 at 6:07 pm | Permalink

          After some more playtesting, I realized that there are enough situations where you have large and dense clusters of items to warrant adding a mouse-related solution beyond the current scan window. It’s true that in some cases the clustering causes unavoidable overlap of labels, where an even better/quicker possibility for examining dense groups of items is to show those names directly over the map itself, one at a time as you suggest.

          To avoid the whole annoyance factor (labels popping up while simply moving the cursor for other tasks), you have to hold keys for it to work (ctrl+shift), but I rather like the utility of it as this feature does fill a gap that wouldn’t quite be satisfied by the kind of search window I described. You can see the new feature in action here. Thanks for the suggestion!

  3. Posted November 15, 2014 at 10:16 am | Permalink

    You’re setting the benchmark for roguelike UI. All the things I ever wanted to do, but was too lazy. And I’m sure others also had the desire, but couldn’t be arsed. Our loss!

    One thing I think about when looking at graphical text-based roguelikes, like those based on your engine, and those based on libtcod, is that for the most part there’s no real reason they can’t also have an ANSI/ASCII/curses backend. And this is why I always pull back from doing a custom font which extends the standard set of characters, with custom pixeled options. But the further someone goes down the UI path, this also adds cost to any curses backend with a significant cost in ansi codes being sent. Then again, if one is going to do something like ttyrec, to allow others to replay the games, or to be able to view the games online, I guess a subset of UI-related ANSI events could be excluded from the logged record.

    Anyway, keep up the good work. And maybe open source your engine, but not GPL because it inhibits freedom ;-)

    • Kyzrati
      Posted November 15, 2014 at 3:50 pm | Permalink

      Thanks--I hope a higher benchmark doesn’t discourage anyone from developing new roguelikes =p. Of course, at the same time seeing cool stuff inspires some devs, so hopefully we’ll see more inspired roguelikes in the future.

      Well, your “laziness” that’s preventing you from spending all your time on your own RLs means you have time to revive Incursion, an effort we all appreciate :D

      I don’t have any experience with curses, but I can imagine it could be difficult to use a standard terminal to perfectly replicate what REX (the Cogmind/X@COM/REXPaint engine) can do. I’ve thought about trying in the past, just to see. Theoretically it’s not impossible, but I don’t believe the result would look as good. I do think curses games can look and feel wonderful (see TGGW for a modern example), but once you add extensive animation to the mix it might be tough to achieve the same smooth aesthetic.

      Maybe I’ll open source one day, but it’s not a near term consideration. Actually, I think anyone capable of using the engine could probably just as effectively write their own. Using it requires class inheritance and there’s quite a large number of features yet zero documentation :/. One reason (among several) I don’t consider open sourcing now is that I would feel obliged to help people use it properly, and that would be a huge effort. Props to Jice for his work on libtcod.

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>