next »

[Kyzrati]

(...continued from previous post)

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:

Code:

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

[JobLeonard]

So what's the big deal with multitile actors?

[Gunroar:Cannon()]

wow, this game still in the works. I love it. Always followed your posts on roguelike dev on reddit

What are he chances of an android port ala brogue or nethack. Something for tablets? I always love playing on them.

Anyway, real good ASCII art, real good concept. Nice

[Kyzrati]

Ah hey Gunroar, yeah.... still in the works

Roguelike ports... just don't work xD

None of them are good, well okay I'm thinking of phones when I say that, where they really don't work, whereas on tablets some are at least serviceable, but still, not the greatest experience? Better to have something designed for that sort of platform from the ground up.

While personally I don't have any plans for it, I do know that people have played Cogmind on various tablets, and some play on the Steam Deck as well. Personally I wouldn't want to force that on someone, but some fans are gonna do what they want xD

[Gunroar:Cannon()]

. Personally I wouldn't want to force that on someone, but some fans are gonna do what they want xD

Peeps gonna do what they need to do to play a good game on the go. I even remember playing CDDA on mobile (not even a tablet this time )
The brogue port (again...heheh...on a tablet) is really good IMO. Like. really. (Brogue does have kinda limited keys and plays through a mouse mostly so...)...

Yeah. Good work. Hopefully people will do what they do and I'll see "Cogmind apk" one day 

Edit: in fact the whole reason I even say this is because I kind of got bored with brogue (after maybe +100hrs ) and now I'm looking for another well designed deep game to replace it (on the tablet). Tried DCSS, and thought of CDDA, but they have a lot of stuff to barely consider them ... designed. For having games. I tried Star Traders frontiers cause I heard things but ... Maybe Hopefully DCSS will click or Shattered Pixel Dungeon

[Kyzrati]

Cogmind "Encrypted Comms" is ready--welcome to Beta 12! Embrace the new Scrap Engine to create unique parts by feeding it other items, and explore significantly expanded Garrisons with major new rewards.

Full release notes and demo images.

[Kyzrati]

Special Mode Design, Polymind Part 2: Players, Stats, and the Future
[Cross-posted from the devblog here--follow link for better formatting and light-on-dark style.]

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

(continued in next post...)

[Kyzrati]

(...continued from previous post)

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

???

[JobLeonard]

Wow, sounds like the new gameplay mode is a huge success! Also in terms of learning new things about how to play your own game

[Kyzrati]

Pretty successful, yeah, at least in technical terms, and being an enjoyable romp for those who did play. Curious to see if/how much it's played in the future, though I imagine not a whole lot, just occasionally by a small number of people who want to fool around with something different.

In any case, it was a good excuse to experiment and work on something different, kinda like the currently ongoing 7dRL but without having to do a bunch of foundational work

[Kyzrati]

Lots of updates and new features for last year's Beta 11, so now that we've moved on to Beta 12 I've gone and done a big player stats post on the main dev blog to analyze the data to see how things are going

[Kyzrati]

Roguelike-Discord Integration Using Webhooks
[Cross-posted from the devblog here--follow link for better formatting and light-on-dark style.]

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

The good old GSG forums!

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

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

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

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

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


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

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

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

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

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

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


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

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

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

But integrating with Discord never appealed to me.

Then I learned more about webhooks and had an idea.


Webhooks!
It turns out you can technically do a form of Discord integration without their SDK, using these "webhook" thingies...

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

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

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

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

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

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

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

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


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

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

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

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

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

As for the meat of the feature, what we're posting...


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

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

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

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

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

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

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


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

Achievements appear bracketed and in italics.

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

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

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

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

Another history logging sample from #cogmind-activity.

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

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

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

(continued in following post...)

[Kyzrati]

(...continued from previous 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 :D

[Kyzrati]

SITREP Saturday #51: "Another Big Bang"



The world is expanding, again! Beta 13 is adding more maps, and that means... more lore, NPCS, and lots (LOTS) more tech. Nearly 100 new items are coming, together with multiple new bots, new AI behaviors, dozens of new encounters... all the sorts of things one needs to keep new maps interesting and replayable.

I'm glad at the decision to have released Beta 12 as a standalone when it happened (Scrap Engine, Garrisons, ECA, etc). Even though some of it was technically not yet fully integrated into the lore, it would otherwise have been quite a long wait for all this stuff without much in between to keep it fresh, except perhaps the possibility of special events, but I'm avoiding such detours for now in order to be able to focus on this sizeable expansion, Cogmind's largest to date.

Consider it a major post-1.0 expansion (with its own complete arc), just without the 1.0 part ;)

Today I'm here to share with you a little mid-cycle update to give you an idea of what's up. I've streamed the first major prerelease version of Beta 13, but other patrons have been doing that much more frequently in recent months, over on the Roguelikes/Cogmind Discord server. (Other than making an exception that one time, due to health reasons I've not been able to keep streaming for a while now, but I'll get back to it eventually.) Anyone interested in the latest news can find me hanging out with the Cogmind community every day over there, and I also post some updates on Patreon regarding upcoming features, but checking out other streams or player reports is another good way to see how new features are taking shape.

Subcaves

The first new map has been mostly completed, found right at the first depth and essentially offering an alternative start that skips some early floors, but can also be quite dangerous.

It was when I put out that prerelease that I did a one-off stream to fool around there and see how it plays:





To avoid spoiling the explorers among you I won't be detailing what you'll find within, but for those interested in more information, the video above visits a couple times as an introduction, naturally along with commentary.

I will say it's a fairly large map, and rather different from other caves in a number of ways, most importantly featuring several new types of inhabitants.

A debug shot showing encounter classifications as distributed across a particular procedurally generated Subcaves map (connections between encounter areas not visible):



Combat Log 1.5

As a common request by patrons during past feature voting, Beta 13 includes a revamped combat log. I was considering writing a blog article about it, but never got around to doing that beyond what was posted to Patreon, so since I can't point you to the blog, I guess I should at least run down a summary of main points here.

The combat log update is a decent one, but I wouldn't call it a 2.0 because this isn't a major overhaul, per se. The format is essentially the same as before, just lots more info is being added, alongside an important new functionality. I admit the results are growing on me, despite not being a "combat log user" myself, but no, this will not get me to start taking it seriously as part of my own play :P. The main goal is still to not require use of the combat log, just maintain it purely as a tool for those who want to more deeply analyze some specific encounter or setup, or just really like poring over ever more log data.

For quite a while I wavered back and forth between expanding the existing combat log content or completely rewriting the architecture from scratch to possibly support new features, even starting some work on the latter idea which showed promise since it would theoretically result in something easier to debug and modify, not to mention allow some even more special functionality, but I noticed it would encounter some of its own unique roadblocks so gave up on that approach and decided to just deck out the existing combat log with most of the relevant data people would like to see there. It's looking nice.

The combat log still supports the original five different detail levels, though this update is mostly for players who prefer the "Full" detail setting, so I'll be focusing on that here.

Of course, with all that extra potential information to display, we're ideally going to have a new way to view it, more than the mere 6 lines of log space we normally have (a limitation that made me less eager to greatly expand it in the first place). What I did to facilitate searching back through longer sections of intense combat is have the main/normal combat log itself serves as a scrollbar for an expanded view that appears when and only when the combat log is manually scrolled back.



You'll still have access to the expanded and configurable automatic on-map version of the combat log, as the action is playing out, though this new feature is more for further exploration of details after the fact, which is clearly what you're after if you're scrolling back through the log anyway. Scrolling to the bottom of the combat log, or performing any other action, automatically hides that view again so you can get back to playing.

(By the way, I also renamed that top-center multiconsole mode from "CALC" to "COMBAT," to reflect the fact that it really is a combat log these days--it's original purpose, when added by request, was simply to allow players to see all the factors included in hit calculations! A bit of Cogmind dev history there from, oh, a decade ago...)

As for the contents of the combat log, when set to Full it should be a good bit easier to follow the entire flow of a battle as you know it, details and all. I won't claim that it's perfect, an unrealistic goal in part because you don't always have perfect information anyway, and how to display such situations in an understandable manner gets incredibly complex.

Here's a sample expanded combat log pointing out some of the new data:



First of all you'll probably notice that separate turns are easier to differentiate due to how only new turns are marked with a number (though I did not extend this feature to other logs or standard combat log presentation, just this one).

Drilling down into the details, the rest should be pretty self-explanatory. All critical effects are now indicated where applicable, as are disruption, penetration, heat-triggered meltdowns, and more.

Melee combat is also more detailed, explicitly indicating sneak attacks and follow-ups.



Also terrain destruction!

As you can see, for combat purposes there is much less need to mentally merge the regular log and combat log to get a clear picture of what happened during an encounter. The combat log was originally designed purely as a supplement, providing additional information not present in the main message log to avoid doubling up between the two and thereby keeping the combat log short, but now that there are ways to see more of it at once, pretty much the entire process can be followed in the combat log when desired. In the interest of keeping the main log self-sufficient for those who don't want to bother with a combat log, there is indeed now duplicate messaging in some cases (although sometimes appearing in a different form).

The updated combat log also actually does multiprojectile weapons properly, and in a nice format, giving you a tally of the portion of shots that hit followed by what is hit:



In the past multiprojectile weapons were not even compatible with the combat log at all, with additional projectiles past the first just appearing scattered in between later messages, since it wasn't originally built to support them.

Another new addition to the combat log: programmer hacking.



Overall Beta 13 has a lot of nice QoL updates, the combat log just being one of the more expansive projects in that category.

New Tech

There are so many new toys in Beta 13, toys that enable whole new types of builds, or support existing ones.

As usual I'll be leaving the details to your discovery, but sharing the art for some of them couldn't hurt ;)



71 new items have already been added, with plenty more on the way. Of course the majority of these exist because new enemies and friends alike need them to operate, meaning you'll be finding new bots to salvage for material, perhaps whether they want you to or not :P

For example the new Multitool that Artisans use to build and reconfigure their creations, in your hands can also be used to repair damaged machines and restore them to functionality, among other capabilities:



On that note, a handful of item abilities are a bit more extensive and need more space for a complete description, so that's handled by the QoL department which has inserted a convenient new button to access it if necessary:



After Beta 11 did a good job of finalizing the core parts, I've again taken to using the helpful spreadsheets put together during that period to continue balancing in the same vein, like with this propulsion data I was using to add several new types:



Scraptown

I'm currently working on a major new faction, one mostly concentrated in a new map of their own, but with the potential for significant reverberations throughout the world. The United Federation of Derelicts might like to meet you. Or not, depending on what kind of Cogmind you are :)

Depending on how long Scraptown and all the other related features take, there's a good chance I may end up deciding to release this expansion before its full story arc is complete, since it will require a third new map (a new Research branch) and that would of course extend the production time. We'll see just long it takes.

That's all content to come, though. In the here and now, note that the leaderboards now more explicitly indicate the location of each win (as originally reflected in the scoresheet) instead of showing all wins as simply "Ascended."



Beta 11 Stats

It's been a while since they came out, but there were no other announcements in which to mention them since, so some of you might not be aware that earlier this year after Beta 12 released I did the normal survey of select stats from the previous version, Beta 11. As usual there are tons of charts, graphs, and data to pore over, things that were relevant to look at after that transition. It was a particularly interesting one considering the rebalancing that occurred in that release.



Thanks for all your support! It's been great to hang out with all the wonderful folks in the community, really keeps me going and looking forward to introducing the UFD in all their derelict glory :D

[Kyzrati]

"Post-Balance" Cogmind Item Expansion
[Cross-posted from the devblog here--follow link for better formatting and light-on-dark style.]

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

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

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


Balancing Levers
The idea of "post-balance" from this article's title doesn't mean no balance.

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

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

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

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

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

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

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

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

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

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

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

• 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

[mecholdem]

it's something cool 

[Kyzrati]

Teleportation Mechanics
[Cross-posted from the devblog here--follow link for better formatting and light-on-dark style.]

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

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

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

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

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


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

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

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

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

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

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

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

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


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

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

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


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

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

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

 

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

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

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

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

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


Personal Teleporter v0.10
You may have spotted this little thing among all the art I shared for new items last time:

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

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

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

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

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

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

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

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

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

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

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

I didn't need my reactor anyway.

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

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

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

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

Mysterious.

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

Happy teleporting!

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

• "Post-Balance" Cogmind Item Expansion
• Special Events Give Back, and Perfect Stealth - coming soon
• A Simple Approach to Player-designed Robots - coming soon
• Projectile Deflection - coming soon

[Kyzrati]

Special Events Give Back, and Perfect Stealth
[Cross-posted from the devblog here--follow link for better formatting and light-on-dark style.]

Cogmind's "special modes," timed events with unique mechanics, can in one sense be seen as the experimental test beds of Cogmind. Sometimes ideas come along that are interesting to play with, but may either not be suitable for the regular game, or I don't feel the effort and architectural requirements to support them are worth it in the bigger picture compared to what they add vs. all the other content options awaiting development. And although I don't usually go into building such a mode with the intent to test ideas potentially applicable in the regular game, the results often do inspire such features down the line.

One new example of this phenomenon at work is the ID Mask.


Finally, Perfect Stealth
In short, the ID Mask is a new consumable "disguise utility" that allows you to travel completely unnoticed and untracked in Complex 0b10, waltzing right past enemies if you want to.

The holy grail of stealth tech, if you're not welcome in Complex 0b10.

The ability to disguise oneself like this has been requested by players since Cogmind's alpha days (shout out to its main proponent, zxc!), but to me it wasn't the sort of tech that the game was ready for, be it for balance, architectural, or lore reasons. A confluence of factors have contributed to now being the time it's finally ready to be designed in.

Using an ID Mask is fairly straightforward, just pop it on to start the clock and enjoy your anonymity for as long as it lasts. I'm sure it can save your butt, or enable some sneaky tactics.

Hm, more Behemoths maybe calls for more masks? :P

These will also fit deeper into the lore, as I prefer any tech does in order to exist, though some of that lore (and more sources to acquire one!) will be coming in future versions beyond the initial inclusion.


Polymind and Other Test Beds
If you played Polymind you'll probably recognize this ability, which is actually where the architecture comes from in the first place. As special events do, Polymind introduced new mechanics that needed to be built into the system, both showing us that they're possible, and also allowing everyone to test how they play out.

Several major new features were required for Polymind to work, one of which being the central idea that "0b10 bots can ignore you." It's possible there might still be some kinks in there somewhere when it comes to special cases, but it should at least work as well as it did for Polymind, and adjustments or fixes can be made if necessary.

But anyway this is one example of a mechanic originally unique to that mode now becoming embodied in a specific item available in regular Cogmind! Sooner or later the same thing may happen to some of the other Polymind-specific features, but as of now this is the first.

The first from that mode, anyway.

Another feature I've added for Cogmind's next release takes a chunk of code from Player 2, the mode in which you're accompanied by what is essentially an AI-controlled Cogmind capable of building and maintaining itself from items as you can.

"P2" introduced a number of new mechanics, some of which I've always wanted to include in regular Cogmind (after seeing how they work) but haven't had the chance. And no, the new feature is not a Cogmind-like ally, although that is something I would like to add to the regular game at some point if I get to it. (There are even perfect lore tie-in opportunities!)

Specifically, what I did was adapt Player 2's contextual dialogue system for... something interesting ;)

Player 2 commenting (at bottom) after letting loose with a ridiculously massive amount of firepower against some targets in the caves (screenshot provided by nikolayAg).

Among other previous event influences, you might notice similarities between Abominations (Halloween 2019) and the Botcube, which I'll be writing about next time.

Despite having never proactively used special events to test planned Cogmind features, based on my experiences incorporating and adapting ideas from past modes, and liking how they save time on both implementation and design (while not necessarily ever being something that must make it into the regular game), I've even started planning to use this approach for future special events, a way to test features I might want to add.

Specifically for the past year or so I've had an idea for an event that could tie in pretty well to a future faction, so long as the gameplay works out when it becomes a central focus. It could be one of the potential Merchant systems.

This is the third 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:

• "Post-Balance" Cogmind Item Expansion
• Teleportation Mechanics
• A Simple Approach to Player-designed Robots - coming soon
• Projectile Deflection - coming soon

[Kyzrati]

A Simple Approach to Player-Designed Robots
[Cross-posted from the devblog here--follow link for better formatting and light-on-dark style.]

I like the idea of designing robots, putting together builds for a particular purpose or with particular capabilities in mind. As I've stated many times before, my first influence for Cogmind was the original BattleTech board game, where my friends and I wouldn't just take stock mechs, but designed our own based on the rules, selecting the right combo of weapons, heat sinks, armor, and special tech.

A BattleTech loadout sheet. Sadly all my old BT books and records are at a relative's house right now, otherwise I might go through them and share a thing or two :)

A Mechwarrior Online build. I also played all the early PC BT games, and later MW spinoffs and related games, all the way up to MWO (though had to stop some years into it because for some reason my new computer kept glitching out on it, but it's probably for the best :P).

Even more than being a tactical roguelike, Cogmind is a strategic game about engaging in a dynamic form of this process, repeatedly replacing and upgrading components as you go. And based on the current situation, or plans for what's to come, you can even pivot your whole build at one point or another.

So if bot-building is a main feature, and players of Cogmind therefore most likely enjoy bot-building, then perhaps there are other areas we could apply this activity? What about designing robots other than yourself?

Actually Player 2 mode sort of has this quality to it, since even if your opinionated ally is technically responsible for putting themselves together, they can only do so using parts they have access to, which like in your case are acquired entirely from their surroundings. If you can control what they get their hands on (e.g. by destroying or stealing whatever you don't want them to have), you can indirectly control what they are more likely to build. And when they need parts to complete or improve their build, you can also drop stuff nearby and see if they're interested in it. It's not quite reliably building your own robot from scratch, but you can influence the outcome, so there's that.

Player 2 builds shared by various players over the years.

Some players have been known to take Player 2 sculpting to the next level and even try to carve specific parts off their friend (chop 'em up!) in order to force them to use alternatives, either from their inventory or provided by Cogmind.

But yeah, clearly still not the same thing :P

How else could we add robot construction? Well I don't really want* to go as far as creating a full-blown in-game design system with a dedicated interactive UI like you might find in some sort of RTS or games with a vehicle design element. That'd be fun, but overboard.

*Oh no, on the heels of my previous post about special modes and their experimental test bed nature, I realize that yes I do actually want to try that, and some forms of this could make for a very interesting event xD

It's got to be simpler than that... How about simply dropping a bunch of parts on the ground and telling them to be a robot?


The Botcube
Say hello to the Botcube, and the new friend it will create for you, or more specifically the new friend you will create with it.

It's a cube. It makes a bot.

Usage is indeed quite simple: Drop the Botcube on the ground and interact with it in the normal way ('>' or left-click) and it will start the creation process, turning itself into a brand new robot. Hopefully by that time you've prepared a collection of suitable parts for it to use, lying around on the ground within range (or maybe are just dropping Botcube in a pile of post-battle wreckage to see what happens?).

Every couple turns it will suck up a new part and merge with it, until either all potential slots are full or there are no more compatible parts nearby. Then beep boop your new friend will self-activate.

Creating a Botcube mutant. In this test recording, a robot created by the Botcube is represented with a Mutant tile, but will have their own once released.

Your history log will conveniently record the feat.

The history log also includes some basic information about what kind of Botcube friend you created.

Don't forget to inspect your formidable new ally!

Inspecting the Mutated Botcube's final stats. Its core attributes are static, though as with most robots the majority of their capabilities are defined by their loadout.

Implementation of this feature was somewhat quicker than it otherwise would have been because I already had a template for the process of building a bot from nearby parts, originally used in Abominations, one of the advantages I wrote about in the previous post.


Complementary QoL
As a player what do you need most to facilitate using this sort of tech? At least some way to tell which parts the Botcube is compatible with. The answer is most, but there are a few exceptions, generally including things that AI-controlled bots can't really use, or aren't suitable for certain types of allies from an architectural standpoint.

In order to help out with that, while standing on the Botcube (the only position from which to activate it) all nearby compatible parts will intermittently flash. Anything not flashing will be ignored.

Botcube compatibility highlighting demo.

This also coincidentally makes it obvious which items are within range to be utilized--double QoL!


Ancient History and Distant Future
In implementing this feature, I'm reminded of one of the times Cogmind was written about in Rock Paper Shotgun years ago, where the author assumed you would also be "building your own allies" in the game. Anyone who's played in the years since will know that's not really much of a thing aside from fabricating bots based on existing designs, at least not in the sense implied by the original assumption (designing them as well), but I guess we can have some of that now :)

I bet there will be a range of new theorycrafting discussions to go along with this mechanic as well. Really looking forward to what people do with this one.

On that note, one area of concern here is that Cogmind's allies are notoriously disposable, by design. You put effort into collecting a few parts you want to see merged into one bot, or even *gasp* take time to plan one with care, only to have it gunned down by the next squad. Yeah that would suck.

We can't exactly make them invincible, either, but to at least protect against rapid death they're given high EM resistance, a decent amount of core integrity, and low-ish exposure. With your level of control you can of course also choose to armor them for better coverage, or improve other stats you think will help them survive, or aid you in your situation. They're essentially akin to a customized Hero of Zion.

There are also more possibilities for this tech, which I had actually revisited in my notes a couple years back to specify that it would be appropriate as a piece of primary content within yet another new map that might happen further down the line. But since I do think this mechanic will be fun to play with, and there's no guarantee that other map will actually happen, I think this is a good opportunity to at least provide a taste of it!

I can also use this opportunity to hint at its origins for the lore.

:D

This is the fourth 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:

• "Post-Balance" Cogmind Item Expansion
• Teleportation Mechanics
• Special Events Give Back, and Perfect Stealth
• Projectile Deflection - coming soon

[Kyzrati]

Projectile Deflection
[Cross-posted from the devblog here--follow link for better formatting and light-on-dark style.]

Ever since my first design docs from Cogmind pre-alpha, written back in 2013, I always wanted a projectile deflection mechanic. Like it doesn't get much cooler than that, being able to swat away bullets or even send beams back at an attacker, or redirect them into other targets.

Every few years I think about the concept again, and it finds its way into my ongoing notes in yet another location in some slightly-altered form or alongside some other content idea, begging to be implemented. At the same time, being so cool it's likely one of those rarer abilities that ends up more suited to unique parts, and even after ten years of development had yet to find a proper home on Tau Ceti IV.

One day several months ago I decided the wait had gone on long enough and this mechanic needed to happen now. Who cares if I didn't even have a specific use case yet?

This marks the first time in Cogmind history that I implemented a new mechanic before actually having a spot for it in game--I had no idea what item(s) or robot(s) would make use of this feature. But I did know that we're now in the Era of Cool Expansions outside the core game, so I'd find a place before long, and unfortunately around that time I also need a smaller project to tackle while getting my health back on track after repeated concussions (seriously annoying and a huge drag on development for much of this year). The opportunity was ripe to implement something fun and compartmentalized, as opposed to the grand projects I was supposed to be working on at the time which would take a lot more brain power.


Not Recommended
In gamedev it's generally a Bad Idea to do this, building mechanics for your game that you aren't ready to apply anywhere. Having one or more detailed use cases helps you think through your specific needs and acceptable limitations, otherwise when it comes time to use a generically-implemented feature for an unplanned use case, you may either find there are problems or insufficiencies and have to rewrite it, or eventually discover that you did too much work because you're never going to actually use all those features or options you built in anyway :P

I already know I've built a system that's probably more flexible than I'll make use of, based on a lot of hypotheticals as opposed to real world scenarios, but at least it includes a set of features I do know I want.

The main other aspect to worry about when prematurely constructing any non-simple system is that when it comes time to use it and you find the system doesn't quite fit your real world needs, you then have to go back to make adjustments, which can easily be more time consuming than it would have been if the initial implementation happened at the same time, given complete familiarity with the system at the time. It's just potential for extra overhead, really, but dammit I wanted to see projectiles bouncing around!

Aside: This whole section strongly reminds me of those who design, build, and expand game engines without actually using them to make a game, though that's on a different scale altogether.


Flexible Deflection
So I tried to cover all the bases by building a flexible implementation for projectile deflection, identifying tweakable parameters in order to hopefully support a range of fairly different items, of course all still centered around the idea of making sure projectiles hit something other than their intended target ;)

Among the main features of this system:

• random deflection within a specified relative arc
• deflection that always counterattacks the source
• redirecting projectiles to target nearby hostiles
• categorization of projectiles for deflection purposes, and the ability to specify a category to deflect, or deflect all of them

Architecturally, deflection of projectiles is somewhat related to the penetration and guided waypoint systems, which served as a good starting point for implementation. The main requirement is to be able to give the projectile a new trajectory at the right time and let it continue on its way.

On that note, it's nice that there were actually multiple indirect benefits of building a deflection system, improving the game in other areas along the way, including addressing the longstanding issue of guided projectiles always treating weapon ranges from the original source, rather than by measuring the actual path traveled, enabling them to exceed their maximum range in some cases. It wasn't too much of an issue, hence why I'd left it like that for years, but this also factors into play with deflected projectiles, so it was about time to do something about it--projectiles traveling along a non-straight path now measure cumulative range for accurate distance calculations:

Firing a guided projectile to the left here and reversing its direction will not reach the targets on the right, but if firing to the right they are all in range. Before this update, firing to the left and circling back around would still work. Not a useful tactical situation by any definition, just demonstrating the difference in action :)

Shiny Applications
So while I had no spot in Cogmind for deflection just yet, or any plans to even include it in the next release, the soonest I saw it appearing was with the Unchained, a deadly group of hostile unique derelicts working for MAIN.C.

And no doubt beyond that as well, since there are a good number of ways to use this new tech. When we think of deflection, the obvious use case is in defensive shield technology, but most any item is allowed to have deflective properties, meaning we must have an energy sword that can deflect incoming projectiles. Because duh.

Below are some recordings made while I was building the system. Note they're all just test shots with fake items I was using to make sure everything works as expected, so don't read anything into that aspect. These are also not usually very realistic scenarios, either, just having a bit of fun :)

The very first system test, deflecting grenades back in the direction they came from within a 90-degree arc.

 

Similarly deflecting incoming shots within an arc, but sending them back into an enemy within that arc. Cogmind is not firing a shot here, just passing turns :P

 

Deflecting kinetic projectiles backwards, like shedding them off to the side.

 

A 360-degree deflection capability redirecting an incoming missile at a nearby group of Swarmers.

 

Spectating a dangerous game of hot grenade with the local opposing Demo squads.

 

The system also supports per-item animations and SFX for the deflection, seen here using a random placeholder to confirm that it works. (You can also see there deflection benefiting from the cumulative projectile range limitation feature, unlike the earlier shots before that was implemented.)

 

Also yes, deflection is recorded in the all-important revamped combat log coming to the next version.

Well I can finally cross deflection off my list!

Funny enough, back when I first wrote about building this feature on Patreon, there really was no intent to add any deflection-related items to the next release, which is already packed with so much other stuff. Fast forward to a couple months later and there are already no less than three different such items xD

This is the fifth and final post in a series on new item mechanics. I didn't cover 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:

• "Post-Balance" Cogmind Item Expansion
• Teleportation Mechanics
• Special Events Give Back, and Perfect Stealth
• A Simple Approach to Player-Designed Robots