next »

[Kyzrati]

Roguelike Level Design Addendum: Static or Procedural?
[Cross-posted from the devblog here--follow link for better formatting and light-on-dark style.]

Having walked through both static and procedural map design in the previous posts, this is a good opportunity to examine the qualities and value of each. Why use one over the other? Why not use both?

Roguelikes tend to be associated with procedurally generated maps, so much so that we see mainstream non-roguelike games having the "roguelike" label applied purely for that reason alone (despite possessing no other roguelike qualities...). That said, not all maps in a true roguelike need to be procedural, either, nor is that extreme necessarily desirable. Static maps can serve roguelikes well, and most sufficiently large roguelikes contain a mixture of the two.

Not every roguelike needs both static and procedural maps, but I'd argue that both are good for roguelikes, and properly mixing the two can combine their strengths into a better experience.

With procgen we get the first advantage that generally comes to mind: increased replayability. More specifically, the player lacks perfect knowledge on which to base strategic and tactical decisions, leading to variable challenges. Roguelike players also enjoy discovering interesting and unexpected results, the likelihood of which increases with the number of systems interacting with one another.

Static maps offer a much wider variety of advantages:

• They help with world building and anchor the story/lore (a topic I covered in my series on Weaving Narratives into Procedural Worlds), while also allowing for specific hand-crafted challenges.
• Being familiar with certain areas of the world means players can plan for them. Certainly a more general form of planning can be done for procgen maps through knowledge of the range of possibilities, but sometimes having more concrete goals at various points makes for interesting experiences--knowing those goals or checkpoints in advance also builds anticipation!
• In general, static maps offer a change of pace, and like good books, movies, and other forms of entertainment, varying the pace makes the content more engaging when properly spaced out. Navigating back and forth between areas of the known and unknown is also less stressful, allowing certain parts of the mind to rest for a bit.
• Outside the single-player experience, static content also has value for the community at large, giving players more concrete landmarks to discuss. They can also more easily share some of the memorable experiences related to static content that others are familiar with.

That's a decent list!

An important point to make here is that the distinction is not absolute, either. Even individual maps do not have to belong solely to one category or the other, it's more of a spectrum. Close to one end we have static maps with bits of procedural content, and near the other we have procedural maps including pieces of static content, either fully static by location as well, or perhaps simply "guaranteed to be on that map" but not necessarily found in the same location each time.

Demo of the static-procedural composition spectrum using several Cogmind maps as examples, from fully static to fully procedural. Larger areas are more suited to procgen

I went through Cogmind's map types and classified each according to which it most closely identifies as, and found a pretty even distribution, slightly favoring mixed maps.

Static-procgen distribution of Cogmind's maps.

Note the above distribution is based on map types rather than actual map count, in which case the ratio of procedural and mixed locations in the world would both be somewhat higher than shown, each at least twice the number of static maps, rather than as close as they are now.

In any case, Cogmind has benefited greatly from having a wide variety of maps, and I highly recommend taking advantage of both approaches, considering which is more appropriate for the goals you have in a given area and the world as a whole.

For patrons, there were more comments and discussion of this article over on Patreon here.

[Kyzrati]

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

I've always enjoyed turn-based games, giving you unlimited time to consider and react to changing situations (even if you don't always take advantage of that opportunity and instead bumble into mistakes far faster than necessary). Turn-based mechanics are especially apt in traditional roguelikes, where the RNG typically plays a starring role and therefore said changing situations can be unpredictable, but exactly what can be accomplished in the space of one turn, and what a turn really represents, varies from game to game.

At the most basic level, we have turn mechanics which are simply [player acts] -> [enemies act], all in sequence, one action per turn, and then the queue starts over again, [player acts] -> [enemies act], and so on. Then some games might add longer actions, though still very clearly based on "whole turns," like performing a longer action forces the player to skip their next turn. Or the more complex variety: An action requires first waiting for two consecutive turns without interruption (by attacks, for example) in order to be carried out.

But sometimes even more granularity is desirable for content or balance purposes. Like what about actions that take one-third of a turn? Or 2.5 turns? Roguelikes of significant scope are more likely to need a greater level of granularity in order to accommodate more content in a balanced manner. (It's not absolutely required, of course, but it's helpful in the long run :D)

This granularity can be a double edged sword, though, since there's always the chance that as a time system grows increasingly nuanced, the more oddities arise and the more opaque or confusing (or at least challenging) it might become, both to build around and for players to master. As with any game mechanic the opaqueness is at least generally solvable through a better interface and feedback, if necessary, but it's worth noting that systems with higher granularity will also be much less predictable, so hopefully precise turn predictability isn't an important factor in a roguelike that also features extreme granularity!


Cogmind Time, 2012~2018
Cogmind 7DRL, written in 2012, was my second roguelike project, based mostly on the X@COM source code. Well, X@COM being a reimagining of the original UFO Defense, it was a squad-based game with explicit Time Units which could be used to perform actions by each soldier until declaring the end of the turn and allowing enemies to act. There was no single player character, and most turns by each individual involved a sequence of multiple actions limited by their stats and what kinds of actions they wanted to perform.

Migrating from this sort of system to a decidedly more roguelike time system would be a pretty big leap, and being a 7DRL I wasn't going to have a ton of time to experiment with what does and doesn't work, so I searched around and decided to adopt the system demonstrated in this useful Rogue Basin article.

What is a "roguelike" time system? I think the most basic assumption is that it consists of a single actor performing a single action at a time, and after their action it's at least possible, if not likely, that other actors will get to perform their own action. Of course there are many potential variations, and definitions don't mean much in the bigger picture, but X-Com's TU-based turns would not be considered very roguelike, which generally boil down to [one command] -> [one action] -> [implicitly done].

I picked the system in the linked article because it seemed easy enough, and at the time I wasn't really familiar with how roguelike time works under the hood anyway. The system is not a simple queue, and has some interesting characteristics, but I'll get into those details later when I cover how they eventually became a problem and I recently decided to replace it!

For the next bit of discussion, all you need to know is that each "turn" is subdivided into 100 "time units." Actors can carry out actions that might require only a fraction of a turn (< 100 units) or multiple turns (e.g. >= 200 units). While sometimes more difficult for players to wrap their heads around at first, and also sometimes difficult to accurately predict even once it's understood, I believe its flexibility outweighs those potential negatives.


Action Costs
The length of an action is extremely variable in Cogmind. Most actions require a static amount of time, but the two most common actions, moving and attacking, are calculated based on multiple factors, and therefore change throughout the game depending on your status.

To keep things simple, the majority of actions take either one turn, half a turn, or 1.5 turns:

Cost	Action
100	Pick up Item
100	Attach Item
150	Attach from Ground
50	Detach Item
50	Drop Item
150	Swap Item (Inventory <-> Equipment)
100	Misc. Actions (Ram / Rewire / Escape Stasis…)

And that's it--Cogmind doesn't actually have a wide variety of unique action types, and for simplicity sake a lot of miscellaneous actions require precisely one turn. But with one turn the equivalent of 100 time units, there's a lot of leeway for fine-grained requirements when it comes to the most common actions: moving and attacking.

Moving even a single space involves a potentially huge range of time, quite different from the average roguelike. How long it takes to move is highly dependent on the form of propulsion:

Cost	Propulsion
40	Flight
60	Hover
80	Wheels
120	Legs
160	Treads

Those are simply base costs, though, which might vary somewhat with unique items, and which in the case of flight and hover can be further modified by using multiple items at once. For example using three flight units will be faster than using two.

So in a simple scenario, a flying actor (robot) can move three times for every one move of a legged robot, or four times compared to a treaded robot. And that's only given the base costs! Assuming a loadout of five flight units, each of which gives a -3 cost modifier after the first, the movement cost is 40 + [-3 x 4]=28, or 3.57 moves per turn, or the equivalent of 5.7 moves for each treaded move. For Cogmind's first several years the additional flight unit cost modifier was -5, but for balance purposes this was adjusted down in 2016 as it was a little too easy to reach very high speeds.

The highest speed currently possible is 20 moves per turn, though that speed is much more difficult to reach than it was in the early days. Not to downplay the effects of even "average" fast speeds once compounding is taken into account--a meager three-times speed advantage means that for 10 moves by a pursuer you've traveled 30 spaces, which is usually plenty to reach safety.

In the opposite direction, movement is slowed if overweight (an effect that matters more for the normally faster forms of movement), so it's quite difficult to escape a swarm of flying robots tailing you if you're a mass of components hopping around on one leg.

As you can see, flee/chase situations can play out very differently depending on the relative speeds of those involved, but it doesn't lead to boring play; instead it's possible due to the world being an active ecosystem spread across huge maps rather than than based on individuals or groups of monsters waiting within a small area. Escaping danger in one area can still lead straight into danger from another.

Overall, this approach to movement leads to interesting scenarios, like being stuck in an overwhelming firefight without any propulsion (or weak propulsion) and forced to drop things and run in order to survive, or flying so fast that almost nothing can catch you (so long as your sensors help keep you from running into more trouble ahead), or so fast they can't even see you (since robots only register targets during their own turn, by which time you could be long gone!).

Because movement speed is an important factor in turn-to-turn play, it is displayed on the HUD at all times, though in one of two forms. For beginners it's shown as a percent of base speed, so 100% when one move=one turn, 140% when 1.4 moves=one turn, etc. This is to keep it more intuitive at first, rather than having new players misunderstand that in terms of time units, technically lower "speed" numbers are faster. Players who activate the more advanced "Tactical HUD" mode in the options see instead the actual current movement cost itself (thus the meaning is reversed, higher is slower).

Speed display, percent mode

Speed display, cost mode

Warning: Dangerously slow. When beginning a new sequence of movement while quite slow (one-third normal move speed or slower), confirmation is required in case the player simply forgot to activate/attach a propulsion unit, because the consequences can devastating if you take one slow move while under fire!

Attacking has smaller time cost scaling than movement, but is interesting in that its costs are greater than those of other actions, especially movement. The base cost to fire a single weapon is 200 (two turns!), meaning defenders can more easily escape after coming under attack (if they want to). This effect is even more apparent once the time cost of an entire "volley" is taken into account. Weapons are often fired in groups (called volleys), and the total cost of firing the entire group is applied at once (front-loaded, like all action costs in Cogmind):

Cost	# Weapons
200	1
300	2
325	3
350	4
375	5
400	6+

In the earliest versions of Cogmind, firing costs for multi-weapon volleys increased about twice as quickly as they do now, but the rate was later reduced to encourage builds with more weapon slots, since they already have other issues to contend with such as the resource costs involved in larger attacks.

Most robots have two weapons, so if you're relatively fast, each time enemies fire you can fly something like 10 spaces. Even average-speed robots can move three spaces in that time, important for repositioning to a more defensible location. And for combat-focused players, the system is obviously designed to give them an advantage in one-on-one combat, since few actors other than the player are capable of using that many weapons at once.

Sometimes individual weapons may modify the required time (firing speed), though they're the exception rather than the rule. More unique among this system are melee weapons, which can only be used one at a time (multi-wielding is possible, but additional weapons only have a chance to follow up a primary attack). They are almost always slower than projectile weapons (~300 time/attack), but also more damaging, and come with their own special effects.

Before firing, the HUD displays how much time the currently activated weapons collectively require to fire:

Volley firing costs indicator, changing as weapons are toggled (Autoguns have a faster firing time).

I think Cogmind is a good example of a unique approach to time management, showing that even while using a very traditional system roguelikes don't have to follow the principle that the cost of one action is near or equal to a single turn, or a multiple of turns.


Continued in the following post...

[Kyzrati]

..continued from the previous post.


New Challenges
Of course it's only a matter of time before extreme min-maxers come along and pick apart all the system details in a roguelike to scour it for every last possible advantage. They got around to the time system in 2017, and discovered that it was possible to game subturn actions such as quick movement to figure out when it would be impossible for AIs to mark the player as a target, thereby guaranteeing free peeks around corners without being spotted.

Only a few players knew about this, and even fewer actually used it, but as an "optimal but tedious" strategy (and also an unintended one) this was definitely something to eventually put an end to. Besides, the original time system might not even be the most appropriate for Cogmind--heck, I barely understood its current gameplay implications and had just brought it on board for a quick 7DRL years ago!

At first, mainly because it wasn't having a broader impact on play, I just wanted to try some quick band-aids to see if I could fix this under the existing system without digging too deep.

So I slapped on two separate "fixes" that year, specifically: 1) randomizing turn offsets for each AI (so they didn't always start their life at 0 time, and therefore be likely to act on turn boundaries, especially if stationary like guards), and 2) changing the "wait" action to cost 100 time units, rather than simply draining the actor/player of all their remaining time in the current turn.

And neither of these worked because, well, I admit I didn't understand the time system I'd borrowed seven years before, and hadn't actually read through to understand what was really going on xDAt this point I should explain the actual mechanics of that time system! Basically:

• Each actor gets a certain amount of time units to spend on actions during their turn, for example a base amount of 100 time units, which might be modified by stats or status effects.
• During their turn they perform actions that consume this pool of time, and as soon as their remaining turn time reaches zero (or even goes negative due to a time-intensive action), their turn is over, and they are moved back into the queue of actors where they belong, depending on their current time value.
• Each time they reach the front of the queue, they again have a new pool of time units to use, again based on their stats or status effects.

This system has some interesting characteristics due to the fact that in some cases it can allow for an actor to make multiple uninterruptible actions in a row, assuming the actions cost less time than their available pool. Really you might notice that's a lot like the X-Com TU system, only handled at an individual actor level (plus you can overspend your available time) and therefore feels much more roguelike.

Such a system also allows for different actors to have different amounts of time available to them per turn, essentially speeding up or slowing down all of their actions relative to other actors. Now in Cogmind I actually never used this adjustable time pool feature at all! Funny enough, I do distinctly remember back in 2012 liking that the system offered such a possibility. There was a spot for it in the actor turn code, but every actor always got exactly 100 time for their pool. Apparently this just wasn't how I wanted to handle the 7DRL actor "speeds," not to mention Cogmind's special movement and attack time mechanics already introduced a lot of variability without the unnecessary complexity that another layer on top of that would bring. Actors could already affect the cost of their individual actions, such as using utilities to fire faster, or attacking with weapons that were simply faster on their own, or speccing for fast movement, or any number of other actor-controlled variables--this level of nuance seems more appropriate for robots built of components.

Anyway, the whole "player always gets at least one full turn" aspect made it impossible to solve the peeking issue--the time system simply wasn't compatible with Cogmind's "enemies cannot spot you if it's not their turn" mechanic. It's a good system, just not right for Cogmind

At this point I still didn't go as far as replacing the time system though, because there was one other relevant mechanic I'd thought up in the meantime: "off-turn spotting."

This tackles the issue from a different angle, allowing actors to maybe know about something passing through their line of sight, even if it happens extremely quickly, where the chance for them to notice depends on their type, e.g. Sentries should be more likely to investigate a "potential anomaly." While so-called "partial spotting" won't lead to an aggressive chase, they'll at least check out the area where they think they saw something before going back to their original task.

I like how this mechanic turned out, but honestly it's tangential to the whole peeking thing.


New System Time
Seeing as I wasn't even using the original time system as intended, the obvious answer for this problem is to just allow "turns" to be interrupted--immediately reorder the actor queue after every action. Duh.
I finally made this change in Beta 8.1, ripping out the old 7DRL system and replacing it with a very simple standard queue.
This change has a number of implications:

• It's impossible to be completely sure one won't be immediately spotted when rounding a corner
• The chance of being spotted immediately becomes essentially directly proportional to movement speed
• Common sequences of actions that cost less than one turn, like dropping a couple items, can now technically be interrupted by other actors
• Other fast-moving actors won't appear to move so fast compared to a fast player, since moves will be spread out and not lumped together in a sequence

Honestly I'm pretty sure the differences will barely even be noticeable for most players, if at all, but it was about time to remove this unintended, basically non-designed, part of Cogmind. Revisiting it also had another nice side effect which I'll get to, but first... the bugs.

Oh my, the bugs. I'm pretty bad at technical stuff, so I needed some extra debugging features before I could track them all down.

I already had the first debug visualization from back when I was messing with turn offsets ineffectually trying to solve the problem the first time. (Seriously, if you truly want to solve a problem, examine the entire circumstances first or you're probably just wasting your time like I was xD)

Visualization: Current relative time values for every actor on the map.

This wasn't enough, though, since under the shiny new system some actors were acting out of order. I originally tried just debugging it internally by looking at values and queue contents, but this was a slow process and before long I had a fully visible turn queue.

Visualization: Current turn queue, soonest to last to act.

The visible turn queue not only shades actors by the relative amount of time until their next turn, but also shows in yellow any that are acting out of order (or somehow managed to get a positive value :/), which had thankfully been fixed by the time I took the above screenshot.

Once all the bugs were ironed out, I also used this opportunity to actually add binary searching to the turn queue. The original time system just uses a linear search, which is fine if you only have maybe 20 actors on a map, but Cogmind has literally hundreds! I did a bit of quick profiling and found that on a mid-game Cogmind map (Factory) 11.59% of the turn processing was taken up by putting actors where they belong in the queue.

Profiling Cogmind's turn queue updating under the old linear search.

That seemed like a lot, and switching to a binary search brought it down to 2.25%

Profiling Cogmind's turn queue updating under the new binary search.

The final time system and visualized turn queue in action in Cogmind's opening Scrapyard.

Turn Queue Explained
Since I've gotten questions before, I should probably go into slightly more technical detail about how my basic roguelike turn queue works, especially since it seems so amorphous with regard to absolute time. Where does the idea of a "turn" even fit in here?

A specific example will really help:

• Say you have three events in your queue: Player
• , Enemy
• , and Turn [100]. The initiative is set in that order.
• Player goes first, spends 120 time on their action, and the new queue order is Enemy
• , Turn [100], Player [120].
• The first event in the queue is always the next one to take place, so Enemy goes next, and decides to perform an action that requires 50 time. The new queue order is Enemy [50], Turn [100], Player [120].
• So now the enemy gets to act again because they are still at the front of the queue. This time they do something that requires 100 time. The new queue is now Turn [100], Player [120], Enemy [150].
• At the front of the queue is... the Turn counter itself! So it handles any absolute turn updates, i.e. things that should happen "once per turn." Then because each turn is set to be 100 time, the new queue is Player [120], Enemy [150], Turn [200].
• So the player acts next, and so on... As you can see, the turn itself is an event/actor, just like the others. You can even add other types of events into the queue if you like, for example as of Beta 8 Cogmind has autonomous weapons that take their own actions independent of the turn counter or even their owner.

Note I use positive numbers in the above example just so it looks prettier, but internally I actually subtract action costs and allow everyone's time to go increasingly negative.

Inserting a new actor is as easy as adding them to the front of the queue and matching their current negative time value with that of the actor already at the front (or insert them elsewhere as appropriate if it's desirable to delay their first action).

[Kyzrati]

SITREP Saturday #46: Extreme Bothacking

Beware, the bothackers cometh!



Hacking robots has gotten a lot more interesting since Beta 7, and although there were some buffs after that, the strategy was still somewhat lacking in the late game, at most serving as a supplementary capability rather than holding its own. So now we've got... permanent upgradable RIF abilities!

I've written a full explanation on the new system over on the blog: "Robot Hacking: Upgrades"



You can read all the details there, but in short, you'll be able to seek out new abilities at RIF Installers, eventually becoming a bothacking powerhouse if you can brave that many Garrisons. Abilities include stuff like upgrading your Relay Couplers, using Phasewalls, and making allies immune to Programmer hacking.

Using the Robot Detection ability to see nearby enemies:



Walking through Phasewalls:



The new RIF abilities UI for listing learned abilities and their effects:



In this week's stream I also demonstrated RIF abilities (along with some other upcoming features) in a Beta 9 preview:





Zyalin drew our bothacker build :D


   
Me? On a flight run?

I took a month off streaming Cogmind to review a bunch of 7DRLs, but have since gotten back to Cogmind streams and did a complete flight/thief run. Part 1 is here:





The original goal was just to steal from the Exiles and evade all the inevitable thieves, but the epicness continued for much longer than that. I wrote up a full summary of the run with links and images, though note it does eventually get into extreme spoilers.

I won't go into details here, but one of the epic events was getting two major bots to fight each other. I can't not show it because Zyalin drew this awesome depiction of us flying around with our friend, who is having his nuke intercepted by that much bigger non-friend.



Pay2Buy2Win

Before that I also streamed a couple weeks of Pay2Buy mode, the new version released for April 1st.

https://www.youtube.com/watch?v=6VVNZBiqAuc

A list of parts purchased throughout that run :)



After some time had passed, I put together a special leaderboard to record those who'd participated in the 4/1 event (and opted into uploading)



That and a bunch of related stats can be found on the forums here.

Writing and Doing

Following my article on level design, I added a pair of related pieces:

"Roguelike Level Design Addendum: Procedural Layouts"



"Roguelike Level Design Addendum: Static or Procedural?"



More recently I posted an in-depth look at the evolution of Cogmind's turn time system:



In little features I worked on, we're getting specific death messages for the scoresheet. Check out some samples from that system at work here:



I took a few-hour detour to add all the commands to the manual. Commands have always been available in game, but some people prefer to reference them externally in the manual. The list there was always incomplete since I'd approached it differently--only showing an alphabetized list of keys with their effect, rather than organizing it categorically as you find it in game. Now it's organized and complete.



This of course also means that the in-game manual includes the list as well, even though they're already available via a separate explicit help menu :P



Also have a red mapgen visualizer:



Art from 2243

A new gallery of works for your perusal...




Storage Jammin', by Zyalin




A multitreaded combat bot, by Zyalin




EM Cogmind, by Zyalin




Mni. ARCs?! by PlasticHeart




Unsafe branch spawns, by PlasticHeart




A randomly trapped Fabricator, by PlasticHeart




Storage shopping, by PlasticHeart




ECM Sweet, by JackNine




March leaderboards, by 8FPS

The Great Server Outage of 2019

At the end of May the servers were, um, "updated" by the host and this broke a bunch of stuff. The blog and wiki were both down for five days, and for two weeks the in-game news/version checking feature as well as score uploading and error reporting were all broken. Sadness.

Fixing this took quite a lot of work, no thanks to the host service who had no idea what was going on. Fortunately we have lots of web devs in the player base and I got some tips and ideas that eventually helped get everything up and running again.

As of last week our leaderboards are once again accepting new data \o/



As part of the fix I was forced to update Cogmind itself, so I put out a quick and relatively unannounced Beta 8.2 earlier, which has all of one line in its changelog :P

Saves are compatible with the previous version (so there's no legacy branch on Steam), it was just a modification to how COGMIND.EXE connects to the website for the optional online functionality.

Going forward Beta 9 will be running on a different db-based leaderboard system, so would no longer be affected by availability or reachability of the website itself, and will also feature multiple attempts, in case a score cannot be uploaded for some reason at the time a run ends (for example no active internet connection). Too bad that wasn't in place yet when this even occurred, but we'll get to it soon enough!

The 9th Circle of Betas

Speaking of Beta 9, when and where is that, anyway?

Well, it's going to still be a while yet. As we approach Cogmind 1.0, there have been a few major meta systems remaining to work on, and all of these happen to be features that need to be released simultaneously, making this by far the longest release cycle to date as I get everything in place.

The first is the revamped scoresheet, which is now complete, and also awesome--I'll be writing about that for the blog next. It's been a massive project that alone took more than a month.

The second is a new leaderboard system. The current one is pretty nice, but it's not fully automated and also has no internal database, limiting the kinds of things that can be done with it.

And the third is rebranded difficulty modes, which won't be changed in too many fundamental ways, but will get a new selection UI and hopefully be more useful to new players while also better at setting expectations.

Plus on top of all that we of course need other fixes and features that make releases interesting, like the RIF abilities :D

So Beta 9 is a big one, even if a lot of it is internal work. But it must be done, so I'm doin' it.

I was hoping to have it done by mid-June, when I'll be out of town for a few weeks, but there's been too much extra work involved so unfortunately I won't be able to finish it until after that, which means some time in August.

I'll still be chipping away at it while on the road, and updating the blog and Patreon, but four weeks from now when I leave I'm pretty sure there'll still be a little more work left to do on Beta 9, and I don't want to rush it out.

That said, even though it's incomplete, patrons can fool around with a prerelease version of Beta 9 (the one I streamed earlier this week), which already has the fully functional new scoresheet features and RIF abilities.

With Steam revenue falling lately, patrons are now clearly responsible for keeping development going without having to worry about wasting dev time advertising or wrapping up Cogmind to switch to another project, so many thanks to them <3



I mean it's true I've been working on Cogmind for six years now and continue expanding it without charging for the extra content, so this trend is inevitable xD

Patrons have also put in their votes for their choice of feature to focus on going into Beta 9:



(So yeah, yet another thing to work on!)

While we're talking money, here's your notice that Cogmind is having a weeklong 10% discount from June 17th through 24th, both on Steam and the website (where you can also get a Steam key and it's a lot more helpful for the bottom line).

I'll leave you with our favorite cheer (courtesy of Zyalin).

[Kyzrati]

Since my Beta 9 preview/bothacking run was running under the debugger while streaming and I screwed it up and lost it at the end of the stream, I started a new one this week which will go much further, seeing how far we can reasonably take this new play style . It's getting strong already, with some interesting new possibilities...





(Also put Cogmind on discount right now for 10% off over on Steam and my website.)

[Kyzrati]

Special Game Modes in a Roguelike Context
[Cross-posted from the devblog here--follow link for better formatting and light-on-dark style.]

By their nature roguelikes are highly replayable, but can also serve as a great foundation on which to essentially multiply that replayability again and again. Adjust a few variables here, add a little content there, and you can have a very different game, one that some people admittedly might enjoy less, but they don't have to play it--others who do like the the alternative mode have a whole new way to interact with an otherwise familiar world, or take it as a challenge depending on how it's designed.

What I'm calling "special modes" includes everything from timed events to challenges and conducts, basically different ways to play the same game, primarily ways which are explicitly codified by the game, although non-codified alternatives are also within the scope of this discussion.


Why Special Modes?
There are many good reasons to including special modes in a roguelike. Here are some of the advantages I've encountered during my work with them over the years:

• Value: Well obviously as with any additional content, there's more value for players. This also translates to value for the wider community as well, since special modes serve as another source of interaction whether it's sharing stories, bragging rights, or just talking strategy.
• Replayability: Special modes can require players to explore whole new strategies within the context of a body of knowledge they've already accumulated about the game so far, just seen in a different light, making an already replayable genre that much more replayable.
• Learning: Having seen the game in a new light, some of the knowledge gained through these alternative experiences can even translate back to improved skills while playing the main game.
• Experimentation: Special modes enable players, and most importantly the developer, to experiment with new ideas that may even make it into the game proper--the design can go out on a limb here without any real repercussions. Of course you can already do this with prereleases/beta releases/EA/whatever, but the idea here is that these mods can also continue to live on on their own, without having an impact on the game as well, for those who choose to play them.
• Interlude: As a developer, sometimes it can take a while to put out a major update. In the meantime, rather than keeping players waiting too long for something new, why not release a special mode to play around with? (Note this category also includes postludess as well, breathing new life into a game after most or all of its updates are out there and development is "complete.")
• Efficiency: Handling special modes as "interludes" is also made easier by the fact that they're generally not that hard to implement. You get lots of bang for your buck in terms of dev time here, due to reusing not just assets, as you might with an expansion or DLC, but basically reusing pretty much "the entire game" and just changing the experience, possibly even significantly, in a relatively short time. This generates a lot of low-cost value.

Naturally it makes more sense to apply special modes to an existing expansive project, since there's more content and systems to work with, though technically many of the same characteristics can apply to any roguelike, large or small. Still, these modes are more of an optional "extended development" sort of goal, and if the base game isn't yet complete or at least itself an already compelling experience, then clearly more work needs to be focused there first :P


Sample Cases
To demonstrate some of the above, let's look at the range of Cogmind's special modes, which take multiple forms.


Timed events
A few times over the past couple years I've added special modes that trigger automatically at a certain time, for everyone to participate in. Of course there is/should also be a way for people to opt out of this if they'd like to play a regular run during that period, but I also make it so that these modes don't kick in unless a player has already finished several runs and has some experience (or in the case of one of the events, a fair bit of experience).

I've seen a number of indie devs do holiday-themed events these days, though most don't seem very expansive, maybe just a little change or bit of content here or there.

April Fools Day is a good candidate if only because the theme can be a combination of something totally crazy/funny/unexpected. Plus of course there's the fun result that some people don't even believe the news is true, while for those who learn it's a real thing it also kinda counteracts the growing internet annoyance at all the fake game-related announcements people wish were true xD. I like making an April Fools announcement about features everyone can actually play with.

I've done a couple of these so far, starting in 2018 with Launcher Mode. This one is a good example of a quick modification that changes the entire experience in interesting ways. All it does is essentially convert all obtainable weapons to a random launcher instead. Launchers are powerful, but also resource-hungry and not great at solving every sort of challenge, so strategizing ways around their shortcomings (with a more limited set of options) is a pretty new kind of experience. Plus players get to use fun weapons that tend to be more rare in regular runs :)

Sample map area with all items replaced by random launchers for April Fools Day 2018.

Being put together so quickly there were a couple of oversights, like at first enemies could still drop their weapons and you could arm up with non-launcher weapons that way, but I fixed the main issues with a quick patch shortly after release.

From conception to implementation to deployment, this entire mode took only an hour to put out, and wasn't even planned at first, but literally on the morning of 4/1 a player asked about April Fools and it sparked an idea (another reason having an active community is so great--lots of interaction to spark new ideas). Overall a relatively small effort for big gains.

Unfortunately I don't know how many people actually played because at the time I simply decided to deactivate score uploading if using that mode to avoid polluting the leaderboard with non-standard runs, but news about the mode did get posted around (and even attracted attention from new buyers) and people thought it was fun, or at least funny even if they didn't play :P

Certainly the AFD (April Fools Day) data could be directed elsewhere, but I wasn't thinking about it then, and there wasn't time much time to think through doing that anyway--it was already the morning of release!

In April 2019, however, I once again released a special mode, and this time I had both more experience and some time to dedicate to redirecting scores for this mode so we could get some player data, and a dedicated leaderboard. Participation was limited (42 players) since the leaderboards are opt-in and it was just a timed event, but it was nice to be able to look at some stats from the runs.

Cogmind April Fools Day 2019 Leaderboard

The theme for AFD 2019 was "Pay2Buy," where players don't find or salvage spare parts, but instead earn coins and buy items from the "Cogshop." There's even a market economy, loot boxes, and special deals!

Buying items from the Cogshop.

This was most certainly not a one-hour job like AFD 2018.

I spent a week designing and putting together the Cogshop and related mechanics, but I think it was a week well spent since as per the "interlude" concept mentioned above, it gave me something new to put out there during a lull of regular releases. The previous release was 7 weeks before 4/1, and now 7 weeks later (as I still work on some extremely time-consuming features) the next major release still hasn't hit, so yeah we really needed a little something out there :P

Pay2Buy actually wasn't the first idea entertained this year--in the run up to April 1st I experimented with turning Cogmind into a real-time game, but that didn't feel like it would be fun for a majority of players so I dropped it. I talked about this mode and its design on Patreon here[/url] (patrons only).

Another important detail about these particular "timed" events, is that I built them to also be available after the event period. Not everyone who might want to can necessarily play on April Fools Day, so just like there's a method for players to opt out of the events, they can also opt in on other days (both handled via command line switch). This wasn't true in 2018--back then the advice was simply "change your system date when you start a new run," but it's kind of annoying to require that players mess with their system for something like this! I added the mode-forcing feature this year.

So these event modes have become permanent optional features. They're simple and/or isolated enough that there shouldn't really be much maintenance involved in future versions, may as well make them available to everyone down the line :D

Late last year we had another timed event which I approached very differently: "Limited Edition Holiday Mode 2018."

Cogmind Limited Edition Holiday Mode 2018 logo

Running from December 20th through January 1st, the highlight of this event was getting PRESENTS.

The Scrapyard is full of presents! Who could've done this...

Go ahead, open it!

Opening each present revealed one or more items, really good stuff, and available right in the starting area. Not just any good stuff, though, the majority were chosen from among 17 brand new holiday-themed items, some with new mechanics (see this followup announcement for details).

Dropping a piece of "Black Coal" outside a Garrison and making a run for it.

A few of the less special items were randomized, but most I handpicked for each day to allow for different experiences through different combinations, of course taking into account special days like Christmas Eve, X-mas Day, and New Years. The craziest, flashiest item was reserved for reigning in the new year:

Behold, the RPDS!

RPDS Demo: Now With More Tiles Edition

Yeah it looks OP, but it's also an insane drain on resources so is not easy to properly use! Not to mention the complex gets really mad when you destroy so much stuff that quickly, and that usually means trouble. Still fun though :D

Now this all seems like a fairly big production, but I only spent two days on it! Surprised myself with that one, really. It would've taken longer had I decided this event's features would be future proof and available through all following releases, but this one was a true limited-time event only available in that one version of Cogmind. As a one-time event, I was able to rapidly add content without putting any time into considering or preparing for possible long-term consequences of my decisions (or even organized/coherent scripts and code xD) like I normally have to do.

This highlights one of the drawbacks of special modes, that in order to keep them usable in future versions they may have to be maintained along with changes to the rest of the game, which can be time consuming and possibly not worth it, so it's good to differentiate between temporary but extensive modes and those modes with a more limited feature set which can more easily be kept with minimal maintenance going forward.

Both AFD 2018 and Holiday Mode had really high "bang for buck" quality. Less so with AFD 2019, but it was definitely still worth it since we got to keep the mode and it's a pretty interesting way to play.


Challenge Modes
Cogmind currently has 12 "challenge modes." The design scope for these is somewhat narrower than time-based events, which might inherently be challenging to various degrees, but the focus there is mainly on fun. Challenge modes, on the other hand, are an optional way to increase the challenge level of the game through various modifications. Multiple challenges can be active at once, and each one intermittently awards points for reaching milestones. Plus of course there's the advantage of allowing players to simply face different or unusual challenges compared to those they might normally face during their runs.

I haven't covered these on the blog before since I've generally considered them an "experimental" part of the game, although I've been maintaining a forum thread updated with their content.

They're not even accessible from in-game menus, actually, only via an external config file, but challenge modes have technically been integrated into the game proper via achievements for winning them, and there's a separate leaderboard as well.

Below is the current set of possible modes, just stuff I either 1) thought would be challenging to try or 2) easy to implement anyway and worth experimenting with:

• Devolution: Start with three times as many part slots, chosen randomly (from a weighted distribution) and lose a random one at each new evolution, growing from super strong to eventually extremely weak.
• Fragile Parts: All parts are destroyed on removal, mimicking the standard behavior of processors.
• Gauntlet: All exits from each map are blocked from use except for the furthest main exit from the map's entry location.
• Inhibited Evolution: Only evolve half as many slots as usual at each depth (essentially weaker throughout the run).
• No Salvage: Destroyed robots leave no salvageable parts, only matter (a resource), making it harder to find the right/useful spares.
• Pure Core: No inventory slots are available for the entire run, only what parts be attached.
• Scavenger: There are no random part stockpiles in the main complex, and any lone items strewn about are damaged. Everything else must be salvaged from other robots, stolen from haulers, or fabricated.
• Simple Hacker: No indirect or manual hacking of any kind.
• Sticky Parts: No parts can be removed or swapped out manually, and must be destroyed to free their slot(s).
• Super Gauntlet: All exits from maps are locked, and the only way to advance to the next depth is to find and fight through the one unlocked Garrison.
• Trapped: Most maps have 10 times as many traps, which are also more likely to trigger, and most methods of learning trap knowledge are unavailable.
• Unstable Evolution: No control over slot type evolution, which is random.

Random damaged parts lying around in the Scavenger challenge mode.

Manual hacking option disabled for the Simple Hacker challenge mode.

(See the forum thread for sample images from more challenges, along with other ideas and discussion. Also the manual has more specific mechanics and scoring descriptions than what's found above.)

Most of these are actually quite easy to implement, again a good way to add value and new experiences to the game at little cost.

They're also still an ongoing part of feature development. It's been ages since the last batch was added, but I've got dozens more ideas in this area (and of course many suggested by players as well), I just need to decide when to add more... I guess the plan was to make an in-game menu to access them first, and do this and more as a dedicated release, but as a time-consuming but low-priority feature that's been repeatedly pushed back.

(continued in the following post...)

[Kyzrati]

(...continued from the previous post)

Conducts
Conducts (also called "challenge games" or "challenge runs") exist in many roguelikes, from as early as the classics. Conducts are different from Cogmind's so-called challenge modes in that the latter actually modify the content or mechanics in some way to create the challenge, whereas traditionally conducts work within the base game itself without any changes--they're purely dependent on some kind of player-based limitation.

For example NetHack includes a number of optional conducts that you can read about here on the wiki.

Some of the conducts NetHack tracks, as listed in game via the extended #conduct command.

Brogue also tracks conducts, which it calls "feats." The full list can be found here.

Victory screen from Brogue, having achieved two conducts (source).

Unlike the above examples which are just detected automatically as you play a normal run, Angband players essentially treats some of its "birth options" as conducts, though there aren't very many--some roguelikes lend themselves to conducts better than others.

Not all conducts are necessarily tracked by a roguelike, many more originate in the player community and become established as "unofficial" conducts, challenges attempted by many players but that aren't technically coded in the game, instead relying on players self-enforcing the appropriate limitation(s) or requirement(s).

NetHack also has a decent-sized list of unofficial conducts (some of which are tracked by variants even though vanilla does not), and ADOM has a number of established unofficial conducts as well. Some of ADOM's achievements have since become semi-official by having them recognized via Steam achievements in that version of the game.

Cogmind definitely has its share experienced players who self-impose conducts, too, and even an "official" set as in those represented by relevant achievements. Although Cogmind achievements don't require Steam, the achievement system is the only one to codify and enforce these conducts, and therefore technically each only works once (the first time it's achieved). Later this could be expanded to recognize them in any subsequent run even after having been previously achieved, but I'm not too sure of the value in doing so just yet since there's a lot of other more valuable features, not to mention there are so many achievements that it's easy for players to stay occupied doing new and different things anyway, as opposed to repeatedly attaining the same goal.

One difference worth noting here is that "conducts" are traditionally more specific than a lot of achievements, which may be accomplished before actually winning the game. A conduct is not fully earned until the run is won, so they're generally challenges by and for the minority of experienced winners choosing them as a way to intentionally make the roguelike even harder.

Cogmind currently has 256 achievements, but win-related conduct achievements all fit into the following subcategory:

Cogmind sample achievements in the UI.

Then there are 12 more for winning with each of the Challenge Modes, though again these actually change the game, and I wouldn't consider them conducts as defined here. And quite a few more of Cogmind's achievements require long-term conducts within a given run, but can technically be earned before winning so don't really count, either.


Non-meta Conducts
Conducts as described above and generally thought of by the roguelike community are "meta achievements," basically optional challenges imposed on top of the game itself, and probably can be stopped/forfeited at any time by player choice, regardless of whether or not the game is tracking a given conduct.

But I think there's an interesting alternative category of conducts embedded within the gameplay.

DCSS god conducts would be an interesting example here. Once you worship a specific god, they may expect you to avoid certain behaviors, or reward you with greater piety for other specific behaviors. This clearly restricts or at least affects the player's "conduct" for much of the run, or at least until (if) the player is willing to suffer the consequences of leaving for another god.

See here for a list of DCSS gods, which link to more information about each, where the "Deprecates" heading indicates what kinds of conduct that god expects.

DCSS's Chei is a good example of a restrictive god.

Most gods don't have a whole lot of limitations, instead focusing more on behaviors they'd expect or prefer that you do in order to gain piety and reward you for it. An interesting exception here is Ru, the god who will only reward you (greatly) as you take on additional permanent drawbacks ("personal sacrifices"), which essentially act like minor conducts.

Cogmind also does some of this non-meta "embedded conduct" stuff, although not god-related and instead on a more macro scale. For example you can permanently install RIF in order to gain a range of useful abilities, but doing so makes two of the other factions hate you, and you'll therefore lose access to their respective help and abilities for the rest of the run.

There are a number of long-term effects like this, though unlike traditional roguelike conducts which are purely negative, Cogmind generally (but not always) balances them out so that something else of similar value is gained in the process. Either way, the effects are for the long term and some will make certain areas, or even the entire run, more challenging.


Randomized Challenges
Beyond tradition, there is still plenty of room for innovation in the roguelike "special modes" space.

One of the more interesting possibilities is randomization of challenges. As a highly replayable run-based genre roguelikes are quite compatible with this approach, where you have a pool of mini-challenges which can include things like tweaks to mechanics, items, enemy behavior, or the player character themselves, and at the beginning of a run a combination of these tweaks is chosen to be combined as the challenge. With enough tweaks to choose from, different combinations can create very different experiences, all without too much work beyond the supporting framework.

Even better is having the combination be shared across the community as daily and/or weekly challenges, giving the community more topics to discuss and allowing for separate leaderboards.

I'm not too sure this is appropriate for Cogmind given the game's wide range of interconnected systems and far-reaching balance concerns (it's a very tightly balanced game compared to many roguelikes...), though the concept certainly deserves more thought and possibly experimentation. Could be fun!

While combining multiple Challenge Modes is a thing, personally I have a pretty specific idea of what constitutes such a mode, which tends to exclude tweaks which might be too small a change (or, less likely, too large an overhaul) to consider for a pool of mix-and-matchable mini-challenges. The target scope would be different in that case, so this would need to be a different system. I can see affecting game variables like item availability, salvage drops, and map demographics, adding permabuffs/debuffs of various kinds, or possibly starting from different parts of the world.

Anyway, there's already (still xD) lots of do, but maybe this could happen one day.

[JobLeonard]

(...continued from the previous post)

Ah, one of those updates, eh?

[Kyzrati]

So short though! TIGS has a pretty low character limit on its posts--I don't have this issue anywhere else

Next up: 9,000 words on morgue files! I'm breaking that into a series, but still, even then each segment won't fit into a single TIGS post xD

[JobLeonard]

How dare you post such in-depth postmorems of your gamedev experiences! :p

[Kyzrati]

Building the Ultimate Roguelike Morgue File, Part 1: Stats and Organization
[Cross-posted from the devblog here--follow link for better formatting and light-on-dark style.]

In-game content is important, but for many roguelike players there's a lot of fun to be had outside the game as well, be it reviewing records of one's own runs, getting good insights into runs by other players, or relying on data to learn more about the game and engage in theorycrafting.

Back in 2015 I explored morgue files in various roguelikes and wrote about a potential future for Cogmind's own so-called "scoresheets." The original intent of these files, added for the 7DRL in 2012, was simply to report the player's score for each run and give a few very basic stats. It was a 7DRL , after all, and there wasn't a bunch of time for heavy record keeping.

A sample Cogmind 7DRL scoresheet (2012!), very simple indeed.

In the days after 7DRL I wanted to run a tournament and thought it'd be fun to hand out achievements, but to do that we'd need more stats to base them on. Being outside the 7-day restriction I was free to spend some time on that and the "Stats" section got a few dozen more entries. You can see what the scoresheet became in those days in this example from Aoi, one of only two players known to have ever won the 7DRL version (the high scores, with links to scoresheets and tournament achievements, can be found here).

In the years since, aside from occasionally adding new sections to the file, the primary Stats section simply grew longer and longer as I tacked on entries for new mechanics and content, growing from 79 in the 7DRL (2012) to 328 in Alpha 1 (2015) to 818 in Beta 8 (2019)!

A Cogmind scoresheet from a sample Beta 8 run by Tone, which I've restructured horizontally because the full length is 24 pages! I've also shrunk the image down to avoid spoilers while retaining the general idea of its breadth, however if you don't mind spoilers (this particular win spoils a lot!), you can check out this same run in its text form here. Note the full potential length of a scoresheet is technically even longer than this--many stats are not shown unless they're relevant to the run, omitting them either to speed up parsing or to avoid spoilers, so this sheet for example is missing about 100 entries xD

As such a massive collection of stats, all in a single section, the format has really strained to do its job, badly in need of better structure to make it easier to both parse and understand. But despite the ballooning size, I intentionally avoided making any big changes to the scoresheet format for a number of reasons:

• The format was at least pretty simple, and if there any significant changes to its content I'd already have to put a bunch of time into rewriting the analysis code (used to produce the leaderboards and aggregate metrics), and that code was a mess and all going to be replaced one day for the final system anyway.
• Some players had built useful third-party applications based on the scoresheet format, so too many changes in the interim could break these unnecessarily.
• As usual, it's best to wait on designing systems that touch a lot of other features until most all those potential features are in place, so that the supersystem's design can take everything into account.

With Cogmind approaching 1.0 now, a lot of the content and systems are already in place, plus we have a lot more experience with run data and what people want to know about their/others' runs, so it's finally time to bite the bullet and build Scoresheet 2.0!


Preparation
To prepare for the transition to the new scoresheet, I finally exported all the existing score data parameters to an external text file. The original scoresheet data being as limited as it was, from 2012  it simply lived inside the code as a bunch of separate arrays. It was messy, and I never cleaned it all up  simply because I knew that one day it would all be replaced anyway, so may as well wait until that day in order to do it right the first time. This allowed me to merge quite a few arrays and multiple disparate bits of data storage into a single text file with contents represented by a single data structure.

A snapshot of Cogmind's scoreType data, a new 897-line file where all the score/stats entries and their behavior are controlled.

Even just this first step made the whole system feel sooooo much better. Moving data out of the code makes it much easier to maintain, and less prone to errors.

The next question was how the new data would be stored, but that couldn't be answered without a clear idea of everything that would go into the new scoresheet...

Aside from organizational concerns, and new content, the most significant aspect of Scoresheet 2.0 would be its recording of stats on a per-map basis. Scoresheets historically just had a single value per entry*, and it was clear we wanted more values in order to paint a better picture of how a run progressed, but at first I wasn't sure just how many values to store--once per depth for some values? Once per depth for all values? Once per map for... everything?!

(*There were just a few important stats already recorded once per depth--remaining core integrity, for example--but these would be rendered obsolete by an even more detailed per-map system.)

At this point I did a couple tests, the first a layout mockup to compare the aesthetics of per-depth and per-map values, just to get my head in that space.

General data layout concepts for multiple values.

As you'll see later, I decided the total should remain at the beginning to ensure all those values line up (since they are the most commonly referenced, after all), a separator line was necessary between the total and per-map areas (for easier parsing), and along with the map abbreviations it would be important to indicate their depth as part of the headers as well.

I also calculated out the text file size for such a scoresheet, to ensure it would be within reason given the number of stats we're talking about here. Upwards of 800 stats recorded across 30 maps, for example (a higher-end estimate for longer runs), is 24,000 entries! Not to mention the composite run-wise values and all the other data included in scoresheets (lists, logs, and more). The result is definitely larger compared to Beta 8 scoresheets (around 10~25KB each), but a majority of these newer scoresheets should still fall within 100KB. Based on real tests by players so far, this seems to generally hold true, although the longest runs visiting over 30 maps will fall between 100~150KB.

If necessary to keep the number of values down, I was considering having only a portion of the stats do per-map recording, but eventually decided to instead go for consistency and keep the full set, especially since I could envision times when almost any given value might want to be known on a per-map basis. There are just a few stats for which per-map values would make no sense and therefore be confusing, so those are excluded.

On the technical side, to make the transition easier I simply had the existing "Scorekeeper" class change its behavior on receiving a new score value. Whereas before it would just merge values with a single list as necessary, now it has multiple sets of score values (a "batch"): The composite batch is each stat's value for the entire run, while the map-wise batches store a separate complete set of stats for each map. So for example when the player destroys a target, that event is recorded in both the composite batch and the batch for the current map.

ScoreBatch with the primary score manager class, Scorekeeper.

While we're in the source, below is the data structure storing all static values defining each scoreType found in the external file mentioned earlier.

ScoreData struct for holding score type definitions.

There are six different tally methods to choose from, with the vast majority of scoreTypes belonging to the default "additive" category, though a few require special alternatives:

• HIGHEST: Takes the highest between the stored and new value.
• LOWEST: Takes the lowest between the stored and new value.
• STRING: New value only included if a string provided with it is unique to this stat (for example only wanting to record once for each unique object).
• AVERAGE: Takes the average of all values.
• AVERAGE&gt;0: As AVERAGE, but ignores any zeroes.

Mockup
There would be a lot of rearranging data to come, all amidst adding new entries, so to make sure I got it right the first time, I needed a clear and complete goal to work towards. Thus in addition to the large collection of related notes I'd already accumulated, I also took an old-format scoresheet and modified that to create the target format, in the process taking yet more notes as I thought through the requirements, feasibility, and repercussions of each change. That mockup would serve as the initial blueprint to simply implement top to bottom, step by step.

Excerpt from the first Scoresheet 2.0 mockup.

You can download the full text mockup with annotations here. I used a winning run uploaded by Amphouse as the basis for this mockup because I wanted it to contain a wide variety of stats, though that also means it originally contained more spoilers--most of that stuff was edited out so I could share it here. Note that while the per-map data formatting gives you an idea of what it could look like, many of the numbers are either made up or outright missing.

Later there were also some small changes to the format as well as yet more sections/content I hadn't foreseen to include in the mockup, but I saved that original version for posterity (it also includes some of my notes and reasoning about parts I hadn't settled on yet). We'll get into the final form next

(continued in next post...)

[Kyzrati]

(...continued from previous post)

Organization
For the remainder of this post I'll be showing image excerpts from sample scoresheets to demonstrate various sections, but if you want to also follow along with the full text version of a complete Beta 9 scoresheet, you can download this recent run by Ape. There will likely be a few tweaks here and there before Beta 9 is officially released (it's still in prerelease testing), but for the most part this is representative of the final format. (Remember a number of stats are not visible because they weren't triggered for this particular run, so it's technically not a complete set, nor is any individual run, for that matter.)

One of the obvious improvements over the original "endlessly expanding version" is that it's now much better organized. Alongside the preexisting "non-stat" categories like Parts, Peak State, and Favorites, the core stats list itself has been broken down into 15 categories and reorganized as necessary to match them. We now have separate sections for Build, Resources, Kills, Combat, Alert, Stealth, Traps, Machines, Hacking, Bothacking, Allies, Intel, Exploration, Actions, and Best States! Categorization makes it easier to both find and understand relevant data. Plus it looks cooler :D

One thing I didn't add to the scoresheet is a list of every part attached, or even every build at the end of each map. There's just no great way to do these, and compared to the amount of space it would occupy this information would be difficult to parse, anyway. In hindsight I discovered the new automated class system will work nicely for that purpose, and that in itself also occupies two new sections in the scoresheet I'll talk about later.

"Per-weapon damage" and other details discussed by the community before in the context of an expanded scoresheet is another of the few things that were left out for similar reasons. I thought of somehow combining it with the Favorites section, but alone this information doesn't seem as valuable as it would be in comparison with all weapons used. We already have shots fired by weapon category, as well as damage tallied by type, both of which combine with per-map data to provide a clear yet concise picture of weapon use.


Sub-subcategories
Stats can now make use of a second level of indentation.

Multilevel indentation example.

Previously scoresheets could only contain primary stats and sub-stats, but that led to a handful of problematic situations where (mainly because stat names are kept from being too long) some stats really needed to be indicated as a subcategory to an existing subcategory and were therefore prefixed with '^', which is a bit esoteric . The new system fixes that by allowing more indentation. I'm not going overboard with it, but it is needed or advantageous in a few situations so I expanded the use of sub-sub-stats a bit.


Header
At the top of the scoresheet are a few lines serving as the general header where you'd naturally put the run's vital info, even if that info appears elsewhere.

This includes the name of the game and its version, as well as whether it was a win or loss. If you look back to the 7DRL scoresheet example, you'll see that the header remained relatively unchanged through the years (aside from adding a player name, which couldn't be specified back in the 7DRL).

Scoresheet 2.0 adds extra detail, most importantly the cause of death!


Scoresheet 2.0 header format changes.

The result can of course show a win, in which case as usual it will state the type of win, but many roguelike runs end in a loss, and although it's fairly common in roguelikes to record the cause of death, this isn't something Cogmind was equipped to do before.

For six years now, internally the game only got as close as recording a general cause of death, for example "by cannon," or "by cave-in," and this was not really worth including in the scoresheet because it's clearly an incomplete system that can't account for all possibilities, and also needs more detail to be as meaningful as possible.

So while we're vastly improving the scoresheet, it's about time to include this information! (Also imagine the fun aggregate data we can collect :D) This took a fair bit of work to both identify all the possibilities and variations and store the necessary information when it's available to provide it for the final conclusion. The sentence needs to take into account the relevant actor (Cogmind? enemies? no one?), kills via proxy, death to non-robot/attack causes... all sorts of stuff. Here are some more examples:

Scoresheet 2.0 run "Result" samples (cause of death).

Some players have indicated they'd like to be able to remain on the main UI after death to get a better idea of the situation, but this is at odds with Cogmind's immersive approach so I decided not to. There are alternatives like examining a log export afterward, or now using the scoresheet to see the specific cause of death, and/or last log messages, and/or surrounding environment (these I'll get to further below).

Going back to the header format changes, see how it also now includes the date and time of the run's end, but without the more compressed YYMMHH-HHMMSS time format used in the filename.

Scoresheets for special modes or events will also be listed next to the primary difficulty mode, if applicable. Those always used to only be recorded elsewhere in the scoresheet, if at all.

The difficulty modes and their names are changing as well, but that's a topic for a whole other article!


Performance
The score structure hasn't changed much. Throughout alpha/beta I've been watching and waiting to see if an all-around better approach to scoring would suggest itself, but didn't come up with anything, so the existing system will remain.

Sample scoresheet 2.0 excerpt: Performance.

It has, however, been expanded slightly with the addition of Regions Visited. Rewarding exploration is a good way to encourage it, so a set amount of points are earned for reaching each new map. In the early years points for "Evolutions" served that purpose well enough, earned at each new depth, but back then the world was narrower, whereas players can now spend up to a half or even three quarters of a run inside branches, exploring horizontally. While it's true there are also bonus points to earn in branches, not everyone may actually earn those anyway, and it's worth recognizing that they still made the trip.

The bonus point system will continue to be an important source of points for most runs, but it's flexible and can be adjusted/expanded more in the future as necessary. Notice that I moved that breakdown right up under the Performance section.

There were no changes to Parts, Peak State, or Favorites, which all still serve their purpose just fine.


Stats
There have been quite a few improvements and new entries added to the stats section (which, again, have been divided into 15 categories). I won't cover all of them, but will talk about certain areas of particular interest...


Build
Much of this section is new, adding a breakdown of all slot evolutions, as well as info on subtypes for attached parts and slot usage. Combined with the per-map data, we'll be able to have a pretty clear picture of how builds evolved across the run as a whole, in a much more condensed and readable format than if we had list after list of build loadouts or some other highly detailed approach.

Sample scoresheet 2.0 excerpt: Build.

Instead, after the detailed data we get a list of the most popular build classifications used throughout the run, ordered by usage. The list excludes any used for less than 4% of a run, as there could be many such transitionary states that aren't really meaningful in the bigger picture.

Sample scoresheet 2.0 excerpt: Class Distribution.

Following the aggregate class distribution is a summary of the player's dominant build classification for each map. Where multiple build classes were used, which is common, it picks the one that saw the longest period of use.

Sample scoresheet 2.0 excerpt: Dominant Class.

Automated build classifications are a new system I'll be diving into later in a separate article in this series. It'll be fun to run data analysis on the future scoresheets to learn what builds are more popular, a very new way to understand the player base.


Kills
With scoresheet 2.0 we finally get kill counts for more specific robot types! To simplify the code, this system had always relied on Cogmind's internal robot class system, which is essentially what you saw appearing on this list before. The problem is, the game has grown so much since then and you can now eventually meet some rather special special variants that shouldn't really be tallied along with the others--like not-your-everyday Grunts and Programmers, but there was no way for the system to distinguish them, meaning some of the most powerful hostiles in the game were being lumped with the average ones. No more! Now we'll finally be able to see real kill counts for all of the special robots out there...

The "NPCs Destroyed" list also now includes all uniques (as well as where they were killed!), so yes that means we'll also have a record of the nefarious exploits of those out there murdering bots who should otherwise be powerful allies . This list always included the major NPCs, but over the years Cogmind has gained a cast of minor named NPCs as well, so it's finally time to start seeing them in the data.


Hacking
As of Beta 8 the scoresheet only records Terminal hacks, but that's been greatly expanded to include every possible hack--all machines and even unauthorized hacks, too.

Sample scoresheet 2.0 excerpt: Hacks.

Remember here that a lot of entries don't actually show unless they're non-zero, so there are quite a few more possible data points than what you see in the sample run, hacking and otherwise.


Actions
I can see some interesting analysis coming out of looking at a breakdown of actions across a run. It's a pretty fundamental kind of data, but was actually rather challenging to implement because Cogmind didn't originally need to distinguish between action types in such a granular way. Anyway, we have it now :D

Sample scoresheet 2.0 excerpt: Actions.

Debugging action type detection via the in-game message log.

History and Map
It's common in roguelikes for a morgue file to include the last X messages from the message log, and while I don't think this section will be quite as valuable or interesting in Cogmind as they are there (due to de-emphasis of the log in general), it won't really hurt to add it and could at least in some cases help describe what was happening just before The End, especially in combination with the map.

Sample scoresheet 2.0 excerpts: Last Messages from three separate runs. For Cogmind I've chosen to record the last 20 messages in the scoresheet.

However, the ASCII map and history log (different from the message log!) are quite valuable and I'll be dedicating separate articles in this series to each of them.


Schematics and Fabrication
Since Alpha 9 the scoresheet has included a list of any parts fabricated during the run, and where they were built. But with literally every part of the scoresheet being revisited for 2.0, I discovered this one needed some improvements, too!

Original format for Fabricated list as used for the past few years.

The content is mostly unchanged, but the same data can be presented in a much more easily readable fashion--alignment is important!

Sample scoresheet 2.0 excerpt: Part Fabrication List.

Due to their varying lengths, it's far easier to scan a list of columns than with all the data mixed together. Content-wise the only addition is the new "Preloaded" marker indicating that a particular fabrication was completed using a schematic not loaded by the player themselves.

Item and robot schematics weren't even recorded in the original scoresheet, but have been added for 2.0, also aligned in a pleasing and readable manner.

Sample scoresheet 2.0 excerpt: Item/Robot Schematics.

Often times players will obtain schematics but not actually use them, either due to lack of opportunity or deciding not to, but either way it's interesting to see what schematics players are going after, and how they're acquiring them since there are a number of different methods (including four more that don't even appear in the above sample!).


Game and Options
Another area that got the formatting treatment are the last two meta sections, Game and Options.

Years ago they were very short lists with just a few entries, and output using different code than regular stats, so they were never actually aligned and this didn't seem too problematic early on. But now they collectively account for over two dozen entries and the difference between alignment and non-alignment is stark.

Sample scoresheet 2.0 excerpt: Game/Options (non-aligned vs. aligned).

As shown in the header earlier, the date format has changed, now also recording the start time in addition to when the run ended. Originally only the latter was included, but in my research I noticed other roguelikes recording both and this seems like a good idea.

Run play time and cumulative play time both have new formats as well. These were originally shown in minutes, whereas the latter now uses the gaming "standard" of hours to a single decimal point (127.3 hours is much easier to understand than something like "7636 min" ) and run time is shown using the HH:MM:SS format. Now real-time speed runs can care about the seconds as well

This is the first article in a four-part Building the Ultimate Roguelike Morgue File series.

[Kyzrati]

Building the Ultimate Roguelike Morgue File, Part 2: ASCII Maps
[Cross-posted from the devblog here--follow link for better formatting and light-on-dark style.]

Although there's only so much information ASCII alone can hold without color or a supporting interface, it's still worth it for morgue files to include a map of the area around the player at the end of the run for added context. For wins generally not so much, but such maps can definitely be useful for determining the tactical circumstances behind a loss. (That said, some wins while on the verge of death are only even made cooler with a final map showing a horde of hostiles on one's tail!)

Last time I covered the general organization of Cogmind's Scoresheet 2.0, but wanted to get into more detail with maps in particular since there's a lot to say/show.


Other Roguelikes
Three out of four of the roguelikes I surveyed earlier for their morgue file content include an ASCII map within it.

ADOM's morgue file is topped by a console screenshot taken at the end of the run, so naturally includes the surrounding area. Here I've taken a few maps from different morgue files to give you an idea.

ADOM morgue file map samples.

Unlike the others, DoomRL (DRL) reveals the entire map, regardless of whether it was explored or not:

DoomRL (DRM) morgue file map samples.

And DCSS morgue file maps show a relatively small area (interesting since it also has the largest maps of these three roguelikes), but are also the only ones to use Unicode characters--the other two are pure ASCII.

DCSS morgue file map samples.

Cogmind Style
For Cogmind I decided to go with pure ASCII. One of the big limitations of exporting a text map this way is that it can't show Cogmind's machines properly. These are drawn with CP437 (extended ASCII), but I want the entire scoresheet to be widely compatible and not require any special encoding, which means we have to forgo Unicode. (Not to mention non-ASCII characters can look especially weird depending on the font, and because they're narrow rather than square like in game, machines' appearance is otherwise significantly distorted anyway.)

An example of what happens when character encoding can't be interpreted correctly and requires manual/reader adjustment (not ideal!).

Well in most cases the type of machine is not terribly important, so I decided to draw all of them using a character not used elsewhere: the double quote. Interactive machines are certainly important, so their interactive piece is still represented by the appropriate capital letter, making it possible to distinguish that particular machine block from the rest. This is looking better:

The initial concept for Cogmind's scoresheet ASCII map style.

Here I've also added a border around the map view, which comes in handy when near map borders, or when the known map doesn't fill the available area. I left empty buffer columns to the left and right of the map, but not the top and bottom; this is because as a text file it will generally be viewed using a non-square/tall font, so the spacing looks more even this way.

In terms of area, Cogmind shows all known terrain and objects within a 50x50 area (the smallest), where areas outside FOV are output as whatever the player remembers to be there.

You'll also notice that debris is completely removed (anything that would just be noise and interfere with interpreting the map shouldn't be there, especially since there's no cellwise brightness we can use to emphasize/de-emphasize various elements). This was actually kinda hard to do for previously seen areas and required a bit of a hack to retroactively "erase" debris ASCII without misinterpreting actual item knowledge.

At this point I started testing out various different map styles. Do we want to be able to distinguish between FOV and non-FOV areas? How should unexplored areas be represented? I did tests of each to compare... (see legends)

ASCII map style concept 2.

ASCII map style concept 3.

ASCII map style concept 4.

ASCII map style concept 5.

I decided the last one is best, as it's not too meaningful to distinguish FOV vs. non-FOV areas, especally when doing so has the drawback of making the map harder to read. Much more important are the objects present, specifically the letters (robots).

On that note, I wonder if it would end up being useful to have a description of major features on the map, such as the names of meaningful robots and parts that can't necessarily be gleaned from the ASCII map alone (like technically an 's' could represent a weak robot, or a very powerful one, although cases like this aren't too prevalent, and some can be determined through other context clues).

Anyway, I worked out some kinks in the content and did some more tests. If you've played Beta 8, you'll probably recognize this place

Cogmind ASCII map style in Exiles lab.

Here's what the caves look like in this style:

Cogmind ASCII map style in caves.

Then I went back and added a way to see the edges of the map (as with the advanced.cfg showMapBorders setting):

ASCII map style concept 1 with inner/map border.

But after all that work realized such a feature is pointless if going with a style that marks unknown cells, which reveals the map border naturally xD

ASCII map style concept 5 without explicit inner/map border.

Duh.


Samples
ASCII maps aren't even in the public release yet, but patrons have been trying out the system in recent weeks and I'm already really liking the results as I examine scoresheets. Here are some samples from real runs...

The classic Assembled and Demolishers in the Mines. Killed by a grenade.

Another sample Mines death, albeit to more mundane causes (a Swarmer patrol).

Getting dogpiled in a late-game branch. Mistakes were made.

Beta 9 makes Garrisons very inviting. But this doesn't make them any less dangerous!

Clearly there was some serious exploding going on here.

Fun
Not long after Cogmind's map could be output in ASCII form for the scoresheet, I realized I could do something with them that I'd wanted to do for a while but didn't have the means.

REXPaint has the ability to import text files (via the -txt2xp switch), so I could take map views from Cogmind and doctor them in the editor! I do a lot of map editing in REXPaint, but it's mainly for prefabs, and of course it's in the REXPaint-&gt;Cogmind direction. With the direction reversed, it's easy to dynamically play with other font styles and colors using the editor's features.

For fun I took a sample map and colored it in the original C64 font:

C64 Cogmind

The original ASCII text as it appeared in the scoresheet.

And a screenshot of the area in game.

I don't have any practical applications for this right now, though I recall in Cogmind's early years I did consider using something like this for testing purposes and/or to compile marketing materials.

Anyway, it's a thing, but the main point is having maps improves yet another facet of scoresheets :D

This is the second article in a four-part Building the Ultimate Roguelike Morgue File series.

[Kyzrati]

Building the Ultimate Roguelike Morgue File, Part 3: Mid-run Stat Dumpss
[Cross-posted from the devblog here--follow link for better formatting and light-on-dark style.]

In the first part of this series I described how I didn't want to get into fundamental changes to the stat system while in the middle of development, leading me to completely avoid modifying the underlying architecture despite greatly expanding the number of stats recorded. Among other limitations, this is also why we've gone for years now without a way to examine stats in the middle of a run. But that ends now!

Clearly "mid-run stat dumps" (AKA character dumps) are a really useful feature in a roguelike of decent length, and even more so in a roguelike with an active community that enjoys discussing strategy. Some reasons to support dumps:

• Share with others the full details of runs still in progress
• Check the current scoring breakdown and other stats
• Help track progress towards in-run achievements or other goals (this would be nice to have in game, but Cogmind has hundreds of achievements and it would be a ton of work to implement a way to review this progress in game, so I'm not sure if that will exist)
• Make the system easier for me to debug, and work with in general (I have been loving the ability to output stats at will since this feature was completed! Previously having to self-destruct and reload all the time was a pretty annoying and repetitive sequence compared to just a single command...)

I'm sure there are more, or more variations on what I have above, but the point is: they're useful!


Form and Architecture
Years ago when thinking of this kind of feature, I envisioned a mid-run stat dump as an alternative short summary of the run's progress and (most importantly) current situation, different from scoresheets. But other than the advantage of keeping it concise, that doesn't really make sense when we already have a great source of comprehensive info to draw on--the scoresheet itself. Stats for the scoresheet are maintained throughout the run and (mostly) ready to be output at any time, so why not just create an "in-progress scoresheet" on request?

So that's the form we're aiming for here, basically just a scoresheet-on-demand

This did, however, require a fair bit of work.

The original code for stats in Cogmind was quite simple: Have a class storing all the data in a few simple arrays, and when the run ends mix it in with whatever other player/run data is necessary, rework it all into a printable format, and write it to a file.

The problem is all of this was done in a single function--there was essentially no division of responsibilities, although clearly we can't use an identical process for mid-run stat dumps because there can no longer be an assumption that the run is ending! For example the original code would even change game data as part of its work without worrying about negative repercussions, since the run was ending anyway

And as you've seen in the samples before, Cogmind's scoresheets contain quite a lot of data, so there was a lot to go through...

The scoresheet architecture diagram that's been sitting on my desk for months now, from when I first sketched out the difference between what we had and what we needed.

In terms of architecture, the main goal would be to migrate everything from a linear system to a properly compartmentalized one which could handle three separate possible outputs independently of each other: scoresheets, mid-run stat dumps, and uploading of online stat/leaderboard data.

The most important part here was separating out all the necessary data into a new intermediate format, basically a new data structure outside the game data that contained everything necessary for any of these purposes without relying on the game. Technically as described before I already had such a separate structure outside the main internal game data, but it still relied on a lot of support from the game data itself because that was what was easiest at the time . Now the code has been restructured around a whole new intermediate data structure that purely contains all the raw data necessary for any desired final form.

Although I haven't done it yet (though it will come soonish), this is also a stop on the road towards having an online stat database, so the dump feature's development comes at just the right time.


Content
What's inside a mid-run stat dump? Well, it's almost identical to a scorehseet, simply stopping at the current point, except for one main difference: there's no Result to show in the header. I mean... of course there isn't

That said, it'd still be nice to use the expected "Result" line in the header to indicate that the run is still in progress, and show something else interesting instead (rather than just "in-progress," "stat dump" or something else mundane), so I came up with some new content for it.

I thought it would be neat to provide a short one-line summary of the run as it stands, which in cogmind basically boils down to two things: your build, and your status. Pretty simple, although each half of this would require a new system and take some time to realize.


Build Categorization
I started out thinking the first element would use terms along the lines of what we've come to be using in the community, e.g. "flight hacker," "infowar combat," and so on, sketching out some related notes on how to make that determination.

Initial incomplete build categorization notes.

At first it looked like it might be in the form of [prefix][main][subtype] (e.g. infowar combat hacker), with the possibility of other hybrids mixed in there and whatnot. It's a practical approach, but also given the kind of options I saw it was kinda boring and probably overcomplicated. (During this process I drew on my character archetypes post about Cogmind from a while back on r/RoguelikeDev, which you might find interesting if you haven't seen it before.)

So I thought what if we had it instead detect builds as something more akin to true classes? The focus would still be on clear, functional names rather than creating whole new ideas unique to Cogmind or anything crazy, but it would be more fun than the dry (and even more limited) terms we normally use.

Unlike many roguelikes/games where you select a class to play, as you know Cogmind is a dynamic, flowing experience and it's interesting to explore classification of these builds as they happen.

To this end I came up with a chart of characteristics and 13 names to go along with them. In the code, a long series of nested conditional statements determines which "class" most closely applies to the build.

A sample from the beginning of the base class determination--it continues for a while after this, filtering further and further down through possible builds based on state summary variables. Lots of if-elsing

Then, since a single name would have been too limiting and many more creative combinations can be captured via a two-name system (kind of like multiclassing!), I came up with an additional 15 special designations that can more specifically describe some aspect of the current class.

Unlike the main designation, this one is determined via a point system. Your build earns points in each category based on its parts (and sometimes other factors), and whichever category accrues the most points is applied as a modifier to the class. If nothing applies very well, then only a single base class is used.

Cogmind is not constantly recalculating your class. That would waste a lot of time, and also be pretty inaccurate when you're doing things like transitioning between builds, or lose a part or two for just a little while or are in the middle of swapping things in and out for whatever reason. What I did there is have it not only calculate only every so often, but also wait until there has been a decent stretch of turns without any actions that affect your loadout, like attaching, dropping, swapping, etc. Only when your build is considered "stable" will it take another sample for analysis.

In the end this automatically determined "build class" appears in the format [special modifier]-[base class], where the modifier is empty if nothing really applies. Everyone starts as a Mutant, the default base class, since that's more or less what Cogmind is at heart, a non-specific machine attaching a random variety of parts while not really capable enough in any one area to be noteworthy.

There are currently 195 multiclass combinations (plus the 13 pure base classes), some more specific and less likely to be discovered than others. Below are a few screenshots of my first test run in which I traveled and battled through five maps as I changed my loadout around and saw how the game classified it. For this purpose I put a nifty "class readout" right at the top of the parts list. (I wasn't aiming for any particular builds, this is just what I ended up with, among others I didn't screenshot.)

Build: HAULER-TANK. Armor and firepower!

Build: HAULER-GUNNER. A more offense-oriented combat build.

Build: SKIRMISHER. Combat bot supported by infowar utilities.

Although the class indicator seen on the HUD there was originally for testing purposes, I later decided to include that as an advanced player option as well. It's kinda non-immersive so I don't want it appearing there by default, but it's a fun thing for veteran players to turn on.

In designing the above system, I realized it could be expanded into an interesting permanent part of the full scoresheet, as described in the first part under the Build section. Thus we get two new scoresheet sections:

Sample scoresheet 2.0 excerpt: Class Distribution.

Sample scoresheet 2.0 excerpt: Dominant Class.

I'm happy to see that builds aren't whipping all over the place, which would otherwise be likely if the classification system wasn't stable enough. Having relatively broad definitions helps in that regard.

Builds also have a place in the History Log, to be described in Part 4 of the series.

But getting back to the idea of mid-run stat dumps and that Result line, this is where it all started, just to drop the class name in there like so:

Sample mid-run stat dump header, with build classification and situation analysis.

There you can see we have the current build type, followed by a second piece of information we'll get into in the next section.


Situation Analysis
Since we can't describe the final result of the run, I thought it would be interesting to try to summarize the current situation in one word. This is determined on a scale from dire to wonderful.

The full situation analysis scale for a run's status.

The default is "fine," and a number of factors are checked to simply raise and lower the scale to arrive at a final value. So having some negative factors mixed with some equally positive factors will still average out to a "fine" situation, but having extra factors in a given direction will start pushing the rating towards an extreme.

The calculations are all quite simple, just checking factors that we has Cogmind players tend to rely on when considering what's truly important in terms of how we're doing. Some of these are pretty common to roguelikes in general, like having low HP is not good, being surrounded by enemies is bad, and you don't want to be completely defenseless.

Here's a general list of factors used to analyze the situation:

• Core integrity
• Speed (can't be ridiculously slow)
• Essential parts (missing power or propulsion is dangerous)
• Spare parts (this is never included as a negative factor, but it's always a good thing to have spares of everything)
• Part condition (empty slots count against this)
• Matter levels
• Armed enemies and allies nearby
• Known exits

The entire thing is only 77 lines of code, but seems to work pretty well. Like build classifications I added a current situation analysis indicator to the HUD for testing purposes so I could see how it was changing throughout a run, but I don't plan to make this even an optional feature for players.

Current situation analysis debug mode view (you can tell it's not for release because clearly it shouldn't be lowercase).

If you want to see that in action, I was using it in

where I ran the debug version of Cogmind. Actually for a simple example, here's a debug shot in -9/Materials:

Situation analysis: "good."

UI
Scoresheets are normally produced at the end of a run, so how do players get a mid-run stat dump?

There is a new command that can be used on the main UI, Shift-Alt-s (for "stats"), which creates the file and puts it in a new separate directory in the Cogmind file structure, /dumps/.

Of course this also needs to be mouse accessible, so for that we conveniently have a logical place to put it: the Records menu.

Dump Stats button in the Records menu.

Even just in prerelease so far players have already been using the stat dumps, not to mention this feature has proven quite useful for my own needs whenever it comes to testing or debugging anything stat related.

This is the third article in a four-part Building the Ultimate Roguelike Morgue File series.

[Kyzrati]

SITREP Saturday #47: Under Siege



Siege mode is here! Wait what? Siege mode?

Yeah, this concept kinda came out of nowhere because suggested by patrons who came up with a bunch of ideas and voted on the new mechanic they wanted to see in Cogmind. The full list and voting results are here:



I like the idea of having a "siege mode" for treads since we already have conditional "overloaded" functionality with some other propulsion, but before now treads didn't have this and it provides new tactical options depending on your situation and capabilities.

In short, you exchange your mobility for combat buffs, becoming immobile but gaining bonuses to accuracy and coverage, with even some damage resistance.

Here's a demo of some of the relevant interface bits, showing how it takes time to enter/exit the mode (and during that transition you're more vulnerable):



And yes there's cool transformation sfx when you fully enter siege mode ;)

There'll be a blog post that goes into more detail about the design process behind siege mode, all of the mechanical aspects, and even a discussion of the tactical implications, but I'm still working on that so I'll link to that in the next announcement.

This week I did already start streaming a new run using a nearly-complete version of Beta 9 to show off some of the latest features, including siege mechanics! So naturally it's a heavy combat run, that in combination with a so-called "crit-stacking" offense, which I've wanted to try for a while, and now is a good opportunity because enemy crit immunity has temporarily (?) been toned down for Beta 9 as an experiment.





Part 2 will be coming next week.

The Good Stuff

Also as voted for by patrons (albeit from a list of potential features I provided) manual hack autocompletion got an overhaul to bring its behavior more in line with regular editor consoles, including even a selection menu to see the available options.



And my favorite part: it even works with schematics, listing all those valid at the current machine given the current depth, with partial name matching of course, and tab autocompletion.



On the part management QoL side of things, in order to facilitate swapping back and forth between two parts (which some people like to do before/after combat with certain builds), after a part swap between the inventory/attached lists, those two parts are remembered ("paired") so if you want to swap back that's always possible via the 'Y' menu option:



Here's a demo of the autopair swap feature in action:



And I don't imagine it'll get a lot of use but it was one of those "do it because I can" things: All remembered autopairs can be swapped simultaneously if you really want to!



The Unbroken Stuff

I've already fixed all the known bugs from Beta 8--it's been a while so a lot of little things had piled up, but as always part of getting the next major release out the door means cleaning up any reports from the previous one!

The Terrain Scanner activation animation was unintentionally revealing the positions of traps via little blips. In fact, it was technically also revealing some internal script trigger points as well, which was how one player first discovered this! And then another player on Twitter mentioned that they thought the trap revealing was a feature xD. No this is totally not a feature, please use the other available means to detect traps rather than this rather tedious and non-Cogmind-like method! You see the blips in there?



Oops, the scanning list was revealing non-scannable prototypes by color even when unidentified. Fixed:



The Random Stuff

Lots of other little improvements here and there as well as I cleared out my TODO list for this release.

Inventory type-wise and mass-wise sorting also subsort by integrity



Parts ejected by machines now push away other parts, rather than rolling the ejected part over others.



Prop explosion data now shown in the scan window, making this more apparent without having to open the info window.



And we can always use new explosions.



30,000 Data Points? Yes, Please!

You know how Cogmind's extensive scoresheets have always contained hundreds upon hundreds of data points to paint a fairly detailed account of that run's highlights? Well let's multiple that by... a lot.

The scoresheet format has been revamped in a big way, reorganizing all those many stats into more (and better) categories, adding a range of entire new categories, and significantly enhancing each scoresheet's ability to paint a clear picture of the run with history logging, automated build class identification, an ASCII map of the final surroundings, and even separating all those data values out into their per-map stats!

I've given this topic new "meta feature" in-depth coverage on the dev blog, writing a massive dedicated 4-part series on it, and as you'd expect, each article is packed with samples, diagrams, and detailed explanations.

Building the Ultimate Roguelike Morgue File, Part 1: Stats and Organization - Examining the process of developing Cogmind's scoresheet and its content as it evolves into its final form.



Building the Ultimate Roguelike Morgue File, Part 2: ASCII Maps - Designing the ASCII map style for Cogmind's new scoresheets.



Building the Ultimate Roguelike Morgue File, Part 3: Mid-run Stat Dumps - Why and how I'm including accessible character dumps in Cogmind, including automated build classification and a situation analysis system.



The Ultimate Roguelike Morgue File, Part 4: History Logging - Exploring the structure and content of full-run history logs as a way to record notable events in a roguelike.



While on the subject of blogging, I wrote another article about Special Game Modes in a Roguelike Context,  talking about stuff like their value and types.


   
Hard Still Means Hard

Another big change coming to Cogmind is the rebranding of difficulty modes, which I hope will help a lot of people. No more automatically defaulting to the hardest mode and calling the other two options "easier" and "easiest"--from now we have Explorer, Adventurer, and Rogue!

A lot of people don't even realize Cogmind has difficulty modes, and has for a couple years now, so that option will be front-loaded into a new menu seen the first time the game is run, before even the title screen:



Explorer/Adventurer modes even come with a convenient quicksave/load system, which I hope will help a lot of people better enjoy the game (Rogue mode will continue to enforce permadeath).

There is of course a blog post on this change, Rebranding Difficulty Modes, talking about design, reasoning, and player expectations. Another one specifically about the save/load feature will be coming as well!

Flying and Hacking

Last time I reported that I'd begun streaming a flight run, which was eventually finished and made it into super spoiler extended-game areas. There were five parts in total, with the second starting here (you can find the rest from there):





I also did another streaming series of a run using the new upgradable RIF abilities. That starts here:

https://www.youtube.com/watch?v=ciCC37FuFac

Zyalin drew our late-game build there <3


And at one point earlier in the run I was also crazy enough to continue along with rather high corruption and ended up causing a misfire to destroy the exact thing I was after--Zyalin sketched that scene, too xD



Of Course We Have More Art

Zyalin drew Tone's massive-storage late-game bothacking borg build, with allies in tow.



He also drew this...



...which makes more sense when you learn where it came from, the time in chat where I was fooling around with making Cogmind a 2x2 bot by changing a single value in the game, and... it actually sorta worked and was playable though the sprite became a conglomeration of several other non-combat bots as well!



Zyalin's imagining of a "combat version" of that particular NPC everyone loves to murder for their amazing hackware.



And I really love this piece, a huge thief-inspired bot that rips parts off:



Zyalin has finally set up a website for his fan art of various games, including Cogmind, so if you want to see some of his other great work, and a lot of his past Cogmind pieces, check that out here. (Today's opening art is also a work by Zyalin, giving his impression of siege treads)

PlasticHeart, originator of the idea of "cogmics" (the 4-panel Cogmind comics now created by a number of players) has also collected a bunch of their past work on a new DeviantArt page here.

For his own "work of art," in July JakeThyCamel announced he'd been doing some wonderful work on an online HTML-based version of Cogmind's manual, filled with links and supporting screenshots. The conversion isn't quite complete (I'll bring it up again when it's done), but it's definitely getting there and worth checking out.



Oh look, there's some of my art, too. Stuff coming to a Beta 9 near you :)



Platforming

If you hadn't hear, this week Steam launched the new Library beta, and for that purpose all us devs had to make new assets to fit the new format. So if you opt into the beta you'll notice a couple things, one being the fact that quite a few devs have not updated their assets so the games don't show up very well, but assuming you own Cogmind you get to see this new box art in action :D



I made this and other new stuff a few months back when Steam first announced the upcoming changes, then totally forgot about it. It wasn't until players started showing me the game standing out in their libraries that I realized it was live :P



More recently I certainly remember the headache of suddenly having to go back through and migrate old announcements to the new system because I couldn't live with Steam automatically classifying all of Cogmind's previous updates as "small patches" :P. Cue hours of figuring out the system and creating new images in the right format! In the end it's at least a little more modern and less clunky than it was before (if we ignore the fact that comments are now harder to reach and see...).

Here's a couple excerpts from the editing view when I was working on that:



I'm quite happy that Steam integrated Proton and for a while now it's become even easier for Linux players to enjoy Cogmind via Steam Play. Cogmind is now rated Platinum in ProtonDB, so keeping the software super minimal and fixing those Wine-specific issues was definitely worth it :)

In less good news, the newest macOS is dropping support for 32-bit apps, which will mean those on the new system might have a harder time running Cogmind. I believe it'll technically still be possible, but you'll have to approve it or something like that? Or maybe because Mac users are already running it under some form of emulator anyway it might work? Not really sure about these things I guess we'll see.

Wizardry on the Horizon

Beta 9 is coming.

No date for you yet, but the only feature remaining before it can be released is the database and leaderboards side of things,
and while not every one of its features needs to be ready immediately, 1) it's important to lay a good foundation and 2) the basic version definitely needs to be functional for the Beta 9 release because I want to see the initial usage of the rebranded difficulty modes given the new menu and related features.

I can't be too sure about the timeline because I have someone else helping build it--I normally work alone but this is outside my area of expertise so that wasn't really an option here if I wanted it done well :P

In any case, regardless of when Beta 9 is done, a longer dev cycle just means more time to throw in extra little features and content before it's out!

[Kyzrati]

Cogmind Beta 9 is out! As big as two major releases in one, it's got upgradable bothacking, siege mode for treads, Explorer/Adventurer modes with optional permadeath, even more detailed scoresheets, and much more...

In the works for more than half a year, this release brings us pretty close to 1.0, at least based on the fact that there's little left in terms of "must-have" features on the roadmap.

Even just the changelog won't fit in a TIGS post, so I'm just going to point to the full release notes, demo images, and changelog over on my forums.

Here's an overview of the notes in image form:



And the same for the changelog:

[JobLeonard]

What's insane is that this feels like one of the smaller changelogs you've ever posted here

[Kyzrati]

Haha no seriously it's actually the longest ever, but yeah it could feel short since the entire post didn't fit on TIGS and I didn't want to bother to split it up into... let me count it... three different chunks/posts just to fit xD

Even on my own forums which are less restrictive I had to up the character limit specifically to post the full release announcement, which I've never had to do before, wow.

[Kyzrati]

Hot on the heels of our massive Beta 9 update, time for an extreme change of pace...

Beta 9.1 "Abominations!" fixes a few new issues from Beta 9, but more importantly adds a special Halloween event that's been in the works for a couple weeks. This event's special mode includes:

• 20 new robots, most with new capabilities and mechanics!
• 1 new hidden map, complete with boss
• other event-specific mechanics

(Please excuse the lack of detail, it's a surprise!)

Full release notes can be read here, including a link to a lengthy article covering the the mode's content and entire design process, for those who don't mind spoilers.

[Kyzrati]

New release! With 9.2 Cogmind gets Rich Presence on Steam, an explicit colorblind option, Abominations mode improvements, yet more scoresheet updates, plus the usual bug fixes and more.

For the full release notes and feature demo images, see here.



Cogmind Beta 9.2 "Robotic Riches" (191112) changelog:

• NEW: [Steam] Supports Rich Presence, sharing current build, location, and status with friends
• NEW: [Steam] Option to deactivate Steam Rich Presence (advanced.cfg: disableSteamRichPresence)
• NEW: Options menu "Colorblind Adjustment" setting to modify certain color schemes to be more colorblind friendly
• NEW: Option to display remaining integrity in item/robot popup labels (advanced.cfg mapLabelsShowIntegrity)
• NEW: Option to fully highlight visible cave-in areas rather than the low-distraction default (advanced.cfg highlightCaveinAreas)
• NEW: Manual explicitly mentions "Ctrl-Alt (Hold)" also highlights areas that can cave in
• NEW: Manual explicitly documents "Ctrl-+/-" as global volume up/down commands
• NEW: Scoresheet records current movement-related variables under Cogmind header
• NEW: Scoresheet relative alert level percentages now also recorded on a per-map basis
• NEW: INVERT renderFilter variable
• NEW: [Abominations mode] Explicit log message when Paradox Anomalies repair Cogmind parts
• NEW: [Abominations mode] Final boss also has unique parse text
• MOD: [Abominations mode] Fire/Sundering Anomalies won't appear until -7/-8 respectively
• MOD: [Abominations mode] Negative Anomaly effects no longer applied to themself if affiliation modified via Field Lobotomy Kit
• MOD: Complex 0b10 capable of remotely opening blast doors under certain additional circumstances
• MOD: Scoresheet Parts and Peak State lists now align part names taking into account any prefix
• MOD: AI combat pathfinding and targeting behavior updated, less likely to be blocked by non-combatants
• MOD: "More Dakka Please" achievement condition more specifically requires kinetic projectiles
• FIX: New pushing algorithm for machines releasing parts might unnecessarily destroy parts under special circumstances [Valguris]
• FIX: External issues likely caused by Steam cloud for runs played across multiple sessions could cause incomplete scoresheet achievements list [Valguris]
• FIX: A8 manual hacking code wasn't reported in message log in a certain scenario, even though properly received [Valguris]
• FIX: No longer able to enter Proximity Caves directly via large 0b10 bases [Valguris]
• FIX: Possible crash under extremely rare circumstances involving a controllable ally attempting to attack Cogmind [Gitida]
• FIX: New scoresheet game number tally incorrect for Rogue mode if previously played Adventurer or Explorer mode [Solar Sloth]
• FIX: Part autopairs weren't remembered between maps [Benjamin]
• FIX: New scoresheet system wasn't handing out score threshold-based achievements for current run, instead based on previous run in same session [5taquitos]
• FIX: New scoresheet "Challenges" subsection did not list applicable challenges [sideriver81]
• FIX: Field Recycling Units could be used to refine matter into even more matter [NikolayAg]