Exploit Optimization

Once upon a time my friend Gregory Weir released a game called Exploit. I immediately fell in love with it and played straight through it. The story was very strong for a puzzle game, and the implementation was nearly perfect. I immediately wanted to port it to every platform, begged for source code access, and then never set aside the time to do any porting.

More recently, however, Future Proof Games has been working toward the release of a brand new game in that world, Exploit: Zero Day. Unlike the last version it runs in a browser, making it so much more accessible, and … tweakable.

Over the past couple of months I’ve had the distinct privilege of having “Alpha Zero” access (sign up for the newsletter for access codes!) and did my best to put that to good use. After being that guy and pointing out all of the bugs, I also noted that it was possible to modify outbound requests containing solutions resulting in impossible scores. Once it was no longer possible to … erm … achieve the impossible, I devised a plan to at least achieve perfection.

Until the game has different rewards, the interface presents the fastest completion times for each individual system. I completed all of the systems during the first month and, being the micro-optimizer that I can be, I kept playing until I was at the top of each of those lists. It’s totally not the point of the game, but completely in fitting with how I play games. (As you can imagine I’m really fun on board game night.) For a month having the fastest solutions and simply knowing that it was possible to optimize further was enough for me.

But then a month later I went to see how quickly people were beating systems and was disappointed to see that I was no longer at the top of each list. Playing with a trackpad there was simply no way I could compete with the fastest times, so I would come up with a solution and modify it by hand until it was perfect. The problem with that approach is that it becomes tedious. Remember how I said that this game ran in a browser? I finally decided to pop open the inspector, find the hook for system solving, and wrote a bit of JavaScript to iteratively improve the solution time until it was “perfect.”

The first step was to eliminate the time lag before starting to solve the puzzle. This isn’t anything particularly mind-blowing, but if you sit and analyze a system for a while before starting to solve it, this can make a tremendous difference in your solution time:

The next step is to slowly step back the last packet that was fired’s firing time until it no longer works. And then you move to the second-to-last and all subsequent packets, et cetera:

This works, but has one amusing side effect by virtue of being brute force: I’m responsible for probably 90% of the solutions in the Exploit: Zero Day database. It could be optimized by intelligently choosing the step for the current context, but that would be more code and heuristics to figure out.

Now that I have the tools available to me, I’m considering building Exploit systems that require you to actually build tools in order to complete the system. It seems like a really fun way to extend the Exploit meta-game–which is already intended to be far more than just solving the puzzles themselves.

Check out Exploit: Zero Day! And if you’re fluent in code, find ways to improve my solution optimizer!