Official development blog

FOV Aesthetics

At its most basic, displaying field of vision in a roguelike is simply a matter of whether you see a cell or don’t. These cells are in view--draw them; those cells aren’t--don’t draw them :P

But there can be more to it than that!

There are plenty of ways to get better-looking FOV, though before recently I hadn’t spent any time exploring them in the context of Cogmind. By contrast, this was something I did early on with X@COM, because FOV plays an even more central role in that game, being directional and having control of multiple units each with their own viewpoint. With Cogmind it was never a high priority or even something I seriously considered since the FOV system’s original iteration couldn’t handle additional processing, and the central algorithm had already been highly optimized as part of the pre-Cogmind engine’s code base.

However, last week while playing around I realized there’s now a lot more breathing room in the system, enough to make some experiments worthwhile.

These experiments have paid off in the form of new FOV features described below :D

To clarify, this article is concerned with the aesthetic side of FOV, rather than how to determine what is visible from a given position. For the technical side you can see an earlier post from 2013, and also check out this FAQ for how myself and others calculate it.

Within FOV

Some roguelikes allow for dynamic FOV-affecting elements within the player’s own FOV. This includes features like light sources, or fading/darkening objects that are further from the player.

Dynamic lighting is great for realistic environments. I use it in X@COM, where it’s quite an important part of both the realism and mechanics, so there are lamps, light posts, flares etc. that can light up areas of the FOVs around them when ambient light is otherwise low.


A night scene from XCOMRL, showing light emitted from soldiers (triangles) and lights (‘L’--the source of light for the gray ones along the road is actually three floors up).

Cogmind intentionally doesn’t do any of this, but I’m including this feature in the discussion for completion’s sake, and to explain why :). Unless a roguelike is specifically designed around this (say, a pure stealth roguelike where lighting is a core mechanic, or a world in which light plays an important role in creating the atmosphere), it can easily become an unwanted barrier, obscuring tactical information in a way that brings out biological differences between players (e.g. eyesight), something best avoided where possible in game design.

The FOV area is where a player needs to be especially aware of what objects can be seen, and just as importantly, where those objects might not be seen. The latter can be difficult to discern within an FOV of variable (non-uniform) brightness. Clarity of tactical information is of utmost importance to a roguelike given the emphasis on gameplay over visual appeal. This is also why Cogmind’s map view is generally quite static, and contains a lot of black (few to no background colors except when something important is happening/displaying, like combat or object labels and other UI feedback).

So I’m glad this isn’t a necessary part of Cogmind’s world (that way it doesn’t interfere with other goals of the design), though I’ll likely want to put more work into the FOV design when continuing the X@COM project (yeah, “it’ll happen one day”).

Outside FOV

How to display what’s outside the player’s FOV is pretty important, too, though of course for different reasons. Players need to be able to scan previously explored areas for reference, and those areas need to be sufficiently distinguishable from currently visible areas (especially the floors so that it’s possible to easily locate the FOV edge in open areas). At the same time objects outside FOV ideally must be distinguishable from each other as well!

From the outset, Cogmind has technically included four different “extra-FOV display modes” that it inherited from X@COM. These alternative modes make sense in a game like X@COM, but are pointless in Cogmind, as ambient light levels are static and uniform, and there’s no dynamic lighting, so Cogmind has only ever used one of them (of course it’s the most processing intensive one :/). But while we’re here, might as well look at what they are:


Comparing XCOMRL’s four methods of displaying non-FOV space (click for full size). Bonus image: FOV coverage mode showing exactly where each unit can see.

For Cogmind, to fit the theme an additional green overlay was layered over method #4 (unlit grayscale):


FOV vs. non-FOV areas in a Factory map.

Note that because the original colors of terrain and objects outside the FOV are different, and that helps distinguish them under normal circumstances (while in view), the grayscale method is best because it reflects those differences. The simpler alternative, using some static darker color for everything outside FOV, is harder to parse because objects lose that relative brightness and then shape takes over as the only way to tell objects apart. Not very helpful:


The previous scene shown instead with a uniform green--no good. I am, however, considering an additional FOV toggle for non-FOV areas, which you can see in these darkened and full color experiments.

Conclusion: Grayscale conversion is awesome.

I use the luminance method to convert, taking the original RGB components of a cell’s foreground color and setting each value to a new value created by combining 30% of the original color’s red component, 59% of its green, and 11% of its blue (e.g. r = g = b = 0.3*r + 0.59*g + 0.11*b).

FOV Transitions

So most of the above is background/supplementary to the meat of what I’ve really been working on lately. While I haven’t made any changes to the appearance of FOV, inside or out, when the player is just sitting around thinking about what to do next, a lot of time is also spent moving, and that now involves some interesting new display options.


FOV options!

Delayed Updates

Since 2012 (!), when any obstructing terrain was destroyed, FOV would not be updated until the current action completed. This could delay an update until a 1-second explosion fully plays out, for example.


Delayed FOV updating in action.

There are multiple drawbacks to this method: We can’t always instantly see all the results of an action (feedback delay), and explosions appear overly constrained in some situations despite having technically already blown through obstructions.

The main advantage is speed: FOV is only calculated once no matter how many doors, walls, or machines an explosion blows through. The locations of every FOV-affecting change to the environment are stored in a list while the effects of an action are being carried out, and at the end of that action the engine checks if the player can currently see any of those locations. If they can then it updates FOV.

This “delayed update” option is still available, because as the least processing-intensive method it might be useful on an extremely slow old CPU. Otherwise there’s no reason to not go with method #2: real-time updating.

Instant Updates

Last week I realized that Cogmind doesn’t really calculate much in the way of FOVs, not like its parent game X@COM (dozens of units each calculating FOVs in a 3D environment, on top of omnidirectional FOV-based light sources). Cogmind has hundreds of AIs in a single map, but they use a non-FOV visual detection method, so all we have to calculate is the player FOV and possibly those of their active drones.

The “instant update” option also checks the same list of environmental changes, but rather than waiting until the action is complete, it’s allowed to recalculate FOV every single frame as long as there has been some change.


Instant FOV updating in action.

This is the common and natural way to handle it in a terminal roguelike, but large-scale turn-based games with other CPU-intensive routines to carry out might delay this kind of update until the end of an action (or they’ll delay it for design reasons). Cogmind’s original FOV system, together with the game’s heavy use of animations in some cases, was that kind of barrier to instant updates when it was first developed, which is why instant updates weren’t a thing to begin with.

Fade In

Even with instant updates, when Cogmind moves or obstructions are removed, newly revealed FOV areas just *pop* into existence like you see in most roguelikes.

Why not have the new area fade in? Some players will appreciate the extra flair, and it does perhaps introduce a slight benefit in that for a split second you can differentiate between what’s new and what isn’t.

Doing this isn’t too hard: When calculating a new FOV, if a location is visible but wasn’t visible on the previous calculation, store its coordinates in a list; then, when rendering the map, fade in the cells at those coordinates.

At first the fade-in code wasn’t working, so as part of my tests I ran this debugging mode that showed FOV changes in red. It looks kinda cool so I’ll just show that here :D


FOV record debugging visualization.

After confirming that FOV changes were being properly recorded, it was just a matter of tweaking the fade formula to actually render those changes dynamically.

Specifically, when each location is stored by the FOV algorithm it must also store the time when that particular change took place, and while rendering the engine uses the time elapsed since that point to calculate the amount of fade, which in this case is not actually a simple linear fade in from black to the target color. Instead it uses a 400-millisecond linear interpolation along a sine curve from the RGB color (0,48,0) to the target color. (0,48,0) was chosen to approximate the dark green colors used to display known areas outside FOV, to give a smoother transition from outside to inside FOV. Each cell’s record is removed after its 400 millisecond timer has expired.


Fade-in FOV updating in action (tiles mode).


Fade-in FOV updating in action (ASCII mode).

400 milliseconds isn’t very long, but it must be responsive so that fast-moving players can clearly see what’s ahead. Besides, the best secondary animation effects are subtle--in my own work I most often use fade timers in the 200-400ms range.

Performance-wise this is another step slower than the instant update, but it’s not like we’re updating a ton of units here, so it shouldn’t be an issue.

The biggest issue I did run into, and one I initially thought might keep me from enabling this feature, was how to reconcile the differences between revealing unknown areas compared to previously known areas. Unknown areas are black, and previously known areas are, as per the grayscale-with-overlay method, displayed in various shades of green. So in revealing new FOV areas, the ideal linear interpolation would shift from black or the relevant green shade to the new color, but it’s impossible to achieve a perfectly smooth transition without knowing the actual color from each source cell. Unfortunately there would be a lot more code (and processing) involved in figuring that out, so the easiest route here was to pick a single source color that was dark enough to work for black-to-light transitions, and also compatible with the various shades of possible green from known areas.

Before coming to that conclusion, in the search for a perfect transition I experimented with another alternative: using a static uniform color for everything outside FOV. As described earlier, however, failing to account for relative brightness of individual objects is a a pretty poor way to handle non-FOV display, being difficult to parse.

So, back to the chosen color, (0,48,0). Using a static color to transition from a variable source causes a bit of flicker at the FOV edges depending on what color the walls are, most noticeable while racing down a narrow corridor where the majority of your FOV is walls.

And with that we have the final results of our new FOV updating features: See explosions in all their glory!


Instant FOV updating with fade-in on explosive removal of terrain.

I think I might prefer the Instant method for its traditional feel and instant feedback, though technically the coloration only applies to the map itself, and not animations nor the most important feedback mechanisms like labels and indicators--those still appear all the same regardless of the fade-in effect. Either way, for now I’m setting the game’s default to Fade In, because it’s “better.” What do you think?

Posted in Design | Tagged , , , , , , | Leave a comment

Generating and Populating Caves

Before this point, the vast majority of Cogmind maps have fallen under the room-and-corridor style generation. The wide range of adjustable parameters, when combined with a variety of themed content (and prefabs!), give that one style plenty of potential to create a unique feel and gameplay for different areas of the world.

That said, roguelikes which combine multiple disparate map generators can do an even better job of presenting the player with new challenges. Check out this compilation featuring some of the map types found in Dungeon Crawl: Stone Soup:


DCSS map generation variety--click for full size, and see here for some descriptions.


With Cogmind, setting, lore, and atmosphere are important to consider alongside pure gameplay variety, so maps are designed to meet multiple goals in those respects, somewhat reducing the possibility for radical deviations. Aside from the 100% machine-built parts of the world, however, there is room for the more natural areas found in the planet’s interior: caves.

Of course, caves bring with them a set of problems different from the original map generator and its associated algorithms. Fortunately the caves also have a very different meaning in terms of lore and gameplay, and lack the “living ecosystem” found in the core areas of the world, so there’s no need to migrate many of those existing systems to fit a new architecture. (Besides, doing so would also lessen the impact of using a completely different map generator in the first place!) Instead, caves are all found in branches, a concept described in the Layout section of this article, and these branches have a different composition and purpose you can read about over there if not already familiar.

For this article I won’t be going into descriptions of content (so it’s mostly spoiler free); we’ll instead be looking at some of the design and technical considerations accounted for with cave generation.

Generating Caves

Regarding the method used to generate caves, I’ve already given an introduction to the randomized cellular automata algorithm. There’s plenty of background information that I won’t repeat here, though at the time parameters were not yet set for inclusion in the world (those were demos created in the mapgen test program), so it’s worth taking a peek at what the cave layouts really look like in game now.

Firstly, know that since release last year there has been one variation of the cave generator at work, in the form of mines:


A fully-revealed mine.

These are basically small square-shaped areas containing sparser caves interspersed by what appear to be dug out rooms linked by tunnels.

The real cave systems are significantly larger, and because individual caves have more room to expand, they’re more likely to generate a few extra nooks and crannies.


A fully-revealed cave map, without content. Overlay insets show major loops and flow paths.

For reference, I drew overlays demonstrating the relatively linear overarching flow structure (despite being caves) here, and the primary loops here. There are definitely loops available for tactical purposes, but generally fewer than you’ll find in other areas of the world--this could have a strong impact on strategy for some players. Overall the linearity-with-loops design should work together to keep the map from being too linear, while still doing away with boring backtracking. (And of course the player is free to create their own loops by destroying walls where convenient :P)

Again, if you want to read more about the principles of connectivity, looping, and guided generation as they apply to the algorithm, check out the introductory article. Here I just wanted to show an example of what a real cave layout looks like now that they’re in the game. It’s still possible the parameters will be further tweaked depending on how content generation goes, which is a work in progress. You’ll also see below that the layout itself may in some cases be altered by content.

Populating Caves

While the system behind procedural cave layouts themselves was worked out back in 2014, the first stage of content generation wasn’t added until last year.

This was in the form of “encounters,” wherein caves (analogous to rooms in room-and-corridor maps) each have their own content pulled from a pool of available encounters that themselves generally fall into one of four categories: fluff, rewards, risk vs. reward, and danger. The encounter system was described in more detail towards the end of the map composition post.

As a reminder, here’s what a potential encounter distribution scenario might look like in a mine:


A mine with distributed encounter types marked with their associated category color.

So this is a feature which has been in use to populate other branches, and also even cave maps in the form of mines. But mines are relatively small and contain a fairly narrow selection of simple encounters, thus they didn’t really need support for prefabs which allow for a wider range of unique (but still dynamic) content to be added fairly easily. Truthfully, there wasn’t enough time to implement cave prefabs before launch in 2015, either, so that also played a role--mines use a bit of hardcoding instead.

Full-size caves, of which there are also many more than mines, will need better encounters. And certainly more encounters. These are areas that prefabs can really help since hardcoding content is a slow error-prone process, and scripting support for encounters has expanded greatly since first described, while adding multiple features for prefab content in other branches.

So the last thing really needed here is prefab support in caves. Well, caves have had prefab support, just not encounter prefab support--the more important and versatile kind.

There are actually two methods of adding prefabs to Cogmind maps. One is integrating them into the cave generator itself, which isn’t even a part of the game engine (i.e. it can be run without Cogmind at all), and by nature this one will be somewhat limited in what it can do because it places prefabs before the caves are even generated. Thus these prefabs would be meant to serve a central role on the map, e.g. a huge and defining static area, or special entrances/exits. Relying too heavily on this type of prefab will result in maps becoming too repetitive and familiar over time, as it’s not a very flexible system (at least not without a ton of extra work for each new map). It’s more efficient to add a majority of cave prefabs through method #2, the encounter system.

The problem: How do you integrate static prefabs with a cave map that’s already been generated?

Prefabs themselves have a defined shape, one that we obviously can’t change to fit the surroundings, so the only option is to terraform the caves as necessary to accept a prefab. This must be done without having a negative impact on cave connectivity, and also in a way that looks good, and doesn’t cause some other manner of chaos :P.

I’ve currently added two methods for prefab-cave integration. And hopefully two will be enough (hardcoded encounters pick up the slack in terms of highly unique content, or those that are more free-form and able to fit into any cave without disturbing its natural structure).

Centered Prefabs

The most easily implemented cave prefab is very intrusive, simply dropped onto the geometric center of its parent cave. (Remember that here I’m referring to “cave” as a single cave-room, just one of many caves that make up a single cave system map.) Here’s an example of a prefab outpost plopped right into a rather large cave:


Geometric centering of an outpost in parent cave.

Notice that the outpost’s territory completely overwrites both the closed and open areas that were under it, and includes an open buffer zone around it as well. Intrusive, but it gets the job done here.

I chose to center a prefab over the geometric center of its cave (meaning a position that gravitates towards that largest open areas of that cave) in case the parent cave has a big open fat area to one end and a long protrusion headed off in the opposite direction, in which case its geometric center could be some distance from its simple coordinate center. In such a situation, using the latter would be more likely to break one of the few rules governing this type of prefab placement: Prefabs are allowed to overlap any earth and the parent cave itself, but not other caves.

One of the current limitations on centered prefab design is that they must be rectangular, though I might remove that restriction later if it becomes annoying at some point. Organic/rounded centered prefabs have their thematic uses, especially in caves, though technically this can be faked under the current system by rounding corners in the prefab and simply leaving a little more open space at the corners where it integrates with the map.

Here I should remind readers that prefabs are not static (unless I want them to be :P)--most come in variable layouts, and also have randomized content, so there’s plenty of variety even for a single encounter type. This leads to unexpected roguelike fun for new players (“hey I remember this place from last time, there’s a helpful friendly robot inside--OMG WHAT’S SHOOTING ME”) while also being designed to provide strategic challenges for experience players (“there is definitely useful loot here and I can take the usual guards, but is it worth the small chance of possibly being ambushed by a larger force?”).

As mentioned a few times before with regard to world structure, branches are meant to be the less predictable areas of the world, compared to the main complex where there are plenty of procedural-driven systems at work, but they’re relatively consistent and predictable for the experienced player. This offers two different types of major areas you can bounce back and forth between as necessary (or desired). In terms of design, prefabs are the key to “custom” content available in branches, so it’s important to get them right :)

Embedded Prefabs

This one was more complicated.

There needed to be a way to add prefab areas that are not nearly as intrusive, for the more common cave-like situation where you have interesting encounters off the main path in some side area, or at least not right smack in the middle of a cave. This meant there needed to be a way to excavate areas for prefabs off the edges of existing caves. And that meant there needed to be space to do that excavating, and a way to efficiently locate that space…

As you can see in the full-size cave image further above, caves are fairly tightly packed in. So my first thought, in order to vastly increase the amount of earth (diggable area) between caves, was to do cave generation in two phases: a first phase uses a cellular automata-like process to define cave-shaped blobs which are marked off limits to digging during the regular mapgen process, then do the normal process, which would automatically avoid the natural “pockets of earth” formed from phase one. These pockets would then be available for latter digging out by encounters for their prefabs. As promising as it sounds, the more useful this approach (i.e. more pockets), the more it would have a broad impact on the caves as a whole, lengthening corridors and increasing the amount of space between individual caves, regardless of whether there were any prefabs inserted. This solution felt a bit too extreme.

There’s a much easier alternative that doesn’t compromise the integrity of the existing cave designs: Simply expand the diggable area around all the outer edges of the map so at least those are generally valid directions. Now there’s plenty of area to dig! Then comes the next step: Where exactly do we start digging? This is really easy to do by eye--we can immediately see ideal places to dig out little areas, but in the code caves are just numbered areas with a list of their internal coordinates. So at this point it was a matter of figuring out the smallest set of rules that could search for applicable locations and satisfy all conditions and potential layouts when trying to excavate areas for prefabs.


I spent two hours figuring out a workable set of rules.

The final rules are very brute force, but they work so let’s go with them :D


Steps to embed a prefab in a cave wall.

  1. Select a random prefab for a given encounter, and rotate it to face a random cardinal direction.
  2. Pick a random open cell in the cave, intended to be one front corner of the prefab’s location. Then based on the length of the front face of the prefab, locate where its opposite corner will be. If the second corner is not inside the cave, keep trying with different points.
  3. Measure the distance along the imaginary sides of the prefab until it hits a wall.
  4. Every prefab has a manually set “maxProtrusion” value, a restriction on the amount its depth is allowed to protrude into its parent cave. If the distance measured on either side exceeds the maxProtrusion value, push the corners back towards the wall until both distances are within that value. (If there is no distance at which the protrusion value can be obeyed on both sides, which might happen with a combination of small protrusion threshold and highly uneven/diagonal cave edges, go back to #2.)
  5. Check the validity of the prefab’s target area: The “outer rectangle” cannot contain any stairs (since it would overwrite them) and the “inner rectangle” can only be earth--not even open cells from the same cave are allowed, since it would allow unexpected/unpredictable alternative entrances to the prefab area.
  6. Also ensure there is at least a 1-cell-thick wall of earth around the sides and back of the inner rectangle (i.e. not immediately touching some other open cave or prefab area), for the same reason indicated in #5.
  7. Place the prefab on the map! Then convert to wall any earth cells around the outer edge that are adjacent to open prefab space.
  8. Add objects as per the prefab’s definition, like… a terminal that allows you to access a door and collect a cache of nice launchers someone so considerately left here :D

If no valid area was found in the current cave within a certain threshold of tries, try with other random prefabs for that encounter, and if that still doesn’t work, start over with another cave. (Encounters are chosen first, so the goal is to find a valid place for that encounter.)

Unlike centered prefabs, embedded prefabs can be non-rectangular since their sides and back edge are guaranteed to be against earth, meaning they can have a built-in cave-like appearance as in the example above.

The above diagrams were drawn in REXPaint. Here’s a shot of a real prefab generated in game:


Sample embedded prefab in game.

Time to make some more prefabs!

Posted in Design | Tagged , , , , , , | Leave a comment

Dialogue UI

I recently added the third and final dialogue-related UI feature to Cogmind, so it’s time for a review of what all these different ways of displaying who says what are doing in the game :D

Message Log

This is the obvious one--any NPC dialogue is added to the message log for future reference if necessary, especially useful if you’re told something that might be important, like a unique terminal access code you didn’t bother to write down :).

Like most other uses of the message log, however, it plays a secondary role with regard to dialogue, while the primary method of display depends on whether the speaker is a minor or major NPC.


Sample dialogue text in the message log.

I’ll write more about message log itself and its design another time.

Transmission Window

Major NPCs open a modal dialogue box when they talk to you, reflecting their importance to the story. They also get their own window because they’re likely to have a lot more to say at once than the average NPC.


Listening to Revision 17 when you first awaken.

Players already familiar with a given conversation can just ESC out of it.

One significant advantage of putting this dialogue in its own window, besides modality, is tighter control over pacing. By dividing a longer conversation into segments on separate pages rather than having it all suddenly visible in the log, each page switch can represent a pause in speech which is reflected directly in the player’s UI experience, even just for the moment it takes to advance the conversation, which can be useful for conveying feeling beyond the words alone. Revision 17′s initial dialogue includes an example of this technique (and a glaringly explicit one at that):

“If I know the one behind it this can only be bad. And trust me, I know that one all too well…”
“I give you a hook like that and get nothing? You know, you’re pretty boring to talk to.”

On-Map Dialogue

This is the newest one, showing dialogue from minor NPCs, and might even be considered redundant since the message log has always shown this same content, but there are good reasons for wanting these to appear on the map as well.

Cogmind’s message log is afforded relatively little space, and the overall interface design intentionally de-emphasizes the log by providing the same useful information elsewhere in the interface via more convenient, accessible, and relevant means. But even a minor NPC might tell you something valuable or interesting. I know I tend to ignore the log for 99% of play time, so when something does come along there’s a chance I’ll miss it. Thus the non-log parts of the UI are responsible for re-emphasizing anything that should be known, dialogue included (which is kind of a special case, anyway, since there’s only so much of it).

My original concept for on-map dialogue had a secondary goal as well--use a larger font to make the dialogue more readable than when squished into the log, but the map font is a square font and therefore not exactly more readable despite being technically larger, so that approach was scrapped. (Later testing showed that wider space available for dialogue displayed over the map was already somewhat better for readability compared to the log window, anyway.) At least the fact that these lines appear on the map rather than only alongside mundane messages in the log achieves the primary goal of emphasizing them.

There are other unique advantages to map-based dialogue, but before we go there let’s look at the first implementation:


First fully-implemented concept for on-map dialogue (click for full size).

The first test looked pretty good. You’ll see a quick line flash between the speaker and the new line, to indicate their position, and the spoken dialogue flashes in. New lines are added to the bottom, since reading downward is more natural, and it looks better when old lines fade upward into the map. (These lines are not modal, and will simply fade away with time.)

This first test also took into account the need to differentiate between dialogue from different speakers (or wrapped lines from a single statement), by alternating between slightly different hues.

There were still several subtle ways to improve on the animation, so I tweaked the short-lived speaker position indicator line to appear smoother, and added a very fast swipe to each new dialogue line, originating from where it’s connected from the initial indicator line. The latter addition makes it a little more obvious which and how many dialogue lines are new, plus it just looks cooler :P


Final appearance of on-map dialogue (click for full size).

More colors are also helpful--the color of on-map dialogue messages reflects the relationship of the speaker with Cogmind, making them more informative than the log (which can’t effectively do the same because there are already other uses for those colors there!). As one would expect, green dialogue is from friendlies, gray from neutrals, and red from hostiles. (Note that the swipe speed also had to be tested on wider map view settings, which is what the speed values are based on, since there’s more distance to cover under those circumstances.)


Dialogue appearance mockup work done in REXPaint prior to implementation.

As you can see in that mockup, there’s also some blue in there. After finishing the dialogue feature I couldn’t resist giving “scene descriptions” the same treatment. Sometimes the log will show a cyan description of a unique encounter or event (these are often accompanied by dialogue, shown in sky blue), and these, too, will now appear over the map.


Sample scene description.

Future posts will look at the role of NPCs and story in Cogmind and roguelikes, though I might not get to those in the near term, as those parts of the game are still taking shape. (I’ll also have to tread carefully around those topics, because I don’t want to spoil anything!)

Posted in GUI | Tagged , , | 2 Responses

Designing Cogmind’s World Map

Cogmind began as a 7DRL based around a simple fight (or flight!) from your subterranean starting location directly to the surface. As the new Cogmind works its way towards 1.0, a big part of its departure from those humble origins is the significantly expanded world. (For an initial discussion about the layout of the world, see this post from last year.)

As that world increases in size, the chances of feeling lost without a map increase along with it.

This isn’t such a huge deal for current alpha players, as new areas are added two or three at a time so there’s an opportunity to gradually expand one’s knowledge, but I can imagine that future players joining at 1.0 will be overwhelmed by the dozens of different locations, and it will overall feel more maze-like.

The fact that exits will only ever take you upwards towards the surface or sideways into a branch, and you aren’t allowed to backtrack, means that theoretically you can just look for exits and will eventually reach the surface one way or another. But there are some advantages to adding a map that provides an overview of the route you’re taking throughout that process.

  • A map enables players to form a better mental picture of how areas are connected in the world, and which areas are branches vs. non-branches. This will help gain an early understanding of the direct relationship between ascension and evolution.
  • Even more importantly, once the full-sized world is realized, players can take advantage of new mechanics to learn approximately where certain locations are to better plan out a route. Right now most players tend to wander around and allow their route to be determined mostly by what exits they happen to find. With experience (and especially later on when there are even more routes to choose from) players will in some cases attempt to seek out certain areas when possible, for whatever benefits they might provide for that player’s style or strategy.
  • Similarly, players can also get a better grasp on whether or not they’ve passed the depths in which a given branch might be located (even without access to explicitly obtained knowledge).

As of now this map has been fully implemented, and will be coming to Alpha 7. See it in action:


Cogmind’s animated world map in action. (As usual, for this and all other images click to view at full size.)

Beyond this point, this post is mostly about examining the process behind the creation of the world map and its functionality, followed by some discussion of related mechanics.

World Map Design

A majority of the world map design process was carried out in REXPaint via mockups, which saved a huge amount of time that would’ve been wasted testing out variations that ultimately wouldn’t satisfy all necessary conditions. Below you can see how and why the design evolved over time.


First world map concept.

In April last year I put this together mostly as a quick demonstration of what a theoretical world map might look like, as a part of the world layout discussion, and note here that “world map” at this point really meant nothing more than the route you took through the world on a particular run. In that sense it’s more of a route map.

I really liked the aesthetics of that one, but on revisiting it for a proper review it was simply too wide for the area in which it would be placed--the standard map view. One option would be to block out the entire UI and replace it with the world map when opened, but this would ruin the immersion created by a deliberately dense and subdivided multi-part UI, especially in cases where the world is mostly unexplored and therefore the world map/route itself doesn’t take up much space. Another alternative would be to use the narrower text grid for the design, but because the world map appears over the local map view and is just another type of map, I wanted it to match the local map font’s own square ratio.

So the first aim was to reduce the map width, where the easiest solution would be to drop the three-letter abbreviation for representing each map, replacing it with a single letter instead.


Reduced-width world map concept.

Then there was a more fundamental problem with this particular design: The style is not very flexible. This becomes apparent when considering Waste and Garrison. These special areas may be entered multiple times from any number of locations and do have an impact on your route, but don’t really count as maps in the normal sense, characteristics that should be reflected on the world map.

To this end I reexamined the first two concepts for ways to incorporate these “maps between maps.”


Concept 2 excerpt with Waste/Garrison examples.

Unfortunately without additional colors beyond each map-associated color, this design doesn’t distinguish between situations like entering both Waste and a Garrison on the same floor. Some amount of modification to the shape and or color rules would be necessary.

So I went on to explore an alternative style that could clearly distinguish special maps while still keeping each map within a small area.


Detailed world map concept.

That looks fairly good and provides more information in the same amount of space.

Despite the earlier reduction in width, however, assuming that branches on either side can extend outward by as far as four areas (which happened as of the most recent release and now looks to be what will become the upper limit), even this is not enough to fit within the minimum 50×50 map view--a theoretical route that visited up to four maps outward on both sides would require a width of 61.

Fortunately the new style can more easily be squeezed yet further:


Narrower concept.

This both looks nice and fits better with Cogmind’s “dense data” aesthetic, while also turning each area into a square, tempering the map’s extreme flatness.

It does feel a bit too cramped, though. At a maximum height of 40 (4×10 depths) out of an available 50 rows in the map view, with the world’s 10 depths we have an extra row available for each depth and it will still fit. Perfect.


Finalized world map route style.

Overall, having a world map was planned from the beginning, but it’s taken this long to get one because as a general rule I put off implementation of overarching and inclusive systems (especially those requiring a complex dedicated UI) as long as possible to avoid wasting development time when other contributing elements inevitably change during the iterative process.

In this case, one example would be Waste and Garrison areas, which were not a part of the original design doc (“special maps between maps” were, but weren’t confirmed nor had a specific form until after alpha release and some public playtesting). Another example is the recently-decided limit on the maximum width of branches (4), which naturally had a bearing on the space available for each individual map indicator. And there are also a couple other late developments in terms of world layout that I can’t reveal for spoiler reasons, but they, too, had to be taken into consideration. With regard to the UI as a whole, the world map design also couldn’t be finalized until the main interface’s aspect ratio was itself finalized, as discussed in the previous post.

All in all, game development is all about attempting to identify dependency upon dependency, resolving them in the most logical way to keep everything from falling apart before it’s even complete! :D

But back to the world map… we still haven’t finished it yet!

It’s too empty, too black, and needs some sort of unintrusive background. At first I thought of using a visually altered version of the local map itself as a background, a purely aesthetic approach, but then I decided it should ideally be something functional as well. Why not depth indicators?


Depth indicator concepts.

  1. I started with sepia lines because, you know, you’re underground :P. That works okay on its own, but together with the complete main interface, sepia as a UI element doesn’t really fit (it’s not used that way anywhere else that). Hm, what color to use… I know, green! Okay, it was obvious. Sepia was perhaps my subconscious attempt to use something other than green. But consistency is king, plus green works. Regarding the semi-dotted style, using full lines is too many pixels and attracts extra attention to them, while also unnecessarily stratifying the depths a bit too strongly; a purely dotted line is to weak, harder to follow, and… dotty. A mix of the two feels just right here (though notice the pattern changes at the ends to give them a little more strength there).
  2. I wanted the depth values themselves to stand out so for those I started with white. It turns out that’s far too distracting from the route itself.
  3. The answer, of course, is more green. Just a brighter green in that case, and if you’ll notice I also slightly darkened the meaningless placeholder zeros, included to maintain horizontal alignment regardless of the value.

Final world map concept, showing only route and depth indicators.

All of the above images were taken directly from REXPaint, created before writing any code at all. That made it much easier to implement, since I could see exactly what I wanted it to look like and do beforehand.


The world map is easy to access--for mouse users there’s a new button in the bottom right corner of the main UI that reads “<MAP>”, and both Backspace and F9 open and close the map (mouse users can click anywhere to close it).

Mouse users can hover the cursor over a map location for information; keyboard players can use the movement keys (numpad, arrow keys, vi) or numpad -/+ to cycle through the map. When an area is selected, the box shows its full name, depth, and a list of any other known areas not yet visited at that same depth.


Final world map concept, showing all components. (Two different types of selection indicators are shown.)

The next section talks about what those little letter blocks at the top mean and how you get them. (Actually my young son wandered in while I was working on these mockups and blurted out “letters!”)


As mentioned in the introduction, the “world map” is not purely a representation of what you already know (i.e. the route you’ve taken up to that point); it’s also possible to learn about areas in advance, to get an idea of how the world is organized and therefore maybe adjust your planned route. While you won’t learn precisely how to reach them, knowledge of other areas will at least let you know what depth they’re at (though that’s enough information for more experienced players to be able to locate them sooner or later).

Thus the world map also ties into the mechanics. There are initially two primary ways to find area locations in the world:

  • Encounters with other robots might reveal a specific area during dialogue.
  • Recycling Unit systems are now susceptible to a new type of brute force hack, one that outright destroys the system in an attempt to simultaneously override its defenses and tunnel through the recycling network to find what other areas it’s hooked up to. This is more likely to discover areas closer to the Recycling Unit in question.

Once you learn of an area, its block will appear at the appropriate depth, and you can hover over it all the same to see the basic info for it and other areas at the same depth. Any intermediate depths about which nothing is known are represented by dark question marks as placeholders.

There will likely be one or more additional methods to obtain area data and build a picture of the world. This will become more important soon as the current three branches expands to four or five in the next release or two!

A Note about Structure

While you are capable of learning about areas in advance, and to enable that feature the layout of the entire world is determined when it’s first created, that layout is generated anew procedurally with each run. How branches are connected to the main complex, and to one another, follows a set of rules that you can gradually learn as you play more runs, and as stated the world map view is a tool to help in that regard, but there is no persistence between runs.

For example, you’ll quickly learn that the first/lowest three areas in the main complex are always Materials, and that there are always entrances to the Mines located within each of the first two Materials areas. Those relationships are fairly obvious, but later some of the more interesting outlying areas may not be so easily learned (even if only because you’ll visit them less often), so having a world map handy will be useful in clearing up more obscure relationships.

Your complete route is also now recorded in the score sheet produced at the end of a run.

Posted in GUI | Tagged , , , | 6 Responses

An Alternative UI?

Normally when I publish a new article, the focus is on explaining the results of some new feature/mechanic/design. Today’s post is a little different because it’s about an important feature that has not yet been implemented, nor have I come to a decision on how best to handle it.

I’m using this post as a way to lay out all the facts and considerations before making a decision, while at the same time giving anyone else who’d like to provide input an opportunity to do so.

So what precipitated this post?

For some players the Cogmind UI is too dense given the size of their screen. I prefer playing in a small 720p window myself, but when making a game for wider consumption it should be as accessible as possible for as many different types of players as possible, and some players find that their setup results in objects/words that are too small to parse/read clearly--they “just want bigger fonts.”

Unfortunately it’s not as simple as that.

Cogmind already comes with many fonts, including very large ones, but there is an upper limit to what can be used in combination with a given screen simply because the current UI requires a minimum of 60 rows to display all its information.

Note that I used the term “screen” here, and not “resolution.” The latter is not an issue, since Cogmind’s font system will allow it to scale up to any resolution with pixel-perfect crispness (right now I’ve only included full-size font support up to 2160p/4K, but more can easily be added on request).

Thus the question we’re addressing here is one of physical screen size--regardless of resolution or pixel density, displaying 60 rows of information means dividing that physical screen height by 60. The only approach, aside from recommending play on a desktop or large-screened laptop, is to offer a different UI layout that reduces the amount of information available at any given time, and apply this across the entirety of the interface. Oh my.

History behind Cogmind’s UI

How did we get here in the first place? The current UI’s history goes back surprisingly far, to even before Cogmind’s conception…

In 2011, I began working on X@COM, a tactical squad game based on the original UFO Defense. Naturally one of the first things that needs to be decided with a game represented via an emulated terminal is the dimensions of the grid. I had spent many years developing games in real terminals before that point, so it felt natural to go with the standard terminal width of 80 characters. As for height, the largest UFO Defense maps play out in a 60×60 grid, so it looked pretty perfect to fit that into the standard width and leave a 20×60 area for the UI sidebar.


A shot of the early X@COM UI (it was later changed, and there are other windows). (Click for full size.)

The following year I decided to participate in 7DRLC2012, and I certainly wasn’t going to start from scratch, so I basically gutted the X@COM source to use as a foundation in creating Cogmind 7DRL. The latter ended up being designed around an 80×60 terminal, purely because that’s what X@COM was using at the time.


Cogmind 7DRL from 2012, which has multiple font options as well. Coming from X@COM I did reduce the map view to 50×50, since maps are much larger than that, anyway, and we needed the space for a log plus more info in the sidebar. (Click for full size.)

So if you weren’t already aware, now you know that Cogmind originated as a game jam game that itself splintered off a UFO Defense fan game. The early decisions definitely had an influence on how the game developed, because at no point in all this did I start over from scratch.

When I decided to pick up Cogmind again in 2013 to turn it into a full game, I made a short-lived attempt to start over before deciding it was a waste to throw away all that prior work (this was discussed on the blog a couple years ago).

In terms of UI layout, for Cogmind the 60-row minimum was just enough to fit all the information I wanted to include in the 7DRL, and font size was also less of an issue then because all characters were square, and therefore could use twice as much horizontal space as in the new version, making them easier to read even when small.

I was really excited to transition from the 7DRL to the modern version capable of narrow fonts, effectively giving me a 160×60 terminal where non-map text is concerned, because it meant I could fit in all the extra information I needed to make the UI as useful as possible with little window switching. (I hate square fonts, anyway, so I was happy to see them go.)

And there you have it, the origin of Cogmind’s default 4:3 aspect ratio, which is somewhat out of place in today’s world of HD resolutions. Of course I’ve made the UI dynamically expandable, allowing the logs to fill as much space as possible, though this can often result in a lot of black space up top since log messages were meant to be short and the contents of those windows were designed to fit well within their narrower default width. (See the end of this post for diagrams/explanation regarding UI expansion.)

Thus we finally come to the current version:


Cogmind’s current primary UI, as it appears in the most commonly used resolution, 1920×1080 (click for full size). Currently the second most commonly used resolution is 1366×768.

I’ve also put together a new reference page where you can preview what Cogmind looks like at different resolutions using different fonts, especially useful for those prospective players who aren’t sure whether Cogmind’s UI will be too dense for their particular screen of choice.

Why an Alternative?

Now that we have our background and recognize the current state of affairs, the first important question to look at is why it’s even necessary to explore an alternative. There are two main parts to this…

The first is a question of marketability.

These days, Let’s Plays on YouTube and Twitch make up one of the most vital marketing channels for indie games. (It’s a fairly obvious trend; see this report for one summary with data to back it up.) If a game isn’t easy to stream/record, or doesn’t look so good in that environment, it’s less likely to be picked up by as many channels. A UI crammed with fine details doesn’t hold up against compression very well, and won’t always look great unless viewers are willing and able to watch in a large window at high quality. When I stream, I somewhat cheat on this by using my 1200p screen to stream at 1080p, letting the lower 120 pixels be cut off since that area’s not too important for viewers, anyway (and therefore I can stream using a larger font).

So a very dense UI is non-ideal for recording or streaming, and while Cogmind has already received fairly good video coverage since launch (from smaller channels!), reception and exposure would no doubt increase with an option to enlarge the UI elements.

Interestingly, I did recently encounter an unexpected marketing-related benefit from Cogmind’s UI density when it appeared in a 2015 GotY list alongside other games like Undertale, Helldivers, and Everybody’s Gone to the Rapture, where the editors couldn’t do the game justice with a smaller image like they could with the other games, so they just gave Cogmind a much bigger image :P.

The second, more important question is one of individual accessibility.

As mentioned before there are plenty of players on laptops rather than desktops (the second most frequently used resolution is 1366×768, a common netbook resolution) as well as older players and others with poor eyesight that need to be considered.

And again, it’s not so much a question of resolution, but the fact that physical screen sizes are shrinking compared to years past (even compared to when Cogmind was first developed).

I’ve been contacted about this literally dozens of times since Alpha 1 released. The number is only a small portion of players overall, though there is a common rule that for every person who makes a statement, unless it’s something completely off the wall then you can expect there are X more thinking the same thing who just didn’t speak up about it. That and alpha players are more forgiving. Add these X’s up and it’s no longer such a tiny portion of players.

My first response was to release alternative fonts, which was enough to satisfy some of these players. However, that only works for those for whom the default text was perhaps just a tad too small or,  more accurately, was not as readable due to the stylization in combination with its small size on some screens.

We need to examine the feasibility of a more heavy-handed approach.

Roadblocks & Solutions

If only the  solution were easy! But no, there are some major roadblocks in the way here.

Anyone who’s followed the blog for a while, or played Cogmind before, will know that a lot of attention has been given to the UI design, and it’s unfortunate that the ideal solution here--reduce the amount of information available at any given time, would undermine years of careful thought and effort.

Showing less information at once breaks one of the fundamental rules in the design, that as much vital information and interactive elements as possible be accessible at once, without additional windows or scrolling. The UI has been quite successful* at this, though it ends up requiring a large grid to achieve it, leading to the topic of this post. (*One notable exception is the meta strategy some alpha players are using with large inventories, which require excessive scrolling and will likely prompt me to add a new inventory management mode to alleviate that down the road and fall in line with the usability of the rest of the UI.)

So at the root of the problem, having started out with 80×60 terminal means that each UI element’s size, relative location, contents, interactions, everything even including game mechanics have been influenced by that decision. It’s a delicate house of cards in which any piece that’s moved or resized will trigger a ripple effect that essentially lowers the quality of the entire game (unless it’s redesigned from the botto--NOPE :P). If I’d taken this issue into consideration from the start, Cogmind would be a different experience!

However, here I must admit that as part of my vision for the game, I was intentionally cramming the interface with as much data as possible. It does a very good job of fulfilling the goal of creating a sometimes overwhelmingly detailed environment that really gives you the feeling that “You are the Cogmind” :D. In that way it’s been a success, just not a success that transfers well to all devices…

Let’s begin investigating specifics!

(Images for discussion below will use Cogmind’s “native” 720p mode, all of which can be opened to see them in their crisper full-size form.)

First of all, note that because Cogmind was designed to a 4:3 aspect ratio, our limiting factor is height--width is never an issue, what we need to do is reduce the number of rows of data in the interface. How many rows we can afford to lose, and what impact does that have on the rest of the UI?

Starting with the main interface, let’s assume we’re redesigning it 1) for a 16:9 layout and 2) to allow for an increase in relative font size across all resolutions. My first thought was to move the inventory from where it’s hanging out at the bottom, since that is the biggest potentially movable chunk…


Concept: Moving the inventory to the top.

Doing so would give us back 14 rows! Sure enough, such a change would allow the current 1366×768 players to upgrade from a size 12 font to size 16, and 1920x1080p players to move from size 18 to size 22. However, such a radical change leads to multiple problems on the main UI alone…

  • It would reduce the amount of visible inventory from 10 items to 6 in order to fit the top area.
  • It drops the viewable map height from 50 to 36, meaning that with the player at the center only 18 spaces are visible to the north/south, while it’s technically possible to see out to 24 spaces according to the mechanics (not to mention all the other mechanics that work beyond 18 cells and are normally within view).
  • The current inventory position relative to the parts list above it is actually quite important. Conceptually it’s a smaller area below (= less important than) the list of attached parts, and to use something you move it upwards (= raise its importance). (Yes, this was part of the original UI concept, and these are the kinds of things I think about when working with a GUI--many of my ideas come from prior training in linguistics and conceptual metaphors.) Moving the inventory away also loses its parallelism with the parts, both of which share the same info visualization modes to allow for more direct comparison of values like integrity or other qualities.
  • A lot of the game is spent moving items between the parts and inventory windows, and further separating them would slow that process, especially for mouse players.
  • If the inventory were to become a part of the top-center multi-console, as it’s the most commonly used window the player wouldn’t be as free to choose one of the other optional windows as desired (the area was intended for situational secondary windows).

So, um, yeah, that’s not gonna work.

Before we continue experimenting with the main UI, let’s look at the effect of changing the console height on other windows. We do have the status window, item info, hacking interface, and the help and many game menu pages to think about. These, too, were naturally all designed with the 60-row limit in mind, along with the desire to have as much information available as possible without scrolling or forcing separate windows.


Sample status and data windows, for reference.

Without removing any existing data, these two windows have about 3-4 lines to spare. Ideally we’d also want to leave an empty row at the bottom because it looks better. Given these examples I can see ways to condense the amount of data to free up a total of 5-6 lines without any serious sacrifices in content or quality. Technically there are a few items that manage to fill their entire data window, so those would need to be dealt with as well, but they’re in the minority. (No scrolling allowed here!)

The hacking interface has plenty of room and flexibility, so no need to examine that.

As for game menu pages, most of them are dynamic and don’t required their full height--basic commands, manual, game, news. The options and credits pages each have about 8-10 rows to spare at the bottom. The art gallery would need a slight redesign to be able to free up at least 8-10 rows, but that one’s not too difficult. The only one that would need a bit more work is the advanced commands page, which is already packed in its current form :/


The advanced commands help, for reference.

Looking at the numbers overall, the scale of the 14-row inventory move described earlier would also be an impossibility where many other windows are concerned. Something lesser might be feasible, though.

Before we continue, here it’s worth bringing up a common misconception among players just starting out: It feels like there’s plenty of empty space in the HUD, so why not just allow the contents to be larger? Or, for example, why not shorten the parts list by the necessary amount since that area’s not being used?

Anyone who’s played longer knows that, as you can see in the sample complete UI image shown earlier, that list eventually gets filled up with parts--26 of them from A to Z. There’s actually not a single row to spare, and seeing that list in its entirety is extremely important, i.e. not something that can be sacrificed to scrollability. That number of parts was another mechanic that was decided early on but could’ve easily gone another way had I decided it was necessary to have a lower part limit for the purpose of shrinking the UI. Now the entire game is balanced around it!

So let’s take another look at the main UI for different candidates from which we can realistically remove/relocate some rows. Within the inventory, there are the two item-name scroll buttons at the top/bottom, empty if there is no previous/next item. We could theoretically get rid of those and enable scrolling via another means.


Concept: Slightly condensed inventory.

That doesn’t really work, though, since it would ruin the consistency of the aesthetics across most of the other scrolling windows, most of which are laid out and interacted with in the same manner (plus it looks bad). More to the point, only removing two rows isn’t going to make a meaningful enough difference to allow for font size increases.

A better candidate for adjustment is the HUD area above the Parts window, specifically the Scan and Volley windows, which don’t have to be at that particular location. In fact, both could be redesigned and provided as info over the map or other windows.

The Scan window’s info is actually almost entirely available through other means as is (it’s a legacy 7DRL feature left as redundant info even after adding the dynamic map info system we have now). The Volley info is only really used in firing mode, and could be represented on the map, or together with weapons when preparing to fire--it only needs to be shown in that mode.


Concept: Volley data strip (containing hypothetical data just for demonstration).

Unfortunately the 4 rows this saves aren’t quite enough--it turns out we need to reclaim at least 6 rows in order to give our most common resolutions the next font size up (1366×768 would increase from 12 to 14, and 1920×1080 from 18 to 20). So we’ll still need two rows from elsewhere…

The top HUD area has two empty lines, though that’s a bit of intentional black space to keep things from getting overly cramped. Even more important, the HUD is shaped as it is because the corner intersection of the top-side windows and sidebar forms a makeshift rectangular area that doesn’t need a border of its own. Shifting the sidebar upward looks bad.


Concept: Shifting the HUD and condensing the upper block.

Well, now that I draw it out, it doesn’t look quite so bad. Yay for mockups. I prefer the bi-directional diagonally mirrored look, though the zig-zag intersection is somewhat interesting. The corner layout’s density is a bit over-the-top, and it looks kind crushed and less important considering it’s actually your most vital info…

But we did free up 6 rows :P.

There would be quite a few other consequences of this and changes mentioned previously, in terms of little UI feedback details and interactivity, but I’ve been focusing on the big picture here. To point out some of the other problems on the main UI alone, the cascade of changes would also require: moving the volley visualization toggle, a new home for the hidden Scan buttons, some new way of providing the names of machines, another method of showing the item data summary… All of these elements fit and work nicely where they are now (while also making sense!); I think the overall quality of the UI suffers by shuffling these things around, since they’ve already been optimized, after all.


In terms of difficulty, providing an alternative UI doesn’t seem quite as bad as I expected, but at the same time the benefits are not as great--it only enables one step up in font size.

Converting the base terminal area from 80×60 to 80×54 does bring it almost half-way from the 4:3 (1.25:1) aspect ratio we started with to a native 16:9 (1.77:1) better compatible with today’s screens.

That said, under the new system non-16:9 screens (the most common one being 1280×1024, approximately 5.7% of Steam users) would still not benefit from the changes, remaining at the same font size. On the technical side, the advantage of a 1.25:1 ratio is that you know you can always expand it horizontally to fit whatever screen space is available, while it’s not so straightforward with a terminal with an odd 1.48:1 ratio =p.

On the plus side, even a one-step font increase will slightly narrow the top-side windows back towards their intended/designed width, which has always been stretched too far for these 16:9 screens.

Mapwise, shaving 3 cells (6/2) off the sight range to the north and south is okay, though it would mean we’d probably need to remove the best tier of sight range-enhancing items, simply so they’re not annoying by frequently spotting hostiles outside your map view.
(Note: As is the case now, players can always opt to use a smaller font to see more of the map at once.)

Timewise, implementation could require devoting the majority of an entire major version release to this one feature. That’s about 3-4 weeks.

Financially I believe the effort could probably still pay for itself down the road by expanding the number of potential players and somewhat mitigating the number of complaints. (I’d be far more certain of this if we could increase the font step by two instead of one, but that appears out of the question.) That said, money has always been the lesser of my concerns, with the priority instead on making an awesome game. Cogmind was, after all, designed from the ground up with these particular UI dimensions, layout, and content in mind, which has in turn heavily impacted the mechanics.

Technically, one of the options here, and how I originally approached the issue, would be to make the alternative UI an optional “special mode,” i.e. not the default appearance. But maintaining two such distinct modes is complicated, and would continue to be a drag on future development. Fortunately the 6-row proposal reached above is not a significant divergence from the original UI, thus there’s a chance it could become the UI layout.

In summary, it’s doable, but do we want to do it?


If the necessary UI adjustments were any larger I was originally just going to chalk it up to lack of foresight and say it’ll have to wait for Cogmind 2 where the design could account for it, but based on the analysis above (carried out as I drafted this post :P) it seems worthy of serious consideration.

The question, now more specific, becomes whether it’s worth investing the necessary time/money while also making slight sacrifices in the original UI.

One aspect that keeps me from enthusiastically jumping on this opportunity is that the second most common resolution, 1366×768, would be upgraded from Cogmind’s “native” (and best-looking) size 12 font to size 14, which is the absolute worst in terms of style (it’s an intermediate font size that’s difficult to balance properly given the style).

There’s also the loss of the half-width HUD windows that nicely divided up the sidebar to keep it from looking too monotonous, not to mention providing effortless access to more information… :(

I’ve prepared some mockups showing what Cogmind’s UI would look like under the new system in the two most common resolutions.


Concept: Condensed 1366×768 UI. (Click for full size.) Also in ASCII form, and using one of the alternative fonts (Terminus). Compare to what 1366×768 looks like now.



Concept: Condensed 1920×1080 UI. (Click for full size.) Also in ASCII form, and using one of the alternative fonts (Terminus). Compare to what 1920×1080 looks like now.

What do you think? Is it better? (Worse?) Is it worth it? Is it enough?

Posted in GUI | Tagged , , , , | 10 Responses