next »

[JobLeonard]

(Only the latter has the entire changelog in text form, though, because it's huge and vastly exceeds Steam's character limit on news announcements xD)

This is the most Kyzrati thing ever

[Kyzrati]

Agreed

But like what's up with that?! It's only about 6,300 words, c'mon!

[Kyzrati]

Audio Accessibility Features for Roguelikes
[Cross-posted from the devblog here--follow link for better formatting and light-on-dark style.]

Anyone who's followed my development work over the years will know that I'm big on providing all sorts of quality of life features, optional functionality, configurable settings, and so on. This is also why even from the earliest stages (pre-7DRL!), and ever since, I've given the utmost priority to Cogmind's interface.

How players interact with a game, both in terms of input and feedback, is vital to the experience, so even the greatest mechanics and content can be held back by insufficient attention to UX. Although it's a lot of work to always be putting the interface first (while still trying to maintain progress and design within the necessary constraints), and I sometimes have to pick and choose what I can implement as a result, I think it's been worth it in the long term. Not everything I'd like to do is really possible, but I try my best.

Having recently covered the new ambient audio system, today I'll be introducing Cogmind's audio-related accessibility features, features that other roguelike developers could potentially learn from and apply to help their players as well.

In particular I'll be talking about Cogmind's "visible SFX" system, allowing you to see the sources of sound effects, and the audio log for listing in text form both ambient and non-ambient sounds currently heard from Cogmind's position. As we'll see, the cool thing about both of these features is that they're not just for people who must have them by necessity for accessibility reasons, but can also help other players in certain situations! Like anyone playing with the volume low, or even muted, or in an otherwise loud environment--everyone can benefit :D


Visible SFX
Originally a "what if" kinda feature that was mostly intended as a fun experiment, I immediately started liking the implications of being able to see the origin of sound effects outside your field of vision. This means being more aware of battles happening nearby, pinpointing enemies attacking from outside your visual range, locating undiscovered doors currently in use, knowing exactly where nearby garrison reinforcements are coming from... all kinds of useful applications. It's essentially a free type of sensor, but one that only works when the surroundings are changing and therefore often lends itself more to reactive than proactive tactics.

Visible SFX demo, "seeing" a battle playing out around the corner.

More or less the same situation as above, but playing out on a black background so it's a bit clearer.

The animation is generally just a single flashed dot at the origin and a quickly fading box around it, although for sounds with especially longer ranges (usually explosions) and therefore presumably louder, the animation is both brighter and has a larger fade radius.

Visible SFX animations are also color-coded by sound type to make the indicators more useful, even more so when lots of things are happening at once:

• Red: Combat-related
• Orange: Door open/close
• Yellow: Trap trigger, carrier deployment, or garrison dispatch
• Blue: Emergency door open/close or phase wall destroyed
• Green: Machine destroyed
• Brown: Walls destroyed or cave-in

Successive red flashes mean there's fighting going on, naturally one of the more common situations, and if you didn't instigate it, then depending on your build and condition it might be wise to either avoid the area or hurry over to lend your firepower to whichever side is on good terms with you (hopefully one of them is? :P). Either way, the system offers more options for informed decision-making rather than flying blind.

Together with the extra positional information you otherwise wouldn't have simply by listening to the sounds, this feature also has the added advantage of better accessibility for hearing-impaired players, or anyone else playing without sound.

Although visible SFX are active by default, it's possible to turn off in the advanced configuration file in case the extra visual flair bothers someone.

(Visible SFX were added to Cogmind three years ago back in Beta 1, though I haven't mentioned them on the blog before.)


Audio Log
Something I was exited to finally add to Cogmind, since I've wanted to do it for a very long time now, is the audio log. The audio log is meant primarily as an accessibility feature akin to closed captions, allowing anyone who keeps their volume low or muted to be able to retain access to important audio knowledge (alongside the visual SFX feature, although that one is much more of a perk for everyone). This optional feature is disabled by default, but after testing it out I think this'll be a pretty popular one even among those who don't require it.


Features
Now, I say "closed captions," but it's definitely not a list of "pew-pew" and "kaboom" or anything like that, instead listing the name of the effect's source in a small window embedded in the top-right corner of the map view. Ambient sounds are listed first, followed by a separator, then any non-ambient sound effects (the latter category referring to one-time sounds like gunfire and explosions).

Walking around a Materials map as the audio log updates to reflect machines that are being heard from each point.

The number to the left of each sound type indicates its current volume, which players can use as a proxy for distance.

Like visible SFX, the audio log also color-codes its contents to provide extra info where applicable:

• Gray: Fluff machines, those serving to reflect the theme of the area and be destructible obstacles rather than serving an otherwise significant mechanical function.
• Orange: Explosive machines. Beware.
• Blue: Special-purpose machines with a unique function. Destroying these always has some effect.

Watching the audio log while passing turns and occasionally moving around as a war is playing out nearby. This demo also makes it clearer that sounds are ordered by near-to-far rather than the order in which they were heard.

Non-ambient sounds are color-coded by category as well:

• Yellow: Attacks and gunfire.
• Orange: Explosions.
• Red: Robot destruction. Very specific compared to other categories, but also very important so it gets its own color.
• Green: A wide variety of events including traps, drones, turrets, scans, phase doors, door hacking--basically everything that doesn't fit in any of the other three categories.

When combined with the visible SFX system the non-ambient data is even more powerful: "see" this great fight heard outside the room as it's described by the audio log and blips on the map:

Funny how it ends ;)

Not quite every sound appears in the log. In choosing what sounds to report in the audio log, in most cases it was geared towards information that is strategically helpful to know when out of view, rather than providing an exhaustive list. Limiting it to what really matters helps keep the log cleaner.

Although door interaction is fairly important, it is not reflected in the audio log since even if out of view they are clearly displayed via the visible SFX system, and their frequency is often rather high so it might threaten to drown out more meaningful sounds. An exception was made for phase wall interactions, since those are strategically important but do not reveal their precise location as a visible SFX source.

Other sounds that have clear visual alternatives are also generally excluded to avoid padding the audio log with unnecessary "noise." Examples include dispatch alerts, and the EMP charging and discharging in Waste (which come with their own graphics and messages).

So while the audio log technically doesn't paint a 100% complete picture of Cogmind's soundscape, it provides one aimed at an optimized play experience, not unlike the optimizations found in many other parts of the interface.


(continued in following post...)

[Kyzrati]

(...continued from previous post)

Challenges
It was a surprising amount of work to finish the audio log, taking an entire week to complete as I discovered quite a few roadblocks along the way. Definitely worth it and I'm glad it's now implemented, but I expected it to take just a day or two xD

There were lots of questions to answer about this feature...

Right from the initial mockup stage we of course needed to know what kind of information would be conveyed. At first I was thinking distance alongside the name of the sound's origin (e.g. the machine--at this point I was only thinking about ambient loops), but then realized that precise distance is conveying more specific information than you get by simply hearing a machine. Overall I wanted to try to avoid making the audio log seem like a necessary feature for everyone to have active at all times, meaning the info provided should to be comparable to hearing a sound. So of course it should report the volume as a number (percentage), duh.

Excerpt from my original audio log mockups. You can see there were yet more changes made after these ideas.

Then I was considering how an ambient sound list would treat multiple sources of the same type, like a group of Nuclear Reactors. The answer is to just do like the actual ambient audio system and only list the type once at its loudest current volume, again maintaining parity between the audio log and what is heard, but I clearly kept getting sidetracked thinking about all the new info made possible by this new format! The point is that throughout the process one of the roadblocks was myself--I repeatedly had to reign in these wild design thoughts :P

Naming the ambient sounds for the audio log wasn't hard since I already had a list of the sources and their respective names, and none of them are reused across different sources. Non-ambient sounds, however, were much more problematic since there was no precedent for this in the architecture (which of course hadn't taken it into account from the start), but including them is quite important for accessibility. After all, once you're familiar with the sounds certain weapons make, for example, the fact that you can hear them around the corner technically lets you guess what types of enemies (or allies) are fighting nearby, even without sensor data. This same information needs to be reflected in the audio log.

I experimented with a number of different approaches for the names of one-time sound effects, but after a complete survey of the parts involved (in particular weapons) determined that it made the most sense to use a single name associated with the audio sample and add no further differentiation. This means that weapon sounds do not necessarily list the specific weapon name, but instead the base name for the sound. For example there are a number of railgun variants that use the same sound, and the audio log will not differentiate between them, simply listing each as a "Railgun." Any weapons with unique sounds are indicated by their specific name where applicable, though. This, too, seems obvious in hindsight, again maintaining parity with what is heard, but it wasn't clear to me at first...

Other naming issues or ideas considered along the way:

• I originally thought the audio log would have to take into account player knowledge, i.e. unknown parts or unidentified prototypes, but in the end it doesn't really make sense to obscure that information since players who generally play with the sound on learn to quickly recognize different SFX and retain that metaknowledge regardless of what the game would list in the log anyway. So we can ignore this limitation (which would otherwise be a hugely complex possibility to account for). Bullet dodged.
• At one point I also thought about using descriptive names that didn't exactly match weapon names, e.g. "Weak Laser" for Small Lasers or Backup Lasers, since both use same sound effect, but this approach doesn't scale well at all and would just end up being unnecessarily confusing, forcing players to learn a whole new set of words just for this feature.
• Then I also thought about using a special type of marker, prefixing the sound name with a tilde (~) in certain cases to represent that the sound belongs to a category of multiple variants and it could be any of them, but that seemed like unnecessary extra info so I simply removed all of those from the data.

Under the final naming system explosion sounds were an issue since many of the same samples are shared across different types of sources such as launchers, machines, and traps, so for those I opted to go with a more generic "Explosion (XX)", where the XX refers to the common abbreviation for the relevant damage type.

Multiprojectile weapons presented one of the biggest problems, one for which I sadly only found a partial solution. Each projectile actually plays its own sound because of how the projectile mechanics are tied to the particle system, and because the audio log is directly tied into the sound system, which doesn't know about game mechanics or what's really happening, thus a single weapon can cause more than one (or even numerous!) entries to appear at once.

The best solution I could come up with for limiting the extra entries involved adding a variable set manually for each sound effect that essentially blocks a predetermined number of subsequent matching audio log messages after the first. Hacky, yes, but it mostly works...

For example an EM Shotgun fires two projectiles, each playing the same sound*, but because the sound effect has a '1' assigned to that variable, on playing the sound the first time the audio system records that it should simply block the next attempt from being logged. (*Note that even though it's the same sound, weapons tend to randomly modify their pitch for each firing/projectile, and multiprojectile weapons in particular may also add a random but slight amount of staggering to their projectile firing times.)

Unfortunately it's not a perfect solution because the value must be set at the SFX level, but in rare cases some weapons use the same sound effect but each fire a different number of projectiles, so there are a small handful weapons for which the log might desync on certain turns, though in most cases these are not weapons enemies use anyway (only Cogmind does), so it should rarely if ever come into play.

Technically I suppose we could just always report every single projectile as a separate audio entry, but for some weapons that could get excessive, and it also just makes the log harder to read by polluting it with extra lines, so maybe I could change it later, but for now we'll stick with this method.

Aside: I did actually test the per-projectile approach, using the standard roguelike message log behavior for duplicate entries, but that didn't pan out. The idea was to merge duplicate entries with a multiplier, like "50 / Flak Gun (x6)" and so on, simply allowing multiple projectiles to stack when they are of the same type and volume. One problem here is that weapon sound effects are often heard at maximum volume across a decent range, leading to lots of overlap in the log and making it difficult to discern just how many different weapons are being heard (or at least require the player to do some math when there are lots of things happening at once). The potential gains here (being precise and consistent in every case) didn't outweigh the costs (confusing!), and considering how rare it is for enemies to have a weapon that might cause temporary audio log desyncing, I prefer that the log show weapons on a per-weapon basis rather than per-projectile. Obviously most games don't have to worry about this kind of thing at all--it's kind of a weird situation likely unique to the way Cogmind's projectile, logic, and audio systems interact :P

Altogether it was a lot of work to go back through every sound and projectile, cross-referencing all their uses in order to assign names and other values for audio log purposes, but eventually that was done and... oh wait, there was still more to do xD

Aside from the content, the new audio log's existence itself caused some issues. For one its design places it against the right edge of the map, which would obscure any intel markers appearing along that edge segment.

To resolve that I spent a while updating the intel marker placement system to get them to avoid the window itself:

The audio log displacing various intel markers that would appear along the right edge.

Labels for offscreen exits needed a similar treatment, although there are always far fewer of those, so I opted to instead just shift them downward rather than pushing them to the left of the audio log window:

The audio log displacing various offscreen exit labels by pushing them downward if they would otherwise appear behind the window.

In hindsight maybe it'd be better to just treat the audio log like most other on-map windows that can appear and displace it from every edge by 1 column/row, although I felt like the right side should be snug against the edge since this particular window doesn't have its own border. So maybe it needs its own border??? As a result of writing this article to here I had to mock it up :P

Mockup for an alternative audio log concept, with a border and increased padding.

This option occupies more space (and has to leave even more space for markers), but I guess the consistency could be worth it? It also serves to better separate the log from the map behind it so that it's more clearly it's own thing, which is kinda nice. Cogmind's special mode UI windows that appear at the bottom-left of the map already do this, as do the achievement icons that appear in the bottom right when those are earned...

That said, I saw the audio log as more of a right-adjusted counterpart to the full combat log appearing at the top-left of the map, also without any border. Designwise that one is slightly different, however, because as left-adjusted lines (and potentially long ones at that) it felt fine to have them cover only as much of the map as they needed to on a per-line basis, whereas the audio log on the right works better when the width of the area covered is uniform.

Anyway, I'll have to think about that one. (Edit: On discussing this with patrons, one good point brought up by Tone is that an explicitly bordered window that frequently changes its height could end up being more distracting, which makes a lot of sense and is good reason to leave it as is, without the border, like its similarly "shapeshifting" borderless counterpart, the full combat log.)

There you have it, just a sampling of the problems encountered in building the audio log--there were lots of other little ones, mostly specific to how Cogmind's architecture works, its limitations, or trying to get information from one place to another, and, again, overall it took a full week to finish this "little" feature for which a lot of the foundation had already been established!


Options
The audio log itself is optional, off by default but accessible from the options menu. As usual, I've also made some of its behaviors tweakable where that may be desirable:

Normally ambient sounds are always listed, while non-ambient sounds are only shown when the origin is outside Cogmind's FOV. Although this goes against the idea of a truly complete "closed captioning" system, this is actually a more reasonable approach to default to since you can clearly see visible attacks and other sources of audio anyway, and this behavior also keeps the audio log focused on sources currently out of view without letting it become too cluttered with duplicate information. But of course the option is always there to include every sound effect if someone wants/needs to expand the rules. Regardless of this setting, non-ambient sounds originating from Cogmind's own position (mainly attacks) aren't reported to the audio log, since those should be obvious and would just clog up the log with too much info.

Ambient sources ended up being listed regardless of whether they're in view because even though it might've similarly made sense to only list those that are outside FOV, it turns out this was completely impossible without rewriting much of the ambient audio system xD. No matter, it's fun (and sometimes convenient) to see those listed, anyway, and they're definitely not excessive like non-ambient sounds can be!

Fluff machines (reminder: those that do not explode and have no special mechanical purpose) are normally included in the audio log, but there is also a setting to exclude them to avoid the extra noise. I imagine most players would want to leave them on for a number of reasons, though preferences could depend on what other settings are being used.

The maximum length of the log is adjustable, too (down to the bottom of the map view, which is actually the default), as is the length of time for which non-ambient sound effects remain visible before disappearing from the log.


General Audio Settings
As a major accessibility feature the audio log toggle has been given a place in the Audio section of Cogmind's primary options menu, alongside several other options some might find useful.

Cogmind's latest options menu layout and contents.

Of course there's a master volume control, but as part of that each of four separate channel categories can also be adjusted individually to change their relative volume. "Interface" includes all the UI feedback, the beeps and clicks and alerts, etc.; "Game"covers mechanics, combat, and other events; "Props" are all the environment objects like machines (basically any ambient loops that aren't the mapwide audio); and "Locale" refers to the mapwide ambient audio track for the current map.

Over the years I've also added a couple other special audio options by request, though these only appear in the advanced configuration file:

• muteTextSfx: Some players are sensitive to the text typing sound, which is pretty ubiquitous in Cogmind because there's text being printed to the log all the time as things are happening, but it usually isn't a vital part of the interface feedback, so I added a way to disable that particular effect.
• muteGlobalAlertSfx: At least one player didn't like hearing global alerts, generally referring to enemy squad dispatches as a result of your presence or actions, or otherwise potential danger coming your way, so I added a separate way to disable those. Alert situations are also accompanied by a more specific white log message and an additional flashing message at the top of the map view, anyway, so it's usually not too hard to miss. Personally I tended to miss anything except an alarm playing, but the idea of options is that not everyone has the same observational habits or abilities so making things customizable is usually advantageous where possible.

As with many of Cogmind's huge range of quality of life features, it took a while to reach the current state--naturally not every issue will be foreseen and implemented right away, and it can take years to properly add all this stuff to a game (especially as a solo dev), but in the long run listening to feedback from players and doing what I can to offer improvements to the experience has been an important part of the process.


SFX, Stereo, Action!
You can see both the visible SFX and audio log in action in my first Beta 10 prerelease stream in which I introduced the log alongside the new soundscape:

[JobLeonard]

Wow, that is an amazing amount of accessibility polish

[Kyzrati]

Yeah it was nice to finally be able to add this! Made sense to do it after adding all the ambient audio, which was basically the last thing on the roadmap, so... took a while to get here

Also--oh no, running out of generic-ish topics to do and write about on Cogmind xD

[Kyzrati]

It's a new release with a special event for Halloween, and more!

Let the ARG begin :D



Release notes with details.

I'll likely be doing some sort of writeup on this event since it's quite unlike anything I've done before, though that'll have to wait until the event period is over so as to avoid giving anything away, and also allow the opportunity to see how players interact with it!

[JobLeonard]

Ooh, that looks like a very cool event! Looking forward to the follow-up blog

[Kyzrati]

Ooh, that looks like a very cool event! Looking forward to the follow-up blog

Heh, yeah I was taking a lot of notes today as I sat in player voice chat listening to them working through the levels. Lotsa fun!

[Kyzrati]

Exploring the Concept of a Terminal Roguelike "Overmap"
[Cross-posted from the devblog here--follow link for better formatting and light-on-dark style.]

Lots of games have "minimaps" allowing you to view a greater area than normally visible in the game screen, although (except in maybe a few rare instances) these usually aren't games with displays limited to a strict terminal grid like we have with Cogmind. After all, you can only "zoom" so much given the restrictions of such a grid.

That said, it has certainly been requested multiple times before, so I first explored an alternative possibility last year, what I've been calling an "overmap," just to kinda work through what an implementation might entail, and what benefits it could provide us with.

At the time it didn't get very far since it was a spur-of-the-moment type of little side project and I got too busy with other features later, though the rudimentary code and interface have actually been in the game all this time and some weeks ago I picked it back up again to play with the idea some more.


Method
So what's the best option here--how much more information can we really show using an alternative display method that obeys the grid?

Fortunately for us Cogmind does technically have a narrower grid than that used by the map: the grid on which text is displayed, and which represents the actual base terminal grid underlying the program. Map cells each occupy the same amount of space as two of these text cells combined. Purely by taking advantage of that fact, we could use text cells to represent map cells in order to narrow the map into half as much space horizontally.

Then we can get even more creative and use a CP437 character, the half block, placed in every single overmap "text" cell to divide it in half yet again, this time vertically. Then the foreground color of a cell, that coloring the block itself, is used to represent one map cell and background color represents another. Altogether this allows us to compress four map cells into a quarter of the space!

Comparing text and map cells in Cogmind. Notice how the square '#' cell (an ASCII mode wall) occupies the same amount of space as two letters ("nd") below it.

Representing four map cells in two text cells using purely foreground and background colors, also showing how the wider room looks when converted to the colored block method.

Using this method, a 200x200 map like Factory could be displayed in a 100x100 area (one quarter of its normal size in pixel terms as well), 35% of which would fit in the usual map display area, and 48% of which could appear if we expand the "overmap" to fill the entire Cogmind window! In other words, using this method we can squeeze an entire Factory map into approximately two screens worth of visual data.

A quick demo of opening a Factory map in its basic overmap form.

Some Pros and Cons
As you can see it loses a lot of detail, but I mean it's essentially just a "huge minimap" so that's inevitable :P. In that sense I've always been skeptical of how useful it really is considering you can already 1) see such a large area at once on Cogmind maps due to the relatively small grid (by default containing more cells at once than almost any other roguelike) and 2) easily pan around the map at full detail and get all the normal features and benefits of doing so.

I can see it coming in handy to more quickly skip the map view focus to a specific distant point on the map, at least via mouse (this aspect would perhaps be somewhat less useful for keyboard users in that regard?).

Certainly more worrisome from a development perspective is that there wouldn't be a whole lot of interaction possibilities due to the fact that half-cells cannot normally be distinguished and interacted with separately in Cogmind's engine, although technically I guess it might be feasible to get the engine to make an exception here (basically have the overmap ask it for extra info when necessary--this could lead to a fair number of unforeseen complications or restrictions though, hard to tell without further testing). But obviously players want polished features in their roguelikes, so it's not all that desirable to release a feature that either can't be polished due to limitations, or isn't worth putting in a huge amount of effort to polish for limited returns. Features like this are usually best avoided because they're more likely to lead to unhappy players. These are some of the primary concerns that have been keeping me from doing much with the overmap all this time.

That aside, what other benefits could we potentially get out of something like this? Naturally based on its greater range of visibility we can assume many of its features would be associated with the idea "exploration." Cogmind's main map view already has a good bit of this in the form of intel and labels for off-screen objects, but perhaps a dedicated display would lend itself to additional uses instead of simply highlighting known stairs, for example.

One interesting idea I had while working on the foundation for this feature was to have an optional highlight for areas that haven't been fully explored yet. Combined with player "map sense" this could perhaps help realize that an exit may have been passed somewhere, or remind that a particular door wasn't opened, or even for tracking down that elusive Garrison Access in -8/Materials ;)

A partially-explored Factory map with edge highlighting.

Another common request related to this sort of feature would be the ability to add annotations. I'm not really sure what people would use it for, but I've added some random samples here as an example of what that might look like :)

Sample optional map notes superimposed on the overmap to describe certain locations.

Aside from gameplay use, I imagine some players might also be interested in using this feature to annotate how certain battles/adventures across a map progressed in order to share with others (or just for their own records). Some players do this already, but using either screenshots or Cogmind's full map export-to-PNG feature:

Sample map export image from a run shared by Pimski. Exporting a map to an image creates a large PNG showing all areas that have been explored so far.

It's also possible that we'll one day get on-map annotations regardless of the overmap, and those could transfer between the two automatically.

Despite my reservations regarding the overmap feature, I did add it to the feature voting list for patrons where it garnered a surprising number of votes, at one point in the lead though eventually falling to second place behind the item searching and filtering overtook it.

[Kyzrati]

Time for the annual annual review! This is the seventh, now available on the blog. There's the usual discussion of dev hours, an overview of releases and events from throughout the year, and confirmation that 1.0 will not be released in 2021, among other news :P

[Kyzrati]

Cogmind 2020 ARG Post-mortem
[Cross-posted from the devblog here--follow link for better formatting and light-on-dark style.]

A few months ago as I was planning out the rest of the year, naturally it was about time to start asking myself what kinds of special events we might have for Cogmind. The major Beta 10 was released in September, so there was once again an opportunity to spend some time playing with different ideas, and players have certainly come to expect some kind of event around various holidays given Cogmind's history (see: Launchers, Pay2Buy, Holiday Mode, Abominations, RPGLIKE, Player 2...).

The next upcoming holiday was Halloween, but none of the specifically Halloween-themed gameplay concepts I had were particularly compelling, then one day I suddenly came up with the idea to do an ARG. I'm not really sure where this thought came from--it just popped in there xD

ARG refers to "alternate reality game," which as a genre has a growing variety of possible forms and definitions, but among the primary uniting factors is that ARGs are created by mixing multiple types of interactive media, ideally with social aspects. (Wikipedia has lots more background info on ARGs.)

So what exactly would something of this nature work with Cogmind, and how would I build it? Having never done anything like this before, I had a ton of questions--well that's what every special event planning session starts with, but this time it was especially acute. It really shows in my early notes, several pages of ideas bouncing all over the place, some of which aren't even close to what the event became.

Early on I was clearly wrestling with trying to get myself into the ARG spirit by steering the concept outside the game itself as much as possible, against the grain of what I'm used to designing. I started out with REXPaint UI mockups (most Cogmind special events come with a special interactive UI component that appears in the bottom left corner, serving both as a useful reference and tool, and also providing extra info for screenshots), but in this case it didn't seem necessary, and kinda worked against the ARG idea by concentrating more of the event inside Cogmind. Instead it would make more sense to move the primary form of interaction with this event outside the game itself.

So I built a little website.



Forbidden Lore!

The event banner for Cogmind's ARG, more or less a screenshot of the website home page.

Players start from that page, on which there's a single link to reach the next page, or "level," but doing so requires a password. Getting a password is a multistep process:

• Read a hint on the web page which suggests a place in the game world to visit, or action to perform. The hint is just that, a hint, so doesn't constitute specific instructions, and figuring it out is to some degree a small puzzle in itself (though in most cases not usually that difficult for players relatively familiar with Cogmind).
• Find the associated password clue indicated by the hint, somewhere in game.
• Use the clue to obtain the actual password, which is somewhere on the internet. This is often the more challenging part of the puzzle, at least for a single individual, since the possibilities cover a broader range of domain knowledge, and the clues are more cryptic.

So the goal for each level is to solve a pair of puzzles to get the password to continue advancing to subsequent levels. (If you're wondering about more details and examples, there will be plenty of those in the walkthrough I'll be sharing later.)

Each new level provides not only the next hint, but also comes with a reward: lore! This perhaps makes the Cogmind ARG more unique than some, helping keep players interested by offering an explicit reward at every step, rather than making the solving of puzzles the only reward in itself, with maybe a single reward at the end.

A lot of Cogmind players enjoy the lore behind the game world, and there's plenty of unwritten pieces to that lore worth introducing or expanding upon. Some pieces are already hinted at in the game's current lore, while others are just my own additional concepts behind some of the content that the game doesn't (or hasn't yet!) directly addressed.

At first I had no idea at all even what theme to use for the ARG (it is "Halloween" in color only :P), but I'm glad I settled on lore since this was a fun opportunity to share more information about potential future expansions. In most cases they're not guaranteed, but are at least fun to read and think about--I've reread all the entries many times myself, just thinking about the possibilities :D


Design Options
Even with a theme nailed down, there were still some important general questions to answer, like whether the event should focus on individual participation or be more of a community event.

I did want it to bring the community together in solving a set of puzzles which would be relatively difficult for any one person to complete on their own, even planning to explicitly dub it a "Community ARG," but decided that wasn't really necessary and it could simply be a suggestion included as part of the announcement.

I also considered offering cash prizes, but changed my mind at the last minute since that might work against the idea of encouraging general cooperation across the community. Plus time zones, the fact that this event wasn't pre-announced at all (I wanted to surprise everyone :D) nor designed with hardcore competition in mind meant it would be hard for a cash reward to be fair to everyone. And of course there's already lore rewards at every level, anyway!

Another big question was whether to allow for multiple paths through the ARG, completing puzzles out of order (this was especially relevant to how the website would be built). It turns out there really wouldn't be so much content that such an approach might become very desirable, and designing for a more controlled, linear progression would make it more enjoyable overall. In the rare cases when players might discover an in-game clue before they need it, they could simply write it down for later reference.


Time to Solve
I targeted 1~2 weeks for a decent individual player working hard at it, or a month if relatively slow, but based on the amount of ARG content I figured that a group of players working together could probably do it in just a day or two.

Sure enough the first team to assemble as soon as the event started managed to reach the end in about 22 hours.

The puzzles are ordered mostly by depth, thus the first clues are found early on, and so on, making it easier to find multiple clues in the same run without having to start over. Of course with branching and a lack of backtracking in Cogmind exploration, it'd be impossible to solve the entire ARG in a single run. Theoretically one could acquire every single clue in a minimum of two runs if they happen to have the right branches spawn in the proper order and choose to do certain things in each, although it's highly unlikely someone would both get that opportunity and make the choices required, in some cases because the choices could be more dangerous and jeopardize some other clue they were aiming for at the time. More realistically it would at least take about 4~5 runs to complete (not counting potential deaths along the way).


Participation
70.5% of ARG release version (Beta 10.2) players were playing in ARG mode.

Note that Cogmind stat uploading is opt-in, so data only includes a subset of the community, and this event in particular had a higher run requirement threshold than previous events, at 10 runs instead of 3. What that means is that the event only auto-activates once a player has logged at least 10 prior Cogmind runs. Events normally exclude beginners like this in order to avoid confusing them (alternative rulesets and content are basically being added for experienced players to try out, or at least those already somewhat familiar with the base game). Players who hadn't yet met that threshold could still manually activate it, but according to the data only one player chose to do that.

This event in particular, with its deep lore rewards and requirement that one already be pretty familiar with the world in order to make good progress, was very much aimed at long-time players, and the median historical run count among participants was 40.

9.7% of players who met the threshold to automatically activate ARG mode decided not to and forced the mode off in order to play the regular game. (Some other players and runs were also excluded from the 10.2 ARG because they had manually activated some different past special event.)

The median number of ARG runs per participant was 3, which isn't really enough to solve it to the end, although in some cases where people were working together they might only do one run for the team.

Honestly the overall data here is not incredibly useful because it doesn't offer a way to know who was actively playing the mode with the intent to participate, because again it activates automatically for most players. Unlike how I've handled most previous events, I didn't include any mode-specific scoresheet data for analysis this time around.

But! We do happen to have another metric which will be somewhat more accurate, and also include anonymous players who didn't opt in to data uploading. It just so happens that anyone who gets the first hint and is on their way to completing the first level of the ARG has to visit a particular Pastebin paste, and that page has a unique hit counter. The paste itself is unlisted, so it's mostly going to be visited by players who are participating. Looking there (and subtracting my own test visits to that page with various browsers :P) I can see that we've got 185 unique hits. Still not likely 100% accurate, but it's a decent gauge of participation.

Apparently several dozen people also visited the account page I set up to make that post, from a special someone in the game ;)

Note the data for the above section was recorded a couple days before the end of the official ARG period (one month), so would be missing the last bit, plus some will still be playing past the end.


Architecture
The website part of the project is quite simple, a good thing because I ain't no web dev.

Like the front page, the content of each additional page/level is simply an image containing the entire page's text and graphics (so I can work where I'm more comfortable, in Photoshop :P), plus a hint linking to the next page.

Each new level is protected by htpasswd authentication, where as the first page indicates the user name for each level is simply "cogmind" (for simplicity), while the password is what players have to discover, as described above.

While building the site I tested all the content and links numerous times in multiple browsers to make sure there were absolutely no mistakes, since I didn't have anyone else helping me with prerelease testing this time as I wanted the nature of the event to be a surprise for everyone (even patrons). I did another complete round of testing once again shortly before launch, just in case.

On the game side there were a few new things to build, all of it pretty simple, though.

Naturally there's new content included with this release, basically messages in various forms, and those needed to be stored somewhere. My inclination with this sort of thing is to store all related data in a single external file, for ease of editing and organization. Doing this for an ARG, however, would make it quite easy to identify and hack, so I decided to avoid centralizing the data and instead spread it around within the executable itself.

Even there I didn't want the text to be that easy to scrape, so I also added a new system to encrypt strings within the executable. Despite these precautions I'm sure a dedicated individual could still hack it in less than a day, but that's fine, and could be a challenge in itself if anyone with the appropriate skills wanted to take that route to "solving" the ARG :)

The other main game-side work involved display methods for clues. This was fairly easy since sharing clues in most cases just piggybacked on the existing message systems, although in some cases it was necessary to make it a bit more obvious that something was a clue, for example the on-map alert/notice pop-up system got a new Halloween color theme option I could use for messages prefixed with "FORBIDDEN NOTICE:". There'll be plenty of examples of this in the later walkthrough.

Early in development I considered going the usual special event route with a dedicated interface for recording hints, listing clues and whatnot, but decided it wasn't necessary, and would even get in the way given how the event ended up being designed.

Mockup for an unused hint and clue interface.

Like raising levels during the RPGLIKE event in 2019, the mockup suggested there would a flashing popup whenever a clue was obtained, to make it extra obvious.

Puzzle Ideas
To come up with ideas for the puzzles, I first came up with two lists: one representing potential sources of clues within Cogmind, and another suggesting where I might want to hide passwords outside the game.

Most of the in-game options ended up being used, since an event like this should aim for maximum variety:

• NPC dialogue, for example on meeting them, or when they're destroyed
• Hacking to parse an NPC (reading their mind)
• Scene text on witnessing an event
• ALERT-style global announcement
• Terminal query
• Some special cases used other more unique channels, as indicated in the walkthrough

For possible password locations I chose mostly bits of the internet over which I have some or complete control, in order to ensure the event would go according to plan, and also even continue to be accessible after the official event ended:

• The event website (a variety of things are hidden in the website itself, which seems not too uncommon for an ARG? :P)
• Cogmind run database
• r/Cogmind subreddit
• Grid Sage wiki and/or forums
• Roguelikes Discord
• This dev blog
• Pastebin
• Other websites

Not all of the above were actually used. Also note that some clues would likely require using a search engine like Google to find information relevant to uncovering a password. Passwords might also be directly provided within the game instead of via the internet, where that approach would be fun or made more sense.

As for the puzzle content itself, aside from being basically familiar with the world of Cogmind, much of it is tech-oriented. Obtaining passwords is easiest with some knowledge of very basic web page analysis, binary text, CPU hardware, a certain movie, multiple other roguelikes, specific Cogmind lore, and Cogmind achievements. Being good at using a search engine in general would definitely help a lot, and could mitigate much of the need to have these skills or knowledge prior to the event.

By the way, the terminology I've been using throughout this article, and that I stuck with throughout development to keep things organized, defines a "hint" as the piece of info given on the website for where the player can get more info to progress, and a "clue" being the info found in game that leads to the final answer/password which is usually found online, outside the game.

(continued in following post...)

[Kyzrati]

(...continued from previous post)

Results and Observations
Reception was pretty good. Some players had never even heard of an ARG, others said they'd done a few before and loved them, and yet others said they didn't really like them in general. Regardless of what kind of event is held not everyone is as open to a larger departure from a game's normal format, but some players were really excited about it and enjoyed the process.

Not everyone was interested in the same part of the event, either--some were big on the puzzle solving, but didn't necessarily want to go through and do the in-game clue-collecting part. Even some who did want to do the collecting themselves had trouble targeting a specific location in the game during their run, since that's not normally how they would play (and it's overall a more challenging way to play Cogmind). And some players simply had fun watching others do the ARG to share the lore afterward.

It definitely turned out to be a community event that helped give a singleplayer game more of a multiplayer feel, because even if not in a team, often times players would need additional hints from others to fill gaps in their knowledge, or because they maybe overlooked a clue.

I had fun listening to players in the voice channel on Discord working together to advance through the ARG.

I hung out in that channel for six hours, mostly as a silent observer, as 5~8 players at a time solved level after level. The group had some of its better players responsible for quickly playing to the relevant in-game areas, while others were thinking through puzzles or alternative approaches. Puzzles that would eventually stump a lone individual for a while, or even permanently without extra hints, were no match for a group of players working together bouncing ideas off one another, and that first group was the only known one to finish in a day.

One interesting thing about hosting an ARG partially inside the game is that people pay a lot more attention to the game's details, to the point that players were asking others "wow, was this here before?" and "is this new?" or "did you know that???," where in every case it was something common that had been a part of the game for years--some player just hadn't noticed that particular detail before :P

So in that sense, ARGs are apparently a good way to force players to really notice details! (relevant or not...) Of course this effect also had players trying to find lots of meaning even where there is none, both inside and [especially] outside the game, leading to a variety of wild goose chases when searching for clues. One particular clue I'll get to later in the walkthrough was especially funny because one of the websites players needed to visit (not mine) also had its own cryptic ARG-style content embedded in the page itself, unrelated to the Cogmind ARG :P

Most of the Cogmind community plays with the default Rogue difficulty setting, but several switched to easier difficulty modes specifically to collect clues more quickly and reliably.

Early chat about different player approaches to, and opinions on, the ARG.

Starting from the second day a dedicated chat channel was set up for the ARG (day 1 would've been best, but at the time most participants were hanging out in the voice channel for faster communication at the start anyway). Technically the default ARG period was for the entire month of November (and some will likely continue playing beyond that), so it's been there and receiving a trickle of new comers as time goes on, more so because I keep pointing people there when they ask related questions on other forums or elsewhere.

The ARG channel is naturally filled with spoiler tags :P

As far as organization goes, and seeing how players advanced through the event, in the end I still think a linear design was the best approach, though I feel it would've been nice to have even more "side quests," additional ARG content to discover along the way but that wasn't required in order to progress to the end. There were a few such secrets, but not many--two of them were discovered, and to my knowledge the third has yet to be found.

So that's it for the background and meta discussion. In my latest followup article on the blog I share a walkthrough for the ARG puzzles with lots of juicy details and commentary:

[Kyzrati]

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

Many years ago, Cogmind's predecessor X@COM pioneered the idea of using a pop-up label system in an ASCII game to identify objects like items, beneficial both to help teach new players as well as a natural quality of life improvement. This allows players to more quickly know exactly what an item is, useful when there are otherwise few ways to depict differences beyond the typical character and color options. Labels can appear in various situations such as automatically when new items come into view, when a specific item needs to be pointed out for some reason, or when the player wants to label everything at once.

An early demo of X@COM's item label system, where ground items appear in gray, and soldier-held items in green. Weapons can also use color coding to differentiate their amount of remaining ammo.

Using the same system to label soldiers and visible aliens. Soldier labels can be color-coded by remaining health.

As a descendant of X@COM, Cogmind also shares this important feature, but by necessity has since expanded it even further. Particularly in Cogmind it's not uncommon to have a huge number of items visible at once across the map, or even within a small area, so what do we do in cases where there's a ridiculous number of labels all over the place?

In X@COM one of the first things I did (because it was easy :P) is allow item labels to overlap one another but randomly shuffle their z-order over time so that labels on the bottom would at least have a chance to be completely visible at some point while observing them. Not ideal, but worked okay.

Cogmind doesn't do that, but does color code labels to make it easier to focus on different item properties, or easier to find whatever the player might be searching for at the time. And even more useful for avoiding overlap, Cogmind allows labels to extend out from an object in any one of six different directions, ensuring that more of the labels are likely to be completely visible when multiple objects are near one another. Early on, labels also started to carry useful extra bits of info that don't take up much room, like an item's rating, and whether it's of a type the player has never used before (in case they'd like to collect it for their gallery).

The original 2017 demo for when Cogmind's item label system was switched over to coloration by integrity (the new default).

Labels were later updated to include even an item's current integrity if damaged.

None of this helps with the sheer number of labels, however, which can be significant, so we ideally need ways to manage that as well, ways I've gradually been adding over the years...


Automatic Item Filter Settings
To start tackling the excessive label issue, at least with a few simple tweaks as a start, back in 2018 with Beta 5 I added some adjustable filters to automatically exclude some items from being labeled.

So-called "mass labeling" of items (manually labeling all items at once) would become a two-stage process, where the first attempt would ignore all faulty items, broken items, heavily-damaged items, or those with low ratings relative to the current depth--basically those things which players are much less likely to be looking for at any given time. Attempting to label items again within a short duration would label everything, regardless of these filter settings. All such automatic filters can be tweaked in the options for players who want to adjust their behavior, or turn them off completely.

Demonstration of automatic filtering of item labels for those heavily-damaged by an explosion. Notice a quick subsequent call for labels will include them anyway, making it possible to have two levels of detail via the same command.

This doesn't go nearly far enough in terms of mitigating all of the excessive label situations, but it's a good start and definitely helpful.


Manual Item Category Filters
At the highest level there are five main categories of items, corresponding to the four types of slots items can be attached to, plus non-part items. And it's a fairly frequent need to find an item of a particular category, for example propulsion when you're literally on your "last legs" (or worse xD), or just any old power source when you've lost (or are about to lose) your last one and can foresee an impending energy crisis, or any number of other more nuanced situations.

As such, limiting the labels to only those items belonging to a particular category is an effective way to vastly reduce their number and make it easier to quickly see what nearby relevant options are available.

For this purpose I've more recently added the ability to cycle through the various categories while item labels are open, automatically reopening them and applying the new category.

Filtering item labels by category.

The cycling sequence switches between all items -> power sources -> propulsion -> utilities -> weapons -> non-part items (there are three different sets of key options for this interaction, each of which can be reversed as well). Not opening any labels for ten seconds resets the system back to "all items " again.

Automatic label filter settings are also applied in these modes, and can be overridden by calling labels a second time as usual (the demo above includes example of this, with the weapons and utilities).


Item Searching
Automated and/or simple solutions are nice, but sometimes we need to pull out... the big guns of the item-seeking world: full-featured search. For this I built a more powerful system capable of both filtering and searching through all known items across the entire map according to a range of customizable criteria.

Now this new dedicated interface is going to be overkill if just checking out a handful of items scattered around in the local area, but sometimes in Cogmind you might encounter a huge war, or maybe you're just a deadly and determined Cogmind rampaging across a map where there's no cleanup crew (or they simply can't keep up with you :P), and the map becomes littered with a mess of salvageable items.

Looking through a mess like this could be challenging even with a robust labeling system :P

Another example of wide-scale destruction from running battles in a late-game map, this one in ASCII.

There might be parts you want in there, but it can take a little while to sort through them. And although with experience the process gets faster, why not make it fast for everyone, and vastly increase the speed of doing so, by allowing the player to describe specifically what they want, or at least some aspect(s) of it.

Activating the new search feature opens a window over the right side of the HUD initially listing all known items:

Item search window showing a list of nearby items.

Items in the list are ordered by their current direct distance from your position, near to far, not taking into account walls or available paths (this is a more meaningful approach in Cogmind, since terrain destruction and making your own paths where helpful is common practice). Those items currently within Cogmind's FOV display their distance in blue, whereas those outside FOV display it in a shade of gray depending on distance. To the right of each item is its last known integrity, if available.

Once in this mode, simply typing enters text into the Search bar, where the most basic filter is text which must be found in the item name. For example "Imp" will list all items with the Imp. prefix, but technically also include "Impulse Thruster" (unless a period is added, of course, to search for "Imp.").

Searching for items via text.

Combine separate strings (requiring all of them to be present, but not consecutive) by using a comma. For example searching for for "par,char" would return any Particle Chargers. (Searches are not case sensitive.)

As usual, standard text editing commands are available, such as the Delete key, Arrows to move the cursor, and Ctrl-Backspace to erase the current text. The Enter key also simply resets the current search.

This interface is an easy way to look for very specific items, or quickly find the precise location of an item you remember to be somewhere on the map, because the list items are also interactive! Clicking on an item name (or using Ctrl-a~z) both centers the map view on it and highlights the shortest known path to reach that position:

Centering on items via the search interface, also highlighting the path to reach them.

Double-clicking (or repeating the keyboard command) will then also automatically move to that item.

Using the item search interface to path to a desired target.

But the item search feature is about more than just names--it's made much more powerful with support for specifying other required properties.

Special filters are available using the period prefix. For example ".power" will list all items that count as parts equippable to a power slot, or ".treads" will list all tread items. Generally only the first few letters are actually required to specify a particular filter, as indicated in the reference list below, but the full word is fine as well.

The current list of special filters for item searching, as found in the manual.

Multiple special filters can be combined with one another, as well as used alongside name filters if desired, again using a comma to delineate separate filters. For example "rifle,.th" would list any items with "rifle" in the name which are also capable of dealing thermal damage. Or ".hov,5,70%" would list all hover propulsion of at least rating 5 with a minimum of 70% current integrity.

Applying various filters to the item search list.

Under the search UI the extra space in the HUD is filled with a persistent list of helpful commands as a teaching tool and reminder:

Search UI help text.

For most cases I imagine the manual item category filters for mass labeling will generally be more useful since backtracking is not something a lot of builds want to do in Cogmind, and you're generally trying to browse a low to medium amount of nearby parts anyway, but there are definitely some cases where a more powerful search feature will come in handy, so I decided to add both :)

[Kyzrati]

The Map Ruler (and other overlay QoL)
[Cross-posted from the devblog here--follow link for better formatting and light-on-dark style.]

As the player's gateway to accessing the experience they're after when they want to play a game, building a fluid and comprehensive interface is essential. Many high-priority player needs should be apparent in the earliest stages of development, and help shape the entire foundation for an interface's design, but still other needs with lower priority may only gradually become more obvious over time.

If you find that players are spending extra time doing a certain task that could be facilitated by improvements to the UI, then hopefully those improvements are feasible and there's time/resources to add them! Honestly doing everything possible is unlikely--in a sufficiently complex game the list of possibilities seems almost endless, plus of course it has to be balanced against investing in other features.

I enjoy UI/UX work and recognize its importance, so naturally every release of Cogmind comes with its fair share of QoL features, and the huge upcoming release (Beta 11) is no different. In particular a collection of map overlay ideas has been building up in my notes over the years, so recently my tendency to work on related features in batches kicked in and several new options were born: a map ruler for measuring distances, a more powerful volley data visualizer, and robot FOV overlays...


Ruler Overlay
Roguelikes traditionally take place on a grid, and it's not uncommon to need to know the distance to a location for the purposes of movement, magic, guns, abilities, etc.

Given the discrete grid, this info is generally not that hard for experienced players to visually estimate, although in cases where knowing precise distances is important for optimal decision-making and one miscalculation could mean the difference between a tactic's success or failure, it's much more efficient and reassuring if the game can just calculate and display the desired details. Computers are good at calculation, after all.

Previous versions of Cogmind have already contained some ways to use the UI to confirm distances in certain cases, like the Volley window active in targeting mode that constantly updates its range readout to indicate the distance between Cogmind and the cursor location on the map.

Showing the the volley window rangefinder distance readout (top right, "R=).

However, since its introduction this has only ever actually worked with ranged volleys, so melee builds haven't been able to take advantage of it for this purpose.

Attached weapons and utilities also display their range circle over the map if hovered over with the mouse, or in the latter case many utilities also animate their AOE during their toggle animation, meaning these other features can be used to at least indirectly measure distances, although this is fiddly at best. That said, in the past I've definitely relied on this design to help quickly calculate distances, another sign that we need some kind of dedicated "ruler" feature :P

Another argument for a dedicated ruler is that all the existing methods of using other UI features to measure distances assume you want the distance from Cogmind's current position, when that may not be the case. In fact, many cases of wanting to count spaces arise from a desire to know the distance between two other arbitrary points. Like if I move to this particular coordinate will I be within range to shoot that other position? Or once I reach a certain location, how many more spaces is it (and therefore how long will it be) before I can cross over to another spot?

Enter the new ruler overlay:

No more guesstimating just how far it is between two cells!

As you can see above, the new ruler overlay shows the distance to every other point from wherever the cursor is positioned, suitable for any general distance calculation need. It's just an overlay, so of course equally compatible with keyboard mode:

Is that ASCII or a ruler? :)

It actually took a while to come up with the best way to visually represent this ruler from among the many options in terms of layout and colors. The underlying functionality itself is quite simple of course, just showing the distance to each cell from an origin, but many more hours were spent figuring out how to display the values in a readable and good-looking manner.

Double-digit ranges are too cramped to print out in full, resulting in a massive block of numbers, so I decided on the alternative of using double digits only for clear thresholds--multiples of ten, which makes the whole thing much easier to parse. I mean the final iteration is by necessity still a jumble of numbers, but at least pretty quick to read by comparison!

The earliest test version of the ruler overlay when it still retained full digit values. I also tried variations of coloring and checkering, but it only made things worse :P

 

Another early concept where I'd decided on the threshold approach, but still had yet to include unknown cells in the measurements. One player suggested that could come handy for the occasional need to measure across partially unexplored areas as well, so I added that as seen earlier.

Control-wise, the ruler overlay is toggled via Shift-Alt-x (mouse toggle still to come), and since it's not modal or anything, just an overlay, technically you can continue playing while it's active, although naturally it covers up a lot of important info!

The ruler is nice for planning, but playing while it's active is not officially recommended :P

Do it for the cool (or crazy!) factor?


Terrain Destructibility Visualization
A common question while playing is "can I destroy that piece of terrain?", be it a wall, machine, or some other prop. This usually involves checking the armor and resistances against your current (potentially modified) volley damage, and although it usually doesn't take all that long to figure out the answer, crunching data is again what computers are good at, so now I've mostly automated that process with a single button :D

This feature is integrated into the volley range visualizer, which has always been useful for showing the relative range(s) of active weapons, but now also highlights in red the foreground of visible destructible terrain depending on whether or not the current volley is capable of destroying it.

Even better, it also checks the player's inactive weapons and searches through their inventory for other weapons that might still be able to destroy terrain and in that case gives it a different color glow (yellow).

Here you can see it in action, where the Assault Rifle isn't capable of taking any of the machines, the Beamcaster can only destroy one, and none can destroy the Fabricator (thus it always remains blue):

Terrain destructibility visualization demo.

The calculations generally take into account all applicable sources of damage modification, e.g. active utilities, current momentum, resistances, etc. The appearance of terrain the player doesn't likely have the means to destroy at the moment remains unchanged. Note that even in such a case, it may sometimes still be possible to destroy the terrain using other means, since the system does not take into account inactive utilities or those in inventory, special weapons, the environment, or other means to creatively destroy terrain, but it is at least a useful way to quickly confirm that you already do have the capability.


FOV Overlay
Warning: Although I'll be describing this feature here and even showing demos, it may not actually end up in the final public release of the game, or at least not quite in this form :P

Player-mob spotting is usually not perfectly reciprocal in roguelikes, as in enemies the player can see may not simultaneously be aware of the player, and vice versa. This provides room for additional relevant abilities and/or tactics (stealth/speed/sneak attacks/sniping/etc), as well as allowing for some level of risk taking (might I be able to slip by these enemies undetected?). However, very few roguelikes will actually display on the map those locations where actors can spot enemies (if doing so even makes sense given the mechanics and variable nature of being spotted).

In Cogmind there is an indicator for robots that spot the player, but before that pops up you can't always be sure whether moving to a given location is close enough to be spotted in the first place, especially where obstacles like machines come into play since they can be used to partially obscure line of sight. The fact that robots can only fully spot you on their own turn further adds to the uncertainty, since quickly passing through their FOV might even go undetected.

Over the years there have been a few requests to allow players in Cogmind to see the FOV of enemies, but for a number of reasons I've always avoided adding this feature.

The earliest reason is the significant processing cost of calculating a proper FOV for what is potentially a lot of nearby robots, and it's for that reason that when I converted X@COM to create the first version of Cogmind back in 2012 I decided to rewrite the entity sight handling to not actually use real FOVs and instead use a method that would scale better for the huge number of robots in Cogmind, specifically just calculating LOS between important points as necessary. This was far more efficient, and still is, for more or less the same results.

Nonetheless, for a temporary FOV overlay display used at most in short bursts and/or with lower robot counts it'd probably be doable these days, so I recently wanted to play around with the idea since it was still on my ever-growing List.

In short, Shift-Alt-v toggles robot FOV overlays, allowing you to identify every cell that each enemy can see. All the FOVs are combined unless examining a single robot, in which case it only highlights areas visible to that robot in particular:

Keeping an eye on the FOV of several patrolling bots to avoid detection.

While we're at it, there's no reason to limit it to just enemies...

Another FOV overlay demo in ASCII+keyboard mode, also tabbing around to different robots including even non-hostile bots (neutral FOVs appear gray, and ally FOVs appear blue).

Object popup labels are not active in this mode, since the main intent is to observe the area covered by FOV, and having labels pop up interferes with that goal.

The visualizer also takes into account active Cloaking Devices, using darker shading to represent the FOV reduction effect.

The overlay shows how much closer you can get to that Watcher due to the cloak effect.

So for the most part the implementation worked out okay. I did also have to put some time into optimizing to bring it within acceptable bounds because it could really tank the FPS, and while further optimizations would be possible, they'd also require a large amount of work compared to what was done already. In any case, the problems I have with this feature are actually now somewhat less technical and more on the design side...

My biggest concern is that as a freely usable overlay this has the potential to really change the feel of the game in a lot of situations. Where without this information you're kinda guessing at the edges of enemy FOV (especially due to the effects of machine obstruction) and maybe have to deal with the consequences of a surprise spot, always knowing exactly what visible enemies can see takes some of the suspense out of those moments.

A smaller concern is that when people can see FOV for all bots, they might not understand or like some of the results and report them as bugs, when it's simply nuances behind how the system is designed.

Then there are the logic issues. Unless I put a huge amount of time (and program memory) into building a secondary world data and FOV system around what the player remembers rather than the actual map layout, the current approach can sometimes indirectly reveal information you shouldn't actually know (e.g. missing walls, open doors, and various other situations).

One way to circumvent the logic issues entirely, and also somewhat reduce access to this feature, would be to make the FOV overlay only available by attaching a dedicated part, or perhaps a new RIF ability, which would quite in-theme.

That said, I wonder how necessary that even is given that we already do have the Triangulator utility which... no one really likes xD (in fact, the community makes fun of it all the time!)

One of a Triangulator's several functions: See how close enemies are to spotting Cogmind.

Granted, an overlay is much easier to use and less situational than requiring a part that vies with other utilities for a slot, and also more broadly useful since it allows for visualizing the greater FOV rather than just LOS with Cogmind, meaning the ability to see what bots can spot other bots, and also for example plan a possible route past enemies by seeing the limits of their vision in other directions.

Having complete FOV data might indeed make for some interesting precise stealth planning, but in my experience you can get a lot of those moments just fine without it, and I do feel something is lost by showing everything. Unlike the ruler and terrain destructibility, this is not pure QoL--it can actually have a significant effect on gameplay and the whole feel of the game.

We've done pretty well with Cogmind's existing system of hidden FOV for years, so I think this feature might end up getting canned, but having implemented it for testing anyway, I did recently include it in experimental patron builds to try it out for fun and science.

[Kyzrati]

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

Stealth plays a role in most Cogmind runs, with the degree varying all the way from "maybe I'll dodge this one patrol until I'm in a better position to siege up" to "I am ninja." To best support a variety of play styles in that regard, we need a range of systems and utilities built for information warfare, of which stealth is one aspect.

Many years ago prior to Cogmind's Alpha 1 release I wrote about related topics like robot sensors, visual sensors, terrain scanners, structural scanners, hacking, intel and others. Now it's time for even more!

I haven't yet covered this here on the blog, but Cogmind's next update (Beta 11) is taking years of play experience, feedback, and observations into consideration for a comprehensive review of the many items and their stats with an eye towards readjusting a variety of aspects to create an even more balanced and fun game full of interesting decisions and trade offs. A number of values need to be reevaluated in the light of all the changes and (especially) tons of additions that have been made in the years since 2012.

We'll be getting to other related topics later, but for now as a backdrop to this article I'll just say that one side effect of a particularly significant change already confirmed is that player builds will on average have a greater number of utility slots to play with! This shift suggests we're going to also want an even greater variety of useful and generally available utilities, otherwise there's a decent risk that more builds will start to look alike. Plus of course it's nice to simply have more options when coming up with builds, tactics, and strategies :)

New Structural Scanners... Trap Scanners... Machine Analyzers... Bring on the infowar!


Sensor Ranges
We begin this story like every good story, with a nerf.

The longest-range sensors, which have allowed you to detect robots up to 30 cells away, are being reduced to a range of 20. This is a sizeable reduction, establishing a trend we can trace back to the 7DRL in 2012.

For the 7DRL utility stats I wanted meaningful steps you could really feel as you upgraded to new parts, and the original set of sensor array ranges stretched from the weakest one at only 5 (!) to the best at 50 (!).  Throughout Alpha and Beta the set of ranges has gradually tightened to make high-end sensors less OP and low-end sensors actually useful sometimes, landing us with a less extreme improvement of 14 to 20 range over the course of a run in Beta 11.

Diagram comparing minimum and maximum sensor array ranges at points across Cogmind's development (open for full size).

So technically we have a nerf at the high end and several buffs at the low end, though at the same time these changes also give Watchers a bit of extra range within which they can jam Cogmind's sensors (which they do with their own array based on its range), therefore increasing the challenge when they're nearby.

Particularly with sensors I think it's important to shift away from the 7DRL design of noticeable steps and instead ensure that 1) all of them are at least helpful to some degree, and 2) losing a really good one does not feel quite so bad or seriously cripple a run (Watchers can be salvaged for their decent arrays, which are no longer much worse than the best option available). This is a better approach for what can be such an integral component of many builds and strategies.

20 range is still quite good, allowing one to know about robots in all the adjacent corridors and rooms (or even further depending on the layout), and setting the maximum benefit to that distance also does a good job of balancing sensor arrays against visual sensors to make the latter even more interesting in straightaways since the best of them can increase sight range to 24, so slightly further out (alongside their other unique properties).

Now where did that shot come from?! (art by the great roguelike concept artist Zyalin!)

Structural Scanner
The Structural Scanner is probably the most changed item across Cogmind's development history, having been mentioned in the version changelogs 11 times already... but that isn't even its final form!

The first iteration, available from Alpha 1, had one function and a simple description: "Scans all visible walls for signs of hidden doorways." By Alpha 14 that became:

Scans all visible walls for signs of hidden doorways, determines whether an explosive machine has been destabilized and how long until detonation, and provides a 2% chance to detect each hidden trap within field of view (the latter is checked each turn on a per-trap basis, and stacks). Also highlights areas that will soon cave in due to instability even without further stimulation.

The reason for the evolution was that it was originally of questionable usefulness as far as taking up a utility slot goes (so few players would ever use it), that and I wanted to add a way to obtain other bits of info but didn't have another suitable part to put those on (which themselves would be even less desirable).

Still some people even laughed at Structural Scanners as useless, but at the same time at least a portion of players reported they found them compatible with their build style. To me this is the best place for a part's balance to reside, right in that sweet spot where players are divided over its usefulness. In that sense I was satisfied with the state of the Structural Scanner, but it's changing yet again!

For one, reducing its variety of features would bring it closer to my original vision for Cogmind, that each part only has a single function, while a build is the composite of those functions, rather than complicating things by also giving multiple functions to individual parts. But more pertinent to current developments, an increase in free utility slots on many builds plus the desire to add more types of infowar utilities means we can attempt to focus the Structural Scanner on a smaller but still useful feature set while splitting off some of its functionality into other new parts.

As per the description above, over time the Structural Scanner gained abilities related to terrain, traps, and machines, and the goal here is to reduce that to terrain only. The new description (emphasis added):

Scans all visible walls to analyze the structure behind them and identify hidden doorways. Also highlights areas that will soon cave in due to instability even without further stimulation.

Basically this modifies the FOV algorithm to also identify any unseen cells adjacent to visible solid cells, so basically "seeing" one layer of terrain just behind all doors, walls, and earth.

New Structural Scanner behavior revealing terrain behind solid walls.

This is similar to Terrain Scanners, but without any additional depth and therefore entirely focused on finding adjacent rooms and hidden corridors, which is a fairly common use of Terrain Scanners (or poking/shooting walls :P), seeking out ways to make alternate paths through the map layout for more efficient exploration, to circumvent hostiles, or for some other purpose.

However, Structural Scanners operate instantly whenever FOV is updated, unlike Terrain Scanners which take time to gather their data, so the two types of parts each have their benefits and drawbacks. As such there will be builds and players who prefer one over the other depending on their strategy and other factors. Perfect :D


Trap Scanner
The first new utility to poach one of the Structural Scanner abilities is the Trap Scanner, which as designed so far does just what one might expect: detect traps--nothing more, nothing less.

As a part dedicated to a singular function it naturally needs to be more effective to make it worth the occupied utility slot, so the trap detection chance is increased to doubled to 4%, and unlike the Structural Scanner there are actually multiple tiers beyond the base model, including at best a 20% detection rate, which is almost guaranteed to pretty quickly reveal traps that remain in view, especially considering that a lot of traps are found in groups and therefore if you see one there are likely more nearby to be wary of. Note that the 20% variant is an outlier, and the more easily acquired ones provide a 4-8% chance, although even an 8% chance is fairly reliable.

Activating a Trap Scanner. Of course utilities need to have their activation animated ;)

Machine Analyzer
The Trap Scanner didn't take long to implement (aside from having to put together a new animation); not so with the Machine Analyzer which took ages...

Of course it was quick to transfer over the Structural Scanner's ability to detect and report on machine destabilization:

Now it's the Machine Analyzer that can tell whether an explosive machine has been destabilized and when it will blow.

But that's not new, nor is it sufficient to justify spending a slot on it...

What is new is using a utility to discover nearby machines and those elsewhere on the map! A Machine Analyzer reveals the entirety of a machine as soon as you spot any piece of it, and more importantly, reveals others machine linked to that one--this means both machines in the local area as well as one or more other groups of machines elsewhere on the map, probably but not necessarily nearby.

In Cogmind, knowing machine locations provides a number of advantages:

• Placement of machines suggests where rooms or open areas are located
• Interactive machines generally come with useful features, and the machine group linking system specifically enables you to follow them like bread crumbs--locate one Terminal and another likely nearby Terminal is revealed, giving another near-term goal
• Find nearby explosive machines that could be used for tactical purposes

Again similar information can also be obtained via terrain scanning, but:

• Good terrain scanning requires two utility slots
• Scanning takes time, whereas spotting a machine and analyzing it is instantaneous
• Can also potentially learn about machines that are much further away than even scanning is likely to find

On the reverse side, some reasons to prefer actual terrain scanning over machine analysis:

• Machine Analyzers aren't as consistently reliable for info--they only work in the main complex, and won't help in areas that happen to have few or no machines
• They only dig up machine info rather than other terrain layout knowledge, which comes in handy in other ways

In the end some players are no doubt going to really like this utility.

Exploring with an active Machine Analyzer.

Machine discoveries are also reported to the log, by default only listing any new interactive machines because otherwise the list is simply too long and updating too frequent (but I did add an advanced config option to enable the full list of all machines if someone really wants it :P).

Machine Groups
Clearly crucial to the whole idea of analyzing machine networks is exactly how are these links formed?

Figuring out the best approach was quite challenging, since it would require an algorithm to derive the links from the existing map layout and machine positioning, and on the outside I wanted it to make some sense as well as be useful, but not outright too good. I wrote pages and pages of notes on the possibilities before finally coming up with a workable concept.

First of all, note that machine groups technically have no meaningful connection to one another for the purposes of other mechanics or systems--this is purely for intel purposes, simulating behind-the-scenes networks presumed to exist, but here only as a form of data.

The process to form and connect groups:

• All machines in a single room or hall belong to the same group, and any interactive machine in a corridor junction or embedded in a wall forms its own group. (For an understanding of concepts like "room" and "hall" as they relate machine placement, years ago I wrote about them in the context of procedural generation.) The group system (and therefore extent of the Machine Analyzer's usefulness) does not extend to prefab machines or those local systems which by the lore are isolated from other machine systems (e.g. door terminals).
• Randomly order all machine groups.
• Go through each group establishing link(s) to others, where if it's a group containing an interactive machine* it automatically links to the nearest interactive group of the same type that it's not already linked to, and regardless of whether the group is already linked with another, each group also always links to the nearest other machine group it's not already connected to. This guarantees at least some knowledge of nearby machines, maybe more. (*Based on the rules used to generate Cogmind maps, it's impossible for a group formed using the Step 1 above to contain more than one interactive machine, if any.)

All links are bidirectional, meaning that seeing a group at either end of a given link reveals the corresponding group at the other end.

Partially destroyed groups are revealed as normal, unless a group's "representative machine" is damaged. The so-called representative machine is always the group's interactive machine if it has one (otherwise it's chosen at random) and also serves as the machine used to visually link to other groups on the map.

Machine groups are seed dependent, so consistent in that regard.

Before adding the real utility functionality, I first needed to build the groups and then a debugging visualizer to make sure they were actually working as intended. Visualizer was a good idea, because yeah there were bugs and it wasn't always easy to figure out what was up xD

One of the early debug views for color coding different machine groups, which are clearly not working very well here for some reason...

Eventually I got it working and the visualizer could also show the links themselves, which connect representative machines via direct lines if aligned along an axis, or by turning one corner.

Debug view of machine group links and group IDs which came in handy for tracking down elusive bugs.

Animation
Once that was working and the part itself was linked into this system, it was time to animate things.

You've already seen the machine-and-link reveal animation in the earlier demo above, but it's kinda fun to see where it started out. The premise: I've never really done any super multicolored effects in Cogmind, and it seemed like a good opportunity to try that out here, especially since I think it can go well with the concept of "calculating" something (further emphasized by the accompanying sfx).

Shifting monochrome shades would work, too, but if subtle it could incorporate more colors and perhaps be more fun for it...

It did not start out subtle :P. The effect here is obviously way too over the top and distracting to be included in this form--at the time I was just making sure the HSV noise generation technique would work, and do the necessary tweaking later.

Later I changed the rate of the color shifting and darkened it appropriately so it wouldn't be so obnoxious while moving around repeatedly revealing machines.

The Machine Analyzer also has an animated toggle, which simply does the usual reveal animation for any and all groups connected to currently visible machines.

More cool Beta 11 features to come!

[Kyzrati]

Design Overhaul 1: Capping Inventory
[Cross-posted from the devblog here--follow link for better formatting and light-on-dark style.]

Last time here on the blog we covered sensor changes and other new related utilities coming to Cogmind's next major update. At the time I wrote:

Cogmind's next update (Beta 11) is taking years of play experience, feedback, and observations into consideration for a comprehensive review of the many items and their stats with an eye towards readjusting a variety of aspects to create an even more balanced and fun game full of interesting decisions and trade offs. A number of values need to be reevaluated in the light of all the changes and (especially) tons of additions that have been made in the years since 2012.

While many of the early design decisions established a good foundation that in a general sense has withstood the test of time by both attracting and holding the interest of many long-time players, and along the way the integration of new mechanics and content expansions certainly resulted in a number of retroactive adjustments to prior work to keep things more or less balanced, there's never been a much wider review of the kind we've wanted to do since like... five years ago xD

Especially with regard to less vital parts of the game, there's been an understanding in the community that one day they could one day all be addressed together as part of the "Great Utility Update" (so called because Cogmind's largest category of items and many of those frequently discussed in balance/usefulness terms happen to be utilities), so lots of these kinds of things have piled up over the years.

With Cogmind basically done and preparing to embark on expansions definitely outside the realm of what was originally planned (see the 2020 ARG :P), Beta 11 is finally the time to do this big review.

But we're not starting with the little stuff! On the contrary, if there are any significant balance changes to be made, those need to happen first, and it just so happens that some of these are indeed coming down the pipeline, somewhat unexpectedly, even...


Capping Inventory Capacity
One of the more fundamental design levers when it comes to utilities is whether or not their effect stacks when attaching multiple of the same type. Storage Units have always been stackable, meaning players who want to carry around even more spare parts (and don't mind being overweight, because storage is heavy!) could just load up on extra Storage Units and fill them with salvage and looted parts. Among the better players, over time this feature clearly led to rampant inventory inflation, and we saw more and more superheavy storage-laden builds working their way through most of the game like that until they'd shed most or all of their storage and use the contents to assemble their ultimate build for the final stretch/extended game. Basically the safest play tended to be maximize inventory size for as long as possible, whatever players thought they could get away with depending on their build goals and how dangerous their chosen route might be along the way.

Zyalin's depiction of a storage-laden Cogmind build (in particular a bothacking RIF build, a topic we'll get to later).

This whole approach is actually kinda anti-Cogmind, circumventing much of the "dynamically adapt to circumstances" aspect while being a significant drag on the build effectiveness and the experience in general (due to generally slower builds and more utility slots allocated to increasing storage capacity because spare parts are so valuable compared to using the slot for one other active part).

Either avoid most confrontations, or suffer from higher than average part attrition due to reduced effectiveness both in and out of combat while constantly cycling through replacement parts instead.

Other drawbacks of massive inventory growth start to appear as their size expands further beyond what the interface was designed to handle. The original GUI layout and functionality assumed that builds would generally have one or two pages of inventory content (or at most three), as it can only display up to 12 parts at once and allows interaction with 10 of them (equivalent to the 1~0 number keys). Then of course there are the players frequently running around with 5~6 pages of inventory (10 has happened before, too xD) and it becomes cumbersome to use on top of the weaker build resulting from having so many utility slots devoted to all those Storage Units.

Insane inventory capacity at work in the wild. This particular streamer's late-game build had a total of 18 utility slots at the time, 10 of which were occupied by storage units xD (not to mention the focus on evolving utility slots meant having evolved nothing else).

Players being inventive and challenging themselves to work their way outside the bounds of a game's design can be interesting, but less so if it's a very easily triggered compulsive behavior like hoarding.

That's not to say the goal here is to completely remove the potential for superheavy hauler builds--even in Beta 11 fairly large inventories will still be possible, but some kind of limitations would really help here and I believe 1) we do still need to tweak the cost-benefit equation when it comes to carrying an almost endless supply of parts, and 2) this can be done in a way that also keeps the game more fun by freeing up more utility slots for other purposes.

At the same time, I'm grateful for the period over which players did put a lot of pressure on the inventory management interface because it gave us QoL enhancements like swap functionality :)

Demonstrating two of the many ways to swap parts in Cogmind.

So with a general consensus in the community that inventory capacities were getting out of hand, naturally the next step is to figure out what to do about it...


<no_stack> Storage Units
In the Balance Overhaul discussion thread on the forums, zxc repeated his outlandish suggestion to go with <no_stack> storage (referring to the in-game tag used to mark utilities that cannot be stacked). One might think that too extreme a change, and I was definitely in this camp from the beginning. For one I prefer to avoid no_stack whenever possible since it's a very hard limitation, and that can mean somewhat less flexibility in terms of build variety, especially worrisome in this case due to how central the storage capacity element is to a build--to me the the ability to mix and match different types of Storage Units (or multiples of a certain type) to get just the right balance of mass and capacity seemed really important. But it can also be easy to overlook the fact that limitations in one area open up more opportunities elsewhere, particularly in this case as we get even more utility options (like the latest infowar set!).

A range of less extreme alternatives were proposed by other players, but I decided we could try some truly experimental patron builds featuring behaviors which might not actually make it into the official release, and if we're going experimental, might as well go extreme to begin with and see how that feels before possibly dialing it back or examining other options in more detail.


Numbers
Taken in isolation, simply slapping no_stack behavior onto Storage Units does indeed seem way too radical and likely to both weaken many builds, but compensating with much greater capacity from a single unit as well as adding extra types to choose from resolves these issues nicely.

The main question here is of course what kind of inventory sizes are we targeting?

Somewhere around an inventory size of 20~25 seems reasonable for the average combat build--it's a size I'm familiar with since I often go with that, and others agreed, so let's let the Large and High-capacity units straddle that range and extrapolate from there. Altogether this results in only about two pages of inventory items, which is very reasonable to work with, and remember that concentrating this much storage into a single slot also frees up one or two extra utility slots for other uses, helping those existing inventory slots go the extra mile since increased build effectiveness somewhat reduces the need for spares.

Of course some builds might still like to carry more than that, which is fine, so under no_stack rules that would require adding some more options at the higher end which come with pretty hefty costs, namely both significantly higher mass and an additional slot.

After testing and tweaking, it turns out no_stack storage is a great improvement overall, and the final set is as follows:

Beta 11 Storage Units reworked and expanded for compatibility with no_stack behavior.

As you can see there the naming system was shifted a bit, allowing all existing robot builds to continue using the same type of storage as before, good for both loadout familiarity as well as retaining names that feel more in line with each robot's purpose as originally designed (mainly the non-combat varieties).

Numberwise, with the main series mass doubles for each linear increase in capacity, which is the same style of progression we had before except instead of focusing on +2 capacity per jump, the new number is +5. And because most builds will attach some type of Storage Unit, but Cogmind's base inventory size has always been 4, to avoid creating a bunch of awkward inventory sizes like 9, 14, 19, 24 and so on, the base inventory size (the amount of storage with no additional units attached) was increased to 5. This makes any related mental calculations a bit easier.

Overall these changes to mean player power in the early- and mid-game are somewhat higher, but this is fine because it means we can more safely add more challenges there to compensate ;)

Cargo Storage Unit art.

The most common question among players with regard to this type of inventory cap is "what about full RIF builds?!" (maybe sometimes with more exclamation marks? :P) Since we could always adjust the RIF system if necessary, this wasn't even a concern for me going into the no_stack experiment--wait and see, right? That's just one secondary system, after all, whereas the goal here was to first modify a core gameplay element. It's an inevitable question, though, seeing as some RIF builds focus on hoarding a huge supply of spare couplers as their main source of power, and using them in smaller numbers doesn't require the support of numerous other parts so there's plenty of room for storage utilities.

Once no_stack was implemented I did a full RIF run to test it out, as well as listened to feedback from patrons doing the same, and surprisingly even without any other changes it was actually a better experience! Despite a reduction in total inventory capacity, without the excessive amount of storage myself and others might choose to attach, there was plenty more room for active Relay Couplers, couplers which 1) don't need to occupy inventory space anyway and 2) can help deal with threats (especially when combined with RIF abilities, many of which rely on having a relevant active coupler in the first place). Plus of course optional room for other non-coupler parts, too, such as infowar, armor, or whatever you need...

More active couplers=more fun :D

The full run is archived on YouTube:





(Also remember this is just relevant to "full RIF" builds, whereas there are alternate RIF strategies that use only one or two types of couplers, or even none.)

Players will notice that the Lightpack unique item is not included in the storage chart above; this is because it will be balanced differently given its special origin. And there is also room for additional unique storage types, in fact even more so given that they're no longer stackable, since the knowledge that they must be used in isolation rather than potentially in combination with other Storage Units makes more interesting designs possible.

As for acquisition, the new Huge type can be found in stockpiles, and while the new Cargo Storage Units are unlikely to be found just lying around, they can still be fabricated from schematics, or taken from from a new type of robot and dispatch coming to Beta 11.

[Beastboy]

My God, 8 years in development

How are you holding up?

[Kyzrati]

My God, 8 years in development

How are you holding up?

Hehe, same as always. Was going to be a "short" 1~2-year project, and where it went from there would depend on whether enough people continued supporting it, but there have been plenty out there so... still going

This has been my full-time job since 2013.

[Beastboy]

My God, 8 years in development

How are you holding up?

Hehe, same as always. Was going to be a "short" 1~2-year project, and where it went from there would depend on whether enough people continued supporting it, but there have been plenty out there so... still going

This has been my full-time job since 2013.

8 year in dev + full time on it? How did you got the funds for such a miracle?