This Game Design Workshop is designed to jump-start the game-design process for those of you working on games for your final projects. You should leave this workshop with a clear sense of what your next steps are for research and development, even if you don't yet have a clear sense of what your end product will be.
For those of you making games, the final project for the course will not be a fully-realized game, complete with a beginning, middle, and end; well-defined game mechanics; beautifully designed visual elements; masterfully wrought text; and so on. Instead, we are aiming for four things in particular:
- a design document, which specifies the overall contours of the game, including a thorough description of any narrative, visual, action, and gameplay elements,
- a quasi-functional prototype, probably developed in Twine, which will allow a user or (aspirationally) a coder to glean a sense of how gameplay proceeds,
- a mockup of core game mechanics, also likely in Twine, which either can realize a small portion of a larger mechanic (if the mechanic sprawls or is particularly tricky to implement at scale), or might realize several different mechanics (if the mechanics are reasonably easy to implement),
- and a framing and research document, which lays out not what the game design is, but your motivations for your design choices, what aesthetic effects you hope those design choices will have, the referents for your choices, including course material, and so on.
This workshop is fairly directly adapted both from Anna Anthropy's Rise of the Videogame Zinesters and from Jentery Sayers's gaming course at UVic. It was prepared for use by students in my “Experimental Media” class at Wayne State University in Winter semester 2015.
By the end of this workshop, you should be able to:
- articulate clearly your goals in the design and development process,
- describe the major conceptual and aesthetic goals of your game,
- outline the most important game mechanics in your game, including a schematic English or pseudocode description of that one or more mechanics,
- and plan the next several steps of your game design and development process.
Design Choice #1: Objects and Agents
What are the agents and objects in your game? These can include agents that are traditional “characters,” or they might be objects (for example, an object to be looked for or found), or you might include the player directly, or they might be more abstract still (snippets of text, a virtual model of a concrete process, a representation of a system, an algorithm, and so on). You should include at least two. You should also be quite concrete and specific: not just what these objects and agents are, but what they might be able to do. This list should not be expansive, but rather extremely precise.
For the purposes of the assignment, it will be useful also to specify why you want these objects and agents to behave as they do. What sorts of experimental behaviors or activities are engaged by these agents? Actually, take this as a guiding principle for all the activities in this assignment: you should be able to articulate a motivation in terms of the course material for each of the design choices you make.
Design Choice #2: Relationships and Rules
Next, it's time to start specifying how these objects and agents might interact with each other. This is not yet a question of gameplay: you're not designing an interface, not yet. Rather, you're specifying what sorts of interactions can take place between objects and agents in gamespace. What can an agent do with an object? To another agent? How do objects interact? When can this interaction take place? When is it precluded? What results can arise? This is going to be more conceptual than anything else, since most of your games in Twine won't involve direct representations of physical interactions—although they may involve textual representations of such activities.
Design Choice #3: Interface and Mechanics
Now it's time to start thinking about how your player will interface with the gamespace you're slowly building. In Twine, this means a largely textual interface, but how you write this text is important in itself. What will your links look like? What models for interaction will you present? Will your player move around? Or say things? Perform activities? All of the above? (Compare Martens's Hack-and-Slash RPG with, say, DepressionQuest or Queers in Love.) Will you organize the game into scenes? Levels? Do you keep score? How does the game model player behavior? Quantify player labor?
Next Step #1: Iterate
Once you've gone through all three steps, go back and refine each of the decisions you made at each step. Do you need to revise your objects now that you've made a decision about interface? Is a particular behavior difficult to model? Integrate your interface into your objects and agents and rules and relationships.
Next Step #2: Implement
Once you've got a working paper model of the game, now it's time to start thinking about how you might implement it in Twine or another platform. How can you work Twine's text-and-script model to the gameplay you're working with? What requirements do you have for implementation? How does the implementation inflect your model? Remember, you're only aiming for a quasi-functional prototype, so if a particular behavior seems especially difficult to model in Twine, ask how you might describe it instead. Here is where Scott is an especially important resource to you: he may know some shortcuts, hacks, or design solutions for your implementation.