Kredati
{
Game Design Workshop

Overview

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:

This last will be different from your cover letter, but evidently it will cover the same amount of material. Clearly, the balance of how thoroughly executed and realized each of the above documents are will depend on what your priorities are, and just how much Twine you feel you can fight with.

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.

Outcomes

By the end of this workshop, you should be able to:

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.