Development Blog

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 :P

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).

Polymind-specific Scoring

Some bigger Cogmind events come with their own dedicated section in the scoresheet for recording event-specific data, and for Polymind there we’ll find some other entries besides the host kill leaderboard.

A sample Polymind scoresheet’s data section.

Among the Polymind-specific scoresheet data, we have the Top 5 Hosts by Kills per run, where it’s interesting to pick out the most destructive individual hosts among winning runs. Captain Winky led in this category by far, having managed to take control of 8R-AWN, by far the most powerful early target but also very expensive for that depth, hence only being used twice during the event.

Polymind’s ten most deadly hosts (and their controlling player) among winning runs.

The kill records get even higher if we include all runs, even those that did not ascend:

Top 10 individual Polymind hosts by kills, across all runs.

Captain Winky is still up there, in fact the only one on both lists. We can also see the only other 8R-AWN controller ;). And Perseus sure knows how to get the most out of a host!

Here are some more samples of host leaderboards submitted in various scoresheets. Each ranks the best hosts by kill count, and where they were first controlled.

Note that during the first couple days of the event there were some issues with the host kill leaderboard system (fixed in one of the several patches), so technically a portion of the earlier runs may have failed to consider a few hosts for inclusion.

With a further fleshing out of the job system, it could also be interesting to tally a corresponding “unsuspicious leaderboard” ranking individual hosts by how much they contributed to lowering suspicion over their lifetime. This would allow us to see what kinds of hosts were being used for that purpose, and their relative effectiveness.

Classes Controlled tallies would be fun to examine over the long term if players were to continue doing many Polymind runs, but as an event there are only so many runs per player. This means the likelihood of optimal play is fairly low, as everyone is still experimenting with possibilities and learning what they can do with different hosts, making that stat less meaningful for aggregate analysis right now.

Robots Controlled data might hold some insights, especially looking at the percentage of new hosts at each depth which are combat-capable, although pulling those numbers from our data set in a meaningful way would be pretty challenging so I didn’t go that far…

Average host suspicion among winning runs was 64.2, lower than I expected! And among non-winning runs the average was 60.7, so not a significant difference. Some of the more interesting runs in this regard:

• Thermalderp averaged only 26 suspicion, surviving 90% of the run as a Recycler and making it all the way to a -6 Garrison before being destroyed by a Grunt
• Perseus spent 78% of one run as a Programmer and made it all the way to -1 with an average 32 suspicion
• LILY and lyrabold tied for the lowest suspicion (40) among winning runs, the former also surviving 67% of the run as a Programmer, and lyrabold 58% Sentry.

Bonus Points

Outside the Polymind section, we also have a special bonus point entry simply called “Polymind Skill.” This value is a combination of multiple factors to reward players for being good polyminds, generally awarding points for behavior and achievements that are not normally sources of bonus points (or don’t even exist in the regular game).

At the high end Polymind Skill tended to contribute about 10-20k points to one’s final score, so often counts for a fairly significant chunk of that.

Top 20 Polymind leaderboard scores, along with the percentage of that score accounted for purely by the Polymind Skill bonus.

To compare, I also reranked the leaderboards by Polymind Skill to see what would come out of that:

Polymind leaderboards ranked by Polymind Skill (final Top 20 only).

Only a couple players swapped in/out of the Top 20 when switching metrics, so the effect was not significant in that regard, although it did enable a few players in the Top 20 to jump quite a few places.

I was thinking it might be fun to rank the final Polymind leaderboards using this method, but I would first want to further tweak the values and formulas used to generate the bonus, since all that was set based on theory, before Polymind had ever been played.

Perseus earned the highest Polymind Skill of any run (23176, 32% of their total score), and Captain Winky earned the highest among all wins (17933, 41% of total score).

aoemica had the only extended game wins, and while both of those runs had by far the lowest Polymind Skill as a percentage of score (both only 18%), that’s a more likely result as branches and extended game areas offer lots of alternative point sources to tip the balance in favor of non-Polymind scoring. As far as true play style goes, we could get more accurate readings by looking only at main maps, for example.

One of the preexisting bonus score components pairs especially well with Polymind: pacifism. Polymind’s capabilities of course lend itself to aiming for even more points (and survivability!) via the Pacifist bonus (the way it normally works is that you receive extra points for each new depth reached without having destroyed any robot on any previous floor, generally achieved by either avoiding enemies completely, running from them, or using alternative means of dispatching them). Polymind can fairly easily remain unsuspicious in the early floors, which are dense with cheaply controlled non-combat bots, and the data strongly reflects that: 44.4% of Polymind runs had at least some Pacifist bonus, quite high compared to a mere 4.5% in the regular game!

Looking at runs with the highest Pacifist bonus, we see a bunch of new names:

Top 5 Polymind runs by Pacifist bonus.

These players were particularly interested in remaining undetected, only sometimes controlling a combat bot such as a Sentry or Hunter to gather Protomatter for more sneaking around (eventually losing their pacifist streak at that point unless they had acquired Protomatter through other means). Above I only listed the primary class for their run, though they tended to control a good variety of classes across their run, at least 5~6 different types.

lcbb_tuk in particular had an interesting one, sticking with the same Watcher picked up in -10/Materials for the entire run. They were apparently attempting to speed run it with that Watcher, a decent choice due to their speed, evasion, and sensors, all in a single package, but eventually headed into the Upper Caves where they were chased down by a P-70 Sage.

Future of Polymind

Like most Cogmind events, Polymind will remain accessible in future versions of the game. (A list of all currently available modes, each with a summary and date when they were held, is avaiable in the manual.)

Seeing as I had already done quite a lot of work on Cogmind’s next version (Beta 12), and that version wasn’t yet itself ready for release, Polymind was developed as part of the public Beta 11.1 branch, and released as 11.2. (Patrons found it funny that when starting up their Beta 12 builds the date-based version notification system informed them that a “newer” version was available, even though Beta 12 has a lot more new stuff :P)

As a pretty big project, one that even included a few features we want back in the regular game as well (that new force melee toggle!), there’s a lot to import into the upcoming Beta 12. I normally don’t bother simultaneously working with multiple branches like this, but here it made sense.

Out of curiosity I checked just how much the code base expanded with the addition of Polymind and was surprised to see it clocked in at nearly 5k lines! Lines of code is of course a pretty bad metric, but it’s easy to calculate and fun to compare nonetheless, as long as the context and limitations are understood. Naturally we want to see how Polymind weighs up against Cogmind’s other special event versions :)

Lines of code added for each of Cogmind’s special event versions over the years (2017~2022).

Yep, as expected Polymind is a chonky one. Also, fond memories of building an entire event in one hour--Launchers mode, Cogmind’s first ever April Fools Day event, which was unannounced and really caught people by surprise ;) (it was made and released on a whim that very morning). Note that some of these larger builds were accompanied by unrelated changes or fixes that could impact the LoC count, but the vast majority (if not all) of each was about the main event. Also note that some events added data as well, but I only compared source code for the purposes of this graph (it’s likely a similar ratio, except with Holiday Mode 2017 which was a data-heavy mode and that’s also part of the reason it was only playable in that version of Cogmind--I didn’t want to keep all that data polluting the later versions).

Anyway, time for Beta 12 Polymind. I’ve merged code before, but not anywhere near on this scale, so I searched up a new tool to help facilitate the process and found the lovely Meld. It’s very easy to use, can be navigated pretty much entirely by keyboard for fast merging, and supports three-way comparisons of directories and the contents of their files.

Meld comparison of files between Beta 11.1, 11.2, and 12.

This is perfect for my case since I can load up the original 11.1 alongside 11.2 and 12 while moving all the new parts of 11.2 into 12, most of which are detected just fine.

Meld source code comparison between Beta 11.1, 11.2, and 12.

There were just a few cases where I had to look a little closer due to some changes while writing Polymind that affected the overall logical organization rather than simple modification to lines of code.

A relatively rare sighting during this process: red denoting an obvious conflict.

Of course this was also helpful for merging all the other supporting materials as well, so not just source code but also media files (SFX!) and external data/scripts.

Sample data comparison between log message definitions.

After completing the merge, I went and tested it out by streaming a round of Polymind in the IDE. It was meant to be a short one, followed by switching over to regular Cogmind to ensure that’s working properly as well, but I ended up having too much fun (and also playing well enough despite fooling around) to get really close to another Polymind win :P

Since it was basically a test run for dev purposes, there’s some dev talk in there, too.

Among my notes for Polymind, as I built it I was also recording features that would be nice if it were revisited one day for a significant update.

Probably highest priority among them would be making it so that almost any 0b10 robot has more relevant jobs it can do, especially combat bots. Derelict incursions! Calling for help from Garrisons! Basically things that would’ve required a lot more unique content and balancing to actually produce, and therefore beyond the scope of this event. At least there’s the low-hanging fruit of guard-type robots being able to remain at designated guard spots to lower suspicion, but even that system could be expanded.

Examples of other ideas:

• proper faction responses to various host types outside 0b10
• more machine interactions for 0b10 classes
• add derelict reactions to having been a host
• rework the “hidden faction” issue, since that doesn’t matter in Cogmind but clearly affects behavior in Polymind

I was thinking, and others were even later commenting, that Polymind could really be developed into a whole different game, leveraging the world of Cogmind and layering over it an alternative story and gameplay goals. Of course making another game is on a whole different level in terms of work :P

There are already other possession-focused roguelikes, a surprising number, actually, including also several 7DRLs, commercial projects, as well as multiple games in which it’s not the central mechanic but does at least exist as an ability.

In any case, some of the smaller bits from my notes that never made it into the Polymind event will likely find their way into a future release of Cogmind anyway, like I sometimes do for other major alternative modes when people are still playing them. There are still a couple fixes to come, but I didn’t want to do yet more releases during the event period, since there had already been several…

And even if Polymind is never revisited in a major way, experimenting with events like this, and the features required to get them playable, sometimes has a way of filtering back into the regular game in some form or another.

Like I discovered and experimented with what it’s like if the player has a way to temporarily be “friendly” with 0b10 (without actually changing faction alignment), harking back to that zxc idea about disguises mentioned earlier. Maybe we have a reasonable framework for that now?

Multitile Entity pushing is another feature that could offer a potential route for solving movement issues with very large bots (so long as it’ll agree with the AI--there is a distinct difference between allowing the player to do something and getting the AI to use it properly).

That backup utility for Mechanic repairs is definitely on my radar now, too…

???

At the end of 2022 I launched Cogmind’s most involved special event yet: Polymind (not to be confused with my earlier unrelated 7DRL, POLYBOT-7!). The release announcement already covers the basics, so I’ll assume you’re familiar with those already and avoid rehashing most of that here. Instead let’s talk development! Now that the event is over, towards the end we’ll also be taking a look at player stats from Polymind, which also had its own leaderboard for the duration.

Polymind cover image. The word layout was actually created in REXPaint, which was faster than trying to use Photoshop since it was easy to drop in Cogmind tiles and manipulate those on a grid.

In terms of dev investment, Polymind is Cogmind’s most involved alternate mode yet, requiring well over a hundred high-paced hours of mostly coding work to realize. Unlike most prior events which tended to be concentrated in just a few areas of the code, this one is all over the place. It modifies the AI, player input, alert mechanics, part interaction… all sorts of stuff, while also adding many of its own new mechanics, too.

In short, Polymind enables the player to take direct control of almost any other robot, basically “possession” mechanics as found in many other games. For years players have jokingly imagined roleplaying as a Worker or some other lowly non-combat robot frequently seen roaming the complex. In Polymind it’s not only possible, but doing so can even aid in your survival :)

In a complete departure from Cogmind’s normal core mechanic, the player is unable to attach any parts, or even evolve more slots, but is instead entirely dependent on hosts for protection, or avoiding detection completely by melding into Complex 0b10. While undetected, you can move around as if you belong, trying to keep your suspicion down, or eventually need to figure out a way out of trouble when things start going south. Fighting is always an option, too, but can be a dangerous one in the long term without access to Cogmind’s normally superior capabilities.

Is this Even Possible?

There were a lot of questions when initially considering whether to implement this mode, since more often than not a common but high-level comment like “[feature X] would be pretty cool…” is so much easier to say than actually build :P

So the very first thing I had to do after selecting Polymind from my list of potential event ideas was to do a feasibility study looking at the potential roadblocks with respect to Cogmind’s fundamental architecture and design.

Architecture

A good many roguelikes are coded such that the player and non-player “actors” (creatures/mobs/entities/whateveryoucallthem) are based on the exact same systems and data structures. This is really helpful for balancing the game, simplifying player understanding of mechanics and interactions, and of course simply building the game where you can have a ton of interactive systems but don’t have to always treat the player as some separate special case.

In this sense, roguelikes probably lend themselves well to possession mechanics, inherently being easier to swap in some other actor for the player to control without worrying about too many unexpected side effects. While Cogmind does have a few player-specific exceptions with regard to certain mechanics where necessary for balance reasons (usually being a little more lenient on the player), for the most part it follows this roguelike design tenet: The player is just another Entity composed of a handful of base stats and operating as a collection of items that confer the majority of their additional capabilities.

That doesn’t mean Polymind was completely smooth sailing on the architecture front, just… close to it :P

As I wrote about in Item Variants and Randomization in Roguelikes, data for Cogmind objects such as items (and Entities!) is mostly held in static databases loaded on startup, essentially a large number of game-defining values which are assumed to remain unchanged while Cogmind is running. I already had to address this roadblock in order to implement Constructs with variable stats for the upcoming Scrap Engine mechanics, so I was able to draw from that experience and code when working with Polymind. Directly editing the underlying data seems easy enough, and makes sense, but could have unintended side effects since it wasn’t built with that in mind, not to mention requires separate attention to actually loading and saving the relevant unique data changes for runs in progress, data which exists outside the normal serialization process. Anyway, as with Constructs it works but it’s a bit crude, as one might expect when venturing outside the bounds of what a system was designed to do in the first place…

Polymind also benefited from RPGLIKE, another earlier special mode, for which I had already added indirect access to a number of Cogmind stats that might be modified through abnormal/non-part means as a simpler alternative to editing underlying data which I had always wanted to avoid before. For example, instead of editing Cogmind’s base sight range in the database, leveling up that stat in RPGLIKE would edit a separate value, and retrieving sight range for an Entity first checks whether it’s the player, in which case it will draw from the separate value, or instead from the database for any other Entity. This offers another avenue for changing that value (and a few others) where applicable, if I don’t want to worry about saving and loading things directly to and from a supposedly static database…

So while this mode was already a lot of work, it would’ve been even more time-consuming if not for the fact that it could be built on the foundation of several big projects that came before.

In the end it’s not an ideal solution for the architecture side of things, but it works, and I’m open to cooking up a bit of spaghetti when it comes to putting together special events since they’re short-term projects isolated in the code anyway.

The “possession” process itself is interesting in that it actually destroys the host and transfers their stats to Cogmind, while separately storing as much of the original information necessary to recreate the host if and when the player releases control at a later point.

The code used to take control of a host, transferring its stats to Cogmind, along with the reverse process for restoring Cogmind’s default stats upon releasing control.

Data stored about a new host before destroying it. Not very much is required for recreation, since the majority of a robot’s values are either static or properties of their constituent parts, all of which are simply returned/reattached to the host later (any that still exist at the time, that is). hostID, killCount and routeIndex are actually not even necessary for the process--those are recorded purely for scoresheet generation purposes, since it wants to create a leaderboard of the hosts with top kill counts, and where they were originally found.

Due to how this latter system operates, storing the host’s original faction to restore it later, one side effect allowed players to discover a facet of Cogmind’s internal design which wasn’t previously known (and is confusing unless I explain it :P).

As players see it, Cogmind robots don’t actually indicate their specific faction, instead simply showing whether they are friendly, neutral, or hostile to the player, so sometimes in a few special case branch maps, as far as the data goes NPCs might technically belong to a “faction” that doesn’t behave as one might expect in another map. What this means is that specifically in Polymind, controlling such an NPC and releasing them in one of these other maps might cause them to be friendly to robots one would think are their enemies!

I did this early on in Cogmind development since it wouldn’t have any noticeable impact on the game, reusing “factions” on different maps for different purposes in order to keep the total number of required factions as low as possible. This is one of many things that could be addressed in the long term if more work was put into this event, but the focus was on gameplay in the main complex (more on that decision later), and the potentially unexpected faction behavior actually only comes into play in very few situations anyway.

Honestly I recall considering a more dynamic faction system for pre-alpha Cogmind, since at the time I was close to building one for X@COM, Cogmind’s predecessor and the source of its initial code, and although I later did do that for X@COM, I didn’t really see a strong need for it in Cogmind compared to the overhead it would add, so decided to forgo it. I’ve since started adding a few extra faction slots to Cogmind for different purposes, but it’s still not a dynamic system which would be even more flexible.

Design

On the design side my primary concern was interface complications, since all necessary interactions must be fully mouse and keyboard compatible, where a deficiency on one side or the other will as usual serve to limit and guide the mechanics. While in some cases mouse input in particular did require special attention, I was happy to discover that pretty much all of my goals there were achievable.

One new UI feature required on several different levels in order for Polymind to even be feasible is a toggleable force melee mode. Normally a “force melee” type interaction is enabled by holding a modifier key, though technically due to command conflicts has never been possible when combining force melee and diagonal movements using vi key directional input, for example. Alternative input options exist for such an occasion (not incredibly common), but for quite a while I have always planned to address the issue more directly with an optional universal toggle, so this was the perfect opportunity to finally make it a reality.

Force Melee on the Special Commands menu, toggleable via Spacebar then mouse click, or from the main interface with Spacebar-e or Shift-Alt-e.

(I’ll write about more mode-specific interface features later.)

Mechanically speaking, one of the big potential roadblocks was how to let the player remain friendly with all those bots out there that otherwise attack on sight. It’s not as simple as changing faction relation settings, which would introduce its own set of bigger problems. Instead I found a simpler solution to circumvent faction considerations and treat the player differently depending on their current host and status: just don’t let hostiles add the player as an enemy if they don’t currently see them as one.

Each AI normally stores its own list of enemies that it remembers for however long, a duration set initially by the AI’s robot type and can be shortened by system corruption or ECM effects. Polymind-Cogmind is blocked from being added to “hostile” AI memory if using a host friendly to the AI (based on that host data we stored earlier!) and not currently suspicious.

Technically under this system, if the player manages to break line of sight with hostile pursuers and significantly lower their suspicion level, perhaps in combination with switching to a new host (which itself lowers suspicion), they can once again be removed from pursuers’ memory and operate in safety, though the pursuers will likely investigate the local area and potentially discover the player again if suspicion again reaches the maximum level.

Technical design issues resolved, the other early requirement was to convince myself that the mode would actually be fun.

This aspect can be harder to nail down in gamedev, but at an early stage there’s really no need to get into the nitty gritty details--I just needed to focus on the bigger picture: Will this create challenges that the player can overcome by making interesting decisions using the resources and capabilities they have available at the time? What will the player be thinking from moment to moment during the various scenarios I can envision under the type of gameplay this will lead to? What can I do or add to help facilitate that interesting gameplay?

This line of thinking leads into some Polymind-specific features like the free intel system on controlling a new host. And of course first and foremost this is also where the suspicion system and corresponding jobs system come into play. I saw enough flexibility in those that players could find a fun balancing act to carry out in there, oscillating between suspicious and unsuspicious as necessary throughout their run to achieve their goals amidst evolving circumstances. Assuming the numbers are set right, that is, but balancing is for later when the features are actually implemented. The important part is to know that it’s theoretically a good track to be on before investing the required dev time.

Multitile Robots

This was huge (haha). Multitile robots are cool. They also tend to be a nightmare to work with. I wrote a lot about them in Developing Multitile Creatures in Roguelikes, but letting the player control one is a different and even more complex matter!

Multitile bots felt like they were close to derailing the project in its latest stages, since I had repeatedly pushed them further and further down the TODO list until they were just about at the end, then by the time I got to working on them and we were past my initial deadline for completion, all the related bugs sure took a long time to weed out (Polymind was definitely completed later than I wanted).

At one point it felt like they might need to be cut--essentially no controlling multitile hosts allowed, but I really felt like we had to have them in there if at all possible! They’re just too cool, and an important goal of this mode was to attempt to allow the player to control almost anybot. Even if only a few players ever ended up doing it, it needed to be a thing (cue late-hour coding sessions xD).

My first experience with this was back in 2019, when players were postulating what it’d be like if Cogmind could occupy multiple spaces as 2×2 bots do, so at the time as a joke test I simply changed the one variable determining Cogmind’s Entity size and surprisingly it actually more or less worked. Now that’s a far cry from what it takes to have proper full control of a large robot, but at least it showed me that such a change doesn’t immediately break the game!

A recording from 2019 showing the quick and dirty version of a 2×2 Cogmind. Of course, Cogmind doesn’t have a tile large enough for it to occupy multiple cells like true large Entities, so instead the game automatically renders other adjacent tiles found in the tileset positions where such image data would normally be stored :P

A quick and dirty sketch by Zyalin to go with our innovative multitile Cogmind design that seems to be melding with various other robots…

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…