Development Blog

Recently a player asked me a question regarding my game balance philosophy, and while I can often respond to queries by pointing to some previous article, despite all my writing and no doubt occasionally touching on related topics, I had yet to explicitly do any sort of summary of the philosophy behind my gamedev work.

Now I’m sure this won’t be a comprehensive summary, mainly since it’s harder for me to quickly step back and reflect enough on the bigger picture to think of every meaningful element in the time it takes to write this article. Normally I’d collect notes for an article like this over a longer period, then eventually get around to writing it out one day, but since this topic comes on shorter notice and I just want to get it out there, let’s just go with what I can come up with for now.

Note this article refers to design of a game itself, rather than the complete gamedev process, which is a pretty different topic altogether. (I sorta covered high-level process before, albeit more in a technical sense than a philosophical one, in an early article on Cogmind’s alpha release cycle. Note that since that time Cogmind development has entered a couple different cycles, so while I once used that approach, the process has since evolved to fit different circumstances.)

And of course the context (plus any examples) for this discussion will obviously lean heavily on Cogmind, since that’s currently my main project, although as a fairly general philosophy the same factors could be applied to many games.

Let’s just dive right in, dissecting my gamedev philosophy as it pertains to a range of topics…

Vision

I’m a strong believer in starting out by crafting a clear vision for what kind of game and world you want to build, and sticking to that vision throughout development. A well-developed vision serves as both a driving force on the way to a complete game, as well as an anchor that limits expansion in tangential directions that could otherwise jeopardize cohesiveness of the experience.

In its earliest form, Cogmind’s premise as a 7DRL was pretty simple: You’re a robot building yourself from scratch using parts found and taken from other robots, with rampant item destruction so you’re forced to rebuild pretty often. That’s just the core mechanic, and about the smallest vision you can have (which is actually what I recommend when starting to build a roguelike), though even then my vision included an immersive interface and using sensor data to help navigate a living world occupied by both hostile and non-hostile robots.

Cogmind 7DRL! (2012)

The potential scope for a 7DRL naturally has its limitations, and while my vision for the commercial version of Cogmind didn’t make any significant changes to the original, it was however greatly expanded as evidenced by the 7DRL’s one-page design doc ballooning into a hefty doc describing a world of more varied locations, interactive machines, NPCs and “robot life.”

And yet amidst all of this the player is not the center of attention--sure there’s a lot going on in the world, but in most cases you can even simply try to be a spectator. That I keep revisiting this aspect whenever I add new content shows that it is indeed an ingrained part of the vision. For example, DSFs are a new type of map added in Beta 11, and as with most other locations you can happen across unexpected events which have nothing to do with you at all, just inhabitants of the world driven by their respective history, relations, and goals.

So this is along the lines of what one would expect to find inside a little DSF, but the player isn’t the only one who might find their way inside…

Many times throughout development, sticking to a vision also means having to resist the urge to add certain features/content that might seem cool, either to yourself or players. There’s never a shortage of tempting ideas and feature requests out there!

Sometimes you might be able to edge an unlikely one into the game, maybe there’s some creative way to do it, or preserve the concept in some other way, but never at the expense of compromising on vision (or really many other parts of the philosophy we’ll be covering here!).

Difficulty

I want my games to be challenging but fair. Challenging in that it takes a decent enough understanding of the game’s mechanics and content in order to build the necessary grasp on effective strategy and tactics to sometimes win; fair in that a player with an excellent understanding of those aspects should pretty much always win, as long as they’re not intentionally attempting something dangerous or even more challenging.

In a mature player base, the natural result of this approach is more or less a bell curve.

I posted this curve back in my difficulty article, saying that it’s just an illustration, but the actual curve based on player score data actually looks more or less like this.

Of course not everyone has the time or inclination to develop the skills necessary to improve or explore at their preferred rate, so although I always design Cogmind around the intended challenge level, the “Rogue” difficulty, I eventually added two other difficulty settings, one a little easier for those who want to retain most but not all of the challenge (“Adventurer”), and another which is much easier and literally dubbed “Explorer” for those mostly just wanting to explore the world rather than seeking tough challenges.

This is one area that reflects an evolution in my design philosophy, since based on my personal preference the idea was originally to have only one way to play, as with all classic roguelikes. It certainly makes some sense that in a genre known for its challenges, everyone should ideally be playing the “same game” to maintain matching expectations and reference points during community discussion/sharing/bragging :P

But as described here on the blog when I first introduced difficulty modes (see there for much more discussion), in the modern age of roguelikes, including some of the most popular ones, we do now see examples of adjustable difficulty.

In my experience (and I’m very active within the community), accommodating more players like this hasn’t really had any major negative side effects. (Well I do recall there was that one negative Steam reviewer who went off the rails about how roguelikes should not have difficulty levels because how are you supposed to know which it was designed and balanced for, but they apparently didn’t read the one-line description of the Rogue difficulty on the selection screen, which literally says it’s the mode the game was designed for xD)

The majority of players do still play the mode Cogmind is designed around (in some cases later switching to it after gaining experience in other modes first).

More players have been using easier difficulty settings since the pre-game menu was added, but still appear to make up a minority of the player base.

Cogmind’s easier modes are also more than just number changes--there are extra mechanics and features aimed at tweaking the experience for players via tangible strategic and tactical benefits, for example highlighting the positions of hostiles that have become aware of your position.

This feature was originally added for everyone, but is really too advantageous for the player in normal play and therefore removed from Rogue mode in particular.

Back to the idea of fairness, it’s worth highlighting some of the important elements that contribute to maintaining it, especially in a RNG-heavy genre like roguelikes.

One of the most important is the need to telegraph or signpost major challenges so the player can make a semi-informed choice about the dangers of something even on first encountering it. With individual enemies this is often easier, since you can at least always examine their details to see how powerful they are, but it’s also important on a macro level, like what parts of a map might be more dangerous (bigger doors to access it?) or what maps are more dangerous in the first place (special defenses around the entrance? or just a menacing or suggestive name :P).

These signposts can range from subtle to explicit, depending on the danger level and, more importantly, how unexpected the results might be given a general understanding of the world order.

The new Heavy class added in Beta 11 makes quite a point of signposting itself because of their extreme effects on the local area.

For example, integrating with the Exiles’ FarCom system gives some pretty nice benefits in most areas of the world, but when you do so there is a huge drawback they warn you about, and the consequences are so harsh (but sometimes forgotten by the time they might come into play) that in Beta 11 a second reminder was added lest forgetting that little detail simply end the run.

“Instadeaths” are an unfortunate possibility not always easy to avoid in many roguelike designs, though interestingly in Cogmind’s case the player has so much “HP” that death is naturally a protracted affair rather than a potentially sudden or even quick chain of events. While on some levels this can be a frustrating experience, the chance for comebacks is also very high, especially among skilled players, and pulling one off feels very rewarding.

It’s important to give the player tools to recover from mistakes or unexpected events, a role most roguelikes fill with consumables or escape abilities. Beyond being able to swap in more and more parts to block hits and deal with (or avoid) threats, Cogmind uses a fairly unique approach by being able to 1) take a huge beating, and 2) outrun most enemies once reduced to a naked core.

Instantly “purging” all attached components and making a run for it, to survive and rebuild another day.

Players new to Cogmind tend to have trouble quickly realizing the implications of such mechanics in order to take maximum advantage of them, but it’s fun watching new players think they’re pretty much dead, then get lucky after being reduced to scrap and end up rebuilding right back up again. Eventually with enough experience the luck component of rebuilding can be significantly reduced (in fact, last year one of Cogmind’s top players streamed a run in which they intentionally nuked their own build to repeatedly rebuild from scratch on every new floor, and still made it to the final floor regardless).

Giving players ways to control their own difficulty during the run is also useful for contributing to its fairness, as well as making it feel more fair, too, in the sense of “well it was my choice to take on that more challenging area…” For this purpose many roguelikes have optional areas, be they branches with a different risk-reward profile, or an “extended game.” Cogmind has both of these, as well as numerous win types with varying conditions.

On a similarly macro level, branching paths with multiple segments also include intermittent ways to return to the main areas of the world (to recover health and return to what are generally easier/safer locations) rather than continuing onward, allowing players the option to back out early after reevaluating their situation and goals rather than feeling trapped.

Cogmind’s world map as seen in my yEd graph (initially shared in my Cogmind dev tools article), albeit with branches distorted and some locations completely removed to keep the spoiler level low. You can still see how there are paths from individual branch maps that cut out early to return to the main areas.

Not surprisingly, the base difficulty of Cogmind has fluctuated over the years as more and more content is added, sometimes leaning to the harder side, other times easier, so there is always a need to revisit and adjust the overall balance to keep it within my target range. Most recently, Beta 11 swung it back towards higher difficulty, after quite a number of releases that originally pulled it in the opposite direction. (Update: More recently in 2025 I wrote another article on Designing for Mastery which covers a lot of relevant topics as well.)

Balance

Good balance is of course another important contributing factor of fairness. Not all games (especially single player games) have to strive for balance, but for me it’s absolutely vital. Among the many other benefits of balance, it provides a clearer frame of reference when designing new features, and players in turn have an easier time establishing their own frame of reference for putting together builds and strategies.

Numerical balance is a good place to start, as I did way back with Cogmind 7DRL and wrote about here on the blog before, and more recently with the full Beta 11 rebalance. But a game’s balance also needs to aim for the right feel, regardless of the numbers. It doesn’t matter if some mechanic is technically balanced if it doesn’t also feel balanced to players.

Any balanced game of sufficient complexity is going to be backed by lots of spresheets!

This can be an especially thorny issue with roguelikes (or any RNG-reliant game, really) in which percentages are often known but results don’t necessarily align with individual player expectations, even if statistically correct.

This reminds me of the machine hacking results which caught a lot of flak from players over the years (and always seemed odd to me as well, to be honest), enough so that I eventually gave it a different kind of custom-built PRNG, and complaints have since stopped. Amazing! (The results aren’t as randomly distributed now, but it’s random enough and feels better, and that’s what’s important.)

When we’re dealing with something as arbitrary as “game feel,” listening to player feedback is going to be important, though even more important here is the indirect feedback, i.e. simply reading about player experiences and preferences (or watching them, in the case of streams).

I take a lot of this into account while working on updates and designing future features, and it’s especially relevant for all the times individuals might claim item/mechanic X is terrible or useless. Many players pass judgement based on their own limited experiences and/or personal preferences and biases, but as long as we can see that item/mechanic X is useful to and/or enjoyed by some other types of players, then it’s likely serving its purpose.

So numbers aside, we also have to take play style into account with regard to balance, and content and mechanics that spark debate between players is a good thing. Usually it’s just enough to watch players hash these things out themselves, although sometimes I’ll want to explicitly join in on or bring up some topic for discussion (this was a big part of the final Beta 11 rebalancing, which I also streamed in order to discuss with everyone--videos in that article).

Now “balance” doesn’t have to mean everything is directly comparable to everything else on an equal playing field. Context is important. There are many ways to balance an item/mechanic, including even methods completely outside the object itself! (Okay from here on when I write “item” it means “item/mechanic,” because they’re often interchangeable given that most of Cogmind’s mechanics are based around items :P)

Obviously we have our core set of items which are numerically balanced, essentially directly comparable and found all over the place. Then there are those which are tweaked to emphasize one characteristic over another, for example extra power at a greater resource cost. To keep things interesting while remaining balanced we essentially apply more and more significant tradeoffs--bigger benefits for bigger drawbacks, all the way up to the crazy level if we want to. This is the space that Cogmind is exploring more and more of as time goes on with a stable and balanced foundation already serving as the core.

The Active Sensor Suite added in Beta 11, occupies a whole three slots on its own, more than any other sensor, but also also has multiple powerful functions, but also eventually alerts enemies to your position.

To give us more leeway in terms of making interesting items, external balancing factors are the most interesting, but also the most demanding in a development sense. Some items can be outright better with few to no tradeoffs if, for example, they are simply more rare, or difficult to acquire. There are some items which are insanely powerful, but can also be very difficult to acquire. The “difficult to acquire” part is what adds development pressure, since it’s no longer purely about the item’s own design and implies the need to also design and build whatever is making it hard to reach in the first place.

At the same time, it’s also pretty cool that due to Cogmind’s built-in “ultimate balancing factor”--the fact that most items are destroyed eventually, we have a somewhat easier time balancing (and therefore including in the first place!) what would otherwise be a lot of overpowered items. The heavy reliance on this factor becomes incredibly obvious in the RPGLIKE special mode, which all but removes attrition and is much easier as a result, especially once you acquire powerful unique items which then carry you :P

While Cogmind includes several item repair mechanics, by necessity these types of unique or powerful items generally cannot be repaired (though they can be better protected through various means!). As a new player it’s easy to initially be shocked at the amount of item attrition in Cogmind, but this very element makes possible a lot of Cogmind’s fun mechanics, and many players come to realize this and embrace it, as well as learn how to mitigate that attrition through a better understanding of the mechanics, and simply better tactics.

Technically if we were to teach players actual strategy in the game itself, it would certainly help retain those who can’t figure it out themselves, and I’ve considered this possibility since early development, but continue to feel that sort of information is better served by sources outside the game (community, guides, etc.) and doesn’t really belong inside a roguelike, especially an immersive one about discovery.

Criteria

Content isn’t added just for the heck of it, or even filtered purely based on balance considerations, as there are various other criteria to satisfy as well.

First of all there has to be enough design space to sufficiently flesh out a piece of content, and once fleshed out it can’t interfere with other features.

With Cogmind an unfortunate example of this is the much desired environmental-type effects found in some other roguelikes, like fire, gases, or anything other kind of temporary state which can occupy a cell or area. Even my original Cogmind 7DRL design docs listed this potential, but it’s not very compatible with the type of game that is Cogmind, especially in its since-expanded form.

One of the issues is simply a case of presentation. With only three components of information available in a given map cell--character, foreground color, and background color, we don’t have enough room to also comfortably display persistent effects like this. The most likely candidate for showing this sort of effect is of course background color, but we already use that for other sorts of temporary information, especially at the interface layer. Maybe environmental features could be included if they were an occasional thing that only affected a small area for a shorter time, but that goes against the principle of aiming for fleshed-out features.

Either way, having something like this also shifts the design away from its core focus on robots and items (and to a lesser extent, machines), while adding a lot of potential clutter to the UI, especially once taken to its natural conclusion of being a full feature complete with raging fires, billowing smoke, waves of radiation, and whatnot.

I do really love me a good spreading fire and FOV-obscuring smoke, though… (Taken from X@COM, this particular old recording doesn’t really show off the environmental effects so well since it was intended to demonstrate blaster bombs instead of incendiaries, and doesn’t leave much to burn, but some effects are clearly apparent there :D)

Focus on as few core areas as possible, and do them well!

At the same time we ideally want any new content to hook into as many other existing elements as feasible (taking into account design, architecture, and development effort), lest they feel out of place. The more interconnected the world, the more natural it feels (and therefore less gamey and more immersive).

One of many examples here are Fabricators, which in a game sense exist most fundamentally to allow the player to build things, but these machines can also:

• produce robots and items for the enemy, the former of which will head off to join the nearest Garrison, and the latter are scheduled to be picked up by a Hauler
• have their own scheduled builds intercepted or modified by the player
• be hacked for various other purposes (in one case even as an attack vector)

There are currently still some “feature stubs” present in Cogmind, very early pre-alpha experiments which were never removed, but also never expanded, perhaps in the hope they will one day become “a thing.”

One of these is implemented and working despite never even having have any associated content: the ability to require components when building something at a Fabricator. Eventually I should decide whether and where to use this, but it’s the kind of thing where at this point if it were used, it likely would not be very fleshed out, and seem like an odd outlying sort of feature, so for that reason I’m not really eager to take advantage of it…

Currently I think this one in particular only has a reference in the gallery data exports and schematic Fabrication data readout, though technically should be hidden from there for now, too.

This entry simply indicates “None” for all schematics.

Another situation that falls under this category and should ideally be removed or modified (or expanded?) is the handful of items with “internal batteries” of limited use, which take effect when dropped on the ground. It feels like an outlier type of mechanic.

All in all, “non-part items,” as in items that cannot be attached as usable equipment, were a mostly experimental feature not present in the original design, so one day revisiting them to consolidate their behavior would make a lot of sense based on the way I normally approach feature design as described here.

But therein lies another principle: When considering changes, avoid quick reactive decisions and prefer to wait for a sort of “critical mass” before making a move. Quick decisions lead to mistakes, which in succession will compound on one another and just create a mess. So I keep a lot of notes about various topics and plans (a lot of notes), and revisit them for additional updates from time to time, waiting until I feel like I have a strong enough grasp of the potential consequences of such a change (or new feature, for that matter) in order to implement it with confidence that it’ll have the desired effects and is the best option available.

Specific to the non-part items, I can see that I’m still kind of shaping their role and breadth in the game, so doing anything with them too early would be a problem in that it’s still too hard to tell what exactly should be done with them, if anything. So yeah, this is basically a little ongoing experiment, which is okay in a game that’s still in constant development anyway :P

In the end, consistency is important, both in terms of world building but also just generally in terms of mechanics. Concepts that sound cool but also likely break implied rules or otherwise introduce inconsistencies are usually best avoided. Wiki-heavy “kitchen sink” games (and roguelikes in particular) are definitely a subgenre enjoyed by some, though that’s clearly not my style. Maintaining internal logic is important and useful for easier player understanding, while also meeting expectations.

In that sense, expectations are a powerful driver, and limiter, on development. I’m frequently asking myself what players will expect, or even hope, in a given situation, and factoring that into plans.

At a basic level, this implies the usefulness of rooting a game in realism, and that is without a doubt a good starting point since many players share that common ground and make assumptions based upon it. The better a job one does at world building, however, the more you can get away with features that otherwise break with that realism since they at least hopefully make sense in context.

As far as player “hopes” are concerned, we know that players exploring content will always be asking “can I do that? / what happens if I do this?”, and it’s really nice to be able to accommodate those possibilities when feasible (always with the “when feasible…” :P). As the developer, I should ideally have a better understanding, and also ultimately some control over, what kinds of questions players will be asking as they interact with the world. So if I feel that some feature will create too many questions without answers, or without good answers, that’s a clue that it might not be developed well enough to include in the game.

The ability to enter Garrisons as a separate map was a direct result of me assuming players would want to be able to explore inside if possible, and it was only after that point that I even started coming up with what would actually be in there :P (eventually the interior continued expanding a couple times with new features, with another update due in Beta 12/the next release)

Long-term GaaS dev (which really defines most traditional roguelikes, including Cogmind, but without the monetization aspect--most of us just do it for free, or essentially at a huge discount xD) also means that you can spend a lot of time observing what players are actually talking about, and react to that through further tweaks, or take it into account for future features and direction. Again it’s usually better to observe this sort of thing via player discussions rather than pay quite as much attention to direct feedback, since the former tends to be more telling. You also get a greater sample size by seeing multiple people discuss a topic, which is important for an RNG-based procgen game with many different encounters and play styles.

Density

“Content density,” or essentially the amount of possibilities in a given area (usually defined as a map) doesn’t need to remain entirely consistent throughout the game. In fact it’s kinda nice to have some areas that are simpler, and therefore more predictable (good for planning!), and others which have a wide variety of possibilities (good for surprises!).

Because it’s much easier to develop “micro content” (like items and mechanics) than “macro content” (maps and factions), I’m always saving up a lot of ideas belonging to the former category to help populate the latter once they’re finally added over time. This will result in a better moderated experience than if I were to give in to the desire to completely pack the current areas with even more items. It also gives me a decent-sized pool from which to select concepts which will best work for a new area, rather than trying to come up with completely fresh ideas on the fly. I generally prefer to let concepts stew for a long while before actually using them (though on occasion I do suddenly add a pretty outlandish idea for fun--see Throwing Claymores :D).

With the next releases it’s finally time to start adding more involved new maps and factions, so I’ll be happy to draw from all these other mechanical possibilities. I’m sure the United Federation of Derelicts should and will have some unique offerings ;)

Lore

Lore is typically an overlooked potential component of roguelikes, but I really like telling stories and infusing that process throughout the experience, something which can definitely be done with the right approach (a topic already covered in the Weaving Narratives into Procedural Worlds series).

As it pertains to design philosophy, lore is more than just a story though, it’s the background which can be used to glue everything together. So like the earlier mention of creating connections between systems on a technical gameplay level, lore can have the same effect on a different level, explaining how and why certain things are the way they are, so that it all makes sense and is connected in yet more ways.

At first Cogmind’s lore was told purely through terminal entries, since that was the only medium available. (Note: I decided to forgo item descriptions for this purpose, since they would actually reduce the type of immersion I’m going for, and instead some item descriptions appear in terminal entries instead.) Later once branches, events, and NPCs were added, an increasing amount of the lore came from those sources, eventually overtaking terminals.

Rule #1 of lore: Never give players all the lore.

This helps create a sense of wonder by leaving room for interpretation and imagination. Exhaustively answering every single question, explaining every link and detail, is overkill, not to mention probably involves a ton of reading! We’re mostly playing a game, not reading a book, so I feel it’s more appropriate to offer little bits here and there, just the right amount of information on which to build a decent framework of the world and what’s happening there.

Cogmind’s lore collection interface, for conveniently referencing all the important lore encountered across all runs, here in a recording made when it was under construction so that’s just a bunch of placeholder text.

Going about this correctly does involve writing more of the lore than is actually provided in game, then strategically selecting what to share from that, like at least most of the major parts, but players are really good at coming up with their own ideas to understand unexplained bits at the edges, or filling in cracks. Players also have fun sharing their fan theories, and I’ve had a lot of fun reading them, too--heck, some are cool enough to become canon if necessary at some point ;)

Leaving pieces of the world and its background vague or incomplete has another useful advantage: flexibility with regard to future content. Since not everything is clearly set in stone and more than one interpretation can apply, new content is less likely to be irreconcilable with old content, meaning less of a need for annoying retcons (which can be costly or even impossible in gamedev due to the potential cost of changing chunks of content or even how certain things work).

And that’s it, no more lore rules for today :P

Tedium

Tedium is bad. Must stamp out!

“Optimal tedium” is a common topic of discussion in roguelike communities, unsurprising as some top players attempt to eke every iota of advantage out of any mechanic that will allow them a 0.01% better chance to succeed. The issue is particularly acute in granular turn-based systems (e.g. most roguelikes), since reaction times don’t play a role and everything can be calculated out to give an idea of the relative chances involved. While I’m not really concerned with the 0.01% (or even 0.1%) categories, there is definitely a threshold beyond which tedium would become really noticeable with lots of people willing to do it, and a drag on enjoying the experience.

To be clear, by tedium I mean for example going out of one’s way to spend lots of time doing something that isn’t particularly fun or strategically interesting, or otherwise excessively repetitive boring actions.

I try hard to preemptively avoid designs that will result in tedium, and although as a player I’m not quite that sort of optimizer myself, I can usually spot areas certain others would try to take advantage of, especially after years of “training” watching the player base do their thing… Yay for long-term open development ;)

Of course I can’t always catch all these possibilities in advance, especially in a sufficiently complex game world with so many interconnected systems. Emergence is both a boon and curse! As usual the answer is to just keep an eye out for what players are doing, take notes, and be open to tweaking designs if necessary.

Minimizing optimal tedium is basically saving players from themselves, always a noble goal in my book.

Exploits

There’s saving players from themselves, and then there’s saving the design from players…

Players are incredibly creative, and there are a lot more of them than developers, so exploits are inevitable. But there’s a fuzzy line between an exploit and strategy… what really classifies as an exploit? My attempt at a definition: An exploit is an unintended interaction that circumvents one or more challenges in a very easy way and (probably the most important factor for me) is reliably repeatable.

Navigating a procedural world, “riding the RNG” to make the best of situations as they present themselves, is a great part of roguelikes (one that Cogmind happens to take to its extreme by also making your build and abilities more amorphous), while having a guaranteed or almost guaranteed way to significantly reduce the difficulty upsets the balanced experiences I want to craft. This is an especially big deal in a large game, where one piece becoming unbalanced can have more and more ripple effects in the long term as systems expand and more are added.

Note that preventing exploits is not meant to place heavy restrictions on strategies--there should already be plenty of those freely available and intended in the design itself; and it also doesn’t prohibit the possibility of the player gaining access to extremely effective means to accomplish some goal--becoming OP is fine as long as the design and balance takes it into account!

It’s also worth emphasizing here that again the line is somewhat fuzzy--some players assume I will “nerf” some tactic they think might be so effective it seems like an exploit, but then I don’t because I feel it falls enough on the strategy side of things. But usually players have a similar understanding as myself when it comes to exploits that need to be removed, and even request that I do something about them (because the players, too, are generally looking for fair challenges and hope to be saved from the temptation to play in an unfun but effective manner!).

Interestingly there’s also another category here, of tactics which aren’t all that tedious but do circumvent the design, the “true cheese,” which to me still harms the experience so I’ll remove that if and when I find out about it (though in some cases players might try to hide certain such strategies from me :P).

Some players are even helpful enough to take screenshots and/or produce and share diagrams to describe their specific strategies, which I can reference when considering changes :D

It can be hard to keep up, though, primarily because some of these are really hard to combat* and require an outsized amount of dev time to address, so I maintain a list of potential cheese to deal with, and just keep an eye on those which are otherwise hard to remove to see how frequent such a factor really comes into play across most runs, and how many people are trying to use it. Prevalent or obviously egregious cheese is removed pretty fast, but anything rarely used which would also require devoting a lot of time to work out sits on the TODO list and waits…

*The word “combat” above reflects an interesting dynamic when it comes to long-term gamedev, in that this facet of development really can be framed as player vs. dev, escalating with each new feature, update, or even sometimes new blood in the community.

It also really helps that I play a decent amount of my own game, which is important especially for solo devs to maintain a good direct feel for the true player end of the experience. I’ve found a few exploitable aspects that way, though mechanical tweaks are a more frequent result of my runs.

Interface

Now I’m not going to cover a whole bunch of interface-related concerns here, but there are a couple which are absolutely vital to my philosophy.

For one, gameplay features always take a back seat to UI/UX concerns. Feature X might sound awesome, but if including it requires the player to learn yet another new type of UI interaction, or anything too slow or complicated, then it’s very unlikely to happen. Ideally simple UI interactions are able to power numerous types of behavior, and can also be expanded to support more in the future (this is one reason radial context menus became more common in games, because they’re an easy way to achieve this goal).

As an example, Cogmind’s ability to toggle items between active/inactive states also included the ability to cycle to a third “overloaded” state for certain weapons and airborne propulsion in its first alpha release. Throughout future versions, that functionality was extended to other types of items in order to unlock secondary active states in which those items have different capabilities, all without creating some new interface for doing that.

Various parts reusing the state toggle cycling feature to enable different functionality.

Using all the same commands that normally toggle an item, it’s very easy to access these features, which can still be unique to each item, and they’re right there on the interface, as usual--no need to open new menus or windows, no need to press some other types of keys.

Imposing limitations like this naturally becomes a bit of an issue later on when you want to add new features, but to me the best approach is to focus on designing new features that fit within the current UI framework, rather than expanding the game with more interactions. Repeated expansion of the UI to serve new content leads to more and more edge cases and special exceptions, threatening to make the barrier to entry for a game that much harder. Sure all the older players who’ve been keeping up might be okay with it, especially if it enables cool new features, right? But we gotta also consider the many new players who may want to join, and there are still hopefully plenty of neat features that fit into the existing UI framework anyway, so build those!

New UI features might occasionally be called for if really worth it because they’re easy to learn and have wide potential applicability, but as with all things in development, there needs to be a serious analysis of cost (in player understanding and convenience) vs. benefit (cool stuff!!!).

Another Cogmind example of getting more use out of an existing UI function is the ‘<‘ key (equivalent to left-clicking on yourself). It was initially only used to leave a map while standing on an exit, then later expanded to include interacting with a trap at your position. Then even later, this became a new way to interact with certain items on the ground, either as a property of the item itself, or enabled by a piece of equipment.

Because only one object (exit OR trap OR item and so on) can occupy a location at a time and there is no ambiguity with regard to what this simple input is referring to, it’s an easy and consistent way to allow for more item interactions. In recent years I’ve used this to add features like releasing drones from a bay, turning engines into proximity mines, and setting timed charges. This approach plays into Cogmind’s item-centric UI paradigm very well.

Sapper Charges aren’t easy to come by, but they can be really effective.

With regard to interface development I’m also big on accessibility. The UI is the gateway to the experience, after all, so it better be good, and easily usable!

Full mouse and full keyboard control, difficulty modes, colorblind modes, all manner of audiovisual feedback/reinforcement, a huge and ever-growing number of config options, partial support for key rebinding… Cogmind has a long list of things I put a lot of effort into. It does really bother me that for architectural and design reasons I can’t fulfill all goals in this respect (like full rebind support on all foreign keyboards, or larger map cells), but it’s inevitable in development that some choices will preclude other options. (That’s also the main reason I wanted to make POLYBOT-7 :P)

Recap

All that sure is a lot to take in, so I thought I’d do a quick summary of all the bits that I was originally thinking of highlighting in the text itself.

Disclaimer: This is just my personal approach and not suitable for all games or developers; all of these points were covered with more context and detail above.

Kyzrati’s Game Design Philosophy (ordered by appearance in article, not relative importance):

• Start with a clear vision, and stick to that vision throughout development.
• Resist the urge to add features that seem cool but don’t align closely with the vision.
• Aim for a challenging but fair experience, though accommodating players with differing skill levels and time on their hands is important where possible (even better if it can be done with actual feature changes rather than simply numerical adjustments).
• Telegraph or signpost major challenges using a variety of means.
• Give the player tools to recover from mistakes or unexpected events.
• Integrate into the design multiple ways for players to control their own difficulty during the run.
• Good balance is vital, and not only in a raw numerical sense, but also just the feeling of balance as well.
• There must be enough design space to sufficiently flesh out a new feature, though once fleshed out it can’t interfere with other features.
• New features should hook into as many other existing elements as feasible--the more interconnected the world, the more natural it feels.
• When considering changes, avoid quick reactive decisions and prefer to wait for a sort of “critical mass” before making a move.
• Consistency in all things is important, while maintaining internal logic is useful for easier player understanding and meeting expectations.
• Player expectations are a powerful driver, and limiter, on development, suggesting the usefulness of rooting a game in realism.
• If some feature will create too many questions without answers, or without good answers, that’s a clue that it might not be developed well enough to include in the game.
• Varying content density is good, as is avoiding overpacking too many areas.
• Lore is a great tool for explaining the world and creating more explicit connections between content.
• Never give players all the lore.
• Save players from themselves, stamp out optimal tedium wherever possible!
• Removing exploits is important when building an experience, but not necessarily those which would require a huge amount of work while few to no players are using them for much benefit anyway.
• Gameplay features always take a back seat to UI/UX concerns.
• Accessibility is important, address it wherever possible.

In the end it’s important to remember that in any game of significant scope we can’t possibly fully achieve every goal here (hey this is the crazy challenge that is gamedev, after all!), but it’s always worth a try, and worth aiming for those lofty goals!