Official development blog

Versioning Schemes

Normally I wouldn’t have another post up so soon, but the topic of versioning has become somewhat time-critical. I’ve been thinking over it quite a few times in recent months, but haven’t been able to make a final decision on where to go from here.

Why now? Well, know that in one sense--one of the more important senses, actually--next week Cogmind will be “done.” All the confirmed maps are in, all the major NPCs exist and are doing their thing, all the endings are in place… The story will be complete.


*fanfare, cheering*

Development will continue, but this is a pretty significant milestone.

That said, there are still certain items left on the TODO list that keep me from calling it a true 1.0. And honestly I’m not ready to handle all the meta work that should come with a 1.0, anyway, mainly on the marketing side which at the very least requires putting together a new trailer and getting in touch with press/LPers. (I still like the two-year-old alpha trailer and am tempted to just update it using new visuals, but even that takes a while.)

So what to do about version numbers in the meantime?


Searching for version numbers in the matrix.

We could at least wait until the Steam EA release (as a different kind of milestone) before switching to a new system. However, rather than basing it on an external factor like that it’d be nice to keep the system a little more relevant to the current state of development, and we’re definitely switching some gears here (more on that later).


I wouldn’t say continuing along with “Alpha #” releases is off the table, making next week’s release Alpha 15 as expected. Plenty of games do Alpha 1-2-3 their way to 1.0, and I admit I’m fond of the Alpha system, if only because I’ve been using it for a good while. But there are a few reasons for which, if possible, I’d like to find a satisfactory alternative.

Another vote for switching away from the alpha designation is that for most people it implies a game is in a very unfinished state, probably even buggy or unenjoyable, neither of which would describe Cogmind even years ago. While it’s true I’ve wanted people on the outside to believe that for the past couple years of alpha so that I could reduce the number of buyers and instead focus on development (not unlike my approach to pricing), I’m now more willing to allow the terminology, and first impressions, to start inching into new territory :)

For a short while I was thinking of using “Beta,” as it naturally follows Alpha, but that’s technically more of a “this software is feature-complete though still subject to pre-1.0 tweaks and fixes” sort of state. If we wanted to judge Cogmind’s development in those software terms, it’s clearly still in alpha and will be for a while, since I plan to do lots more with it! Even major new features…

Hey, maybe we could do something off the wall and go with “Gamma” releases? Haha, okay that might cause some confusion.

R for Release

Some games and libraries simply increment an integer with each release: R1, R2, R3… Pretty straightforward. I like it. I’ve also used it before, for X@COM. Minor patches can just add a decimal or letter, e.g. R5.1 or R5a.

If I went this way, another thought is to skip straight to the actual release number, so “R15,” just to keep the sequence going rather than starting over, though an “R1″ is a pretty meaningful statement for that one release in its own way. A true new beginning rather than more of the same.


Maybe one day!

“RC#” is another option, though not too often used with games (?). Designating a Release Candidate is more akin to beta, or the final versions of beta software, not to refer to something that will continue receiving large feature updates for the foreseeable future. But then you have games like Starsector, which has been using an RC numbering system alongside their decimal-numbered releases for many years now :P


Speaking of decimal systems, they’re definitely the most ubiquitous. But I don’t really like the idea of purely sticking with a bunch of numbers. (Just this week I posted about how and why I’ve circumvented numbers where seeds are concerned :P)

Numbers aren’t as easy to remember, and more importantly any sub-1.0 version numbers might be assumed to reflect the amount of development remaining until completion (e.g. 0.5 is half finished), even if they’re not intended that way. Given that there’s a huge number of possible future features, and I can’t say exactly which will make it in, it’s tough for me to nail down where a given release stands in terms of numbers.

Trivia: Technically Cogmind does have decimal version numbers, but they’re all simply 0.10 (a common “this is an early build lots more to do!” number) followed by the date, e.g. 0.10.170509. These are just for my reference, because I find it really useful to have the date in the “version” itself.

One way devs work around the boring number version issue is to give releases unique names. I did this for X@COM, for example “Sheer Terror” when adding terror missions, “Sound Like a Hero” when I added sfx, “Chryssalids in my Backyward” for… the chryssalid update :o. They’re a fun and easy way to remember, more interesting to read, and useful for setting the theme of a release.


Revenge with Blaster Bombs in an X@COM town. Damn that game’s a blast and I want to work on it…

I’ve thought of naming Cogmind releases for a long time, even retroactively naming older ones for consistency, but never went ahead with the plan.

Actually, I have sort of named each Cogmind release, if only in one place: IndieDB. For release announcement posts there I always name the release rather than reporting it as a number like elsewhere, just to give the post title a less boring look since it appears listed with other games, and also to give a hint of what the release includes. The next release is already dubbed “The End,” Alpha 14 was “Hack ‘n Slash” (melee multi-wielding), Alpha 13 was “Rise of Zion” (new plot thread), Alpha 12 was “The Place No One Lives to Tell About” (boss map), etc. While we’re at it, do you have any opinions on named releases?

In any case, version names are really just supplementary to another system, as ideally a game’s versioning should reflect some kind of sequence.

Dev Cycle

As far as other considerations go, the decision here depends somewhat on the future release schedule.

In the past it was easy to maintain a 4/5-week release cycle, with a couple weeks of adding a big chunk of content centered around a new map or branch, followed by a week of bigger feature(s) and then some little ones. While I really like that approach, which makes each release pretty substantial (and discussion-worthy!), future updates won’t usually have new maps to be focused around, which themselves lead to lots of other related required content, features, and mechanics.

I’m also looking forward to the pace being a little more flexible and responsive, such as releasing smaller batches of new features every two weeks or so. This change in pace would be another reason to depart from the original alpha designation, if only because sticking to the ongoing “Alpha #” system can distort and dilute the effort and value of the previous releases, each of which took a lot of work to complete.


Grid Sage Games release history as of 170504.

I very much enjoy the practice of releasing with meatier changelogs, but then players also appreciate more rapid development, so there’s a good chance I’ll be heading in that direction for a while, at least for much of 2017 (once past the “actually releasing on Steam” hurdle).

Are you done yet?

No, this is cathartic and I might be coming close to a decision :P

Having written all of this out, I’m leaning a lot more strongly towards an R# system, maybe calling it R1, kinda like a fake 1.0.

And beyond that? I guess then we can, okay, eventually declare a release the 1.0, and then I imagine there will be updates even beyond that (I probably won’t be able to stop myself even if I wanted to), so then we could go with numbers since there is no longer some kind of commonly-assumed target after 1.0, which just breeds updates like 1.01, and so on. Alongside it we’ll probably just continue with the R-numbering as well.

Anyway, regardless of what versioning we go with for now, I’ll keep up the same date-appended pure number version (still 0.10!).

So what do you think--have I overthought this enough yet? :P

I… still can’t decide. Because after sleeping on this post I woke up thinking about it from another angle and started to question the whole R-thing, in that unlike a < 1.0 decimal version number, or clearly having an “alpha” right in the version name, using something like “R” doesn’t even hint that the game still has a fair bit of development coming, or that it’s technically “early access.” That information has to be expressed externally to the versioning, which is somewhat annoying. Maybe just let innertia do its thing, call it Alpha 15 and stop thinking about this? Or is it time for something new? Hm.

Maybe Beta? It’s different from Alpha but clearly “not done,” and we can ignore what it really means in terms of software development (most games ignore it…). Hm.


Update later same day: For scheduling reasons I had to make a quick decision since it’s Friday and for some reason I really thought it was still Thursday :P. So… Beta it is. Huge feature preview for Cogmind’s Beta milestone is now posted!

Posted in Gamedev | Tagged , , | 10 Responses

Working with Seeds

No, not plant seeds.

As most fans of the genre are aware, a fair portion of a given roguelike run is determined based on values returned by a pseudorandom number generator, commonly referred to as the RNG. Before it can do its job, an RNG must be “seeded,” or given a value that starts the entire chain of values to be returned beyond that point.

Certainly when a roguelike starts up all it has to do is seed the RNG with the current time (the most common practice) and then not worry about it after that--the RNG helps create maps, chooses what populates that map, determines the outcome of actions, and so much more. But it turns out there are many other seed-related considerations and applications when developing games with procedural content.

Important to all this is the understanding that the seed used to initialize the RNG doesn’t have to be random. If manually set to the same number each time, the resulting chain of numbers it spits out will also be the same!

Cogmind’s Seed Structure

For reasons we’ll get to, Cogmind doesn’t just store one seed. There is of course The One Seed, actually called “worldSeed,” which is the single seed from which all others are derived. So in a normal run the world seed is simply based on the current clock time (meaning yes, players who start their run at exactly the same millisecond will technically be getting the same world layout!). And by reusing a specific world seed value in a future run, the exact same world can be generated again and again. Or by simply starting a new run at a different time, the world generated will be completely different.

But if that’s true, then why do we need more than one seed? The answer in two parts: 1) individual maps are not generated until the player reaches them; 2) different players may visit maps in a different order. Therefore at the very beginning of world generation, right after the world seed is determined, it then creates the world layout and within the data for each potential future map it stores the seed to be used to create that map if and when the player arrives there.


Every map has its own mapSeed, generated by the worldSeed (some extraneous comments and code trimmed for clarity).

When the player arrives at a new map, the map generator loads the seed for that map before starting the process. This ensures that everyone visiting that map via the same world seed will also get the same map, regardless of how they reached it.

Development and Debugging

As you can imagine, the ability to force the world to generate in a predictable, repeatable pattern by manually setting the seed is extremely useful for perfecting a map generator like the ones I’ve talked about before.

My first use of seeds in Cogmind would have to be during early pre-alpha development, where much of the focus was on map generation. Being able to seed the generator to recreate the same map again and again when working out problems with the underlying algorithms saved a ridiculous amount of time compared to just waiting for specific problems to pop up. So I could keep skipping through procedural maps until finding an issue, check whatever seed led to it, force the generator to use that seed, then step through the process to find out what went wrong (or could be improved). It’s really easy to track down isolated issues by simply putting a breakpoint in the debugger for a specific coordinate in question, and examine what’s up with it.


I spent a lot of my time looking at maps like this, waiting for a “bad seed” to investigate.

After releasing the alpha, bugs either reported by players or that I discover myself are sometimes related to the initial state of a map, and in cases like that it’s ridiculously useful to be able to just load up whatever seed produced that map and take a closer look. Being able to reliably repeat a bug is the first, and biggest, step to actually resolving it! The alternatives are not too pretty--if unable to guess the cause from a simple report, having to wait for it to appear again to get more details is an annoying drawn out process, not to mention much more difficult to do remotely.


A run’s seed is output to run.log while the game is running, as well as added to the final score sheet.

Preserving Consistency

It turns out there are all sorts of places where a seed can go wrong :P

Ideally a world and its maps and all the little details within those maps originating from a single seed should be the same for each player using it, so there are important game-specific considerations aimed at preventing “divergence.”

A simple example would be scrap piles in the caves, which are kind of like treasure chests that drop loot. If I didn’t care about proper seed support my normal approach would be to simply generate the loot on the fly when the player steps on the pile, but each player will have taken different actions before that point, meaning the RNG will give each of them different items! For consistency, all players using the same seed should have access to the same “random” loot. Of course the brute force method would be to pre-generate and store all the loot when the map is first created, but this is wasteful in terms of both time and memory. Instead each pile just stores its own unique “loot seed,” and when necessary that seed is used to seed an RNG which generates the loot on the fly. That way it comes out the same for everyone on the same map. (It also means that attempting to save scum to get different loot won’t work :P)


Determining loot from scrap at the point of interaction.

An example of a system that required a more involved solution to ensure consistent game worlds is the unique encounter handling. While some encounters in Cogmind are generic and might occur more than once, many are unique and should at most happen only once per run. (It would be weird to meet the same named NPC and specific encounter more than once in the same run :P) But because maps aren’t generated until the player reaches them, there’s no way to know which map might use a certain unique (or otherwise limited-count!) encounter. A given encounter may be allowed to appear on any number of maps, but what if player 1 visits map A first and gets that encounter, while player 2 instead visits map B first and gets that same encounter. Their maps will generate differently! And they’ll have even more divergent experiences if they then visit their respective “other map.”

To address that, all unique or limited encounters are randomly assigned a valid map when the world layout is first generated, and they will be chosen from among the pool of encounters available for their map, which may or may not use them--it can’t be sure because there may be other conditions required for that encounter to actually appear (conditions that cannot be confirmed until the map itself is created), but at least it’s known that said encounters cannot appear on other maps and cause divergent runs from the same seed!

Seed-based map generation also requires explicitly separating out a number of components that factor into the initial state of a map, where those components are derived from player actions. Actions like bringing allies from one map to another, or plot-related content through which the player can affect future events, all need to be taken into consideration to prevent prior actions from affecting the base map, which should remain as consistent as possible aside from purely what the player influences. For this reason I’m careful to exclude anything player-specific from the map generation process until the very end.


Cogmind mapgen source transition from the underlying map to player-specific adjustments.

Other changes to the usual behavior are necessary when players manually seed their own run. This is to make sure that the handful of automated player-specific meta features are deactivated. These are features aimed at newer players, such as the tutorial map, which normally replaces the first map for a player’s first three games. Another example is an encounter inserted only the first time a player enters a Waste map, wherein a Derelict says a little dialogue before running ahead and getting brutally crushed so the player immediately realizes that’s not something they want to do :P


Bad things are about to happen.

Seed Formats

Seeds don’t have to be numbers! Well, they are internally, but developers shouldn’t place dev restrictions on players where unnecessary. It’s time for more “ergonomic” seeds :)

Number-based seeds are boring, and not as easy to remember or share, so early on I made sure to allow any alphanumeric strings to count as valid seed input. Players can, for example, try out using their name as a seed, or some other interesting words or phrases. I’ve even had one player go through multiple runs, changing the seed to a new phrase each time, which when read together formed a longer message and appeared in the upload stats :P

Of course, internally these string-based seeds are no different from numbers. Each character is converted to its decimal value, all of which are multiplied against one another to create a final number the RNG can use as a seed.

So manual seeds have always allowed strings, but random seeds (i.e. the majority of seeds players are using by default) have still been represented by numbers. More recently I decided that I wanted to take this a step further and have even random seeds be expressed in words, but how would they be determined?

The solution was inspired by gfycat, which instead of generating a string of random characters for their URLs uses an AdjectiveAdjectiveAnimal format (see the end of their about page). My first thought was to go with lists of Cogmind-relevant words that I’d draw up myself, but that looked like it would be quite a lot of work--there had to be a quicker solution. And there is!

Cogmind already has a bunch of relevant adjectives and nouns in the game data itself, so why not just use those? Specifically, most items are named in a predictable Adjective + Noun format, and those words can be extracted for use in mixing and matching. Cogmind has nearly a thousand items, and the number of permutations if we pick three sub-words in a row gives plenty of variety. AdjectiveAdjectiveNoun it is :D

To create a seed, the entire list of existing item names is parsed according to various rules, creating a separate word pool for adjectives and nouns. Nouns are generally assumed to be the last word in an item name, and all the others are treated as adjectives. Other filters to keep some of the weirder items from creating seeds with odd formatting:

  • Word must contain at least three characters
  • First two characters must be different from one another
  • No words including punctuation or digits
  • Word cannot be entirely upper case

And finally no duplicate words are added to the pool (which would weight them higher). In the end we get random seeds like this:


Randomized “fake item names” as seeds--much better than something like “1477302648″! (see a longer list of samples here)

These fake item names are a heck of a lot more fun than numbers, and there’s the added bonus of seeing words in there that you may not recognize, as a kind of teaser for other items that are actually out there somewhere. As mentioned before, the random seed used to create a run appears in the score sheet, and each is also listed alongside its run in the composite score history.


Scorehistory.txt, with fake item seeds.

Miscellaneous Applications

We’re not done yet! Seeds have a surprising number of applications, so let’s check out some more of them…


Roguelikes are single-player games, but there are plenty of features with community-building potential. One of those is so-called “weekly seeds,” where a single seed is played through by multiple people who can then share their experiences, or compete with one another for the best score, knowing that they are at least playing with the same fundamental circumstances.

Cogmind has had… semi-weekly seeds for the past couple years. Although not as popular as they were in the early days (when lots of the regular players were on the forums instead of chat :P), I’m sure they’ll pick up again when the player base expands again this year. Some roguelikes such as Caves of Qud even have the weekly seeds built into the game itself (with separate leaderboards!), something I haven’t done yet but probably should at some point.


One thing I’ve always wished I could to do is enable full replays of a run, which is most easily accomplished by combining a seed with the player’s recorded input. But a couple of architecture road blocks have made that all but impossible :/. Cogmind’s animation system is mixed in with the game logic, so features like adjusting the speed of animations (or canceling them altogether) are not possible. For replays to work there’s also a need to use different RNGs for the game logic and any rendering-related functionality, which is something I didn’t do. Essentially, this kind of feature should be built in from the beginning to make sure it works, rather than trying to tack it onto a sprawling 120,000-line code base :P

Obviously replays also add a lot of value with respect to learning and community-building. At least we always have streams and LPs, in any case.

Regarding that replay technique, it can even be used to implement saving. Instead of actually saving the entire state of the game, save all of the player’s input from the beginning. Then when it’s time to load, seed the RNG using the same value, followed by all the same input to get the same final result! I’ve heard that Brogue saves work this way, although “replays” are such a complicated thing that I’ve also heard Brogue’s saves are prone to breaking in some cases, which prevents loading that saved game :/. Still, a very cool system overall!

Saving Large Worlds

Another type of seed-based saving is useful for large open-world games, in which storing the entirety of the game state isn’t feasible (too much space!), nor is keeping every visited location in memory. Instead the world is divided into chunks, each with its own seed (essentially how Cogmind’s map-specific seeds work), and a chunk is only generated when the player nears it. Storing that area on traveling elsewhere, or saving the game, is simply a matter of storing its seed along with whatever changes occurred between its generation and the time it’s stored. So even games with destructible terrain and other player- or NPC-induced changes can take advantage of this kind of “delta map” system to keep system requirements within reason, despite having nearly infinite space to explore. (Literal space exploration games can use this same method. One such example was Infiniverse, but sadly its site and some relevant technical articles are no longer available…)

Seed Catalog

One of the more unique seed applications I’ve seen is the Brogue “seed catalog,” which comes with the game and contains a list of every item found on each of the first five floors for the first thousand seeds.


Excerpt from Brogue’s seed catalog.

Basically it’s a meta-approach for adjusting the difficulty, or perhaps to look for a seed more suitable for a desired play style (since early-game items in that roguelike can have a significant impact on long-term strategy).

Have you heard of any other uses for seeds? I’m sure there have to be more out there…

Posted in Gamedev | Tagged , , , | 2 Responses

Music for Cogmind?

For a while the whole music thing was something I was going to start dealing with in mid-2016, but last year Cogmind just kept increasing in scope as it felt like there was enough funding to justify adding more Fun Stuff while still on the route to finishing off the story. And my intent all along has been to wait until the main game is complete before tackling the issue of music, to be able to better gauge the full extent of what’s needed. With the upcoming Alpha 15 being story-complete, this can wait no longer!

Most roguelikes don’t even feature sound, much less music. Of course, “most roguelikes” are also non-commercial--nearly all the commercial roguelikes do have their own music. That said, these commercial roguelikes also have nowhere near the same soundscape that Cogmind already does, so there’s an argument to be made for not bothering with music in this situation…

I’m a huge fan of video game music, and have been since the 80′s. Yes, the 80′s, back when I’d record NES tracks on cassette tapes to play back later. VGM is almost all I listen to--every. single. day. :D To me music is a big part of the gaming experience as well, and I’ve always thought it accounts for much more of the experience than most people gave it credit for, though that public perception has certainly changed over the past 15 years. On both the development side and among players, nowadays game music is afforded a much greater importance than it once had, and is more widely appreciated. Yay!

So naturally I’d love to have music in Cogmind. That I’d one day be all grown up with my own game that could have its own professional OST? My 7-year-old mind would be blown :P. But in the end I’ll have to put aside my personal preferences and do whatever works best for Cogmind, for which there are a number of different options that don’t necessarily equate to a full-on “music music” OST.

Music vs. Sound Effects

Cogmind is rather unique in that it already includes a detailed soundscape providing lots of audio feedback for everything that’s going on, both interface-wise and surrounding actions. Different beeps and bloops for anything you do, material-based sounds for a variety of actions, unique sounds on talking to each major NPC, distance-based volume for explosive and other special machines, of course hundreds of weapon-related effects, and much more supported by an array of more sound samples than almost every indie game out there. If it happens, there’s a sound (or three :P) for it.


Zoomed out view of all Cogmind sound data to date, 821 of them (even more if including the additional samples layered in).

These sound effects do a pretty good job of creating the right atmosphere on their own, though there is still potential room for a separate continuous layer of music or ambient tracks to enhance that atmosphere and mesh it all together. The question is whether it’s necessary or desired, and what factors play into that decision.

Music is certainly tied closely with pacing, and in roguelikes pacing can vary greatly from player to player, or even from moment to moment in the same run. You might be making rapid decisions that could involve either combat or simply inventory management, or you could be in a pitched battle during which you suddenly choose to cautiously and intentionally make every little decision only after some thought. This makes dynamic music not quite as appropriate for turn-based games. Instead, sound effects work better as a way to match the player’s pacing (problems associated with animations and large battles aside, which I’ve tried to mostly head off with faster animations). In this way the sounds themselves are together a type of “dynamic music,” with the added benefit of each component offering its own feedback to the player.

While over the past couple years Cogmind has gotten along just fine like that, let’s examine some other possibilities.


There are multiple potential approaches to music here, each with their own benefits and drawbacks.

Music Music

Music with strong melody (and a variety of instruments?) makes for good listening on its own, but would steal too much of the attention from the existing soundscape. This is also the kind that players (especially roguelike players) would tend to simply turn off anyway, and is the only category I believe should probably be out of the question for Cogmind.

Of course, like any of my claims in this post, an individual composer’s talent could very well prove me wrong under certain circumstances. Regardless of type, the best video game music eventually doesn’t even register while playing--despite being a part of the experience, as an integral part it is absorbed into the whole. Ideally players can focus on it and it sounds good, or not focus on it and it fades into the background. I’m guessing it’s harder to achieve this effect with less ambient forms of game music, so again it’s a question of skill.


One step away from music with a strong melody we have that which borders on ambient, but still uses a recognizable yet subtle melody. This more subdued type could be appropriate for Cogmind, having the advantage of using continuous music to “unify” everything in the existing soundscape without overtaking it, while also possessing its own identity.

Pure Ambient

For a while I’ve imagined that this will be Cogmind’s best option, though it’s also harder to find and judge who might be good at this, since it’s a very game-specific, atmosphere-specific approach. For someone to do this well, they would also ideally have personal experience with each respective area in Cogmind’s world, because a lot of that feeling comes from playing rather than from visuals (by contrast the latter would be the case in most other games). I guess I’d end up just trying to do my best via descriptions :P

Any music should definitely strongly reflect the area in which it’s heard, in line with Cogmind’s overarching design goal to maximize immersion, and pure ambient tracks would have the easiest time helping to achieve that goal.

As a test, for a while now Cogmind has already included two tracks that fall under this category, relatively monotonous looping drones used in

the cave areas

as well as Command.

Not the best examples, but they work okay. In all these months I haven’t received any feedback as to whether they actually add anything / enhance the experience.

When I think pure ambient I also think there could be other faint/distant sound effects playing in there, so better than the samples above, although it’s challenging to have a looping track in which such elements don’t stand out every time they come up! That might need to be dynamic--random effects layered on top of a continuous looping background.

Local Ambient

Very similar to the previous pure ambient option, this one may be able to achieve the same effect. It takes the “sound effects create the ambience” approach to an extreme, relying on numerous localized ambient sounds sourced from machines producing looping effects. However, in its pure form there is no unifying continuous track throughout a map.


Visualizing the sounds emitted by select machines. I’ve written about the system behind this before.

The advantage here is that it’s something I can do myself, meaning it’s both cheaper and gives me more control over the feeling I want. (I don’t have the skill to do any of the other types above.) Finishing it would probably take at least a week, so technically it’s something I could try before going with any of the other options. As seen in the screenshots, only a handful of machines in Cogmind currently produce sound--like the ambient samples they were just a test.

Cogmind Dynamic Ambient Sounds

They’re dynamic! Ambient sound changing as a door is opened or wall destroyed.

In the end, machine-based ambience and any kind of music are going to be mutually exclusive, unless that “music” is extremely subdued, as with the cave/Command samples.

Outside roguelikes, there are some examples of games that have taken this route, and for similar reasons, too. For example, The Witness doesn’t include music. Nor does Duskers. Like Cogmind, both place a heavy emphasis on immersion, and have been praised for it (random example, one of many I’ve seen). Interestingly, since it came out I’ve heard more than one account of direct comparisons between Duskers and Cogmind.


In a general sense there are two ways to go about music style, either something bold and experimental, or “safe”/”just there in the background.” Hard to choose between the two! Especially in a game like Cogmind which already has its own audio identity to an extent.

Movies and games are rather different mediums, but the same general principles apply across them--check out this video (the point is summarized from the linked 12:04). Lots of games go with safe music, which is otherwise not very interesting in itself. But more and more games have proven it doesn’t have to be that way. Of course, taking a pure ambient route misses out on the value of having music which is memorable and associated with the game, as well as a draw for anyone listening to trailers or gameplay videos for the first time. (That said, I’ve also noticed people dropping into streams and immediately being awed by Cogmind’s existing combination of animated terminal aesthetics and its accompanying sound effects, so I guess that much already comes across…)

As for specific style, I don’t think there’s any argument that Cogmind music (assuming there is any) should be electronic/tech-ish in nature. No pianos or acoustic guitars here. One common reaction might be “chiptune!,” but to be honest as much as I like that style myself I don’t think it fits the theme of immersion and realism which we already see with the mostly realistic sound effects. Chiptune has more of a gamey, less atmospheric feel to it. Cogmind probably needs something more gritty and sci-fi than that.

We can make further inferences about what Cogmind players expect and enjoy by checking out what they’re already listening to (see addendum at the end of this post).


Music is expensive. Well, okay, it can be very expensive, or even not too bad, depending on the composer, style, and volume of work required. Cost is the biggest reason I’d even hesitate to at least try out a soundtrack.

Music is obviously not necessary for Cogmind, but how much would it add to the experience? And is that cost worth it? The answer will vary greatly by individual player and whatever style and format are chosen. Taking it as a trade-off, a professional composer to do a full OST for Cogmind would come at the cost of at least several months or more of time I could afford to spend adding extra content. That’s because I’m willing to work very cheaply on my own game, but the pros are not :P

I’m not looking to buy the full rights to the music, meaning a composer could certainly sell a Cogmind OST, and Cogmind is not exactly an unknown game (I can see it being fairly popular once it’s out there), so maybe that counts for something? A lower rate perhaps? :) For a composer that only makes sense at the more musical end of the OST spectrum, but that’s also the type of music which is more expensive in the first place. (Ambient work is generally cheaper per minute.)


How much music do we really need, anyway? I can’t show a full world map here because spoilers, but I can say that at an absolute minimum there would need to be 6 different tracks. But that’s woefully inadequate in a world with nearly 40 maps divided into about 30 types.

The problem is that as soon as one or two of the more specific map subtypes get their own music, it would seem odd that others don’t have their own as well. A more realistic minimum would be 10 tracks, which still merges a number of areas with unique meaning, gameplay, and/or atmosphere. As I’ve divided it up, a more ideal number hovers around 16.

The total cost will also depend on the precise length of each track, which itself could vary widely depending on style, composer, and what turns out to work the best. I’d say a minimum is probably 2-3 minutes per track, putting the minimum combined length at 12~18 min (low end, unlikely), 20~30 min (realistic middle ground), or 32~48 min (better estimate). Preferably they’d be longer, but then some of those in quicker areas would naturally also be shorter to mostly compensate.

Then of course there’s the consideration that new maps added in the future will likely require their own music, and that any additional asset requirements placed on new content slow the addition of said content while also reducing the total amount which can be added further down the line. This is one of the unavoidable annoyances of taking roguelikes commercial and adding higher production values overall :P


There are countless qualified pros out there. I spent a good bit of time researching potential candidates a couple years back, and over the past two years of alpha others have contacted me directly expressing interest in doing the OST. I’ve never specifically contacted any of the composers I researched, but all of those on the short list below have gotten in contact with me at one point or another. I’ll introduce each below, but know that I have not all that recently spoken with them about the possibility of doing an OST, so they may not even be available these days, or simply too expensive.

(Of course, as my luck would have it, all these composers live in expensive countries, which makes it harder for me to come up with the rates necessary xD. I’ve seen some pretty good composers in cheaper countries who work for lower rates, but no one yet that I think would be a good fit.)

Alex Yoder

Alex did Cogmind’s Alpha Trailer music, which has received a lot of praise (no surprise there--it’s wonderful!).

A trailer music’s format is different from what one hears in a game, but Alex has done work on games before, including the well-known Crawl. His style involves some pretty interesting sounds. It’d be neat to see what he could come up with for Cogmind. You can hear more of his sci-fi-ish stuff here, here, and here.

Ben Prunty

As composer for the famous FTL, Ben probably needs little introduction. It’s hard to say what he’d come up with for Cogmind since he’s got a wide variety of styles, but he did mention being interested in doing the OST if given freedom to experiment.

On top of the skill factor, Ben also brings up the potential value of having a recognizable name attached to the OST, and by extension the game. That fame can be a drawing point itself, something that isn’t as easy to quantify and factor into cost vs. benefit.

Neon Insect

A composer-plus-Cogmind-player, Neon Insect sent me a track inspired by the game. You can listen to it here. It doubles as a good example of what I was calling “semi-ambient” above.

This particular track isn’t amazing, but then it was just a quick fun thing he did one day a couple months back, not a final version. I played through a whole run with this going in the background and it did a nice job.

I have more composers on my list--these are just the first few that stood out so far. If you yourself think you’ve got a style that could work, or would like to recommend some other composer, I’m happy to listen to suggestions and submissions :D

Addendum: What are Cogminds listening to?

People have so much of their own music these days, or access to it via the net, that it’s been easy for players to insert whatever they feel is appropriate while playing. It still seems better to provide something official if possible, which can then be muted if desired. But if we can know that a large number of players will just turn off the music, then it’s kind of a waste, eh? :P (That money can be put towards feature dev!) At the moment it doesn’t really feel like anything is truly missing without music, as it would with other games, though the fact that many players are usually playing to their own music implies that there’s space for something there.

Looking back at what Cogmind players have reported listening to over the years…

The Deus Ex: Human Revolution OST is popular, which together with the OC Remix adaptation is what I’ve played to the most. The System Shock 2 OST is also popular. Other OST recommendations from players: Frozen Synapse, Hackmud, A New Dawn (MW2 covers).

What do you listen to while playing? What direction would you like to see Cogmind take in terms of music, given your experiences and the considerations I’ve run through in this post? Discuss here or over on the forums. (Also more discussion has been happening on r/Cogmind)

Posted in Design | Tagged , , , | 17 Responses

Dissecting a Cogmind Changelog

Cogmind has had 15 major releases in the past 21 months, and the changelogs for especially the latest four have each been massive walls of text. While it’s fresh in my mind, and before we move on to a different system of smaller, quicker patch-style releases, I thought it would be interesting to share an inside look at how even an impressive changelog isn’t all that representative of the work involved, or even the true content of a given release.

I’ve talked about the bigger picture with regard to release cycles before, but here I’ll be going into a lot more detail focusing on a single changelog itself, specifically that of Alpha 14, the most recent update.


Alpha 14′s changelog as a scaled down image just to give a general idea of its length and composition.

I always split the changelog into three sections, NEW, MOD, and FIX, something I’ve done for about six years now, since the early X@COM releases. I got the idea from one of the libtcod devs back then, and liked its simplicity and the fact that it conveniently relies on only three major categories to cover every possibility, distinguishing explicitly what’s new vs. what’s changed, which I think is more important than categorizing by other characteristics such as “UI-related,” “gameplay-related” etc.

The largest single section tends to be new features (here 42%), followed by changes (37%), and a smaller number of fixes (21%), a distribution more or less common across all releases.

Cogmind gets put through a good amount of both manual and automated testing, so there aren’t usually many bugs to deal with, generally just a couple larger things with each release, and a handful of minor rare issues with no significant effect. Most are either UI-related or emergent issues that naturally sneak into such a large code base. By contrast, there is a fair amount of tweaking both to mechanics balance and QoL. Then of course new features should make up the bulk of a release, as that’s what everyone looks forward to the most!

This same ratio will likely continue for the entirety of Cogmind development, including post-1.0, because I’ve been operating from a “complete game” foundation since Alpha 1, so there won’t be much of an incomplete game vs. complete game shift going on (hypothetical public changelogs of Cogmind’s two years of pre-alpha versions, on the other hand, which correspond to what a lot of other games consider “alpha,” would easily be 95% “NEW” line items).

As for the changelog presentation itself, you’ll notice that I color some items. These are the important ones, basically what I think anyone who only wants to skim part of the list should prioritize--the features, changes, and fixes players would most likely want to know about.

Within each category, their order is honestly pretty random, though if there are a few related entries they’ll be grouped together, and I always stick the handful of biggest NEW features at the top. The fact that there’s a new map, the numbers of any new robots and/or items and major features (e.g. difficulty modes) need to be the most visible. (In this particular case melee multi-wielding also deserved to be at the top, but both it and difficulty settings have multiple associated entries, so one had to win out, and the former is a much bigger deal, after all.)

For the purposes of this post, I’ve rearranged the changelog in the order I actually implemented everything. They’re also colored by category, so we can examine how that aspect relates to the process (green = NEW, yellow = MOD, red = FIX).


Alpha 14 changelog, ordered and color-coded. (click for full size)

At the top there you can see a few fixes, generally made shortly after an update when a handful of new issues are discovered by the initial surge of players. These aren’t for a patch (in which case they wouldn’t even appear here!), but come at a time when I’m mostly just interacting with players--and playing myself! So I’m less busy and it’s convenient to take care of these right away.

Otherwise, most of the fixes don’t come until a phase after all the major features are complete. Before that point I’ll just collect them in a list, although if it’s not immediately clear what caused a reported bug, or I don’t think I have enough information to solve it (I usually do), I’ll tackle it right away in case whoever found it might be able to help by providing additional relevant information. (Another exception would be very simple bugs reported when I happen to not be too busy, in which case I’ll just take care of it immediately.)

Why prefer to do tasks in groups? Efficiency. It’s quicker to handle tasks of a similar nature together, both in terms of tools needed and mental state, and I don’t like to waste time :). On smaller projects wasted time doesn’t really have a chance to add up, but losing a little time here and there on a project spanning years can in the end add up to weeks and months!

Note the “issue resolution” section is named such as it includes MODs, not fixes per se, but usually balance tweaks or other changes often in response to player feedback, sometimes direct and explicit, and at others just based on my observations of player experiences.

At the end is a flurry of smaller features, feature requests, QoL and the like. AKA the “OMG I must release ASAP--WTF it’s been a month since last alpha!” period. It’s nice to have some semblance of milestone deadlines, even on an epic project with no real oversight :P

Now let’s take a look at how the changelog grew over time. Surprise!


Ordered Alpha 14 changelog, subdivided by development week. (click for full size)

Alpha 13 went out on January 17th, but I didn’t actually start on Alpha 14 until the 26th. It’s pretty normal to spend at least a week of time doing followup work from the previous alpha--compiling stats, watching how players interact with the new features, maybe writing a blog post or two, and certainly taking care of all the personal chores I no doubt neglected in the run up to a release :P. So technically this alpha was completed over a period of four weeks (half of which were spent out of country).

Look at that… two-thirds of the changelog was done in the final week?! One week!

Despite appearances, it was most certainly not two-thirds of the work. There are three major factors to consider here:

  • Some of these individual entries have a lot of work behind them, not represented here. (This compared to some that took mere minutes.) Especially during the first couple weeks I’ll work on bigger features, which as described before is because the required time for these can be more difficult to gauge, and therefore they have priority over the many tiny features that can be rapidly packed in one after another at the end. In particular you can see “NEW: Branch map ‘Deep Caves’” sitting there by its lonesome in week 2, next to a handful of other related entries. That was a ton of work--a whole new map that includes new mechanics, new robots, new events, new parts… but none of the details are broken down there. I don’t want to ruin the chance for players to make new discoveries, so while the public changelog for Alpha 14 is 126 lines, the internal version contains 207, part of that attributed to spoilers. (Of course the other part is simply elements that don’t concern the player.)
  • Some weeks I am actually busy with other non-changelog-related parts of development, like writing updates or articles, or for example during Week 3 when I had to take about a day and half out to work on and push the Greenlight submission. That particular week, as a result of all the other writing I was doing there was only a day and a half to work with the source code, much of which was allocated to the semi-major feature “High Security.”
  • Some weeks I simply devote more time to development. This is also more likely closer and closer to release, where I really hope to fit in a certain chunk of features (the “final cut” list is always made at the beginning of the fourth week, and I usually get through about 75% of it). I always aim for about 45 hours per week, though in this case Week 4 was somewhat extreme, as I ended up putting in 70 hours. So that had something to do with the lopsided changelog, too :P

Interestingly, despite the underrepresentation of major features I do believe that overall the final length of the changelog does kind of balance out with the amount of work that went into it.

I hope you enjoyed that--I certainly found it enlightening. I mean, I more or less knew this stuff, but it’s nice to punch in the numbers and and turn it all into pretty diagrams to visualize it :D

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

Adjustable Difficulty

Roguelikes are notoriously difficult. In this way they’re really no different from games of old, across numerous genres, which many players were far from guaranteed of completing. It’s only today that roguelikes have become more uniquely associated with difficulty because the market around them has changed so much!

There will always be an additional layer of inherent challenge to a game with content that changes from play to play, but while traditional roguelikes and their players continue to embrace that challenge, the wider games market has shifted along with player expectations. In short, as gaming has exploded to include a much larger group of consumers, consumers with different needs and capabilities, developers have sought to take those circumstances into account. (There is even a portion of players that believe they deserve access to every part of a game, as content they paid for!) Therefore these days it’s common practice for games to include multiple difficulty levels, with pressure to embrace such options as just another form of accessibility. This is especially true with respect to commercial games, which are reliant on sales to survive--more accessible games simply means more sales!

Being free, and niche, roguelikes have always been somewhat insulated from this trend--very few offer difficulty settings, not to mention the nature of their design and common mechanics (e.g. permadeath) make following that trend somewhat less meaningful. In some ways the point of a roguelike is to offer as many challenges as possible, and as long as it is theoretically possible to overcome those challenges then no one’s to complain, right?

That said, it’s probably not a coincidence that two widely popular roguelikes also offer multiple difficulties.

Tales of Maj’Eyal has five separate difficulty settings, one below normal and three above. From the creator, DarkGod:

“Difficulties were first added like six years ago or so. As for why, well first because I can! I made the engine robust enough that I can do them very easily. And most importantly because not all players have the same skill. I for once barely manage to win on normal with my preferred class while others find normal to be braindead. My goal has always been to give fun to as many people as possible and that follows along. Also to note that my difficulty levels are not simple number bumps (there are those too obviously), each level introduces new harder mechanics (like random bosses, being constantly hunted, …). To be fair I do not understand why devs do NOT put difficulty levels in their games heh ;)”

DoomRL also has five separate settings, distributed in the same way. From the creator, Kornel Kisielewicz:

“It raises the replayability of the game, allowing you to go more difficult once you feel that the game is getting to easy. Initially it was added just as a tribute to Doom, but it turned out to be a great feature, so I gave it a lot more thought later on.”

Interestingly, both developers emphasize settings as a way to increase the challenge level, an approach also reflected by the available options, wherein the default is towards the lower end of the scale.

ADOM also added more gameplay settings in recent years, some of which have an effect on difficulty.

Whether or not to implement difficulty levels, and the best approach to take, comes down to a question of who we’re balancing the game for, and what do we hope those players can experience? As a hardcore fan of roguelikes, I’ve always enjoyed that winning is not inevitable for everyone, even given years of play and practice. The thrill and excitement at each new degree of personal achievement has always felt like an integral part of the roguelike experience, and if “content” is attainable without a high level of skill then that experience is watered down.

Outside the roguelike realm I’ve noticed a trend of games stating up front that they are very challenging and aimed at the hardcore audience, which at least puts players in the right mindset from the beginning, asking themselves “hm, it’s meant to be hard--can I take this challenge?” before even starting. This trend became most apparent following the success of Dark Souls, interesting because the same mindset used to be simply assumed back when gaming was more niche: If you weren’t good enough, you may very well not see the whole game. That is certainly one option, to just make it clear that “the game is tough, good luck!” I would argue that if areas of the game most players can generally reach are still fun (and they should be!) and fully satisfying (that one’s a bit harder…) that’s the most important part, but times have changed. And expectations with them.

I’ve softened my own position on the matter as well, especially in the 21 months since releasing the first Cogmind alpha and listening to feedback from the community. I can now more clearly see the benefits of adding difficulty settings to a roguelike. But first, a little look at the drawbacks!


If there weren’t any negatives to allowing adjustable difficulty, lots more roguelikes would have them, right? :)

For brevity’s sake I’ll use a list:

  • Trivializing some aspects of the game by using an easier setting potentially results in a less rewarding long-term experience (mentioned before). While it’s possible to take on higher settings later, the player has already lost half of the reward: the initial discovery aspects associated with that achievement (e.g. what comes after).
  • Using easier difficulty modes may teach bad habits, or at least not teach good ones. Players using easier settings as a crutch are less frequently forced to improvise effective solutions to challenges. This is fine for those players who don’t want to improve, but might hinder others looking to learn the skills necessary to tackle at least the default mode.
  • Even though roguelikes are single-player games, multiple difficulty modes somewhat fragment the community. “You reached where?!” and “You did what?!” etc. no longer have quite the same meaning once there are easier difficulties at which the same content is available. Essentially not everyone is playing the same game anymore, and progress is no longer quite so instantly comparable. To me this is one of the bigger drawbacks, though it can at least be mitigated with a sufficiently large community in which there are plenty of players at each tier.

I don’t believe that any of these are conscious reasons behind the relative lack of difficulty settings in roguelikes, though. When it comes to development effort, game design and balance are delicate things, and making changes to systems to accommodate difficulty levels can have negative consequences for the overall experience. It’s not just about difficulty, as the whole “feel” can change as a result. Adjusting certain aspects of a mechanic could have a cascade of unbalancing effects on others, especially in roguelike worlds featuring grand scope and numerous interconnected systems. Not that this can’t be overcome, it just takes longer to get right. And dev time spent accommodating different player needs is unfortunately very much not in the roguelike tradition. (Further compounding the issue is the fact that roguelikes often continue to evolve and are never quite complete--changes and new features have to take into account the potential effects across multiple difficulty settings, and creating a roguelike already requires so much work to begin with! If anything, at least the fuzziness of the RNG can help soften some of the impact of working across multiple difficulties.)

Anyway, while I didn’t go into details there are pretty strong arguments against most of what I’ve written above with regard to drawbacks, so… yeah :)

But Benefits!

The benefits of difficulty settings are more straightforward:

  • It’s nice to be able to cater to different types of players (especially as a single-player game where we don’t have to concern ourselves with multiplayer balance issues). We do it with UI options, so why not with difficulty?
  • Some players learn better in a low-pressure environment, at least when it comes to basics.

Straight from Cogmind’s new manual section on Difficulty:

“By default Cogmind has been carefully balanced to provide a fun yet challenging roguelike experience that can be reliably overcome given sufficient experience and skill. That said, some players simply don’t have the time or inclination to strive for mastery, thus alternative modes are available that tweak multiple aspects of the game to make survival somewhat easier.”


About that difficulty…

Hence the number on reason difficulty settings are important: People have less time in general these days as the pace of life has picked up, and there are so many more games than there used to be. On average, players used to acquire new games less frequently, and play the same ones longer, which also meant it was more likely to reach those difficult areas as skill improved over time. (The average gamer was also a lot younger with more free time :P)

The Baseline

Notice that most of what I’ve discussed so far is in terms of easier difficulties. This is due to how I’m approaching the whole idea of these settings.

I believe that the default mode itself should be quite challenging, even for experienced players. In that sense Cogmind is different from other roguelikes such as DCSS or ADOM, where once players are familiar enough with the mechanics, content, and strategies, beyond the early game a new run is often just a case of going through the motions to win. Instead, difficulty should ramp up towards the end, not down. (This in itself is a topic I want to cover in more detail in a future article.)

And regarding the distribution of player skill--or rather visualized as which sections of the game different players are likely capable of reaching, I feel a bell curve is appropriate:


Cogmind player skill distribution: This is an idealized curve, though the actual curve based on reported score data actually looks more or less like this.

Thus assuming the normal difficulty, probably half of players will likely struggle to best the mid-game. While that’s the end result, the true target of (most) well-designed roguelikes should be focused on being winnable nearly 100% of the time by an experienced and skilled player. Remember this does not equate with everyone actually being able to win--some people have gone decades playing, and enjoying, the same roguelike without ever actually winning!

Still, I’ve decided that we need these settings so let’s get into the details of what that actually means.

“Easier Modes”

Cogmind has three difficulty settings: the default, an easier mode, and an even easier mode. I prefer to call them “easier” modes as opposed to “easy” because they are purely relative to the default difficulty, and may very well still be difficult for certain players! (I admit this is somewhat pedantic given everyone’s clear understanding of video game difficulties :P)


Setting Cogmind’s difficulty in the options menu.

The mode can be changed via the options menu, and does not take effect until the next run. I.e. switching to another difficulty mid-run is not allowed. This is for score sheet consistency, so it’s possible to clearly define a run as belonging to one mode or another. Because obviously we’ll want to keep runs separate on the new leaderboards:


Leaderboards 2.0 testing, divided by difficulty setting.

Players appear only on the board of the mode for which they most recently submitted a run (older runs are of course remembered for those who switch back and forth). It will be pretty interesting to see what kind of distribution we end up with starting with the next release!

As for the meaning of these modes, adjustments go beyond simple changes in number values, because numbers alone wouldn’t be enough to make the game easier while retaining some semblance of balance and fun.

Easier Mode: The purpose of this mode is to retain most of the challenge and content of the default, still requiring a fair amount of experience and persistence to win, though not quite as demanding as the default mode. It is more for those who would still want to improve and hope to tackle the default mode later.

  • 20% base resistance to all damage types
  • +5% base accuracy (both ranged and melee)
  • Effect of allies on alert level halved
  • Disabling machines has less of an impact on alert level
  • Traveling to a new area/map lowers alert level more than usual

As you can see, much of this is aimed at reducing the influence of alert level, which presents one of the larger long-term dangers to players who are frequently in combat. And the free damage reduction will somewhat slow the rate of item attrition, the other major factor contributing to Cogmind’s downfall.

Easiest Mode: This mode is quite easy, generally too easy, though yes it’s still possible to lose, and especially certain areas of the world are going to be pretty dangerous! That said, it will be easier to avoid them with minimal experience since the destination of every exit is automatically known in advance. It basically suits those looking for pure entertainment or those without much free time.

  • 35% base resistance to all damage types
  • +5% base accuracy (both ranged and melee)
  • Effect of allies on alert level cut to one-third
  • Disabling machines has a much lower impact on alert level
  • Traveling to a new area/map lowers alert level much more than usual
  • Lower chance of random hostile encounters (most notably in mines/caves)
  • Hostile branch encounters (e.g. in caves/mines) cannot appear directly in spawn area
  • -1 to all patrol squad sizes (stacks with garrison effect)
  • -1 to number of garrisons per floor (cannot reduce to 0, however)
  • Exit destinations automatically revealed on sight
  • Evolve 1 extra slot on exiting scrapyard
  • Scrapyard contains random useful utilities
  • Items nearby your spawn in main complex maps replaced by random items more likely to be useful given your current state

All effects are subject to change, but as is there are too many variables and I’m not the target for these features (unlike the default mode!), so to determine how effective they are I’ll have to rely on outside feedback from those who actually need and/or want these modes.

I’ve added a tutorial message that shows after the player’s 5th death (if they are still using the default mode), to let them know there are easier modes if that’s their thing.

For those already using other modes, I’ve added a number of indicators to help both themselves and other players distinguish the setting. First of all, score sheets are now clearly topped with a different header for each mode:


Score sheet headers by difficulty.

And to help players posting and looking at screenshots discern which mode is being used (it would get really annoying to have to say/ask every time!), the two primary views we’ll see images of now also have highlight color changes to reflect the mode.


Game over screen, now in three variations.



HUD parts list, with a very subtle divider color change (to avoid having a significant impact on the aesthetics).

Hard Mode?

Interestingly, often times when I’ve brought up the idea of difficulty levels someone will ask if there will be harder modes. The fact that this is asked with regularity, despite many players barely being able to survive through the first half of the game, again reflects how valuable varying difficulty levels can be!

For the reason mentioned before--default roguelike mode should be hard--I don’t currently plan to add an explicitly across-the-board harder mode. Instead I’ve taken other approaches to the idea of even more challenging options for experts.

Structurally speaking, the world already has more difficult optional routes and challenges built into it. Some of these are not even known to non-expert players, but are possibilities gradually discovered over time while uncovering more of the lore and NPC encounters. Some involve plot events, and others involve visiting certain areas in a certain order, taking advantage of the non-linear structure of the world to create a multitude of options. Even close to the surface, there are “extended end game” options for the brave or well-equipped.

On another level, strategy-wise winning with different builds also provides its own challenges (akin to winning other roguelikes with a different race or class), some of which are much more difficult than others.

Also falling under the “hard mode” end of the difficulty spectrum, as of the next release Cogmind includes a new framework for “Challenge Modes.” In a sense, these are essentially what are called “conducts” in roguelike tradition, playing the base game albeit while applying some additional rule or rules. Here, however, they are formalized rather than player-enforced.

These rules are more interesting than outright making the game more difficult by changing numbers around, because all the latter suggests is that the player is aiming for highly efficient/optimized play (plus maybe some luck), whereas challenge modes actually fundamentally change the way the game is played! Much more interesting :)

So far I’ve implemented two such modes, mainly as a test, with many more to come, I’m sure. The first is named “Unstable Evolution,” where you no longer have control over which slots you evolve--they are selected at random.


Random slots chosen due to UNSTABLE status shown in the log.



Examples of random slot evolution from beginning to end.

The first there actually looks to be a fairly normal composition, although of course the order could be odd--not evolving what you need when you need it, forcing you to adapt; the second is kinda crazy due to that large number of power slots! This mode should lead to some interesting runs, and enable more types of replayability. (Note that selection is weighted towards what players most often want--e.g. not a ton of power slots, so it’s not necessarily that terrible, but you could get unlucky and have to deal with it… Adapt or die, such is evolution!)

The other new mode is named “Scavenger,” wherein there are no part stockpiles and any solo randomly available items are damaged--everything else must be taken from other robots, or stolen from haulers! (Fabrication would be another option, but that has its own limits.)


A sample of the kind of junk one would find lying around the Factory in Scavenger mode.

You earn points for each challenge applied, and can pick more than one (unless one or more are for some reason incompatible with each other).


Active Challenge Modes listed in a section of the final score sheet.



Score History with a new column for difficulty and any active Challenge Modes appended to the end.

With only two modes, for now they are activated directly in the config file, but a new submenu will be added to the in-game options menu once there are enough of them to establish how that submenu will function. There is a forum thread where anyone can drop Challenge Mode suggestions/ideas that I can draw from later.

“Achievements” (as in Steam achievements, but I would want to implement them for non-Steam players as well) will also be a thing, and are similar in nature to difficulty modes, providing alternative goals that might be challenging or just fun. There’s a forum thread to drop those, too :D

Posted in Design | Tagged , , | 10 Responses