DevBlog #9 – SS2 Strategic Node Hacking

This is part of a series of development updates discussing the main features of the upcoming version 2.00 of System Shock 2 – Rebalanced Skills and Disciplines.

Strategic Node Hacking
Have you ever felt that System Shock 2’s hacking minigame is missing something? It’s not too bad, all things considered – it occurs in real-time gameplay, so you have to be mindful of your surroundings while you do it, and there’s a tangible influence from character statistics that you can really feel as you upgrade your abilities. But at the same time, there’s not really any depth to the minigame itself, as it’s just an RNG clickfest until you get three in a row. The only choice you have is whether to click the red nodes with a risk of a critical failure (almost never), and whether it’s worth the cost to start/reset the minigame.

A long time ago I was watching someone stream SS2 for their first playthrough, and they engaged with the hacking minigame in a way I’d never seen; they strategically clicked those nodes which had the greatest likelihood of getting three in a row, while otherwise being conservative about their clicks. Evidently, they had thought each node click deducted nanites rather than just the board reset. It dawned on me that this simple change would be a massive improvement to the minigame, as it would go from a completely mindless clicking of nodes to something that benefitted from a little bit of strategy.

Years later when I began modding SS2, I poked around with the custom overlay system to see if maybe such a change were possible. What I found was initially disappointing. The original user interface implementation was locked away in the engine code, totally inaccessible to editing. But maybe I could get away with some clever hacks (if you’ll pardon the pun)? No dice there either: native overlays always display on top of custom overlays, and block all mouse input. I couldn’t even track where the mouse cursor was if it were hovering over a native overlay, let alone intercept any mouse clicks. Indeed, the only way to make this happen would be to reimplement the entire hacking minigame from scratch. So I gave up on the idea for two whole years, keeping it in the back of my mind as a pipe dream change that would likely never see the light of day.

Even later, when I had really familiarized myself with the overlay system and created complex custom user interface screens for weapon and armor modding, the idea of recreating the hacking minigame from whole cloth was a daunting task. Some preliminary investigation revealed some difficulties with even tracking what object was being targeted for a hack, as the usual GetInterfaceFocusObject() and OverlayGetObj() script services weren’t capable of grabbing the object ID that was hosting the Hack/Repair/Modify plug button when the minigame window was queued up. One day I figured out a workaround for this, similar to those I had used for dealing with mouse click events on my custom overlays; allow the native minigame window to open for one frame, and then grab the target object ID. This worked!

This was only the beginning, of course. I would need to carefully reimplement all of the original UI functionality in Squirrel script. Happily, I had gained access to a partial decompilation of the original C++ code in the time since I had learned to use custom overlays, which would be my ticket to porting over (and modifying) the minigame. Most of this was a fairly straightforward job, but there were as always a few complications. Looking Glass included a string manipulation library with a word wrap algorithm in the Dark Engine, which I couldn’t use in Squirrel. What’s more, the character arrays used in Dark weren’t something I wanted to emulate with Squirrel’s string operations, so I looked online for a different word wrap algorithm and tinkered around with it until I could finally get the spacing, organization, and stacking right. This ultimately turned out to be the hardest part of this project!

Another challenge was replicating the maximum interaction distance behavior from the original UI. Unless you’re remote hacking with psi, SS2 disallows you from interacting with objects from far away via the user interface, which it does by globally checking the player distance at every draw update of the base overlay handler and closing any windows associated with faraway objects. With my custom overlays for weapon/armor modification, I’ve previously gotten around this by closing the window when you move the target item out of your inventory (as you can never look at the mod list without having the item in your inventory in the first place). Hacking, however, can be performed while running in circles around a turret, or fidgeting next to a keypad. So I had to implement a parallel distance check in the draw update of my custom overlay handler, with special exceptions for when items are in the player’s inventory (as their position in the world as read by the object property system is not updated until the object is dropped back into the world), which receive the same workaround as weapons and armor to close the minigame window when moved out of the inventory, taking advantage of the “overlay oracle” system I invented to allow object scripts to pass data and requests to and from the custom overlay system, detailed here.

You can see a demonstration of the new hacking minigame below. Each node click deducts 1/5 of the original start cost (minimum 1), while resetting the board costs 2/5 of the original cost (minimum 2). It pays dividends to do a quick scan of the board before you begin, based on the placement of the critical ICE nodes in the board layout. Corners and junctions are usually the best places to start, as they give an opportunity for multiple three-in-a-row connections if one line fails. If the first click succeeds, it’s better to click two spaces away at another corner/junction so that you can rule out (and avoid clicking) nodes that could never add up to three.

Other Improvements
The total reimplementation of the hacking minigame (which also applies to the repair and modify skills) opened the opportunity for some other QoL changes and systemic improvements:

  • The minigame window now displays chance to succeed each node click instead of chance to fail, which was generally harder to parse from character statistics
  • The minigame window no longer closes abruptly when the target object disappears from the world due to success/critical failure (such as when successfully repairing a spent battery, or destroying a weapon during an attempt to unjam it), instead freezing its state so the player can better interpret the consequences of their actions
  • Psi hacking now respects the reworked Power Psi O/S Upgrade detailed here, overloading up to a new maximum of PSI 11 where previously it was the sole psi discipline to which I could not grant +3 overloading
  • Psi hacking now has double psi point costs with Recursive Psionic Amplification active, balancing what would otherwise be a free increase to hack chance (note that the initial cast of Remote Circuitry Manipulation was made free)
  • Psi hacking now counts Psychogenic Cyber-Affinity towards effective CYB, where previously it only utilized the player’s PSI stat (divided by 2 & rounded up) as the player’s effective Hack skill and CYB stat. This helps counter the prohibitive cost of psi hacking (which still does not benefit from hack software bonuses) with a logical synergy of player abilities

This small but impactful change to the hacking system, on top of the previous expansions to repair and modify, should make builds centered around technical skills quite a bit more engaging than they were before. You can try the latest beta with the hacking rework here, and otherwise look forward to the impending release of Rebalanced Skills and Disciplines v2.00.


Leave a comment