Development Blog

Death is fairly frequent in roguelikes, but the fun doesn’t stop there! We usually still have access to post-game “content” in the form of text files detailing how a particular run played out.

The typical traditional roguelike player tends to love statistics describing their performance, and detailed morgue files are a good way to satisfy that desire, while at the same time enabling players to show off achievements, get opinions from other players, and review an experience to perhaps learn more from it. Looking back through an overview of their game, a player might discover something they hadn’t noticed before, or the file may directly reveal unknowns like the fully identified contents of one’s inventory. (I had a potion of what?!)

Other Roguelikes

A lot of the major roguelikes have been modernizing their community services with extensive public databases that allow for searching, sorting, and all manner of additional features. (References: DCSS Online Players and Scoring Overview; ToME4 Characters Vault; Angband Ladder; Nethack High Scores) I’ve written a little bit about Web Support in Single-Player Roguelikes before, while here we’ll just be focusing on a survey of text info data referring to a specific run/character.

DCSS begins with a summary of vital information, followed by:

• basic character stats and status
• detailed descriptions of each inventory item
• dungeon locations visited and features discovered
• message log and map immediately before the run ended
• complete list of kills
• long list of important chronological notes from throughout the run
• chart containing a breakdown of all major actions taken

I really like the density of information at the top, probably the best example of a character file where so many details are available without scrolling--even equipped items are summarized right there. The actions chart found at the end is an interesting tool for reviewing general strategy and comparing it to other runs.

DoomRL also begins with an overall summary, though subsequent sections come in a somewhat unexpected order, seemingly aimed at front-loading information reflecting final results:

• special levels
• awards earned
• snapshot of the map/surroundings where the run ended
• basic character stats
• equipment and inventory items
• complete list of kills
• history of important events
• message log immediately before the run ended
• meta information comparing previous runs

My favorite part of this one is the history, which in describing only important events in a condensed format does a better job of telling the story of the run than a full message log can. I’d like to incorporate something similar into Cogmind, later when story elements are in place and such a feature would be a lot more meaningful.

Meta info tracking the player’s progress from other runs is a nice addition, too, though here it’s quite limited.

Angband’s file opens with a very dense block of character stats, then:

• detailed equipment list
• carried inventory items
• home inventory items
• history of important events and when/where they occurred
• UI/game options

As with DCSS, I like the density up front, the one drawback being that it is more complicated to parse when writing code to scrape the data. The best way to handle this is of course to store the information in a separate format meant to be parsed, then it can be output in any format necessary. Nethack, for example, does exactly this with its Xlogfile format, but it surprisingly doesn’t have human-readable morgue files, at least nothing official. The online system linked earlier does record and display basic run information, however.

ADOM begins with a complete screenshot of the final game state, map, stats and all, followed by:

• character background
• equipped items list
• backpack (inventory) contents
• weapon skills
• skill list
• spell list
• major achievements
• artifacts generated
• other player characteristics
• monsters vanquished
• meta data (play time, version)

The screenshot opening is a nice approach, as it provides a pretty effective summary, which honestly a good UI should be capable of in the first place--putting it directly into the log reflects that effectiveness. ADOM is capable of outputting the character log in both an abbreviated and verbose form (the latter is what’s shown above).

Format

All of the above games provide their morgue files in a simple text format, enabling players to easily share/paste them on forums or elsewhere. Of course an alternative is to just link directly to an online record, text or not, which is currently the only way to share complete character information in ToME4, for example. That does have the advantage of providing a more interactive experience for understanding the contents (ex: ability descriptions), though the information itself isn’t as easily posted elsewhere in a predefined format.

Terminology

There is no common term for referring to these files throughout the genre. In fact, there are almost as many terms as there are games…

• Character File: The official term for DCSS morgue files, and the most generic of the bunch that doesn’t really have any additional connotations, except that it perhaps doesn’t imply that a run has ended. Technically this one’s generic enough that it could be confused for a save file.
• Morgue File: Generally associated with DCSS as well, though not an official term. (It happens to be the one I’ve picked up on.) The name implies that a character is dead, and therefore may not feel all that appropriate for victories (although as we know death is more common). That said, your character will die eventually, right? :) (On that note, even when you win UMoria, it will indicate that you died of “ripe old age.”)
• Character Dump: This term implies that the information might have been exported from a game still in progress, though Angband uses it even for completed games.
• Post-mortem Character Dump: DoomRL adds a qualifier to indicate that the run has actually ended.
• Character Log: The ADOM community uses this one (though it’s not written anywhere in the file itself); it’s pretty generic and applies well enough to this use, although there is that chance of confusion between a record of everything about a character and just the message log itself.
• Character Record: Another generic term used by some games not discussed here.
• YASD/YAVP: Colloquial abbreviations that can just as easily refer to the files themselves as they can the final outcome, adding a little extra meaning since we know both that the run ended and how.

Not that terminology is super important; I just thought it was interesting to note while doing this survey.

Cogmind Score Sheets

I’ve always called Cogmind’s morgue files by yet a different name (of course…): score sheets. When first created the intention was to essential just show a score breakdown and a handful of character stats, but even early on that changed rapidly and score was left as only a very small portion of the file contents…

History

Shortly after Cogmind’s birth for 7DRL2012 I decided to hold a player tournament for fun, but felt that basing it on score alone wouldn’t by very exciting, so the first update in preparation for that was to add to the score sheet a variety of other collected stats that described the player’s run. Not just the number of kills on enemy type X, but also some less obvious values like “number of tactical retreats,” “shots fired from each class of weapon,” “number of items of each type lost to attrition,” etc.

At the time there were 78 variables, along with a few separate lists of varying types. These served as the basis for a more interesting tournament while I was still working on improving the game by implementing feature requests.

Then of course as a little side project the game was put on permanent hiatus with no plans to revive it.

Then of course “no plans to revive it” turned into making it something really big, and throughout more than a year of pre-alpha development I kept adding more of those score sheet variables as new features were added (and I came up with more ideas).

Now we have 350 of them.

Score Sheet 0.10

After completing the above survey of morgue files in other games, I’m surprised that none of them go as far as to record numerous statistics describing events or highly specific actions that shed light on player behavior, or derive other meaningful stats from the game data. (The DCSS action chart is a notable exception, but still limited in scope.)

Perhaps it’s that Cogmind is much more a tactical game than a strategic one. Most roguelikes on the other hand have a strong emphasis on long-term character development and therefore recording and reporting information about the player characters themselves already tells you so much. That’s where a majority of the gameplay decisions are reflected, whereas in Cogmind there is almost no emphasis on character development at all; instead it’s a game about making minute-to-minute decisions without certainty that your condition or form will be even remotely similar on the next floor, or even around the next corner. As such, the focus of a score sheet should be more about actions, behavioral statistics, and factors external to the character.

To be more specific, here are some of the variables recorded for each run in Cogmind:

In any case, without additional variables like these Cogmind’s score sheet would be pretty barren. Having all the extra data also came in handy when the recent Alpha Challenge 2015 took a page from the 7DRL tournament playbook and added lots more achievements based on them. With data like this there are also the many useful graphs that come out of comparing runs or combining data from multiple players as shown in the previous post about player metrics.

As with the other games, let’s look at the header of a Cogmind score sheet then discuss the contents:

(The first thing you’ll notice is it doesn’t use horizontal space very well. More on that later.)

Cogmind begins with a complete score breakdown, then:

• player stats
• attached parts
• inventory contents
• peak state
• favorite item of each type and subtype
• many gameplay stats (e.g. the earlier variable lists)
• list of identified prototype items
• meta data (play time, UI preferences, etc.)

So-called “peak state” is very important, added because unlike characters in other roguelikes, most Cogminds die naked and alone. Sad, I know. We’d never know what a player’s equipment really looked like if only recording it at their point of death (unless they made it to the surface, as in the sheet shown above).  So the game also shows what a fallen Cogmind looked like at their best, defined as when the combined combined rating of all their attached parts is at its highest.

Because Cogmind’s gameplay revolves tightly around the items you use, which may change significantly throughout a game (since there is no such thing as skill/class/race limitations that might lock you out of using anything in particular), simply looking at peak state is only informative about a relatively short duration of the run. To tell us more, there are lists of favorite items of each type, further divided into subtypes:

Taking the bottom-left list as an example, while that player may have been a hovering hacker bot at their peak state, according to their favorites they spent most of the game as a treaded heavy weapons platform.

Format

Having become bloated by simply tacking on more and more variables, while the content is sufficient the score sheet’s overall format is far from perfect, with its combination of vertical lists and simple VARIABLE=VALUE format all the way down. All that horizontal white spice should be put to work as we see in the DCSS and Angband morgue files. Many variables could be expanded to show more details, reorganized into meaningful charts, and more…

I’d really like to redesign the entire file to better condense the information, though as mentioned earlier that’s a problem for parsing. Using two files, one machine-readable and one human-readable, isn’t the greatest solution since players tend to share human-readable files so there would be no way to easily import a file shared that way. However, seeing as the game directly uploads the score sheets now anyway, maybe that would be a route worth considering. Upload a non-human-readable version of the data which is easy to parse, while separately outputting a local text file for the player’s own records.

Additional Post-Mortem Features

Like many other roguelikes, at the end of a run Cogmind shows a summary window. It contains a complete score breakdown (there aren’t all that many score components) as well as select stats, serving as an abbreviated version of the score sheet.

Because a full message log is too verbose to include in the score sheet itself and there is no short version yet, that is not included. Instead, in the options menu the player can choose to not save it (the default) or output it to either a text or html file. The latter has the advantage of being able to use the same colors as the in-game log, making it easier to parse.

I thought this would be enough, but players have since requested even greater detail in the output logs to better follow progress of the game when re-reading it for learning purposes.

The Possibilities!

Outside the existing score sheet and log files, there is the potential for quite a few other related features that serve similar purposes, or present the same information in a different form. Keep in mind that none of what I mention below is 100% certain to happen, but with unlimited time (haha) I’d love to be able to at least test, if not implement, many of these features:

Dumps

Mid-game character dumps are useful for sharing progress and getting feedback online, so it would be nice to have a dedicated way to do that.

Image sharing is so common on the web now I’m not sure how many players would bother to use a text-based dump option if available. The latter is less readable due to lack of color information, and any time someone pastes/views it without a monospace font it would look terrible, but I put together a mockup anyway:

The current stand-in method for character dumps--a simple screenshot of the HUD--already works pretty well (and is what players have been using) since it shows nearly everything you’d want to know. Its primary drawback is an inability to show more than 12 inventory items at once, an issue for some combat builds. Screenshots are also exceptionally wide for those players using high resolutions since it uses their font settings, making them harder to view on smaller screens.

By rearranging some of the existing windows I put together a mockup of a somewhat more condensed “image-style progress dump,” though this one doesn’t look so great, and is too wide.

Instead here’s an alternative mockup of a truly condensed version without any secondary information--it’s nice and tight, and includes space for a lot more inventory items, but no map:

Even cooler would be a way to output your current build--or peak state from a run--using the game’s ASCII art to represent the items. Unfortunately at the high end you can have so many parts that the combined art wouldn’t fit within any reasonably sized image.

Score Sheet 1.0

By the time the score sheet is complete, it should include not only more stats, but also expand to contain a written summary of a run’s history, told like a story, as well as a world map showing the route taken through the world.

Along with the score sheet, there might also be an option to output an accompanying image of the entire last floor explored (not just the part viewable on the screen). This wouldn’t uncover unexplored areas (which would too easily reveal secrets), but players could at least learn something about map layouts without having to try to map it themselves (we’ll leave that practice in the 80s, or to games with smaller maps). The problem there being that maps can get quite huge, not to mention the data loss to corruption by this point:

It would be a nice addition if the map also highlighted the specific path taken through the map.

Long-Term Performance

For those players who can’t or don’t want to upload score data, we could add a local history of personal high scores. Taking that a step further, we know that roguelike players appreciate more data, so why not track even more performance indicators over time.

Currently the results of each run are stored and viewed in complete isolation, except that each record shows the total number of runs that came before it, and a meta data file stores which items have been discovers and allows their art and usage counts to be viewed in the gallery.

I can see this being a huge development time sink for too little value if not limited to only a handful of the most useful data.

Another much simpler yet more granular approach to progress, is to have a place where players can review what discoveries they’ve made in the game so far. We already have this in the form of an “art gallery” that shows all the items collected throughout previous games, including their name, ASCII art, and how many times each was found and used (plus of course a name chosen by the item’s associated early supporter as a perk).

This feature is a great incentive to keep players exploring, while showing just how much more there is to discover (a lot!). Recording the number of times each item has been used also gives this feature some statistical value for even those players who’ve discovered most of the items (discovering all of them is impossible at this point, since many of the best ones can’t yet be found).

It would be nice to expand this to include other parts of the game, such as types of maps and robots (however, I don’t believe I’d be drawing the latter).

Online Database

As mentioned before, it would be nice to have an online database with sortable tables and customizable graphs based on the data. Before we get to that point, I may further expand the current leaderboards by increasing the number of generated html pages to at least include some sortable charts that also link directly to individual records. I’m not rushing into that since I would want to make sure it’s somewhat future proof when it comes to new versions.

For the tournament I already wrote a data parser which scrapes a directory for all of its score sheets and compiles everything into a single CSV file. That formed the basis for the stats and analysis I shared earlier.

 

Update 190724: Since this original article I revisited Cogmind’s morgue files to greatly expand them even further, and wrote up a series of articles about what goes into “Building the Ultimate Roguelike Morgue File.” Cogmind’s leaderboards and online database have also since been revamped.