This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.
This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.
I certainly spent a long time working on achievements proportionate to other features, so I guess the first question that comes to mind is why add them 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:
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:
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.
Notice that these categories somewhat roughly align with the six reasons for adding achievements listed earlier, which probably isn't a coincidence :)
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:
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.
Prior to building the achievements list I also set out some important guiding principles:
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!
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!
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.
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.
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.
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:
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.
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 64x64 JPGs, in which I can fit up to a 5x5 grid of 12x12 pixel ASCII (12px happens to be the default size at which I draw ASCII art), so 5x5 it is.
But icons also need a border, and inserting a border into a 5x5 grid means all that's left for content is a 3x3-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.
Looking closer at the structure of individual icons, there are two main ways to differentiate categories: border style and color scheme.
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.
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:
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."
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.
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 achievements need a display icon as well, and there are about three ways to handle them:
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) 64x64. 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 60x60).
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.
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:
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.
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.
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).
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 :)
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).
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.
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.
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.
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.
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.
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.
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...)
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...
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.
The source is somewhat bloated with additions of my own, which I'll get to in a moment.
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 :)
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
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).
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.
(This article was originally serialized here, on the Grid Sage Games dev blog.)