Designing a game is great fun. As the designer, you get to curate the player’s experience from the moment they start their adventure. You can weave an intricate story around them, set them up for teaching moments, or put them in situations where their skills are tested. That ability to meticulously plan every detail – every high and every low – allows a well-designed game to become a beautiful, flowing conversation between a game’s designers and its players.
But when you’re designing a sandbox game, it can feel a lot more like handing your players loaded guns and hoping like hell they don’t shoot themselves in the foot.
As such, we’ve developed a comprehensive plan to prevent our obnoxiously feature-rich content creation system from sucking the fun out of our game. Our “sandbox disaster mitigation strategy” boils down to the following three tactics: Player Education, Helicopter Parenting, and Protocol Robustness.
Player Education
This is the obvious one – of course you should teach your player how the game works, duh! But Player Education transcends simple design principles like Learner Levels. The entire structure of Jetsam’s main story has been built around the principle that players need to be educated really thoroughly.
Jetsam is a puzzle game based around a simple mechanic – you can only move in one direction at a time, and you slide indefinitely until you collide with something that brings you to a stop. In each level, you must collect a Relic and escape to the Exit. All the game’s puzzles are based around the awkwardness of movement in this environment.
To complicate matters further, other obstacles show up in the game’s various worlds. Fuel batteries give you extra moves, gravity wells stop you cold, boxes shatter on contact, wormholes preserve your momentum and warp you across the level, and deadly buzzsaws destroy you. The game’s main story thus begins with six distinct “worlds,” each of which emphasizes a certain mechanic and teaches the player all kinds of dirty tricks for dealing with it.
That’s a lot of information for a player to retain though – so occasionally, a game mechanic from a previous world is re-introduced alongside the current world’s primary mechanic to keep the player’s memory fresh. Only after the player has demonstrated competence by completing all fifteen levels in each of the six introductory worlds are they allowed to progress to world seven and beyond, where the real challenge starts.
Helicopter Parenting
“Are you sure you want to do that?”
It’s amazing how effective a simple confirmation popup guarding the “delete all my saved levels” option can be. In fact, it’s our opinion that most of the really bad things that players can do in a sandbox game are identifiable in advance, to a certain extent. As the game designer, it’s your job to identify them and take defensive action.
Obvious things: “deletion” actions should be guarded with a confirmation, possible runtime exceptions should be caught, game-breaking exploits should be patched if found, and Hidden Rails should attempt to prevent players from frustration. Fuzzing can really help when testing your functions for strange behaviors.
Non-obvious things: players shouldn’t be able to share unwinnable levels, players shouldn’t be able to load unwinnable levels, players don’t want to overwrite their save data by accident, and players will probably try to make levels that look like penises.
Not all non-obvious things can be solved outright (too bad “Not Hotdog” from Silicon Valley doesn’t work for identifying penis-shaped Jetsam levels), but a lot of them can be made more difficult or made less of an issue through clever design. The Nintendo classic Mario Maker forces would-be level creators to beat their own levels before they share them, for example.
Protocol Robustness
In Jetsam, every level can be expressed with an ASCII code – for example, take a peek at the following level (which just so happens to be the first one in the game).
The universality of Level Codes is extremely useful for sharing and saving levels – all people need to do is transmit text between each other. However, it introduces the problem of protocol robustness – whereby we need to make damn sure that our Level Codes are backwards-compatible, and that we have flexibility available for the future should we need it.
As such, a lot of thought has gone into our encoding scheme. We settled on ASCII characters because of fears that some UTF-8 characters might be reinterpreted by overzealous text manipulation and rendering programs. We had to purposely avoid the control-character subset of ASCII as well, in order to make sure that no meaning was lost by text message apps that strip such characters from inputs.
We also left ourselves some breathing room – certain characters are invalid in our encoding scheme for now, but we might make them valid in the future to represent things like additional level types.
The moment we let Jetsam out into the wild, its success and staying power will depend greatly on a growing network effect from a massive library of player-created levels. Our Level Code protocol has to stand the test of time – we can never deprecate Level Codes once they’ve been deemed valid, or else we will have wasted our players’ hard work (and built up a library of Level Codes that don’t work!). The Level Code rules will thus be at their narrowest at launch, and will progressively loosen if we continue adding features.
Conclusion
Sandboxes are hard to design, but we’re confident that we’ve anticipated a lot of the headaches players might run into, and that we have designed Jetsam to mitigate them where possible. Players will always surprise us though – so we’re going to be launching a public Beta test of the Level Editor soon (on iOS). We’ll be adding 15 of our Beta testers’ best level creations to the shipping game as an added incentive to participate, so if that piques your interest, stay tuned!
If you liked this blog post, follow us on Twitter and check back regularly for updates.
Zonzle LLC 