Official development blog

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

REXPaint 1.0

Over two years ago, I released the first version of REXPaint, a tool I originally built to explore the possibility of adding art to one of my other projects. Since then it’s become a major component of my workflow for everything from art to UI mockups to map design and prefabs.

Come November there hadn’t been a new release for over a year, though the TODO list had continued to grow with little things that needed done here and there, on top of a number of feature requests from the many other developers, artists, and others who have integrated REXPaint into their own workflow (or fun time :D).

So it was about time to stop calling this thing beta and put together a symbolic 1.0.

New Website

The first thing I did was finally retire the old dev blog, replacing it with a new site here at Grid Sage Games.


REXPaint’s spiffy new logo--made in REXPaint, of course =p

That old blog will no longer be updated. All future developments will be announced on the Grid Sage Forums, and possibly here as well, since I should say that this blog isn’t technically only about Cogmind, that just happens to be the main project since its inception. Eventually we’ll even be seeing other games here :D.

Below I’ll introduce what’s new in 1.0, while for the full list of features accumulated in REXPaint’s nine previous releases you can browse the new website’s features page, which also shows many of them in action.

New Features

Aside from the four non-square Terminal/Fixedsys fonts added for the ANSI crowd, earlier versions of REXPaint came with four square fonts: 8×8, 10×10, 12×12, 16×16, essentially providing four zoom/scaling levels. With 1.0 I’ve added three more to close the gap (14×14) and make for larger-font images at the high end (18×18, 20×20).

Probably the biggest new image editing-related feature is cellwise HSV shifting. Both foreground and background colors of individual cells can have their HSV values tweaked in intervals you set in the options menu. Combined with right-click-to-copy, this can be a useful way to draw art or adjust an image or palette. Here’s an example of creating a quick image using only two hues and brightness shifting (hue/saturation remain unchanged).


REXPaint cellwise HSV tweaking (brightness only).

In that recording you can also see a couple of the other new useful features:

  • The left tools HUD has been expanded to include color values under the cursor, applicable when hovering over either the palette or an image. The display can be toggled between RGB/HSV, whichever you prefer. I’m surprised this wasn’t added earlier, since it’s a feature I rely on a lot in other image software, but I guess I didn’t often need it while working on my own REXPaint stuff since I stick to my generated hue chart… and no one asked for it =p
  • While drawing rectangles or copying an area, the dimensions  of the rectangle are displayed next to the cursor. This is optional, and the same information shows in the info window on the bottom left as it always has, but it can be nice to have it right next to the cursor.

I also added a pair of popular general-purpose palettes to the resources page (alongside DawnBringer 32, which has been there for a while):


Arne 32 & Arne 64 palettes.

For a while REXPaint has featured glyph highlighting that can be used for image analysis--showing exactly where a given glyph has been used in the current image, which in 1.0 has been extended to include colors.


REXPaint image analysis: Locate all uses of a particular color or glyph in the current image.

The rest of the changelog is mostly little stuff, though it’s worth highlighting two other notable optional features that were added to help prevent shooting yourself in the foot, should you need them:

  • Individual layers can be locked to prevent editing the wrong one. “Just in case.” If you try to make an edit, a message will flash to remind you the target layer is locked.
  • Exiting REXPaint with unsaved changes will first pop up a warning dialogue.

The full public changelog for REXPaint v1.00:

  • NEW: Added more CP437 fonts (greater range of image zoom/scale options): 14×14, 18×18, 20×20
  • NEW: Cellwise HSV color shifting of both foreground and background (interval controlled in options)
  • NEW: Info window shows palette/art foreground/background color values under cursor, either RGB or HSV (toggle with ‘q’)
  • NEW: Rect/Copy tools can show area dimensions directly on the canvas (toggle via “RDim” button, or Ctrl-d)
  • NEW: Lock individual layers to prevent accidental modification (“Lck” button, or Shift-1~4)
  • NEW: Hold Alt while cursor hovering over a palette color to highlight all uses in image (akin to glyph highlighting feature)
  • NEW: Options menu (the ‘O’ button at the bottom, or F2)
  • NEW: Program settings changed while running are saved/remembered for next time, without requiring cfg modifications
  • NEW: Exiting while image(s) have unsaved changes requires confirmation (can be disabled in options)
  • NEW: Reset image location to top-left corner via Enter (centering switched to Ctrl-Enter)
  • NEW: Ctrl-RMB copies the uppermost visible cell at that position in a multi-layered image (useful for working from reference layers)
  • NEW: Premade Arne32/Arne64 palettes available from the website resources page
  • MOD: Enhanced 16×16 CP437 font’s relative proportionality with other fonts
  • MOD: Image dimension limits increased from 999×999 to 2500×2500
  • MOD: Removed Undo/Redo buttons to save space (use ctrl-z/y instead)
  • MOD: Autosaving now inactive by default (must set desired interval value in options)
  • MOD: Layer delete button changed from “Del” to “X”
  • MOD: Palette/color swaps only operate on unhidden layers
  • MOD: Changes to layer hide/unhide/active states no longer count towards the unsaved progress indicator
  • MOD: Different cfg format, now that options are available from within REXPaint itself
  • MOD: Change skin keyboard command switched from F2 to F3 (also now accessible directly from options menu)
  • MOD: License in README file more explicit about commercial use of images
  • MOD: Removed backwards compatibility with pre-R9 .xp images (2013 format), which were converted by 0.99r9 build (2014)
  • FIX: One mixed-line glyph in the square 10×10 CP437 font was 1 pixel off
  • FIX: Reversed NW/SE directional canvas scrolling via numpad
  • FIX: Using the mouse to select a value box in the color picker required an extra key press before detecting input
  • FIX: Creating a new image copied the view offset of the image currently open, rather than resetting it to (0,0)
  • FIX: Image browser couldn’t collapse subdirectories at a depth of three or greater
  • FIX: Copy-paste of transparent cells on layer 2+ triggered fatal error in undo history (Note: RMB copy faster for this purpose, anyway!)
  • FIX: Cellwise drawing off edge of image without releasing LMB damaged undo history, which could crash if accessed
  • FIX: Could attempt to draw multi-cell objects to parts of a large image shifted under the tools area, leading to other UI issues
  • FIX: Typing a grave character at the end of a text entry would crash the font renderer
  • FIX: Crash on running without an enabled audio device (now no such device required)

(Previous changelogs can be seen on the downloads page.)


While I’ve always called REXPaint “user friendly,” that’s more a relative phrase since I’m comparing it to other ASCII/ANSI editors, which at this point don’t have either the same breadth of features or flexibility. Still, it’s not exactly intuitive even for regular users of other editors like the Photoshops, Inkscapes and Aseprites of the world, something we can attribute to it being a very different type of editor.

Some advanced features are accessible only via hotkeys, which I think is fine because most users won’t need them, anyway, but one of the most egregious omissions normally required to earn the title “user friendly” is a true options menu.

Prior to 1.0 the options were only accessible via a text file--that’s behind us now with the addition of a true in-program options menu. Changes to settings made while REXPaint is open, including the state of the editor like the font and palette you’re using, are all saved to disk automatically to be restored when next run. And of course it’s nice to see all the options listed right there with a description of each, as well as proper bounding of values and access to the color picker for setting relevant options. The options menu also provides a quicker method to access a needed font or palette if you have many loaded at once.


Sample interaction with the options menu (click for full size).

The options are still saved to a text file, a much cleaner one than before, which you can copy over to another version of REXPaint if you ever need to upgrade:


A new config file, containing default values, which is created automatically the first time you run REXPaint.

The Future of REXPaint

1.0 is certainly not the end of the line. There are other features I’d still like to add, we may get some cool requests, and I will continue to maintain my prioritized TODO list used as a basis for updating REXPaint when time permits.

In related news, now that 1.0 is complete, the next step is to host a competition/event for REXPaint creations. I don’t have it entirely planned out yet, nor a specific date, though I’d like to hold it some time within the next few months. More info to come!

Posted in Uncategorized | Tagged , | Leave a comment

Year 2 of the Cogmind

Cogmind has been in mostly full-time development for 2.47* years now, and things got especially interesting this year with alpha opening up. Again it’s time to recap the past year’s highlights and make, um, “educated guesses” as to what the future holds ;).

Like last time, let’s first check out a collage of development images from the past year:


Images from the past year of Cogmind development as shown on this blog (click for mega size).

I’ve been showing a heck of a lot of gifs instead of static images, so that doesn’t really do the past year justice, but it’s still pretty to look at :D.

Development Timeline

In the period since full-time development began, I’ve invested 4,339 hours of work into all things Cogmind. Below is a summary of how work was distributed over that period:


Cogmind Monthly Development Hours, 2013.7-2015.10 (click for crisper full-size version). (The color coding is for different aspects of development tackled each month, which I’ll be covering in detail in a future article along with many other interesting charts when we have even more data :D)

Comparing year 1 and year 2 (note that for discussion purposes each of these “years” was more like 14 months), it’s obvious the average input varied between the two: 115 average hours per month in Y1 vs. 195 in Y2.

During the first year I wasn’t yet certain how long Cogmind might take to develop, or that it would be able to support itself when the time came, so I was occasionally taking on short freelance jobs to supplement the huge chunk of preexisting savings I was drawing on for development.

Then at the start of this year I decided there was no way about it--I needed to be 110% in, not 75% in, to make 1.0 a reality without spending several more years on it. I made a four-month release plan and set a deadline in April. I ended up getting pretty sick in April and postponed the release until May, but as you can see, the deadline and focus vastly increased the amount of work put into the game beginning in January.

One of the pre-release development highlights focused on early this year was the addition of a tileset pixeled by the great Kacper Woźniak. Like ASCII, the tiles emphasize recognizable shapes and readability over flair. Detailed yet not detailed. Simple and beautiful. He agonized over every pixel, I assure you ;).

Unfortunately his greatest works remain under wraps because 1) those parts of the game have not yet been added, and/or 2) spoilers. Still, we can admire this sample:


Tileset sample, with some closeups.

This year we also got our new website. For the first year Cogmind’s home page was little more than one of those curiosity-inspiring black pages with a logo and basic description of things to come.

Then on May 19th, 2015, Cogmind Alpha was released into the wild.

The launch was a great success for an indie alpha game in an obscure niche. (Or maybe it was successful because it’s an innovative new game in an obscure niche--but still, alpha!) You can read about the release process and first month of sales data in my in-depth postmortem here.

Since sales began in May, I haven’t broken even on development costs, nor do I expect to before 1.0, but just yesterday the 1,700th player purchased Cogmind, and revenue is impressive for a game still in alpha and not sold through any major platform. Thank you everyone for your strong support!

I’d spent a few weeks before release putting together the launch trailer, and it was time well spent as it does a fairly good job of summarizing the game in 80 seconds. To date it’s had more than 36,000 views, a majority of which watch through to the end. I wrote about the trailer production and results in a postmortem for that, too.

We’ve had three major releases since the first, so far aimed mostly at adding yet more features rather than jumping right into the long-term roadmap as originally planned:


Cogmind Releases through November 9, 2015.

One major drag on development itself, but helpful in its own way and a community reward for early supporters, was the Alpha Challenge event held in September. Fun, prizes, and DATA! In this year’s collage you’ll see quite a lot of graphs, and this is where they came from.

Other developments:

  • Over the summer I did an interview with Roguelike Radio--a podcast dedicated to our favorite genre--in which you can hear me talk about the past, present, and future of my projects (mostly Cogmind, of course :P).
  • Quite recently I’ve started doing a bit of streaming, which is kinda weird but fun, and I need to do some real playing for playtesting purposes anyway, so I might as well share it. I stream the weekly seed runs when I have time.
  • As the year comes to a close, IndieDB is once again voting for Indie of the Year, and it would be nice for Cogmind to make the Top 100 as in 2014 (before Cogmind was even released, heh :P). I’d appreciate any votes here! Woohoo, made the top 100! If you see this, you can still help vote for the top 10 here (much more difficult to take on the more mainstream games, but it’s worth a shot).


The decision to ride the wave of amazing initial support and allocate more effort into expanding Cogmind’s feature set rather than immediately heading straight for 1.0 has pushed back the potential completion date, though there is a high chance that will still happen in 2016.

The next release, Alpha 5 (coming soon!), is starting to put us back on track with the original roadmap as we fill in the world’s many more maps and story-related elements.


Cogmind Development Roadmap as of November 9, 2015.

As you can see: maps maps maps maps maps maps maps…

Not that there aren’t a number of non-map features to work on--a couple of the newly-acknowledged major ones aren’t even listed yet because I’m not yet sure if or how they’ll be implemented. (Note the FAQ always has the latest version of the roadmap, which is updated at least once per release. The next update will involve more significant adjustments.)

I’d like everything to be in perfect shape by the time we hit Steam, but if funding starts running low and I think it will work I may have to cut some optional pre-1.0 features and join Steam earlier. (Don’t worry, I’m not referring to anything you see listed there, and we can consider “these other features” again after 1.0, which is actually a good thing since it gives a suitable source of post-launch updates.) That’s not a near-term thing--I’m talking like more than 6-8 months away.

This year GOG also approached me some time ago, asking if I’d be willing to put Cogmind on their platform. That was kinda nice, and a likely possibility as well.

For now I’m perfectly happy not giving a huge chunk of the revenue to a middleman. It all goes straight into Cogmind where it belongs :D.


*For the record Cogmind is technically 3.77 years old counting from the first prototype. Interestingly this is the same age as my son--too bad they can’t play together :P

Posted in Gamedev | Tagged , , , | 3 Responses

Unauthorized Hacks

Hacking has been around since early pre-alpha 2013, and while the early Alpha releases have dozens of commands you can use to achieve various effects, I’ve always considered the system a work in progress. There are more things that can be hacked, a few tweaks and changes to expect, and furthermore there are three major categories of hacks, and before Alpha 4 we’d only seen the first!

  1. Common hacks. Most of these are commands native to the system itself, functions and data that Operators and other robots need access to for their work. There are currently 54 of these.
  2. Unauthorized hacks. The topic of this post. Alpha 4 contains 11 of these.
  3. Unique hacks. NPCs will under special circumstances, or for plot purposes, give codes that can be used to achieve unique effects. These would of course always be entered manually. (There are actually a number of these coded in the game--originally added to test the implementation and ensure it works--but no way for players to discover them yet =p)

These three categories run the spectrum from common to obscure, in that order. So with Alpha 4 we’ve begun exploring the second category. Don’t worry, there are still more improvements and features to come in category 1.

The concept of “unauthorized hacks” was first introduced in relation to Garrison Access systems. These are hacks that attack the system itself or abuse it in some way, decidedly not what you’re supposed to be doing there. They are always entered manually--you’ll never see these listed like the others.

SPOILER WARNING: Beyond this point I’ll be revealing how to do each hack and how they work, even though you’re meant to learn all this via in-game lore! However, right now the necessary lore only exists for one of these hacks--respective lore for the others cannot be added until I create the part of the world where much of it will be found. Reading this will allow you to get around that temporary roadblock and check out this new content, but doing so doesn’t make it any less spoilery! Your choice :)

Unauthorized hacks can be divided into two sub-categories…


With Trojans you install a program that runs on the target system to provide delayed or continuous long-term benefits. You’ll want to make sure the machine itself isn’t disabled, since that will of course render the Trojan useless. Once planted Trojans will continue to operate even if you are traced, however.

There are eight Trojans so far, affecting either Terminals or Garrison Access systems.

Terminal Trojans:

  • Trojan(Track): Reports to you the current location of all robots within a square zone around the terminal, as if you were standing there with sensors and an Adv. Signal Interpreter. The area of effect is determined by the security level of the Terminal--higher tier systems have a greater range.
  • Trojan(Assimilate): An Operator attempting to use this Terminal will instead be permanently converted to an ally (to join your personal hacker network :D).
  • Trojan(Botnet): As long as this terminal is active, it provides a bonus to both direct and indirect hacks at any other machine on the same floor. This effect stacks across multiple infected Terminals (with diminishing returns, in the same way multiple allied Operators stack). Build your own network!

Installing a Botnet Trojan at a terminal.


Machine info lists the currently active Trojans, and allows you to call up context help for each.

  • Trojan(Detonate): Sets all explosive machines within the Terminal’s zone of influence to explode immediately when your enemies pass by. Create your own oversized minefield!

Oops, Mr. Programmer, looks like you should’ve taken a left at the Subcomponent Replicator. (Nuclear Reactors previously infected by the Detonate Trojan--they glow yellow so you know/remember which ones they are).

Garrison Access Trojans:

  • Trojan(Broadcast): Any squad dispatched from this garrison will have its type and composition reported to you immediately, and their location added to your intel database for reference.
  • Trojan(Decoy): The next squad dispatched from this garrison will have its intended target switched to somewhere/something else at the last moment.
  • Trojan(Redirect): All squads dispatched from this garrison have their target altered (more difficult than a one-off decoy).
  • Trojan(Reprogram): The entire next squad to emerge will be converted to loyal followers!

Brute Force

A “brute force” hack completely disregards stealth and overwhelms the target system to achieve some effect, rendering it useless in the process (permanently locked). While brute forcing a system is guaranteed to attract attention, it’s quite easy to do and allows for some more extreme benefits.

Three different machines are currently susceptible to brute force attacks.

  • Force(Extract): At any Scanalyzer, extract from the system’s memory a number of schematics for parts previously scanned by other robots. You can’t control the results, but if lucky it can be fairly useful.
  • Force(Jam): Use this to prevent a Garrison Access system from opening the door for any squads trying to exit into the local area. This is the easiest way to cut off access from a garrison, but is also the most meddling from the enemy’s point of view, a third-rate option behind the much more difficult Seal hack, or simply blasting the Garrison Access system.
  • Force(Overload): For those of you who don’t have much need of Fabricators, how about turning them into engines of destruction? :D This very unauthorized hack causes the machine’s EM imprinting system to go haywire, randomly zapping passing robots with corrupting beams of energy. Use only with intent to cause maximum chaos. And you’d better get out of the way! (This is the one which has already been added to the lore, so I didn’t really have to mention it here, but may as well for completeness sake--plus it’s the most fun =p)

There’s plenty of room for more unauthorized hacks in the future. This first batch was just a medium-sized “side project” alongside Garrison Access, to enable some additional strategic options for that machine.

Posted in Mechanics | Tagged , , , , , , | 4 Responses