The Map Ruler (and other overlay QoL)

As the player’s gateway to accessing the experience they’re after when they want to play a game, building a fluid and comprehensive interface is essential. Many high-priority player needs should be apparent in the earliest stages of development, and help shape the entire foundation for an interface’s design, but still other needs with lower priority may only gradually become more obvious over time.

If you find that players are spending extra time doing a certain task that could be facilitated by improvements to the UI, then hopefully those improvements are feasible and there’s time/resources to add them! Honestly doing everything possible is unlikely--in a sufficiently complex game the list of possibilities seems almost endless, plus of course it has to be balanced against investing in other features.

I enjoy UI/UX work and recognize its importance, so naturally every release of Cogmind comes with its fair share of QoL features, and the huge upcoming release (Beta 11) is no different. In particular a collection of map overlay ideas has been building up in my notes over the years, so recently my tendency to work on related features in batches kicked in and several new options were born: a map ruler for measuring distances, a more powerful volley data visualizer, and robot FOV overlays…

Ruler Overlay

Roguelikes traditionally take place on a grid, and it’s not uncommon to need to know the distance to a location for the purposes of movement, magic, guns, abilities, etc.

Given the discrete grid, this info is generally not that hard for experienced players to visually estimate, although in cases where knowing precise distances is important for optimal decision-making and one miscalculation could mean the difference between a tactic’s success or failure, it’s much more efficient and reassuring if the game can just calculate and display the desired details. Computers are good at calculation, after all.

Previous versions of Cogmind have already contained some ways to use the UI to confirm distances in certain cases, like the Volley window active in targeting mode that constantly updates its range readout to indicate the distance between Cogmind and the cursor location on the map.

Showing the the volley window rangefinder distance readout (top right, “R=”).

However, since its introduction this has only ever actually worked with ranged volleys, so melee builds haven’t been able to take advantage of it for this purpose.

Attached weapons and utilities also display their range circle over the map if hovered over with the mouse, or in the latter case many utilities also animate their AOE during their toggle animation, meaning these other features can be used to at least indirectly measure distances, although this is fiddly at best. That said, in the past I’ve definitely relied on this design to help quickly calculate distances, another sign that we need some kind of dedicated “ruler” feature :P

Another argument for a dedicated ruler is that all the existing methods of using other UI features to measure distances assume you want the distance from Cogmind’s current position, when that may not be the case. In fact, many cases of wanting to count spaces arise from a desire to know the distance between two other arbitrary points. Like if I move to this particular coordinate will I be within range to shoot that other position? Or once I reach a certain location, how many more spaces is it (and therefore how long will it be) before I can cross over to another spot?

Enter the new ruler overlay:

No more guesstimating just how far it is between two cells!

As you can see above, the new ruler overlay shows the distance to every other point from wherever the cursor is positioned, suitable for any general distance calculation need. It’s just an overlay, so of course equally compatible with keyboard mode:

Is that ASCII or a ruler? :)

It actually took a while to come up with the best way to visually represent this ruler from among the many options in terms of layout and colors. The underlying functionality itself is quite simple of course, just showing the distance to each cell from an origin, but many more hours were spent figuring out how to display the values in a readable and good-looking manner.

Double-digit ranges are too cramped to print out in full, resulting in a massive block of numbers, so I decided on the alternative of using double digits only for clear thresholds--multiples of ten, which makes the whole thing much easier to parse. I mean the final iteration is by necessity still a jumble of numbers, but at least pretty quick to read by comparison!

The earliest test version of the ruler overlay when it still retained full digit values. I also tried variations of coloring and checkering, but it only made things worse :P

Another early concept where I’d decided on the threshold approach, but still had yet to include unknown cells in the measurements. One player suggested that could come handy for the occasional need to measure across partially unexplored areas as well, so I added that as seen earlier.

Control-wise, the ruler overlay is toggled via Shift-Alt-x (mouse toggle still to come), and since it’s not modal or anything, just an overlay, technically you can continue playing while it’s active, although naturally it covers up a lot of important info!

The ruler is nice for planning, but playing while it’s active is not officially recommended :P

Do it for the cool (or crazy!) factor?

Terrain Destructibility Visualization

A common question while playing is “can I destroy that piece of terrain?”, be it a wall, machine, or some other prop. This usually involves checking the armor and resistances against your current (potentially modified) volley damage, and although it usually doesn’t take all that long to figure out the answer, crunching data is again what computers are good at, so now I’ve mostly automated that process with a single button :D

This feature is integrated into the volley range visualizer, which has always been useful for showing the relative range(s) of active weapons, but now also highlights in red the foreground of visible destructible terrain depending on whether or not the current volley is capable of destroying it.

Even better, it also checks the player’s inactive weapons and searches through their inventory for other weapons that might still be able to destroy terrain and in that case gives it a different color glow (yellow).

Here you can see it in action, where the Assault Rifle isn’t capable of taking any of the machines, the Beamcaster can only destroy one, and none can destroy the Fabricator (thus it always remains blue):

Terrain destructibility visualization demo.

The calculations generally take into account all applicable sources of damage modification, e.g. active utilities, current momentum, resistances, etc. The appearance of terrain the player doesn’t likely have the means to destroy at the moment remains unchanged. Note that even in such a case, it may sometimes still be possible to destroy the terrain using other means, since the system does not take into account inactive utilities or those in inventory, special weapons, the environment, or other means to creatively destroy terrain, but it is at least a useful way to quickly confirm that you already do have the capability.

FOV Overlay

Warning: Although I’ll be describing this feature here and even showing demos, it may not actually end up in the final public release of the game, or at least not quite in this form :P

Player-mob spotting is usually not perfectly reciprocal in roguelikes, as in enemies the player can see may not simultaneously be aware of the player, and vice versa. This provides room for additional relevant abilities and/or tactics (stealth/speed/sneak attacks/sniping/etc), as well as allowing for some level of risk taking (might I be able to slip by these enemies undetected?). However, very few roguelikes will actually display on the map those locations where actors can spot enemies (if doing so even makes sense given the mechanics and variable nature of being spotted).

In Cogmind there is an indicator for robots that spot the player, but before that pops up you can’t always be sure whether moving to a given location is close enough to be spotted in the first place, especially where obstacles like machines come into play since they can be used to partially obscure line of sight. The fact that robots can only fully spot you on their own turn further adds to the uncertainty, since quickly passing through their FOV might even go undetected.

Over the years there have been a few requests to allow players in Cogmind to see the FOV of enemies, but for a number of reasons I’ve always avoided adding this feature.

The earliest reason is the significant processing cost of calculating a proper FOV for what is potentially a lot of nearby robots, and it’s for that reason that when I converted X@COM to create the first version of Cogmind back in 2012 I decided to rewrite the entity sight handling to not actually use real FOVs and instead use a method that would scale better for the huge number of robots in Cogmind, specifically just calculating LOS between important points as necessary. This was far more efficient, and still is, for more or less the same results.

Nonetheless, for a temporary FOV overlay display used at most in short bursts and/or with lower robot counts it’d probably be doable these days, so I recently wanted to play around with the idea since it was still on my ever-growing List.

In short, Shift-Alt-v toggles robot FOV overlays, allowing you to identify every cell that each enemy can see. All the FOVs are combined unless examining a single robot, in which case it only highlights areas visible to that robot in particular:

Keeping an eye on the FOV of several patrolling bots to avoid detection.

While we’re at it, there’s no reason to limit it to just enemies…

Another FOV overlay demo in ASCII+keyboard mode, also tabbing around to different robots including even non-hostile bots (neutral FOVs appear gray, and ally FOVs appear blue).

Object popup labels are not active in this mode, since the main intent is to observe the area covered by FOV, and having labels pop up interferes with that goal.

The visualizer also takes into account active Cloaking Devices, using darker shading to represent the FOV reduction effect.

The overlay shows how much closer you can get to that Watcher due to the cloak effect.

So for the most part the implementation worked out okay. I did also have to put some time into optimizing to bring it within acceptable bounds because it could really tank the FPS, and while further optimizations would be possible, they’d also require a large amount of work compared to what was done already. In any case, the problems I have with this feature are actually now somewhat less technical and more on the design side…

My biggest concern is that as a freely usable overlay this has the potential to really change the feel of the game in a lot of situations. Where without this information you’re kinda guessing at the edges of enemy FOV (especially due to the effects of machine obstruction) and maybe have to deal with the consequences of a surprise spot, always knowing exactly what visible enemies can see takes some of the suspense out of those moments.

A smaller concern is that when people can see FOV for all bots, they might not understand or like some of the results and report them as bugs, when it’s simply nuances behind how the system is designed.

Then there are the logic issues. Unless I put a huge amount of time (and program memory) into building a secondary world data and FOV system around what the player remembers rather than the actual map layout, the current approach can sometimes indirectly reveal information you shouldn’t actually know (e.g. missing walls, open doors, and various other situations).

One way to circumvent the logic issues entirely, and also somewhat reduce access to this feature, would be to make the FOV overlay only available by attaching a dedicated part, or perhaps a new RIF ability, which would quite in-theme.

That said, I wonder how necessary that even is given that we already do have the Triangulator utility which… no one really likes xD (in fact, the community makes fun of it all the time!)

One of a Triangulator’s several functions: See how close enemies are to spotting Cogmind.

Granted, an overlay is much easier to use and less situational than requiring a part that vies with other utilities for a slot, and also more broadly useful since it allows for visualizing the greater FOV rather than just LOS with Cogmind, meaning the ability to see what bots can spot other bots, and also for example plan a possible route past enemies by seeing the limits of their vision in other directions.

Having complete FOV data might indeed make for some interesting precise stealth planning, but in my experience you can get a lot of those moments just fine without it, and I do feel something is lost by showing everything. Unlike the ruler and terrain destructibility, this is not pure QoL--it can actually have a significant effect on gameplay and the whole feel of the game.

We’ve done pretty well with Cogmind’s existing system of hidden FOV for years, so I think this feature might end up getting canned, but having implemented it for testing anyway, I did recently include it in experimental patron builds to try it out for fun and science.