In The Process of Game Creation & the Game Design Document I described how a design document provided a description of a game that could be passed to a technical development team and turned into an actual game.
Once the game has been completed, it becomes possible to tell the story of the game in a post hoc fashion, as a walkthrough of the game itself.
Game walkthroughs are often provided as ‘hint’ based miniwebsites or ‘official’ game ‘strategy guides’ that can help you to work your way through a game. Of course, some people might see this use of walkthroughs as ‘cheating’, arguing that to appreciate a game you need to play it – and work through the puzzles set within it – by yourself. But when the games are sold as entertainment, not providing a hint every now and again may prevent the player passing through the game, and may upset their enjoyment of it.
Some game producers provide official online walkthroughs of the game, that can act like a “tour itinerary”, almost, for a journey through a game. Sometimes these are also published as physical books that act as merchandise around the game franchise – for example, The Legend of Zelda: The Wind Waker – Official Strategy Guide. Indeed, so popular are game guides that online bookstores such as Amazon even have genres dedicated to them – Any Category > Books > Computers & Internet > PC & Video Games > Strategy Guides!
Looking at these walkthroughs can often provide inspiration for working out how to describe particular actions, events or sequences in a game design document, “closing the loop’ or “round tripping” the description, from design document, to game implementation, to game walkthrough and back to a (designlike) description of the game.
For example, walkthroughs of some of the Zelda game franchise can be found on the Zedla website: walkthough of “Ocarina of Time” (text version), or the walkthough of “Ocarina of Time” (flash version, with screenshots and interactive maps).
Fans of a game may also produce walkthroughs that in effect become manuals for how to complete a game. For example, a submission by the user WishingTikal on the IGN game FAQs site prvides a comprehensive walkthrough for the The Legend of Zelda: Twilight Princess game. This level of detail would not be amiss in a technical design document where the controls for each game mechanic are described in such a way that they can be implemented directly.
If you are familiar with any games, see if you can find a walkthrough for it, for example by serching for the name of the game alongside the word “walkthrough”. To what extent do you think the walkthrough could act as a design document for the game? For example, see if you can rearrange the walkthrough so that it resembles the structure of a design document. What is missing from the walkthrough that is required in a design document?
Not being a gamer (?!), the first time I came across mention of speedrunning was in an article in the Spetember 2007 edition of Edge magazine (number 179), Speed Freaks, which describes it thus:
There are two distinct camps in speedrunning. The first, ‘regular’ speedrunning, is dedicated to running a game as quickly as possible using whatever tricks and glitches can be exploited within its engine. There are a multitude of variations on this theme, from completing a game with all items and secrets found to completing it with as few items as possible.
The second, and the most recent, is tool-assisted speedrunning, or TAS. Typically dedicated to older games that can be emulated, TAS runners aim to complete a game as quickly as possible using frame-stop techniques and often otherwise inaccessible bugs. On one team, runners dedicated to cracking a game from the inside using whatever tools it gives them; on the other, runners dedicated to breaking it from above by whatever means necessary. [“Speed Freaks”, EDGE magazine #179, September, 2007]
Read the “Speed Freaks” article. What different techniques are used to complete a speedrun as quickly as possible? To what extent do you think these techniques might be seen as ‘cheating’?
Speedruns are documented as videos, and particularly when filmed from a third person point of view, may be considered to be a particular form of machinima (which I’ll cover at more length in a future post).
Speedruns are often recorded using screen recording software, although some games are released with demo recorders in them. Typically, these demo recorders make a recording of the on-screen action using a screen recorder built in to the game.
However, the Halo 3 game which was released in 2007 included a special “Saved Films’ feature which actually records game data rather than ‘screen images’, thus allowing the game to be replayed ‘by machine’ – and hence viewed, and possibly recorded, from several different viewpoints.
Read the official Saved Films: How to Use Them document. What are the claimed advantages of using the “Saved Films” technique? In what ways does the Saved Film idea resemble the use of MIDI for recording music?
If you manage to make a recording of a demo or speedrun of one of your own games, then please post a link back here. (A quick web search for something like game screen recorder should turn up some candidate tools. I generally use Jing to make screen recordings, though I did notice a