Here’s a nice, simple game prototype that explores the core movement, inventory, and timing mechanics of Motherload that took just 10 minutes to design and 60 minutes to program using our new design tool. Rather, this is the half of a nice, simple game prototype that supports human play testing, but there is more to it than that.
Why make a relatively crude approximation to an awesome game? Well, we we’re really more interesting in testing the capabilities of our new system called BIPED which provides computational support for play testing game sketches. The system aims to provide equal support for human play testing (the traditional kind where you and your friends poke at a program with graphics and sound, having your fluffy emotional reactions and stuff) and machine play testing (the kind where the computer pokes at your game’s formal rules with theorem provers and laser beams and reveals exploits and speed runs).
The basic idea behind BIPED is to ease the transition from fuzzy, informal, board-game-like paper prototypes to rigid-rule computational prototypes of game ideas. The first time you “code up” your game idea, you make a lot of somewhat arbitrary design choices (regarding the formal representation for things like health levels, combat resolution, input mappings and the like) and it is easy to overcommit to these choice while you spend your weekend plugging in graphics just to get the thing running. You are making this program so that you can get the kind of feedback about your design that you couldn’t from the non-computational version of your game, but you shouldn’t have to pay too much for this feedback. Let’s take a look at how this works in the context of the game mentioned above.
DrillBot 6000 is an action-oriented space-mining simulation game, but you might not be able to tell this from the video. The player navigates the robot (a small, yellow token labeled “db6k”) around caverns (the network of green spaces connected by lines representing pathways), mining rocks (other tokens with either non-descript or fancy names) while managing a dynamic energy level (textually represented at the bottom of the instructions panel). Mined rocks are stored in the inventory (another green space) until the robot returns to the base (space) and triggers the trading action which sends the rocks off to either the bank or slag pile (you guessed it, spaces) depending on their value. Checking in with the base also entitles the robot to a complimentary refill on energy which is used in mining, upward motion, and slowly drains with inactivity as well.
We described the rules of our game in our game sketching language. The definition (take a peek!) first lays out rules and setting, declaring dynamic state and events that can change it, and enumerating all of the caverns, rocks, and pathways and how they relate to one another. The rest of the definition tells the system how to link the abstract world of our mining robot up to a simple set of visual representations. As if we were setting up a board game, we say that the robot and the rocks are tokens (you can imagine them as cute little miniatures) that can sit on named spaces (like the properties on the monopoly board) which are linked by lines (which help the player understand which navigation actions might make sense). The glue between the visual interface and the game world (the UI bindings) also describes how actions like clicking on a token that represents a particular rock translates into the a mining action for that rock in the game world. Some elements of interface have no real connection to the abstract game world (the instruction text, title, and awesome streaming mp3 background music), but they help the player understand the idea the designer was trying to illustrate and give clues as to how to decode the otherwise meaningless yellow, green, and gray shapes on the screen.
BIPED’s two legs read this single game definition, but take each take it in a different direction. You’ve already seen a bit of the human play testing support in the video above, and maybe you can imagine how we might see simple design bugs manifest themselves on-screen, notice that our friends felt too rushed by the spontaneous energy drain or (more often) failed to even notice there was an energy level in the game because it had drained to zero while they were reading the instructions. This is accomplished by having a fairly straight-forward game engine call out to the game’s rules as if it were just a script whenever the player clicks something or a timer expires. The UI bindings tell the engine what to put on the game board at startup and how and when to animate the little tokens. We could have gone overboard with the visual representations, allowing fancy image sprites or 3D model to stand in for tokens and spaces, but we decided that a clean-but-abstract visual aesthetic would help keep players focused on the abstract game world and tempt them to get hung up on temporary art assets.
Remember that we gave a formal (“code-level”) definition for the rules of the abstract game world. This definition didn’t depend on the input mappings — it just said what was possible and how to determine the consequences of various events. BIPED’s machine leg (the peg leg?) pairs the game definition with another kind of game engine. Our analysis engine (an abstract/logical game engine?) is a rather unnattractive pile of logic programming tools, but it gets the job done. The main function of the analyis engine is to find abstract game play traces (ordered sequences of game events) that meet interesting criteria. Using a language similar to the one used to define the game (ok, we’ll admit it, it was Prolog all along), we can say things like “at least 6 rocks must be put in the bank without the robot ever refueling” and have the system give us a step-by-step walkthough of how to accomplish this. If we just made some radical change to the mechanics and we want to know if the game still makes sense (but we haven’t even updated the interface code yet), we can ask the analysis engine for a random trace with no specific constraints (here is an example trace from DrillBot 6000). Getting fancier, we asked for speed runs by looking at traces that maximized the number of rocks banked within some time window. Interestingly, these speed runs revealed something about our human players that we hadn’t consciously noticed during human play testing: humans are really conservative about their robot’s energy level, topping up when their tank was still half full. The analysis engine determined that a sufficiently hard-core player might pile quite a few rocks into their inventory before returning to the surface, saving several steps that our friends spent recovering old ground to refuel.
While it might be no big deal for a few PhD students in artificial intelligence to encode the rules of a game in some esoteric syntax, we know that the kind of person who BIPED could help the most is probably not going to have the same logic programming background we do. It is best to think of our current game sketching language and its associated play-trace query language as a sort of intermediate code that might be the output of a much friendlier language or graphical assistant. The idea is to get you to lay out the rules of your game with as few assertions as possible to start that feedback streaming back at you. We want assist you in making the kind of big creative leaps that show up as really novel game mechanics and we think the way to do this is to keep the game’s definition tiny, flexible, and declarative (save that C++ hacking until after you’ve seen some people have some real fun).
If you’d like to try DrillBot 6000 for yourself, and maybe even experiment with tweaking some of the rules to see what comes up, download our demo distribution (requires Java 6, don’t forget to read the instructions). Just double-click the jar and off you go! The “script.pl” file can be opened in any text editor and is loaded by the engine dynamically; there is no compilation process. Because of nasty dependencies, we don’t know how to share the analysis engine yet. For the pioneer who fears not exploring the undocumented wilderness, we can still offer a glimpse at what may be possible when “game AI” stops making your units seek the shortest path to some resource and starts helping you with your design ideas.
One Comment