John Buchanan from Carnegie Mellon university in Australia revealed this new concept that he led the research on called Game Sketching. The purpose of game sketching is to overcome a serious problem in game development, and that's the fact that in many cases there are games in development that really aren't in a playable state until at least a year into production, which John says is an "outrage", but it's sadly not that uncommon. This is a situation that can be demoralizing for a team, and it can also lead to mis-matched expectations. So when the time comes to actually play the game, things may not turn out the way the developer and publisher had intended, and the further into the development process you go, the more expensive it is to make changes to the game. In addition, John knew of at least 15 game projects that were killed by publishers before the execs even had a chance to play them. So the idea is, what if the execs could play a game sketch in as little as two weeks?
So the idea behind game sketching is a no technology, no art asset solution to getting your game up and running in a way that you can demonstrate to people how the game works. Note that this is not a prototype! Sketches are defined as rapidly executed freehand drawings that are not intended as a finished work. They usually serve to quickly explore ideas for later use and are reference for prototype and development. Prototypes, on the other hand, are one off builds of a product that encompasses the majority of the features of the final product and are built prior to final production to study manufacture issues. So you can see that getting a prototype up and running in 2 weeks can be a lot harder than getting a sketch up and running.
So the life cycle of a scketch is to first have the artists build a very simple construct of the game world. No fancy textures or lighting, Google Sketchup is a perfectly good tool, for example. Next you have sketched characters placed in the world with basic movement and the actors controlling these characers are given a script. Finally you have a single director/dungeon master that oversees the entire play of the game. Before I go into more detail, have a look at the following three shots.
So in the first shot we have an actual Harry Potter game that served as one of the case studies for this program. Here the three game characters are learning to use magic, and they have to attack this creature in order to lower the bars and proceed to the next section of the level. In the second shot we have the game sketch, which has the same three characters as simple textured polygons. In the third shot we have the various actors who are manipulating each individual game element; three for the characters, one for the creature and one to server as the director, who lowers the gates on cue, resets the world, moves objects, etc.
So the idea is that you're pretty much acting out your game, much in the way that movies use cinematics to test out shots. The actors follow a script and when, for example, the creature is killed that actor deletes it from the scene. The designer/producer/exec is in another room (not neccessarily always) piped through via audio to tell the actors to maybe make changes in the way that the scene is performed, much like a movie director. In testing this idea on actual games, several mistakes that the actors made in following the script lead the designers to include those mistakes as actual gameplay features.
An internal white paper on the technique has been published, I'll keep my eyes open for a public release. |