Official development blog

Weaving Narratives into Procedural Worlds, Part 1: Value

There’s been very little discussion of Cogmind’s story here on the blog, which belies its informative role and importance throughout the alpha development process. In fact, following the mediocre stock sci-fi back story given to the 7DRL, on rebooting the project in 2013 the very first stretch of Cogmind development was actually devoted solely to fleshing out a unique story in great detail. Everything afterward would serve to support that narrative in one way or another.

Now that said part of the game world has taken shape and nears completion, it’s time to venture into new territory and discuss the whys and hows of integrating story elements into a genre traditionally light on story. This is the first in a three-part series:

  • Part 1: Value
  • Part 2: Characteristics
  • Part 3: Methods

Note that this series is specifically about static narratives in procedurally generated worlds, and not generating the stories themselves! There’s quite a distinction between the two :)

(As usual I’ll be avoiding spoilers, although in this case it’ll mean fewer concrete examples until we get into Part 3.)


Naturally the first question here is why would we want to include a story at all? Roguelikes are not strict RPGs, and rarely put much effort into storytelling. In fact, there is even the danger of story ruining/interfering with what makes roguelikes great in the first place (a point we’ll touch on several times).

However, I’d argue that when used carefully there are quite a few ways in which story elements can enhance the roguelike experience, making them a potentially valuable addition. Let’s look at some of the benefits, which double as goals when designing a new roguelike.


The value of story elements in a roguelike, an overview.

World Building

Theme and setting define a roguelike’s starting point when it comes to source material, but crafting a story on top of it all (ideally with multiple plot lines) takes it to the next level. A story requires that actors have motives and goals, and the whole world feels much more alive when for the purposes of storytelling actors have goals other than “approach and kill player.” Certainly mechanics and basic content like actor/object descriptions can go a long way towards reflecting the nature and state of the world, but a full-on plot reinforces it all in the strongest way possible: through action.

Seeing the game’s lore in action really brings it to life, giving it added meaning beyond the words. From the beginning this approach has been important for Cogmind in particular because it strengthens the immersion, a focus of the whole player experience I’ve been going for. And on the development side that same desire to bring everything to life drives development to dig deeper. As the game world expands I’ve often asked myself “wouldn’t it be neat if the player could actually visit that place? Or meet so-and-so?” And then suddenly there they are, being written into the game :D. As a result the world has gotten increasingly dense over time, with each new piece reinforcing one or more others.

Meaning & Purpose

Roguelikes infused with story elements also gain additional layers of meaning on top of whatever might happen in the world, contributing to a more “epic feel”--the world is definitely bigger than the player character, who can have a greater purpose beyond being a “murderhobo.” With the 7DRL version a short back story merely provided the premise, good enough for a straightforward dungeon crawl, while I can’t imagine the Cogmind of today without its deep and engaging story. Whole new maps and interactive NPCs were added to allow the player to influence the world in different ways, because it made sense in the context of the greater narrative.

Interactive stories also offer a good source of memorable crafted experiences, which can be even more complex and powerful than standard roguelike encounters because a story is capable of spanning multiple locations and events. For example, in Cogmind the player can visit a certain area where all hell breaks loose, which in turn affects other areas after that, the details of which could depend on other player actions. The story links different locations and actors in numerous ways, supporting a grander scale that few roguelikes attempt to tackle. (Lots of room to innovate here!)

While exploring the resulting web of possibilities, individual steps along the way provide the player with explicit intermediate goals. This means a greater number of “things for the player to do,” generally a nice quality to have in a roguelike wherever it makes sense. These can be rewarding experiences in themselves, experiences that extend beyond simply killing things…

But it’s worth noting that depending on its execution (covered in Part 3), the presence of a story does not have to completely supplant a player’s own narratives, either. I’ve noticed players coming up with their own little stories all the same, just as they do in other roguelikes, based on the danger, unexpected RNG shenanigans, close saves, and deaths that come out of isolated encounters which may have no bearing on the wider plot. This is important because it’s a valuable part of the roguelike experience, and demonstrates that it’s possible to include a story without drowning out the emergent mini-stories made possible by procedural generation.

So aside from moment-to-moment survival and long-term progression strategy, story becomes a third potential target for player enthusiasm and purpose. This advantage works on both an individual and community level…

Generating Interest & Discussion

Exploration is a fundamental part of roguelikes, be it of mechanics, new content, or simply unrevealed procedural map areas. Having a story gives players yet more reason to care about (or justify) events in the game world, along with hooks which in turn drive exploration to find answers and/or uncover secrets. Not that the extra incentive is required for the game to be enjoyable, but it’s nice to have one more channel through which players may connect with the world.

This feature also works on a wider level, from two people playing alongside one another to the community at large. Story elements become common points of reference, allowing players of an otherwise single-player game to share experiences in the same way they can talk about mechanics and strategy. Lore, locations, NPCs, motives, factions and more all become part of the “common language” that players internalize as they explore the world and what is happening in it. For anyone following along with the latest release, or who isn’t spoiling themselves with the wiki, there’s plenty of speculation to go around. From my perspective, it’s been fun to watch the community puzzling out what’s going on :D


Players talking about secret plot spoilers in public chat :)

Other aspects that contribute to the overall discussion and level of interest, both with regard to those outside the community looking in, and within the community itself:

  • All the minor actors and events that players talk about, some of them quite memorable like “the annoying derelict” as everyone has come to know a certain NPC with no particular name.
  • Story also adds another dimension to seeded runs, where different players may take the same or different approaches to the same set of story-related encounters.
  • Relatively rare events are especially meaningful, including those which rely on a chain of actions. There are a good number of comments along the lines of “I saw…!” and “Have you ever seen?!” Just last week a major plot event added to the game ten months ago was discovered by a player for the first time :P

In all it appears there’s a lot of value in building a roguelike around a good story, assuming it’s done right, but we’ll get to that  :)

Part 2 of this series is coming next week, to talk about the ideal characteristics of a narrative for use in a procedural world.

Posted in Dev Series: Story in Roguelikes | Tagged , , , , , | Leave a comment

Roguelike Celebration 2016, the Experience

For years I’ve wanted to participate in IRDC, but they’ve always been held in Europe, or as of last year the US East Coast as well. Both destinations are too far away and too expensive for me from here in East Asia, so I definitely paid close attention when news first popped up of a new roguelike event on the West Coast.

Initially the plans for this Roguelike Celebration started out relatively small, however, and as “close” as it was, I couldn’t quite justify the cost in both money and time. It wasn’t until July that the list of attendees started to grow so quickly that I began rethinking my decision to skip it. Even the original creators of Rogue would be there, and Tarn and Zach Adams were coming, too. Clearly this was becoming an opportunity not to be missed, so I contacted the organizers to confirm I could sign up to do a talk (to make the trip extra worthwhile :D) and bought a plane ticket the next day. It helped that my brother lives across the street from the venue, otherwise adding in the costs of accommodation would’ve really pushed the limits of my meager budget since I also needed to arrive several days early to at least somewhat get over the effects of jet lag.

So the stars were apparently aligned and I could finally take part in a roguelike event, and actually the first ever video game-related event I’ve been to.

And the Roguelike Celebration wasn’t just “an event.” As the list of participants snowballed it turned into the largest roguelike gathering in history, one that it felt great to be a part of, and one of the most amazing experiences I’ve ever had as both a developer and fan of roguelikes. I got to spend time chatting with Tarn and Zach Adams (Dwarf Fortress), Brian Bucklew and Jason Grinblat (Caves of Qud / Sproggiwood), Thomas Biskup (ADOM), Jim Shepherd (Dungeonmans), Brian Walker (Brogue), Santiago Zapata (Ananias and a zillion other roguelikes), Sabouts and Rogueliker (Let’s Players), Gabriel Santos (Stone Story), David Craddock (Dungeon Hacks author) and so many others.

At the end of the day we got a group shot of many of the speakers, devs, and organizers:


Roguelike Celebration speakers, developers, and organizers. (Click for larger size, or get the full-resolution download here, for all your devious Photoshopping needs. List of those pictured here.)

Not that we took a survey, but it was pretty obvious the average age of the participants (audience and everyone included) was easily in the 30s.


Noah Swartz and his co-conspirators did a wonderful job putting everything together over the preceding months, and on the evening of September 16th it was time to check out the venue and prepare it for the next day. This mostly involved moving some tables and chairs around and talking to the volunteers about various tasks to come.

There was no official get-together the evening before, and I wanted to hang out with other roguelike folks if possible, so I planned to wander over there around the time this preparation was likely to happen. Again, it was across the street, so this was quite easy to do :P. Except for the fact that I was also planning to meet up with Sabouts on the way (his hotel was right next door), but the last pic I’d seen of him didn’t involve a big fuzzy beard, so I didn’t recognize him at first and walked right by. (I found him after a few minutes…)

This became a recurring theme at the celebration since many of us had never seen one another (even a picture), and it wasn’t exactly small (~200 people), so even someone that you knew must be there somewhere, was probably not all that easy to find.


The main room where Track 1 talks were held, as seen the day before. Track 2 talks were in a smaller corner room with bleacher seating, and several hallways connected both of these to the entrance areas, restrooms, etc. Everyone was not in the same area at the same time.

We saw a group of people waiting outside the venue building, and while I recognized Brian from his frequent Twitter pics, he 1) had no idea what I look like and 2) thought I introduced myself as “John” rather than “Josh” (it was somewhat noisy by the roadside). Shortly after that we had to register at the security desk, and then he realized I was the guy he’d been chatting with for a while online :P. So yeah, things like this happened a lot--the next day there were plenty of “oh you’re [insert familiar name here]!” moments.

Prep also involved Britta and others setting up their atmospheric decorations, including a table covered in NetHack scrolls and many other props,


Roguelike shop?

and walls adorned with posters of giant ASCII characters, or the perfect phrases:


Mind the stairs.


On the main entrance/exit.


Eventbrite generously let us use their offices for a day. (This is not a normal public event space.) Curses on these iceboxes were conveniently removed once all the roguelikers dispersed.

Celebration Day

Even having arrived in the US on Tuesday, come Saturday I was still having problems with jet lag, waking up at 3 AM and just kinda waiting until 6:30 to get up xD. No doubt the excitement also played a part there :D

I headed over as early as I might be able to get in, and hung out inside with Tarn and Zach while attendees started gradually filling up the entryway.


The Roguelike Celebration is about to begin!

There everyone picked up cool shirts, and speakers even got unique shirts:


Such an awesome speaker shirt.

Other roguelike items up for grabs included pins and even @ socks!


Socks of RNG +10 for everyone. And a challenge coin for speakers.

(Designs by Allison Hughes.)

At sign-in everyone got a lanyard ID, but the low-contrast colors and small size did not really serve as an aid to finding people, seemingly appropriate at a roguelike event :P. But whatever, it looks good and is a nice souvenir.

Fortunately in my case I had my Cogmind shirt so it was nice to be walking around and have some people recognize me from that, and of course in terms of speakers we could finally identify who was who after their talk. There were certainly those I’d missed for much of the day and only later found--Thomas Biskup and I said as much when we traded places on stage. So many roguelike people!

Overall organization was great, with talks proceeding on schedule and no big hiccups, no doubt facilitated in part by the professional AV help. I was mostly focused on listening to talks and meeting as many people as possible rather than taking pictures, but do have a few random shots from the process that I can share here.


Noah kicks it off.


David Craddock moderating a talk by the creators of Rogue, Michael Toy, Glenn Wichman, and Ken Arnold (left to right). This was the first time they’d all been together in 30 years.


Nicholas Feinberg talks about weeding out boring optimal play, among other topics, in the context of DCSS.


Jim Shepard covers the importance and methods behind maintaining a focused tone throughout a game.


Tarn and Zach Adams pack the room when talking about their early games and inspirations.


Thomas Biskup giving an overview of ADOM’s complete development history, from beginning to today.


Brian Walker analyzes approaches for creating good gameplay.

All the talks were streamed live (with around 200 online viewers), and later uploaded to YouTube here. Check them out!

My own talk is here. Also, my slides themselves are actually accessible online as well if you just want to look at pretty pictures rather than watch my ugly mug and listen to that voice--I, for one, refuse to listen xD

I was unbelievably nervous, but apparently I felt it a good bit more than it came through, at least according to what others tell me… My mind was almost totally blank as I talked, which felt extremely odd, and I didn’t even reference any of my notes.

It was actually my first ever talk, and I learned a lot in doing it, so I’m pretty sure I could do a much better job next time! Reflecting on it, I should’ve done fewer slides about a slightly tighter topic, and gone a bit more in depth about each part, since the need to fit so many slides into 30 minutes contributed to my nervous rush. That could’ve also left some time for Q&A, which would be more fun and makes sense for a live event. I’m so used to writing long articles and packing in everything I can, heh.

Still, I’ve never been good at talking to crowds unless it’s completely spontaneous, otherwise I tend to put so much thought and planning into it that I end up paralyzing myself. Ack :P


Blathering on about something. (Photo courtesy of Santiago.)

The best part of the talk was where I didn’t have to talk at all, and just showed Cogmind’s [now old but still pretty representative] trailer to demonstrate the value of audio, and that went over quite well. I also later heard that the Twitch stream chat got quite active while I presented.

In terms of other content, I took my originally planned talk topic (innovation in roguelikes) and tacked it onto the end of my newer “becoming a developer” topic, giving it an ever-increasing weight until they were about even and essentially became two full talks in one. (I.e. far too much to properly cover.) As important as innovations are, I’ve never shared the full story behind how I became a developer, and knew it could be inspiring considering my non-professional background, so I really wanted to describe that process. Certainly since the talk I’ve heard from quite a few people who have been inspired to make a roguelike, so that much is a success.

That said, either topic would’ve been much better in isolation where I’d have time to provide more explanations, like those found in the notes which I ignored :)

Other results from my talk include several interview requests, and selling about 12 copies of Cogmind that day (much better than the average day, which is like 2). In fact, according to friends in the audience, several people at my talk bought Cogmind while I was talking, which I thought was pretty neat (and unexpected). I also heard that some people who would like to use it learned about my REXPaint tool via the talk, so that was good.

After Party

We ended up having to leave the venue earlier than scheduled. 8pm became 7pm, and 7pm became “let’s try and shift people towards the doors around 6:15 because everyone will stop every few feet to chat” (yes, we did :P). So no time to really play roguelikes or talk much right there after the event ended, but there was an after party at the Thirsty Bear, a bar with a sufficiently RPG-sounding name.


We took over one of the larger upstairs spaces.

Unfortunately a number of people had to retire for the evening, but we still had a good turnout at maybe a few dozen. There the majority stayed for at least a couple hours of meandering conversations, and I really enjoyed talking to Thomas (ADOM), Brian (Brogue), Santiago (Ananias) and others.

But it wasn’t entirely roguelike talk. Meeting in person is great for allowing conversations to drift through all manner of related subjects, and they did. On that note, everyone I met throughout the entire event was of course wonderful, as can generally be expected in the roguelike community.

I wasn’t on social media all day since I don’t use a phone (thus being away from my computer thrusts me back to the days of 90s communication), but there was apparently quite a flurry of online activity throughout the event, and it was fun to browse that the next day. Among the discoveries:


Garret Voorhees did some speaker sketches :)


I brought a shirt for Jeremy Mitchell because the Cogmind logo was changed to its current ASCII form in 2015 at his suggestion. Many thanks for that.

The End?

Is this only the first of many Roguelike Celebrations? Everyone sure hopes so. Whether you’re a player or developer, I highly recommend participating in the future if possible. It’s just so much fun, and an excellent learning experience, to be around so many other people with a shared interest that many of us rarely (if ever) get to share with our everyday IRL friends.

Sure you can still watch the videos, but that misses out on the all the little interactions and conversations that play out through the day. Getting to know existing roguelike internet friends on a somewhat more personal level is also neat.

Many thanks to Noah, Britta, Asheesh, and Allison for putting it together, and Eventbrite for hosting it. Several considerations for next time:

  • The earlier in advance the date and location can be set and announced, the more likely people will be able to attend, especially those of us who are further away.
  • The intermittent notifications/announcements prior to the event could be posted to a news section of the website to see how preparations are progressing, rather than only by email, since a lot of people miss mass emails for whatever reason. (I know I never even received the last one sent out before the Celebration--wasn’t found in spam or anywhere, but I heard from someone else that it existed and what it said.)
  • Depending on the potential turnout, a two-day event would be more appropriate (based on the size this year) so it’s not so rushed and leaves more time for talk and play aside from the talks themselves.

Keep celebrating those roguelikes!

Posted in Uncategorized | Tagged , , | 2 Responses

Ability/Effect Systems and Scripted Content

While most roguelikes include basic attack and defense mechanics as a core player activity, the real challenges are introduced when gameplay moves beyond bump-combat and sees the player juggling a more limited amount of unique resources in the form of special abilities, magic, consumables, and other effect-producing items.

Just as they challenge the player, however, the architecture behind these systems often imposes greater challenges on the developer. How do you create a system able to serve up a wide variety of interesting situations for the player without it turning into an unmaintainable, unexpandable mess on the inside?

It’s a common question among newer developers, and there are as many answers as there are roguelikes, worth talking about here because it’s fundamental to creating those interesting interactions that make roguelikes so fun.

An increasing number of roguelikes are based on flexible entity component systems, though being born of a combination between my old 7DRL and an even older project built before I even knew what ECS was, Cogmind’s abilities are each handled by one of two unrelated implementations: hard-coded routines and trigger-condition-effect scripts.

Hard-coded Routines

The first system is dead simple, the kind of thing that you get when starting a game as a 7DRL :P. But, as a result it’s also the kind of thing unlikely to cause problems down the line as long as we don’t ask too much of it. (That was also the point of starting with it, to make sure nothing would go wrong on the technical side of things in the seven days available to create the game.)

In short, there are a set number of hard-coded item abilities, and an item can choose at most a single type of ability, and also assign a single integer to its variable which usually serves to define the degree of that effect. There are 95 such abilities in all:


Hard-coded effect descriptions, as seen in source, where “effectData” is the integer referred to above. I removed a couple dozen abilities due to huge spoilers! (I rarely hard-code text like this, but here it was easier to build some strings that require formulas, e.g. many of those not shown.)

If you look closely you’ll see that some are essentially identical to others, differing only by a single factor and thus not really providing additional unique behavior. That reveals one of the limitations of this kind of system: it doesn’t well support slight variations on the same behavior without extra code, something that a more complex system could do quite easily.

But once an effect is coded, it is extremely easy to assign it to an item, making ability-based items quick to design and compare.


List of sample items with their effects (other stats cropped).

So these abilities/effects are each checked for wherever they’re relevant in the game code, be it when an actor is attacked, attacks another actor, scans an enemy, is hit by a thermal weapon, is caught in stasis, or any number of other things happen. Some are simply direct modifiers to a stat, affecting it only while the given item is active (this was another 7DRL decision--values are always referenced by the function that calculates on the fly all factors which can affect them, rather than allowing changes to modify a value which is stored and referenced, since those changes may need to be undone later and that’s… really annoying and complicated).

In terms of behavior it has maximum flexibility since we can code whatever we want :). Examples:


Testing for the jamming effect.


Applying matter savings modifier.


Applying thermal absorption effect.

So far I’ve only mentioned items, but there are a smaller number of non-item abilities handled in a similar manner. Instead of ability types they are sourced from what are called “traits,” of which an object can have as many as necessary (but realistically most objects have none, some have one, and a very few have multiple traits).

Traits originally existed as part of the more involved second system I’ll be describing below, but in some cases it was convenient to borrow them in circumventing the old one-effect-per-item rule instated for the 7DRL, and also giving hard-coded abilities to actors and terrain (to which item abilities cannot be applied, but traits can). Despite the name, these aren’t always passive characteristics, and in terms of implementation they’re not really any different from item abilities (defined by way of a type-and-variable pair), so I won’t go into them here.

In addition to being simple to implement, the straightforward nature of this approach somewhat carries over to the player side as well--each ability-capable item can generally be expected to provide one unique benefit, a benefit that only differs from similar items by a single variable, making them easier to analyze and compare (fairly important in a game where you can equip up to 26 items at once :P)


Comparing the Improved and Advanced versions of the Weapon Cycler. Technically opening the info window isn’t even necessary to do the comparison, since their respective effect values are also displayed in the parts list’s info mode right on the HUD.

Scriptable Ability Objects

The other system is much more powerful, and while it’s still rooted in hard-coded effects, once the necessary code is in place it can be used as the basis for a much wider variety of possibilities.

This system was actually inherited from X@COM, where it enabled me to turn the X-COM world and ruleset into a fantasy game complete with classes, unique special abilities, dozens of spells and special items, etc, all in a few weeks. And that was purely via scripting--no code at all! (Around that time, other non-coder types were also able to use it to create interesting behaviors for their own mods.)

So with that as a background, let’s look at the underlying system that makes it possible…

“Abilities,” or really anything that might affect something else, are a type of (C++) object that can be created and assigned to one of the game’s primary object types (Entity, Item, Prop). The assignment occurs manually in external data files, and, more importantly for a dynamic system, at runtime by other abilities as the game is played.

Abilities themselves are defined in their own data file, by listing the trigger, conditions, and effects of each. Those individual components are all defined in source code, and work as follows:


An ability first specifies what causes it to take effect. Only one such “trigger” is allowed per ability, and at relevant points in the code the engine explicitly checks for applicable triggers. Example triggers include being hit by a projectile, moving next to a prop, a robot exploding, seeing another robot… dozens of them.


A single ability may have any number of effects, or multiple effects from which only one or some are chosen (the list can be weighted if desired). Example effects include dialogue, explosions, modify AI behavior, spawn an object, convert one object into another… again dozens of available possibilities.


The key to making the whole system dynamic is conditional application of triggers and effects. Those which only happen under certain conditions allow for much more interesting possibilities, as well as more complex relationships and behaviors. Thus both triggers and effects may be controlled by any number of conditions. Examples include a random roll, robot stat values, distance from player, what faction a robot belongs to, how long the ability itself has been in existence… (once again, many dozens :P).

Multiple conditions can be combined on the same element with the syntax A|B|C, and there is even syntax for more complex conditionals, like “A|[B|C]” is “A and either B or C”. Effects with conditions can also use the “contingency” system, so that a certain effect might only take effect if an earlier effect from the same ability did not occur for whatever reason (one of its conditions failed), or all previous effects failed, or all succeeded, or basically whatever :)

To demonstrate all the primary components working together, I’ll dissect a single “ability,” in this case really an event, that can occur early in the game when you visit the mines:


The MIN_Helper_Spawn script.

This particular ability is assigned to an invisible prop used to facilitate location-based events. PROP_INTERVAL is a trigger checked once every turn for any prop that has one, but in this case there are conditions: it won’t be triggered unless P_PLAYER_RANGE is within 10 cells, and its position is also visible to the player (the “(1)”, as opposed to (0)). When the player approaches and successfully triggers it, as per the SPAWN_ENT effect it will create a new entity (robot), but only if the effect’s conditions also pass, which in this case requires that the player not already have a Mining Laser in their possession. This effect, like many others, must specify a number of additional details describing the result, here the NUMBER and type of ENTITY to spawn, its FACTION, and optional values that tell it to FOLLOW the PLAYER and assign it another ability to define future behavior (Min_Helper_Helps1). When this entity appears it also says a line of DIALOG.


The same script in action.

All components (triggers/conditions/effects) might have various data parameters that help specify more about its behavior, such as AI details for spawning actors, the shape of an effect area, how to treat various special cases, and more. There are also generic data values applicable to most all components, allowing any of them to create log messages, particle effects, etc.

On that note, the system is fully hooked into the code-external sound effect and particle systems, so composite content can be created without touching the code at all.

It’s also tied into a system of global world state variables, to control the plot and other situations stemming from that--useful for conditions! For example, there is one NPC encounter that only occurs if you destroy a certain group of robots, but you have to get them all, so each one destroyed adds to the global counter, and later when you reach the NPC’s location one of its SPAWN_ENT conditions is that counter which must have reached the required number.

Effects may also mark objects with traits (mentioned earlier) that appear in conditional expressions, allowing even more complex relationships that can evolve over time. This application of traits would be more appropriately named “markers” given how they’re most commonly used. For example, there are a few special places in the world where an entire section of wall opens up when the player simply approaches. When created, as per its prefab definition each of those positions is marked with a specific trait. Nearby on the ground is an invisible “ability” object that triggers when the player passes by, and the effect is to send out an invisible explosion which checks for that trait on any walls that it hits, which are then “opened” using a particle effect while the original walls themselves are destroyed/converted into floor. Hm, can’t demo any of these here because they’re all secret :P

Even more interesting are abilities that actuaflly assign abilities to other objects, like the Molecular Deconstructor, but details on that bad boy are classified.

If absolutely necessary, for extra special cases the ability system can also hook into unique hard-coded behavior via the SPECIAL effect. When developing the original system for X@COM, I avoided relying on this one since the goal was to allow ability scripts to be able to define just about anything the game was capable of without access to the source (to empower modders), but with Cogmind the more important goal has been to finish the game, while some of the special events have so many wide-reaching consequences that it was deemed too much effort to make the necessary abstractions to further expand the system. Better to hard code and move on. Still, only a tiny percentage of effects are hard-coded, averaging about one per map (compared to hundreds of text-scripted effects associated with objects).

At heart it’s really a pretty simple system, but you can imagine the number of possible combinations here is massive, even with only a modest number of components of any one type. So with the right hooks into the code, and a script parser to make sense of a list of triggers, conditions, and effects, this can be used to create some cool stuff :D

A shorter version of this post previously appeared on /r/roguelikedev under the FAQ Friday by the same title, where you can also see how other roguelike developers approach this same topic.

Posted in Mechanics | Tagged , , | Leave a comment

The Alpha Release Cycle: Running a Successful EA Program

Just last week I put out Cogmind’s tenth alpha release, and as we speed towards the end of the open alpha period, now is a good opportunity to look back at the very deliberate pattern behind the development of each release, a repeating cycle that has continued for over a year now.

And not just development itself, either--I’ll also be describing how I use social media in parallel with this process, because that outreach and interaction with the community is important to growing and maintaining the audience necessary to drive a successful indie game (i.e. anything not backed by advertising dollars where you can basically just pay for your potential audience).

Hopefully by sharing my approach here, other game devs might learn something useful, and players will better understand what goes on behind the scenes while waiting around for a new major version to drop :D

One Month

Assuming no special circumstances or interference from external factors, I aim for one major alpha release every month.*

I’ve found that interest tends to wane when letting players wait too much longer than one month for new content and features. I’m sure the appropriate length of time here varies by game--for example something driven more by community content could easily go longer between releases.

A shorter two-week cycle (or even less) could work, but presents its own problems. It means that each release will naturally be less substantial, and therefore less impressive, and fewer people talk about things lacking impressiveness :P

So for marketing purposes it’s better to turn each one into a somewhat larger production, while doing so also increases the likelihood that players will feel that each new release is worthwhile, since it’s enough development time to address multiple facets of progress, namely work on a sizeable chunk of new content, make adjustments to existing mechanics and content based on player experiences, and provide fixes for any previously discovered issues.

As a full-time solo indie there are also residual tasks to deal with (e.g. community stuff) for each new release, and those are better to spread out than trying to maintain some unsustainable breakneck pace (it’s easy to be overwhelmed!), whipping back and forth between front-facing promotional efforts and internal dev work.

Thus a one-month cycle strikes a balance between making just enough progress to be considered significant, while not keeping players waiting. My cycle is divided into three distinct phases, each of which I’ll walk through in detail below.


At its simplest the cycle looks like this, but there are a lot of details in there.

*One month is the ideal, anyway. Looking back at Cogmind’s previous release dates, the true numbers show an average between 5-6 weeks. This is due to said special circumstances and external factors, including a multi-week community event, a recent vacation, and a detour to build the technical foundation for a large unique part of the world. I also write at least several blog posts and other articles per month (like this one :P), and the time to do that has to be edged in there somewhere.

Phase 1: New Content

Half of the cycle, the first two weeks, is devoted almost purely to completing the majority of the release-to-be’s new content. For Cogmind that means working on new maps and the lore, NPCs, dialogue, plot elements, and sometimes new items that go along with them.

So I’ll generally spend the first day of a new cycle sketching map layouts on paper, followed by figuring out what parameters my mapgen utility needs to meet that criteria.


Working on a variety of maps in Cogmind’s mapgen utility. I’ve written a lot about map generation before.

I also write up a text file for each new map that describes its layout, inhabitants, special encounters, and summarizes its gameplay value in terms of challenges and how it could fit into a player’s long-term strategy. Here is an example of such a file for the Recycling map, one of the less involved areas but it still gives you a clearer idea (warning: minor spoilers if you haven’t played! This is also why I can’t really show files for other/better maps--the spoilers are much worse :P).

All of the above is a pretty organic process because sometimes the map might do a better job of informing the text, and sometimes the opposite is true, leading to a bit of back and forth adjustments between them until they align.

When the map is generating within expectations and will likely play as desired, all the other details start to go in, like prefabs and the other content listed before--everything that combines to make a map come alive.

New content comes first in the cycle because it’s the largest component of a new release, with the most moving parts, and it can be more difficult to accurately predict what its full implementation will entail. Maybe a new area needs a new mechanic to go along with it? Or an existing system needs to be expanded? If a release deadline approaches, little tasks can always be postponed to a future release, but a new major alpha release without complete new content defeats the purpose :P. Therefore it’s safest to get this out of the way early on, which has the added benefit of allowing further development to proceed with peace of mind.

On the Outside

When it comes to promoting Cogmind, my goal is to always have at least one image/gif to show for each week (if not more), which makes this first phase the most difficult in that regard since it is centered around either internal development of non-visual elements or content that I don’t like to spoil. Sometimes there’s just nothing to share!

To avoid breaking that rule, I might spend Friday instead working on some quick UI/visible feature that I can show, just to be able to keep putting something out there. It’s motivating to interact with players and followers over some new development, and from everyone else’s perspective they can see that, yes, progress is being made. Keeping that flow of information going is important.

Whatever I do have, I generally share to Twitter first, and sometimes other forums where Cogmind gets a lot of attention (Bay 12, TIGS), depending on what it is.


This sometimes includes development shots, since those following a game in alpha development are likely interested in the process itself. Above is the FOV transition detection test visualization.

At the end of each week, I also share whatever I’ve been doing to /r/roguelikedev’s Sharing Saturday, usually taking anything I’ve posted to Twitter and using that as the foundation for a post, adding to it notes on whatever else happened, e.g. blog posts, release details, plans.

By the end of this phase, it’s about time to do a progress report for the forums and /r/Cogmind, summarizing recent developments. Again, keeping players in the loop is crucial to maintaining interest, not to mention the responsible thing to do once the very first player has given money to support alpha development. They have a right to know, and it’s not very difficult to post a few words to update everyone on its status! For reference, here are the progress updates for the latest alpha: 7/21, 7/28.

Phase 2: New Features

The next phase is shorter, a week devoted to some bigger feature (or maybe two), either mechanics or UI-related, which is chosen by analyzing and weighing what’s most important to address, what’s most requested, and what’s most feasible at the time.

For Alpha 10 it was the lore collection UI and evasion stat summary window, Alpha 9 was the interactive machine overhaul, Alpha 8 was real-time FOV updating, and so on.


Cogmind evasion readout in action.

Regarding the feasibility aspect, it wouldn’t have been as efficient to implement the lore UI early on, since a good portion of what it was designed to access wasn’t added until Alphas 8 and 9. If implemented before that, it may have been necessary to go back and make adjustments later, meaning wasted effort! I never choose what to work on based on what I want to be doing, but rather what I should be doing at the time, after all factors are taken into consideration.

Developments in this phase are a good pair with Phase 1 because they are generally features that all players can experience. It’s nice to ensure with each release that there’s something new for everyone, especially those who may not yet have the knowledge or skill required to reach all the new content/maps (particularly in recent releases, as those areas are further and further from the beginning of the game).

On the Outside

This phase is much easier to share than the first because it doesn’t contain spoilers and the results are generally worth showing and very recordable (GIFs!). Anything big produced from Phase 2 is shared to all of the places mentioned earlier. Around the end of this week it’s also time for another progress update.

Phase 3: The Little Stuff

In the run up to release, the last week (or more often just 3-4 days) gets a lot more exciting. Accelerating progress is always exciting :).

Phase 3 starts with a review of the TODO list. I primarily organize development through a single text file containing everything from high priority plans, feature requests, known bugs, mechanic tweaks that came out of playtesting or reading about alpha players’ experiences, random thoughts of what can be improved, all the way down to low-priority long-term “maybe” stuff. Any dev time outside Phase 3, this list tends to get out of priority order as new items are thrown in (usually at the top), and priorities can also change with each release depending on the results of the previous release, among other factors.

Thus the first order of business here is to take the top section of that list, a realistic number of tasks to complete that would be nice to include in the next release, and reorder them based on priority.

While the previous phases focus only on the new, this one includes all three components of development: simple new features, changes to existing content/features, and bug fixes.

All bugs are immediately prioritized to the top, since I won’t release until all of them are fixed (there usually aren’t too many, and nothing serious). By leaving this for the end of the alpha cycle, all the bugs in the previous release will have been found (most I find myself while playing, since I know how everything is intended to work and can spot them relatively easily), so all of them can be solved at once.

Remaining items are prioritized according to the same factors considered in Phase 2, in addition to how long each might take to implement.


An excerpt of what a post-prioritized list looked like for Alpha 10 (click for full size). This file is actually named changelog.txt, because it also includes the current and all previous changelogs, with earlier versions at the bottom, the current one at the top, and all the TODO items in the middle, where completed TODO items can be immediately reworded and shifted right up to the changelog.

Notice that a given listed topic may also have a link to a forum thread, some other web location, or even a player’s name. Whenever applicable I’ll save links to any relevant discussion on that topic, often useful for reference once I’ve inevitably forgotten the details (way too much to keep track of!). There some of the reasoning will have already been done--usually including my own opinions at the time--thereby shortening the implementation process and offering different points of view against which to compare my more recent thoughts.

As mentioned earlier, this list can be cut short as necessary if release day is approaching, which is why it’s saved for last. I’ll just keep chipping away at it until I run out of time, and anything that’s not done continues to survive on in the list for future release work.

My workload for this phase is not purely time-based, however. Just as important as fleshing out the “something for everyone” aspect of a release as begun in Phase 2 is the desire to ensure the changelog reaches a certain length. Yes, length as in number of lines :P. Examined closely, changelog length is a poor metric for the quality of a release; after all, a single item may take as little as a few minutes to implement, while another line may represent an entire day’s worth of work, if not more! Regardless, appearances are important, so if a release is imminent and the changelog hasn’t yet reached my prescribed length, I may choose to promote a few easier tasks to fill it out.

Besides, we already know that the release is a good one from an experience standpoint, because that’s what the first several weeks were spent ensuring :D

On the Outside

This is by far the most outwardly prolific phase, and as such there is no shortage of images to share. Release day is also not far away, so towards the end of this phase I screenshot features and record gifs (LICEcap is great for that, and I optimize the results with gifsicle), and collect them all into an “Upcoming Features” post in lieu of a standard progress update. Here‘s an example from Alpha 10. And 9. (They’re cross-posted to the subreddit, too.)


List of images collected to demo Alpha 10 features.

This is also generally when and where I’ll imply that the public release will be coming within the week, though I never announce specific dates because anything could go wrong and there’s no sense in making a promise that might be broken.

There are also enough images here that I’ll be able to share them intermittently on Twitter, and often save one for the #screenshotsaturday hashtag on Twitter to maybe have a better chance of exposing someone new to the game.


Pre-release testing is important, but there isn’t all that much of it to do shortly before release given my approach to feature and content development. Each element added to the game undergoes extensive testing based on a list of potential problems prepared both prior to and during implementation, as different considerations are thought of at each stage. Whether brainstorming, designing, or coding, in the background I’m constantly asking “what could go wrong here?”, and jot all those possibilities down so that once the feature is presumably complete, every single condition on that list (which may be dozens of items long) is explicitly tested. It’s essentially a QA job, only in this case my deep familiarity with the source and systems makes it easier to think up hypothetical issues. Integrating this process closely with development of a single feature also increases efficiency, taking advantage of peak understanding of the new system and code behind it.

Before testing a feature, anything in the list which might affect other test items is shifted to the top, and nearly every change to the source is immediately compiled into a new build for testing before moving on to the next item. Compiling is quite fast, as is testing on the game side with the help of debug mode, where it’s easy to teleport around, spawn objects, reveal maps, and basically control any aspect of the game necessary to confirm or disprove issues. Finding bugs before they reach players is a worthy goal, and a good debug mode is essential for quickly setting up test scenarios to stay as efficient as possible.

With that kind of process throughout Phases 1-3, there isn’t as much need for a dedicated testing phase. But in game development, complexity rapidly expands with the number of interacting systems, making it difficult to fully predict the results. A portion of issues will inevitably make it all the way to players. However, testing still plays a vital late-cycle role in preventing the worst problems: crashes or known errors caught by assertions in the code. And there is a pretty good way to keep these out of the release: automated testing.

The goal with automated testing is of course to get maximum coverage, for which I have two main setups.

The first is aimed at map generation, an extremely involved process from building the initial layout to defining its contents with the help of scripts. In this test the game starts normally, loads the first map, chooses a random exit and builds that next map, and continues like that to the end of the game before starting over at the beginning again.


Mapgen auto-test. This one I usually let run for a few hours, directly in the debugger, and that’s enough to feel safe.

The second auto-test is aimed at AI behavior (both central and individual), combat and many of the game’s other mechanics, looking to crash or bug out by repeatedly loading different maps and pitting a wide variety of different opponents against each other. Hundreds of them, in teams. In a game where the world is already pretty alive with robots carrying out their regular duties, this gets pretty chaotic, and chaos is good for testing :).


AI/mechanics auto-test. This one is carried out in four separate games running in parallel, all four of which will continue running overnight. If none of them encountered any issues then it’s safe to say it’s ready for release, otherwise any problems are fixed and all four will be run again the next night. Normally the player is automatically teleported to a remote inaccessible location so as to not interfere with the tests (their turn is simply skipped), but if you want to see some of the AIs blasting each other, I recorded that here :D

Testing sometimes overlaps with the latter part of Phase 3 because in a worst case scenario it might be two or three nights before the all clear. And the worst thing that can happen to a player is to have the game crash, so it’s vital that these thousands of runs are played by my laptop first--laptops never complain if the game crashes :P

Release Prep

The day before release it’s time to package it up and get ready to put it out there.

To make sure I don’t forget anything I follow a simple step-by-step checklist:


Pre-release checklist (the content is explained below).

Once the game is zipped up, I unzip it and run to confirm a fresh copy is working as expected, and that often evolves into a couple hours of playtesting, mostly for fun (it’s hard to stop :P) but also to be on the lookout for anything glaringly wrong. On average there’s usually one thing that I notice which needs a quick fix, so I do that and slip in a new executable.

Then I pre-write all the release announcements for the next day:


Announcements ready!

The first and most important would be the release notes, which give a more in-depth explanation of major features than the changelog can. (Ex: Alpha 10 release notes.) That’s followed by reformatting it for /r/Cogmind, and the simpler versions prepared for other forums.

For each of these announcements I follow a similar format each time (which varies somewhat by channel). It’s nice to have something that works and just follow it, to save time and effort.

I also screenshot the changelog, which will be sent out on Twitter. I always highlight the more noteworthy additions and changes by highlighting them, so the list is easier to parse for those looking to get a general idea. That highlighting carries over to the other forums (and subreddit) where I also post it.

Altogether the prep process can take the better part of a day.

Release Day

Release day itself is almost always a Tuesday or Wednesday, because

  • More people are paying attention to social media around that time, so more likely to hear the news (including non-players who might be hearing about it for the first time).
  • Fewer players will jump on the download right away, meaning I can get in a hotfix (if necessary) before an issue impacts too many players.
  • I wouldn’t want to be dealing with issues over the weekend, which is more likely to be family time.
  • This leaves Monday open to do final prep work, and extra time over the previous weekend to do more auto-testing when I might not otherwise be using my computer for development. (Testing must be done alone, because my dev machine is a five-year-old old cheap laptop :P)

Aiming for specific days of the week is another reason a single alpha cycle might have a few extra days tacked on, as mentioned in the beginning, because I’ll have to wait around for the next window.

With all the real work having been done the day before, first thing in the morning (which is actually evening in the US where most of the players are, because I’m in Asia) I’ll open up all the targets for pre-written announcements and start filling them in--multiple forums, the subreddit, YMLP, Twitter, Facebook, Rogue Basin, etc.


Getting ready to post all release announcements.

So I’m mostly on autopilot, which is good because I’m kinda not entirely “with it” early in the morning, sometimes even more so after staying up too late the night before to make sure everything is in order for a smooth release.

With that ready I’ll upload the latest build to FastSpring, the distribution system, at which point anyone can now get the latest version but technically won’t know about it until the announcements are made.


Updating a product in FastSpring.

This is where everything is done very quickly, because it can be confusing for a new player if they buy while I’m in the middle of a version transition, i.e. getting a newer version than has been shared.

As soon as the game files are ready, I’ll immediately upload the server file containing the release news and latest version number, which notifies anyone who starts up the game that a new version is available.

Then I release all the announcements at once.


Then I sit back and relax. Sort of :). Each time it’s a huge relief to have yet another release behind me, and I’m generally pretty tired from the inevitable accelerating pace towards the end of a cycle, but there is always more to do!

I’ve got to update the roadmap on the FAQ:


Latest iteration of the roadmap. It’s great to have a place where players can both see how much has been done, and watch progress towards major milestones.

As part of the announcements I send out email notifications to owners, using YMLP, a newsletter service provider I can’t recommend. (MailChimp is presumably better, but they’re more expensive and better for high-volume senders, whereas I don’t send out emails very frequently--nor do I have much money xD) Despite repeated changes to avoid the problem, these days the email is filtered as spam for some users of some email providers. There are so many ways to get the news and many players follow progress one way or another so I’m not worried about players not knowing. But I still keep an eye on the YMLP outgoing email monitor to see what portion of owners are receiving and opening the email.


YMLP mail monitor.

I’ll also be monitoring the forums, email, and chat for issues with the new release. Anything serious will get an immediate hotfix, which I’ll usually turn around within an hour, and if it’s still release day I’ll probably do it as a stealth update to the existing version rather than going with a minor version increment, also providing a publicly downloadable patch for anyone who already got the release.

For each release there are feedback threads on the forums (example) where alpha players can discuss the latest release without cluttering up the forums with separate threads (and are more likely to offer feedback when there is an explicit place to do it). These and other forum threads are where the majority of my notes (i.e. the TODO list from earlier) on what to tweak will come from.

More recently I’ve taken to releasing interesting stats and player metrics from the previous version, since the leaderboards are wiped with each major release. For example:


Alpha 9 stats posted here after the Alpha 10 release.

Players enjoy stats, and developers can also learn something from the metrics:

  • 81% of players use fullscreen (i.e. 19% play windowed)
  • 10% use hjkl for movement
  • 21% prefer ASCII over tiles
  • 27% use only the keyboard, no mouse
  • About half of players stick with the default font, while the rest are divided up among many fonts, but among them Terminus and the older default are the most popular

While I’m at it, some resolution stats, which aren’t too unexpected since we can see similar trends in the Steam survey results: 46% use 1080p, 15% use 768p, 26% use resolutions in between, 12% use resolutions above 1080p.

I also post a different kind of release announcement to IndieDB, one that mixes the changelog with all the preview images collected earlier, but wait until the first Friday after release to do that.

It’s fun to stream the new release, which usually comes with a new weekly seed, though my laptop apparently can’t handle streaming anymore so I’ll get back into that when I finally get a new one :P


Even if other devs don’t use this same pattern, the point is to figure out a cycle that works and stick to it! The details will vary by game and individual, but it’s always nice to maintain a consistency that players can appreciate.

I can say that Cogmind would have a very hard time being successful without repeatedly reminding everyone it exists through both visual progress updates and meaty version releases.

From time to time I receive emails and PMs from appreciative players, and while I was writing this article a follower posted one of those comments that makes a dev feel all warm and fuzzy inside, and happens to be really on point here, so I’ll temporarily suppress my ego-blocker to reproduce it here:

“Not to needlessly inflate your ego or anything, but you are without a doubt the best solo project developer I’ve ever seen. Your first playable version of the product was shockingly polished. Your steady stream of updates is unmatched. The super low level of bugs per release is actually straight unbelievable. Your dedication to using your own new ideas rather than easy tried and true mechanics is in a league of it’s own.

Following your progress I feel like I’m witnessing the output of a team of veteran programmers under time dilation.

I don’t know how you do it.”

Maybe there’s some value to this approach.

Note: Regarding the subtitled “successful EA program,” there are definitely other aspects to discuss such as the important issue of pricing, but I’ll write about that another day once I have more data to share!

Posted in Gamedev | Tagged , | 2 Responses

Tutorials and Help: Easing Players into the Game

With a generally lower barrier to add content compared to other games, roguelikes have a tendency to be packed with features and mechanics, and while that doesn’t characterize every roguelike out there (notably 7DRLs and other quick hobby projects), there is an important need to help new players overcome the initial barriers to learning a new roguelike. At least if we want those new players to stick around long enough to learn what’s so fun about it :)

Many roguelikes do borrow a portion of their paradigms from prior games in the genre, be they common keyboard commands or ASCII meanings, and that helps lessen the burden to some degree, but there will always be plenty more to learn. So the question is how do we teach it?

Traditionally roguelikes would come with an explanatory text file, and probably a ‘?’ page/window in the game itself, but little to nothing else. Even today some roguelikes still leave it at that. But game design has evolved quite a lot since the early days of roguelikes, and players are familiar with (and often come to expect) many more help-oriented systems, so we’re seeing an increasing number of roguelikes that incorporate them, especially after migrating away from terminal displays and grid-based, ASCII-only graphics.

Some players are more forgiving than others, and will slog through a slow and difficult learning process in the hope there is an interesting and fun game on the other side, but with easy access to a large and growing selection of games these days, player attention spans and willingness for punishment have declined significantly. To reach the most potential fans possible, new roguelikes need lower barriers to entry so that those who might enjoy the game--but not learning it--make it through that first stage.

That was my starting point for designing Cogmind’s help-oriented features, and here I’ll be discussing the most important ones.


First off, the easiest way to help a player is to make it so they don’t actually need help in the first place :P. Obviously that won’t work for all cases, but as a principle should be applied anywhere feasible. This is most easily applied to input, making important actions easy, intuitive, and accessible based on what players expect: Click on self to open status window. / Click somewhere to move there. / Click on an enemy to aim (shows a targeting line), click again to fire. / Right-click on an object for more information. / Drag item from the inventory to equipment list to attach them. / Drag them from the HUD to the map to drop them… Notice the common theme here is that these all involve the mouse. Full mouse support is a must for accessibility. Players can transition to partial or full keyboard use with time, once they have a grasp of the new mechanics and other components to learn. Why force them to learn everything at once if they don’t want to?


Drag-drop example.

For players who do eventually learn to use only the keyboard (or do it right off), which right now is 26% of Cogmind players, because the mechanics don’t have much overlap with other roguelikes there isn’t a whole lot of existing experience to invoke there. In fact, I can list them all here easily: ‘?’ for help, numpad/hjkl/arrows for movement, ‘f’ for fire, and ‘.’ for wait. That’s it. The rest are unique, and there are a ton of them, but in most cases there is a pattern, or they start with the letter of what they represent, which aids the learning process.

To teach any commands that the player hasn’t figured out on their own there are two separate ‘?’ pages, one for beginners and one for experts. This is to avoid overwhelming new players with a page full of commands they won’t need right away anyway (or at all if they’re using just the mouse); instead the basic commands page provides the minimum amount of commands and information a mouse user needs to use and understand the entire interface. By comparison the advanced commands page is packed with every command in the game, including duplicates (some actions are possible via multiple different keys).


Basic commands.



Advanced commands.

Also notice that window-specific commands are displayed in their relative windows, and certain parts of the interface (for example the top-right HUD area) have descriptions explaining each piece of data.

But input is generally the lesser fraction of what a player has to learn. Mechanics are the bigger issue!


Some mechanics can and will be understood naturally through regular play, but even in these cases it’s possible to speed up the learning process, not to mention the need to teach other mechanics and stats might be too opaque or unclear without additional explanation.

The old go-to in that case would be the manual. Cogmind includes a text manual that fully explains all mechanics and UI features, weighing in at 8,000 words. But to make it easier to reference and put it where players are most likely to need it, the manual can be opened within the game itself in an interactive form.


In-game manual example.

Manuals are good when players have a lot of free time and would just like to browse or even thoroughly read through the manual for information they might not already know, and if the topics are arranged sensibly they can also make it easy to seek out information on a given topic in order to answer a specific question. But honestly specific questions are best handled at the point where they’re asked, and that means context help.

In Cogmind this is how the stats are handled, because the status page, robot info page, and item info page are all a combination of data and graphs, the meanings or implications of which won’t always be obvious to the player, and making them search through the manual each time they need to learn something is a terrible and frustrating requirement. So simply clicking on any stat provides an explanation (or for non-mouse users, pressing Up/Down and hitting Enter on an entry).


Context help example.

In general the way to head off player uncertainty is to ensure that obtaining information is as intuitive, automatic, or direct as possible. Thus another way the UI works to help the player:


Automated map labels, which help players learn the ASCII (or the ASCII-like minimalist tiles) for objects, and even if they forget them, labels are still always available to speed up the recognition process!


The player’s first contact with the interface and mechanics is of course extremely important, so many games these days start out with a tutorial (or at least make it optional and recommend it). I was originally loath to provide a tutorial at all, because I didn’t want to include immersion-breaking elements (like there’s no main/start menu), especially not right at the beginning. But from an audience-building perspective that would be a massive mistake.

So eventually I came up with an “immersive tutorial” that teaches the basics by introducing them step by step in a few short connected rooms. And these rooms are a plausible place for the game to start, so it doesn’t feel out of place.

The tutorial map, basically an alternative version of the first floor of the game that leads normally into the rest of the game, is only shown three times for each player, the first three times they play. I decided to have it repeat more than once so a new player isn’t suddenly thrown into a new and unfamiliar starting area the second time they play (this being a roguelike, the “second run” will probably come pretty quickly :P).

Also, it’s a very short tutorial anyway, and the second and third time through it doesn’t even include the tutorial messages, so it loses even that little bit of tutorial feel. “Tutorial messages” appear in the message log, hot pink and blinking and with a special beep, and still people sometimes miss them after the first few as they’re eager to explore. Oh well.

While the better alternative, modal tutorial messages, are great for forcing players to pay attention, they’re very intrusive and really ruin the immersion I’m trying to create, so I decided against that approach pretty quickly. (It’s a bit of design conflict between accessibility and the theme, which honestly plays out in many more areas than just this one, and is really annoying :P)

Anyway, each tutorial message is only shown once, and most of the important ones are context-triggered, for example telling you to drag-drop an item you just picked up in order to equip it, and they work in tandem with the tutorial map based on how it’s laid out.

A lot of thought went into the layout of the tutorial map which, unlike much of the rest of the procedurally generated world, is completely static. It’s only four rooms total, and the idea is that the player encounters elements in a very specific order, without simultaneously seeing other elements that would distract them from what it is they’re supposed to be learning at that time (despite how small the area is).


Tutorial map layout with explanation (click for full size).

In those four rooms the player learns pretty much everything they need to have a good time, which is the best way to start any roguelike :D. Sure there is plenty more to learn, but that can all come with time. Also, for comparison check out the regular non-tutorial start area:


Standard Cogmind starting area. There are only two rooms, where the player starts with more options for gear--all in the immediate vicinity--and then can head over to the next room and leave right away.

Independent of the tutorial map, later in the game as new elements are encountered, there are some tutorial messages to explain features that might be incredibly important but not necessarily obvious--for example bumping into machine control panels to interact with them. At various timed points there are also other more general non-context reminders, telling the player about the manual, or how to save and exit, etc.


Turn counts on which time-based tutorial messages are shown.


Sometimes players like to seek help outside the game, and that’s where having a community comes in handy.

Letting individual groups of players spring up in their own forum threads wherever they may be is nice, and that will happen regardless, but it’s still worth having dedicated forums these days, so I did that and love the community interaction it brings. When players ask questions in a public forum dedicated to a single game, the answer can in turn help anyone else who comes looking for similar help.

I set up /r/Cogmind for a similar purpose, but Reddit is a pretty terrible format for a long-term community that can benefit from preservation of information and more convenient search functionality, so it’s more of a communication channel than a great source of help.

In either case, though, communities have advantage of providing a type of help that isn’t usually provided by the game: strategies. This is something a manual won’t cover, and while in Cogmind there are NPCs who give tips for survival, that can only cover a small portion of the potential useful advice… So player guides are another valuable form of third-party help :)

Many roguelikes of significant size and following also end up with a wiki. In my case rather than wait for someone to create one on some free site with ads and that we don’t have as much control over, shortly after releasing I set one up on my site. It’s almost entirely run by players.

Hopefully all these features (and who knows maybe more to come?) will be enough when Cogmind reaches the hands of even more players in the future!

Posted in Design | Tagged , , , | 7 Responses