Ain’t that the truth. Doug Church in “Formal Abstract Design Tools” addresses the need for a common language among game designers, since “… design evolution lags far behind the evolution of overall game technology” (367). The more I dip past game writing into game design, the more I appreciate breakdowns like Church’s. His work was later added to, preliminarily discussed in “Game Design Methods: A 2003 Survey.” On the same note, though, game design patterns and the 400 Rules project can also be layered over FADT.
Since this paper was so preliminary, it only focused on three FADTs:
Intention: Making an implementable plan of one’s own creation in response to the current situation in the game world and one’s understanding of the game play options.
Perceivable Consequence: A clear reaction from the game world to the action of the player.
Story: The narrative thread, whether designer-driven or player-driven, that binds events together and drives the player forward toward completion of the game.
The only one I have an issue with is his definition of story, since he doesn’t take into consideration the difference between narrative and story, which can be further broken down by research like Henry Jenkins’ concepts of micronarratives.
A designer should be concerned with “… knowledge of how the world works, how they can move and interact with it, and what obstacles they must overcome” (371). This really fits into Jenkins’ view of game designers as game architects. We’re designing this space, this experience.
Church adds: “I believe the challenge and promise of computer game design is that our most important tools are the ones that involve and empower players to make their own decisions” (379). That, and that you’re aware of not upsetting the player by setting up negative feedback for their decisions in a way that doesn’t make sense. For example, Church talks about Mario, and points out “if something exists in the world, you can use it” (372). I know how frustrating it is for me in a role-playing game when there are buildings with doors you can’t open and no explanation as to why. You’re suddenly very aware that the buildings are probably just exterior models and the game loses life, which is especially a problem for the RPG genre.
Speaking of RPG design, Church points out: “This year’s real-time strategy (RTS) clearly built on last year’s RTS games. And that will continue, because design vocabulary today is essentially specific to individual games or genres. You can talk about balancing each race’s unit costs, or unit count versus power trade-offs. But we would be hard pressed to show many examples of how innovations in RTS games have helped role-playing games (RPGs) get better. In fact, we might have a hard time describing what could be shared” (368).
I’ve run into this very problem right now working on a design for a game based on the Doig First Nation cultural archives. On the one side, I have a request for resource management as a core mechanic (in a way that screams map RTS), and on the other, rich stories and characters they want available as the player’s role. There’s not much in the area of crossing these genres, but by using FADT as opposed to a structure that’s more specific to genre, I can at least construct an understanding of how RTS and RPG genres relate and what mechanics I can keep and cut. In a way, it may make a new kind of genre in the way the game is played, determined entirely by the mechanics that emerge from Indigenous content in game design. More on this later as I get into further design stages.
