Official development blog

Achievements UI: Design and Implementation

Players not only appreciate a game having achievements to begin with, they really appreciate it when said achievements are available without Steam. A sizeable chunk of players don’t use Steam for whatever reason, so having achievements be a Steam-only feature would leave all of them out of the fun and benefits described before! Achievements are essentially a form of content in their own right, so it’d be unfortunate to restrict that content to a subset of the player base. I’ve heard a lot of praise for this decision, both with regard to Cogmind and other games that have taken the same approach in the past.

Of course supporting achievements independent of Steam does involve a lot more work! At least on the implementation side there’s not much extra to do, since actions that earn achievements need to be detected all the same in either case, but without relying on Steam a game must provide its own interface to both notify players of new achievements and offer a way to interact with them. With Cogmind in particular this need comes to the forefront even for Steam players, since achievement interaction is restricted due to the lack of Steam overlay support.

I took this opportunity to build a better system than Steam’s own :)

Supplementary UI

The most basic UI requirement is notifying players when they’ve earned an achievement. I added this much before even starting on individual achievements, since being able to clearly see when one is earned is fairly useful while testing and working on them :P

New achievements are immediately shown in the bottom-right corner of the screen as a pop-up that remains for an adjustable 5 (?) seconds, where multiple simultaneous achievements will push up older ones that haven’t yet disappeared. Cogmind was designed to be an immersive experience and these pop-ups can kinda ruin the atmosphere at some points, so I also added an option to remove them completely (though it’s probably best that they be left on by default).

cogmind_achievements_map_popup

Achievement notification pop-ups in action, showing both their name and icon.

Achievement pop-ups are queued through a separate system so their display can be delayed if necessary. Although they’re shown as soon as possible, some may be earned while in a different UI (hacking, for example), and it’s better to have the notification appear in a consistent, predictable location (bottom-right corner of the map) once that location is available for use. Notice that the code for earning an achievement, shared last time, ends with a call to GM::addAchievement(). That just adds it to the queue and the UI can draw from there when ready.

New achievements also get their own meta notification in the message log, for later reference after the pop-up has disappeared. Meta notifications are game-related messages that always appear in white and enclosed by brackets.

cogmind_achievements_message_log

Achievement notification as it appears in the message log.

The majority of achievements are earned and displayed mid-run, but some cannot be determined until the end of a run, in which case they’ll appear to the right of the game over stats in a separate window.

cogmind_achievements_gameover_list

New achievement list displayed on game over if applicable.

Since I didn’t really want to mess up the balance and flow of the game over screen, I originally imagined I’d display any end game achievements at the beginning of the next run, but later decided it would be a bad idea, and unnecessarily anti-climactic, to force a such a potentially large disjoint between when an achievement is earned and when it is shown. It’s great to have a sense of accomplishment be associated more closely with how and when it was achieved. In fact I even read that on the PlayStation developers must show achievements immediately at the point they are earned, presumably for that same reason. So even though it doesn’t look great, for now this subset of achievements (if any were earned) appears in its own window.

An alternative solution I’m still considering is to have achievements appear first in a centered window over where the stats will be (or perhaps on a separate window after the stats), and the player has to press a button or key to advance to the next window. This would kinda mess with the flow, but at least it would look better. A lot of games take the multi-page game over approach in order to fit more information in without crowding the layout.

Main Achievements UI

The last part of the interface I worked on, and by far the most involved, was the achievements browsing UI. According to my records I spent 18 hours coding it, but as an essential part of any game that wants to provide its own system for interacting with achievements independent of Steam, it was worth it to make this UI as functional and informative as possible.

As with any major UI component I started with a design mockup in REXPaint, setting a clear goal to aim for that also accurately reflects intended functionality so that I knew everything I needed would fit just right and there’d be no time wasted on iteration following the implementation phase.

cogmind_main_achievements_ui_mockup

Working mockup of the achievements UI, as it appears in REXPaint. Note that the achievement-specific content is in some cases repetitive or inaccurate--it’s purely for testing purposes and needed to fill the space :)

The elements across the bottom match the other two collection-oriented features (item gallery and lore), with page buttons, animated percent bar, and export buttons. Exports are for players who like to view or process their performance via other means. For image examples see this progress update.

New subwindows were implemented one by one, starting with the secondary ones that control content in the main window so that when it came time to do the latter it could be fully implemented and tested all at once.

First was the category-specific window, useful for enabling players to cut down the otherwise huge number of achievements that could be annoying to scroll through looking for something specific.

cogmind_achievements_ui_category_filters

Interacting with achievement category filters.

Below those are the state filters, further helping players hone in on an achievement they’re looking for, or simply browse their actual achievements vs the pool of remaining achievements they can aim for. 256 achievements is a lot, but with sufficient filtering each subgroup can be reduced to a pretty manageable size, especially considering that the UI can display up to 16 achievements on a single page.

cogmind_achievements_ui_filters_and_sorting

Achievement state filters and sort types.

Sorting features have a number of purposes: search efficiency is increased when listed alphabetically or grouped by category; “oldest first” gives a chronological listing since the player starting playing Cogmind; and “newest first” is best for reviewing those earned across the current run, or seeing the exact description for the latest achievement, since that’s not reflected in the map pop-up notification.

Note the highlighted letters in all these windows, there to indicate the relevant keyboard command for that button. Giving keyboard players easy and intuitive access to everything actually affected what words could be chosen for each button, simply to ensure it was always the first letter highlighted. Fortunately there was no overlap among the achievement category names themselves, though the “Category” sorting method had to be renamed to “Grouped” due to the former’s overlap with the “Challenges” category itself.

And here’s the whole thing put together! (As usual scrolling was annoying to implement, but having done it a ridiculous number of times in different formats by now it went surprisingly smoothly…)

cogmind_achievements_ui

Interacting with the full Cogmind achievements UI.

Notice that the UI behind it remains unchanged when the achievements UI opens, resulting in oddities like that dangling “Alt” in the bottom right, and leaves other commands visible at the top left. To fix the top left, for now the Beta 6 version of Cogmind simply raised the height of the Filter window so that its top is level with the Achievements. I’ll lower it again like this later (as per the mockup, too) once I implement darkening of the background while this and similar windows are open. The current height adjustment is just a temporary measure so that the UI appears less confusing until then.

All done! Oh wait yeah, this is it for the DRM-free version of Cogmind but there’s still more to do for Steam…

Steam Integration

Integrating with Steam is pretty easy, even for often technically challenged me :P

It would be more involved if I also had to make use of Steam’s stats interface as a backbone for achievements, but 1) most Cogmind achievements are for intra-run accomplishments anyway and 2) Cogmind has its own internal stats system for recording long-term progress in the few areas it’s needed so there’s no need to rely on Steam for that, either. (Any game that wants to offer its own Steam-free achievement system will naturally need its own solution for stats, and the good thing is that with Steam cloud saves even players on Steam can retain persistent data all the same, as long as the meta data is considered part of the cloud saved content!)

In any case, all the relevant API commands can be found on this page, and Steam has pretty good step-by-step documentation for how to set up an achievement system, including a complete example with code you can just borrow directly or modify as necessary.

My own version is pretty similar to theirs.

cogmind_source_steam_h

steam.h

The source is somewhat bloated with additions of my own, which I’ll get to in a moment.

cogmind_source_steam_cpp

steam.cpp

On startup the game basically just has to ask Steam for the latest “stats” (which includes achievements) and wait for a response via callback. Then it’s good to go, adding new achievements at any point or using any of the API’s other dozens of methods.

As per onUserStatsRecieved(), as soon as Cogmind has the online stats data the other thing it does is immediately sync the data between the game and Steam. Usually there will be no difference, but if for example a player has been using the DRM-free version then migrates their data over to a Steam install, it’d be nice to automatically upload all their previous achievements. Likewise, a fresh reinstall of Cogmind on Steam will also need to know all previous achievements so that it can display them in the game’s own UI. The drawback of the latter Steam->Cogmind scenario is that Cogmind technically stores more information about individual achievements than Steam’s database (for example the highest difficulty on which it was earned), meaning that extra data would be lost.

So that’s what all the logged “uploading” and “downloading” is about in the source there :)

With a basic API interface available, the first order of business was to test it! Using my trusty new EARN_ACHIEVEMENT debug console command, I gave myself a couple of achievements--earnAchievement() simply calls SteamAchievements::SetAchievement() and voilà, the first ever Cogmind achievements to appear on Steam popped right up :)

cogmind_achievements_steam_working

First Cogmind achievements to be tested on Steam. “Every single achievement” my…

I also needed the CLEAR_ACHIEVEMENT command to make sure different scenarios worked as expected, and it was pretty neat to see how quickly Steam’s UI reacted to having or not having the achievements (it’s pretty much instantaneous), even when I was just repeatedly toggling them on and off :P

Testing achievements on Steam requires them to be added to the Steam database, sure, but unfortunately test achievements also show on the store page. I guess you could make an obvious “test_achievement” and use that temporarily to make it more obvious, but I didn’t want to pollute my data with testing stuff, so for a couple weeks or more leading up to the Beta 6 release, Cogmind’s store page looked somewhat odd xD

cogmind_steam_achievements_test_batch_visible

Test achievements appearing on Cogmind’s Steam store page… 2 of them.

Steamworks clearly has an internal toggle for whether a game supports achievements, but it doesn’t honor that toggle in terms of showing on the freaking store page whether a game includes any. How misleading…

There were no hitches at all--time to upload the entire batch! Steam does not, however, provide a way to batch upload achievements, so games with lots of them are going to have a harder time here. I dunno, maybe they do it as a way to discourage devs from adding too many achievements? (there have certainly been a number of requests for batch uploading over the years)

It took me about two hours to add the data (tag, name, description, hidden state, locked icon, unlocked icon) for all 256, a pretty decent pace. Sometimes it’s fun to just put on some good music and find ways to do some mundane task more and more efficiently until it’s done. You can technically write a script to do it for you through Steam’s web interface, but I’m terrible at web stuff so it was unquestionably faster to just upload them manually xD

Also the different focus of this task, and looking at achievements from a different angle as I worked with them yet again, allowed me to notice a few last minute issues that needed to be addressed (e.g. correcting descriptions).

cogmind_steam_achievements_full_batch_uploaded

All achievements appearing on Cogmind’s Store Page. Now that’s more like it!

More?

Aside from the two-page game over screen I mentioned earlier, another new feature that might be worked in is global achievement rates. You can see there’s a place for these numbers in the original mockup. Games can retrieve these values as part of the API with RequestGlobalAchievementPercentages(), so it would only be available to players on Steam.

Also it goes without saying that there’ll definitely be more achievements as more content is added :). That’s too bad because we’ll ruin the coincidental “256” figure! 512 is out of the question… for now.

Posted in Design | Tagged , , | 2 Responses

Achievements

Whew! I’ve finally finished putting together all the achievements-related features for Cogmind! As a large single system I’d like to provide a rundown of the whole process and reasoning here on the blog. It’ll be divided into two articles, this first one exploring achievements in general, how they were selected and organized, icon creation, and underlying implementation. Next time I’ll cover meta aspects like the UI and Steam integration.

I certainly spent a long time on this feature, so I guess the first question that comes to mind is why add achievements at all? In my case the answer isn’t simply “it’s just something games on Steam do to sell better” (although Valve recommends them for this reason :P), because after all Cogmind achievements are available to non-Steam players as well, and throughout development my focus has always been first and foremost on making the non-Steam version the best it can be as the “primary version”--Steam is simply a distribution platform.

When first starting out with achievement work, to help guide the development process I came up with my own list of reasons for adding them:

  • Record progress and skill milestones. Prior to achievements Cogmind already included a couple such systems in the form of lore and item gallery completion rates, and aside from their reference value they’ve shown to be useful among players when it comes to keeping track of their own long-term progress, and also measuring their progress versus other players in the community. Achievements provide yet another metric for both personal advancement and to compare against other players.
  • Recognize special accomplishments. Some interesting aspects of a run that a player might accomplish in the course of normal play under certain circumstances may go unnoticed or forgotten in the long term. Achievements can offer formal recognition of these accomplishments, like Shocking Conclusion, earned after corrupting 50 hostiles (something that combat players with a heavy EM focus might manage in a single run).
  • Create unique meta challenges. Unlike achievements that recognize existing milestones or likely (if situational) accomplishments, another type of achievement can actually suggest new goals outside the normal scope of gameplay. For example the Giant Slayer achievement challenges the player to take down five Behemoths. It’s fairly rare for players to even encounter this many in a single run, much less attack them (since they can be troublesome and are often best avoided when possible). So this isn’t the kind of achievement one might incidentally earn, but instead means actively hunting them down, requiring a different style and possibly a specialized build. Although having achievements at all increases replayability (as a kind of “collectible” like the lore and gallery), meta challenges are one of the best categories in that regard because they essentially expand the scope of the game.
  • Teach players about the world or mechanics. At the most basic level, achievements can be an alternative indirect method of helping players learn. Lots of games have these, perhaps because many players are blind to tutorials or help messages but pay a lot more attention when it comes to achievements! Still, although I added quite a few of these there isn’t a lot of overlap with Cogmind’s dedicated tutorial messages. For example there aren’t any “achievements” for basic UI functionality (which the tutorial messages cover), but instead we have achievements for some mechanics worth highlighting which don’t otherwise have a tutorial, e.g. Hehehe (“Reprogram a trap.”), or useful tips like Short-term Sacrifices (“Escape a Stasis Trap with help from an explosion.”). Loot Pinata (“Destroy a Hauler.”) was added because I’ve heard of players going for a while before realizing Haulers are a pretty good source of decent parts, or at least a source of spares, so achievements like these are aimed mainly at the players interested in actively seeking out achievements, where these are low-hanging fruit and also teach something in the process.
  • Hint at some things possible in the game. Achievements can be used as a way to tease content or features that players may not have early or easy access to, kind of as an incentive to keep exploring further. “Subspace Traveler” is simply described as “Find a way to teleport”--most players still don’t even know this is a thing in Cogmind :). Then there’s “WMD” (“Destroy 100 robots in a single turn.”), suggesting that it’s possible to wield some pretty devastating firepower. Similarly, only one plot-related achievement was intentionally left unhidden, “Origins,” which is described as “Discover what you really are.” Not too revealing, other than to suggest that there’s more to what’s going on than one might assume until starting to discover the story elements (intentionally somewhat left out of main areas of play).
  • Suggest alternative play styles. Although many people will have their preferred play style(s), providing achievements that emphasize a specific style is a good way to get players branching out, possibly discovering additional ways to enjoy the game, or simply approaching a new style as a different challenge. “Explosive Specialist” (“Destroy 100 hostiles with at least 90% of damage dealt by explosives.”) is one of the more straightforward examples, likely requiring a dedicated build focused more around blowing things up for an extended period. And not just a build but the associated tactics and long-term strategy as well--specializing in explosive-based combat means paying extra attention to matter acquisition and consumption, managing the risks of likely opening up a lot of terrain and increasing exposure across the combat zone, and dealing with the likely higher alert that results.

Although achievements are available both on and off Steam, having never played a game with achievements (or used Steam in any serious gaming capacity) I did have to spend some time researching how Steam handles them as well as how other devs have chosen to use them in their games. You’ll see this information come into play a little more later, but starting such a big system without a decent plan laid out in advance is just asking for trouble.

A more specific area for early consideration was how to treat difficulty levels. Cogmind has multiple difficulty settings, so how do achievements work in relation to those? Here I thought through three different approaches:

  • Require a minimum difficulty level for certain achievements. This one’s pretty unfair to some people who enjoy unlocking achievements, those who just want to play at their own level, undermining the purpose of adding difficulty levels in the first place.
  • Have separate achievements for every achievement at every difficulty level. Even though it’s possible to automatically award same-type achievements of a lower difficulty each time a new one is earned on high difficulty (important to avoid forcing better players to also play at a lower difficulty just to earn achievements), I’d prefer to avoid massively bloating the achievements list like this. An informal poll of current players showed that most people were against achievements for different difficulty levels. Instead I’d like to just make it possible to clear achievements in case a player wants to permanently move up to a higher difficulty and start over. I did, however, make it so that the game internally records the highest difficulty on which each achievement was earned, so this data could be exposed in the future considering that Cogmind has its own achievement browsing interface.
  • Allow any achievement to be earned at any difficulty level. This is what I went with. Simple. Accommodating.

Organization

Cogmind has a lot of achievements, and any time you have a lot of something it can benefit from some organization. I divided achievements into six categories, which comes in useful when there’s a need or desire to filter or sort them, or even simply to assist with quicker recognition of an achievement’s icon.

Some categories also further subdivide their achievements into “tiers” where appropriate (higher tiers being more difficult), similarly aiding in recognition and differentiation as we’ll see later with the icon design.

cogmind_achievement_distribution_by_category_beta_6

Initial category distribution for first batch of 256 achievements.

  • Mechanics: A group of mostly basic achievements covering common useful tactics and learning about systems. Even the obvious ones can serve as a way to reinforce features that players may accidentally trigger without realizing it. These make up over a quarter of the total, as there are quite a few different suitable mechanics.
  • Style: Specifically play style-related achievements, like combat, stealth, hacking, etc. These are generally earned through normal play using a given style/strategy, and while some might be more challenging or require focus in a certain area, they’re not difficult enough to be considered “special challenges ” (a separate category).
  • Progress: Personal meta progress like high scores, lore/gallery collection, and world exploration.
  • Challenges: This group doesn’t have anything to do with Cogmind’s “Challenge Modes,” but are instead achievement-specific individual challenges ranging from Tier 1 (not too hard) to Tier 2 (hard) to Tier 3 (pretty hard!). This is currently the smallest category, but is also the most likely to grow if and when more achievements are added in the future. (It’s also the smallest because a fair number of challenges are siphoned off by the later Wins category.)
  • Events: Story-related elements. Basically once you’ve visited every location and exhausted all the branching possibilities of the plot, you’ll have all of these. This category is entirely hidden, though, so these aren’t achievements to be explicitly sought out as if going down a list. You’ve just gotta explore and maybe in some cases use the in-game lore as clues to find more out-of-the-way areas.
  • Wins: There are many different ways to win the game, whether achieving one of the seven unique endings or simply winning by overcoming other challenging scenarios, so these get a whole category of their own. A lot of win-related achievements are technically considered Challenges, but since they require a win at the end they’re all collected under this category rather than the other one above.

Notice that these categories somewhat roughly align with the six reasons for adding achievements listed earlier, which probably isn’t a coincidence :)

Selection

I didn’t have any specific goal for the total number of achievements, just wanted to come up with what seemed like a pretty good variety covering as many aspects of the experience as possible. And while I could’ve eventually put together a large selection on my own, the process certainly benefited from player suggestions! Long before I started working on achievements, there was already a forum thread where players could submit ideas, and one of my very first actions when starting achievements work was to read through the entire thread and harvest any ideas compatible with both Cogmind’s architecture and my aims for achievements, in some cases modifying them where necessary.

Aside from of course thinking up a fair number of achievement concepts from scratch based on my own play experiences, I had a couple other outside sources for inspiration as well:

  • Score sheets: Years before achievements were even a consideration, Cogmind’s extensive and ever-expanding score sheets already recorded quite a few stats and accomplishments, so this was an obvious place to look for meaningful achievements. As of Beta 5 score sheets held more than 600 values, plenty to choose from!
  • Game Manual: I also parsed the manual to see if my Mechanics list wasn’t potentially missing out on anything worth emphasizing with its own achievement, although in the end not many came from here.

Coming up with a good set of achievements was a very gradual process of adding new ones to the list and making repeated passes over that list to group them by likely category, although this was before the final categories were determined so it involved a bit of back and forth. At first there were a lot of uncertain achievements organized into tentative categories, and later on the appropriate categories (and specifically their names) became clear, further helping flesh out and finalize the achievements.

Even within categories there are subcategories. I mentioned tiers earlier as a form of subcategory, but for determining which achievements to add, more important than difficulty-based subcategories are type-based subcategories. For example the rather large Mechanics category is broken down into general mechanics, combat mechanics, alert, interactive machines, machine hacking, robot hacking, information warfare, flight, allies, and more. (My earlier summary of Style-related achievements also happens to essentially reflect a partial list of its hidden subcategories.) This level of subcategory was created purely for my own organizational and development purposes, though, there’s no need to make them public.

cogmind_achievements_data_subcategorization_style

Well, not public in the game anyway--may as well demonstrate here how they appear in the game data for my own reference :)

Prior to building the achievements list I also set out some important guiding principles:

  • Most importantly, an achievement should be obtainable in the space of a single run (rather than accumulated across many runs). First of all this does a better job of adhering to the roguelike spirit, which places a lot of emphasis on individual runs given the nature of procedural generation and permadeath. Second, since there would be so many achievement descriptions which ideally need to be as short as possible, it’d really simplify the system to not require every single one to specify whether it’s per run or across all runs combined. There are a few exceptional “meta achievements,” but it’s a small number and they’re obvious enough to not even require explicitly pointing out that it doesn’t refer to a single run, e.g. “Curator: Reach 100% gallery collection.”
  • While all achievements are definitely guaranteed earnable with the right tactics, strategy, and skill level, not all achievements will be within reach of all players. Certainly more of them become accessible to a wider audience by lowering the difficulty level, but it’s still going to take a decent amount of practice and skill to reach 100%. Some of them are downright hard even on easier difficulties, but serve as interesting goals in and of themselves, supplementing the many goals already suggested by the plot and world layout.
  • Although some games do this, I decided against having achievements emphasizing negative effects and experiences that might not ever happen to certain players, since it feels counter-intuitive to require that players intentionally subject themselves or their run to nasty things simply to earn achievements. A small number of exceptions were made for situations that will certainly happen at one point or another, but these are specifically designated as hidden achievements so that they’re not something to aim for--they’ll be earned naturally through regular play.

Again there was no target number of achievements, but by pure coincidence the final tally came to 256. It was originally 255, but after late-stage polishing I ended up removing a couple and adding a few :P. “Too bad” this is only the first batch--more achievements will almost certainly be added and end up ruining this rather appropriate number!

cogmind_steam_achievements_full_batch_uploaded

For now we can admire this number on the Steam store page.

Definition

The naming of achievements is important, but pretty straightforward so I don’t have much to say about that other than pointing out the obvious: players like names that are fun/interesting/provocative/cool/punny/etc. There were plenty of opportunities to come up with a variety of names when there are so many achievements :D

Of course there are a lot more details to creating a good set of achievements beyond simply choosing and naming them!

Numbers

While a lot of achievements are essentially binary (“player did X”), many others involve reaching certain thresholds, which usually means numbers. It was really nice to have so much score sheet data (including archives) and past analyses to draw on in order to set realistic values for these numbers.

cogmind_player_stats_data_subset_beta_4

Excerpt of run stats from Beta 4 (the full table includes 446,028 data points). Filtering and sorting this data is able to answer a lot of questions about balance and difficulty, suggesting potential achievement requirements.

I could adjust the difficulty of an achievement based on the precise reported performance of players in earlier Betas, and further informed decisions by recalling anecdotal evidence from player discussions over the years--I’m always listening to stories and this continues to help shape the game in numerous ways, the most recent example of which being achievement design. Being pretty familiar with the game myself (I’m decent at it and enjoy playing, too :P) also provides some important context for creating reasonable achievements for all skill levels. So in the end details emerge through a combination of hard data and subjective experience.

One of the things I wanted to avoid in the number department are a lot of repetitive achievements, as these aren’t very meaningful. For example there are many different types of robots, but we don’t need dozens of varieties of “destroyed 10 of this robot.” In fact there are almost none of that type of achievement except where doing so is especially interesting, as with the Giant Slayer achievement discussed earlier.

Descriptions

Names can be fun and in a lot of cases not perfectly descriptive of the achievement, but descriptions themselves had better be clear. These I wrote (and sometimes rewrote, on later passes) with a mind towards “what are players going to ask about this achievement?” “What’s not clear?” Once descriptions have satisfied that condition, they’re also checked for consistency of tense, grammar, style, etc. (basically what should be done with any game writing :P), and at the end I ran a spell check on the final set to ensure no typos were overlooked.

Hidden?

Steam achievements don’t have a wide range of functionality, but do at least support marking an unearned achievement type as “hidden,” which shows only its name and whatever icon is associated with that state. (Or on the global achievements list for a game it’ll show the achievement’s icon and name, but still no description.) This offers some interesting possibilities, so I enabled the same feature in Cogmind and in order to take proper advantage of it spent some time thinking about reasons for whether or not to hide an achievement:

  • Plot spoilers is an obvious one. There are numerous plot lines and points to explore across different runs, reaching almost any of which can be considered an achievement in itself since every single one is off the beaten path. But I’ve always been spoiler-averse, not wanting to ruin the discovery aspect of the experience, so plot-related achievements (or any others dealing with “special content,” even if not necessarily connected to the plot) are all hidden.There is one plot-related achievement, “Origins,” which is not hidden but instead given a vague description (“Discover what you really are.”) and meant to be a teaser of sorts for any new or potential players just browsing the global achievements list on Steam. It hints that there’s more to even the basic premise for the story than one might guess.
  • A handful of special achievements I wanted to hide for spoiler reasons, but doing so would make it very difficult for players to discover them so I had to keep those unhidden. In this case it’s useful to rely on a “middle ground” approach: Make the description vague enough that the average player won’t know what it refers to, but experienced players will be able to accurately guess the requirements.
  • Actions that require specific behavior which is boring to set up with the intent to earn an achievement, but otherwise fun to recognize when it happens organically, should be hidden. This goes along with the general game design principle of “don’t reward tedium.” There are only a few of these, but they’re fun :) (as I write this article Cogmind’s achievements have been in prerelease testing for a short while, and already I’ve got reports from players laughing at these)
  • While it’s fun to recognize achievements that can be earned organically, and certainly many can, sometimes where the intent is to get players to explicitly try different styles it’s best to leave them unhidden. For example the Explosive Specialist achievement from earlier would be fun if and when earned suddenly by players focusing on that style, I believe it’s more valuable to use as a suggestion for any players browsing the achievements for something they might want to aim for. (In the same vein, Gun/Cannon/Melee Specialist also remain unhidden.)
  • “The Most Popular Achievement” (an actual achievement name :P) is a special case worth discussing, as it’s quite vague and also hidden. This one, awarded on a player’s first death, has several uses. First of all it takes the sting out of a loss, pointing out that this is a normal thing that is likely going to be a frequent occurrence. It’ll also be the one achievement that anyone who plays will have, meaning it will top the Steam global achievements list--as a hidden achievement (remember that means there’s no description) this makes it kinda intriguing to potential players who open the list. As the “guaranteed achievement” it also serves as an indicator of the percentage of people who’ve actually played through a run. Unfortunately this percentage will remain low at first since a lot of owners are waiting until Cogmind is out of Beta, and too bad achievements weren’t around when a huge percentage of players tried it for a bit during the EA launch, but I’m sure we’ll be seeing more players jump back in with the Beta 6 achievements release, and of course 1.0 later, and can use that number to follow the trend.

When creating an achievements list, my approach was to “assume unhidden is the default state, what should I hide?” But another game might take the opposite route and come out with different results, i.e. hide everything and only reveal what’s absolutely necessary (or nothing at all?).

Some players might even prefer this, because then they feel less obliged to play in a specific way and either all the achievements are surprises, or any descriptions that do exist might instead just be indirect clues to figuring out what that achievement requires. This would allow for an extra sense of accomplishment on earning one, but I decided not to have any like that for now. Maybe in the future as a fun expansion, depending on how players fare with the initial batch. (Note their icons could also contain clues, or not since icons for displayed achievements before they’re earned can be non-specific.)

Of the final set of Cogmind achievements (as of Beta 6), 31.2% are hidden, exactly half of which are for plot-related reasons. Therefore 15.6%, or about one-sixth of all achievements, are hidden for one of the other reasons.

cogmind_achievement_distribution_by_hidden_setting_beta_6

Initial hidden setting distribution for first batch of 256 achievements.

Icons

Oh my… When you’ve got 256 achievements, not only do you need good names and descriptions, but also a whole ton of icons to represent them!

At least ASCII art is fairly quick to produce, and I didn’t have a choice with the style anyway, because 1) I am not capable of producing anything else decent, and more importantly 2) all of Cogmind’s art must be CP437 in order to fit in the game (remember that Steam is the sideshow in this system--the game itself has even more achievement-related features).

I did, however, have to ensure from the start that icons would also be compatible with Steam. Their system requires 64×64 JPGs, in which I can fit up to a 5×5 grid of 12×12 pixel ASCII (12px happens to be the default size at which I draw ASCII art), so 5×5 it is.

But icons also need a border, and inserting a border into a 5×5 grid means all that’s left for content is a 3×3-cell interior! This seemed ridiculously limiting, especially for “abstract” achievements, so after coming up with the initial list of achievement ideas I went through each category and sketched about 20% of them (since each category represents a different set of concepts). It started out well enough, and wasn’t nearly as time-consuming as I’d feature it would be, either, so amazingly it actually seemed like this would work out in the long run. Limitations leading to interesting results is basically a cornerstone of Cogmind development, and this ended up no different :P

Thanks to REXPaint the drawing part was quick and easy, but it took longer to both establish the symbolism and ensure it was consistently applied throughout all of the icons. It was definitely fun working with the symbolism, and later when I started sharing batches of icons some regular players were pretty good at guessing the meanings of each, even without a description! (of course it helps greatly to have an understanding of Cogmind’s ASCII mode…) So I think the system has worked out pretty well.

In terms of productivity, as usual it helped to draw all the icons over a very short period, making it less likely I’d forget some of the symbolism and either make mistakes that would need to be discovered later, or slow down the process by having to repeatedly review such a large collection of icons before continuing.

I also drew them all in a single file to make cross-referencing as quick as possible.

cogmind_achievement_icons_spritesheet_rexpaint

Cogmind’s complete achievement icon spritesheet as it appears in REXPaint. The code knows how to extract the icons and which is which.

Looking closer at the structure of individual icons, there are two main ways to differentiate categories: border style and color scheme.

Border Style

Since nearly two-thirds (64%!) of the cells in an icon will be occupied by borders, they’d better be put to good use. Their first priority is to reflect an achievement’s category--each should have its own unique style. The most basic category has the simplest style, but decisions for other categories had to take into account another factor: how many difficulty tiers would be required within that category. Some potential border styles naturally lent themselves to a greater range of modifications, making them more suitable for multi-tiered categories.

Before starting on the icons, I first designed a large collection of different borders, seeing which looked bad, decent, or good, and which could be expanded into a natural progression of multiple tiers. It’s from that page of concepts that I’d pick the final set which best matched up with the requirements.

cogmind_achievement_icons_border_concepts

Achievement icon border style concepts. I generally started with an idea on the left and changed only one aspect of it for each new iteration moving to the right, or sometimes up or down if I wanted to try taking the concept in a different direction.

Higher tiers would need to look “cooler,” essentially more intricate or elaborate. I eventually settled on this arrangement:

cogmind_achievement_icons_category_tier_templates

Final Cogmind achievement icon templates by category and tier, colored.

The Wins category doesn’t use its full range as a “progression,” as it has four border styles but only two tiers. The other two borders are for special subcategories of wins, specifically the core seven different win types according to plot, and challenge mode wins, so these have a different look from the tiered “special condition wins.”

Color Scheme

Border style is not the only way to differentiate categories--each has its own base color as well (demonstrated in the above template matrix).

Colors were picked with purpose. As an “extremely Cogmind” color, green is used for one of the highest level of achievements, Wins. As a “powerful, deadly” color, red is used for the special Challenges. As a category of “basic” achievements that don’t really need to stand out, the Mechanics category uses dark amber (somewhat close to brown) as its main color. Colors for other categories were chosen for somewhat less specific reasons :)

Border colors for the templates are all dark, at 25% brightness (and backgrounds are even darker at 12%), but each category also has a base foreground color (100% brightness in the same shade) used for generic content like numbers. This way the numbers, as secondary bits of information, are somewhat connected to the category and background/border itself, at least more so than most other elements that make up the interior.

cogmind_achievement_icons_generic_foreground_number_samples

A sample of Style category icons with generic number components highlighted.

Most foreground characters are all quite bright as well (usually 70-100%), so while the border and background colors serve a supporting and informational role, they don’t take over the entire icon.

As for icon interiors, colors used there are drawn from Cogmind’s ASCII mode where possible, although in some cases alternatives were needed where a concept is not already associated with some specific color (sometimes required for abstract icons). Again though, in all cases colors were chosen with purpose, and where a concept is repeated across multiple icons those colors are applied consistently.

Locked (Unachieved) Icons

Locked achievements need a display icon as well, and there are about three ways to handle them:

  • Use a grayscale or muted/darkened version of the unlocked icon. Most games seem to handle it this way, and it’s the recommendation from Valve.
  • Use the same icon to represent any locked achievement. This is a lot less common, but some games do it. I guess it has the advantage of making the actual icon part of the surprise/reward on achieving it. Hiding the icon contents also removes yet another clue as to what a hidden achievement might be referring to, becoming a truly hidden achievement aside from whatever information is suggested by the name alone.
  • With enough achievements to divide them into categories, a separate icon can be used for each category, but used across all achievements in that category. I went with this approach to further emphasize the categorical nature, and because it helps break up what would otherwise be a huge mass of identical icons if I went with the second method above. (For the same reason I don’t like the idea of grayscale versions--too much information value is lost when this many achievements are at play.)
cogmind_achievement_icon_export_locked

Locked achievement icons.

Note that locked icons also reflect the relevant tier--essentially these icons are equivalent to the templates, with the interior replaced by dark question marks.

As for those PNGs, they are exported from the game via debug command in order to convert them from the internal format and assign proper file names. This isn’t necessary for the default DRM-free version, but again Steam requires that achievement icons be 1) JPGs, and 2) 64×64. So I created a tool to output all icons, then use Photoshop to batch convert from PNG to JPG while also adding a 2-pixel black border around each (since in Cogmind their dimension is 60×60).

cogmind_achievement_icons_export

256 Cogmind achievement icons, exported as individual PNGs.

Implementation

We’ve got names! Details! Descriptions! Even icons! But… achievements also need to actually make their way into the game :P

Once all the data and resources were defined and ready, next came the code and systems.

On an individual level each achievement is pretty straightforward to implement, being a quick check for the condition and corresponding call to a method to assign it if applicable. This process was made even easier by the fact (mentioned earlier) that a fair number of achievements are based on the existing score sheet data, which itself already tracks many hundreds of conditions and stats throughout a run. Implementing a related achievement could take as little as a minute or less since I don’t have to search around for or confirm the right location in the source--just ctrl-f for the appropriate stat name!

Of course some achievements required new stats that I hadn’t been tracking, so throughout this process I also ended up expanding score sheets by several dozen entries where it would help. In yet other cases some achievements required whole new internal variables to track special conditions in more complicated situations, basically those which had to be confirmed at more than one point in time to award.

Note that most games will actually use Steamworks’ stats system for this kind of thing, but Cogmind has its own internal stats system so I could more readily use that, plus I wanted non-Steam Cogmind to fully support achievements as well, so relying on Steam for any help wasn’t an option anyway.

cogmind_source_achievement_check_assassin

Checking the internal stat value for whether to attempt to award the Assassin achievement (“Sneak attack 15 hostiles.”).

The above code doesn’t do any heavy lifting because control should naturally be as centralized as possible to make any potential changes easier to implement down the line. So additional generic checks and the actual achievement award itself are handled by that single earnAchievement() method:

cogmind_source_achievement_award_checks

Generic code for handling achievement application.

For now I’ve decided to not hand out achievements to brand new players, to help them focus on the tutorial messages and avoid overwhelming them with even more information in an already daunting interface.

I was originally thinking of ways to save on development time throughout all this, and seeing as a lot of the achievements were so straightforward, one of the possibilities was to… skip testing. Nope--too difficult to go against my standard practice of manually testing every little feature, so I tested all 256, too xD

Only a tiny percentage didn’t work as implemented, but it’s better to make sure they do rather than have so many players scratching their heads, or reporting bugs I could’ve easily found on my own. Setting up testing conditions was extremely fast with debugging commands anyway.

The final step was to integrate achievement data into score sheets as well, which I did in three areas.

Like gallery collection and lore percentage, at the bottom of the sheet in the section for general game data there’s a new “Achievement%” which keeps a running tally of the total number of achievements earned so far, out of 256.

cogmind_achievements_score_sheet_cumulative

Cumulative achievement progress in a Beta 6 score sheet (recorded from one of the prerelease testers’ runs).

Like the other two, this percentage is a fun and useful indicator of overall progress.

There’s also the full list of achievements earned for the first time specifically on that run.

cogmind_achievements_score_sheet_list

An achievement list as it appears in a score sheet.

And although it’s possible to count the number of achievements in that list to get a total, the tally for the run also appears as its own entry in number form with the regular stats. This is more convenient for players looking for a quick count, and also for me when I run the data analysis since no extra work is needed to extract the number of achievements while analyzing global stats.

The final feature tacked on at the end is a way for players to reset all their achievement progress for whatever reason (without losing their other meta data in the process). It’s a text-only advanced config option, but unlike other options this one is only discussed in the manual, not even listed in the config file itself, because players had really better be sure they want to do this and not accidentally trigger it. Manually adding “resetAchievements=1” to the file will tell Cogmind when it next starts up to erase all achievements.

I’m glad all this achievement work was handled late in development, i.e. after the core game content and features were completed, because it would’ve been much more likely for achievements to become a disorganized mess over time if it was added too early.

And I’m happy with the results--there’s something for every skill level, and players appreciate them. Achievements are a great high-value meta feature (so yeah, no surprise that lots of games offer them, and Valve highly recommends adding them, too).

And that’s it! Next up is another piece on how to provide ways for players to monitor and learn about their achievements, and hook everything up to Steam…

Posted in Design | Tagged , , | Leave a comment

2018 7DRL Postmortem, Part 4: Finishing Touches

Picking up where we left off at the end of Part 3, an in-depth look at the map generation and content work

The Last Minute

With all my planned balance time eaten up by adding content, there wasn’t much left for… “proper” balance. There was nowhere near enough time to do all the math required, and while I would have loved to write all-new content from scratch and use formulas to balance it well for the new format, this is a 7DRL--plans need to be semi-realistic :P

That said, I’m kinda impressed/relieved with how well it turned out because there was only just enough time for some emergency band-aids, and into the final hours I was still making pretty huge improvements. It’s not nearly Cogmind level of balance, but from a couple quick playthroughs I did identify the biggest issues and what was needed to quickly resolve them.

Aside from repeatedly dropping the number of robots (early counts were way too high!), I added lots of weapons across the board, basically hacking them into the normal item distribution system by forcing a minimum 15% of all individual items to spawn as weapons. This is not normally how item distribution works, but after repeatedly running out of weapons during my test runs I used Cogmind’s item distribution debug output system to examine the normal likelihood of having weapons spawn and noticed that the numbers were surprisingly low on most floors.

polybot7_7DRL_item_distribution_rates

Final (post-balance) distribution of items, both common and prototypes, by slot/type on each floor.

In the same way I enforced a minimum weapon count, every floor is also guaranteed to contain launchers (more on larger floors), because launchers are FUN and I wanted the 7DRL to be FUN :D. Besides, in POLYBOT-7 players may not always have free slots to pick up the items they find/want (and remember there’s no inventory space whatsoever!), so even with a lot of fun stuff lying around, not all of it will actually be used, meaning there’s more leeway to add plenty of it without making the game too easy.

More weapons and other good items were also added in the form of guaranteed prefabs, specifically “weapon rooms” and so-called “build rooms.” These are rooms that contain caches of out-of-depth parts, the former purely weapons (again to make sure there were enough to play with) and the latter having a balanced variety of items across the slot spectrum such that players who find these rooms could essentially purge right there to get a decent fresh build. “Build rooms” are guaranteed to have a power source along with some propulsion, utilities, and weapons.

polybot7_7DRL_embedded_prefab_placement_sample

Special prefab rooms, labeled. Also notice how these rooms often have double doors so they’re easily recognizable from the outside.

In hindsight I overdid the weapons (they’re now all over the place :P), but more choices always has its advantages so may as well overdo it rather than risk underdoing it! Reaching the perfect balance there would’ve taken much longer than the time available. I was doing all this in the final hours, after all xD

One of the core mechanics was also changed at the last minute: the purge timer. At first it seemed like siphoning off a portion of the player’s energy each turn to charge it would be strategically more interesting. This behavior would add another important consideration to any decision to purge, since the action would be followed by reduced energy production until fully charged again. But I realized this wasn’t very desirable in the bigger picture, since purging already destroys random parts and can lead players into an uncertain situation, so there’s no reason to kick them while they’re potentially down! Instead I changed it to a simple 100-turn timer--more predictable, and also more fun.

polybot7_purge_timer

Purge timer in action. Counting down and repeatedly attaching remaining nearby items only to purge again.

At the very very last minute I was testing the game out real quick and spotted some important QoL that was missing from the UI: the number of newly collected slots from the current floor (since there is a guaranteed number and these are a vital improvement to seek out), and even the actual letter of the current floor! Both of these are useful for assessing progress, and there was almost not quite enough room but I squeezed them in next to the turn counter.

polybot7_hud_indicators_slots_floor

Last-minute HUD additions: slots collected and floor ID! (Instead of numbers floors have corresponding letters: A/B/C/D/S)

Aside from their usefulness to the player, HUD indicators like this also make screenshots a lot more informative when players are sharing them, avoiding too many basic questions and giving discussions more context to work with. This is one of many advantages to Cogmind’s “pretty much everything you need to know is visible on one screen” UI style, in addition to making it easier to get up to speed when continuing an unfinished run from a previous session.

The End

Although I’d finished on time in my time zone, I was working with Kacper and he needed the rest of his Sunday to finish the tileset, so I didn’t submit until the next morning after I had a chance to wake up and package his tiles with the game.

It was finally finished!

Even though I was working on this project pretty much non-stop all week, it was a surprisingly refreshing week during which I didn’t feel like I was on the clock for once. It’s been such a long time since I did any development aside from my full-time work on Cogmind that I’d forgotten the excitement of pure development from my hobbyist days. With a commercial project everything has to be documented, polished, and hopefully built to careful futureproof specifications, whereas with POLYBOT-7 I could just let the work flow. Such a free-form “full speed ahead” approach was hard to get used to at first, but it sure felt way more productive :D

Shortly after release it was reported that you could still access the Garrison hacking interface by clicking on a Dispatcher xD. I’d removed the bump-to-hack interaction, but forgot that clicking on them is handled in a separate part of the code! Amusingly this meant players could hack open a Dispatcher, which created stairs to an oddly named floor, “G” (taking the first letter of “Garrison”), and it was technically a legitimate link to a garrison map but I had removed all the garrison data so attempting to enter would simply crash the game. I put out a fixed version real quick to avoid people walking into a black hole (not to mention the hacking interface wasn’t redesigned for POLYBOT-7 anyway).

polybot7_bug_accessible_garrison_controls

Bug-enabled hacking interface opening a theoretical exit into a Dispatcher.

Speaking of bugs, throughout development I discovered a number of them in Cogmind, and even the engine itself. Nothing major, but it’s nice to have been able to clean those out, too.

I find the POLYBOT-7 concept super interesting overall, but the 7DRL only really takes a quick peek at its potential. One of the ideas that could greatly improve the fun factor, given more work, is “kit rooms.” These would basically be rooms containing all the parts needed for an excellent build balanced around a particular style or weapon(s), making it likely players will want to purge on finding them to instantly turn into a killing machine. Actually the “build rooms” added at the last minute were a simple implementation of the kit room concept, but with completely randomized parts so not necessarily all that balanced. Unlike build rooms, however, kit rooms would be hidden behind secret doors, requiring scanners or lucky collateral damage to uncover. There is technically one kit room in the game, which I quickly threw together for the last floor. It’s pretty cool if you can find it ;)

Reception

A good number of Cogmind players have picked up the game and are enjoying it. I heard from one even mentioning that it helped them understand Cogmind better! And it seems even non-Cogmind players have been finding it fun.

In the first 8 days so far since release there have been 437 runs (not individual players, which is somewhat less than this) and… 882 downloads. Apparently a lot of people download to consider playing later when they have a chance. (I know there were some people who downloaded multiple times because I updated, but not quite 2~3 times per person :P) It would be fun to compile the stats and leaderboards like I do for Cogmind, but I’ve really got to focus on the latter for now!

Although not a demo, the similarities are enough that it can serve as a sort of advertisement for Cogmind, especially as a way to get my name on itch.io, a platform I hadn’t used before. (At the same time POYLBOT-7’s connection with Cogmind is an indirect way to get the latter on itch.io.) It topped the Strategy category by popularity, also reaching #1 in most of the tags I set, e.g. “pixel art,” “turn-based,” and… “roguelike” :). It was popular enough to rank in the top 20 games on itch.io (which had just passed the 100,000-game mark at this point), and starting a day later they even featured it on their front page :)

polybot7_itchio_featured_game

POLYBOT-7 featured on itch.io front page.

Popularity is basically just page hits, of course, so it helped that I posted announcements on a number of sites, plus Nookrium, a decent-sized Let’s Player who has tried out my other games, gave P7 a shot as well on day 1.

I’ve kept an eye on Cogmind sales and there’s been no significant impact there, but wishlisting on Steam is up 29.4% comparing the week before and after the 7DRL release ($20 is a bit more expensive than free, plus it’s “Early Access” :P).

Anyway, I’ll probably just do one more release that fixes a couple tiny issues, then shelve it until another time when maybe I can revisit it for some extra polish. I’m thinking I should take on a smaller project after Cogmind, and POLYBOT-7 already seems like a fun possibility to develop in a serious capacity for 6 months…

Posted in Dev Series: 7DRL Postmortem | Tagged , , , , , | Leave a comment

2018 7DRL Postmortem, Part 3: Spending Too Long on Map Generation and Content

Picking up where we left off at the end of Part 2, about the early days working on the core interface and mechanics

Map Generation

I spent an entire day just working on map generation. At the end of that day my desk looked like this:

polybot7_desktop_mapgen_work_7DRL2018

My desk after reasoning through various POLYBOT-7 map layout needs.

All the maps use my tunneling algorithm from Cogmind, albeit with different parameters. Slot Modules (the way to get new parts slots) are actually among those parameters, existing as prefabs that are deliberately placed in certain locations relative to map entrances/exits.

polybot7_procedural_map_structure_annotated

Sample 100×100 map layout, annotated. The player enters from one of the red dots and has to exit from another. This particular layout has four distributed slot module rooms rather than the usual three, and POLYBOT-7 has a lot more hidden doors and corridors than Cogmind. There are also very few large rooms.

I was particularly worried about screwing this phase up because a good set of maps takes a long time to create and there’d be no time to redo this later. While designing the layouts I based a lot of my assumptions on what I knew from exploring Cogmind maps, combined with plans for how POLYBOT-7’s content was going to change everything (the next step in the process, which I’ll cover later). Honestly I didn’t have to spend so much time on map generation and everything would’ve been fine, but I wanted more variety to maximize replayability while also keeping it challenging. Map size and layout are understandably crucial to balance, and I’d decided it would be appropriate to increase map size at each depth, meaning multiple different layouts were needed for every floor. So this took a while.

polybot7_mapgen_tests_80

Testing layout generation for the 80×80 map (second floor).

polybot7_mapgen_tests_100

Testing layout generation for the 100×100 map (third floor).

polybot7_mapgen_tests_125_cubbies

Testing generation for one layout style (each floor has multiple styles) of the 125×125 map (fourth floor).

It was during mapgen work that I made a huge change to the game’s direction: permanent upgrades. Rather than Cogmind’s evolution-based system where you simply have to reach an exit to regain core integrity and get stat boosts, the player collects random upgrade modules that provide permanent benefits like damage resistance, extra energy/matter capacity, greater accuracy or sight range, etc. This is a mechanic I really wanted to explore in P7, but it had originally been relegated to the “probably no time for that” list in the design doc. Little did I know, come the middle of the week I’d be forced to draw on this idea to balance the design.

When it came down to it, under the new mechanics map entrances and exits were very difficult to place in the same way I did for Cogmind, since P7 maps needed to be smaller, but all stat upgrades being local to a floor would mean that I no longer have to spread out the exits! Players can locate exits quickly and that’s fine, because they’ll still want to explore for more upgrades as long as they reasonably can without losing too much in the process, which is where the real challenge lies.

What’s more, obtaining these upgrades would require attacking Dispatchers (the primary source of enemies scattered across the floor), helping focus on the combat-oriented nature of the game--risk fighting for upgrades, or leave early. Collecting permanent upgrades is also simply a fun thing to do in games, despite being almost totally absent from Cogmind, so it’d be nice to experiment with that in a Cogmind-like setting.

In Cogmind, stealth/speed-based strategies emerge naturally from the mechanics because you can simply attempt to avoid (or outrun) enemies while locating exits, but that’s not possible here and now the POLYBOT-7 mechanics do so much more to reinforce combat as the main approach. Focus! Unfortunately it also meant that there would now be even more work to do when it came to content: making all the upgrades :P

Content

While I had a pretty good schedule worked out for 7DRL, fortunately that schedule also had a couple extra days built in for “balance and fun stuff,” because as it turned out I needed to reallocate all that to more pressing matters with regard to content in the middle of the week xD. My original plan was to focus mostly on giving POLYBOT-7 lots of unique mechanics while retaining many of the same items as Cogmind. But for a number of reasons that felt inappropriate, both thematically and mechanically. A better approach would be to add a whole bunch of new content as well… so I ended up crazily working through that unplanned bit mid-week. Towards the last couple days it was looking bleak and I thought I might not even finish! Apparently I ended up finding enough shortcuts to take, while just working really really fast :P

New content or not, everything had to be reworked for the new map view size. Cogmind shows up to a 50×50 area of the current map at once, and all its mechanics and content are designed assuming those dimensions. Frequently spotting, or being able to shoot (or be shot by), enemies who are off the edge of the map view and require scrolling in order to see/shoot is poor design, so it should be avoided at all costs. At the same time, having items and systems that can take maximum advantage of the available viewing area is also desirable, so you can see how central that view area is to a design.

To try to retain as much balance as possible without excessive work and testing, the simplest way to approach existing data is to take any range-related numbers and drop them by 40%, to mirror the 50-to-30 change. This was the first adjustment, to literally copy weapon range data into a spreadsheet, multiply it all by 0.6, then copy the results back :P

But the 40% reduction would also have a significant indirect effect on firing time. Earlier for the propulsion system rewrite I set the desired base movement speed to be slightly faster than once per turn, and calculated that in practice (based on total loadout mass) players would generally require anywhere from 0.75 to 2.5 turns to move one space--this was intended to keep players from moving too fast relative to the smaller map sizes. And in relation to that, again to retain a familiar balance based on experience with Cogmind, the next goal here would be to choose a firing time cost that gave enemies approximately the same number of opportunities to shoot at a fast or slow moving player as seen in Cogmind. The numbers came out as 3 turns to fire one weapon, 4.5 turns to fire a volley of two. Later testing showed that these seemed to work fine, so they weren’t tweaked at all.

polybot7_7DRL_speed_time_notes

The few notes used to calculate movement speeds and relative volley times, sketched out during the mapgen process to ensure the map sizes would be reasonable for the target movement rates.

The item work of course involved a lot more than just ranges:

  • All (110) Cogmind propulsion items were removed and replaced with 46 new ones (although some of the names were reused, all the stats were reworked).
  • The range of power sources was simplified, removing 23 of them as well as adding a new set of 9 which most of the enemies use (instead of the regular power sources).
  • 14 upgrade modules were created (at least the behavior code for half of these was available from Cogmind, and the other half was pretty quick to add using a similar model).
  • Utilities were reworked to remove most of those with purely non-combat effects, and simplify the remaining ones to use a more basic naming scheme. In all, P7 has 182 fewer utilities than Cogmind.
  • Weapon names and progression were similarly simplified, in addition to adding 21 new weapons, most intended for use by enemies. Lots of Cogmind weapons (nearly 200) were removed, and as mentioned before, this process avoided keeping most weapons that used slower animations. One exception was the micro-nuke, the awesomeness of which many think is underemphasized in Cogmind, so I used POLYBOT-7 as a chance to give it the spotlight and make it the best launcher :D. A number of Cogmind weapons were also significantly altered to convert them into better versions of earlier weapons, and had their animations changed to match their new group, albeit recolored.
  • Overall, POLYBOT-7 has only 412 items compared to Cogmind’s 900.

Once items were done it was then time to put together robots, which are mostly defined by their items. All robots were built from scratch, but in most cases used Cogmind robots as reference templates to guide their design. The general idea is that enemy robots use inferior parts, so while the player can attach and use anything, it’s often best to avoid salvaged parts when possible (but the challenge comes when there’s a lot of salvage lying around and it fills any empty slots for you automatically! This somewhat discourages the “safe” tactic of fighting in doorways). Their power sources also come with no energy storage capacity, so the idea here is that if you rely solely on other bots for power you’ll have less reserves for supporting flexible builds.

I also gave some robots items they don’t really take advantage of but that the player might want, as a reliable way to acquire them. This is a design strategy used a lot more often in Cogmind than with P7, but there were a few cases it’s helpful. For example Aimbots carry Structural Scanners so that players have frequent access to a way to detect hidden doors--remember there are a lot more of these in POLYBOT-7! (Also thematically it does kinda make sense that Aimbots, which can attack targets through walls, might have these :P).

polybot7_7DRL_entitiy_data

Complete robot data!

Once robots were completed (see how all this progresses in a nicely orderly fashion? :D), it was finally time for Dispatchers, the focal point of much of the combat and therefore gameplay experience, including the difficulty! Dispatchers are basically Cogmind Garrisons but with different behavior (activating based on player proximity, timed dispatch of squads until destruction, and dropping modules once disabled), but being a focus of the challenge they ended up requiring a lot of balance work, especially in terms of how far away they might trigger, and how many bots they release. This is something I revisited a few times over the final couple days. Their bots do not, however always directly attack the player! That would be pretty boring, so some of them may stay to defend the Dispatcher, and others will head to the area where the Dispatcher was triggered from, but technically never seek out the player directly like some squads in Cogmind might.

With content more or less finished, I moved on to overall map balance. This is where I’d spend time repeatedly loading random maps and looking at them in a zoomed out view to examine distribution of items, patrols, sentries, Dispatchers, etc. and tweak a lot of spawning numbers/ratios as necessary to create something close to what looked like a balanced experience.

polybot7_WIP_7DRL_day6_balancing_map_content_2_paths

Examining content across a section of map, including patrol paths (the colored lines).

POLYBOT-7 was meant to be a pretty short experience, only five floors, but aside from unique map layouts I figured another relatively inexpensive way to increase replayability for those who are really into it (and play well) would be to offer a “New Game+” after winning. A number of difficulty-related variables could simply be tweaked by the number of times the player had won, and why stop at a single NG+? I decided to add up to five consecutive New Game modes, each harder than the last. Tweakable factors:

  • Number of patrols initially on a map
  • Patrol size
  • Range at which Dispatchers are triggered
  • Number of robots dispatched per group
  • Weighting for types of robots dispatched
  • Chance that a dispatch will be accompanied by a supporting Blastbot (uses missiles) or Forcebot (protects allies with force field)
  • Interval between dispatches (this was implemented but I didn’t see a need to tweak it so it remains static: 100 turns)
  • Salvage rate from destroyed robots

Other non-gameplay-related changes for NG+ runs:

  • Each has a unique name: “Alpha,” “Beta,” and so on
  • Each have their own wall color
  • The score multiplier increases with each mode, giving massive bonus points for all actions that earn points to begin with, even if a win isn’t achieved

To simplify the overall execution, I made it so that losing any NG+ run causes the player to perma-lose the streak and have to start over from the beginning with a “regular run.” Basically roguelike permadeath but for New Game win streaks. This isn’t the best design, but I was in a hurry! In hindsight it would be better to have a loss push the player back to the previous NG+ mode (assuming they’ve won more than one consecutive run already) so that not quite so much progress is lost.

Note: Sure enough one of Cogmind’s top players has already won P7’s final final final NG+++++ mode to achieve ultimate victory :D

Coming next is Part 4: Finishing Touches!

Posted in Dev Series: 7DRL Postmortem | Tagged , , , , , , , , | Leave a comment

2018 7DRL Postmortem, Part 2: First Days with UI, Aesthetics, and Mechanics

Picking up where we left off at the end of Part 1, which covered pre-7DRL preparation

UI, It Begins

The first stretch of 7DRL week was an exercise in chopping up and reconstructing an existing UI in the most efficient way possible.

polybot7_cogmind_ui_conversion

UI-first would be the best approach, since that would enable me to work on the display with the game content (initially equivalent to Cogmind Beta 5) remaining a known variable throughout that process, speeding it up.

Now a lot of those windows in the source material are no longer needed, but as one might expect, a sprawling code base is going to have all kinds of references to them and their contents, so outright removing them and hoping for a stable game is out of the question. What did I do instead? I moved them :)

polybot7_cogmind_ui_conversion_positioning_hacks

The default Cogmind UI layout, with arrows showing how consoles were either moved out of view or shrunk down for POLYBOT-7.

Hackish? Very. Easier than the alternatives? Hell yeah. I also blocked the commands that would otherwise interact with contents of those windows.

So technically while playing POYLBOT-7 there are a fair number of consoles that actually exist and are updating all the same, but aren’t drawn to the viewing area because they’re positioned off the screen.

One of the more specific interesting hacks is the message log. P7 still needs a message log but there’s no room for it to always be visible like it is in Cogmind, so two solutions were used in tandem here…

Cogmind already has a system for printing the combat log (separate from the message log) directly to the map, so I instead hooked that system up to the message log itself--bam, messages now temporarily appear over the map :). Though I did have to alter its behavior to always scroll downward, and shift older messages up, rather than the cyclical approach used in Cogmind (which I might go back and replace with this new one, not sure).

polybot7_message_log_using_updated_map_message_system

Sample log messages scrolling over top of the map.

But we can’t have messages staying there forever, covering part of the map, plus we need a way to review older messages anyway, so we still need an interface to provide that functionality.

For that I came up with the idea of simply reusing Cogmind’s “full message log.” In the original, pressing F4 expands the message log to have it stretch all the way to the bottom of the screen, showing many more messages for faster parsing.

In POLYBOT-7, pressing ‘m’ both repositions the log window so that its top left corner is at (-1,-1) relative to the screen (to hide its title/borders) and expands its height so that the interior covers the map. Closing it with ‘m’ or Escape (or a click) then shrinks it again and moves it back up out of view.

Rather convenient that we allowed that dedicated message log window to continue existing off-screen, eh? :D

Here’s what progress looked like when I had only adjusted a few of the windows so far; notice how the expanded log is opening just off the screen (later I turned off the embedded turn numbers by default, since they’d waste precious log space in P7):

polybot7_cogmind_ui_conversion_message_log_hack

The message log originally spanned only half the width of the map, as in Cogmind, but I later widened it to match the map width and cover it entirely when open--may as well since there’s room and it makes messages easier to read by requiring fewer newlines!

polybot7_expanded_message_log

Opening the expanded message log over the map. Note that later I decided to keep its borders visible since it looked better given the way the fonts work (otherwise letters appear right up against the edge of the screen).

One of the last things I did before actually changing the main terminal dimensions was reorganize the help screen contents to approximately fit in what would be the target area. Here’s a shot from when I wasn’t quite done yet, but a lot of the contents are already gone:

polybot7_early_WIP_help_screen

There wasn’t enough time to build an accessible options menu, but a help screen is pretty much mandatory (and not too hard) for a roguelike, plus it doubles as a game menu with the buttons there. The final version once converted to the new font and terminal dimensions:

polybot7_help_screen

As seen in the earlier layout adjustment diagram, the “Scan” and “Volley” windows (used to get an info summary for the object under the cursor, and attack details, respectively) were both moved out of view, but the info they contain is way too useful to not have it somewhere easily accessible.

While the actual console windows are up above the top of the screen, with all their logic and rendering working normally, I have a one-line strip at the bottom of the parts list that literally reads the display output of those consoles and copies it down below :P

polybot7_info_strip

The “info strip” at the bottom of the parts list, showing summaries for different objects/states.

I didn’t add this particular interface feature right away (notice it wasn’t part of the original mockups), but later on after just a little testing realized that sacrificing a potential item slot was worth it!

polybot7_source_cparts_info_strip

You can see the entirety of the info strip code here, a very messy, quick hack job like everything else done during the week xD. It’s copying text from other consoles and somewhat reformatting it as necessary to show in the new area.

Mechanics

After spending an initial day or two executing the UI plan, the next step was to get all the new mechanics working…

First came one of the main new features: part attraction. This wasn’t too hard to get running because for a long while now there’s been a particular special feature in Cogmind with a similar effect, so I could just adapt that code. A Dijkstra search is performed from the player’s location, finding all parts within range (4), and each uses pathfinding code to attempt to reach the player, one move per turn.

Tactical positioning was always important in Cogmind, but with this it becomes even more vital because optimal play must also take into account relevant item locations, including even potential drops from enemies which if too close might fill empty slots with inferior parts!

The part that attaches is randomly chosen from among those adjacent to you, making it even harder to construct a specific build if already wading through items. And parts cannot be removed individually, which would otherwise just invite boring tedium.

polybot7_attracting_parts_and_attaching

Attracting nearby parts and letting them attach.

(Note: I developed throughout the week purely in ASCII, but am demonstrating most of these features with tiles now that we have them.)

With all these items lying around (especially in the form of salvage remaining after a fight), and a lot of them going unused, there needed to be a way to get rid of all the clutter because:

  1. having a cluttered map makes finding the right item problematic
  2. given the attraction mechanics, extra clutter would make it very difficult to ever attract specific desired items
  3. there would basically always be a variety of extra parts lying around to use, making it easy to avoid having empty slots (i.e. easier to survive in general)

Cogmind has Recyclers to take care of this job by carrying salvage off to insert into Recycling Units, but there was a clear decision to use only combat-related bots in POLYBOT-7. So I again repurposed an existing Cogmind system to handle this need: item self-destruction. In Cogmind this mechanic is only used in special cases, but here it would need to be universal.

All items dropped as salvage from a robot start their own turn counter, and when their timer is up, the item destroys itself. Each leaves behind a little bit of matter, which is both useful (as ammo) and looks cool (you can still see remnants of a battle or group of parts).

polybot7_part_selfdestruction

Passing turns to demonstrate parts self-destructing because the player’s slots are full.

Obviously there still need to be good parts lying around for the player to find, so those don’t have a timer until the player starts attracting them. And to avoid allowing the player to “drag parts” around a map as backup for too long, any parts that are actively being attracted have their timers count down twice as fast.

As a bit of QoL, items glow a bit once their timer is active, and even faster if their timer is approaching zero. That system can use some improvement but I didn’t have much time and it’s only of secondary importance anyway.

Another huge strategic change to the gameplay was the removal of slot types. This took the design down the unexplored alternate route considered in 2012, which I think turned out to be really appropriate in combination with POLYBOT-7’s other new mechanics, particularly part attraction and mixed propulsion. The resulting highly flexible nature of P7 builds makes runs even more chaotic, and interesting :)

polybot7_part_sorting_ascii_and_tiles

Although there are no type headers anymore, parts are automatically sorted while also showing their ASCII/tile to the left, making it easier to quickly tell how many of a given type are currently available.

Executing this was less painful than I imagined--I mean it’s a fundamental assumption in Cogmind that slots belong to a certain type! Internally speaking, slots must still have a type, it’s just that input and display restrictions were removed or modified to ignore it. Technically every time the player gains a new slot it’s of the “weapon” type, although this is not apparent on the outside because you can fit anything in a weapon slot :P

Another key to simplifying item interaction and build management was allowing multiple forms of propulsion to be mixed (unlike Cogmind where only one form can be active at a time). Simply allowing mixing was easy enough, but the whole propulsion system would become really clunky if the old mechanics were kept but multiple types could be used at the same time. There was just no way around it, the entire propulsion mechanics would have to be redesigned from scratch!

In the design doc this was originally on my list of “stuff that would be nice but I won’t have time for,” so finding out partway through the week that I really did need a new propulsion system got me worried! To be good, a system like this would likely need to go through testing and multiple iterations, thus clearly not suitable for 7DRL.

Well, what needed to happen needed to happen, so I just buckled down and rushed through the whole thing in one morning. I won’t go into the details here, other than to say that reducing the options to only three forms of propulsion really helped. (I had already intended to remove flight because it’s no longer appropriate in a combat-focused game, and wheels because they’re extraneous and wouldn’t be able to serve a niche.)

So hover retains speed without being able to provide much support, legs slow the player down a bit but provide a bit more support, and treads slow the player down even more but provide a lot of support. Conceptually it sounds more or less like Cogmind, although the math in Cogmind doesn’t allow for type mixing, and is more complex because it supports other features like overloading (removed for P7) and propulsion that increases base speed (also nonexistent in P7).

polybot7_notes_propulsion_mechanics

The extent of my propulsion implementation preparations. POLYBOT-7’s propulsion mechanics are based entirely on a bit of quick napkin math, rather than proper spreadsheet analysis and testing.

Fortunately I didn’t have to make any changes to the system at all--it seemed to pretty much balance out in practice! I didn’t even need to change any of the item data templates from which the 54 new propulsion items were derived. Whew!

Kinda like the item clutter issue mentioned before, lack of non-combat bots would have another side effect in POLYBOT-7: there would be no Engineers to rebuild walls. Granted, this isn’t as big a problem as clutter, but rampant destruction in a fully destructible world might have some unintended consequences and I wanted to head that off. Plus it’d be cool to see the map being rebuilt, so I did that :P

polybot7_WIP_7DRL_day4_gauntlet_rebuid

“The Gauntlet” rebuilding its structure.

It would be nice if the animation were faster--it’s basically the slowest part of the game (which if you recall I wanted to be fast to play), but I was working quickly and didn’t want it to be without sfx (seeing as everything else is audible…), and the only appropriate sfx I had lying around was that long… so I matched the blocking animation length with that. At least it only actually does this if any terrain has been destroyed since the last cycle.

There’s also an announcement some turns beforehand in case players might want to react to the fact that it’s going to rebuild, for example by repositioning themselves on the other side of a wall to block pursuers/attackers. In hindsight this whole system needs a lot of work :P

Aesthetics

Earlier I mentioned the importance of finding ways to modify POLYBOT-7’s appearance to differentiate it from Cogmind. It plays very differently, so ideally its appearance should be as different as possible, too. We’ve already got the new UI dimensions, larger pixelated fonts, and color changes, but there are also a few other ways this was achieved.

Oriented line-based walls is an easy and obvious one, and it just so happens that Cogmind still includes code to apply that style (originally from the source code’s X@COM days :P). While it was easy to flip that switch, it also hasn’t been flipped on in many years so of course it wasn’t fully functional… After the bugs were fixed, it also had to take into account oriented doors, a new feature which ended up requiring some hackish code to quickly implement, and even then I didn’t quite get to perfect it (the map rebuilding system doesn’t always rebuild doors correctly xD).

polybot7_WIP_bug_doors_fixed_everything_else_broken

Oops, here’s where I finally fixed all the door issues, apparently breaking non-door tiles outside FOV in the process! Typical gamedev… A number of additional complications came from the need to also have the map memory system properly handle orientations. (About the tiles: while I normally work in ASCII I had to check that orientation worked for tiles mode, too, so I still had old Cogmind tiles in at this point.)

As a side-effect of a simple oriented walls implementation, you can get more information than one might expect regarding what’s just behind a wall, though in a robotic world this can be explained away with some logic and I left it that way to allow observant players to make inferences about the layout. I did, however, have to spend a while updating the system to ignore connections with hidden passages/doors, which would otherwise render them pointless. By the end of 7DRL there was still at least one anomaly there which would take much longer to properly address, so I didn’t do anything about it: hidden corridors connecting at the corner of a room would essentially give themselves away. The orientation system had become somewhat complicated already, and accounting for special cases like that would’ve required much more work than the simple rules I set out.

polybot7_wall_orientation_bugs

Wall orientation behaviors, for better or worse…

As you can see in the shot above, floors were also changed, using thick dots instead of full-size floor tiles. This helps the foreground tiles stand out even more, not to mention keeps a bit more of the traditional roguelike look (in 2015 Cogmind ended up going with filled floor tiles because it looked kinda different and it’s something Kacper wanted to try, which I was okay with since either approach could work anyway).

Kacper agreed to join me on the 7DRL by making a tileset, so we needed a new style for that, too. At first the thought was to give him the full 24×24 base cell size, and at the beginning of the week he put together a few concepts based on that size which were then dropped into the game to see what they looked like.

polybot7_WIP_early_tile_concepts_24x24

A shot mixing new 24×24 tileset style concepts (marked) with the new text (the rest are old tiles not converted for testing purposes). Also you can see the solid floor cells here, which were later removed.

The main issue was that I created the text by upscaling a 6×12 Terminus font (for its high readability at all required sizes), so its appearance didn’t jive with the more fine-pixeled tiles, resulting in an inconsistent look. So we thought it’d be better to go back to using 12×12 tiles and just upscale them to match the text and give the whole interface a large chunky look. I also suggested going with a pure side view, and generally as flat as possible (Kacper had already decided he wanted to work with fewer shades anyway).

poylbot7_7DRL_tileset

POLYBOT-7 mostly-flat tileset, except for robots which use two shades.

As you can see in the final style demonstrated in the screenshot below, just like ASCII mode the tileset uses oriented doors and walls, and “earth” (filled space behind walls) was converted to a simple square. This both creates a distinctive look as well as kept the tile requirements as low as possible to make sure Kacper could finish (or at least spend more time on what was really important!).

polybot7_2018_7DRL_final_style_screenshot_768p

Another pretty big change was the item color scheme. I quickly tested a number of different schemes, anything that seemed like it might work or at least had its own logic to it and was worth investigating. This change in particular wasn’t necessarily aimed at differentiating from Cogmind, but more as an experiment in how to simplify the UI.

polybot7_7DRL_item_color_scheme_sandbox_tests

Quick testing of different item color schemes in the sandbox (white are unidentified objects in all cases). #3 won. (click on this to see everything more clearly).

polybot7_7DRL_item_color_scheme_part_list_tests

It was equally important to compare what the schemes looked like in the parts list, where their tile would also appear and be used to get at-a-glance info regarding category, type, and approximate rating. (This is a pretty bad comparison because the contents aren’t all the same, nor is there a good distribution, but I was in a hurry!)

In the end I liked the simplicity of just blues. They aren’t used much in the interface, and go well with “UI green.” Even though it’s more or less a monochrome scheme, brighter shades of blue could still be used to represent higher rated parts so they naturally stick out more. And blues offer a nice range of associated colors, from azure to sky to cyan.

Note however that the player was originally also blue, and this could be somewhat confusing when surrounded by items so at the last minute I switched the player to green, since that color wasn’t used elsewhere on the map either (now that neutral bots were removed from Cogmind). At the same time I also changed upgrade modules to be green as well, since they’re 1) very important compared to everything else on the map and 2) unique to the player character so using the same color for both makes some sense.

Coming next is Part 3: Spending Too Long on Map Generation and Content!

Posted in Dev Series: 7DRL Postmortem | Tagged , , , , , , , | Leave a comment