Official development blog

2018 7DRL Postmortem, Part 1: Preparation

March 4~11… what a crazy, crazy week.

It wasn’t as bad as I thought it might be based on my first experience back in 2012 (this time I actually slept a good 7~8 hours each night!), likely because I’m a lot more knowledgeable than I was back then, and have lots more tools at my disposal. Still, the desire to create something awesome had me putting easily over 80* hours of work into POLYBOT-7, my entry for this year’s Seven-Day Roguelike Challenge. (*This is during the week only--excludes all pre-7DRL preparation!)

The rate of problems and solutions flying through my brain throughout the week was pretty overwhelming. Tiring sometimes, but at the same time exciting to try to find hacks that could manage so many features and content in such a short period. So. many. hacks. The technical debt is real! I was cringing as I wrote much of the code, but had little choice--take the fastest route possible or risk failure. For the first few days I was doing a slightly cleaner job of it, but with the deadline looming I started getting really crazy as the week progressed.

This project was also a little tough at times because my years of “normal” roguelike work have conditioned me to write about absolutely everything I’m doing or planning, and thinking it through to make the best decision possible. I had to get over that tendency and just do stuff--don’t write about it, do it now! Had to keep reminding myself that all week :P

This is my in-depth postmortem covering POLYBOT-7’s development, examining both the process as a whole and the reasoning behind choices made along the way.

The Concept--What and Why?

For 7DRL I originally had slightly lesser ambitions. The goal was simply going to be a “Cogmind demake,” with emphasis on stripping down my main project to create a purely combat-focused roguelike where much of the work involved would be converting the interface to a new condensed layout featuring less information but double-sized fonts and tiles. It would be something I could point people to when they’re interested in Cogmind’s general theme or style but don’t have a large enough display to enjoy it. This version of the concept was dubbed “Bigmind” :)

After thinking on it for a while it started to feel kind of boring, though. This is 7DRL! It should be about experimentation and interesting new roguelikes!

I had to get more radical, and just about the time I was thinking this I was also skimming my notes for upcoming Cogmind features, one of which happened to be a top secret “Katamari Challenge Mode” I wanted to release with a big Challenges update later this year--basically the player would act as a magnet for nearby items.

This suddenly seemed like a great core mechanic to build into the 7DRL, not to mention the ideal design would require a ton of other changes to go along with it, essentially creating a significantly different game within the same world. A 7DRL could do much more justice to this idea than a simple Challenge Mode, so this became the new direction.

Altogether the proposed changes greatly altered the Cogmind experience, and you can read a list of features similar to and different from that game in the original announcement post, though I’ll speak about a few of them in more detail later.

There are of course also a few other reasons why I chose Cogmind as a starting point to begin with, not least of all because doing so would mean I wouldn’t have to do quite as much planning and preparation, and could instead have more time to focus purely on developing any gameplay or content rather than fundamentals. Without a doubt POLYBOT-7 is a better game for it.

One of the best ways to tackle 7DRL is by reigning in scope, but another of the best ways is to base your idea on an existing game or at least a well-developed engine or framework. I’m deeply familiar with the source for my games and engine after working with them for many years, and not having to reinvent the wheel here is good because I’m actually not that great with technical stuff--in fact I’m quite slow so that’s not something I’d want to deal with under a strict time limit.

project_source_evolution_REX_through_polybot_2011-2018

The source code from my earlier projects has been spawning newer projects over the years. I rarely start projects from scratch, just modify things :P

(That said, remember that 7DRL can be used for whatever you want, so maybe the goal isn’t to finish an awesome game but simply build an engine, or start that new framework you’ve always wanted to.)

Things weren’t all that rosy, however! Part of why I did worse this year than I could have is that I didn’t have nearly as concrete a design ready for me at the beginning of the week. Back in 2012, prior to starting my 7DRL I’d already figured out everything--all the math, formulas, and data ranges checked out, it was just a case of putting it to code and ASCII. For POLYBOT-7 I had basic plans laid out, but many details were lacking, and that’s a problem because emerging details can pretty easily cause a domino effect throughout a design. And they did :P. I ended up having to make some big changes and additions to accommodate adjustments to systems I hadn’t fully thought through before.

The biggest drawback though was spending more of the week than I’d like to thinking rather than doing. For maximum efficiency, 7DRL week should be about doing, not thinking (coming up with a good design can take a lot longer than a week, most importantly because ideas generally need an incubation period to see if they stand the test of time or maybe there’s a better approach to something). Anyway, I just barely made up for it by relying on a lot of adrenaline-fueled hacks on the coding part :)

Pre-7DRL

7DRL prep really starts a fair bit before the week itself. I went through several design docs starting back in January, occasionally opening up the latest one to make additions, then when it got a bit messy or I wanted to make a significant change in direction I’d reorganize everything in a fresh doc to get a good overview of the design state. Back in 2012 I had a lot of free time for this sort of thing, though, whereas this year I was pretty busy with Cogmind dev and other stuff, so didn’t have as much design time as I would’ve liked. I went into 7DRL with a technically complete high-level design doc, though given more time I would’ve refined it much further.

Before the 7DRL I also wrote the release announcements for both this blog and itch.io :P. I’m actually a fairly slow writer and knew there wouldn’t be time to prepare good release announcements during/at the end of the week. I did end up having to make a few modifications later based on changes to the design, but for the most part it stayed intact, all I had to do later was put together some quick screenshots. Plus this was also a good opportunity to familiarize myself with itch.io, which I’d never used before and it would be funny to somehow screw up releasing the 7DRL when it was already done!

I even designed a probable cover image before the week started, using an old unused Cogmind tileset style as a placeholder:

polybot7_box_art_style_test

Pre-release placeholder box art.

This made it easier to quickly create box art for POLYBOT-7 at the end of the week once Kacper completed the tileset. You can see the similarities :)

polybot_box_cover

Final box art!

UI

In addition to design docs, I also spent a little time in REXPaint doing UI mockups. The initial focus was making sure I could fit everything I needed into a 106×30 grid, and I tested this early because I knew the restrictions would probably impact the mechanics.

This first mockup got thrown out really fast :P

polybot7_ui_mockup_1_hud

UI mockup #1 (HUD only)

The vertical bars are way too cryptic and not all that readable, while also leaving no space for any extra related numbers. Then I realized I could give myself room above the parts list by removing the four headers/lines used purely for separating the types. I could add the ASCII/tile for each part right next to each row anyway, and they’re automatically sorted, so there’s no strong need for those headers. So next came the first serious mockup (with notes), although as you can see below it’s a pretty bad idea to have the item ASCII covering the left UI divider! (I tried that as an experiment to save as much horizontal UI space as possible)

polybot7_ui_mockup_2

UI mockup #2

It was also important to consider ways to adjust the overall appearance to create something as distinct from Cogmind as possible. One of the easiest ways to do that is with color, so of course my first thought (and Kacper’s, separately :P) was to move away from green and try out a different main UI color, specifically orange. Gold on black is a cool theme, as you can see in this inspiring DynaHack screenshot.

dynahack_composite_screenshot_sample

Sample screenshot of DynaHack with a modified color scheme.

I explored the idea in REXPaint, but unfortunately from an overall UX perspective orange really isn’t all that suitable given POLYBOT-7’s mechanics. Like Cogmind of course item destruction is a major feature, and the whole color scheme is geared towards green being “good” while other effects and states use their own logical colors. In most cases anything not green probably deserves closer attention. This also preserves the standard “green -> yellow -> orange -> red” progression for damage indicators and labels, a theme applied consistently across many parts of the interface. Changing the main color would mess with that intuition and make the UI at least somewhat harder to parse.

So with four extra lines at the top, a decent final HUD mockup was born:

polybot7_ui_mockup_3_hud_final

UI mockup #3 (HUD only, final)

I made some other adjustments later, but we’ll get to that. In any case, once a REXPaint mockup lays everything out as clearly as it does, implementation is fairly straightforward so having this ready beforehand was very useful.

Also with regard to color, I decided that rather than once again going for the same old high-contrast black background style, I’d switch over to a low-contrast theme that relies on a slightly darker foreground on top of a slightly brighter background. Late last year I added “render filters” to my engine (described earlier on the blog), which make enabling a low-contrast look as simple as changing a config setting. At the time I didn’t know I’d end up using it here--the system was just meant to provide Cogmind players with a way to tweak their interface, but it sure came in handy!

polybot7_advanced_config_low_contrast

That line in the config file is what keeps the foreground from being too bright, while also adding a green tint to the entire background.

However, the low-contrast filter itself is a pretty big hack, and as one might expect, Cogmind having been designed all these years with the assumption that the background is black meant that the mode doesn’t always look perfect in combination with the animations. While there certainly wouldn’t be time to update the huge number of particles used for weapons, I could at least get the UI looking better. These changes were all made to Cogmind (which benefited in several ways from this 7DRL :D), something I wanted to do eventually but in this case moved up to before the 7DRL.

There were basically two types of issues to resolve: either forcing a background meant to be black even in low-contrast mode, or modifying animations to lerp from a given color to the desired background color rather than assuming black.

cogmind_low_contrast_UI_animation_fix_optical_array

An example of the latter case, notice how before the fix the animation lerps to black rather than the proper color (effectively going to black before snapping back to the right color), and looks much better (as intended) after it knows the proper target color in the first place.

Fonts were also something I thought about a lot before starting. I wanted something simple--both in terms of appearance and implementation, so I went with Terminus for both the text and map, because it’s a nice and readable pixel-perfect monospace font available at pretty much all sizes. But because I didn’t want to have to provide a massive range of sizes like I do with Cogmind (it takes forever :P), instead of allowing the map view (and HUD) to expand vertically it is locked at 30 rows. The width is still variable, resulting in letterboxing on some displays. This is a much prettier option than scaling, in any case, allowing both text and tiles to retain their pixel-perfect look, straight from the bitmap.

It also means the entire range of resolutions can be pretty well supported with only four different sizes, all created from a single base size. With a base square map tile size of 12×12, a 768p resolution uses a 24×24 font (simply created via 12*2), by far the most common 1080p resolution uses a 36×36 font (12*3), and beyond that there are also size 48 (12*4, 1440p) and 72 (12*6, 2160p). Text uses half-width cells that also need four sizes, based on base dimensions of 6×12.

polybot7_notes_resolution_and_fonts

Some of my pre-7DRL notes. I carry folded pieces of paper in my pocket while out and about to jot down ideas, and my son decided he wanted to borrow this one and draw on the back while bored :)

Gameplay Design

The main goal of the design was to create a quick, very coffeebreak-length Cogmind-ish experience, so everything revolved around that. There should be fewer decisions involved in a normal playthrough, and thus many systems or interactions would need to be removed. And not just systems but even weapons’ visual effects, which are blocking and therefore can slow down the player. With that in mind, during the week I wanted to tweak any slower animations, or outright remove most weapons that relied on them.

polybot7_accelerated_EMP_effect

Comparing Cogmind’s EMP animation with the faster one in POLYBOT-7. (EMPs in particular I wanted to keep for mechanical reasons, so those had to be sped up.)

Another huge decision-saving move was to completely remove the inventory, though it took some time to come to this conclusion. Notice the inventory in mockup #2 above, which was at first envisioned as a modal window that would allow collection of parts to then attach at will. Time-consuming! Even with all the supporting automation features it provides, one of the more time-consuming aspects of Cogmind is inventory management, and I thought it’d be great to limit that. So the next thought was perhaps an ordered “queue” of parts that would be attached next after you lose some, but even that seemed too complex for what I wanted to be a simple, focused game.

It dawned on me that there really wasn’t a strong need for an inventory at all--basically the world was going to be the player’s “inventory,” facilitated by the already established ability to quickly attract surrounding parts. This would be both simple and have lots of interesting implications for play.

Once attached, parts cannot be individually removed because that would make it essentially pointless to automatically attach parts, with players just removing those they don’t want while others are nearby (more tedium!). So aside from losing one to destruction (a slow and unreliable method), there needed to be a different way. Enter another key part of the plan: the “Purge” mechanic.

Cogmind already has a “go naked” command that destroys all attached parts to allow for a quick getaway in certain emergencies, and it seemed like repurposing this for POLYBOT-7 would make it a much better game. Instead of destroying all parts, it could destroy a random half of them and drop the other half, allowing the possibility of keeping some potentially good parts while also not requiring that there be a massive number of parts nearby to return to full slot usage. This mechanic would allow players to “shuffle” their build if 1) it became totally imbalanced and unusable or 2) they found some really good/better items that they want to take advantage of right away.

From talking with Cogmind players (I introduced the general plan to them the week before), it became obvious that allowing unlimited Purging wasn’t going to work and could easily be gamed, so I decided to have it charge up before each use, achieved by draining some of the player’s energy in the meantime. This could be interesting because it would be ready faster if you had more power, but also make the player weaker for a while after a Purge, forcing you to seriously consider your situation before taking this action. I’ll talk more about this later, because there were issues and that’s not how it works now :P

I’ll also talk about other unique mechanics when we cover what actually happened during the week, starting with the next section :)

This post is the first in a four-part series. Subsequent parts will dive into the following topics:

Posted in Dev Series: 7DRL Postmortem | Tagged , , , , , | Leave a comment

POLYBOT-7, a 2018 7DRL

Back in 2012 I made a 7DRL by stripping down X@COM to create the original Cogmind prototype. Now, six years later, I’ve ripped Cogmind apart and put it back together as something else for yet another 7DRL :)

I’ve always wanted to build more roguelikes, and the annual 7DRL challenge is a great opportunity to do just that, but in the years after 2012 the torturous hours I put myself through that week to make Cogmind a reality were still too fresh in mind. While that feeling faded as the years went by and I became eager to participate again, then I got way too busy with work and had to repeatedly pass, despite several false starts that died in the design doc phase. This year the stars aligned and it was about time to finally revisit the event that drove me to create a game which has since become my full-time job and taken over my life :P

Today, following a week of blood, sweat, and ASCII, I present POLYBOT-7!

polybot_box_cover

POLYBOT-7 is purely about scrapping together a robot on the fly to take on other robots. And while that sounds sorta like Cogmind, this 7DRL is instead hyperfocused on tactical combat in a coffee break package. To create it, Cogmind’s hacking, intel, allies, factions, ecosystems, NPCs, events, lore, expansive world and much more, are all gone, as are the many UI elements required to support them. There is only

Destroy. Rebuild. Adapt. The world is your inventory.

All the core combat mechanics are inherited from Cogmind (as of the latest version, Beta 5+), but the surrounding systems, and therefore much of the gameplay, have changed significantly…

  • You now automatically attract nearby parts and attach them when you have empty slots
  • Builds are even more free-form, since there are no type restrictions on slots!
  • Redesigned movement mechanics mean you can now combine multiple forms of propulsion, though flight was removed as part of the purge of non-combat options
  • Part management is greatly simplified, since there is no inventory at all and you not only don’t have to but can’t remove individual parts
  • All salvage (and other free items once you’ve neared them) destroy themselves after a period of time
  • You start more powerful, with 11 slots
  • The world is smaller, only 5 floors (although maps are still quite large, and if you win there is New Game+!)
  • There is no slot evolution between floors--you can skip to the next floor whenever you find an exit, but you can only gain extra slots by finding items on the current floor, so skipping ahead will leave you weaker later!
  • You also find permanent upgrades by destroying Dispatchers, machines that are activated and spit out robots as you near them
  • All robots are hostile--if it moves, you probably want to either shoot it, reposition, or run
  • There are fewer robot and item types than found in Cogmind (though also many new ones)
  • Weapon ranges, sight ranges, speeds, etc. were all reduced to fit the new UI dimensions, making it possible to still see everything that’s going on, though maps might feel a bit more “cramped” as a result

polybot7_7DRL_screenshot_tiles

As you can tell in screenshots, the UI is also fairly different, condensed into a much smaller grid to allow for double-sized fonts. The visual style is also different overall, because it’s nice to make clear that POLYBOT-7 is a distinct game and to experiment with other looks! Walls are now line-based (even in the tiles version), and I used Cogmind’s new and improved render filter system to create the low-contrast aesthetic.

Design

Although probably not entirely necessary after a rundown like that, I want to emphasize that POLYBOT-7 is definitely not a true Cogmind demo. It does, however, showcase a lot of the same particle effects and SFX, as well as UI features and general style.

Features that were inherited from Cogmind:

  • Combat mechanics
  • Numerous items and their effects
  • Soundscape/SFX
  • Map generation (same algorithms with different parameters)
  • Some convenient UI features, wherever I could keep or redesign them since they add significant QoL
  • Many of the same customization options are still available, but because I removed the options menu (no time for that!) you have to make changes direct to the config files. Certainly not all of them are applicable anymore, but a lot are.

polybot7_7DRL_parts_manipulation

Still, for a long while Cogmind has been on rails with such a long semi-predetermined TODO list that just executing it is only half the fun of development, whereas hacking away at a 7DRL was a really refreshing opportunity to work with new concepts and a much cleaner slate. Naturally I got really excited at this chance to experiment with mechanics and create a new experience in an otherwise seemingly familiar world--in that way it’s kinda like one of the Cogmind Challenge Modes on steroids. In fact, the idea that ultimately won out as The Core Mechanic for POLYBOT-7 came precisely from a planned Challenge Mode, the idea of attracting parts which automatically attach to you and cannot be removed as normal.

Everything else was designed around that.

Early on it became apparent that simply shooting stuff and attaching nearby parts automatically, maybe while toggling them to optimize the build as necessary, wasn’t quite enough of a fun challenge. There were too few player choices involved, so to keep it interesting I added a heavy emphasis on a redesigned version of Cogmind’s “go naked” command, the one that strips you of all your parts in a single action. (It became so important that its hotkey went from Shift-Alt-p to just ‘p’ :)) But in the case of POLYBOT-7, a so-called “Purge” destroys only half your parts, scattering the other half on the ground around you. This means it’s kind of like a randomized “shuffle” for your build, allowing you to regain some parts while making room for others you’ve come across, or simply trying to rid yourself of too many broken parts or a highly imbalanced build to start fresh.

The Purge system requires 100 turns to charge before it can be used again, however, making it vital to do this at only the best opportunities, while also preventing players from gaming the system to repeatedly purge and quickly destroy specific parts.

In terms of balance, while the player will have easy access to spare parts by strolling through the remains of any given battle, these parts are often garbage and not that suited to fighting hordes of enemy robots. On the other hand, there are caches of nice parts to be found… When and where to Purge will be key to survival!

Of course there are plenty of other features that didn’t survive the chopping block, but such are 7DRLs! Maybe one day? :)

Interlude

Earlier I said blood, sweat, and ASCII, but while there is definitely a full-ASCII mode, POLYBOT-7 defaults to tiles created by the wonderful Kacper Woźniak. He really knows how to maximize the potential of those few pixels I give him :P. So while I was coding up a storm, Kacper was pixeling our new robots and items (when not at work fretting for lack of time :P). Thanks for the help, man!

polybot7_tile_sample

Impetus

I would’ve preferred doing something completely different for what is only my second 7DRL (POLYBOT-7 is pretty radical, though not as radical as say something built from scratch :P), but there are a lot of reasons I ended up choosing this particular game:

  • First and foremost, this is something I can point people to when they like the theme or basic idea of Cogmind but don’t have a large enough display to enjoy it on. For them I wanted to test how much of the main UI I could cram into only half the space, while also adjusting the content to suit a smaller map area. In fact, the original code name I used in my first design docs was “Bigmind” :P. In the earliest design iterations it was going to be just a stripped-down version of Cogmind, but I felt that wasn’t worthy of a 7DRL--it really needed to be something even more unique, so as those changes made their way into the design I later decided the name shouldn’t be that close to its progenitor, either.
  • That first reason also made it easier to justify taking the required time out of my work on Cogmind (technically my job now!) to join 7DRL. I know POLYBOT-7 is something that existing Cogmind fans can enjoy as well, win-win!
  • POLYBOT-7 allowed me to explore a bit of what Cogmind would be like if I had gone the other route back in 2012: no slot types. Design-wise I’ve been very glad I did go the type-restricted route, but it’ll be interesting to see what comes of completely free-form builds, even if there isn’t as much control over them.
  • I really like the idea of using 7DRL to force completion of quick and focused prototypes, exploring game ideas that might be extendable or polishable into something better later on. I’ve been thinking about that especially often as we get into late Cogmind dev, since I may need a quicker commerical project or two to be able to reliably fund future development.

Download

This year’s 7DRL is the first to be hosted at itch.io, so rather than providing the download myself, you’ll find it over there, along with additional information. If I end up providing future updates, they’ll also be made available there. Here on the blog I’ll also be writing a portmortem covering at least some of the design and technical processes that went into creating POLYBOT-7. I certainly didn’t have enough time to share much of anything during the week!

polybot7_7DRL_various_combat

Oh, and it probably goes without saying there is an ASCII version ;) (F3!)

polybot7_7DRL_screenshot_ascii

Have fun :D

Update 180329: I’ve published a four-part postmortem about this 7DRL’s development process and many of the design decisions made along the way, starting here.

Posted in Release | Tagged , , , , | 17 Responses

Color Customization

I’ve always enjoyed adding accessibility features, hence Cogmind’s sizeable options menu and even more extensive config files. Not everyone will have the same habits or abilities, or play a game in the same way, so where possible it’s nice to be able to accommodate different needs. Although I’ve talked a fair bit about fonts before (still more to come on that front!) and four years back also wrote about some of my ideas on potential adjustments related to color blindness, it’s about time for a generalized set of color customization features.

As the player base has grown a fair bit over the past few months, I’ve received a few requests for ways to tweak the brightness and/or saturation, so that was the trigger for finally implementing a display filtering system.

Essentials

Many games come with a simple “gamma” adjustment option, so that’s where I started. Easy enough:

cogmind_color_filter_brightness_66_tiles_comparison

Comparing the default appearance to a 66% brightness setting.

While it’s true perceived color brightness is non-linear, adding in more complex calculations to compensate would slow the filter down so I implemented it as a direct percentage modifier, just [RGB * (0.0~1.0)].

Note that for comparison purposes the majority of screenshots in this article use the same scene, and all can be clicked to open at full size.

Some players may also want to drop the saturation to take the edge off the eye-burning terminal contrast :P

cogmind_color_filter_saturation_66_tiles_comparison

Comparing the default fully saturated appearance to 66% saturation.

Since I store colors using RGB and it’d be slow to convert everything to HSV simply to adjust the saturation then convert back again, I found an alternative formula for direct RGB saturation adjustment that seems to work nicely.

Filter Settings

So how are these options made available, and how to create a system that will support additional filters? For now I opted to make it a string in the advanced.cfg file. For example the line “renderFilter=BRIGHTNESS(90)|SATURATION(90)” adds two filters, a first which drops the brightness by 10%, followed by a second that then desaturates all colors by 10%.

There are currently eight different filter types, and the code converts this string into a set of filters that the engine renderer applies in separate passes over the terminal grid colors, both foreground and background. They’re applied to every cell individually, so this isn’t some GPU-optimized image modification, just an operation repeated for each cell, meaning each filter pass on the standard-dimension UI costs an additional 12,720 operations xD. Yeah there are better ways used by more competent programmers to achieve effects like this, but it works well with my current engine setup :)

At most the minority of players who will use filters seriously will probably only need one or two anyway.

Getting Wild

Having taken care of basic needs, there are of course even more frequently requested adjustments like the ability to outright change terminal colors.

Traditional terminal players are used to being able to fairly easily customize the appearance of a roguelike, including the color palette, but they also only have worry about maybe just 16 colors. Unfortunately there is a huge range of colors in Cogmind so it would be a lot more work to implement a way to customize individual details, but for now I’ve at least added a very simple method with a broad effect: hue shifting. It can lead to some crazy schemes, but there are reportedly a number of people out there interested in something like this.

cogmind_color_filter_hue_shift_180_pink

Cogmind appearance with all hue values rotated by 180 to become… Pinkmind! (example #2: 90-shift Bluemind)

Colors have been carefully chosen in Cogmind, designed to make the meanings and implications of certain pieces of information that much easier to intuit, and obviously shifting the hue will ruin a lot of that. Some things which were obvious may not be so obvious anymore, and on the flip side unimportant elements may be overemphasized. In any case, doesn’t hurt to have this as an extra option for whatever reason!

With a system in place it’s also not hard to add new filters.

I mean we can even get crazier than hue shifting and go as far as RGB shifting! Check out the color chaos that results from a +90 shift:

cogmind_color_filter_rgb_shift_90_purple_green

Shifting all RGB values by 90. No.

Are your eyes ready yet? Let’s continue with more serious filter efforts…

Low-Contrast and More

One of my goals with this system was to enable low-contrast settings that don’t overly impact the general color design, and rather than darkening and/or desturating everything, a better approach is to start by not using a pitch black background. This required some actual changes to the source code beyond a basic filter, since for the past five years of development I’ve assumed the background is black, but the necessary adjustments weren’t too difficult and for the most part now work via a global switch.

The idea is to choose some other dark-yet-not-black color. To avoid wasting too much time here, I used Photoshop layers to tweak a game screenshot until it was low-contrast but highly readable, then made sure the system I had was capable of replicating that process step-for-step. As usual, it’s good to have a target to work towards when designing something like this. (For the same reason I always do UI layout mockups in REXPaint first.)

cogmind_photoshop_low_contrast_curves

Step 2 for creating Cogmind’s low-contrast mode: Raising the overall brightness, especially for darker colors.

In all there were more steps but I compressed it down to just two:

  1. Swap out the black background with the chosen new color.
  2. Adjust the brightness of all foreground colors using a formula derived from the PS testing above: y = 0.7176x + 59. This raises the brightness of most darker colors so they stand out just enough against the new background, but takes the edge off any really bright ones.

For reasons specific to Cogmind’s color design I did make a couple exceptions--the second step is skipped for any instances where the foreground color is itself black (this is rare but I use it for occasional reverse cell coloring--black characters imprinted over a solid color), or was intentionally set to match the background color (I sometimes do this to temporarily hide the foreground).

So what background colors did I pick as defaults? I started of course with my dark maroon background from the IDE color scheme I designed from scratch and have been using for the past 10 years or so :P

cogmind_source_chack_text_sample

Some Cogmind source as seen in my IDE, the inspiration for the first low-contrast mode.

Like my IDE scheme, this particular filter is called “Autumn.”

cogmind_color_filter_autumn_low_contrast

Interacting with various Cogmind UI features in Autumn low-contrast mode.

In fact, aside from being my IDE scheme Autumn is also a REXPaint skin, and Cogmind’s other new low-contrast mode borrows REXPaint’s default skin as well: “Sleepy.”

cogmind_color_filter_sleepy_low_contrast

Cogmind low-contrast mode “Sleepy.”

These modes still aren’t quite perfect due to the aforementioned universal assumption of black, though I did specifically update some of the particle scripts to be compatible with this new filter. The few features which might not always look great under this mode are some of the ASCII item art and intro/ending animations, but this only affects the small minority of areas that use their own dark background colors.

If more people start using low-contrast settings I might go back and invest more time in overcoming some of the remaining aesthetic challenges.

Although I implemented two named low-contrast filters, these are merely for convenience--under the hood they’re implemented through a more general filter: LOW_CONTRAST(R,G,B). This means you can create your own low-contrast scheme using your favorite color, or whatever you think works, I just thought I’d provide defaults for some tried and true colors :)

Map-only Adjustments

Earlier I mentioned this setting is called “renderFilter,” but there is a second one as well: “renderFilterMap.” All filters set there apply only to the map, rather than the entire application including HUD and other UI elements. It’s compatible with the same filters except low-contrast, as the latter must be applied across the entire application and cannot be limited to the map area since it’s handled on the engine side (as opposed to the game side).

One of the interesting filters more suitable for the map area rather than the UI: SWAP. This filter swaps the foreground and background color of every cell to create an even more colorful “dark on light” style rather than the usual “light on dark” terminal look.

cogmind_color_filter_swap_map_only

The results of a renderFilterMap=SWAP, with no other changes to the appearance.

I don’t think this is as good from a parseability standpoint since it somewhat separates color from the character it’s associated with, but maybe it could fun to play around with, plus some players can get used to or even enjoy anything :)

cogmind_color_filter_swap_map_action

Destructive ASCII action in Swap mode

Notice that these are ASCII examples, because although it’s monochrome the default tileset uses multiple shades, and the whole look is not very compatible with this kind of swapping.

cogmind_color_filter_swap_map_only_tiles

Yeah I don’t think so.

So if you’re interested in trying out this mode I hope you like ASCII, otherwise we’ll have to wait for someone to draw a non-shade monochrome tileset that focuses mostly on solid shapes and symbols. I’m sure we’ll see something like that eventually. It could look pretty cool (and of course also work in the default/non-swapped mode as well, so the idea is that we’ll get that one first then it can be simply swapped over).

Good news is the Swap filter is both compatible with and looks even better when combined with low-contrast mode!

cogmind_color_filter_swap_map_only_plus_low_contrast

Cogmind ASCII map with both a Swap filter and Low-contrast Autumn filter enabled.

All these customization features are explained a bit more in a new “Color Customization” section of the manual included with the next release (Beta 5).

Specifically with regard to color blindness, I haven’t gotten any real feedback from players who need more options in this regard, though from the start I’ve tried to design the UI such that as much info as possible is conveyed through multiple channels, color only being one of them, so maybe there isn’t much demand for additional features there. I could add new filters if necessary, and although individual color swapping would be problematic (primarily because any dynamic colors are scripted and therefore calculated via formulas), perhaps there are some formulas that could be made available as filters to adjust the final color palette that way.

cogmind_color_filter_parser_debug_testing

Bonus GIF: Cycling through various display adjustments in real-time after hooking up the color filter parser to the debug system :D

Update: Based on feedback from players, Cogmind has also since added a colorblind mode accessible directly from the Options menu!

Posted in Design | Tagged , , , , , | 2 Responses

Player Metrics: Stats and Preferences on and off Steam

Wow, Steam release. The core roguelike community has formed the majority of Cogmind’s player base for a long while, but now we’ve had a wave of new players from Steam so we’ll have to see how this wider audience, and a larger portion of players new to the genre, may have affected some of the stats.

For the past couple years I’ve been reporting stats based on player-submitted score sheets, which also include some preferences and other settings (you can sample those linked from the leaderboards if you haven’t seen one before). These “stat summaries” have simply been going to the forums High Scores thread, with the kinds of stats evolving over time along with an increase in total number and quality.

Today it’s finally time to take a deeper look at the data… Doing this sometimes helps with future design decisions, but it’s also just fun :)

I did something similar back in 2015 for the Alpha Challenge, a metrics analysis in 7,500 words and several dozen graphs, but it’s been a long time and we now have a lot more data to work with, plus we can do some interesting before-after comparisons.

Overview

In ten weeks of Beta 3 following its release on Steam, 33,181 score sheets were uploaded, compared to around 15,000 in all of Cogmind’s more than 2-year history of prior releases. We technically even lost some 2,000 Beta 3 score sheets one day shortly after launching on Steam due to a little incident with the leaderboards being overwhelmed :P (wasn’t designed for that kind of load! I did fix it the next day, though)

26,478 runs scored at least 500 points, the minimum required to be included in the scoring data. 65.2% of those runs were submitted anonymously, meaning the player did not set a Player Name in their options. This compared to a mere 5.4% for Beta 2. But we can account for that change with two main factors:

  • As of Beta 3 score uploads were changed from opt-in to opt-out, meaning a lot more submissions by players who otherwise wouldn’t bother manually activating it in the options (or even know it was an option in the first place).
  • Even though Cogmind uses non-Steam leaderboards, Steam players probably assume their in-game username is set automatically based on their account, which is not the case. (I’ve considered adding this feature, but decided not to for now.)

Anyway, lots of anonymous scores. Since we have so many non-anonymous submissions now, as of Beta 3 I removed anonymous scores from the leaderboards themselves, though they’re still included in stats below except where mentioned. Overall 1,287 unique non-anonymous players submitted scores, as well as 4,389 unique anonymous players you don’t see on the leaderboards. 342 initially anonymous players later set their Player Name and appeared normally.

Counting only those runs included in the data (26k), you can see how the submissions gradually decline following the Steam release. (You can also clearly see the effect of the leaderboard system crapping out that day xD)

cogmind_score_submissions_around_steam_release

Some of the decline can of course be attributed to be people trying the game out then waiting on it because it’s “EA” or they have other things to do, and also because many players gradually improve their skills over time and survive for longer periods, leading to fewer submissions overall. As you can see I added average run length (in minutes) to the graph, and the trend line for that rises from 62.5 minutes to 83.8 minutes, a 34.1% increase across two and a half months.

Both off and on Steam, Beta 3 was played for a total of at least 1,541,666 minutes (25,694 hours!), though I excluded a number of suspect high-time records--Cogmind’s run length records exclude idle time, but are also on rare occasions susceptible to oddities in a few system environments. And of course we don’t have data for players who are completely offline or have deactivated uploading, and I also didn’t tally sub-500 score sheets.

Scores and Wins

There was a steep drop in average score, to be expected with so many new players. It reversed the trend we’ve had over the past year, where scores were generally going up as 1) the world grew wider, 2) more sources of bonus points were added and 3) regular players got better and better. Alpha 14 to Beta 1 saw an 11% increase in average score (to 8,035), for example, then up another 5.3% to 8,461 during Beta 2. With Beta 3? Average score fell 53% to 4,503! :P

I’m sure we’ll see it rise again later into 2018.

There was, however, a fairly large raw number of wins. In the 29 months prior to Beta 3 players won a total 292 times, while during just the Beta 3 period there were 139 winning runs. Among the rapidly expanding player base we’re seeing seriously dedicated new experts, some clocking hundreds of hours in just the past couple months.

There are seven different endings in Cogmind, and a few players have discovered them all, but during Beta 3 the spectrum of wins only covered the first four types. 79% of wins were the “default” ending, 1% were special ending #1, 11% were #2, and 9% were #3. Maybe we’ll see some endings 4/5/6 in Beta 4 :) (these are the most challenging, two in particular are for super powerful builds).

Now that we actually have some players using the lower difficulty modes, it’s also more meaningful to look at how many of those are winning. Wins by difficulty mode:

  • Default: 101
  • Easier: 4
  • Easiest: 13

Comparing the number of winning players vs. the total playing each mode, the numbers look like what one might expect, so the modes are apparently doing their job. Winning player ratio by mode:

  • Default: 38/1,183 (3.2%)
  • Easier: 4/52 (7.7%)
  • Easiest: 9/52 (17.3%)

The latter two modes are mostly composed of very new players so in future versions I would expect the win rate there to rise even faster than the default assuming no new large influx of players (and that players don’t decide to move up to a higher difficulty).

I excluded 15 anonymous Roguelike Mode wins, and 6 anonymous Easiest Mode wins, from the above data. Altogether, 51 (4% of) unique non-anonymous players won at least one run of Beta 3.

Looking at all players and score in general, the trend is what one would expect:

cogmind_beta_3_score_range_player_run_counts

Players who tend to score low (which usually but doesn’t always mean dying earlier) also played fewer games on average. Playing more games clearly leads to improvement in skill level, although it’s interesting to note that flat area in the middle of the run count line, which probably reflects a combination of players who are just naturally better and also those who were playing in previous Betas/Alphas and already more skilled to begin with.

Difficulty Modes

Only a small number of players (27; 2%) ever changed their difficulty mode, in most cases (91%) to lower it. Only one player jumped their difficulty level two notches, twice a player raised it by one level, and 17 lowered it by one. 15 players dropped their difficulty from the default to Easiest.

This data is only looking at non-anonymous records, so technically only 22.7% of players, partially because these are players spending more time with the game, rather than many anonymous players who generally do fewer runs anyway before stopping for now.

Steam vs. Non-Steam

Cogmind can be purchased from two different stores, mine and Steam’s, and score sheets indicate which build they were uploaded by (I have a separate build for each), so in all this data we can also look for any differences between the two sources.

During this Beta, 956 non-Steam players finished 4,029 runs, while 4,457 players on Steam finished 22,450 runs. Thus 82.3% of players are using Steam, and playing 84.8% of the runs. A fair number of Linux and Mac players use the DRM-free option (since it’s not supported on Steam), as does anyone who just doesn’t want to use Steam or prefers to buy direct from developers, together boosting the non-Steam numbers by a good bit.

To my knowledge the majority of the experts switched over to Steam release, so maybe that helps account for the fact that the average score among Steam players was 4,386 (median 3,016), vs. 3,975 (median 2,751) off Steam.

I’ll be looking at more at Steam vs. non-Steam data when we get to the preferences later.

Exploration

One of the main draws of Cogmind is exploring the expansive foreign world, so let’s see how far into it players have managed to get so far.

cogmind_beta_3_runs_ending_at_evolution_count

Tallied on a per-run basis we can see that a full third of runs end on the first map. That’s where you’re at your weakest, and especially when inexperienced a few wrong moves can potentially lead to a downward attrition spiral since core integrity is still not all that high and coverage is minimal (lowest slot count).

A still-high quarter of runs end in the floor after that (-9, following the first evolution). Core integrity and coverage are still somewhat low, but most importantly this is the first floor into which Cogmind may enter in a suboptimal state, e.g. partially or totally naked (coming into the first floor this isn’t an issue) without much in the way of spare parts. That’s the most disadvantageous situation to be in, and it’s even more likely here because you may have even entered after passing through the unpredictable and potentially dangerous Mines. This and the initial appearance of Sentries makes the second floor just about as tough as the first for new players.

I’m pretty sure the percentage of runs ending on the first map will shrink with Beta 4 since both its size and difficulty were reduced to not be quite such a harsh early gateway for new players, and to streamline it even more for experienced players. The other two Materials floors also got some tweaks to make them a little easier to survive, so together with the opening floor changes we’ll be seeing that whole early-game peak flattening out a bit (though just as much from the fact that we won’t have quite such a surge of new players as we did during Beta 3).

Beyond the early-game it’s an understandably rapid descending graph with fewer and fewer runs surviving as the difficulty ramps up over distance--difficulty increases rather quickly in Cogmind :)

The final depth at evolution 9 is naturally the most difficult so there’s an uptick of deaths there. By contrast, anyone who can survive the first Research level at evolution 7 can probably also make it through 8. That said, the area is tough enough that many players enter the final map underpowered, accounting for some of the extra deaths there (some of the rest are opting to take on extended game content and don’t pull off the win).

Overall, this related graph tells a less gruesome picture:

cogmind_beta_3_runs_ending_at_evolution_count_bests

Taking only the best run from each player, we can see a more reasonable gradual slope, though the first half of the game is clearly still a barrier to the majority of players (70%).

This is yet more reason to continue adding content to keep players who are stuck there entertained :P. (Cogmind’s content is mid/late-game heavy, greatly increasing with each new depth, so there’s definitely room to expand the early game which is something I’ll turn my attention to again later.) However, for really accurate data there we’d technically have to factor out a bunch of low-run players. Remember the run counts per player graph from earlier--a lot of the people at the low end have only actually played 2-3 runs on average, which is not usually enough to learn all the most important survival tactics. This graph’s peak would naturally flatten out if those people played a few more runs, but many just bought and tested out the game for a bit, and will come back later.

The slight reversal of the trend in the late-game reflects the idea that many who can at least make it to that hardest segment of the world probably won’t take too long to figure out how to push through to the end, especially with… help from branches :D

86% of wins visited special branch maps that, to put it generally, significantly increase Cogmind’s chance of survival in the long run. Not that all branches are created equal--the easily accessible maps aren’t quite as useful as what’s found in deeper or more dangerous areas.

Pretty much all runs that make it out of the early game hit at least one branch or another, even if not looking for them.

cogmind_beta_3_percent_runs_entering_accessible_branches

The above graph shows the percentage of runs which actually visited any map in the given category of branches as a portion of the total number of runs to reach the depths at which those branches were available. For example more than half of players who could enter the Mines did so (many probably newer players entering somewhat unintentionally, although there are certainly players who enjoy taking Mines exits now that they’re not so deadly and can come with more perks).

The Storage branch ratio is especially low because it has fewer entrances than the average branch listed here. And the Research branches are especially high (53%!) because 1) many of the players who can reach those late-game areas know how valuable (and fun) they are and 2) exits from Research are notoriously hard to find so players are sometimes forced to take a branch just to escape before things get too hairy.

Speaking of optional maps, while browsing the stats it was interesting to note that 23 times players passed right through a special secret cave area and didn’t realize it. Also only 2 players visited the world’s most difficult area to reach.

A few plot-related stats, described in cryptic terms to avoid spoilers:

  • Cogmind was imprinted in 3.7% of all runs; players in 84 runs decided not to imprint despite having the chance. 31.6% of winning runs were imprinted, with 8 winners (5.8%) choosing not to imprint. Get your imprinting in during Beta 4 runs, because it’s going to be nerfed in Beta 5 to make it a more strategic decision with additional long-term implications (rather than a no-brainer).
  • 12 runs interfaced with DC and went on to win, of 68 total runs choosing to do so.
  • 18 winning Cogminds visited W, of 41 visits in all (43.9%).
  • 24 wins were achieved with a reset core, out of 101 total resets (23.8%).

With all the fresh Cogminds, average lore collection across all reporting players took a dive to only 6%, as did the item gallery collection rate which now averages 14%. That said, congratulations to GJ, the first (and still only) player to discover every single item in the game, and also every piece of lore! That’s a heck of a lot of stuff, but someone’s finally done it--I’ll just have to add more to keep him on his toes :P

Meta/Preferences

One of the areas I most enjoy comparing across releases is player preferences, and of course we can expect some significant changes with the addition of a Steam version accessible to a wider audience.

Probably one of the biggest questions of preference when it comes to traditional roguelikes is “Tiles or ASCII?” In many cases both are supported, and Cogmind was even designed for ASCII with an ASCII-like tileset only added two years into development. But as we know a lot of players have trouble getting into ASCII, so in the big picture tilesets will always win out. The question is by how much.

cogmind_beta_3_player_preference_tiles_vs_ascii

Prior to Steam 21% of players were using ASCII mode, a pretty good chunk but still a clear minority. With Steam that dropped from one in five to one in twenty players (5%). We’ll see similar trends with many other preferences below.

Note that in these graphs, “pre-Steam” data uses Beta 2 records, which are largely representative of the community we’ve had going for the past couple years. For most graphs I’ve also separated out Steam vs. Non-Steam players in order to examine whether there are any notable differences there. In hindsight it seems non-Steam players show no major deviations from Steam players in terms of preferences, suggesting that the post-Steam trends are a result of simply having a wider audience, and not particular to the Steam community itself.

cogmind_beta_3_player_preference_mouse_vs_keyboard

Not as many traditional roguelikes support the mouse as thoroughly as Cogmind does, but I’d argue that any roguelike wanting maximum exposure and enjoyment should include full mouse support in its design. Of course I don’t really have to argue it, because everyone will probably agree anyway, and in any case there are the facts graphed right there :P

Throughout Alpha and early Beta, about a third of players didn’t use their mouse at all, but now that’s dropped to 7-8%.

cogmind_beta_3_player_preference_movement_methods

As for movement methods, mouse is also king, though notice that even following the Steam release more than a third of players still use the keyboard to move. In Cogmind there is often a need for tactical space-by-space movement, even outside of combat, and even some players who otherwise use the mouse to select targets, get info, or manage their inventory are still open to one of the keyboard-based movement methods.

Before Steam a surprisingly low 25% of players used the mouse for movement. At the time players submitting scores were mostly more experienced (or those very familiar with roguelikes) and would like to exercise maximum precision without fear of misclicks.

Among the keyboard movement methods, as expected numpad is the most popular. Out of curiosity I always keep a close eye on vi key usage, and although pre-Steam vi usage generally hovered around 15-16% and is now below 5%, it’s interesting to note that twice as high a percentage of non-Steam players use vi as those on Steam. (There are 136 of you--more than dozens! :P) I believe one of the biggest factors here is Linux players, who to my knowledge are almost exclusively using the DRM-free version, and the same crowd also tends to be more familiar with the vi layout.

cogmind_beta_3_player_preference_window_options

No huge differences to see in window settings, although based on these graphs I’d say a lot of newer players probably just don’t realize there is a borderless window option yet :). We’ll probably be seeing borderless fullscreen rising later on, unless there really are that many more people without multiple monitors among the wider gaming population compared to what we had pre-Steam.

cogmind_beta_3_player_preference_font_size

For font sizes I’ve only shown post-Steam values. As before, size 18 is by far the most common, generally equivalent to 1080p.

cogmind_beta_3_player_preference_font_typeface

The vast majority of players are sticking with Cogmind’s default typeface (Smallcaps), and as usual Terminus is the second most popular. Interestingly X11 took over as third most popular, attracting a lot more attention on Steam than any of the other remaining options. Also interesting is that Cog slipped pretty far from its pre-Steam third place spot, which we can almost certainly attribute to the fact that it was Cogmind’s original default font back in early development, and a greater number of regular players had gotten used to it, but now it requires that players manually select it over the others.

I also compiled a lot more player-specific stats over on the forums:

cogmind_stat_summary_beta3

Note that some numbers in this post may not always be perfectly comparable across different data sets and analyses. I was using numerous different spreadsheets to work with the data from multiple sources, and sometimes excluded subcategories of data for various reasons. Even if not always fully accurate or comparable, the data does meaningfully reflect general trends.

Posted in Meta | Tagged , , , , | 2 Responses

Year 4 of the Cogmind

Each year in Cogmind development has been bigger than the last, and 2017 was no different!

As in the 2014/2015/2016 summaries, let’s start with a collage of images from this year:

cogmind_development_year_4_small

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

In 2017 Cogmind flew through Greenlight, entered Beta after yet more huge content updates, and has since made its way onto Steam, where it’s continued to do fairly well as we head into the post-Alpha who-knows-when-this-will-end-but-it’s-fun period of expansion!

Development Time

At the Year 4 (technically Year 4.4) mark we’ve reached 8,410 hours of total work, keeping mostly on par with previous years:

timeline - cogmind_monthly_development_hours_201307-201711

Cogmind Monthly Development Hours, 2013.7-2017.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.)

You can see development ramping upward into 2017 as I was eager to finish up the coding (green) and content (orange) to finish the story before a planned Steam launch, but then in April I got that nasty concussion which resulted in a serious hit on productivity.

Still, this year added 2,046 hours, a slight 3.2% increase over the year before. Work on the game itself (923 hours), however, fell 19.8% compared to 2016, a ratio shift that reflects two factors: 1) progress all but ground to a halt while I tried to recover over summer but couldn’t very well stop community interaction altogether, and 2) preparing for Steam inevitably requires a lot of non-game work. You can clearly see the Steam EA release there in October, with a peak resembling my own EA launch of Alpha 1 back in 2015 :). Now that Cogmind is released on Steam and that side of things is stabilized, the graph will start shifting back to more content-focused work over the coming months.

Overall it’s been a great year for progress, though it could’ve been even better had I not hit my head… Luckily when things were at their worst (late August when I was incapacitated most of the time) I finally found a treatment that worked well enough to get me back to full time work!

matrix_acupuncture

Acupuncture!

I’m still dealing with some of the effects now, but have at least gotten noticeably better--I mean, otherwise that 243-hour work month when I launched on Steam wouldn’t have been possible :P

Features

To summarize this year’s highlights: Content was added or adjusted to greatly expand the experience for players across the entire spectrum, as Cogmind got easier difficulty options, the first challenge modes, and an extended end-game with deadly challenges few have even reached, much less survived. Most importantly, in the first half of the year the story was completed with seven different endings to uncover. (I also animated all the endings, which took quite a while!)

cogmind_mapgen_interesting_caves_red_open

There is no map like this in game (honestly it wouldn’t make for enjoyable exploration), but it’s an experimental precursor to… something secret added this year.

I decided to signify the shift into a new post-story phase by declaring Cogmind “Beta,” the massive release of which was both aptly and inaptly dubbed “The End.” This happened around the same time as Cogmind reached two full years in my own “early access” program, which has gone well enough.

Of course plenty of other features came out this year, too, as linked from the ten releases beginning with Alpha 13 in the Release History. And we still have one more update to look forward to this month :D

cogmind_various_2017_feature_gifs_collage

Mix of various feature gifs from the year. Because gifs.

News and Writing

As with last year, most updates have been discussed via release notes on the forums (and now Steam) rather than covered here on the blog. At both of those places I’ve also started regular weekly updates (“SITREP Saturday”) rather than posting randomly once every 10-14 days like I was doing before, so that they’re more predictable.

Although I haven’t been sharing as many design articles this year due to the changing nature of the kinds of things I’ve been working on (for example much of the game content added this year was secret :P), there are definitely more on the way in 2018. But I have been continuing to write FAQs over on r/roguelikedev, where #55~67 are all from this year and you can read about topics like Mob Distribution, Character Archetypes, Status Effects, and Transparency and Obfuscation as they relate to Cogmind.

Exposure

For years I avoided seeking out too much attention for Cogmind, even shying away from some decent opportunities that presented themselves, because the game world was not only incomplete, but more importantly it was definitely priced for hardcore fans of the genre (for those of you new to Cogmind, know that for a long while it was $25-30 as a more reliable way to “crowdfund” the scope I was trying to build into it--we can thank the early adopters for making the current version possible!).

I didn’t want Cogmind’s first impression on a wider audience to be primarily that it’s strangely overpriced for an indie game, which often fall between $10-20, so I turned down some offers for exposure back then. That changed with the Beta and the price drop, although it’s interesting to note that despite my attempts to contact some press and LPers this year, almost all of the best channels interested in Cogmind found it on their own, both before and after the Steam release.

This year Cogmind was one of the subjects of an article on PC Gamer (which also later announced the news of Cogmind’s Steam release), and even appeared in two magazines, PC Guru and Canard PC. There have been more than a dozen other smaller pieces this year as well.

cogmind_steam_EA_release_coverage_collage

Some of the coverage Cogmind received this year, mostly around its debut on Steam.

But often more helpful than media coverage these days, Let’s Players were responsible for the biggest boost in exposure, with popular players like quill18, Aavak, and Nookrium definitely driving interest around the Steam release. (Also many thanks to the smaller channels out there doing even more streams/videos over the long term <3)

Not that I can draw a huge audience myself, but I’ve been continuing to occasionally stream as well, and we often have new players drop by to mingle with the regulars and pick up tips, which goes a long way towards improving the skill level of the community as a whole. As of the most recent stream I’m uploading them to YouTube where they’ll live longer than on Twitch, in case people want to watch them later.

We’ll see if Cogmind gets any mentions in end-of-year articles, but I can say that just this week we already made the IndieDB Top 100 list for 2017--voting for the final round is actually ongoing right now.

Obviously the best new point of exposure for Cogmind in the long term is Steam, where it’s accessible to a greater number of players and can integrate more closely with the gaming community at large.

Steam

We’d been talking about it in the future tense for so long that it almost feels unreal, but 2017 was finally the year Cogmind arrived on Steam.

Early in the year Valve announced they’d be getting rid of Greenlight by replacing it with a simple paywall, and I knew we were close to a Steam release anyway, so I figured I’d respond by quickly putting Cogmind up there and try to beat the inevitable deluge of games to Steam. Given all the assets I already had lying around it took only two days from decision to campaign, which was pretty cool.

cogmind_steam_greenlight_100percent_top_100

Well that didn’t take long!

Cogmind made it through pretty quickly, though I still planned to wait at least a couple months for the Beta before it’d be Steam-ready.

cogmind_greenlit_yes_votes_graph

Clearly a dedicated fan base at work :P

Unfortunately my accident essentially coincided with Beta completion, meaning I had to give up the plan to reach Steam before all those other games, and also forgo a preferable early-summer Early Access release.

Staying alive for the long-term seemed a little more important at the time xD

But hey come October believe it or not it really did happen! Player reviews have been good, and the leaderboards certainly exploded. I’ve actually already covered a lot of details from the Steam release and its aftermath in my postmortem, so check that out if interested.

cogmind_steam_EA_portmortem_graph_collage

Some graphs shared in my recent Steam EA month-1 postmortem for Cogmind.

2018

All that’s behind us now… what we want to know is what great things 2018 will bring!

Well, certainly we’ve gotta finish the stuff still listed on the long-time roadmap, which altogether will take at least a few months, or more considering it’ll all be mixed in with other improvements, too. So without a doubt we’ll get those built-in achievements, an expanded robot hacking system, more ambient audio, and revamped score sheets.

This means Early Access will easily last another six months, and probably longer because I don’t want to bother calling it 1.0 if we’ll still be getting new extra features for much of the coming year.

Exactly how much longer will really depend on what happens on Steam while the remainder of the confirmed features are being worked on. If reception and sales are sufficiently good, I’ll have trouble stopping myself! I can’t be specific about the virtually endless list of potential features I’ve accumulated (player expectations and all that…), but I’ll admit there is room for, plans for, and a desire to add, many new items, mechanics, robots, maps, NPCs, factions, everything…

cogmind_2018_item_art_preview_concepts

2018 awaits :)

Posted in Annual Review | Tagged , , , | 2 Responses