next »

[rndmcnlly]

I just created this game prototyping tool called BIPED that aims to give you equal support for quickly testing your ideas via play tests with human and machines(!).  Before I totally lose you, check out a simple Motherload-like game I created in it:

video demo:



The point of BIPED is not to make full, fancy games -- it is to quickly sketch your idea using the same kind of thingies you might use in a board game (shiny tokens sitting on board spaces connected to form a simple map).  If it only gives you tokens and spaces why should you care?  Well, the two-leggedness of BIPED comes from its ability to turn your game sketch definition (usually a small program in Prolog syntax) into (1) a redistributable game prototype and (2) a formal rule system that, when you use it in my analysis engine, can give you example play traces that meet certain conditions (ex: "victory happens a t=12, no health potions are ever used, and the player character always picks up a treasure if he is capable of doing so").

In my little example game pictured above (which you can actually download from here: http://adamsmith.as/games/db6k -- requires java 6, click the jar), you can easily imagine how traditional play testing might work.  Either you the designer-developer or one of your friends tries playing the game for a few minutes, and you observe some things happening in the game world, find something to revise, edit, test again...  One thing that is probably pretty foreign to you is any concept of "machine play testing".  I'm not claiming to have some program that can play any game, but I do have one that can play short stretches of any game you program that I can translate into its language.  To carry out machine play testing, you launch my analysis engine on your game sketch, along with any particular things you are interested in seeing in a play trace, let it compute, and out will pop a log of game events and game state that you can inspect to figure out where your game's mechanics went wrong (or went right!).

Here's an example of a raw, unedited trace I got from DrillBot 6000, using no special conditions, just looking for the game world running for 14 or so steps:

happens(mine(a1),0).
happens(drain,1).
happens(drain,2).
happens(trade,3).
happens(mine(a2),4).
happens(mine(a0),5).
happens(down_to(a),6).
happens(mine(space_canary_corpse),7).
happens(mine(c0),8).
happens(down_to(c),9).
happens(down_to(f),10).
happens(up_to(c),11).
happens(up_to(a),12).
happens(down_to(c),13).
happens(down_to(f),14).


The real power of machine play testing is when you mix it up with human play testing.  If your friend claims to have found some bug where he got more than full health, but he forgot how he did it, you can ask the analysis engine for an abstract play trace where health goes above full for some time step.  If there is such a trace, the system will find it (though it may take a long time depending on how any steps you let it take).  If there isn't a trace, then you know your friend is bullshitting you (or it was a runtime glitch outside of the mechanics) because the system has actually formally proven that no such trace exists at that point.  Going the other way, you can start machine play testing even before you have actually hooked up input or graphics (which might be good for prototyping resource systems or dynamic story systems where the graphics don't matter for the mechanics).  You might find a particular speed-run trace via machine play testing that your early play testers (again, yourself and friends) might not be hardcore enough to uncover.

Hopefully I've piqued your interest -- the db6k link I posted above can actually be edited by you (take a look at script.pl in the zip) to realized and play test new games, no need to recompile the jar.  The analysis engine is quite a bit more difficult to get running (it has a lot of dependencies that are really only sane to work with in Linux), so I didn't include it in the zip.  I'd like to say I'm giving you everything you need, but I have zero documentation for how to use the language.  If you've ever seen Prolog before or are really good at learning new languages you might be able to guess how it works.  I invite you all to check out DrillBot 6000 on your own computer, browse the game sketch definition (script.pl) and hack up a minimal-but-interesting change.

I'd love to hear what you think of it!

[Mipe]

I wouldn't agree with the health bug analogy. It can be a bug, a typo in the code, that is not apparent in the ... map thingy. Before you call your friend on bullshit, you may want to remember that there may be errors within the coding, not the idea itself.

The whole thing looks interesting, I should peek at it more closely sometime...!

[progrium]

[rndmcnlly]

@Mipey Excellent observation.  I suppose my health example is the sort of thing that is more of a coding bug than a game-design bug.

In my short experience, the most useful part of machine play testing is for a kind of regression testing.  I setup a query for a play trace that results in, say, victory at t=10, and then as I tweak rules I can just re-run the query to make sure I haven't broken anything serious that would keep people from progressing through the game.

[agj]

Sounds intriguing. What game genres do you foresee this being useful for? From the little I understand, I can only picture turn-based strategy types.

[Don Andy]

Sounds intriguing. What game genres do you foresee this being useful for? From the little I understand, I can only picture turn-based strategy types.

I've read this book on game design recently and apparently even FPS games are often prototyped as board games, although less to prototype the gameplay, obviously.

[rndmcnlly]

Was "Game Design Workshop" the book?  I think that one even has a picture of a miniature sitting on a hex grid with index-card walls as an example of a FPS prototype.  For those who don't have this excellent book you can browse parts of it online with google books: http://books.google.com/books?id=OjIYWtqWxtAC&printsec=frontcover&dq=game+design+workshop&ei=5LbwSdzAMaHSkATXncHyCQ.  Chapter 7 is all about the prototyping you can do before even touching a computer.

In response to agj, if you assume that a "genre" is basically a bag of constraints on the core mechanic of a game (and a suggestion for its back story), then there will certainly be some genres that are easier to address with board-game-like prototyping tools than others.  However, as the Fullerton book I linked above suggests, almost any game has a meaningful prototype at the physical level (if you are creative enough).  Because there is always some distance from your paper-level prototype and the "real game", its actually easier to explore games that straddle traditional genres or even forge new genres when you are doing it on paper (because you haven't already committed to, say, a tile-grid, or some engine where the character models are a fixed in the I'm-holding-a-big-ass-gun-at-all-times shape).

If you have friends who are game devs (or at least are interested in dabbling in developing some day), its really fun to find random objects you have around the room and just invent and play games one after another.  You can play five completely original games in the time it takes you to remember how to load a texture in opengl.  Better yet, if you get your friend excited enough, you can trick them into implementing your ideas for you (the paper prototype being a great way to communicate the core mechanics of your game idea to someone else).  You can totally put it on your resume also to paint a picture of yourself as a well-rounded designer-programmer instead of a code monkey.