Grid Sage Games

Adjustable Difficulty

By Kyzrati | Published: February 16, 2017

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!

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:

cogmind_difficulty_mode_score_sheet_headers

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.

cogmind_difficulty_modes_color_HUD_parts_dividers

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.

cogmind_challenge_unstable_log_msg_slots

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

cogmind_challenge_unstable_sample_evolution

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.

cogmind_challenge_easy_mode_score_history

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

Update 190917: Difficulty modes in Cogmind have been rebranded, among other changes based on what I’ve learned from watching the player base over the years.

Posted in Design | Tagged Accessibility, Cogmind, Difficulty, Roguelikes | 10 Responses

Pricing a Roguelike

By Kyzrati | Published: January 25, 2017

Price, funding, revenue, development costs… these are not terms traditionally associated with roguelikes. The situation has changed significantly over the past several years, though. Not only are there many more roguelikes these days, but some of them (*gasp*) even cost real money!

Having made the leap from years of hobbydev to years of commercial roguelikedev, I have some thoughts and experiences to share on the somewhat contentious idea of raising money for a roguelike, and pricing strategies in general. Although I write in terms of roguelikes, most of the same principles can be applied to other genres as well.

In short, Cogmind’s approach to pricing has worked out perfectly, initially meeting my expectations, and then before long exceeded them. Repeatedly.

Why Pay for a Roguelike?

Before I get into examples, the short answer is that money makes more things possible. Who doesn’t want even more higher quality games from their favorite genre?

As for specifically what money can do for roguelikes, not too long ago on the Cataclysm: Dark Days Ahead forum a relevant thread popped up.

Excerpts from a discussion on C:DDA UI development.

You see this a lot in roguelike development, where accessibility and UI features are an afterthought. That’s not to say they aren’t important, nor would many developers make such a claim, but it is widely considered a less enjoyable part of creating a roguelike. Roguelikes are all about adding new mechanics and content--heck, rapid feature development is one of ASCII’s strong suits to begin with! UI work requires yet more time (on top of all the other things RL dev entails) in a very different area of expertise.

Kevin (C:DDA developer) at the end there makes the point well: Hobby projects are more about what the dev wants to do. I can say from experience that after having switched from hobby to commercial development, the focus shifts towards a lot of what the dev should/must do. Sure there’s still the fun stuff--the new mechanics, new map generators, finding new and exciting ways to ~~kill~~challenge players… but I also spend plenty of time doing things I don’t necessarily feel like doing.

You know, like most any other job that pays :P

A developer charging money for a game has an obligation to serve the player wherever possible, and that means devoting proper attention and resources to usability. Note that this in no way implies sacrificing creative control, it just means treating the project as a proper business--taking feedback, interacting with players (who double as customers), and providing customer service. As such, accessibility features have a much higher priority for me, which a lot of players appreciate.

Players get so much more than that, though. Increased production value and quality make up the bulk of obvious benefits from paid roguelikes. Being able to invest extra time or money means:

Extensive professional tilesets of a consistent quality and style. ADOM currently has over 6,000 tiles; ToME4 has a mind-boggling total north of 20,000; Caves of Qud has upwards of 5,000; Cogmind has 1,165 (plus over a hundred custom font bitmaps, a thousand pieces of ASCII art, and many hundreds of procedural animations). And because they’re all in development, these totals are still increasing as time goes by! (It’s early yet for DoomRL successor Jupiter Hell, but with all those 3D assets it’s in a league of its own and certainly not happening without funding! (already acquired through KS))
Sound effects aren’t something that a lot of roguelikes do--that’s mostly roguelite territory, but Cogmind has made it a big part of the experience with over a thousand samples and counting (far more than any other roguelike and most other indie games).
Music. Some roguelikes do this, too! (~~Still to write: my own article on that topic.~~ Posted!)

Certainly plenty of perfectly good roguelikes have none of these things, but many of the more widely popular ones do, not to mention the potentially long stretches with no fixes for bugs reported in non-commercial roguelikes.

Optional elements aside, considering the time-intensive nature of roguelike development, simply having more time to dedicate to new features is a big thing. A revenue stream enables continuous development, much more desirable than the sporadic updates endemic to hobbyist gamedev (for which the ARRP was a somewhat successful attempt to remedy, but still can’t compare to directly funding the process!).

Development on Ultima Ratio Regum, an amazing free roguelike project started in 2011 but only about half done by now, was unexpectedly halted for some months shortly before a planned release last year. Mark is now back at it again, but a number of other roguelikes have died or faded out over the years before reaching completion. Pure hobby projects tend to progress more slowly, and therefore stand a greater and greater chance of dying as time goes on. It’s just a fact of life, in which any number of causes can spell the end of (or at least interrupt) development, be it family, studies, work, a change of interests, or “a bigger better idea!!1” :). From that perspective, means to accelerate progress are a good thing (and of course for their part players won’t complain about access to more timely updates!).

Honestly it’s a huge amount of pressure to keep up that near-nonstop progress, but the ability to (relatively speaking) quickly and efficiently put together a world that others can enjoy is worth it.

Cogmind cumulative development hours, 2013.6-2017.1.

As an experiment, let’s look at the hours I’ve put into Cogmind as of this writing (6,623) in a different light: What if this were a hobby project done in my spare time? Excluding basic needs and all other responsibilities, based on years of data I generally have about 50 hours to spare each week for work (all of which currently goes towards Cogmind). Assuming I use up 40 of that for a different job and develop purely as a hobby instead, and also making the big assumption that doing this other job wouldn’t leave me even more exhausted and desiring extra time to relax and get away from brain-draining activities (it would), that leaves 10 hours per week… 6,623 h / 10 h/wk = 662.3 weeks, or 12.7 years!

So rather than Cogmind being what it is today in January 2017, having started as a hobby back at the original date of June 2013 it would not reach its current state until July 2025. Sure we could chop off a year or two because, yes, I might spend vacation time working as well (though we’d also have to cut out the occasional weeks where I’d be too busy with other life stuff)--anyway, it’s a generalization, but no matter how you look at it that’s still terribly slow.

Then of course there’s the fact that it’s not done yet :P. I can say for sure that including post-1.0 work it’ll easily top 8,000 hours (beyond that I don’t really know).

In the end, most roguelikes and features are technically possible without any funding whatsoever, but it’s going to take a lot longer (which, again, increases the chance of failure), or a lot of manpower (DCSS is a good, if rare, example there).

Why $30? Balancing Price with Other Factors

Although as I write this alpha access is available for $25, in 2015 Cogmind was introduced at $30, the price at which it remained for the entire first year of public alpha. As you would expect, reactions to this number ran the entire spectrum from “for an alpha?!?!?” to “totally happy to pay that!”

I based the specific number on a couple data points, first and foremost what I’d noticed from video game Kickstarter campaigns, that early access as a “perk” often came with tiers upwards of $30. Even outside KS, I found games like RimWorld, similarly a highly-replayable game under long-term alpha development at a good pace by a very active dev, which priced its alpha access at $30.

Overall it felt like a plausible range was somewhere around $20-$30. I would definitely not claim this approach is good for maximizing revenue potential, or even maximizing players while still bringing in “sufficient” revenue, but that wasn’t the goal!

Graph demonstrating the concept of elastic demand (source). Video game demand is pretty darned elastic!

It’s fairly obvious that a lower price point might very well outsell the current sales model in terms of total revenue, but to me there are more important factors than money to consider in the short term. The point of alpha funding is to keep development humming along until 1.0, before which too many players actually becomes a problem!

While not necessarily true of all devs, I believe in the importance of being active in the community, responding to everyone with a concern, question, or some other need of support, while also putting effort into making resources, extensive progress updates, and other information available outside the game. This requires a significant time investment, the effects of which are even more pronounced as a lone developer where talking to players means I’m not making real progress on the game itself.

Lower prices naturally attract more players, which given this community-oriented model will inevitably slow development as more and more time is spent on community management. But I love having the opportunity to maintain closer relations with a smaller player base, even adding custom options at the request of a single player, while still having plenty of time to work on the next release. So in this regard a higher price is beneficial for both development and the ongoing alpha player experience.

Game development is also incredibly risky, so it’s nice to use any knowns to mitigate elements of risk wherever possible. This, too, played a role in the original pricing decisions, which you can see below from my general thought process:

I do know that I have an established fan base who would be willing to pay more for a quality roguelike with quality continuous development and support.
I don’t know whether lowering the price to something more common across the entire indie market (like <=$10) would be able to attract enough players to even make up the difference. But I do know that even if it could, having 2-3 times as many players would be a larger burden on the process and unnecessarily slow development. The resulting “high noise-to-signal ratio” also makes it harder to focus on the best design decisions.
Niche games, especially those with something truly unique to offer, can afford to charge more, and in many cases must charge more in order to be at all sustainable. Long-term sustainability is quite important to me, since this isn’t a one-off thing and I hope to not only develop it further beyond 1.0, but also work on other games as well. It’s (hopefully) a permanent job.

In that light, a $30 price point seemed the much safer route.

From a purely economic standpoint, where time is not a limiting factor (i.e. development and support can and will continue for quite a while), setting a higher price is also just smart business. Eldiran over on /r/gamedev (where especially when starting out I read a lot of first-hand industry info that was very helpful) put it very well in response to a question about how discounts damage indie sales:

Different players value your game differently. Hardcore fans want to buy it as soon as possible at full price. Some genre fans might be willing to grab it once it hits 10-20% off. People who are only mildly interested might wait for a 50% sale. And so on.

If you set up a 50% sale early on, all of those groups will buy it for 50%. That means you lost all the extra money you could have gotten from the 10% group, the 30% group, etc.

There are lots of other considerations. Consider what it looks like as a buyer to see a game go 50% or 75% off shortly after release. That would look like the developer isn’t confident in the quality of their game. Maybe they’re just trying make a quick buck with manipulative sales, and the game sucks?

That said, there are situations where getting a big playerbase as fast as possible is more important, such as for multiplayer-only games. Then it might be worth it to do sales early and often.

The comment is in reference to sales, but the same principles apply to pre-release pricing as well.

It’s not purely a numbers game, though--the price is still very much associated with potential value. Subjectively speaking, I consider Cogmind worth that price if I were a player looking at such a game, and clearly many others agree. Everyone else can make that call for themselves based on the large amounts of information available, while a higher price serves a useful secondary purpose here: prevent impulse buys. Impulse buys, which are where a lot of developers can expect to bring in more players via low prices and steep discounts, are also where a lot of the noise-to-signal problems mentioned earlier come from. It leads to too many distracting, non-constructive comments from players who probably haven’t spent very long with the game in the first place. (Not to say first impressions aren’t important, too, but they shouldn’t make up the bulk of the discussion.)

Side note: A great tool for games with a higher alpha price is a one-time mailing list for those who wish to be notified when the game comes down to its regular price. Over 1,000 people have signed up for that already. This is essentially akin to the Steam wishlist, albeit without the Steam part :P

A pricing discussion wouldn’t be complete without a look at the common argument for a lower price before full release: Players may very well be playing an unfinished, buggy version that’s not necessarily all that much fun, where a higher price equates to paying a premium to help find and report bugs! (That sounds like work…) I completely agree with that argument, though I would also argue that developers need to try to release early versions that are not so buggy, and fun from the start. Then it suddenly becomes more of a privilege to join the alpha process, where those players are not only having fun, but can also influence the future direction of the game via their feedback.

This is how I handled Cogmind--sure there have been bugs, but a relatively tiny number, nor is it usually anything serious (most serious bugs are discovered via automated testing prior to updates, and those which aren’t are patched immediately, generally within an hour of reporting). Fixing bugs is always a top priority, and even the original 7DRL is fun so that aspect is covered, hence the overall player consensus that “it doesn’t feel like an alpha,” which is exactly the kind of sentiment that is important to lay the foundation for by building a quality pre-alpha in the first place.

Yet another advantage of a higher alpha price is a factor many non-developers may not realize: while in early access and not on Steam I can devote a lot more of the revenue to actual development, whereas on Steam a majority of the funds would go to Valve (30% fee) and the US government (taxes…), and they’re certainly not going to help make Cogmind better! :P So each individual person supporting my work at this stage has been far more valuable to the project than even a handful of supporters on Steam could be, and the results are amplified with a higher price, all while keeping the player base to a manageable size. (Clarification: Steam is definitely a valuable channel in the long term, as it provides access to a much larger pool of players--so many only buy through Steam!--but given the context it’s not the right choice for me at this time. That said, in the interest of sustainability the amount of post-1.0 work will be mostly contingent on how successful Cogmind is on Steam.)

Getting Results

Cogmind Alpha Access has been quite successful, my definition being that it’s been able to fund itself. And that’s with just the right amount of feedback from players to help improve the design without causing too much of a drag on the process.

Revenue has been both relatively steady and just enough to keep development going. In fact, the process has been going so smoothly that the original plan to “finish” by the end of 2015 was quickly scrapped in favor of another year of developing extra features, which became yet another year of decent revenue that pushed the intended deadline into 2017. Sure, development could’ve been rushed to the planned 1.0 over a year ago, but there were/are so many tempting optional features, and many new players have come to support this project, so why not add more fun stuff? :D (For the curious, a sampling of the features so far that could only be added as a result of strong alpha support: traps, Trojans, Waste, garrisons, Zionite plot line, about 15% of the items, numerous additional robot designs, countless extra UI features, large-scale refinement of mechanics like hacking, machines, and flight…)

Since Cogmind was available at more than one price when alpha access began (an idea inherited from Kickstarter but without the temporary campaign nature), let’s look at the reasoning and performance of each of the tiers.

$90. While as a sum this highest tier seems expensive, it included multiple keys at essentially $22 each, or $15 if you subtract the value of the t-shirt thrown in. This whole tier was just something I wanted to do because having a custom t-shirt is neat, and 18 other people liked the idea, too :) (only available during the first month, though since then there have been numerous requests to bring back the t-shirt, so I’ve been taking names and will do that at some point).
$60. I can’t take credit for this idea, which turned out to be a really nice one indirectly suggested by sambojin over on the Bay 12 forums, who shortly before launch said he hoped for a way to buy more than one key, preferably at a discount, to give the others away. That sounded like a perfectly reasonable request, thus the Improved Tier was born and to this day 9.7% of all revenue falls into this tier. And it’s not only for gifting, either, as multiple supporters can pool their money and buy this 3-pack which breaks down to $20 each. Especially soon after the launch period it was possible to see such groups forming on various forums among friends. There are multiple advantages here, including a bit of free marketing while also giving those who couldn’t afford $30 a way to acquire it at a 33% discount. I also made sure to clearly indicate that $20 is the intended launch price for 1.0 (it always has been). Managing expectations is an important part of pricing!
$30. This one was already covered pretty well. It accounts for 85.6% of revenue in the first year, before the next tier was introduced.
$25. When the first anniversary of Alpha Access rolled around (May 2016), sales seemed to be in an ever-so-gradual decline, thus it was a perfect opportunity to introduce the first price drop. It was nice to have that middle-ground leeway in between what it was and the future launch price, enough to make a difference to buyers but still be a respectable amount of revenue without opening the flood gates to new players. As expected, sales picked up again, and have continued at a good pace ever since.
$20? More recently I’ve taken to offering the occasional 20% discount coupon in coordination with other events. These are neat since I can see precisely how much a lower price stimulates real buying interest coming from various sources by using different coupon codes for each.

Summary of Cogmind Alpha Access Tiers, 2016.

Note that even in introducing the $25 tier, I did not remove the $30 tier. It’s still available as it offers a few perks that don’t come with the new lowest tier, just a thank you in the credits and a forum badge. And despite the availability of $25 access, some people still go for $30! From May 19, 2016, to date, the $30 tier still accounted for 14.1% of individual sales (15.9% of revenue). Had the same group of people instead only had the $25 option, gross revenue would have simply been $795 less. Not providing ways for individuals to offer extra support when they have both the means and desire is so-called “leaving money on the table.” And when I see that during alpha dev it means “leaving features on the table, too” :P

Cogmind Monthly Revenue (Gross), 2015.9 -- 2016.12 (graph excludes initial 4-month period after first release due to distortion by outside factors)

While there are too many factors involved to draw sweeping conclusions, it’s probably safe to say that lowering the price in May didn’t hurt the bottom line. Compared to the period before, when the lowest price was $30, average monthly revenue rose 13.9% from $2,478 to to $2,823. The latter average excludes October, which was a weird month because it was Cogmind’s largest-ever update combined with a little surprise article from RPS. In fact, October, November, and January were three consecutive “largest ever” releases (January’s not quite done so I couldn’t include that data, but it looks like it could break $4k alone).

Actually, we can do better than this with a comparison of averages from just the few months before and after May. February through April (plus the first half of May) sales were showing clear signs of flagging (monthly average: $1,927), while in the four and a half months after adding the new tier (through September, before things started getting crazier) the average increased 45.3% to $2,799. Looking at it that way, the change had a larger impact than I’d realized! A more detailed look at the difference between the 15 days before and after May 19th is equally telling:

Cogmind Daily Revenue, May 5 -- June 5 (2016)

During the months leading into early May I was getting kinda worried because I’d definitely have to wrap up development more quickly if that trend kept up (see those two zero days?! Scary!). But the new price put alpha back on a healthier long-term feature-filled schedule. The one-year anniversary turned out to be an excellent opportunity used well.

Update 170614: For additional stats and analysis on how pricing and other factors affected sales, see my more recent Year 2 financial overview for Cogmind.

Changing Times

Indie devs in general tend to undervalue their games, though it’s nice to see that a growing number of devs aren’t afraid to charge a (minimally) decent price for paid roguelikes. Caves of Qud is only $9.99 for early access, but will reportedly rise to $14.99 at full release; both Ancient Domains of Mystery and Dungeonmans are $14.99; Jupiter Hell is aiming for $30-ish… It’s necessary if we want this quality and pace to be sustainable.

Those graphs and numbers look pretty, but they’re not much compared to the amount of hours and money that I put into development, or what I can make in another line of work (it’s also gross revenue, not net!). Other devs are in similar situations. The genre is relatively niche, after all, and based on publicly available Steam data the above released games only have somewhere around 20-25k players each, so it’s been heartening to see the core community repeatedly coming out in support of paid roguelikes over the past couple years.

Roguelikes especially, with near infinite replayability and near endless development cycles (those games have been putting out updates for years), are just the kind of high value-to-cost ratio games that both warrant and can benefit from higher prices in the long-term.

As for my own future plans for Cogmind pricing, 1.0 will be released at $19.99, with no plans to do any significant sales for a long while as I continue updating with extra features (I hear this echoed by several other devs as well). Of course once on Steam, players in certain regions will have access to lower regional prices. Steam changes a lot of things by introducing its own many variables, so it was interesting to be able to take this somewhat more “pure” look at revenue and pricing data before it gets that much more exposure.

Good Luck

To the devs reading this, do remember that every ~~genre~~game is different, and there are other very different yet equally successful models out there, too. Dwarf Fortress, UnReal World, and Tales of Maj-Eyal, for example, are all widely-popular free roguelikes that exist on purely donation-based systems (with full-time devs!), or offer some extra perks to supporters. My pricing decisions came out of what I felt could work for Cogmind based on lots of research and also consideration of my personal circumstances and experiences.

Oh, and I’m sure there’s gotta be some luck in there, too ;)

Posted in Gamedev, Marketing | Tagged Cogmind, Gamedev, Marketing, Post-Mortem, Pricing, Roguelikes | 12 Responses

Map Prefabs, in Depth

By Kyzrati | Published: January 11, 2017

An increasingly common approach to roguelike map development today is to have content partially determined by so-called “prefabs,” with layouts which are hand-made rather than fully procedurally generated. Doing so gives a designer more control over the experience, or portions of it at least, without completely supplanting the advantages of roguelike unpredictability.

Prefabs are a great way to add more meaning to a map, which when otherwise generated purely procedurally and visited again and again by a determined YASD survivor is often going to end up feeling like “more of the same” without a little manual help to shake things up. Yes, even procedural maps get boring once players start to see through their patterns! Not to mention the general lack of anything that really stands out…

Background Reading

I’ve written and demonstrated a good bit about map generation before, including the basics of how I create prefabs for Cogmind, starting with essentially drawing them in REXPaint. This method is light years ahead of the old “draw ASCII in text files” method I was using with X@COM (now that I have REXPaint, I’m definitely going to have to go back and convert that system, that’s for sure!).

Sample X@COM map prefab excerpt, typed! In text! The horror! (At least it used a little bit of syntax highlighting to help pick out important features…)

And once prefabs are created, one of the major challenges is how to actually get them into a procedural map. After all, they need to seem like they belong! Previously I demonstrated some methods for handling that part of the process in cave-style maps, namely geometric centering (sample) and wall embedding (sample). Read the full post regarding that style over at Generating and Populating Caves.

But most maps in Cogmind are not caves, instead falling under the room-and-corridor style. Naturally these other maps will require different methods for embedding prefabs, and below I’ll be sharing these methods in addition to a more detailed look at what Cogmind’s prefab definition files have evolved into over the years.

“Seeding” with Prefabs

One way to place prefabs is before map creation even begins, in fact shaping the initial generation itself. This approach is for prefabs that will help define the core feeling or difficulty of the map as a whole, thus it’s more suited to larger prefabs, or key points such as entrances and exits. It’s easier to control the absolute distance between these important locations by placing them first. So high-priority prefabs come first… that makes sense :).

As entrances and exits are essential features while also having a large impact on how a given map plays out, thus my maps are designed to place most of them first. Not all of them are handled as prefabs and are therefore beyond the scope of this article, but some special exits that require more flair, fluff, events, or other types of content use this “initial prefab” system. The first such example is found very early in the game in the form of the entrances from Materials floors into the Mines (admittedly one of the less interesting applications, but I don’t want to leak spoilers for later content).

Step 1 in the map generator is to go down a list of potential prefabs and configurations and put them on the map!

cogmind_materials_mapgen_static_features

Complete feature list for Materials-type maps.

cogmind_materials_mapgen_variant_3_phase_1

Sample step 1 (feature variant 3) as seen in the map generator for Materials.

In this case, as per the feature list the generator chose to go with variant #3, which calls for two BLOCKED barriers to prevent pathways from linking areas on either side of them, in addition to two top-side MAT_00_S_1_MIN prefabs, one to the west and one to the east. Looking at the relevant feature data (those last two lines), these prefab areas block all entity spawning within their area, and have ever so slightly variable coordinate offsets (some prefabs elsewhere make much greater use of this ability to shift around).

The MAT_00_MIN file stores the data that allows the engine to decipher what objects are referenced within the prefab:

Data references shared by all Mine entrances.

And “MAT_00_S_1_MIN” refers to the file storing the layout itself:

cogmind_materials_mapgen_mines_entrance_prefab

Mines entrance MAT_00_S_1_MIN prefab layout, as seen in REXPaint. (This is a multilayered image, so here you can’t see the complete machine hidden under the ‘A’s.)

The southern edge calls for a tunneler (width = 3, the yellow number) to start digging its way south to link up with the rest of the map (when its generation proper begins), while both the left and right sides are tunnellable earth in case later pathways are dug out from elsewhere on the map that would like to link up here. Those are simply other possibilities, though--the only guaranteed access will be from the southern side.

cogmind_materials_mapgen_variant_3_final

Final map after all steps concluded, incorporating Mine entrances placed first.

Other common candidates for initial prefabs are huge semi-static areas, sometimes as large as 25×25 or even 100×100, which play an important role on that map either for plot or mechanics purposes.

A portion of map generated with two large prefabs (highlighted) that were placed first.

The next method is a bit more complicated…

Embedding Prefabs

Most of the prefabs in Cogmind are not applied until after the initial phases of map generation are complete. Therefore all the rooms and corridors are already there and I had to determine the most flexible approaches for adding this type of content to a map without screwing up either the prefabs or map itself.

Before going any further, though, we have to decide which prefabs to add in the first place, a decision naturally affected by the theme, depth, and other various factors associated with the map in question. That process is handled via the “encounter system” I initially described in this blog post (half-way down), but I never got into the technical side of how those encounters are selected, or how those with prefabs are actually merged with the map, which is relevant here. (*Clarification: An “encounter” refers hand-made content which may be loot, enemies, friends, or basically anything, sometimes combined with procedural elements, and sometimes but not always associated with one or more prefabs.)

In general, while there are a few types of encounters that appear across multiple maps, like rooms full of debris, each type of map has its own pool of potential unique encounters. And then there are multiple base criteria that may or may not be applicable in determining whether a given encounter is chosen:

Depth limits: An encounter may only be allowed within a certain depth range. (I’ve actually never used this limitation because maps containing encounters generally only appear at one or two different depths anyway.)
Count limits: An encounter may be allowed to appear any number of times, or up to a maximum number of times in a single map, or up to a maximum number number of times in the entire world (only once in the case of true unique encounters such as with a named or otherwise NPC with very specific behavior).
Mutual exclusivity limits: Some encounters may not be allowed to appear in the same map as others. These will be marked as belonging to a certain group, and exclude all others once one is chosen.
Access limits: Encounters can require that they only be placed in a room connected to a certain number of doors/corridors. It is common to restrict this to 1 for better prefab layout control (i.e. knowing which direction from which the player will enter makes it easier to design certain prefabs).

Encounters are also not given equal weight--some are common while others are quite rare. I use words/strings to assign encounter weights in the data, because they are easier than numbers to read and compare, and can be more quickly tweaked across the board if necessary (by changing their underlying values).

Encounter weight value ranges (source).

cogmind_encounter_weights_data_matrix_excerpt

Encounter weight values (data excerpt), where each column is a different map, and each row is a different encounter.

So you’ve got some prefabs chosen and a map that looks like this:

Completed room-and-corridor map generation, sample 1.

Or this:

Completed room-and-corridor map generation, sample 2.

Or something else with rooms and corridors. How do we match encounters with rooms and actually embed prefabs in there?

Unlike “seeding prefabs” described earlier, these “room-based prefabs” actually come in a few different varieties, but all share the characteristic that they are placed in what are initially rooms, as defined by the map generator. Of course the map generator must know where it placed all the rooms and their doors in the first place, info which has all kinds of useful applications even beyond just prefabs. Can’t very well place prefabs without some likely target areas to check!

The most common prefab variety is the “enclosed room” category. A random available room is selected, then compared against the size of each possible prefab for the current encounter. (A single encounter may have multiple alternative prefabs of different dimensions, and as long as one or more will fit the current room then oversized options are simply ignored.) In order for a rectangular prefab to fit the target room it may also be rotated, which doubles as a way to provide additional variety in the results. And yet another way to expand the possibility space here is to randomly flip the prefab horizontally. (Flipping vertically is the same thing as a horizontal flip followed by 180-degree rotation, so kinda pointless :P)

Steps to place an enclosed room prefab.

Find a room that’s large enough to hold the desired encounter/prefab.
Find a target rectangle which borders the doorway. (The horizontal axis is randomized to anywhere that will allow the door to be along the prefab’s bottom edge. Prefabs are always drawn to face “south” by default, to establish a common baseline from which to shift, rotate, and flip them. And those with a single-door restriction are always rotated so that their bottom edge faces the door, whichever side of the room its on. This makes designing the experience much easier since you always know which direction from which the player will enter this type of prefab.)
Prefab dimensions will generally not precisely match those of the room in which they’re placed, therefore the surplus room area is usually filled in with earth and the walls are rebuilt along the new inner edge (though the room resizing is optional--it can be left as extra open space).
Place the prefab and its objects, done! (rotated example shown on the right)

There are some further customization options as well. Doors can be expanded to multi-cell doors, like for special rooms that want to be noticeable as such from the outside (as a suggestive indicator to the player). Or the door(s) can be removed to simply leave an open entryway.

cogmind_room_prefab_embedded_process_modifications

Variations on the above room prefab via post-placement modifications.

The third form shown below takes the modifications a step further by removing the door and entire front wall to completely open the room to the corridor outside, creating a sort of “cubby” with the prefab contents.

cogmind_room_prefab_embedded_process_cubby

Front wall removed for cubby variant.

Storage depots found in Cogmind’s earliest floors use the “cubby room” design. The reason there is it makes them easy to spot and differentiate from afar, which helps since the point is to enable players to expand their inventory if necessary for their strategy.

Storage depot prefab as seen embedded in a Cogmind map.

Another “accessible room” variety is essentially like an enclosed room, but the prefab is designed to allow for maximum flexibility and access rather than expecting the room to be shrunk down to its size and new walls created. These prefabs usually don’t have internal walls and instead just become decoration/contents for an existing room without changing its structure. While it may end up in a room larger than itself and therefore have extra open space, including these types of prefabs is necessary to fill parts of the map containing rooms with multiple entry points where rooms with obstructions and walls wouldn’t do because they could illogically block off some of those paths. For the same reason, accessible room prefabs must leave all of their edges open for movement (though may contain objects that do not block movement).

cogmind_room_prefab_embedded_process_rotated

Steps to place an accessible room prefab.

Find a room that’s large enough to hold the desired encounter/prefab (any number of access points is valid).
Position the target rectangle anywhere in the room (random).
Place the prefab and its objects, done!

The primary drawback of using the encounter system to place encounters in randomly selected rooms is that there is no control over relative positioning of different encounters. While it’s possible to add further restrictions or tweaks to guide placement on a macro scale, it seems to work out okay as is. The existing system does, however, also sometimes result in suboptimal placement of encounters, i.e. a smarter system could fit more into a given area, or better rearrange those that it did place to maximize available play space. But these effects are only apparent on the design side--the player won’t notice any of this.

An alternative would be to use a room-first approach, choosing a room and then finding an encounter that fits, but in my case I wanted to prioritize encounters themselves, which are the more important factor when it comes to game balance.

Post-mapgen prefabs placed in a map, highlighted by category for debugging.

So overall my prefab solution is a combination of external text files and binary image files, processed by about 3,000 lines of code.

Update 220718: To see another example of embedding encounter prefabs, in a different environment with somewhat different steps, see my later coverage of Garrisons 2.0.

Inside a Prefab

So far we’ve seen how prefabs fit into the bigger picture, but another equally important aspect is what goes into a prefab itself. Each prefab must have an associated definition file (sometimes shared by multiple prefabs if they have similar contents), which is a simple text file that describes the objects found in the prefab.

My first ever prefab article (linked earlier), written two and half years ago (!), appeared before even any prefabs had been used in Cogmind. As you can guess, things have evolved since then, getting a lot more versatile and powerful as new features were added to meet new needs throughout alpha development. Here I’ll give a general rundown of those features, to give a better idea of how they work.

At the most basic level, a definition file is simply a list explaining what object each ASCII character in the prefab represents. After placing the initial prefab terrain--walls/doors/etc, the generator consults the corresponding definition file and creates those objects at the specified positions. Reference characters are written to the prefab image’s fourth layer as part of the design process (they can be any color, but I always use green for consistency).

Sample prefab layout image (draw in REXPaint and stored as a compressed .xp file). Green letters and numbers all exist on the highest layer (layer 4) and refer to objects. This particular prefab represents one quarter of a garrison interior, which are built entirely from a large selection of prefabs.

In a definition file, each line corresponds to a reference, of which there are five types:

Prefab definition object types.

For consistency and to aid readability of prefabs when creating/editing them, I always use upper case letters for props and traps (the latter actually being a subset of the former), lower case letters for entities (robots/mobs), numbers for items, and punctuation for debris (of which only one reference is actually necessary, because the actual appearance is determined by the engine).

Note that a “tag” is the internal name for an object, which may not always match the name the player sees, to enable objects that appear the same but are actually different for whatever reason.

The above basic info, a character plus the object’s [TYPE] and [TAG], are the only required data for a given object, but most objects will be followed by additional data keywords that describe the object in more detail (overriding otherwise default behaviors). The set of applicable keywords is generally different for each type of object, though any reference can specify the [SHIFT] keyword, which instructs the prefab to randomly shift that object within a certain area, (+/-x, +/-y), so that it doesn’t always appear in the same place.

cogmind_prefab_definition_keyword_samples

Sample prefab keywords used to expand on different object definitions. Custom syntax highlighting helps parse the file when editing.

Items and entities specifically have more options for their [TAG] value. Quite often it’s desirable to select one from among multiple potential types, a feature supported by additional syntax and keywords.

cogmind_prefab_definition_syntax_randomization_entities

Randomizing entities in prefabs.

The first example demonstrates how it’s possible to designate any number of entities from which to randomly select, in that case a G-34 and G-47.

The second example, on the other hand, simply specifies an entity class, and the game will select an entity appropriate for the depth at which the prefab is placed. This is useful for prefabs used across multiple depths, and has the added benefit that any changes to object names (and other values!) do not force reconsideration of existing prefabs. For the same reason, hard-scripting specific object names is avoided where possible.

The third example simply demonstrates random selection between different classes works, too.

Designating a class instead of a specific name may also call for additional keywords (optional), where [CATEGORY] suggests which category to select an entity variant from, where a single class may belong to more than one entity category, [STRONG] tells whether to select an entity that is one level stronger than the current depth, and [FALLBACK] tells the engine to fall back on the weakest variant when technically no variant of the desired class exists at or below the current depth.

cogmind_prefab_definition_syntax_randomization_items

Randomizing items in prefabs.

Items (and traps, actually) often do the same thing, and can range from extremely specific (Ex 1) to extremely vague (Ex 4). Ex 2 demonstrates just a sampling of the available categories to select from, as away of narrowing down the selection pool--important for balance and controlling the experience! And Ex 3 is a pretty situational one, randomly selecting an item that would normally be equipped by the entity in parenthesis, to allow for thematic loot (the scene of a specific battle, for example).

Where no specific tag is given, the [PROTOTYPE] keyword suggests that the item should be chosen from among prototypes (a better type of item) than common items, [NEVERFAULTY] designates that a chosen prototype should never be a faulty version, and [RATING]+X can be used to have the map generator attempt to choose an “out of depth” item instead (where X is the number of levels higher than the current one to choose from).

The theme of non-static prefab data is an important one, as it’s a relatively cheap way to make even handcrafted content stay fresh despite repeated exposure. To take this theme even further, individual keywords can be modified by various prefixes with different effects:

cogmind_prefab_definition_syntax_randomization_keywords

Prefab keyword randomization modifiers. These can be applied to any data keyword for any object.

For larger scale randomization we also have two available columns at the beginning of each line (excluded from all of the above samples):

cogmind_prefab_definition_syntax_randomization

Prefab generic randomization capabilities and syntax.

Despite the appeal of randomization, it is often desired that multiple entities or items placed near each other in a prefab should be of the same type, even when randomly selected. Thus by default whenever the object for a reference character was chosen randomly, any cardinally adjacent matching characters will automatically use the same object type (extending as far as necessary in a chain). Where there is a need to allow adjacent objects (even those with matching characters) to be different from one another, the [UNIQUE] keyword can be used to explicitly force that.

Some Statistics

As of today Cogmind contains…

148 base types of encounters, 115 of which use prefabs
372 prefabs in all (much higher than the number of encounters because some have multiple prefabs, and as explained before not all prefabs are associated specifically with encounters)
The largest prefab is 100×90
The smallest is 3×2 :P (mostly a mechanical thing)
The average is 7×7
The single encounter with the greatest variety of unique prefabs has 12 to choose from

In total, 25% of encounters are categorized as “fluff,” 15% as “risk vs. reward,” 14% as “danger,” and 46% as “rewards.”

Posted in Design, Dev Series: Procedural Maps | Tagged Cogmind, Encounters, Map Generation, Prefabs, REXPaint, Tunneling Algorithm | 2 Responses

Year 3 of the Cogmind

By Kyzrati | Published: December 19, 2016

Unbelievable… I’ve been working on Cogmind for three and a half years now. Yet another year has gone by, and this time the end is very much in sight!

To start off, as I did for 2014 and 2015 here’s a collage of development images from the past year:

Images from the past year of Cogmind development as appeared on this blog and Twitter (full mega size here).

GIFs outnumbered PNGs about three-to-one, but an animated collage wouldn’t be able to include enough images to do the year justice :). I don’t have anywhere specific I collect only GIFs, though I did use a number of them on the page I put together this year dedicated to summarizing some of the innovations Cogmind is bringing to the genre.

Development Time

As usual I’ve been keeping close tabs on where every hour is spent, altogether 6,383 hours so far:

timeline - cogmind_monthly_development_hours_201307-201611

Cogmind Monthly Development Hours, 2013.7-2016.11 (click for crisper full-size version). (The color coding is for different aspects of development tackled each month, the subject of a future in-depth article to come when Cogmind is complete.)

That’s 1,982 hours this year compared to 2,321 last year, when I was doing a lot of promotional prep for the launch (trailer, website, etc.), and didn’t take any vacations like I did this year. (The year before, 2014, totaled 1,528 hours.) Comparing purely work on the game itself, this year added 1,151 hours compared to 1,273 in 2015 (and 1,078 the year before that), so in that respect progress has remained relatively steady. There’s lots more interesting data in there, but I’ll get into that another time.

At the end of 2015, my only worry was that I’d be forced to do a full launch earlier by cutting or postponing newly-planned features, but through a careful balance of progress and minimal marketing, revenue has remained steady, and Cogmind keeps growing extra features :D

Releases!

2016 saw seven major releases.

Cogmind release summary, as seen on the FAQ. For links to changelogs, full release notes, and preview images, see the Release History I maintain on the forums.

As you can see, progress consisted of maps upon maps upon maps… Cogmind began 2016 with 14 map types, and is ending it with 26, each of which also added unique mechanics, components, and in some cases major plot events. The world got so big that it was finally time to add a world map.

Sample Cogmind world map in action.

And with that Cogmind’s story is almost complete, which is my primary criterion for judging Cogmind to be 1.0. So we’re close!

As far as sharing progress, note that the nature of this dev blog has changed--while I used to share smaller specific development updates here, this year you’ll notice I’ve instead shifted to publishing mostly longer articles of (hopefully) greater value about some relevant gamedev topic, with occasional aggregate Cogmind updates where they align with that goal.

Regarding individual features and content, I technically share even more updates than I used to, but that progress is posted to the announcements board, subreddit, and Twitter (also some other forum threads).

I like this division of focus, and will continue the pattern into 2017, with planned articles on topics like pricing, game difficulty, code testing, roguelikedev tips, and more.

Milestones

So what other big milestones did 2016 see…

Well, the biggest would have to be that Cogmind passed both the 2,000- and 3,000-player thresholds this year! (The latter just this month.) This was the first full calendar year that Cogmind was available for purchase. Yep, in addition to the 2015 initial launch, the public alpha (Early Access, if you must!) has continued for 19 months now. Sales have been acceptable, enough to avoid forcing me to cut features! Actually, enough to convince me that I have leeway to add more, and as a result 2016 brought tons of new mechanics and QoL features that wouldn’t have otherwise been possible. So thanks from myself and on behalf of future players :D. On that note, back in May I did a recap of the first 12 months of Alpha Access, wherein I shared revenue breakdowns, among other reflections.

Cogmind’s community has grown in absolute terms, though as we’re still in alpha most new supporters play for a bit then stop to wait for 1.0. I decided against holding another tournament like the Alpha Challenge 2015, at least this year, because while it was great fun, it also took too much time away from development last year :/. The leaderboards, however, have been very active, and there has been lots of helpful related discussion (both development-wise and player-to-player) on the forums.

A recent snapshot of the top of the Cogmind leaderboards. The leaderboard system has advanced somewhat as well, now separately listing further areas reached by player, and providing access to the score sheets for each run.

Forum discussion has slowed somewhat in the second half of the year, though, as many long-time players have switched to hanging out on the chat server (Discord) for the past 4-5 months.

On the project side, out of curiosity I compared Cogmind’s lines of code to a year ago--this year it passed the 100k LoC mark:

Cogmind lines of code, from 2015 to 2016.

In the past year there’s been a net +16,396 lines of code, or a 17.2% increase. Not a lot! That’s because as described earlier much of the progress this year was in content--new maps and their corresponding robots, components, events, etc. All of that stuff is implemented via external scripts, map prefabs, and other data files rather than code. Essentially this shows the core game was already solid in 2015, all it needed was more content to realize The Vision.

But hey, we passed 100k :P

Recognition

Each year Cogmind attracts more attention, and this year in addition to the smaller sites that published related news/articles, Cogmind appeared among the Top games on Rock, Paper, Shotgun, on Destructoid’s Top 33 list, and Nerd Much’s Top 50 list.

More recently RPS did a sudden quick article on Cogmind following one of this year’s larger releases. That title was quite a shock, and something I totally wasn’t ready for. Very busy those few days xD. In any case, it did spur another big chunk of sales which will help propel development to 1.0! Very grateful for that coverage.

Then just this month Cogmind was once again voted into the Top 100 indies of the year on IndieDB.

It’s good there’s just enough attention going around to keep bringing in new players, because I’m still not doing any active marketing outreach. I get legit review key requests, but they go on a list for later and I’d rather focus on development and the existing community for now. That said, I have been doing a lot in the wider roguelike community, including making my way over to the US to take part in the awesome Roguelike Celebration! I felt like a nervous wreck, but gave a talk people seemed to enjoy anyway :P.

I don’t really look forward to it, but by necessity 2017 is going to be a very different kind of year because I’ll have to mostly shift away from creating content and on to business and marketing -_-. That’s where hobby development really shows its superiority over doing this to make a meager living!

2017

This is it. 2017 will be a crucial year for Cogmind, because it’s the year we reach 1.0, and the year we’ll finally see what cogmind can do once it reaches a wider audience--will it flop, or will it be able to pay for more roguelike goodness in the future? :)

I never imagined back in 2013 when starting out (and most certainly not when putting out the initial free version in 2012!) that I’d still be working on Cogmind now, but I’m glad I am because it’s the result of good things! There haven’t been any serious development hiccups, and progress has continued at the expected pace, I just repeatedly pushed back the long-term schedule to fit in more stuff. It’s true that many of these things could have simply waited until after a “1.0” launch, which is what I’m sure most sane (or financially desperate) developers would do, but even Alpha 1 was a pretty solid game, and there’s been ongoing player support ever since it was released, so I never really saw a need to rush it.

That said, development is naturally coming to a 1.0 milestone. I mean, look where I’ve set the current progress meter:

Cogmind development progress as of November 22nd, 2016.

Almost everything’s at 95%, which is basically me-speak for “you could call it done but I could always do more, and I am.”

There’s still the ambient audio to work on, a portion intentionally left for last so it could more efficiently be handled all at once, and there are already so many sound effects that they essentially create an “ambiance without any ambient sound,” so it wasn’t required for alpha to have additional background effects anyway (though there are a few placeholders out there). I’ll be getting on that soon.

For fun I put together a time-lapse gif showing how the public progress meter (always shared via the FAQ) has evolved to reach this point:

Cogmind development progress graphs, from August 2014 to November 2016 (early on in pre-alpha there were still enough incomplete subsystems to warrant displaying them individually, but eventually for much of alpha it boiled down to just maps and story).

Looking to the future, well, I’ve also continued to share the major bits over in the FAQ:

Cogmind dev roadmap snapshot, November 2016.

A bunch of the pending stuff will be scratched off with the next release--just two more releases and the last remaining bits of Cogmind’s world will be complete, to be followed by whatever features I feel shouldn’t really wait until post-1.0 development. I.e., they need to be in there before Cogmind gets more attention from the less die-hard fans. I haven’t finalized exactly what those pieces are yet, as there are quite a lot of optional features and content still left on the chopping block. I’ll take stock of those later, and after implementing them it’s time to do a 1.0 release. And then, you know, keep releasing more after that :P

In short, Cogmind 1.0 is coming in 2017. Getting nervous, but also can’t wait!

And once again, Happy New Year :D

Playing with a fake weapon that fires 30 missiles. Because hell yeah 30 missiles.

Posted in Annual Review | Tagged Cogmind, Gamedev, Progress, Roadmap | Leave a comment

Improving the Hacking Experience

By Kyzrati | Published: November 17, 2016

The terrible curse of gamedev is that it’s really hard to finish a game when there’s always something that could be better. The great thing about gamedev is that there’s always something that could be better, meaning room for more new features and content to make players happy :D

The previous round of major UI enhancements (in the form of extra optional features) was centered around inventory management, which lies at the very core of Cogmind’s gameplay. And now more recently the less central but still oft-used manual hacking system has undergone a similar treatment, getting its own set of UI add-ons that players appreciate.

In Cogmind hacking is most easily performed directly, via the available list of valid machine commands marked by letters and with percentages reflecting their chance of success, but sometimes players want to carry out more difficult “indirect hacks” of unlisted targets by keying them in manually.

Manually hacking a terminal, including use of unlisted targets.

Forcing the player to remember the information required to take advantage of this strategy, and type it repeatedly, may seem like unnecessary requirements. We have computers to do that sort of thing for us, while we apply our brain’s processing power instead to problem solving--what exactly to do when. That’s the more enjoyable part of games for most players. (Note that it is, however, quite in theme to be typing hacking commands without any form of assistance, and at least one player specifically requested that none of these features be available, so it is possible to turn them off.)

Repetition was initially addressed in part by the “hacking buffer,” allowing players to automatically cycle back through previous hacks (including those during previous runs), or even modify the buffer directly as an external text file.

Cycling through the manual hacking buffer to repeat previous commands.

But the buffer is more suited to recent hacks, since it’s cumbersome to cycle back through dozens of entries to find a particular one, in which time you may as well have just typed the command out again :P. There are buffer features like automatic removal of duplicates and non-existent commands, but they only go so far.

Thus we have several more features to aid the hack-minded Cogmind…

Unique Codes

Any part of the game that causes extra non-fun work for the player is a candidate for streamlining, and when the story portion of the game exploded in Alphas 8 and 9, unique codes for manual hacking became just that.

Obtained by talking to NPCs or accessing certain terminal records, these codes could then be entered while hacking other machines or robots elsewhere in the world for some kind of effect. The problem: using them meant having to know them, which meant having to write them down, or even worse, scrolling way back through the message log to find where they were last referenced. I made the codes short (only four letters) to facilitate this, and at first there were only a couple anyway so it wasn’t much of an issue, but with more plot comes more codes, and neither of the old approaches were satisfactory--scroll searching was a slow process, and writing them down would often be wasteful since they might never be used. (Note that these codes are randomly generated, so they change every run.)

The UI does all this automatically now. Mouse players can simply click on the code they want to input, while keyboard players first type the normal code hack prefix (“\\”) to switch focus to the code list where they only need to press the corresponding letter key. The list even conveniently includes who gave it to you and where.

Interacting with the terminal code assist feature.

And the same feature is available for manual hacks targeting robots, not just machines:

Code assist feature activation while manually datajacking a Sentry.

No more writing down codes :D

Autocompletion

Us coders have autocomplete for our source hacking, so why not give it to players, too? :)

There are currently 82 machine commands in Cogmind, and while I’ve attempted to use relatively systematic naming conventions, it’s still a lot to remember, especially those which aren’t used so often. And even when players do remember exactly how to hack their target, the occasional typo is also annoying.

The solution is to take whatever the player has typed, even as little as one letter, and start narrowing down the possibilities, compiling a list of all matching commands and displaying the first as grayed out text, possibly followed by a number indicator if there is more than one match available. All the player has to do is press spacebar or tab to accept the gray text rather than typing it out in full, or keep typing to narrow down the possibilities, or press up/down to cycle through the other matches!

Manual hacking gets autocomplete!

From the outset all common commands are considered for the autocompletion list, while unauthorized hacks learned while playing are considered only after discovering them, information that is carried from game to game. This is to avoid spoiling secrets that are intended to be learned through regular play (NPCs and terminal records provide this info), though players who for some reason don’t have their user data from previous games (or those who look up spoilers) can type the commands out manually and they’ll be permanently considered “learned” as well.

The automated recording of secrets learned via lore is itself helpful for hack discovery, in case a player didn’t notice or forgot what some NPC told them (and doesn’t want to search through their lore collection UI for it :P), since simply typing “Trojan” at the command prompt (or really even just “tro”!) will list all known Trojans for that machine. (“t” and “tr” work, too, but there will also be non-Trojan matches due to trap-related commands.)

Indirect Queries

Querying terminal records often returns results that themselves contain further topics to query, forming a web of potential lore. Mouse users can simply click on these other topics to attempt to hack them indirectly, but keyboard users have always had to type out the Query(Topic) command manually.

Until now.

When keyboard mode is active, reference numbers appear next to each available topic and simply pressing the corresponding number key will attempt to hack it.

cogmind_manual_hacking_keyboard_quick_query

Hacking a chain of lore-related terminal records purely via keyboard, using reference numbers.

The system only supports the ten most recent topic references (because number keys), but that’s plenty enough to have full access to several consecutive hacking results. After the tenth topic, the numbers will wrap back around to 1 again.

To reiterate, mouse users will not see the numbers, and I don’t think keyboard users will be impacted too much in terms of readability, since the numbers are grayed out and one can learn to ignore/read past them until they’re needed. The affect on readability was, however, one of the main reasons I repeatedly postponed implementing this feature. In the end I’ve decided that convenient functionality is more important, and actually kinda think they make the entry text look cool, anyway :)

Another query-related bonus feature for both mouse and keyboard users is that these topic references themselves now also include a ‘!’ prefix to indicate that a particular record has not been read/discovered before, to facilitate lore collection.

cogmind_manual_hacking_mark_undiscovered_lore

‘!’ marking lore records that haven’t been hacked yet.

This is the same indicator that appears in the machine target list for direct queries.

Addendum

None of the features mentioned in this post are necessary, but they sure are convenient! Why weren’t they just implemented to begin with?

The most obvious answer is time. A lot of work goes into the base features and UI itself, and by the time each is complete and able to get the job done, all the test have been run, the kinks worked out, the bugs fixed… it’s really draining and often feels about time to move on to the next thing :P. Besides, there are always other pressing features that need attention, too! Thus many ways to further improve an experience often end up filed under “Maybe later?” This is fine because it feeds into the second reason:

Sometimes rushing to add “improvements” turns out to be a bad idea. With a working foundation in place, time permitting it’s always better to watch how players use a given feature, listen to how players talk about it, and use it yourself. With more use case data, over time even better solutions might become apparent. Development that moves too fast in one direction without waiting for intermediate results is more likely to waste time, as efforts might clash (either code-wise or UX-wise) with another feature which isn’t as mature.

So in my case I keep a list of features like these and revisit them occasionally to look at them from a new perspective, maybe add some more notes, and when a particular feature hits critical mass (sometimes pushed over the edge by player requests or what I hear players talking about :D), it becomes the next implementation target and will find its way into a near-term update.

Posted in GUI | Tagged Cogmind, Hacking, UI | Leave a comment

Newsletter

Join the mailing list below for occasional development updates.

Email:
Stay Up to Date
- RSS (posts)
- RSS (comments)
- Mastodon
- Patreon
- Discord
- /r/Cogmind
- Indie DB
Links
- Grid Sage Games
- Announcements
- Forums
- Patreon
- Cogmind
- POLYBOT-7
- REXPaint
Recent Posts
Recent Comments
- Anonymous on Hacking, the InterfaceCY-PHR sounds like such a troll of a bot, and it probably be very annoying (in a good way) as well as dangerous
- Kyzrati on Hacking, the InterfaceGood point, and a good reminder from this now-ancient article :) Obviously never took that direction in the regular game, but yep ...
- y0un65t3r on Hacking, the InterfaceSome of these unused hacking risks would make epic CY-PHR mechanics!
- Kyzrati on Adventures in Map Zooming, Part 2: Engine-level ArchitectureUm, yeah, complete overhaul so not something that would ever happen for that reason alone (unnecessary now), although just as impo...
- Kyzrati on A Simple Approach to Player-Designed RobotsYeah it's turned out quite well! (and we've been having a lot of fun with these things even outside the game, as you can see...
- Kyzrati on Fog of WarYeah it's a pretty old post at this point, and I remember that was a fun article but they must've changed their link structure, or...
Archives
Categories
- Annual Review (11)
- Art (12)
- Cogmind Beta Overhaul (6)
- Design (72)
- Dev Series: 7DRL Postmortem (4)
- Dev Series: Fonts (4)
- Dev Series: Full UI Upscaling (5)
- Dev Series: Map Zooming (5)
- Dev Series: Procedural Maps (7)
- Dev Series: Sound Effects (6)
- Dev Series: Story in Roguelikes (3)
- Dev Series: Ultimate Morgue File (4)
- Game Overview (3)
- Gamedev (14)
- GUI (24)
- Internal (6)
- Marketing (5)
- Mechanics (31)
- Meta (7)
- Post-Mortem (5)
- Release (4)
- Uncategorized (8)
Search
This blog is now for long-form topical articles. For most game updates and other news see the regular forum announcements!

Development Blog