Official development blog

65 Robot Hacks

We’ve already covered the design behind the all-new robot hacking system, and now for the main course: the hacks themselves! The entire initial set is complete and ready for Beta 7, all 65 of them :D

I’ll be talking about most hacks in this post, and you’ll notice their names follow a certain pattern throughout--all composed of two words, a verb followed by a noun, separated by an underscore in between. Essentially “verb_noun.” This style was chosen to clearly distinguish them from machine hacks. By default Cogmind uses a small-caps typeface so this choice may not be apparent right away from the screenshots I use here, nor does it really matter in game, but it matters for discussion outside the game. Using a consistent format will make robot hacks immediately identifiable in conversation, even if someone has never heard of a given hack before.

There are several possible requirements for robot hacks, as described in the previous post. The vast majority of hacks require having both installed a Relay Interface Framework and attached the Relay Coupler applicable for the target class, in addition to of course carrying a Datajack to initiate the hack in the first place.

cogmind_robot_hacks_requirements_distribution

Robot hack distribution by requirements.

Wherever possible I tried to add some hacks with lower requirements, though again the main point of the system is to give it fairly significant powers, and the only way to justify that is by setting sufficient requirements.

In terms of combat vs. non-combat hacks, the latter are much more plentiful:

cogmind_robot_hacks_noncombat_vs_combat

Hacks targeting combat bots vs. those targeting non-combat bots (the total does not equal 65 because there is some overlap).

This makes sense simply because there are a larger number of unique non-combat robot classes, and even more so because there’s only so much you can do with combat in particular, at least within the Cogmind framework. Let’s start there…

Combat Hacks

“Combat hacks” refers to those targeting combat bots, even though not all of them are actually aimed at fighting. For design purposes I divided these hacks into groups, helping ensure each hack fit a role and was different enough from others. There are five categories in all:

cogmind_robot_hacks_combat_categories

Distribution of hacks targeting combat robots, by effect category.

I’ll talk about the hacks by category.

Mod

The largest category revolves around simply modifying the target in some way, usually affecting behavior or hit chances (the text here is taken directly from the context help available in game):

  • focus_fire: Force system to prioritize attacking Cogmind wherever possible.
  • reboot_propulsion: Render propulsion unusable for 15 turns while the control subsystem reboots.
  • tweak_propulsion: Rewrite sections of the propulsion control subsystem to permanently halve movement speed.
  • scatter_targeting: Offset targeting algorithms to approximately halve their chance of achieving optimal aim.
  • mark_system: Mark this bot to make it the most attractive target to all allies, as well as improve accuracy against it by 10%.
  • link_complan: Tap into system’s combat decision-making processes in real time, increasing your accuracy and damage against this bot by 25% while also impairing its accuracy against you by 25%.
  • broadcast_data: Openly share the local combat network’s defensive coordination values, giving yourself and all allies 25% better accuracy against this and all 0b10 combat bots within a range of 3.
  • disrupt_area: Actively interfere with the local combat network’s offensive coordination calculations, reducing the accuracy of this bot by 25%, and that of all 0b10 combat bots within a range of 3.

This category is almost too large, as some of the hacks overlap a bit, though they still have distinct enough roles that I felt it was worth adding them all anyway to see which ones might get more use. Most of these hacks won’t make sense against weaker enemies, but that’s a standard side effect of Cogmind’s environment--most bots don’t pose much of a threat individually, the threat lies in the composite danger presented by multiple hostiles, even more so if they have different complementary capabilities. Against a stronger enemy, however, it could be worth taking the time to weaken them first, or apply a modification with some other ulterior motive.

Groups of weaker enemies are also why some of these hacks come with area effects, to work at addressing the fact that combat hacks against an individual bot may not be worth it compared to simply pulverizing them with a cannon.

Intel

Information gathering accounts for nearly half of all hacks, combat bots or not. Although there are fewer intel options available from combat bots, they still make up a relatively large category and can be quite useful in the right situations:

  • find_shortcuts: Reveal and label all hidden doors within a range of 50. (There are a lot of ways to detect emergency access doors, but none with reach like this. Could come in handy in the long run.)
cogmind_robot_hacking_find_shortcuts

find_shortcuts demo

  • find_garrison: Locate the nearest Garrison Access.
  • show_paths: Highlight all current patrol squad routes. Only effective when targeting a patrol squad leader. (It will take a observation to identify which squads are considered to be patrolling, much less find a leader, and the route data is only valid while they’re still patrolling it, so I’m not sure how useful this will be in practice, but it looks cool and can also reveal lots of valid pathways in unknown areas of the map so it might catch on. parse_system will help find/teach about patrol squads and leaders.)
cogmind_robot_hacking_show_paths_tiles

show_paths demo (paths glow intermittently, and are always visible while panning the map for easy reference; lines are color coded by squad type, and these records disappear after a while since they only matter for so long)

  • link_fov: Tap into system’s visual feed for 100 turns. Must remain within a range of 20 to maintain the link.
  • parse_system: (more on this later)

Damage

“Methods to deal outright damage” is a tiny category because merely doing damage doesn’t generally make much sense for a hacker--you either want to take down the target or achieve some other special effect. So even these hacks don’t deal direct damage, but are instead alternatives with their own niche.

  • spike_heat: Destabilize power systems to induce a massive surge of heat. (This is essentially a way to instantly get the target ready for meltown, which anyone who knows about thermal transfer from TH weaponry understands that it could start causing all manner of nasty side effects that can even start to compound. Overall it’s a very cheap way to possibly take down a target, if not very reliable because you’re at the mercy of random side effects with this one.)
  • overload_power: Cause power source to explode. Process takes 4-6 turns to reach critical point. (The effect is equivalent to EM spectrum chain reactions, and being able to trigger it at will offers a lot of tactical possibilities… Plus it’s just fun. And you’ve gotta time it right :). It’s the readily available AOE time bomb you’ve all been waiting for!)
cogmind_robot_hacking_overload_power

overload_power demo (also a demonstration of the effectiveness of doing this next to an array of power conduits :P)

Disable

This category’s hacks are akin to mods, but completely disabling systems is often an even stronger effect, though still without doing any actual damage.

  • wipe_record: Remove any record of Cogmind from memory, and block new Cogmind records from being created for 10 turns. (This effectively makes you invisible to that robot for a little while, which is pretty cool and unique.)
  • disable_weapons: Disable all weapon systems for 20 turns. (There you go, you finally have a way to do this, heh. This has been brought up a few times before by the community with regard to targeting specific systems, though until the new robot hacking there hasn’t been a reasonable way to make it a potentially frequent tactic.)
  • reboot_system: Force a complete reboot. The entire sequence requires anywhere from 15 to 25 turns to complete. (The previous system’s good old REBOOT hack is back in its new form, which does… the exactly the same thing :P)
  • go_dormant: Wipe memory and force immediate dormant state. (This is a relatively cheap way to permanently remove a target from action, as long a you can get out of view quickly and no one else is around to wake them up. In that way it can be even better than a reboot--it’s a “reboot with a catch.” If you recall, dormant combat bots only have a chance to wake when enemies are in view, or if they’re alerted by another robot.)

Assimilate

Assimilation has always been the highest goal of robot hacking, and while it’ll definitely still be useful, I’m sure it won’t be as desirable as before, or as good as other cheaper hacks that might require more creativity :)

  • overwrite_iff: Trick system into believing it is allied with Cogmind. After 10 turns the network will perform an automated quickboot to restore it to normal, a process which takes anywhere from 5 to 10 turns. (Temporary assimilation combined with a bit of a reboot is probably even better than outright assimilation in many cases--I can see this being popular.)
  • streamctrl_high: Hijack the control node to force system to act as an ally. Must remain within a range of 5 to maintain the connection. This bot will follow while in this mode. (An alternative situational assimilation, cheaper than completely assimilating a target, but of course it comes with a bit of a caveat.)
  • formatsys_high: Rewrite all system data, permanently converting it into a fully controllable ally. Requires 6 turns to complete the process. (As you can see, the old full-on ASSIMILATE hack is still here, although it’s fairly expensive so you [probably] won’t be raising large armies with it!)

The latter two hacks were originally named stream_control and format_system, and applied to both combat and non-combat bots, but I later decided it was important (and made sense) for the coupler cost to be cheaper when used against the latter group. It would’ve been possible to simply show and apply a different cost for these hacks depending on the target, but I wanted to remain consistent--one hack, one cost, so I gave them somewhat different names instead. As you’d expect, the other versions end with _low :). Technically there are 67 different robot hacks, but these pairs are equivalent in effect so I didn’t count the duplicates.

Non-Combat Hacks

Most hacks target non-combat bots, which is more in line with a hacker’s non-confrontational style, using other bots to make exploration or combat easier, or helping avoid the latter altogether. However, the wide variety of hacks also means that just about any kind of player can benefit from at least some of the system, allowing for all sorts of hybrids.

Like the combat hacks, here I’ve broken down non-combat hacks into categories, though note that I only did it for fun/demonstration purposes--it wasn’t part of the design process like it was above.

cogmind_robot_hacks_noncombat_categories

Distribution of hacks targeting non-combat robots, by effect category.

Understandably intel is by far the largest category, considering there are so many different classes with their own responsibilities and knowledge to “share,” while most other hacks deal with controlling the target and/or their surroundings in some way.

Although normally non-combat bots see Datajack hits as a threat, in cases where a hack is some kind of order they’ll override that reaction and instead do what they’re told.

Even where bots do consider it an attack, or are affected by a hack, there are currently no effects on alert level. This is cool and logical in a hacker sense, though we’ll have to see how abusable it is. That said, by extension hacks don’t score points, either--they’re just recorded in stats as usual. In any case, robot hacking is meant to be pretty good within its niche, since 1) sacrifices need to be made in terms of plot and build, and 2) it only applies to 0b10 bots.

One major area of differentiation between combat and non-combat hacks: the former requires numerous couplers, one for each target type, whereas all non-combat hacks are processed through a single Relay Coupler [NC]. That’s going to be a popular one… (it’s also the most common). If combat hacks were similarly accessible it would trivialize combat and robot hacking strategies, and the system would be less interesting overall.

Just look at all these [NC] robots that can be hacked…

cogmind_robot_hacks_noncombat_class_distribution

Distribution of robot hacks by non-combat robot class.

Any

Some basic hacks can be used on any non-combat robot, so this category is general purpose stuff which’ll be available almost everywhere.

  • no_distress: Prevent this system from generating distress signals.
  • generate_anomaly: Induce an energy anomaly resembling a long-range distress signal that will attract nearby patrols and sentries to investigate. Anomaly detectable up to a range of 15.
cogmind_robot_hacking_generate_anomaly

generate_anomaly demo

cogmind_robot_hacking_generate_anomaly_easier

Under easier difficulty modes this hack also indicates the positions of robots that will respond to the anomaly.

  • generate_echo: Destabilize power systems to generate a wave of energy which can be analyzed to temporarily pinpoint robots at a distance. Beyond a range of 20 the echo becomes too weak to be useful.
cogmind_robot_hacking_generate_echo

generate_echo demo

  • start_evac: Instruct system to follow local evacuation protocols by heading to another 0b10-controlled level.
  • link_fov, overload_power, streamctrl_low, and formatsys_low are equivalent to the combat hacks.
cogmind_robot_hacking_link_fov_multiple_ascii

link_fov demo (blue circles indicate the range outside of which the connection is lost)

  • parse_system: (more on this later)

Operator

As the most connected 0b10 class central to operations, Operators make juicy hacking targets. For similar reasons some players like to have one of these following them around as an ally, though the benefits are not identical (in a general sense, robot hacks have more potential because the bot still has greater access to 0b10 systems at the time, unlike once it’s been assimilated).

  • check_alert: Query system for current alert level.
  • purge_threat: Lower the alert level. (A useful hack, but it’s also the most expensive by far.)
  • find_terminal: Locate the nearest Terminal.
  • locate_traps: Reveal and mark all traps within a range of 30.
  • disarm_traps: Disarm the nearest trap array within a range of 30.
cogmind_robot_hacking_locate_traps_disarm_traps

locate_traps/disarm_traps demo

  • reprogram_traps: Reveal and reprogram the nearest trap array within a range of 30.
  • block_reporting: Block ability to report hostiles at a Terminal.
  • summon_haulers: Force system’s call for reinforcements to instead redirect any Haulers within a range of 50.
  • recall_investigation: Recall the most recently dispatched investigation squad.
  • clear_repairs: Clear the sector-wide repair queue and any pending Builder orders.
  • clear_recycling: Clear the sector-wide part collection queue and any pending Recycler orders.

Researcher

Researchers have a lot of options because they know stuff. Stuff you might want to know, too.

  • find_scanalyzer: Locate the nearest Scanalyzer.
  • disable_scanner: Permanently disable an active stasis system to prevent scanning and analysis.
  • locate_prototypes: Mark all prototypes and alien tech across the map, also providing their IDs.
  • report_prototypes: Force system to reveal 10 new prototype IDs.
  • report_schematics: Force system to reveal 10 new part schematics.
  • report_analyses: Force system to reveal 3 new robot analyses.

Worker

K-01 Serfs are all over the place, so it’s nice to have some things to do with these little guys. Hacking them can even be extremely useful…

  • find_chute: Reveal and mark the chute this Worker might use if immediately tasked with disposal.
  • deconstruct_machine: Dismantle the nearest non-interactive machine.
cogmind_robot_hacking_deconstruct_machine

deconstruct_machine demo (you can also try what happens when they start taking apart an explosive machine ;))

  • hold_bot: Latch onto the nearest visible non-prototype 0b10 bot to hold it in place. This task is automatically cancelled after 25 turns.
  • start_disposal: Dispose of currently held bot via a chute, if possible. Huge bots are too large to push.

Hauler

For just being defenseless bots that ferry parts, Haulers have some decent hacking options!

  • find_fabricator: Locate the nearest Fabricator.
  • drop_inventory: Force a complete inventory dump, fully identifying contents in the process.
cogmind_robot_hacking_drop_inventory

drop_inventory demo (sure you could just blow them up, but that’s unreliable and won’t give you the advantage of knowing whether any of the contents are faulty/dangerous!)

  • recall_reinforcements: Recall reinforcement squad requested by this Hauler.
  • locate_stockpiles: Mark all common part stockpiles.

Mechanic

Mechanics aren’t all that common, but aside from those operating from a Repair Station, assault squads do sometimes have one in tow, which may be a bad idea for them if you’re a hacker :P

  • find_station: Locate the nearest Repair Station.
  • release_backups: Force the system to release all backup parts from compressed internal storage.
cogmind_robot_hacking_release_backups

release_backups demo

  • deconstruct_bot: Disassemble the nearest allied visible non-huge non-prototype 0b10 bot into its constituent parts.

Watcher

Hacker’s paradise when it comes to intel. I mean, that’s their job, right?

  • map_route: Show scan information from along this Watcher’s patrol route. (While it’s possible to get unlucky and find a Watcher with a really short route, this hack can also be a gold mine of info.)
cogmind_robot_hacking_map_route_exit_ascii

map_route demo (finds an exit)

cogmind_robot_hacking_map_route_items_ascii

map_route demo (here hacking from the middle of its route, and labeling discovered items)

cogmind_robot_hacking_map_route_storage_loop

map_route demo (tiles)

  • mark_security: Mark all active security positions within a range of 40.
  • relay_feed: Permanently hook into the sensor feed system, receiving scan data transmissions from up to a range of 20 from Watcher’s position. (Basically you get a remote Sensor Array, pretty good if you don’t have one of your own, and even better if it’s a high-level watcher.)
cogmind_robot_hacking_relay_feed

relay_feed demo

Protector

Protectors are generally only found supporting assaults, and all they really have to their name are shields, so…

  • disable_shields: Permanently disable an active shield or force field system.
  • redirect_shields: Permanently reprogram defensive system to protect yourself and allies from attacks, instead of Protector’s allies. (This one’s more expensive, but if you and/or allies are close enough to take advantage of it, it’s a pretty nice buff for you plus debuff for enemies. Remote force fields are really annoying to fight through, so you want them on your side.)

Engineer

No you’re still not allowed to build new walls, sorry ;)

  • ignore_repairs: Block system messages regarding the repair queue.
  • map_walls: Reveal all walls and emergency access points within a range of 25.
cogmind_robot_hacking_map_walls

map_walls demo

Tunneler

T-07 Excavators generally hang out at lower depths where you won’t be doing much robot hacking anyway, but just in case…

  • randomize_corridors: Permanently add new paths to the local complex layout. (This is one of the few hacks I don’t think will be very useful, but added it anyway just to give them something extra related to their regular tasks.)
  • map_earth: Reveal all earth within a range of 25.
cogmind_robot_hacking_map_earth

map_earth demo

Recycler

Cogmind’s #1 annoying bot can now also be dealt with by hacking it directly, though there are already other pretty effective methods of handling them (like just shooting :P).

  • find_recycling: Locate the nearest Recycling Unit.
  • ignore_parts: Block system messages regarding the part collection queue.

Compactor

Hackers ain’t afraid of no Crushers! A single [NC] coupler is enough to pacify an entire Waste sector’s worth of these menaces (and you normally don’t need to confront nearly that many on your way out).

  • ignore_targets: Block system messages regarding waste processing targets.
cogmind_robot_hacking_ignore_targets

ignore_targets demo

And with that we’ve covered all 65 hacks, except for that one…

Universal Hack

The combat and non-combat lists above both refer to “parse_system,” a special hack that works on any bot, even non-0b10 bots. All it takes is a Datajack to access it, and it’ll always appear when hacking bots, just like the Manual command.

PARSE was available under the old system, although never really used. I had originally added it mainly for fun, thinking it might eventually become something, and now it has! For one it gives more details than it used to, including info about the AI, squads, and more.

cogmind_robot_hacking_parse_system_composite

parse_system demo (multiple)

But the most tangible advantage is the fact that it both lists all parts attached to the bot, identifies them all even if unknown or prototypes, and even adds them to your gallery if not already there! This will be a new non-evil method to get records for some of those cool parts your friends and/or NPCs are using without, you know, murdering them :P

By extension, using a Datajack on a friendly will no longer be considered a hostile action, allowing you to parse them, too.

In the past completing the full item gallery required either straight up killing your friends (preferably with weapons that increase salvage rates), or getting really lucky and not only meeting valuable allies but having them be killed and drop their special gear for you. Some people understandably disliked the former for roleplay reasons, and the latter isn’t really a feasible long-term approach given how many rare allies and parts there are.

Balance

Last time I talked about one of the first important elements of balance: access to Relay Couplers. The other main one would be the cost of the hacks themselves.

I only made a few references to cost above, though obviously these values will factor highly in terms of each hack’s relative strategic applications. Hacks can range anywhere from free to consuming an entire Coupler in one go, so for reference I’m posting my design spreadsheet used to set the costs in the first place.

cogmind_robot_hacking_design_spreadsheet_new_combat

Combat hacking Coupler costs. You can see how they’re divided into the categories described earlier.

I start with the number of hacks I think is reasonable for a single coupler, and it calculates the rest automatically so that things are quick and easy to adjust. Costs have changed a bit as I worked through the implementation process, and will likely see some more adjustments in the future, but this is a good starting point.

Here’s the cost info for all non-combat hacks:

cogmind_robot_hacking_design_spreadsheet_new_noncombat

Non-combat hacking Coupler costs.

For fun you can compare to the design spreadsheet for the old pre-Beta 7 robot hacking system, which was much more complex, and because it’s based on a percentage system isn’t very reliable--players would only bother with it if they could reach near or at 100% on their desired hack!

cogmind_robot_hacking_old_chance_system_design_spreadsheet

Pre-Beta 7 robot hacking system design spreadsheet.

We went from 5 hacks straight to 65 :P. And this is just the first batch--more could be added, or some might be tweaked or even removed down the line depending on what hacks players use and how. We’ll have to see how Beta 7 turns out first!

Posted in Mechanics | Tagged , , | Leave a comment

Robot Hacking, Take 2

Over three years ago, before Cogmind’s first alpha version was released, I wrote about robot hacking. Well we can keep that post around for posterity and historical research purposes, but as of the next version robot hacking is undergoing radical changes and a major expansion. This post will explain the fundamentals of the new system (much of this content was originally serialized in a series of SITREPs on the forums and Steam news).

Background

First a bit of history.

Back in the pre-Alpha days (2015 and earlier), robot hacking was never fully realized. Ideally it would be designed to fit in with all the other systems, but there had really been almost no playtesting since the 7DRL and three quarters of the world had yet to be created, so there wasn’t much to go on at the time. Rather than build up something large right away, a better long-term approach would be to just add a smaller functional placeholder that could be tweaked or possibly replaced when necessary as the rest of the game took shape.

So then, as now in Beta 6, there were just a handful of general options running the spectrum from “temporarily disable” to “permanently assimilate.” As it was clearly an underdeveloped system tangential to everything else going on, Alpha players almost entirely ignored robot hacking for a long while, exploring other mechanics instead.

Then came late Alpha, and it was discovered that a Cogmind could stack Hackware like there’s no tomorrow and literally own anything in the complex, especially later in a run. Here’s an example of this type of build, in a screenshot shared by zxc:

cogmind_zxc_late_game_robot_hacker_build_alpha

zxc’s uberhacker loadout.

A +247% to hacking and the ability to hack robots around corners before they even know you’re there? That sounds mighty OP! (zxc used such a build in early 2017 to achieve the highest-ever Cogmind score, a record which still stands to this day)

Certainly it takes skill to set up, but roguelikes should technically get more challenging as a run progresses, not easier, and that’s generally how Cogmind works except when it came to strategies abusing this mechanic :P

Flight hackers had their fun with magic wands for a while, then of course I had to nerf it, explaining the diminishing returns of high-level robot hacking over the length of a run as a result of the system adapting its defenses. That said, even the nerf itself was just a temporary band-aid, because clearly much bigger changes were necessary as part of a new system, and that point would be coming in late Beta given that all the other systems were pretty much done.

And that’s where we are now, adding Cogmind’s last major system (“last” on the FAQ’s main roadmap, but I have more secrets planned, plus of course there’s always this which might happen :D).

I collected and mulled over numerous ideas for how to revamp the robot hacking system for more than a year. There were quite a few reasonable possibilities to think through, but also a lot of potential pitfalls! Devs are unlikely to get a system absolutely perfect the first time, but as long as it has a solid foundation it can be tweaked and expanded without too much trouble if necessary. So this foundation is extra important. I’ve never spent this long designing a single system before (21 hours just designing!), and it went through lots of iterations and refinements (all on paper) as it started to look both relatively balanced and interesting.

It’s also worth pointing out that I’m very glad I didn’t move on this system earlier, or try to have a complete extensive system available from Alpha 1. It would have had a negative, limiting impact on other developments, and much about the current state of Cogmind’s world and content has enabled me to make smarter choices about how to best integrate robot hacking into it all, be it the tactics, strategy, or lore. In short, doing this earlier would’ve meant more wasted effort and less pleasing results.

So what is this new system already…

Principles

While reviewing all the concepts floated over the past year, I identified the major areas that a new robot hacking system would need to address in order to fit in with Cogmind’s many other systems and also be enjoyable but balanced in its own right. The resulting underlying principles of the new hacking system:

  • Decouple machine and robot hacking. Even just machine hacking alone provides a wide range of extremely effective abilities, so there’s no reason to keep both types of hacking under the same umbrella of supporting parts. Thus robot hacking shouldn’t be based on standard hackware, we’ll need something else.
  • Control the snowball effect seen with robot hacking during alpha testing. Sufficient stacking of machine hackware makes pretty much any hack a success, and this is fine for players willing to invest that kind of slot use, but applying the same approach to robots makes it far too easy to eliminate any and all danger by accumulating more and more allies, or at least nearly effortlessly taking out enemies. We’ll need upper limits on what is possible.
  • Remove much of the RNG. Under the old system, anything but a good robot hacking setup is too unreliable--you have to hit with a Datajack, penetrate to their system, and then there’s still the final hack chance to succeed at. RNG works well for machine hacking, but with robots the time element is much more limiting, and the consequences of failures are too dire, especially for bots that are not necessarily set up for combat! Too much RNG in a system like this makes planning much more difficult, thus keeping the RNG would basically work against the combat hacker style itself. Removing the RNG here will be very good for balance.

Compared to the old robot hacking system, overall there are more limiting factors under the new system, but by extension that means it can be more effective! More effective is more interesting, as it also increases the range of possibilities. The goal is not to become OP, it’s to gain tools for solving a subset of unique situations and challenges, and being creative in how these are deployed.

Relay Interface Framework

This is where it all begins, with this machine:

cogmind_RIF_installer

Interfacing with an RIF Installer.

Every garrison will now contain an RIF Installer, and it’s your choice whether to use it and deal with the consequences, and of course take advantage of the benefits! You’ll only have to do it once, and the first garrison appears on -8, so that would be your earliest opportunity, though you can also choose to install at any garrison after that as well. You still get all the other benefits of a garrison on top of that, and there will be another advantage particular to robot hackers that we’ll get to later. Basically I liked the idea pioneered by the original system that robot hacking is linked to garrisons (albeit manifested differently), so the new system really emphasizes that link, and as a better system should also better incentivize the occasional garrison visit!

“RIF” stands for Relay Interface Framework, and with that you’ll gain access to dozens of ways to manipulate other robots via the complex-wide garrison relay network. Like a number of other major strategic decisions, however, this comes with a drawback as it will prevent you from forming certain… alliances. Such is the strategic cost of effectively linking up with 0b10 to facilitate access to their systems. And from this point you can probably infer that the new robot hacking system only works on Unaware! This is just the first of several limiting factors--robot hacking will be quite useful, but not a panacea. It’ll be what an interesting system should be: very effective when used creatively, but also challenging you to create manageable situations to begin with. Unlike the Alpha approach of “it’s an enemy, reboot/assimilate it!!!” there will be many unique encounters and different methods of approaching each. As with other strategies, planning ahead will be very beneficial, and to me that also really fits the theme of a robot hacker, whether a stealth hacker or combat hacker or anything in between.

Planning ahead will also be facilitated by the fact that the new system removes much of the RNG from robot hacking :D

Relay Couplers

The hacking process itself starts similar to how it exists now: Datajacks are still a thing, and you have to both hit the target and penetrate to its system, but after that the processes diverge significantly. Robot hackers will often want to make use of a new type of Hackware dedicated to robot hacking: Relay Couplers. As Hackware these are destroyed on removal in normal fashion, and even have limited uses, but they enable all the best hacks.

cogmind_relay_coupler_grunt_sample

Sample Relay Coupler.

Successfully attaching a Relay Coupler requires that an RIF already be installed, otherwise Couplers fry themselves due to incompatibility.

cogmind_relay_coupler_no_rif_self_destruct

Self-destructing Relay Couplers. Oops, better get that RIF.

Couplers come in a variety of types (there are 12) and must match the target’s class to gain access to high-level hacks for that target. For example a “Relay Coupler [Grunt]” is used to hack Grunts. The one exception is Relay Coupler [NC], which applies to all “non-combat” bots, so that one alone will be much more widely applicable.

The alternative approach would’ve been to have Hackware that enables specific hacks, rather than targeting specific bots, taking the system in a completely different direction, but I believe it’s far more interesting to be able to do almost any kind of hack to a specific kind of robot than the same hack to any robot. This both opens the door to a greater variety of strategy and tactics, and will essentially force that variety in many cases because there’s no one-hack-suits-all ability.

Note that not all hacks require a Coupler, or even an RIF. So Datajacks will still have some robot hacking purpose aside from their other functions. The new PARSE behavior will serve that purpose alone, as it’s free and always works, usable on almost any robot. (I’ll demonstrate that later once it’s implemented.) There are also some cost-free hacks that still require an RIF, for use against non-combat bots.

Most hacks do, however, require a target-appropriate Coupler to pull off. These hacks appear in their own box with a “Coupler” header.

cogmind_robot_hack_ui_description_coupler_related

Robot hacking UI diagram.

The numbers off to the right aren’t the percentages you might expect given the other/previous systems, but are instead static costs for executing each hack. That cost is directly deducted from the Relay Coupler value seen at the top and the hack takes effect, period. So Couplers are expendable, and each has its own “remaining value” before it is depleted. You can carry or attach as many Couplers as you want, and if you have more than one applicable Coupler for the current target robot their values are combined into a new total.

As you can see, the new system is easier to balance by forcing a trade of valuable slot/inventory space for guaranteed hacking effects, whether you want them to play a non-combat role, a supporting role, or a fully confrontational “I own you all” role.

cogmind_robot_hacking_build_sample_couplers

Sample robot hacking build with Datajack and a few active Relay Couplers.

As mentioned before, hack costs are static--there is currently no way to influence the cost via utility or other means, and allowing for the modification of costs would make it easy for robot hacking to creep into OP territory again. Better to have only one variable at play, the Coupler value, which can in some cases be higher than normal so that there’s room to get more out of a single Coupler!

I’ve generally avoided consumables in Cogmind’s design, at least in the traditional sense, but Couplers don’t really fit that sense anyway since they have multiple uses and are also quite flexible in what they can be used to accomplish.

Coupler value is a factor of two elements: its source, and the type of robot it applies to. An individual [Behemoth] Coupler won’t let you do much, though you could combine more than one to do just about anything! A lone [Grunt] Coupler, on the other hand, will last for a lot more hacks, depending on what you want do accomplish. There are five ways to acquire Relay Couplers, two of which I’ll leave for you to discover, but here are some of the main ones:

cogmind_destroy_garrison_relay_for_couplers

Garrison Relay.

Straight to the source! Like previous and current versions of Cogmind in which Garrison Relays play a role in robot hacking (albeit through a different mechanism), so do they under the new system. Venture into a Garrison itself and blow up relays to collect the most valuable Couplers inside.

cogmind_destroy_garrison_access_for_couplers

Garrison Access destruction releasing Relay Couplers. Doing this will likely tempt some players to try out robot hacking ;)

Destroying Garrison Access locations will net you some Couplers as well. They’re partially used and thus not as valuable, but at least they’re fairly easy to acquire!

If lucky you can also find special caches in a Garrison containing lots of high-value Couplers, but don’t count on it :P

UI Upgrades

Manual hacking of robots is already a thing, but it’s a pretty simple system that’s always been used purely as a way to enter random codes you might collect as a result of certain encounters. There’s not much of a need to type out any commands to begin with, considering there’s a complete context menu that appears to recall all the codes, as seen here using the old hack list:

cogmind_robot_hacking_manual_codes

Sample special codes menu during robot manual hacking (old hack options).

But with the number of hacks increasing significantly in Beta 7, some keyboard players might be more likely to prefer entering hacks by typing them out rather than finding them in the menu. Of course no one’s going to bother if you have to type out the entire command, so like manual machine hacking we’ll need to facilitate the process! For this I added both autocompletion and a command buffer:

cogmind_robot_hacking_autocomplete_and_buffer

Robot hacking autocompletion and command buffer demo (parse_system effect at the end is a placeholder for things to come).

It kinda sucked to have to switch the whole manual robot hacking system over from its original simple architecture (which already worked nicely) to one that could support these new features, and many hacks were involved, but hey everything once again works as expected so I won’t complain! QoL FTW!

While at it I also added an advanced option to alter the default cost-wise method of sorting Coupler-based hacks:

cogmind_robot_hack_sorting_options_sample

Two different preferences for sorting Coupler-based hacking options.

Another tweak made even more recently (after all the above media was created :P) was to have the header for any Relay Coupler hacks highlight the remaining value to make that clearer:

cogmind_robot_hacking_relay_coupler_value_highlight

Robot hacking UI with highlighted Coupler value.

I had noticed the potential issue while creating the original mockup weeks before, but didn’t see any immediate fixes so decided to leave it like that for the time being. And of course as soon as I started sharing gifs there was already a comment about that value not being clear enough, so… yeah, I put some more time into finding a decent solution :D

In a departure from the machine hacking standard for the past five years, robot hacking is also getting context help! All listed hacks indicate exactly what they do when accessed via right-click or shift+letter key.

cogmind_robot_hacking_context_help

Sampling context help for robot hacks.

Unlike machine hacking it’s quite important to know precise effects in advance because robot hacking often has real consequences while facing off against enemies (one of the principles discussed earlier with regard to the switch away from a percentage-based system). Obviously it’s also good for learning the mechanics, and having easy direct access to what hacks do so that infrequent players don’t have to remember their effects. It’s possible this feature will also come to machines later (I talked a bit about that dilemma in SITREP #32).

And one last UI feature for completeness sake: Automatic removal of newly-depleted Relay Couplers also comes with its own animation in the parts list.

cogmind_relay_coupler_expended

Relay Coupler depletion.

That about covers the fundamentals of the upcoming robot hacking system. There’s a lot more work to do lore-wise and with regard to other peripheral elements, not to mention putting together all the actual hacks themselves, but the latter is a topic for another day!

I’m pretty confident this system will serve as a good foundation for a new play style, as well as augment existing styles, and do the concept of robot hacking justice even if its finer points require a little tweaking down the line.

So no there will not be a Take 3 ;)

But we do now have a follow-up, an article covering the first 65 hacks available under this system!

Posted in Mechanics | Tagged , , | Leave a comment

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