Grid Sage Games

Teleportation Mechanics

By Kyzrati | Published: November 17, 2023

Teleportation. It’s cool. You like it. Your enemies maybe not so much.

The ability to teleport across short and/or long distances to instantly arrive at some destination is fairly common throughout the roguelike genre. Although teleportation can be used for tactical repositioning, or to perhaps reach otherwise unreachable areas (especially if the target is controllable), one of its most common applications is as one of many possible “escape” methods.

Sometimes you find yourself in situations where you’re at a significant disadvantage and would really like some sort of “reset” option, a perfect opportunity for teleporting. There might be drawbacks, like ending up in a worse situation than you left because you can’t control the destination, though as in any roguelike gameplay calculation you weigh the potential costs against the benefits.

Cogmind generally has fewer such direct escape options, but teleport mechanics are out there, if an advanced tech not usually available until the late game.

As a general concept teleportation technology exists in quite a few varieties throughout the world of Cogmind, though the player only has access to some of them. I’m going to go ahead and just make this a SPOILER discussion as far as game content goes, so that I can write freely about related mechanics, so maybe don’t read this one if you’re spoiler averse and not familiar with teleporting.

TR & NEM

So the first and primary form of teleportation is the original alien tech, Transdimensional Reconstructors. These offer very little control over direction, although based on their rules if you’re aware of the surrounding terrain you can possibly get a decent idea of where one might send you given your current position. The High-powered variety has a pretty significant range boost as well.

cogmind_teleport_from_my_stream_200929_warlord_win

Have a clip from my epic September 2020 stream (eventually a Warlord extended win), which was challenged to teleport when things were getting a little iffy, then they got just a little more iffy xD

These were also more recently expanded to support group teleporting--Cogmind and all nearby robots, but it’s only possible to create one of those in a single run (if that), essentially added for a fairly specific use in the extended game.

Come one, come all! No wait not like that.

Aside from those, there is the even more chaotic Navigation Efficiency Matrix, which forces unlimited but unpredictable repeat teleporting (basically “teleportitis” in roguelike terms). Like TRs it causes enemies to lose track of your position, which can be great for losing pursuers, but can also make travel quite difficult and if enemy density is high can even repeatedly put you right in their crosshairs while you’re trying to get away.

NEM has a reputation for being annoying, but also has its perks.

Unlike teleportitis in other roguelikes, NEM is “incurable” and stays with you for the remainder of the run, so it’s important to not acquire it unless you have plans to take advantage of the effect. It’s also possible to unintentionally acquire its effect if not careful in a certain area, so those who are aware of NEM’s mechanics might take measures to avoid that possibility, or maybe just risk it :)

The incurability aspect was important for balance, since being able to control the duration or timing of its effect, even broadly, would be far too powerful in Cogmind. While it’s possible to first activate it at a desired time, which affords at least some level of control, the inability to ever turn it off again always looms with the potential to cause regrets…

Limitations

The thing is, in any form (even a random one!), teleporting is a crazy good ability, so we need strong limitations on it to avoid abuse or simply circumventing many of Cogmind’s challenges.

For TR-based teleportation, that limitation is their single-use nature, a pure consumable. It’s a nice hopefully-get-out-of-jail-free card for your inventory, and you can collect as many as you want to fit, though taking up inventory space for each such one-shot opportunity is an obvious drawback, too, so you need to decide just how many it’s worth carrying for your intended goals or play style.

NEM and its chaotic effect is a whole different ball game that can be great for some builds, but there’s always the chance it’ll mess you up, so it takes a special embrace-the-chaos sort of mindset to use. Extreme randomness aside, its primary drawback is the fact that it cannot be stopped once started, leaving even less room for control.

Controlled Teleporting?

What Cogmind doesn’t have is a consistent way to do controlled teleports. Part of the reason such a mechanic was never originally considered is for input reasons--aside from attacks and hacking, which are direct in nature, Cogmind does not have a concept of arbitrary non-FOV targeting input, and I wanted to avoid adding such a method because it starts to suggest all sorts of other indirect targeting abilities, which become new ways to unnecessarily slow the gameplay. By extension teleportation ends up being more of the random variety.

Technically we do already have some teleport control, in fact very precise control, by combining TRs with Dimensional Node Initializers, but that requires having both of the necessary components and also having visited the intended destination beforehand to set up the node. It is a way to make a perfect escape back to a specific location, but obviously that is for preparing specific strategies rather than a general use case.

cogmind_dimensional_node_initializer_explosioin

Oops no that’s the wrong gif, don’t do that.

cogmind_dimensional_node_initializer_teleport_use

That’s better, although still not necessarily worth using up these potentially valuable tools, just a random scenario I recorded to demonstrate these items being used together.

Back in NEM’s earlier history when it was still under consideration for more serious mechanical adjustments, among those adjustments I thought about giving it a controllable teleport role, allowing you to stack multiple NEM in order to gain the ability to influence its direction through your prior movements, just still not always doing precisely what you want. I decided against that approach after seeing how others played with the NEM (and trying it myself), which seems to be in an okay spot.

So here we are in 2023 still without a way to manage controlled teleports, what do we do? How about we add one, maybe using this new type of charging mechanism (described towards the end).

In fact I have two new concepts for teleportation tech, which is kinda funny because of how they evolved out of the same idea. Some time ago I wrote some notes on a particular type of derelict likely capable of teleporting. Then more recently while away from those notes, and having forgotten many of the details, I jotted down a few more notes on the subject. When it came time to implement this feature last month, I discovered both sets of notes and realized they were describing two somewhat different systems! Both can fit into the lore rather nicely, though, and in fact be related to one another.

One form of this tech will be introduced now, and the other belongs elsewhere in the lore, a source which I’m not sure whether or when will ever be realized, since as I see it now it’s beyond the 1.0 horizon.

Personal Teleporter v0.10

You may have spotted this little thing among all the art I shared for new items last time:

…or not because there was a ton of art samples collected there xD

That is the Personal Teleporter. Clearly an early version of it because it’s not super precise… but it is controlled!

Once fully charged, which takes some time and energy as explained in my deep dive on that mechanic, your next move in any cardinal or diagonal direction will send you off in that general direction, and through any obstacles blocking the way.

A double personal teleport. Normally you’d at most probably have just one, but I’m testing it so I get two ;)

Like with microwarping and spacefolding (also somewhat comparable forms of teleport-like movement!), the interface will warn before your movement command is interpreted as a teleport in case you want to turn it off instead of flying off through the nether and using up your precious charge.

As part of this update I also improved the mouse behavior as it works with both this and microwarping, so that it will always immediately take that action on the first step (and highlight the intention as such) rather than moving to a more distant selected target location then warping, as it currently does in Beta 12.

cogmind_microwarp_active_direction_highlight

While the Microwarp Drive is active, you can see the usual one-step highlight of an adjacent cell indicating direction.

Now just while you’re thinking you got off easy, time to hit you with the drawbacks (no, silly, simply needing to charge the PT is not a massive drawback compared to what you get!).

First a little relevant dev note: When creating new item-based mechanics, internally I’ll generally use more generic names for effects. In other words the name “reconstructor” would not be used in the source code, since that’s specifically an item name, which 1) who knows, may change for whatever reason and it’s a public-facing name for that specific instance of a mechanic and 2) multiple different items could use the same ability with different values, so we don’t want an internal name that matches only one or another. The Personal Teleporter’s capability is known as a “rough teleport,” and now you get to find out why it earns that name (or you can stop reading now and find out later? spoilers :P).

The thing is, not everything that goes through this process might make it to the other side, or at least not take the exact same path to the destination area.

Yes if you’re feeling lucky (and are actually lucky :P), everything will go swimmingly and you’ll be on your merry way, but there is also a decent chance that one of your parts will be ripped off and flung over to some other nearby location. Or may simply not make the trip with you at all. Or if you’re really unlucky it could get stuck in subspace forever.

cogmind_personal_teleporter_part_loss_message_log

I didn’t need my reactor anyway.

So a teleport may result in a need to put yourself back together, if you have the luxury, which if you’re teleporting you may not exactly have, yeah? And if your part was left at the origin (not nearly as common, but it happens!), then if it was something really important you might have to try to find a way back, or do without. There are some other nuances in there which I won’t get into, but anyway, “rough” yeah? :)

I can see some people having a lot of fun with this thing, and I imagine it could get tweaked a bit after playtesting, but there are a good number of levers to tweak with this one.

It should also be noted that this cruder form of directional teleporting doesn’t lose any pursuers, unlike other more random teleportation capabilities, though the ability to pass through walls is probably sufficient to escape a lot of trouble when necessary (albeit perhaps at the cost of losing something, though to be honest my guess is the current cost vs. benefit is generally going to lean towards the latter in most cases!).

After the Personal Teleporter I also added a second source of “rough teleports” which is less rough, though quite challenging to find and has another kind of limitation.

Mysterious.

Stats

As part of this expansion, I’ve also updated the scoresheet calculations to include all forms of teleportation for that particular tally, whereas before it was purely TR types. So NEM and/or the new PT could inflate those numbers if and when acquired, which will also be obvious causes noted in the history log. The Subspace Traveler achievement will also be earned through any of these methods. Early on we only had one form of teleportation, so it’s about time to update these other bits in tandem. The Rincewind achievement is still specifically TR use, since that’s a challenge achievement rather than being discovery-oriented, aimed at acquiring that many TRs to begin with.

Happy teleporting!

This is the second post in a series on new item mechanics. I won’t be covering anywhere near everything (or even the coolest mechanics because I don’t like to spoil much :P), but some of these also offer a chance for relevant discussion of the bigger picture:

Posted in Mechanics | Tagged Cogmind, Items | Leave a comment

“Post-Balance” Cogmind Item Expansion

By Kyzrati | Published: November 15, 2023

Beta 11 was a huge milestone in Cogmind development, having completed a comprehensive review of all items and their stats and mechanics in order to rebalance where necessary, a process I wrote about in detail last year. The results since then have been great, but what comes next?

Fun. Lots and lots of fun.

Beta 12 was a part of that new direction with its expanded Garrisons, new faction interactions, and the Scrap Engine, but the main thrust is still in progress, aiming to bring tons of new items, robots, and maps for them to inhabit. Heck, Kacper‘s on board and there’s even going to be a bunch of new tiles :)

Despite being under full-time development for over 10 years, and certainly adding a fair share of fun secondary mechanics to Cogmind along the edges to keep things extra interesting, most of the work needed to focus on honing the core experience, and therefore the core content. However, aside from procedural generation and the potential unpredictability of unfolding events, special items and rare encounters are where it’s at when the aim is to ensure every run is fresh and exciting.

Well, after Beta 11 that’s where we find ourselves now, switching focus more and more to brand new elements that don’t need to adhere to any sort of core content accessibility requirements. There’s already a ton of core content--many hundreds of hours worth. Now it’s time for the very rare items, the very hard-to-acquire tech, the very difficult optional opponents, and all the implications behind them.

As part of this drive, for months I’ve been creating over 100 new items, most of them including new mechanics. Some individual items take days or even weeks to build. They’re that crazy.

cogmind_ascii_art_beta13_sample_preview_large_more

Sample ASCII art from among the 100 new items.

At the time of the Beta 11 rebalance Cogmind contained about 1,021 items, a number that I’ve increased by 11% so far, the vast majority of which have not been released yet.

Sourcing Ideas

To come up with new items and mechanics, I never just sit down to explicitly think them up. Good ideas do come spontaneously, albeit inspired by random discussions among players, reactions to various situations in game, even playing other games and consuming various non-game media. And I’m always ready to note down these ideas for potential later use, since after all there’s never enough time to implement absolutely everything, not to mention many ideas must wait for just the right opportunity or location to be introduced.

Having done this for many years now, that list has grown quite long, and now that plenty of new space is coming to Cogmind, space for more outlandish stuff, earlier this year I reviewed the entire list for the first time.

It’s not organized at all, being composed of ideas just slipped in at random locations each time a new one popped up, all filed under the heading “post-1.0 items” that was chosen back during alpha when it was first created.

The current beginning of my random still-unused item ideas list. It’s about 800 lines long :P

Here “post-1.0” essentially implies “after core stuff is done,” so we’re clearly at an appropriate junction to do this :) (regardless of versioning systems and the fact that in reality Cogmind is already far beyond what most people would consider 1.0…)

Anyway, it took a while to filter through everything (on the way even removing a few pieces of tech which had since been implemented without even recalling they were listed there at some point :P), but I did pull out a number of ideas that will no doubt be fun to play with. While none of them are central to the coming Beta releases, any time new maps are added a lot of content is needed to fill them out! Peppering them with cool stuff that you won’t see every run helps keep them from feeling too sparse or repetitive.

Balancing Levers

The idea of “post-balance” from this article’s title doesn’t mean no balance.

On the contrary, as you probably know, Cogmind is big on balance, an emphasis achieved initially through adherence to carefully designed patterns and formulas. But then Cogmind is also always expanding with new content that needs to fit into the existing world, either closer to that core or somewhere out on the fringes.

As far as core items go, simple stats are generally sufficient to enforce balance, but the tradeoffs and drawbacks required to balance more extreme fringe items may necessitate unique approaches. Some of the optional mechanisms to use for this purpose are more generic, such as giving an item limited uses, while others are item-specific, such as the Dirty Datajack being overall pretty awesome if 1) somewhat unpredictable and 2) eventually, inevitably blowing up in your face when it detonates a power source.

Rarity and difficulty of acquisition are in themselves balancing factors which allow us to make some new items even cooler than usual, which is essential one of our primary goals here, but most items still likely need their own balancing factors that come into play once acquired.

I’ve organized an overview of some of Cogmind’s special item balancing mechanisms below.

Disposable (limited uses): Interestingly I didn’t want traditional roguelike “consumables” to be an important part of Cogmind’s design from the beginning, and they still aren’t really, but technically all Cogmind items are consumable to a degree (they protect your core and have limited integrity), and later in development as I wanted to introduce more and more truly powerful items this was a good excuse to play the consumable design card. It’s a useful one since it offers really tight control, but I prefer to avoid overusing it if there are any other options available, since it’s kinda boring.

The new CPS Tube, a disposable item. You get two shots because it’s mainly meant to be a one-shot thing, but you might miss and that would be too mean.

Disposable-adjacent: Instead of a direct 1-to-1 use counter, an item’s remaining usage is represented in more granular fashion based on other factors, for example the new “ID Mask” item I’ll be introducing in a later post.
Item integrity loss on use: This concept is fundamentally similar to the disposable mechanic, although not quite the same thing since usage simultaneously weakens the item itself, making it more vulnerable to destruction, and for the same reason damage to the item directly reduces its remaining uses. The idea was pioneered by Vortex weapons, but you will occasionally see more of it where appropriate.
Core integrity loss on use: This one’s pretty cool, although applying it generally requires good enough lore or tech reasons. There’s a lot of room to play with core loss in the design, since it drains something you need to survive, but also tend to have a surplus of at various points on your journey, especially if you’re otherwise doing a good job protecting your core. In this case, saving core indirectly supplies you with resources that can be redirected elsewhere That said, doing so could also be risky since the weaker your core the less resilient you are to later surprises! Balancing factors with deeper implications like this are great. We definitely need more core-eating items ;)
Deteriorating: An item could degrade/lose integrity for every turn that it’s active. Although introduced in pre-alpha as a potential balance mechanism, this was only ever used for one item (Dirty Datajack!), and even that one was reworked along with the robot hacking system and deterioration is now a completely unused mechanic. It’s kinda fiddly so I don’t like it, but it technically still exists if needed one day. (There is a particular quest item that degrades over time, but that’s a different mechanic since it can happen anywhere and you don’t even have to attach it.)

An ancient demo image from Cogmind pre-alpha with a deteriorating item state listed on a hypothetical item.

Unique resource requirement: Unique resources can be a great balancing mechanic (be it via rarity, storage requirements, or other factors), and lots of roguelikes use them--think ammo types!--though in the past Cogmind hasn’t done much in this area precisely because that most common manifestation was simplified into the amorphous energy/matter system (much more appropriate for a game with a vast array of unique weaponry). We did eventually get the Latent Energy Streamer from the Exiles, which takes unique resources to the extreme by adding a whole new geographical resource layer to the world. Honestly that resource should get more use, and definitely would if Cogmind is developed long enough (there are Plans). Looking ahead, one of the new items to come is powered by… other items.

cogmind_latent_energy_visualization_animation_extended_range

Examining latent energy levels in the area.

Overall the more such levers we can add, the more interesting items and strategic/tactical considerations we can create, branching out into different design and gameplay territories. Everything on the above list has existed in some form or another for a long time, so it’s not often that high-level non-item-specific balancing mechanisms are added, but there’s a new one coming soon: chargeables.

Chargeables

We can already indirectly create “chargeable” items (and have :P) by simply giving them huge energy requirements, enough that only a small number of uses is feasible before having to generate more energy, though this approach is technically a bit of a fuzzy limitation that can be circumvented by storing massive amounts of energy in advance, so such items have to be designed taking that possibility into account.

What about an alternative item-centric approach that also essentially enforces a minimum time limit between uses? This way we know the maximum rate at which such an item can be used, plus this kind of item is likely more accessible to builds that don’t have the capability to supply large bursts of energy at once.

Two different ways to implement the same general concept will be more appropriate for different kinds of applications, further expanding the pool of item design possibilities.

When adding any new feature, or in this case a balancing mechanism, it’s important to ensure the UI can keep up with any needs. No big problems there, as charging is a fairly simple mechanic where you have charging and charged states, and it can only be used once the latter is reached.

While charging an item its charge countdown is shown in an adjacent part label, like so:

cogmind_chargeable_voltaic_drivehammer_charge_label

Tag for an attached chargeable weapon.

In this state the item cannot be activated, of course begging the question of just when and how it’s charged. I originally imagined this to be something you could actively toggle, but that would require utilizing the third item state (overload style), which might have other uses for a chargeable item, so it’s best to avoid that approach. Instead the charging happens automatically, as described in the state context help on the item’s info page:

cogmind_chargeable_item_state_context_help

Different object states have also been getting unique context help relevant to their specific mechanics, rather than a generic description of the stat.

The so-called “charge rate” is specified in the item’s description, which includes a phrase like “Charge rate: 20 energy * 35 turns” or whatever its energy/time requirements are.

When the item is ready to be used it’ll play a charge up sound and you are free to blast away. It will also indicate that state directly in its name, in case you want to charge it up then store it away in your inventory for later.

cogmind_chargeable_voltaic_drivehammer_name_charged

They should be afraid. Very afraid.

That said, chargeable items don’t have to be weapons! This just happens to be the first one I created. I wanted a weapon designed around a particular offensive concept but if made as powerful as planned it would be too ridiculous if used in rapid succession, but I also didn’t want to make it yet another case of disposable weaponry and would prefer it become a long-term tool one could reuse again and again if you keep recharging it.

The other chargeable item I put together after this one, which I’ll be sharing next time while discussing a different topic, is actually a utility.

This whole article started out with a discussion of balance, and while I’m sure this new mechanism has potential, I can’t yet say I’m entirely sure just how the balance will work out with these brand new items. They will likely get some tweaks after playtesting, and purely from a theoretical design standpoint I think it may be necessary to at least require that charged items remain attached to retain their charge. We shall see. It also really depends on how they want to be balanced in the bigger picture, as well as how people abuse, I mean use, them :P

This is the first post in a series on new item mechanics. I won’t be covering anywhere near everything (or even the coolest mechanics because I don’t like to spoil much :P), but some of these also offer a chance for relevant discussion of the bigger picture:

Posted in Design | Tagged Cogmind, Items | 1 Response

Roguelike-Discord Integration Using Webhooks

By Kyzrati | Published: June 30, 2023

When Cogmind’s first commercial version was released in 2015, I simultaneously opened the brand new Grid Sage Forums as the main gathering point for the community, a way to share stories, provide feedback, and generally discuss the game. Back then forums were still one of the most common ways for game communities to interact, and I also wanted to maintain such an outlet over which I had complete control (i.e. on my own server and with my own settings and design) rather than making a home under the umbrella of some other company where we’d be subject to their whims over the long term.

The good old GSG forums!

Well… after a year of navigating Cogmind’s early alpha progress with the community on the forums, which were pretty active over that year, Discord came along and became that “other company” xD

Of course the product is different, and therefore we can easily see why it could do such a thorough job of supplanting the forums--it’s simply better suited to this sort of use, hence the now huge majority of games that use it to build engaging communities. Faster, easier real-time communication with devs and other players alike, together with more natural support for multimedia… I guess forums didn’t stand a chance xD

Interestingly, IRC could have been seen as an alternative, or supporting, possibility for community interaction, and there were some who wanted to do that when Cogmind was first released (I was there, too, for a short while), but we have to admit IRC is just not as good for most people--Discord essentially took IRC and made it more easily accessible to the masses, which is apparently exactly what the masses wanted and needed.

For a while myself and a few other players tried to keep the forums active, but the community drive to relocate to Discord was swift and unstoppable…

The forums are technically not dead dead--they still get used as a more official repository for bug reports, or by someone who wants to post something to a location more permanently and easily accessible to all. It’s also my primary outlet for official announcements (this is noticeable when, for example, my release notes are too long to fit on Steam so I link to the forums where I can share them in their full glory because, again, I control the settings to allow that :P). And we use the forums for the occasional REXPaint feature/help discussion, so yeah they have their uses even now.

Roguelikes Discord

Back in mid-2016 a couple of friends decided to make a new Discord server on the topic of roguelikes, and started asking relevant devs like myself to join. I decided to try it out, and it was kinda neat being able to chat with other roguelike players in real time (oh no, we moved further away from turn-based chatting?!).

The Cogmind community started showing up there pretty fast, draining active participants from other outlets (including the main forums, subreddit, and relevant threads on other forums) since it was just so much more natural and enjoyable to engage others via flowing conversations rather than delayed posting and repeated reloading of web pages.

The server became the home of many traditional roguelike communities (small as they may be), and also the “official” Cogmind server, which I like to keep embedded there with all the other roguelikes.

Current #cogmind channels on the Roguelikes server. We ended up adding more and more Cogmind channels over the years, though most are hidden from the average server member so it’s not too annoying unless they’re actually there for Cogmind content :P

Seven years later we’re still there, with a lot of the same folks cycling in and out over short or long periods, and veteran players mentoring newer ones. We also often get interested in other roguelikes on the server and play those :)

Anyway, Discord definitely has its drawbacks, but it works well as a primary communication tool for gaming communities so it’s no surprise its use has exploded over the years.

Discord Integration?

When a community is heavily concentrated in any one form of social media, you naturally start to think about leveraging that platform to encourage community interaction and improve the overall experience. Discord itself of course wants to capitalize on this effect and promote related features, so it provides an SDK for doing such things.

The first feature some might imagine with regard to using the SDK is at least some form of so-called “Rich Presence,” which is what I considered a long time ago when players asked about that as a possibility. But I didn’t want to bloat the size of the game just for that--didn’t seem worth it.

On the contrary, at the time I realized that I already integrated the Steam SDK by necessity (and it’s a separate build from the DRM-free release, therefore only affecting those using Steam to begin with), so I figured it might be low-hanging fruit without any drawbacks to at least introduce Steam’s Rich Presence as a fun little side project. I did that in 2019 and wrote about the process here.

But integrating with Discord never appealed to me.

Then I learned more about webhooks and had an idea.

Webhooks!

It turns out you can technically do a form of Discord integration without their SDK, using these “webhook” thingies…

Now I’m sure this was obvious to people versed in Discord or even online platforms in general, but even having seen some in action I’d never really known how webhooks work, me being generally ignorant of web dev.

I forget what it was that triggered the realization, but some weeks ago I became aware that 1) without embedding the Discord SDK I could 2) simply have Cogmind send messages to the Discord server, and that was all I needed to know to come up with a potentially cool new feature ;)

Discord’s dev resources cover everything you need to implement webhooks, at least on their end in terms of what you can do and how to format each type of data. On the game side you’ll most fundamentally need a way to make an HTTP POST request to provide the message text. That’ll be handled differently depending on whatever languages or libraries you’re using, so I won’t cover that here.

One important consideration worth mentioning if you plan to send a lot of messages, and want all of those messages to actually be posted: You’ll need to have a way to handle webhook rate limits.

I got my first Cogmind-Discord interface all set up and properly sending messages that appeared on my test server, then I tried to do a bit of stress testing to simulate extreme scenarios only to find… not everything was appearing xD. Okay yeah that makes sense.

roguelikes_discord_cogmind_activity_webhook_stress_test

Me typing to myself in my solo test server as I was building this feature :P

So rather than firing off messages as soon as the game wanted to send them, I had to go back and rewrite it such that 1) there’s a message queue and 2) Discord’s server response is actually checked to see if the last message went through and 3) if not, what’s the requested retry delay and wait that long before continuing with the queue. A little more complex, but good to get that out of the way before releasing this feature to players then having it be an obviously substandard experience!

Fortunately there weren’t many technical hurdles to clear, even for webdev-challenged me. It helped that most of the heavy lifting could simply leverage all the past work on my HTTP interface and multithreading functionality, as I couldn’t see myself wanting to dive into this if I didn’t already have that foundation in place. As is it really was a nice little side project that didn’t suck up a ton of time and could comparatively provide the community with a cool new feature.

Content

Now that we have the ability for the game to post messages, what do we post? What’s relevant for a roguelike? And where does this content go?

First of all, since there could theoretically be a lot of messages coming in, and they could come in at any time, to avoid interrupting normal conversation in the server channels it makes sense to give the output from this thing its own channel. Thus #cogmind-activity was born.

We can still chat there, of course, just generally it would be in response to the info coming in, or even just drop emoji reactions to various events, overall new ways to interact with other players’ runs in progress (or that have recently ended) without them having to actively share any info like a summary or screenshots.

Webhooks need an icon to represent the bot, so I threw together a weird, uh, activity scene using random little things my son has collected, alongside my 3D-printed Cogmind from Runia.

I also added a way for the player to manually specify a Discord webhook of their own choosing, in order to redirect all the output from their game to some other server or channel they’ve set up.

As for the meat of the feature, what we’re posting…

Scoresheets

One of the most basic and frequently shared pieces of info about a run is a link to the online scoresheet, which contains a highly detailed summary of pretty much every aspect. I wrote a lot about these scoresheets back when they were further expanded in my Ultimate Roguelike Morgue File series.

This is also the first thing I was thinking with webhook use--players are often sharing these links manually, and the game knows the link, so why not just make it happen automatically for those community members who want to do that?

roguelikes_discord_cogmind_activity_run_summary

A sample run summary output in the wild, including scoresheet links and more.

In addition to the automated link sharing, you can see I also included a short summary of core run data, including final score, difficulty setting and any special event mode, the number of regions visited (good for getting an idea of how long the run really was), and the number of robots destroyed (useful both to show off as well as telling a lot about a run when compared with how many maps they passed through).

Then of course it’s important to know how the run ended, as in whether they were destroyed (and how) or won (and in which way, since there are many win types).

After the links I thought it might also be fun to directly include a printout of their final build state, as taken from the scoresheet itself.

In the above screenshot, notice how the webhook’s name is actually using the player’s name, in this case “szymekc.” This is one of many possible features offered by custom webhook data, and the alternative would’ve been to leave the webhook name static and instead include the player’s name as part of the message itself, but 1) that wastes space and 2) when there are messages from multiple players being posted in close proximity, this approach can make it a little easier to distinguish which run is which (an issue you’ll see come into play soon here).

Achievements

Although each player will only earn each achievement once, there are quite a few in Cogmind (and even more to come!), and many are quite special, so we may as well report on these as well. It’s also the kind of thing players tend to share on their own, having accomplished some significant feat, or even an unexpected or funny minor one, which means another area where automation might be able to contribute to the community.

Achievements appear bracketed and in italics.

History Log… in progress!

One of the major new scoresheet features described at length in part 4 of my Morgue series, Cogmind’s “history log” is meant to read as a sort of story-like summary of an entire run, highlighting special events, important accomplishments or changes, or otherwise potentially interesting or informative bits about the run.

It indeed works out as a pretty nice written review of what transpired, outside what typical numerical data and lists can show, though as is it’s of course something the player, or others, would read after a run is completed (or I guess it’s possible during the run, too, via mid-run stat dumps).

You can see where this is going. Once I got to thinking about what more could be offered via the webhook beyond the normal go-tos, the history log really popped out as an enticing option. We already have the power to describe much of what’s going on in words, let’s use it! So instead of just appearing in the post-run log, now each history message is pumped to the #cogmind-activity channel as it happens in real time.

roguelikes_discord_cogmind_activity_history_logging_sample1

Sample reporting of runs in progress from the latest build currently in prerelease testing.

roguelikes_discord_cogmind_activity_history_logging_sample2

Another history logging sample from #cogmind-activity.

Already we’ve already seen plenty of commenting on particular points during runs, whether from the player themself, or others in the community following the runs, posing questions or making observations. It’s also an alternative way to intermittently follow runs in progress when someone is streaming via Twitch or voice chat, when maybe there’s not enough time (or large enough display on hand :P) to watch the full stream.

As part of this update, I made it possible to set exceptions for some history log messages that I didn’t think needed to be reflected on Discord as well, somewhat less meaningful ones or those that could otherwise seem spammy. It’s not necessarily one single run we’re seeing, after all, but potentially multiple or even numerous runs that could be threaded together, so cutting away a bit of the excess is desirable.

Who knows, maybe seeing the history log output in this format and context might even lead to further adjustments and improvements to its content, now that we have even more direct contact with it, and in a communal space. Either way, there are certainly different thresholds for what we want to include in different environments.

Improvements

This whole feature has only just been added for the latest Beta 13 build released for playtesting among patrons, and being a relatively small side project it didn’t exactly go through the complete process of what all can we do with this newfound power?! As such, there are improvements I’m still considering, as well as some that were considered but left out (for now, pending indirect feedback).

Spoilers

One of the biggest dilemmas during the design of this integration was what to do about spoilers. Cogmind being a game that lends itself to long-term exploration and discovery, sharing and discussion between players is stratified into a few distinct levels of spoilers that the community does a good job of maintaining to respect the desires of many players to remain unspoiled until they discover content on their own.

In that light, it would make sense to, for example, apply Discord’s spoiler tags to all relevant content shared via the webhook to #cogmind-activity, making it so that anyone could hang out there without fear of being spoiled.

Unfortunately that would be a fair bit more work to achieve, and could also get kind of annoying with all the spoiler tags, so for now I decided the channel is basically full redacted content, no-spoilers-barred territory. Basically it’s read at your own risk, indicated in the channel description, which might cut down on participation there, but I think it’s the most realistic option for now.

Color

Another factor I considered while building it, and again revisited after it was released and I could see it in action with multiple players, was how to better differentiate runs when more than one is happening at the same time.

It seemed like color could be a potentially useful differentiator, where each player has their own randomly selected color for their run (from among reasonable/readable options :P), and all messages from that run appear in their color.

Unfortunately Discord does not support colored text via any sort of easy inline markup. There are several workarounds to apply color to text, namely by using code blocks and their associated syntax highlighting, or the newer colored ansi feature, or you can even get creative and insert some color before the text with embeds, but none of these approaches were meant for such a purpose, so of course they don’t do it well.

roguelikes_discord_cogmind_activity_colored_mockup

Using ansi color codes, which also forces fixed width code blocks, just takes up so much room… meh.

An embed-like approach with a simple color before each line of text could be a nice non-intrusive solution (if such a feature existed), since then entire text doesn’t have to assume that color and potentially be harder to read…

Actually, on that note, what about emoji? Oh my, the possibilities. Now that I think about it, it might be fun to allow players to optionally specify an emoji to represent themselves, which would appear before every webhook-delivered message of theirs and make it just a little easier to follow runs when they are overlapping, not to mention just being fun to play with/customize how your run appears.

At the simplest level, instead of picking their emoji maybe we can assign one randomly to each player for their run (which could of course be entertaining in itself, including for the player :P).

And how many types of colored blocks do we have access to? Since those could be an alternative to the embed idea, prefixing run-specific lines with simply an associated color. Accessibility concerns of course imply we should do this with full emoji rather than just color, considering we presumably have access to the full array. Imma go test this because it sounds cool…

roguelikes_discord_cogmind_activity_emoji_test

Emoji test. Yes… YES!

Okay I think we might be seeing more of that later :)

Other Supported Features

Discord webhooks are surprisingly powerful, and based on the API docs it appears there are additional possibilities we can tap into, like theoretically uploading game screenshots. To that end, perhaps there’s a way for the player to enter commands that control the webhook, such as when they want to manually send images or other info. Definitely more complicated, but interesting to think about.

The webhook’s avatar could also be modified for each player, doubling as a form of run differentiator, though this is only useful to those users displaying avatars, so maybe not ideal since it’s not universal, and could also get a bit confusing for some people when actual users show up to chat about runs and get mixed in. In that case it’s probably better if the webhook maintains a consistent icon, since its name is already changing, after all.

Another idea I experimented with was using code blocks to draw ASCII art that could make for fun viewing, like at the end of a run or to otherwise highlight interesting events, but while it’s neat I didn’t feel like the amount of effort required would really be worth it in the end.

While there’s more adjustments likely to come, at this point I think it’s safe to say mission accomplished, welcome to another cool community feature :D

Posted in Gamedev | Tagged Cogmind, Community | Leave a comment

Writing about Cogmind and Roguelikes, a History

By Kyzrati | Published: April 28, 2023

Something that’s kinda bugged me lately is when I look at the blog sidebar and notice that the article count in the archives seems to be trending lower, even though it doesn’t really feel like I’m doing nearly that much less writing.

Hm, numbers down-ish? Let’s find out more!

Now I’ve had some theories and assumptions to explain this trend, but it’s always best to back up assumptions with real data. I’ve now grown curious enough about the details that I decided to compile some stats to explore the situation a bit more!

While I have a lot of writing scattered across a number of different locations, I’m mostly interested in the dev blog since it’s a single centralized site that contains the bulk of my writing, and the data is fairly easy to extract from WordPress, so we’ll be looking specifically at this blog.

The results are a little surprising, but also in line with what I theorized, and can be summed up by examining the changes over the past decade as reflected in this one graph:

Cogmind/Roguelike Articles Stats, 2013-2022

Okay, that’s interesting…

Back in mid-2013 when I started this blog, it was the only formal outlet for information about Cogmind development, since I was highly focused on building the pre-alpha version itself rather than spreading the word. As such, I used it to report progress on many individual features, lots of basic stuff like item types, various machines, hacking, ally mechanics, sound effects, all sorts of fundamentals to show what I was up to each week or even just a few days.

In the graph there you can see those first years with an especially high total word count, but low average per article. Many of these came in at under 1,000 or even 500 words, which honestly I have trouble imagining today :P

That period lasted through mid-2015 when Cogmind Alpha was released. As indicated at the end of that announcement, I was going to start posting progress updates on the forums. Little did I realize this would eventually also start shifting the nature of the blog itself.

Since Alpha releases weren’t that few and far in between, instead of writing about everything on the blog I simply waited until writing the actual release notes to share details. Of course the blog continued, but I was more selective about choosing topics, focusing on those suitable for an interesting deeper dive into design and/or implementation, or especially those topics which might be of general interest to other developers (even outside roguelikes). Not sure about these days, but it was cool to learn that at one point this blog was ranked among the top gamedev-related blogs on the internet! (at least based on RSS feed data from various platforms; there’s no doubt more competition these days haha…)

I was overall still trying to write more articles during the Alpha period since there were many relevant topics I was interested in covering, but then 2017 came along and at the request of some players after the Beta launch on Steam I started providing weekly (or nearly so) updates on progress and various features, dubbed “SITREP Saturday.” I did fifty of those, mostly through early 2019 (though I occasionally use that title for semi-annual updates these days), so yet another outlet besides the blog to attend to.

Cogmind SITEREP Saturday Collection (xxx)

I wrote 32 SITREPs in 2018. These things are like decent-sized blog posts in their own right… I sometimes wondered if I should put all that on the blog, too, but this site really had become something different.

Release notes have also continued to grow larger and larger over the years :P

The Beta 11 release notes earlier this year covered a lot of ground!

So the blog was really left with only long-form articles about the biggest topics, and apparently just like Cogmind’s releases get larger and larger, so, too, do my articles here :P

Cogmind/Roguelike Articles Stats, 2013-2022 (annotated)

Same graph from before, annotated with additional context noted above. I also did a lot of writing for r/RoguelikeDev FAQs from 2015~2019, and started writing on Patreon in March 2019, though in the latter case especially a good portion of that eventually comes to the blog in some form anyway.

I didn’t expect to see that 2022 set a new record for the average article length! Although it’s clear the total word count dropped a bit, that the feeling stayed the same shouldn’t be too surprising since the longer the article the more difficult it is to write, leading to reduced efficiency.

Some other stats:

Years of publishing: 9.25
Total posts: 200
Total word count: 434,766
Total image count: 1,893

Notes on Writing

While we’re getting all meta here, I thought I’d take the opportunity to share some extra info about the process behind my articles.

As with many semi-formal writing projects that you hope to be nicely organized, I almost always prepare an outline in advance. Well-organized writing is not only easier for a reader to follow, but also probably conveys even more useful and relevant information while filling in blanks or expounding on certain sections to improve flow, which is better achieved at a higher level than when trying to write the actual sentences of the article itself.

Having an outline and/or at least notes in advance also leaves time for extra consideration and updating before writing. Plus it’s a lot easier to make adjustments to an outline than to an article which is already partially or entirely written!

In my case, if the topic is going to be about some specific feature I’m working on for Cogmind, which I’ll generally know and have decided in advance when working on said feature, I will actually save any notes related to the hows and whys of the feature implementation for later reference, since many of these will likely not otherwise survive once the feature is complete, but they’ll be a good resource for the article itself. Really they tend to form the more interesting backbones of an article! It’s not a question of simply what, but why and how. In that sense I’ll sometimes even make additional notes during implementation that I don’t need myself when building a feature, but that I think will go well with the future article.

And although I say that I may not need all those notes, I admit that writing such articles (or even just preparing to write them) does have a way of improving the results of development itself as I reflect more deeply on those hows and whys.

[Unfortunately I don’t have any of those outlines on hand to show you since I delete them when finished with an article, and the outline for this article is not so representative of what I mean, so… maybe I’ll come back and add one some other time.]

Research is another important component. Fortunately I write mostly about topics I’m already quite familiar with, or that are okay to approach subjectively as long as I can explain my reasoning, because good research can take a while. Of course I do it where necessary, though.

Pretty Pictures

Although this section is supposedly about “writing,” to be honest a major part of almost any article is not the text, but the images! Screenshots, diagrams, animated demos… I use a lot of images. They’re great tools for demonstrating what I mean, make everything more interesting for the reader, dress up the article up so it simply looks cooler, and by extension also provide something visual to share when discussing the topic with others or referring back to the article.

Cogmind/Roguelike Articles Image Stats, 2013-2022

A comparable chart of article image stats, somewhat less meaningful since the number of applicable images can vary widely by topic. Most longer articles might average around 10~20 images, but some like the art-oriented ones might have 60+, skewing the data pretty hard in some years. In any case, it at least shows that I like supporting images :)

I’m willing to spend quite a lot of time getting the right image, be it putting together a diagram or taking just the right screenshot.

I’ll play a roguelike for an hour just for a screenshot, even learning a roguelike I haven’t played before for that purpose, assuming I can’t find what I need online (which sometimes happens with traditional roguelikes since only so many people both play them and post their progress).

Even with Cogmind where I have complete control I’ll set things up and spend a while to record a gif showing exactly what I want (and in the precise way that I want!). Depending on the difficulty and complexity of what I’m trying to demonstrate, and more important how likely it is to occur exactly how I want it to, I may record dozens or even a hundred times. If it looks tough and like something I can improve the chances of getting a better recording through manipulation of game data I’ll do that, too :P (the same with testing any feature, really--gotta save time where we can!)

Aside: This also goes for non-blog Cogmind stuff as well, like preparing feature demos for release notes--I’m not going to simply get an approximate recording and call it a day, it’s gotta be perfect. I find the better approach here is to do recording after finishing each individual feature, not when it’s time to release, because by then 1) the workload is overwhelming and 2) I already don’t have the same familiarity with the feature as when it was just implemented, so the last thing on my TODO list when working on a feature I’ll need to demo is always “make a gif” :D

Anyway this article is pretty meta, but I found it interesting to learn after compiling the data that there are two opposite trends at work here, and figured some of the points I make by expanding on that observation could be of use to other devs, or even others just interested in what goes on behind the scenes.

This article weighs in at 1,646 words, not including this sentence ;)

Posted in Meta | Tagged Cogmind, Gamedev | Leave a comment

Cogmind Beta 11 Player Stats

By Kyzrati | Published: March 21, 2023

Beta 12 has released, and that means it’s once again time to examine player-submitted stats from the previous major release! Beta 11 was particularly special due to its sheer scope and secondary aim at rebalancing a number of fundamental mechanics, so unlike the usual shorter coverage of stats that I do over on the forums, let’s take a more comprehensive look at some relevant stats from Beta 11… (Beta 9 stats were the last I covered here on the blog.)

Overview

The data we’re examining spans the Beta 11~11.2 versions played from mid-March 2022 through the end of February this year, during which 935 unique players submitted a total of 11,207 runs. Of those, 895 (8%) runs are excluded here for being played in some special event mode, especially Polymind, for which I’ve already collected and shared stats in Part 2 of my Polymind design postmortem. Of the remaining runs, 10,062 had at least a score of 500 to be included in the leaderboards and general stats.

Patron activity was pretty significant throughout Beta 11 development, with 11 incremental prerelease versions to play, and since a big chunk of Cogmind player activity is by patrons (who also happen to be more likely to opt in to scoresheet submissions), technically an equally big chunk of our data can be traced to that group. That said, by default the stats below will ignore prerelease versions because 1) for our purposes we want to look at the final resulting “true” Beta 11, once it was no longer in flux, and 2) doing so also probably gives us a healthier cross-section of community data rather than allowing a small subset of players to significantly skew the results, as you’ll see in an example shortly.

In numbers, 2,997 runs were submitted from prerelease versions, accounting for 22% of the total (hence the real known run total was actually 14,204). I don’t really like the fact that Beta 11 ended up causing this large split, but that was a side effect of it being Cogmind’s longest beta cycle, and something we will generally be able to avoid going forward with somewhat more reasonably-sized releases and fewer prerelease versions.

Wins

Beta 11 added new toys and mechanics, but also some significant new challenges (Heavies! Cargo convoys! …), so as with most releases it makes sense to look for any impact on the win rate, which has remained stable for a while now.

Reminder: For win stats I only examine runs in Rogue mode, since that’s what the difficulty is balanced around, and it’s the only mode that enforces permadeath.

The overall win rate in Beta 11 was 5.3%, so a bounce back up from 4.1% in Beta 10, but not quite up to the 5.7% in the version before that. So still generally hovering around 1 in 20 runs being a win. However, as usual my preferred measurement of win rate is to look at the percentage of players who reported at least one winning run in that version, so I appended the new data to our graph from last time.

cogmind_beta11_stats_player_win_rate_beta8-11

Cogmind Player Win Rate (Beta 8~11, at least one win, Rogue mode)

Back to what I was saying earlier, notice the significant difference among those playing the prereleases, which tends to include many of Cogmind’s most experienced players.

Also interesting is the non-insignificant 33% uptick in win rate over the average from the three previous versions, which were relatively consistent. I can only speculate as to why this may be, but we can at least feel assured that Beta 11 is anything but a great increase in difficulty, and wait to see whether or how this value shifts in future versions. Is it an aberration? Or the new norm?

The most obvious potential reason, also reflected in the player count data, is that Cogmind had a smaller influx of new players during the previous version, leaving older players who are sticking around to get better and drive up the win rate.

Another interesting graph, especially when comparing prerelease data vs the final version, is the distribution of win types. Here we find that about 30% of wins are extended-game wins that achieved boss kills. That’s quite a lot! Still, compare to the prerelease community, where most wins (56.1%) are killing bosses xD

cogmind_beta11_stats_player_win_category_distribution_normal_vs_prereleases

Cogmind Beta 11 Player Win Category Distribution: Normal vs Prereleases

And the disparity there is not a potential side effect of smaller sample size--patrons alone reported 387 prerelease wins compared to the 454 of the entire public release group.

Difficulty

For the purposes of the remainder of this stat analysis, I’ll no longer be differentiating between difficulty modes--everyone’s included, though we can at least once again look at the ratio of players in each mode to see if there are any changes.

Cogmind Change in Difficulty Distribution (Beta 8~11)

It seems there’s no clear trend emerging, so we have found our normal distribution and probably don’t have to pay much attention to this value anymore. It was most interesting after the addition of the difficulty selection menu as the first thing new Cogmind players see ;)

Impacts of Rebalancing

Our next section here will take a look at pieces of data that might be interesting in light of changes to Cogmind’s existing mechanics, of which there were several major ones in Beta 11.

Storage

By far the biggest change was to storage units, removing their stackability to put a hard cap on inventory sizes while redesigning stats around that new reality as well as expanding the number of options. There are a lot of mechanical details and historical discussion/writing surrounding inventory management and various builds which I won’t rehash here, but anyway now that we have the latest data I wanted to compare changes to inventory capacities over time.

cogmind_beta11_stats_inventory_capacity_by_version_beta7-11

Cogmind Avg/Max Inventory Capacity by Version. The chart explicitly shows the Beta 7~8 transition, then skips two releases, because that was a fundamental transition during which the High-capacity Storage Unit was returned to the game after having been removed years before in 2016.

You can clearly see how the new hard cap comes into play, the maximum inventory size being limited to 40 slots, whereas in earlier versions the limit was whatever the player decided to devote their build to in terms of mass and utility slot requirements. Of interest here is that although outliers with massive inventories were clearly removed, the average capacity of a build increased due to the rebalance.

The rebalance included a larger base inventory size, an increase in how much each storage unit could hold, and a couple new storage options at the high end, essentially shrinking the portion of a build dedicated purely to inventory, apparently without having a negative impact on the average inventory size. Great.

Another aspect I was curious about, given that we now have Cogmind’s widest-ever array of storage options, was which types of storage are the most popular, and among what kinds of players. For this data I relied on the “Favorite” item records in the scoresheet, which records the player’s most popular items of each type based on the number of turns they had it attached. Not an ideal reference basis for some use cases, but is simple and does mostly work for our purposes here.

Of course, technically our storage data will leave out a few players because the “Storage” type is shared with resource containers, but those generally spend most if not all of their time in inventory rather than attached, as opposed to storage units which are used continually throughout a run. Nonetheless, 3.9% of runs had a resource container as their favorite storage part. (Note that for these stats I’m only including runs that reached a depth of at least -6, because that gives players ample time to settle into their build and acquire the primary type of storage they want to use.)

4.4% of runs had no favorite storage type at all.

Moving on to our actual data, the winner of the favorite storage contest is… Large Storage Unit!

Cogmind Beta 11: Most popular storage type.

This wonderful middle-ground storage unit has a diverse range of applications, be it for combat builds that don’t need to go quite so heavy on inventory, or fast-movers that want to carry more. About a quarter of runs preferred to use it, and it also happens to be the storage unit used by Haulers, making it relatively accessible

Surely though we’ll see a more telling difference in storage usage if we split runs into those using ground propulsion vs. airborne (hover/flight).

cogmind_beta11_stats_favorite_storage_by_propulsion_category

Cogmind Beta 11: Favorite storage type by propulsion category.

Not surprising that Small or Medium become the most popular if we’re talking about airborne builds, while heavier options are a more likely choice for ground-based builds. It appears that a decent number of airborne builds are still running Large (or even heavier options?!), but in many cases these values are probably not overlapping with the player’s time using an actual airborne build, but instead reflect a change of build at a different time. Cogmind is fluid, after all, with builds changing from time to time, and even transitioning from heavy combat to flight, or vice versa, depending on needs or strategy. So we can’t read too much into the outlying numbers as far as propulsion goes.

We can, however, take another look at the aggregate data, this time checking out what winning builds are going with…

cogmind_beta11_stats_favorite_storage_winning_runs

Cogmind Beta 11: Favorite storage type among winning runs.

Huge has an interesting presence here at the top, especially when you go back and compare its place in the first favorite storage chart. It’s fairly clear that winning runs prefer larger inventories a lot of the time. Not extremely large, have you (we’re not seeing a bunch of Cargo and Humpbacks at the top), but having spare parts, or even whole other builds to transition into when the time is right, is good strategy if you can support it.

Speaking of Humpbacks, look at that Humpback win… They’re suboptimal storage by far (hard to use!), but “Pogmind” fabricated several as soon as possible (early Factory), including spares, and kept using them throughout the mid-game until downsizing their inventory to Huge in -4. The purpose was, I guess unsurprisingly, GUs :). It wasn’t the strategy referred to by the community as “garmy” (I’ll skip the spoilers), but they rather appropriately became a Hauler-Golem and used their extra inventory capacity to keep it going over many maps while still having room to store other gear.

I was also interested in the four wins that utilized Lightpack, by Momo, ktur, leiavoia, and Olga. Momo stole it from the Exiles, but didn’t start using it until the mid-game and then through to the end (an extended win relying on the new Exo build, which we’ll get to later). ktur stole the Lightpack as well (buncha thieves!) and used it as soon as they entered Factory, through to the end of their run in C. Olga borrowed it from the Exiles (so nice!) and used it almost immediately and through the entire run until -2/Research (possibly losing it) on what was a pretty quick run ending in a sprint to the surface. leiavoia also borrowed it (nice!) and used it on arriving in Factory and through the rest of the run to C.

Dominant Classes

Speaking of Hauler-Golems, since build classifications were introduced back in Beta 9, that was one focus of the stats at the time, and I wanted to take a new look at whether there were any significant changes going into Beta 11.

For one, I would expect there to be fewer “Haulers” now, seeing as the redesign de-emphasized stacked inventories by concentrating all storage into a single part and leaving more room for other build-defining parts.

cogmind_beta11_stats_build_classification_modifier_prevalence_vs_beta10

Comparing the most common build modifiers between Betas 9 and 11.

Indeed Haulers were appropriately reduced, although percentage-wise they were essentially converted to yet more “(none),” that is builds with no modifier at all. While it’d be nice to have more modifiers, this is okay since special modifiers are meant to be… special. (Already a couple new ones have been added for Beta 13.)

Another notable change: “Messiah” was bugged before, resulting in a much higher prevalence than intended. Clearly that got fixed :P (there was only one in Beta 11)

The variety of complete build classifications in Beta 11 remained relatively unchanged in Beta 11--75 compared to 76/67 in Betas 10/9, and there we also see Haulers slipping out of the top ten:

cogmind_beta11_stats_primary_class_vs_beta10

Comparing the most popular primary classes between Betas 10 and 11.

The top ten classes among only winning runs shows a somewhat greater number of unique builds:

The most-used primary class throughout winning runs.

Mutants and Scavenger-Mutants are still going to be the most common by far, since that really is what Cogmind tends to be.

Remember these graphs are only showing the class most prevalent throughout an entire run, so don’t really reflect the variety that happens from map to map. I didn’t analyze that particular data, which would take longer to extract, though I do wonder how it compares, even weighting for turn count in each map…

In the end this system is just for fun, and it does at least succeed at that (seeing players commenting on what kinds of builds they create, as defined by the game, is neat :D). While I’d like to define more base classes and modifiers, doing so in an effective manner requires quite a lot more work, including for example building a testing system that could read in player scoresheets for their peak builds and assign class names to allow for aggregate analysis and adjustments based on those results. Such a system would be further complicated by the fact that not quite all the data points factored into class names come from parts alone.

RIF/Bothacking

Another major mechanic to investigate in relation to storage changes is bothacking. Traditionally considered an inventory-heavy strategy by some players, did enforcing an inventory cap affect RIF adoption, or the effectiveness thereof?

Some of the massive inventories seen used by players in pre-Beta 11 builds were indeed put together specifically to carry a huge number of spare Relay Couplers, though the assumption was that by reducing utility allocation towards storage units, more of those couplers could instead be directly attached to provide active benefits and flexibility, as opposed to having more limited options at once.

cogmind_beta11_stats_core_RIF_stats_beta9-11

Some core RIF stats for the last several Cogmind releases.

According to the data, somewhat fewer runs started the RIF journey by using any installer, and there was a greater drop in the number of runs that continued that journey towards maximum RIFness. Technically the latter can also be attributed to players adopting a low-RIF strategy that only wants to use a single installer, combining the benefits with other strategies, so I wouldn’t read much into it. Same with the continued drop in RIF builds that hacked at least 3 robots, which also fell but actually by a smaller percentage.

Comparing the average number of different Relay Coupler types attached at once, as expected that did increase from 2.7 in Beta 10 to 3.0. A handful of players in Beta 11 were often running around with ten or more couplers attached at once! The average total value of couplers attached at once in Beta 11 was 78, also an increase to Beta 10’s 75.

Way back for the Beta 7 stats we looked at the relative popularity of different robot hacks, so while we’re at it let’s see what’s changed since.

cogmind_beta11_stats_most_used_bothacks_vs_beta7

Comparing the most popular bothacks from Betas 7 to 11.

Ignoring raw numbers since there were a lot more Beta 11 runs, we can still see that the top four hacks remain unchanged, and…

purge_threat, while #5 in Beta 11, didn’t even make the top 20 in Beta 7 o_O
overload_power dropped significantly, functionally replaced by the newer amplify_resonance in many situations
find_chute, which?doesn’t even require RIF at all, is definitely growing on people, helping avoid those pesky chutes when you don’t want to get sucked away (or finding one when you do want to)
formatsys_low has gotten lots more popular (more green bot manipulation! smart RIFfers!)

From both the data, and what I’ve seen anecdotally, RIF is alive and well.

Our Top 10 bothackers from Beta 11, ranked by the number of different robots hacked in a single run.

Propulsion!

Propulsion underwent some significant rebalancing, so I’m sure we’re all curious to see if that had a noticeable impact on larger trends. From what I see… I don’t think so? Certainly a portion of strategies and builds were affected, with some older approaches fading from favor and newer ones joining the mix, but in terms of the spread of propulsion types that are being used for the majority of a given run, there hasn’t been any huge paradigm shift.

Comparing primary propulsion type preferences between Betas 10 and 11.

To calculate this I looked only at runs that made it to at least -6, and determined the primary propulsion type of a run to be that which was used to move the most spaces. Crude, but at least somewhat representative :P

Without close examination of individual scoresheets (technically there’s enough supporting info inside…) we can’t easily algorithmically account for players who are forced to switch propulsion types, or temporarily use one type of propulsion when the real goal, and most important parts of that run, instead rely on a different type.

Freely available multislot treads being much less common in the late game could easily have contributed to the drop in that figure, but sometimes it’s also just a case of having more of a certain type of player during a given Beta, especially seeing as a lot of players seem to like sticking to either ground or airborne propulsion for the majority of their runs. They are very different strategies and gameplay styles after all, and preferences differ.

Regardless of whether extracting each run’s most-used propulsion and tallying those, or taking the total spaces moved for each type of prop from all included runs, the end result is about the same: Airborne propulsion is used about a quarter to one-third of the time.

Note that in both calculations, airborne prop is always skewed down a bit from how often it is normally used, since it is not available from the very beginning, and is challenging to main before leaving Materials, so we could get an even more accurate representation by excluding those depths.

But it’s also telling to look at full-length runs that went on to win, which I included in that graph. Flight definitely takes the lead there, being the safest way to earn the simpler win types, and even good at more safely gathering the pieces necessary to put together the best build upon reaching (or nearing) extended game areas for… bigger confrontations.

The least commonly used propulsion is still hover, being harder to build around and maintain, but also arguably the best if you can use it (kind of the expert prop among experts). Wheels are good but don’t have the same longevity as other ground prop, so are used for a smaller set of builds, or for some people primarily in emergencies.

Damage Types

Changes to some common damage types have expectedly had a noticeable impact on usage preferences, for which like propulsion I analyzed by checking runs to at least -6, counting the percentage of those runs that fired more shots from a given weapon type than any other.

cogmind_beta11_stats_damage_type_preferences

Comparing damage type preferences from Betas 8, 10, and 11.

Thermal use shows a sizeable increase after buffing that category in Beta 11, primarily at the expensive of Kinetic weapons, the other of the two most-commonly found (and used) damage types.

Electromagnetic weapons were nerfed going into Beta 10, cutting their usage in half, and again in Beta 11, cutting it in half again :P. While it’s worth noting that strong EM builds can take fewer shots to kill most targets, meaning shot count (or even damage totals) don’t offer a great comparison to other damage types, relative usage from version to version is clearly down. There’s room for that to bounce back up a good bit in a future update surrounding corruption mechanics, but we’ll see if and when that comes to pass… For now I’m good with it where it is, being still pretty effective in combination with the right build and strategies, but no longer an easy approach for any build that wants to just plug it in.

EX damage was added to the graph purely for completion, as one of the common damage types, though being situational it will always remain low compared to the others on a graph like this. But if you think about it, 1.9% in Beta 11 means nearly 1 in 50 runs is someone going ham with explosives and making it to at least -6 like that :P

With regard to the increase in thermal weapon use, we also see a marked increase in robots melted in Beta 11 due to thermal transfer.

Robot melting leaderboards from Betas 10 and 11. You really had to work at it before, but melting robots is now a more common side effect of thermal volleys, not to mention the group of new weapons specifically aimed at increasing melt potential.

Corruption

One of the big changes to EM damage in Beta 11 was of course the potential to corrupt the victim’s salvage, causing some amount of system corruption when attached. This may cause players to shy away from corrupting targets with desirable salvage, or avoid attaching quite as much of that salvage as they would before. Still, sometimes you just have to put on that extra corrupted part to survive, or maybe just don’t care :)

Due to the changes we’d expect the average system corruption to increase in Beta 11, and indeed it did, up from 2.6% to 3.3%. Also note that even if EM weapon use is down overall, targets can still become corrupted in other ways.

The number of actual deaths to system corruption remained unchanged, however--that’ll always be quite rare since other contributing factors tend to kick in long before that :P

cogmind_beta11_stats_corruption_death_leaderboards

System corruption death “leaderboards.” There were five recorded in each of the last Betas, accounting for 0.05% of Beta 11 runs, and 0.04% in Beta 10.

The average number of corrupted parts attached in runs reaching at least -6 was 1.4, so not exactly high, accounting for only 0.6% (~1/200) of all attached parts. I found it amusing that the absolute highest amount of total corruption from attaching corrupted parts was 190 by “deadnoob,” who attached 31 corrupted parts (6.5% of their total), and made it to -1/Access in that run.

That run didn’t even make the top ten when comparing across all Beta 11 runs the highest percentage of attached parts that were corrupted:

cogmind_beta11_stats_highest_percent_corrupted_parts_attached

Beta 11 runs attaching the highest percentage of corrupted parts--up around 10% or more is quite a lot! (incidentally I noticed woegarden on that list, who happens to have recently released an album inspired by Cogmind!)

Following the readjustment of corruption-related utilities for Beta 11, the amount of corruption purged has come down somewhat, most significantly a result of capping the amount of corruption individual utilities can purge. Among runs reaching at least -6, the average amount of corruption purged in Beta 10 was 3.23%, falling to 3.04% in Beta 11. The same trend is reflected in the top corruption-purging runs of each release:

Comparing the top 10 runs by total corruption purged in Betas 10 and 11.

Since the community is split on how much corruption really matters, the types of players playing each version may also impact whether and how often to purge corruption (and you see a lot of different names in the above graph because we did indeed have different players more likely to be playing one or the other), though I’m sure the main reason behind the disparity is that it’s no longer possible to wait in certain areas practically indefinitely with a single utility normally stashed away in one’s inventory to clear corruption. The fact that purging dropped but is still decently high, even with a cap, at least shows that the relevant utilities are common enough to be of help, and getting use.

Next time we’ll have to look at how many people were actually using the new corruption screens. They are better at preventing greater amounts of corruption, and I know some players used them and the data was reported in scoresheets, but the analysis program I was using left them out and I didn’t discover until too late to include them here xD

New Content and Mechanics

How about that new content!

DSFs

Distributed Storage Facilities became places you can actually visit in Beta 11, so how many people have been doing that? 1,056 runs (10.5%) visited at least one DSF. Of those, 138 (13.1%) visited more than one, with Jezoensis setting a record by entering 4 in a single run (the theoretical maximum number that can be visited is five, though the process to enter any more than three is already rather convoluted).

Since the entrances tend to be locked early on, I was curious about how much time players tend to spend in Factory/Research maps prior to entering a DSF: Apparently the average number of turns is 92. Out of 1,210 total DSF visits, half were within 53 turns, and a quarter were within 17 turns.

The absolute longest anyone ever spent on a map before successfully entering a DSF was a whopping 1,538 turns, by yub. They weren’t just sitting around, and they were indeed spotted a little, but it looks like they were jamming at the time, which is the easiest way to keep DSFs accessible for so long--just jam all comers :)

The number of runs that ended in a DSF: 155 (14.7% of those that entered). 42.6% of those died to the sterilization system. Oops. But this was also the first release to include DSFs, so of course it’s a learning period during which you have more people entering for the first time just to see what’s in there, and not necessarily knowing what to expect.

Critical Strikes

Beta 11 significantly expanded Cogmind’s array of critical strike effects, but as they’re more an expected occasional side effect of damage types (which we already covered) and we have nothing to compare to since they’re new, I don’t have much to look at here.

One of the more extreme effects, meltdown, is also on the rarer side for a common damage type, appearing with pretty low base chances on some thermal cannons, so I was curious to see how effective that is for some players and put together a chart for that.

Beta 11 top 10 meltdown critical strike kill counts. Getting several dozen outright meltdowns across a run is a pretty neat reward. I’ve seen screenshots of one-shotting tough Behemoths with builds that do this, which has gotta feel good :)

Overall, crit-focused builds seem as alive as ever in Beta 11:

cogmind_beta11_top_critical_strike_kills

Beta 11 Top 10 critical strike kill counts. Pogmind (nogimagogi from Discord) is clearly a fan of this strategy :P

Traps

Traps have always been an increasingly useful supporting mechanic, and Beta 11 further upped their potential by allowing them to be stored within Trap Extractors, so we’d expect to see a greater emphasis on trap use in Beta 11. The data supports that assumption, showing that on average nearly four times as many traps were extracted in Beta 11 (0.165) compared to Beta 10 (0.046).

2.6% of Beta 11 runs actually found and used a Trap Extractor at all, compared to only 0.7% in Beta 10. Interestingly, the average number of extracted traps was almost identical between the two releases, and the average install count was actually 28% higher back in Beta 10, though this is due to outliers and usage of other non-standard derelict tech.

If we instead compare the top 20 players by total traps extracted, i.e. those people leaning heavily into use of the new Trap Extractor mechanics, we instead see both a 29% version-over-version increase in extraction count, and 43% increase in traps installed among that group.

It’s definitely a become a pretty strong approach in its own right, and anecdotally the advent of extractors holding traps separately has indeed increased the prevalence of new trapping strategies vs. dangerous or high-value targets, rather than using up traps ASAP to free up inventory space.

Fabrication

Beta 11 overhauled the fabrication process, and while some players were worried this would ruin the ability to create builds via those means, I don’t think that’s turned out to be the case. From what I’ve seen so far, everyone basically just needs to learn and grow accustomed to using the new systems. Fabrication-centric strategies are emerging as before.

The numbers are still down, though.

Looking only at runs that reached at least -6 (since there aren’t any Fabricators until reaching Factory), 40.9% built at least one part in Beta 11, versus 54.2% in Beta 10. Players built an average of 1.6 parts in Beta 11 runs vs. 2.5 in Beta 10.

There was a lesser impact on robot fabrication, most likely due to the less specific categorization of robot Authchips combined with the fact that fewer people tend to fabricate allies in the first place. 13.3% of runs to -6 built at least one robot in Beta 11, versus 14.5% in Beta 10. Players built an average of 0.44 robots in Beta 11 runs vs. 0.48* in Beta 10.

1,187 runs (11.8%) carried at least one Authchip, and 60.0% of those runs actually used one to build something, which doesn’t seem too bad. Duckboy carried the most Authchips at once (13!) and used them to build a giant army :D

Comparing the top fabrication runs from Betas 10 and 11, we can see that despite the reduction in parts produced, dedicated players are still making good use of Fabricators with or even without heavy use of Authchips (depends on strategy!).

cogmind_beta11_top_fabrication_runs_vs_beta10

Top fabrication runs in Cogmind Betas 10 and 11, including parts and robots, and showing what percentage of Beta 11 fabrications were completed with help from Authchips.

Fabnet

This section and the remainder of the stats will be covering a few spoilery bits of Cogmind, so feel free to bow out now if you’re not ready to read more about fabnets, SR targets, and the new end-game Exo build.

So we have a new strategy for abusing Fabricators to interfere with Complex 0b10 operation, which doubles as an alternative way of making friends. Obviously I’d like to know just how much it’s been getting used, and it turns out quite a lot!

7.9% of all runs that made it to at least -6 reported using some amount of fabnet (-6 because this feature doesn’t even kick in until then), and 15 runs hit the fabnet cap (15%) at least once.

Beta 11 top 10 fabnet runs. Look at that 72-override win by aperiodic!

Having been just introduced in Beta 11, I’d like to keep an eye on this feature next time to see if it picks up as more people discover it, or falls by the wayside.

SR Targets

Several changes to various artifacts, as well as the addition of some new ones, have occurred since the last replication check in Beta 9, so I’d like to see if there has been any meaningful change in SR targets since then.

Below I’m reposing the old Beta 9 graph alongside the new Beta 11 data. Normally I would be most interested in, and only share, the top uses, but specifically with the replicator, since it’s so unique, it can be fun to see what individuals are doing with it so we can imagine what they were up to at the time (aoemica specifically didn’t need it on one run--the Med. Storage Unit is their work).

cogmind_beta11_replication_results_vs_beta9

Comparing SR results between Betas 9 and 11 (open at full size for easier reading).

This time around we have 53 different SR targets vs. 36 last time, a 47% increase, compared to a lesser 23% increase in the absolute number of replications, so the variety of uses did in fact increase.

One of the biggest catalysts here was the ISR replication nerf to make it create an enhanced version of the original artifact rather than purely duplicating the original, which was very powerful and clearly the primary target of anyone with an SR if they could get their grabby things on both of these items in the same run. The point of that change was indeed to spur more variety, so… success!

The Shearcannon was an entirely new item in Beta 11, and clearly a big hit which absorbs a good chunk of new SR uses, though it was also a bit too common in Beta 11, so I imagine that value will come down a bit in Beta 12 as well.

Seeing a Core Expander on such a list in earlier versions would’ve seemed like a waste, but in Beta 11 it makes sense specifically for the new Exo build! So we know what those folks were up to…

The rest I’ll leave you to mull over :)

Exo

One of Beta 11’s new build options, this one a pretty complete transformation, is the Exoskeleton, specifically that one housed in Section 7. First you’ve got to be able to get there, but once you do, and under the right conditions, it’s a route to new gameplay and content on the back of a mostly OP build. I say mostly because still not quite everyone survives the results of using it :P

Here are some relevant stats I collected:

73.1% of runs that entered and survived Section 7 did not integrate with the Exoskeleton (technically they may not have even had the means, so it’s not always a choice)
0.8% of runs integrated with the Exoskeleton
11.0% of Exo runs did not make it out of Section 7
74.4% of Exo runs went on to win
80.3% of those winning Exo runs were extended wins (67.3 of those earned a ++, 32.7% earned only one +)

Exo runs are definitely easier once you get to that point, especially for experienced players--I got my highest score of Beta 11 in a build based on it without too much difficulty, and aoemica did a lot of extended streaking with it, though using separate patron builds so it doesn’t show up in the data here.

It might see more adjustments in the future to increase the challenge, but for now it’s kind of a backup option providing something else to fool around with if you get to that point and can’t carry out your original plan, or a way for some players who have more trouble with some very hard extended areas to still see them in some capacity (without lowering the difficulty level and having to adjust to the other changes that come with that).

Posted in Meta | Tagged Cogmind, Metrics | Leave a comment

Newsletter

Join the mailing list below for occasional development updates.

Email:
Stay Up to Date
- RSS (posts)
- RSS (comments)
- @GridSageGames
- Mastodon
- Patreon
- Discord
- /r/Cogmind
- Indie DB
Links
- Grid Sage Games
- Announcements
- Forums
- Patreon
- Cogmind
- POLYBOT-7
- REXPaint
Recent Posts
Recent Comments
- Kyzrati on Turn Time SystemsThanks! And yeah it took a few iterations to get to this point, but overall this turn management solution has been pretty robust.
- Sartoris on Turn Time SystemsThank you for the reply, and no worries, I understand. I think your solution is quite elegant, and indeed I assumed something like...
- Kyzrati on Turn Time SystemsHi Sartoris, good question, and the answer essentially depends on your own mechanical/rules preference, like what you think is fai...
- Sartoris on Turn Time SystemsHi, Kyzrati! Thank you for this post! I have one question about the turn queue. To use your own example, let's say the order of...
- Kyzrati on Full UI Upscaling, Part 2: Holy Mockups!Noooo that's not the aim!!! :P I did always want to avoid modal windows, and it should still be optional, but I am really glad...
- y0un65t3r on Full UI Upscaling, Part 2: Holy Mockups!Each modal window brings Cogmind closer to NetHack... and I'm all for it! Even the (i)nventory key is similar to NetHack, soon I c...
Archives
Categories
- Annual Review (10)
- Art (12)
- Cogmind Beta Overhaul (6)
- Design (71)
- Dev Series: 7DRL Postmortem (4)
- Dev Series: Fonts (4)
- Dev Series: Full UI Upscaling (5)
- Dev Series: Map Zooming (5)
- Dev Series: Procedural Maps (7)
- Dev Series: Sound Effects (6)
- Dev Series: Story in Roguelikes (3)
- Dev Series: Ultimate Morgue File (4)
- Game Overview (3)
- Gamedev (14)
- GUI (24)
- Internal (6)
- Marketing (5)
- Mechanics (31)
- Meta (7)
- Post-Mortem (5)
- Release (4)
- Uncategorized (8)
Search
This blog is now for long-form topical articles. For most game updates and other news see the regular forum announcements!

Development Blog