Planet Roguelike-Dev

June 18, 2017

Land of Strangers

Breaking habits

Seeking fresh ideas … Hum!
Accomplished creators will sometimes say something to the effect that one needs to master the formal conventions in order to bend them and innovate. (In the arts, I suspect there is some deeper truth about the historical transition from Romanticism to Modernism, but I digress as always).

When I first started making LoSt, the idea was for a small 7DRL shooter with card based mechanics and no hit points (getting hit was game over). That didn't scale well, however, and was gradually transformed into the current combat system.

Wounds UI
Health: Actors have a number of health levels (HLs), each with a number of bruise levels (BLs). If an actor spends a turn not getting hit, they regenerate one BL. Once a HL reaches zero, however, it won't heal naturally, and the player needs to rest at a saloon or hospice.

Initiative: All events have a speed value, with actions performed in a fixed order each turn. Melee precedes missile attacks, which in turn precede movement. If you're next to an enemy, you can back away, but giving your enemy a free attack. Also, actions can be "interrupted" by incoming attacks. The idea was to give melee an edge in close quarters: If you're wielding a knife and facing a shooter, your best bet should be to get up close and stab your foe before they get a chance to shoot you.

Randomness: The system is mostly deterministic. Attacks have fixed damage, and there is no probability "to hit". Instead, melee sometimes deal grazes (half damage) or critical hits (effect depending on weapon). Firearms have a chance of going wild, depending on conditions like cover and skills.

Game changer
This may sound good on paper, but I've been vexed by the fact that melee in particular doesn't work well in practice. There was a problem of getting ganged up on, since taking more than one hit in a single turn almost invariably depletes a whole HL, something that should be avoidable with clever tactics. On the other hand, the rapid bruise regeneration means the player often has to land successive blows to properly wound the enemy, in turn taking as many hits himself. Likewise, it doesn't make any sense for instance to stab once and then spend some turns to wield and cock a gun, since the stab wound will be fully healed by the time you pull the trigger.

There's also been a problem with balancing damage. Comparing a club and a knife, they both deal 2 BLs, but the club spreads the damage over several HLs, whilst the knife puts all of it in a single HL. At the end of the day, the knife is almost unambiguously better, since it has the chance of depleting HLs more quickly.

However unbearable I find the current states of affairs, this system has been in place for years now, and me stumped as to how to fix it. Should I try to make something different altogether? Introduce a standard hit points system? God forbid! I'm giving the current rules another chance, and started by just tweaking the existing values.

Here are some of the changes I'm trying out currently:

Damage output: I made mostly everything deal a little less damage. I figured the lower tier weapons (bowie knives, tools, whips) can deal just a single BL in damage, and still be better than unarmed fighting, since unarmed fighters are unable to score critical hits. Increasing the player's health might also be an option here.

Bruise regeneration: Bruises now regenerate every second turn, and healing the last BL of a HL takes another extra turn.

Interrupted actions: I've disabled this almost completely. If an actor gets hit right before carrying out an attack, that attack is no longer blocked, but rather guaranteed to be a graze/wildshot. At point blank range, a wildshot will hit the target about 50% of the time.

This already works better than before, even if it's basically the same rules. For one thing, a couple of angry animals won't kill you in a single turn, even though it's still bad to get surrounded. The slowed regeneration rate means that there is more time to apply actual tactics, like spending a turn to reposition, without all bruises being reset. The fact that the last bruise in a HL takes an extra turn to heal also gives an advantage to weapons which deal damage over several HLs. A weapon dealing 2 BLs to a single HL still has an edge when it comes to quickly whittling down your enemies HLs, whilst a weapon dealing 1 BL to two separate HLs is less of an immediate threat, but will give an advantage a few game turns down the road.

I may still have to make some more fundamental changes to how combat works, but it's refreshing just to see the game work slightly different from what I've grown accustomed to.

Props unbound

Inspired by the moderate success with switching around combat rules, I'm also trying some changes to the inventory system. Again, some pretty arbitrary principles had grown out of the original game (some of them outlined in an earlier post). For instance, I felt that limiting actors to carry only six items at any time was pretty neat, since dead dudes would just drop all their loot in a nice circle around themselves.

Now, I've upped the inventory cap to 12 items, which really just lets the player carry more trash around (although balance issues may arise later). Secondly, props are now dropped and picked up from adjacent hexes rather than the one you're currently occupying.

The effect on gameplay is minimal, but I may keep it this way, just because it offers a solution to a problem I've been having: how to give props to NPCs? I didn't want a separate "give" command, so instead I implementing a heavy-handed system for offering NPCs stuff by dropping it in their field of vision. This is how you currently collect bounties from judges, by plopping the severed head of a goon in their vicinity. God only knows if a single player has yet picked up on the fact that this is a thing, as it's only vaguely hinted at in the dialogue. But if props are dropped onto the hex right in front of to you, the system pretty much gives itself: Simply invoking the "drop" command when facing an NPC should make for a pretty intuitive and smooth interface.

Current shop layout, and more spacious mockup
D=door, s=shopkeep, c=counter, p=props
I'm slightly concerned that some veteran RL players may find this counterintuitive. It's still possible to pick up items you're standing on, but that has the disadvantage of not properly teaching how it "should" be done. Players who fall into the habit of walking on stuff to pick it up, will in effect be wasting a turn as opposed to players who fall naturally into using the new system. There are some possible ways to fix that, either by making it a free action to pick something up, or even let props on the ground block movement. This last solution would mean some pretty drastic changes to tactics, but might even work when I start making everything a bit more spacious, which is something I've planned in any case.

Come what may, it's always good to break habitual thinking by changing the rules around a bit. Every dead end explored is a step in the right direction.

As always,

by Aging Minotaur ( at June 18, 2017 06:01 PM

Roguelike Radio

Episode 137: Book on Procedural Generation in Game Design

Episode 137 of Roguelike Radio, where talk about a new book on Procedural Generation in Game Design, with Darren Grey, Mark Johnson, Tarn Adams and Tanya X Short.

Read more »

by Darren Grey ( at June 18, 2017 04:25 PM

June 17, 2017

Land of Strangers

LoSt this week (2 steps ahead, 1 step back)

It's been a while since I found the time to anything substantial with LoSt, but this week I managed to put in a few coding sessions and implemented some features that I've long been wanting to have. 

So I fired up old trusty byzanz to make a gif, which came
out slightly discolored, but I kind of liked that crusty feel. 
First, I got in a basic function to zoom in and out of the map. This will provide the framework for waypoints/travel, a logbook, etc. later on. Even in its current bare-bone condition, it provides me with a nice tool to examine my maps. It is an example of something which it is perfectly lovely to make. Since it'll help me as a developer, I'll of course be furnishing that map with icons to represent waypoints and other points of interest. And I probably won't be able to resist adding some ornament, like a compass rose or a smooth transition animation. All of this will only enhance the play experience.

Coming soon to a GUI near you?
Today I sat down and wrote the outline of an editor for place themes/blueprints. It's been cumbersome to use a text editor to make these, and the simple little application I hobbled together this afternoon is already more comfortable. It just makes the blueprints, so I still have to write the map legend by hand (rules like eg. fill hexes marked "E" with walls, put 1-3 shooters at "s", pick and put features/loot at "a", "b", and/or "c"). But it might make sense to add the function to set those parameters straight from the blueprint editor. It would have to be able to write blueprints as well as regular kits, which are the data syntax I use to store almost everything in the game. A few releases down the road, the actual game might even ship with a full fledged content editor that can be used to add/mod places, critters, props, bounties, skills, etc. :)

I hope to use these tools to do a rather extensive overhaul of the world building routines, that I've been dreading on the horizon for quite a while. The thing is that the current Python class used to build places is very all over the place. So I want to go through it and remove crud, as well as adding some tweaks and variables that I'm going to need to implement the next big thing in LoSt, namely bounties (random quest lines). Let's hope I manage to be clever about it, not leaving too many traps for myself later on. There are details I would like to get right sooner rather than later. For instance, I've been feeling that the game world is a bit too constrained. To amend this, I must above all make some inspired changes to the combat system, but I want to try to tailor them to fit a world with more space. Ideally, a house should have room for a table with some chairs that several people can comfortably walk around. For this alone, I only need some minor tweaks to the code, but when the time comes to remake all the old blueprints, I'm pretty hopeful that my little editor will be a nice tool to have. I've been digging up some maps of Western towns, thinking it should be possible to generate something similar, using map chunks. Typing out big map segments in a text editor was a great hassle, though, and is going to be much easier now.

A sleepy settlement

Nail Soup

I mentioned that bounties are the next major feature to show up. They introduce a whole new feature to design, and it's a feature that touches on practically every other part of the game. From the world map, to dialogue, to props, to combat, to the skill system, everything seems to come together around bounties. It's also a point where the setting is bound to become much more defined, which is a Good Thing™. Although I've always liked that early stage of creative development where everything is still lying quite open, I'm also looking forward to getting some meat on the bones with a starting settlement to provide the player with plot hooks, a place to rest, important NPCs, etc. 

Long term readers will note that I've already touted the coming of bounties as a feature for quite a while already. But it feels now as if I have to deliver at least a rudimentary fun game within the next few releases, or I might as well abandon the whole thing. Not said in a pessimistic note, rather hopeful that I might manage to reach the next stage of development in not too long a time.

Bounties will provide some sense of purpose and direction to the game, by stating explicit goals and pacing healing and advancement of skills/reputation between missions. But as I mentioned earlier, I also have to fix the combat system somehow, to make melee a more interesting option. As is, fighting happens too fast and is too deadly. There is usually no time to do any fancy footwork before you're dead, even if the game points in that direction with "fancy footwork" skills like Tumble and Feint. I may test "slowing down" combat a bit, giving everyone (at least the player) a tick more health, and making most weapons deal a bit less damage. Maybe even natural regeneration of bruises should be slowed, as long as the system stays transparent. The player should be able to take a hit or two as he spends a turn repositioning, switching weapons or using a skill. If I start with gentle tweaks of what I have, it's hard to say in advance if I will stumble upon something that works, or get some completely other idea for how to do it.

And really, it's not just a question of rebalancing the actual combat system. Other planned features will have an effect. For instance, there will be more ways to gather posses to aid you in battle (currently doable with the Populist shtick), and I am planning AI templates that will allow non-lethal battle, in particular surrendering (by dropping your weapon) and capturing (using rope or chain). And so maybe it will be okay for the combat system to be on the lethal side, if the player can (un)reliably hope to solicit the aid of NPCs or let himself be captured by the bad kids rather than outright killed (leading to possible interesting escape scenarios).

It feels a bit like I would want to do all the changes at once, just to be able to see how they interact. But I guess it's more like cooking. You start by frying the garlic and then the onions before getting on to the saucy parts. And a good saucier can predict how a sauce will turn out in advance, when it still only tastes like flour and salt. Me, not so much. I have this floury soupy slop, for sure, but no inkling of how it's going to turn out in the end.

As always,

PS. The current working title of LoSt is "Nail Soup", which is obviously an allusion to Dungeon Crawl: Stone Soup, although the allusion itself may be less obvious: "Stone Soup" is (so I've heard) a Portuguese fairytale about a vagrant who fools some villagers into believing that he can teach them how to make soup out of nothing but stones and water. They gather round, and the vagrant starts cooking, after a while remarking how the soup would be even better if they added a few carrots, perhaps. One of villagers happens be in possession of that precise vegetable, and so they add a few. After a while, the vagrant says this is gonna be good, but it would be even better if they added some chopped potatoes, and so it goes. In the end, the soup turns out pretty awesome of course, since everyone chipped in, which is the morale of the story. "Nail Soup", on the other hand, is the Norwegian variety of that same fairytale. Here, the protagonist vagrant meets with a single old crone in a house, asking to spend the night if he promises to teach her how to make soup just from nails. The story proceeds more or less as its Continental cousin, except here the hero is just ripping off a single person, so that the productive/social morale of the story is flipped. When a Norwegian speaker talks about making nail soup, that means rather to make something with no or meager resources.
And there was much rejoicing

by Aging Minotaur ( at June 17, 2017 11:34 PM

June 14, 2017

Grid Sage Games

Cogmind Alpha Year 2 Sales Data (Pre-Steam)

Cogmind recently made it through a second whole year of its pre-Steam early access program, and as this period comes to an end I’d like to take the opportunity to, like the first year, share some data and pretty graphs :)

This is an interesting milestone because it more or less coincides with the completion of Cogmind’s primary content, represented by the Beta release just last month, meaning it took around two years of work to bring the game from Alpha 1 to Beta 1. And it’s still amazing that support has been sufficient to maintain full-time development for this long--Cogmind’s lifetime revenue passed the $100k mark in April :D. So a big thanks to everyone who has helped it reach this stage!


@’s celebrate the Beta :)

For a more general summary of late-alpha progress you can check out the data in my 2016 annual review, whereas this article will instead be mostly looking at revenue and pricing. And while the first year of sales data was neat simply because it was seemingly the first time anyone in this genre has provided so much open data, the second year is much more interesting due to tier and pricing changes.


Let’s jump right in: Cogmind made US$ 40,325 in its second year. Looking purely at the numbers, that’s only two-thirds of what it made the year before, but it’s important to note that a $25k chunk of year 1 revenue was earned in the first month of alpha alone, the result of pent up interest from two years of open pre-alpha development prior to that. In that light, the second year has technically been a little better than the first in terms of revenue, an 8% increase from $37k to $40k.


Cogmind Year 2 daily gross revenue, annotated (Year 1 graph here). (Click on any image in this article to see at full size.)

Year 2 started with a minimum price drop, from $30 to $24.99 (albeit by adding a new lower tier without any perks, and keeping the old price as an option). This naturally sparked a good number of sales in the short term, which eventually died off as player growth returned to normal once those who’d been waiting for that to happen got their hands on it. At this point the price change didn’t seem to have any long-term impact, but we’ll get to data on that later.

The next noticeable bump coincides with the Roguelike Celebration, an awesome event at which I gave a talk and news about Cogmind subsequently made the rounds. The effects of that alone lasted for a good couple weeks.

Then the obvious spike is obvious :P. RPS has been following Cogmind since pre-alpha and I hadn’t expected to see anything more until after alpha, but it was a nice surprise to have a sudden article about my work arrive the following month.

Starting mid-November, buyers in the EU could finally get Cogmind “VAT-free,” which basically boils down to a loss for me though it’s technically the industry norm to include VAT in the list price. Considering I was still losing money throughout development it took me a year and a half to reach a point where I was willing to eat a 20% cut in revenue from those regions. Since I made that change, between November 15 and June 6th $5,085 of actual revenue received originated from EU countries, meaning $1,271 went to extra taxes (a low estimate). That’s all money I could’ve kept for development if Cogmind was available before 2015 when the EU introduced VAT for online purchases!

For New Year’s day I made an ASCII fireworks gif (actually the first iteration of the one shown at the top of this post) and that garnered some attention, which pretty much always translates to more sales. That’s not why I made it--it was just a fun side project to see if it was possible with the engine, but it’s nice that it had that side effect :)

Valve pre-announced the end of Greenlight in February, and since I 1) wasn’t sure whether I’d like what would replace it, 2) know that having a little Greenlight campaign is itself at least worth some exposure, and 3) already had all the required media on my own website anyway, I decided to put Cogmind up for voting. There was literally only two days between the time of this decision and hitting Publish :P. It was greenlit not long afterward, but that wasn’t really the point--notice that nice little spike in the graph… it’s nice to have some free exposure from Steam when people who’d rather not wait can already buy from my site! Putting Cogmind on Greenlight clearly contributed an instant $750 or so to revenue :D

In April I again lowered the price, to its current and final base price and the level at which I’ve always planned to sell Cogmind once the main game reached completion. In that sense the price change came a little earlier than expected, since the Beta release wasn’t to happen until early the following month, but sales had been flagging over the previous six weeks and I couldn’t let revenue fall too much since I’m relying on it to get by before bringing a mostly complete Cogmind to Steam. (Other reasons: It was also a good excuse/opportunity to do a little advertising that didn’t overlap with the upcoming Beta release, and I also wanted a longer buffer between the price change and Cogmind’s upcoming Steam debut.) I actually silently lowered the price a week before even announcing the change, just to see what kind of impact it would have on random visitors. It seems to have been beneficial, though one week is too short a period and there are too many other factors at play to really draw any conclusions. (I’ll share more data below to shed light on conversion rates.)

The most recent mini-surge surrounded the Beta release, a pretty big milestone considering it allowed me to declare Cogmind essentially complete by multiple metrics. A number of people were waiting to hear that, and the price had already been lowered the previous month, factors that combined to generate a decent amount of revenue for May.

Another factor that I find valuable in examining daily revenue graphs, but that you might not immediately notice above, are “zero days.” Any day during which there are no sales at all is a zero day, and too many of these, especially in a row, can honestly start to get demotivating. On the other hand, ongoing streaks of anything-but-zero days are quite motivational--even if just one or two sales. I always keep an eye on that sales number (it’s easy to follow because I receive an email for every purchase, and I don’t look at them but each one increments a label-based counter in my inbox :P), and if I start to see zeroes it means I’m not quite doing enough outward-facing development, like sharing my progress across social media. I always work harder when there are continued sales every day, so getting into a routine of posting updates is a nice long-term self-reinforcing cycle--especially when I wake up in the morning and get to see how many there were overnight! That’s been a ritual wake-up habit for the past two years now…


The all-important Order counter :P

Throughout Year 2 I made a more concerted effort to ensure there was always something to show at least once every week, and I believe this is reflected in the relative number of zero days: Year 1 was 9.8% (36) zero days, compared to 4.9% (18) in Year 2. In fact, the improvement is technically even better than that: notice a third of Year 2′s zero days occurred close together over summer 2016--that was during my one-month vacation. No work, no pay xD


Cogmind Year 2 revenue zero days.

Looking at revenue on a monthly basis, there’s been a clear positive trend over the past year. (May passed $3k with its Beta release, though isn’t shown here as it technically extends into the third year.)


Cogmind monthly gross revenue, annotated.

I’ve labeled a few of the larger effects already discussed earlier, though I can find no reasonable explanation for March. The graph includes Year 1 for comparison, though I didn’t annotate those months--that stuff was covered with the first year’s data.


Cogmind Year 2 monthly gross revenue by country.

By country the revenue data doesn’t hold many surprises. Comparing to Year 1′s country revenue graph, the only notable difference is that Germany overtook Australia, somewhat interesting because as an English-only game Cogmind is assumed to mostly sell in native English countries. Of course, Germany does have plenty of English speakers as well as three times the population of Australia, and (perhaps more key here) more than one German LP’er picked up Cogmind over the past year. (Plus there was the mentioned VAT change in November!)

That graph would be far more interesting if there were localization, but at least this gives you an idea of what an English-only fairly text-heavy game can achieve in an international sense. Localization is a great idea for any game that can manage it, but sadly it’s simply not possible with Cogmind.


But we do have some extra interesting data to analyze for Cogmind’s second year of sales, now that we’ve been through multiple tier and pricing adjustments!

At the beginning of the year I wrote a lot about Cogmind’s first price change in 2016, including some common and not-so-common variables factored into my pricing decisions. Here I’ll add to that discussion with some final results of that change and the most recent third phase.

As a reminder, Cogmind’s base price was $30 for the first 12 months, $24.99 for the 11 months following that, then $19.88 for the last month of the second year (and on through today). In the context of daily revenue above I already talked about some of the more immediate effects of those price changes, but the bigger picture holds a few more details. One element I finally have enough data to explore is Cogmind’s conversion rate.


Cogmind lifetime conversion rate (2015.5 ~ 2017.5) based on buy.html visitors.

I wouldn’t read too much into that graph because there are a lot of factors at play here, so many that this data is not quite as meaningful as it appears, but it’s fun so I wanted to talk about it anyway :P

First of all, notice that it’s specifically the buy page! Unlike most other indie developers, I don’t put a buy link on Cogmind’s main web page. In fact, I also don’t even put it front and center at the top of the buy page itself! I prefer to 1) avoid generating impulse buys and 2) manage potential player expectations. Thus I intentionally force visitors to wade through other stuff before finding a link to actually buy the game :). Yes, it’s counterproductive from a marketing standpoint, but I don’t care, I’m here to build a good game and foster a healthy community, not rake dollars from random people on the internet.

Thus this source data definitely skews the conversion rate higher, because anyone arriving on that page already has a somewhat higher interest in purchasing than the average visitor. (Note that based on general industry data, those rates are high.) For comparison I did the same with /cogmind/index.html.


Cogmind lifetime conversion rate (2015.5 ~ 2017.5) based on index.html visitors.

Part of the problem with sourcing stats from main page hits is that they’re filled with referral spam which can’t always be completely distinguished from real visits (which, like incessant referral spam, may simply leave without visiting other pages :P). This is why using the buy page provides nicer metrics, because it doesn’t get referral spam--we just have to remember all the additional factors that feed into the buy.html stats.

Getting back to those factors, Cogmind’s exposure comes primarily via roguelike-focused channels, so new visitors coming to the buy page are already going to be of a rogueliking disposition and even more likely to buy :)

Also specific to the fact that I prefer basing data on the buy page, there are a lot of people who have followed development for a long time, even years, who eventually make the decision to buy when it’s right for them, whether due to a lower price, the right timing, or a combination of other personal factors. I believe there’s a fairly steady stream of people who fall under this category, and they’ll naturally just go to the buy page and… buy. This is often after having mostly obtained information about the game through one of the other channels I frequently use,  like Twitter, r/Cogmind, the forums, the dev blog, TIGS, Bay 12, Facebook, etc…

Regarding what appears to be an upward trend in the conversion rate, while it makes some sense when paired with the fact that the price comes down for each period, I think that trend is much less meaningful on breaking down the average number of daily visitors and thinking about where those numbers are coming from. For example in its first year of release Cogmind had the greatest exposure on a number of major websites, so naturally visitors from those sites were less likely to be among the target audience. That was the highest average at 71.8 visitors per day. The second period, during which there was much less general exposure, saw a significantly lower 47.5 visitors/day. And the most recent period with the lowest price, albeit shorter, recorded only 43.5 visitors/day, yet had the highest conversion rate.

Of course, knowing this doesn’t negate the fact that Cogmind’s website and my frequent (if minimal) outreach efforts are fairly effective at selling the game to those who are interested. And on the reverse side, supporting the likelihood of an improving conversion rate, obviously during each consecutive period Cogmind was closer and closer to completion with a longer and longer history of steady releases. That helps convince anyone just discovering the game that it’s both a substantial and promising project.

One of the buyer behaviors I’ve really been looking forward to quantifying is the percentage of those opting to pay more than the minimum price, and how that changed along with the tier adjustments.


Percent of Cogmind buyers opting to pay more. (This data just looks at the two lowest tiers for a given period, since the higher tiers are more complicated and aimed at group buys. The Prime tier and each respective basic tier are more directly comparable.)

After Cogmind’s first year, during which $30 (“Prime Tier”) was the lowest price, I added a new perk-less Alpha Tier for $24.99. For the next 11 months, buyers could decide whether they just wanted the game, or if they could afford and would like to contribute a little extra in return for having their name in the credits. Surprisingly 13.8% of individual buyers still chose the Prime tier!

Part of the equation here would be the relatively low difference in price, percentage-wise. Only 20% more for some extra perks and to support a project they like? Why not? Compare to the rate after the price was lowered to $19.88, which means a 50% (!) increase for Prime, and the ratio of buyers choosing that option was basically halved. Many of the long-time fans interested in paying more to back the project will have already done so anyway. (Though also note that data for the latter period was only collected for about a month, because the Prime tier was removed as of the Beta release. That said, I don’t suspect we’d see much of a difference if I continued to sell that tier--it was removed primarily because development was entering a new phase, and keeping the “early supporters” tier active for much longer didn’t seem right.)

In the end I’m very glad I chose to handle tiers and pricing the way I did, because otherwise Cogmind wouldn’t have gotten nearly as much pre-Steam development as it has! Lowering to $19.88 sooner also probably would’ve been a bad move based on what I’m seeing now, since over the long term there’s been no noticeable increase in the raw number of buyers. Anything in the $19-$30 range really falls into the “too expensive” category for a lot of people, even more so if it’s not on Steam where the convenience of purchases can take some of the edge off a price, or where there’s more likely to be some sort of discount to provide additional impetus. (I’m still not working at getting more exposure to make up for the loss in revenue per player--it’s just the same old social media channels--but that’s why I chose April/May to do this, around when it’s time to transition to Steam.)

However, I certainly wouldn’t claim that sticking with $24.99 would continue to generate a proportionally higher revenue. Conversion rates would likely drop if the price remained unchanged. Each time I’ve reduced the price over the past two years, I was already feeling that sales were starting to flag and would likely continue to do so if I didn’t take action. Even if that may not have come to pass, I also knew that there was already pent up interest in a lower price, and it was about time to lower the gates a bit further and let more fresh players in.


So where does this funding go? Well, as a solo dev with relatively low asset costs, much of it naturally goes to pay my meager salary, and my job is to both create and sell Cogmind :)

As always I’ve been maintaining my detailed records of development time, which show that compared to 3,065 hours of pre-alpha development and 2,177 hours for the first year of alpha, Year 2 continued at a stable 2,192 hours of work. These numbers aren’t too pretty, because it shows that this is a lot of work for the amount of revenue coming in--certainly not worth it in an economic sense, but that’s okay for now as long as it’s been sustainable.


Cogmind development time, July 2013 ~ April 2017 (excludes 2012 7DRL work).

There’s always more coding to do along with any new features, so that has of course continued its long-term upward drive, and community-related efforts are finally starting to catch up to it as I spend a little more time on promotional stuff as the core game approached completion. Content-focused development accelerated significantly over the past year, which is what ate into coding time.

Comparing only the major development categories of Year 1 and Year 2 more directly, the shift from code to content is clear, while other areas stayed more or less constant.


Cogmind Alpha development time breakdown by major categories.

Because “what’s a good percentage of time to spend on outward-facing efforts?” is a common question among newer gamedevs, let’s also look at the major category breakdown for the project as a whole so far.


Percentage of Cogmind development time invested in each major area, July 2013 ~ April 2017 (excludes 2012 7DRL work).

So altogether it’s 66.7% game stuff vs. 33.3% community/marketing. This is really a bare minimum, which I can get away with because the traditional roguelike community is pretty tight knit with a small number of key places to stay in touch with players, making that part of the job easier. Other experienced devs will say literally half or more of your effort needs to be some kind work that helps get your game noticed (or in my opinion just as valuable: serves as time spent interacting with the existing player base).

I have much more behind-the-scenes dev stats and dedicated analysis to share once Cogmind is complete, though wanted to share a little of it in this article to give the revenue more context. (There’s also a month-wise breakdown of development hours in the latest annual review.)

Aside from dev time there have been a number of other expenses, but they account for less than 6% of the total budget (which doesn’t really have room for anything more xD). Music is something I’ve been thinking about, but how much money can be budgeted there is still an unknown for something that may not be entirely necessary and for which there are multiple valid approaches at different cost levels.

Cogmind still hasn’t broken even, but the hope is that it will as soon as it’s launched on Steam.

Next Step

It’s been a good two-year run of alpha releases (see history), and the ability to extend pre-Steam EA development has been wonderful for fleshing out the original vision--some of the stuff I’ve been adding, even entire maps, was totally not planned from the beginning! And as a result of sufficient support despite the previously higher prices, the player base could be kept from growing too large and distracting (as mentioned in my pricing article) while still getting constant feedback on new features and mechanics.

Now that the Beta is out and further development is mostly optional fun stuff, it’s time to seek out more exposure and put Cogmind on Steam :D. Performance there will be extremely important for the future of Grid Sage Games… so hopefully it can make a splash.


Making a splash.

This post Cogmind Alpha Year 2 Sales Data (Pre-Steam) originates from Grid Sage Games.

by Kyzrati at June 14, 2017 12:39 AM