Hacking Revised

One of the first posts on this dev blog was an explanation of the new hacking mechanics in Darknet. This randomly-generated puzzle/strategy challenge, more than anything else, is the core of Darknet's gameplay.

Alas, it needs some work.

I showed a lot of players the Darknet flavor demo at GDC, PAX East, and other events. The demo is very limited, but after watching a few dozen players go through it, a couple of patterns emerged.

First, the system was too chaotic. It was difficult to draw connections between cause and effect; players would sometimes win without being able to explain why, or lose without understanding how it happened, and neither is a satsifying outcome.

Second, players didn't see much potential for variety in the gameplay. To some extent, I can blame the demo for that; it doesn't show the wide range of puzzles that the game can generate. But the fact that this subject came up at all is cause for concern, especially since these puzzles will fill a large part of the player's time in the game.

Luckily, there's still time to do some revision! And that's what I've been working on for the past week or so.

To address the chaos problem, I decided to take inspiration from the players' existing behavior. Most players chose to fire once or twice and then wait for the system to stop moving before continuing, even though they could have continued firing (and, in fact, would have found more success this way). So, I decided to change the gameplay from real-time to turn-based: players now "plan" their shots, then fire them all at once. They can only repeat this process after the system has stopped again. This has an added advantage of emphasizing a more "cerebral" aesthetic, rather than the occasionally spammy feeling from before.

The variety problem is more tricky. In some ways, I see the puzzles in Darknet as analogous to the combat gameplay in a JRPG or roguelike, and I tried to analyze those genres for inspiration. Right now, I'm thinking about adding different types of security programs (your enemies in the puzzle) for variety. That's a little painful, since the mechanics were originally intended to offer a varied puzzle from extremely simple components, but I think it might work if they're mostly spice for the recipe.

So that's what you see in the screenshot above. The red, green, and yellow hexes (WARNING: PLACEHOLDER ART) represent the new elements of the puzzle. One is invulnerable to the player's exploits, another is a stationary "mine" element, and another actually helps the player by regenerating an exploit when it is captured. I'm still playing around with these and getting a feel for them in-game. I'm not sure if they'll stay.

I'm also considering tackling the variety problem from the other end by mixing up the player's arsenal. If the player can choose from multiple types of exploits, that might add an element of customization that's currently missing from the game. I'm considering a cheaper exploit that just eliminates a security program without capturing anything. Another might be an exploit that blocks or destroys part of the puzzle, allowing the player to trap or divert security programs. I like these ideas, but haven't prototyped them yet.

Lastly, I plan to change up the way that the puzzles are generated. Right now, security programs are placed in a mostly-random way, and the puzzle itself is formed with a standard "cave generation" algorithm. I'd like to mix in some more orderly elements, like formations of enemies or manually-sculpted gaps in the puzzle.

Dan Cook visualizes the creative process as "a snake swallowing a series of tennis balls." (Follow the link if that makes no sense to you.) Right now, I feel like I'm at one of the thick points. There's a lot that needs work, but I can feel that there's some good in what I just introduced. I just need to identify it and cull the rest.