So what’s the big deal with multitile actors?

Limited freedom of movement due to terrain is not something we’d address here–at worst they’ll just have to blast open doorways, take down walls, or even widen shorter corridors if they really want to head in some partially obstructed direction. But another movement issue that absolutely must be addressed is interaction with other robots, because those are everywhere, not to mention moving around most of the time and therefore easy to become repeatedly annoying obstacles.

For this I decided it’d be great to have them just push any blocking robots out of the way. Not like the ramming, crushing, or kicking that normally results from bumping another non-allied robot, mind you, just nudging anyone out of the way, regardless of their affiliation.

This is a pretty sensible and elegant solution, I think, although I admit it was kind of a little recursive nightmare–recursion be like that xD. I had to set up specific tests to be able to reliably repeat and fix issues, and just when I thought it was fixed, filling a room with all manner of other robots and randomly pushing through them in various directions would crash the game again in some new and unexpected way, or push one in an unexpected direction. The weirdest issue I recall was when pushing one blocking robot managed to crush it to death while simultaneously pushing a different robot that wasn’t even on the target path!?

Eventually it always worked, whew 🙂

Pushing blocking robots out of the way while in control of a large host.

On the UI side, multitile Entities naturally also have a fair number of issues that require special handling, so much so that I entirely separated out the code for their player movement input processing, as well as excluded from those options certain actions that would be problematic in more ways that I didn’t have time to address (such as interacting with machines, or ramming with intent to damage or destroy robots and terrain).

Still, they can perform a majority of useful actions, and most importantly they work!

Other helpful tweaks specific to multitile player-controlled actors include showing the full-width path preview/highlight. (As usual the path can be highlighted in a brighter color, but this screenshot is taken with the default appearance when simply moving the cursor across the map view.)

After all of the above architecture and design worries, I was pleased to see Polymind work out in the end. While at the beginning I could imagine a lot of potential issues down the road, I also really wanted to bring Polymind to life, so rather than fret over all of them in advance and try to draw up detailed plans, as soon as I had a general feeling that it might be feasible I simply started, which helped avoid the inevitable temporary paralysis from seeing so many issues without clear solutions.

We’ve barely scratched the surface here and you can already see there were tons of moving parts behind this event (and as you’ll see later quite a lot of code!), but sometimes you have to just say “I’ll figure it out when we get there” and hope for the best :P. At least the initial feasibility study where I examined some of those fundamental questions suggested I wouldn’t hit any serious show stoppers on the way!

Polymind-specific Features
Beyond simply taking control of other robots, sharing their parts and basic stats, conceptually what does that mean, both in terms of gameplay and theme.

Thematically this goes back to players’ original desire to roleplay a Worker, doing Worker things. (And actually even before all that, one player in particular (zxc) always thought it would be fun to be able to temporarily disguise oneself in the regular game purely in order to bypass enemies, though a combination of significant technical hurdles and balance issues kept me from considering it in a more serious capacity.)

This is where suspicion and jobs come in. An idea central to the gameplay here is to remain unsuspicious, and for that to work we clearly need to define a new set of capabilities outside the scope of what’s offered by the game through normal part interactions.

An excerpt from my initial Polymind design notes (itself a 3k-word document xD) on what types of new abilities would be necessary to offer a decent range of actions.

The above list of abilities adds some of the tools necessary to remain unsuspicious. It is not, however, an exhaustive list of ways to modify suspicion (either up or down), since other relevant actions are already covered by existing behaviors, such as combat, or even just Operators working at terminals (hacking!) or Minesweepers collecting traps. But those are very easy to incorporate since they already existed in the code, whereas the notes were focused on the creation of entirely new features which would require separate implementation.

Yet more thematic abilities were listed as possibilities, but would be too complex to tackle in the short term, and for little benefit compared to the importance of core behaviors one expects from the bot classes listed above.

New features also generally require new supporting interface elements, at least concerning QoL to smooth out the experience. For example some of those class abilities require a way to designate valid targets, such as areas for tunnelers to dig.

Tunneler hosts are fairly limited in the areas they can help out, but at least excavating is an extremely effective way of lowering suspicion.

For the Engineer in particular I decided Polymind-specific highlighting was unnecessary, since by default even in the regular game it’s pretty obvious when areas have been destroyed and are in need of repair.

For a few of the more complex hosts, it became necessary to blink other robots in white or pink to imply what action would take place if interacted with given the player’s current host and status. This is because item toggle state, suspicion level, and whether the target is hostile could all impact what action currently applies.

Demonstrating the use of a Mechanic to dismantle a lone Grunt, after which a Recycler steals and recycles its parts, then we put it back together with backup gear. Toggling the Recalibrator highlights valid targets in the color matching what will occur upon bumping them.

The actual meaning of these colors, and class abilities in general, are conveyed through the Polymind info panel for the current host, accessed through the usual special event UI window over the bottom-left corner of the map.

By necessity Programmers are one of the most complex hosts to control since they have multiple capabilities, but there is no Polymind-specific command system so everything must be managed through the standard actions, and reflected on the map so the player knows what will happen.

The info panel includes all of the host’s innate stats, like built-in energy generation and damage modifiers, so playing Polymind and controlling different hosts offers an interesting alternative way for players to gain deeper insight into robot capabilities (and weaknesses!) even in the regular game.

Heavy-class hosts are really powerful. My first Polymind run won by basically spending most of the time in one of these guys obliterating everything, and sometimes doing my job to wait for the right moment to strike 😉

Also on that panel is a list of any intel obtained from controlling a new host of that class. The intel idea was something I added only at the very end, not only because it’s logical, but also for design reasons: Players are trying to make informed decisions as they hop around between bots, and intel helps in that regard while also giving yet another reason for wanting to take over multiple different bots to begin with, depending on the circumstances. So it’s not just about what the bot is capable of, but also what information they’ll reveal when you take control. This info is also often tied to their respective jobs, so this feature brings way too many advantages to leave it out…

Haulers have some okay intel, but were one of the non-combat classes that unfortunately did not get a job as a host. Logically speaking there is material to work with there, since they normally do have tasks to complete, but implementing them would’ve been more complicated.

Fortunately the intel portion was much less work that it otherwise would’ve been, because it drew directly from all the normal robot hacks you can perform on 0b10 bots to get information!

My Polymind design notes specifying intel from various classes, the majority simply correlating to various existing robot hacks.

This Watcher host intel acquisition sequence and effect looks suspiciously like a successful map_route hack! (a good bothack, by the way)

Balance
This mode was designed under a lot of time pressure, meaning not much time left at the end for proper balance work. Much of the balance for Polymind’s first release was based on hypotheticals, though I do think it worked out pretty well for the most part.

Once players got hold of it, and I had an opportunity for real playtesting myself, there were multiple updates within a week of release to make some adjustments, but still nowhere near the attention a mode like this would get if it were to become something even bigger. As a timed special event though, I’m satisfied as long as it meets the goal of being fun for at least a little while.

Aside: Designing these events feels somewhat like a 7DRL–basically you’ve got a new core mechanic around which to quickly design a unique experience, just within the confines of Cogmind’s world. So in that sense even though I rarely participate in 7DRLC (even though I always want to and have lots of ideas for it xD), technically I’ve made a good many “XDRLs” over the years. In fact, on that note the idea for POLYBOT-7 came from what was originally going to be a Cogmind event!

On the topic of fun, the relevant “numbers” mentioned earlier could definitely have used more tweaking, but that level of balance requires a fair amount of data that we just didn’t have yet.

There are many numbers involved, but among the most important, and numerous, is the cost of taking control of each type of host. Of course it can’t be free, so for this I resurrected the idea of Protomatter first introduced for the RPGLIKE event, a matter-like item salvaged from some robots as an alternative mode-specific resource.

Even if I did have time for proper playtesting (I didn’t…), we’d still need some kind of starting point for setting these costs, so I decided to base them on a formula derived from each robot’s core integrity and exposure:

cost=[core_integrity] * (1 + ((0.40-[core_exposure%]) / [core_exposure%]))

This formula uses 40% as an average core exposure and increases or reduces their integrity-based cost by a corresponding percentage when they have a lower or higher value than that. The actual costs are not as important here, it’s more about relative cost, since we can always tweak the Protomatter drop rate and amounts as necessary, but the idea is to assign a higher cost to more powerful robots, and by design power level generally corresponds to core integrity and exposure.

I originally tried a formula based on part rating, since many capabilities are based on parts, after all, but found that to be overall too unreliable as a basis for cost. Basing it on integrity/exposure isn’t perfect, either, but it would have to do!

I also considered but did not factor robot speed into the formula–faster robots do indeed enjoy greater survivability as a result of their speed, but as far as Polymind mechanics go, balance-wise it is not only more likely that faster hosts will lose their capabilities, it is also generally more likely that high-integrity/low-core-exposure hosts will be more capable of acquiring additional Protomatter (through the destruction of other robots) in order to keep taking control of other targets. Fast hosts certainly have their advantages, but generally do not contribute as much to later progress (or score, for that matter).

While building the event I was worried Polymind might be too easy overall, but as it turns out the difficulty ramp is similar to the regular game, growing increasingly challenging all the way to the end. To give that claim some context: Cheaper host-dense early depths make it easier to avoid detection completely if desired, compared to later maps which are much larger, along with the usual increasingly powerful enemies roaming about despite Cogmind having access to fewer tools (generally little to no inventory, and no part swapping, slot expansions, or most consumables). Combat becomes all but unavoidable at some junctions.

Polymind is still very winnable, so that’s good, but while I like the resulting challenge level, it could still stand to be tweaked and expanded for an even smoother, better-balanced experience.

As usual when working on a new feature, while building it I also made a list of areas or potential add-ons that could be important to examine for “optional balance tweaks” later on, depending on how the final gameplay turns out and what players do with it, though for the subsequent updates I did not yet need to revisit that list so much since many of those options were implemented shortly before even the first release once I realized there’d be no time for playtesting and instead continued on the instinct that they’d inevitably be applied anyway. (I had wanted to let patrons try out Polymind in advance and tweak from there, but again there was no time.)

Polymind can especially get weird outside Complex 0b10, in branches, since the mode was mainly designed around non-branch content. But unlike some of the previous events (Abominations, for example) and challenge modes, I didn’t want to prevent the player from visiting branches and interacting with much of the game content, especially when it’s possible to take control of a whole bunch of different hosts out there as well, plus trigger interesting game events. So while all maps were left accessible, we had to simply assume that all the other factions recognize you as Cogmind regardless of your current form, and plot/NPC interactions more or less remain the same. So that’d be another area that could be expanded or addressed in other ways, a topic I’ll get into more at the end.

Players Meet Polymind
Part 2 of this article looks at player stats, strategy, merging code, and more…

Last time in part 1 I covered everything leading up to Cogmind’s Winter 2022/Polymind event, so architecture, UX design, balance, multitile robot considerations etc. Now let’s take a look at the aftermath!

After Polymind was finally released and I could take a breather, I had a lot of fun seeing other players dive into it, reflected both in what’s been shared on the Discord server and also simply by checking out scoresheet uploads since those include new information specific to the event mode.

It’s especially funny seeing Cogmind in the scoresheet’s final map summary represented by a character other than ‘@’, as seen here in an image shared by Captain Croissandwich who is just around the corner from the exit/win after having already opened the door, as a ‘u’ (Builder/Engineer)… kinda surrounded by unfriendly bots that had clearly become too suspicious!

Any time new play styles are introduced, there’s always a good bit of activity in the community since figuring out a new meta in an otherwise familiar world is an interesting exercise for fans. Polymind being a pretty extreme departure from normal Cogmind, there’s a lot to figure out.

My hope was that players would find creative new solutions to challenges, or at least fun aspects to toy with while setting their own unique goals besides simply winning.

Some strategies are obvious, as intended, such as preferring to take control of allies since their cost is always much lower (generally by 66%, though there are exceptions), and others are more indirect, such as obtaining robot schematics and fabricating desirable allies to then control.

The great thing about combat-capable allies is that later releasing control doesn’t result in having an angry hostile right next to you. Combat-capable hosts are useful, even required sometimes because they’re more resilient while also being the primary method of obtaining more Protomatter, but as aptly described by players there is a “riding the tiger” aspect to trying to leave a hostile one behind once you’re in control. You’ll likely want to get their weapons shot off first, or have some other plan.

Players also came up with the interesting strategy of using Repair Stations to remove unwanted parts from your host, since unlike Cogmind, hosts are not capable of reattaching the repaired parts themselves.

NPCs are commonly desired hosts, generally expensive but also relatively powerful compared to most common Complex 0b10 bots. Strategically speaking, the main goal of taking a combat host is to eventually end up with more Protomatter than you spent on it in the first place, so we’re back to the importance of those cost numbers, and no doubt more fine tuning is called for.

On that note one particularly strong strategy is “Tracker chaining,” or intentionally getting what are normally dangerous enemies sent after you, specifically with the intent to take control of them and use them to fight their friends–rinse and repeat as you progress. In a later update I had to significantly up their cost because Trackers are a special robot outside the normal build balancing rules, at least insofar as our integrity and core exposure variables do not reflect what they’re really capable of. Even after the increase they’re still good, though somewhat more balanced.

One of the most interesting discoveries, made by CaptainWinky, takes advantage of a Mechanic host’s repair abilities to build robot friends! Normally Mechanics use a collection of Backup parts from their inventory to restore basic functionality to robots that have lost their power/propulsion/weapons, and I had assumed that when fitting replacements they search for the appropriate Backup-named part, but no… The assumption is that their inventory would never contain anything other than Backup parts, so the code actually just checks for any available inventory parts that match the desired target slot (a faster check). You can see where this is going 😛

A regular controllable grunt with very powerful gear xD (screenshot by CaptainWinky while testing the concept in wizard mode)

Since they’re not limited to Backup-series parts, with a Mechanic host you can gather other parts and “repair” your allies with a different loadout. Totally didn’t expect that, but it’s great.

In practice it’s probably hard to take advantage of since it’s a repair functionality after all, one that can’t be used unless the ally in question has an empty slot after taking damage. Other robots are not usually very resilient, so by then their core will often already be damaged as well, after which even with new parts they’ll probably end up dying quickly anyway. It might come in handy later on with stronger robots, or in specific situations. You also can’t fit any utilities to a robot, since that’s not a category of parts they replace with Backups (although this specific discovery honestly has me thinking about adding something that would slot in as a Backup utility).

Stats!
Now that the event has come to an end, the Polymind leaderboards have reached their final state, and it’s time to review the run data and pick out some stats for closer examination!

Final Polymind leaderboards.

I tacked a couple extra days onto the end of the leaderboard cutoff past when the Polymind autoactivation period ended (through January 7th) so that anyone who had started a run near the end had some time to finish it and still be included. That means the official event ran for about 16 days, though other runs outside that period (and any additional lower-scoring runs for each player) can of course be found in the complete Beta 11.2 run database.

During this period, a total of 786 Cogmind runs were submitted, 328 (41.7%) of which were something other than Polymind. In a majority of cases those other runs were new players who didn’t yet qualify to have the mode start automatically, the remainder being anyone who deactivated it manually (didn’t want to participate) or playing some other special mode (launching any new event tends to bring attention to past events).

The data we’re looking at here is for the 457 Polymind runs (58.1% of the total) submitted by 113 unique players. That’s an average of 4 runs per participant. Polymind run counts per player ranged from 1 to 20, but most people played through at least a few runs. (Reminder: Cogmind run data is opt-in, so we don’t have any info for those who are not submitting scores.)

There were a total of 14 Polymind wins by 10 unique players, including two extended wins (both by aoemica). All winning runs except for one took less than three hours, and most were about 1~2 hours, so as reported Polymind runs do tend to be faster than regular Cogmind (see the Beta 10 stat summary for a graph of Win Count by Hours). The reduced length comes mainly because you have few significant incentives to take detours and collect branch rewards, or even seek out specific items–it’s simply a matter of survival to the end through a process of controlling other bots while gaining enough Protomatter to maintain that momentum.

Total play hours for this data set clocked in at 276 hours, so about twice what I spent on it. Not a great ratio, but then not surprising since I mostly work to serve a smaller number of long-term players at this point, and as I’ll write a bit about later, some of the work could impact the main game itself and gain more longevity that way. Plus of course some people will still play Polymind in the future.

Polymind Classes
One of the more fun bits of Polymind data which I was eager to examine is the class distribution list, since unlike the normal behavior which derives player build types from their current loadout, here we could instead use it to see what classes of bots they’re preferring to control (I had the system switch to simply reporting the current host class).

Among those runs with a Dominant Class of “Cogmind,” meaning their most common state was running around naked with no host at all, the majority were understandably limited to the early game (first few depths). 38% of Cogmind-dominant runs, however, reported making it to the mid- or late-game (none won), with half of those also naked for the majority of the entire run.

Of course most Polyminds spent their time in control of hosts, as expected, averaging 4 different classes of host throughout their run.

The record-holder for greatest number of unique classes controlled in a single run is CaptainWinky, whose list includes 11 different classes (making it onto the list requires spending at least 3% of the run using a given class):

CaptainWinky controlled a Sentry-class robot for 24% of their run, but also controlled hosts of 10 other types.

The number of unique host classes ranged from 3 to 9 among winning runs, so generally above average. Actually, the only winning run with a below-average dominant class count was my own–only three! During that run (being my first) I tried out a number of other classes, but not for a significant enough chunk of relative time to be included in the list.

Class distribution for my Polymind win.

As you can see I’m a fan of Heavies and their devastating firepower and just all around buff part-covered builds (plus they can rest off their suspicion at guard points!).

Despite my high 62% preference for Heavies, among winning runs that one actually ranks behind another for emphasis on a single host: LILY’s dominant class was Programmer, at 67%!

Dominant class for each of Polymind’s winning runs, ranked by how dominant it really was throughout that run.

Here I should mention that I’m not differentiating difficulty modes for the purpose of Polymind data analysis. LILY had the only non-Rogue run among the wins, one of 76 (16.6% of the total).

To give some of the data coming out of these lists proper context, we’ll also have to explain one of the quirks of the class system: While players are certainly familiar with common Grunts, Sentries, and whatnot, some may not be aware that there are other special robots also categorized as those same classes. For example, some runs may show a high percentage of Swarmer hosts, like KTG-v3’s win spent 48% as a Swarmer! Examining the history log from that run we can see they indeed must have controlled common Swarmers for numerous maps before finally switching to the one and only Tracker (a special, more powerful, type of Swarmer) they eventually controlled in Research.

KTG-v3 takes control of a Tracker in Research. Before this, seven of the maps they traversed using common Swarmers.

So the history log provides more color as to what kinds of special hosts each player controlled, as does the event-specific “host kill count leaderboard,” both of which record the specific variant or name of the host. It is there that we can examine hosts of particular interest.

122 (26.7%) Polyminds controlled at least one unique special host, with about half of those controlling more than one. youngster controlled the largest variety of special hosts, eight in all, in a run that eventually went on to win.

By far the most popular special host to control was EX-DEC, an Exile that could be met early and controlled for relatively cheap, considering the formula-based Protomatter costs. EX-DEC is not normally a combat bot, but does carry a decently powerful autonomous weapon that allows them to move and shoot at the same time.

Special hosts ranked by total times controlled across all Polymind runs.

The Tracker is up there, too, being quite cheap for a good while (that formula again…) until I significantly increased it manually in a later update (though still plenty worth it considering how powerful they are). Beasts make sense at #3 as one of the earliest ways to have some fun with a destructive multitile robot. The next two, Strikers and Executioners, along with many others on this list are clearly from Warlord-related events where these combat bots are either cheap (allied) or at least plentiful and effective. Many of the rest are various NPCs, since almost nothing was off limits for control, and NPCs often have decent loadouts.

The full mapwise Dominant Class list that goes along with these can be even more interesting, in order to see which stretches of the world, and for how long, players used them, but that data contains much bigger spoilers so I’ll leave that off here. You can always check out other Polymind stats on your own by examining the raw Beta 11.2 run data to see more (sort by Mode to more easily find all Polymind runs).

(continued in next post…)

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.

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…

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 😀

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.

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 😛

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.

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:

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:

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.

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 😛

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:

• Teleportation Mechanics – coming soon
• Special Events Give Back, and Perfect Stealth – coming soon
• A Simple Approach to Player-designed Robots – coming soon
• Projectile Deflection – coming soon