Improving the Hacking Experience

The terrible curse of gamedev is that it’s really hard to finish a game when there’s always something that could be better. The great thing about gamedev is that there’s always something that could be better, meaning room for more new features and content to make players happy :D

The previous round of major UI enhancements (in the form of extra optional features) was centered around inventory management, which lies at the very core of Cogmind’s gameplay. And now more recently the less central but still oft-used manual hacking system has undergone a similar treatment, getting its own set of UI add-ons that players appreciate.

In Cogmind hacking is most easily performed directly, via the available list of valid machine commands marked by letters and with percentages reflecting their chance of success, but sometimes players want to carry out more difficult “indirect hacks” of unlisted targets by keying them in manually.

Manually hacking a terminal, including use of unlisted targets.

Forcing the player to remember the information required to take advantage of this strategy, and type it repeatedly, may seem like unnecessary requirements. We have computers to do that sort of thing for us, while we apply our brain’s processing power instead to problem solving--what exactly to do when. That’s the more enjoyable part of games for most players. (Note that it is, however, quite in theme to be typing hacking commands without any form of assistance, and at least one player specifically requested that none of these features be available, so it is possible to turn them off.)

Repetition was initially addressed in part by the “hacking buffer,” allowing players to automatically cycle back through previous hacks (including those during previous runs), or even modify the buffer directly as an external text file.

Cycling through the manual hacking buffer to repeat previous commands.

But the buffer is more suited to recent hacks, since it’s cumbersome to cycle back through dozens of entries to find a particular one, in which time you may as well have just typed the command out again :P. There are buffer features like automatic removal of duplicates and non-existent commands, but they only go so far.

Thus we have several more features to aid the hack-minded Cogmind…

Unique Codes

Any part of the game that causes extra non-fun work for the player is a candidate for streamlining, and when the story portion of the game exploded in Alphas 8 and 9, unique codes for manual hacking became just that.

Obtained by talking to NPCs or accessing certain terminal records, these codes could then be entered while hacking other machines or robots elsewhere in the world for some kind of effect. The problem: using them meant having to know them, which meant having to write them down, or even worse, scrolling way back through the message log to find where they were last referenced. I made the codes short (only four letters) to facilitate this, and at first there were only a couple anyway so it wasn’t much of an issue, but with more plot comes more codes, and neither of the old approaches were satisfactory--scroll searching was a slow process, and writing them down would often be wasteful since they might never be used. (Note that these codes are randomly generated, so they change every run.)

The UI does all this automatically now. Mouse players can simply click on the code they want to input, while keyboard players first type the normal code hack prefix (“\\”) to switch focus to the code list where they only need to press the corresponding letter key. The list even conveniently includes who gave it to you and where.

Interacting with the terminal code assist feature.

And the same feature is available for manual hacks targeting robots, not just machines:

Code assist feature activation while manually datajacking a Sentry.

No more writing down codes :D

Autocompletion

Us coders have autocomplete for our source hacking, so why not give it to players, too? :)

There are currently 82 machine commands in Cogmind, and while I’ve attempted to use relatively systematic naming conventions, it’s still a lot to remember, especially those which aren’t used so often. And even when players do remember exactly how to hack their target, the occasional typo is also annoying.

The solution is to take whatever the player has typed, even as little as one letter, and start narrowing down the possibilities, compiling a list of all matching commands and displaying the first as grayed out text, possibly followed by a number indicator if there is more than one match available. All the player has to do is press spacebar or tab to accept the gray text rather than typing it out in full, or keep typing to narrow down the possibilities, or press up/down to cycle through the other matches!

Manual hacking gets autocomplete!

From the outset all common commands are considered for the autocompletion list, while unauthorized hacks learned while playing are considered only after discovering them, information that is carried from game to game. This is to avoid spoiling secrets that are intended to be learned through regular play (NPCs and terminal records provide this info), though players who for some reason don’t have their user data from previous games (or those who look up spoilers) can type the commands out manually and they’ll be permanently considered “learned” as well.

The automated recording of secrets learned via lore is itself helpful for hack discovery, in case a player didn’t notice or forgot what some NPC told them (and doesn’t want to search through their lore collection UI for it :P), since simply typing “Trojan” at the command prompt (or really even just “tro”!) will list all known Trojans for that machine. (“t” and “tr” work, too, but there will also be non-Trojan matches due to trap-related commands.)

Indirect Queries

Querying terminal records often returns results that themselves contain further topics to query, forming a web of potential lore. Mouse users can simply click on these other topics to attempt to hack them indirectly, but keyboard users have always had to type out the Query(Topic) command manually.

Until now.

When keyboard mode is active, reference numbers appear next to each available topic and simply pressing the corresponding number key will attempt to hack it.

Hacking a chain of lore-related terminal records purely via keyboard, using reference numbers.

The system only supports the ten most recent topic references (because number keys), but that’s plenty enough to have full access to several consecutive hacking results. After the tenth topic, the numbers will wrap back around to 1 again.

To reiterate, mouse users will not see the numbers, and I don’t think keyboard users will be impacted too much in terms of readability, since the numbers are grayed out and one can learn to ignore/read past them until they’re needed. The affect on readability was, however, one of the main reasons I repeatedly postponed implementing this feature. In the end I’ve decided that convenient functionality is more important, and actually kinda think they make the entry text look cool, anyway :)

Another query-related bonus feature for both mouse and keyboard users is that these topic references themselves now also include a ‘!’ prefix to indicate that a particular record has not been read/discovered before, to facilitate lore collection.

‘!’ marking lore records that haven’t been hacked yet.

This is the same indicator that appears in the machine target list for direct queries.

Addendum

None of the features mentioned in this post are necessary, but they sure are convenient! Why weren’t they just implemented to begin with?

The most obvious answer is time. A lot of work goes into the base features and UI itself, and by the time each is complete and able to get the job done, all the test have been run, the kinks worked out, the bugs fixed… it’s really draining and often feels about time to move on to the next thing :P. Besides, there are always other pressing features that need attention, too! Thus many ways to further improve an experience often end up filed under “Maybe later?” This is fine because it feeds into the second reason:

Sometimes rushing to add “improvements” turns out to be a bad idea. With a working foundation in place, time permitting it’s always better to watch how players use a given feature, listen to how players talk about it, and use it yourself. With more use case data, over time even better solutions might become apparent. Development that moves too fast in one direction without waiting for intermediate results is more likely to waste time, as efforts might clash (either code-wise or UX-wise) with another feature which isn’t as mature.

So in my case I keep a list of features like these and revisit them occasionally to look at them from a new perspective, maybe add some more notes, and when a particular feature hits critical mass (sometimes pushed over the edge by player requests or what I hear players talking about :D), it becomes the next implementation target and will find its way into a near-term update.