Official development blog

Cogmind, 1 Year of Alphas

Cogmind Alpha Access is one year old! (One could optionally end this sentence with “!?!?”)

“Year 1″ since release in May 2015 overlaps with some previous postmortems I’ve done, so rather than rehash that content here I’ll just be linking to it where appropriate. That said, there is plenty of fresh data to share, too :)

The Year 2 of the Cogmind recap is a pretty good general summary of 2015, something I’ll do again at the end of this year. Since then a lot of the work has gone towards overhauling a few mechanics to improve gameplay, and adding more and more content to complete the full world as planned. So, yeah, eight major releases later Cogmind development is still rolling along.

Today though I’d like to focus more on sales and other aspects specific to the alpha which haven’t been covered as much before.

Also, this week I’ll be updating the Cogmind website‘s text and all screenshots. Here are some of the scenes I’ve been working with for the new site:


Composite gif featuring gratuitous ASCII destruction.


Still of that reactor array exploding. (Click here for separate full-view image.)

On to the data…


As of today Cogmind has 2,119 players. Or maybe that’s “players,” because in reality the majority would be better classified as supporters at the moment, i.e. those who joined the alpha program to help the project see 1.0, and maybe try it out every so often before then, or just wait.

There are also an additional 738 people on a special one-time mailing list accessible at the top-right of the buy page, to be notified when Cogmind reaches its intended lower base price (for those who can’t afford to chip in now, or who simply want a lower price for whatever reason). Of course, a number of those people may have signed up earlier and eventually bought anyway, and another portion will never see an email because it’ll end up in their spam box :P

In terms of active players, based on the uploaded game stats there are usually about 20 runs played per day, though that number has fallen in recent months as sales have started to decline somewhat, something you’ll see further down. However, the caveat there is that I don’t actually know everyone who’s playing, only those who opt in to data uploading via the options menu (I do know that not everyone opts in). The active player count is naturally above average in the week after a new release.

Many thanks to the core group of players who have been a continuous help when it comes to providing feedback on each release--zxc, Happylisk, Decker, Sherlockkat, Shobalk, and more have stuck with it for a long time and have helped improve the game for everyone. Even others who simply talk about their experiences give me a lot to go on when I consider balance and potential features, revealing any disparities between the intended vs. perceived vs. actual effects of any changes.


I’m not broke yet!

If you’d like detailed coverage of the first month of sales and other data and issues surrounding launch, you can read my in-depth postmortem here. Crazy and exciting times, that first month :D

But that was only a month, and there have been eleven more since then :P

On the funding side those eleven months have been noticeably less exciting, though there were a few unexpected sales spikes in the first few months after launch. Unexpected because I haven’t been doing any advertising, but I did write that first postmortem which apparently got some traction, and Cogmind has also occasionally been picked up by news and review sites.


Cogmind Year 1 gross revenue, annotated.

Each new alpha release naturally tends to give a slight boost to sales simply because news gets posted around, so there’s the obvious incentive to get new releases out there, but at the same time I want each one to be truly significant, so it’s a balancing act to work on a major version as long as possible before it really needs to be released.

Still, the ongoing sales numbers are so small compared to the initial release (lots of people were waiting for that…) that the alpha release effect isn’t so apparent above. Looking at a monthly revenue chart will explain a little more about the long-term cycle


Cogmind Year 1 gross revenue by month.

The first 3-4 months were all about the initial wave of attention based largely on pent up interest, so they don’t really count. Then revenue started settling into a long, slow trend downward. I believe in the bigger picture November was a pre-holiday slump, since I don’t have any Cogmind-specific details to explain why that was the lowest month. I can say that sales and releases of other games don’t seem to have any real impact on Cogmind sales, likely because Cogmind’s numbers are so small to begin with (really, a couple sales per day makes that day for me :D), plus it’s a unique game.

February I can explain, though. That was a release leap month, when I was working on a big alpha update laying the foundation for the development of a whole new and very different part of the world, so it took extra long and there were the usual news updates but no releases during that period. The effect was also likely amplified by a post-holiday slump, especially after a fairly successful December and January.

Ever since February I’ve started expecting that revenue could truly flatline at any time, but that has yet to play out (whew!). This May is turning out to be another February-like month, though, so it’s increasingly important that I start looking forward. More on that later.

For fun, here’s the revenue by country for the corresponding period.


Cogmind Year 1 gross revenue by country.

Nothing surprising there, given that Cogmind is only available in English. There are dozens more countries on the list below that, among them my own--Taiwan, where currently there are only two supporters (no, I don’t know them!).

So in short, Cogmind has grossed US$ 62k in its first year. That sounds like a lot, but “first year” means first year on sale--development has been ongoing as my primary job for nearly three years now, averaging out to a little over $20k per year, or barely enough to get by. (Right now assuming minimum wage I’m still short $10k.)

Am I happy about it? Hell yeah! While I wouldn’t call commercial traditional roguelike development sustainable just yet, I’m confident that I’ll actually start turning a profit (to fund the next game!) with increased exposure and the inevitable 1.0. And for now at least it’s been enough to continue on without too much worry, instead of rushing to 1.0, which means a better/more game for you :D


Thanks to everyone for your support so far! If I wasn’t on this full time we wouldn’t have seen anywhere near the current progress. Here is a composite changelog from the past year, Alphas 1 through 8, and this is where the time has been invested:


Cogmind development time, July 2013 -- April 2016 (excludes 2012 7DRL work).

The total time investment comes to 5,218 hours.

Cogmind is a code-heavy game, since the vast majority of visual assets are scripted rather than drawn manually--that same graph for other games would look quite different. Not surprisingly two-fifths of development is spent writing code.

As is common with most (successful) indie games, community efforts play a large role in that success. At least a third of my time is spent writing blog posts, posting development updates, and (more recently this past year) on the forums interacting with players.

Sure it would be nice if more of that effort could instead be funneled directly into the game itself, but honestly a portion of that community interaction helps get the word out about the game (thereby enabling everything else because that’s where revenue comes from :P) while also having a number of indirect benefits for the game itself. Interacting with others, or even just writing for a reflective audience of me, has helped shape the game over the years. This approach is the foundation of well-rounded healthy development, something enjoyed by few AAA studios, where everything takes a back seat to marketing and revenue concerns. (The #1 goal there is to maximize profit, after all. If my goal with Cogmind was to maximize profit at minimal risk rather than make a dream game, it would be on Steam and at “1.0″ already.)

In the graph you can also see the Content category is starting to rear its head there, an increasingly important part of late-alpha development as most of the mechanics and systems are in place, but the world has plenty more locations to fill in.

The Future

Where do we go from here? Well, as usual there’s the development roadmap outlined over on the FAQ which is updated with every release.


Cogmind roadmap as of April 27, 2016.

As indicated it’s really just a general outline, and there are quite a few other features (and even new locations) I want to edge in there if I can afford to.

In the near term, another release will be out within the next few weeks, then there will be a slight lull for part of the summer as I take a trip to visit family (it’s been years) and hopefully recover from my recent injuries without issue. Then it’s back home to work on late-game stuff and releases will continue throughout the rest of the year.

The biggest elephant in the dungeon is obviously Steam--Cogmind needs to be there eventually, most importantly as a way to reach new players. It’s unfortunately not anywhere near as simple as I’d like it to be (my current arrangement is super simple by comparison). Due to my situation, I have no choice but to remotely set up a company in the U.S. (as a foreigner) to sell Cogmind via Steam. Yeah, not fun. (WTF I JUST WANNA MAKE GAMES /minirant.) That’s only one factor among many, though.

Increasing exposure and expanding the player base requires a huge investment of time that would further drag on development, but it might become necessary before long depending on how many new players the next couple months bring. Tough to balance!

Cogmind is far enough along (and close enough to completion) that it’s about time to see what if any effect a slightly lower price will have on take up. So to celebrate the one-year anniversary of Cogmind Alpha Access, starting this week I’ll be offering a new limited-quantity tier at $25. Although one could say it’s 17% off the $30 price, it’s not technically a “sale” because the new tier doesn’t come with any perks, so it has somewhat lower intrinsic value as well. I’m extremely curious what kind of impact this will have on sales. As usual, I’ll be sharing the results at some point.

But for now, because they took forever to create and I want my money’s worth, here are a few of the updated website images to come :D


Activating a terrain scanner.


Activating a transmission jammer.


Dev shot of a fully-revealed factory map generated using the latest algorithm (lots of important changes from a year ago).

Posted in Post-Mortem | Tagged , , , | 8 Responses


Fabrication has just been redone, and it is good.

I wrote a little about Fabricators a long while back when they were first introduced to Cogmind as a new feature we didn’t have in the 7DRL, allowing you to build robots and parts if you could get your hands on the schematics and meet other conditions.

Then for years the mechanic sat dormant, and honestly even untested (for gameplay) for that entire duration up until the first alpha. That’s when it became obvious it was likely the most broken part of the game, failing to satisfy its purpose on multiple different levels. It got a couple of quick fixes right away to address the most egregious problems (including an oversight that allowed patient and determined players to construct an army of late-game allies at the beginning :P), but even then it was not well integrated into the whole Cogmind experience.

I can’t say this was a surprise, since complex systems need testing and tweaking before confirming they actually work in the broader context, and since so many other parts of the world had yet to undergo rigorous playtesting, it made sense to wait to do any serious work on fabrication since it was a “secondary” mechanic, anyway.

So it was intentionally left at the wayside. Until now.


First of all, why did fabrication even become a thing? At its core, Cogmind is obviously a game about adapting to the situation, building and rebuilding yourself from salvage as necessary.

But with the right limitations, a system whereby players can sometimes exert more control over what they have access to offers a lot of interesting possibilities. Perhaps you’ve found a really useful part you’d like to duplicate? Perhaps a certain build needs a specific part to really take off? (Or to simply avoid annihilation :P) Or perhaps there’s a very special part but you can’t obtain it directly, only get a schematic after which you’ll have to take the extra step of building it.

Thus fabrication serves to supplement the core mechanic, without completely supplanting it. The goal is that it should be impossible to build everything one needs to survive, instead occasionally filling holes in a build/strategy or just providing access to something special, without being a clearly superior option in every situation.

It should also avoid tedium, and as anyone who’s played will know (and as others can read about below) the process used through Alpha 8 is very tedious…

Original System

Quite unlike the rest of Cogmind’s mechanics, which are streamlined to facilitate relatively quick play and involve only so many elements at once, building anything under the old system is an exercise in tedium. The build process:

  1. Acquire a schematic. (Terminal hacks; Scanalyzer scans or extraction.)
  2. Acquire a container and fill it with matter. (Found; taken from Workers.)
  3. Find a Fabricator of high enough rating to build the schematic. (Found; Terminals.)
  4. Hack to load the schematic. (May fail.)
  5. Hack to start the build process. (May fail.)
  6. Wait for the build process to complete.

It was rarely worthwhile to do all these steps, and even if it were, it’s not much fun.

The original purpose behind the large number of restrictions was to counteract the old hacking system: Prior to the hacking overhaul of Alpha 6, it was theoretically possible to hack forever until you got what you wanted. (Technically fabrication wasn’t the only undertested pre-alpha feature--all of hacking was waiting on the sidelines for proper playtesting and integration.) Now that traces can no longer be reset, unless you’re an insanely good hacker, a single machine/Fabricator can only be used so many times. This paved the way for much simplified fabrication mechanics.


A sample schematic, which looks like the normal item information window, with the addition of fabrication details at the bottom.

Schematics are still a part of the new system, in fact playing an even more vital role as you’ll see later.


Various matter containers.

The container requirement was originally conceived as a cool way to link a general-purpose utility with the fabrication mechanics. Cool in theory. It was actually one of the more tedious steps, and also unnecessary from a logical perspective (the machines can draw their matter from a central network, sure). So that was the first thing to go--no more inserting containers of matter.

To me the most annoying requirement, terrible from a design standpoint, was the level restriction on schematics. Schematics could only be built by a sufficiently advanced Fabricator, but the formula to determine the required tier was completely opaque, and even though it was indicated on the schematic itself, it was just another factor that would vary from item to item, an annoying little detail to remember and consider when searching for a Fabricator (while potentially further reducing the number of applicable fabrication locations). So that was the second thing to go--any Fabricator can build anything!

Under the old system, even if you did get a cool schematic, it was still too much trouble to go through all the steps to try and get it built. Some players would try, but as you can see it was an effort-intensive process and quite possibly that effort would go to waste at any given point of failure. Not fun.

New System

The new build process:

  1. Acquire a schematic. (Terminal hacks; Scanalyzer scans or extraction.)
  2. Acquire a container and fill it with matter. (Found; taken from Workers.)
  3. Find a Fabricator of high enough rating to build the schematic. (Found; Terminals.)
  4. Hack to load the schematic. (May fail.) -- Now much easier.
  5. Hack to start the build process. (May fail.)
  6. Wait for the build process to complete. -- Easier to wait, and can be much faster.

Item for item the new system doesn’t look hugely different from before, but the changes already touched on, along with some others, make for quite a different experience.

Schematics still form the foundation of the system, and are obtained using the same means as before, although even that step is somewhat less problematic because Scanalyzers are much less restrictive regarding what they can scan. (I’ll talk more about other related machine changes later.)

Instead of the old bring-your-own-matter system, matter is instead drawn from a map-wide network itself allocated from the central complex matter stores. The amount of matter available fluctuates over time, sometimes receiving a new infusion from the central stores, and others being drawn down from local use, including your own.


Results of the new “Network(Status)” hack.

Your own use, however, is of course unauthorized, and the further you drain the local network below its normal operating levels, the more likely the missing matter will be discovered after the fact and the entire network will be shut down. Causing a network outage is a fairly big hit on the security level, so there are obviously long-term trade offs involved with building bigger and better things, or more of them. But at least you don’t have to worry about supplying the matter :). (Related: One of several new Trojans reduces the chance that unauthorized matter use will be discovered by siphoning part of the required matter from other systems.)

Choosing a Fabricator is also much less of a problem now that rating restrictions have been lifted. Anything can be built by any Fabricator (hence the increased importance of schematics under this system--once you have a schematic you can build it anywhere). Rather than differentiating Fabricators based on what they can build, high-tier Fabricators instead build even faster. (Like, really fast.)


The new schematic readout indicates the base build time at each type of Fabricator, from tier 1 to the most advanced tier 3.

Hacking to load the schematic is quite easy now, though still only more effective hackers will have a good chance of successfully initiating the build process for better parts and robots. (Design note: The hacking part was split into two separate commands partially for UX purposes, enabling selection of a schematic and first giving feedback on the requirements, and also making it easier to repeat the more difficult second (build) hack without having to again select a schematic from a list. The third reason, implied earlier, was the original possibility of unlimited hacking and a corresponding need for a two step-process so that players had at least some chance to be both detected and traced in a single session.)


Visiting a low-tier Fabricator without hackware assistance.

Then there’s the waiting. This works more or less as before, though for multiple reasons fabrication can be completed more quickly than in the past. The time formulas have been adjusted, advanced Fabricators build extremely quickly, and there is a Trojan which can further accelerate the process by prioritizing all matter requests by a given Fabricator.

And while a couple alpha players wanted instant build times, I feel the strategic implications of a time cost are important because time effectively ties the fabrication into existing systems and gameplay. Any number of things can happen while waiting around ;)

There was one long-standing issue with waiting, though: It often required a little mental math. When the build process begins, it tells you how long the process will take, but then the best thing to do is add that number to the current turn count and wait until then. (In hindsight it could have also given the completion time, but it’s still something to keep track of--we can do better than that!) You could also just keep waiting until the build finished and popped out the results, though that approach is a good way to waste precious turns by over-waiting.

My first instinctive solution was to add an auto-wait feature, a command with which you could automatically wait until a nearby process completed. Unfortunately that involves unresolvable complications like how to treat potential threats that have appeared on your sensors, but may not be threatening at all (or you’re intentionally ignoring them).

Seeing as it’s quite easy to just hold a button (or spin the mouse wheel) for a short while to wait, what’s really needed here is a visible timer. So when a build starts, as each turn passes a little label pops up to report the number of remaining turns.


Starting a build and waiting through the process while the timer runs down.

The timer is also color-coded, so you don’t even have to pay close attention to the numbers--red is a while off, then orange, then yellow, and if it’s green then you know it’ll be done pretty soon and can start paying closer attention.


Short-lived friends making the ultimate sacrifice, and not even complaining that I’m doing nothing to help them.

Note that you could/can always open the machine info window to see the same countdown timer there, but that’s not nearly as convenient. Cogmind’s UI is all about making pertinent information as accessible as possible, and this works well to that end.


Whereas before it was almost never worth it to build things except maybe as a novelty, it can now become an integral part of player strategy. This will be especially true for those carrying at least some hackware, but even those without can make occasional use of the system.

There’s always the chance that in the right hands this less restrictive system might be open to abuse, but we’ll get to tweaking it depending on how it’s actually used in practice rather than based on theoretical analysis and what shows up in a few playtests. I’m curious how players will use it in its current state.

That said, I don’t (and never did) intend for every Cogmind to be great at fabrication, and it’s still an entirely optional part of the world.

Other Machines, and the AI

With the Fabricator updated, it made sense to make similar changes to other machines in order to maintain balance (and working on related systems at the same time is a more efficient approach to development).

To that end, Repair Stations can now repair anything--rating restrictions have been lifted. Like Fabricators, tiers instead affect the repair duration, which means better stations will repair much more quickly. They also get to make use of the new on-map timer:


Repair Station displaying a timer while that process is underway.

Similarly, Scanalyzers can also scan anything! More advanced Scanalyzers are less likely to require additional scans to create a schematic, as well as less likely to break the part in the process.

With that, all machines have now been improved since Alpha 1 last year, working together to enable a wider range of interactions, and hopefully inducing fewer “meh, whatever”s as Cogmind spots a new one :P

Speaking of interactions, the central AI now also makes use of Fabricators, too, a bonus that comes along with the new mechanics. It builds non-combat robots to eventually replace some of those destroyed (rather than sending them in through map access points), builds combat robots to supplement garrison forces, and builds new parts that are picked up by Haulers for delivery to garrisons. It’s nice to tie another machine into the visible ecosystem, similar to how we have mechanics based out of Repair Stations, operators interacting with Terminals, recyclers using recycling units, and more.

Posted in Mechanics | Tagged , , | Leave a comment

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 , , , , , , | 4 Responses

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