Gamasutra is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Gamasutra: The Art & Business of Making Gamesspacer
Formal Abstract Design Tools
View All     RSS
July 12, 2020
arrowPress Releases
July 12, 2020
Games Press
View All     RSS

If you enjoy reading this site, you might also want to check out these UBM Tech sites:


Formal Abstract Design Tools

July 16, 1999 Article Start Previous Page 2 of 7 Next

A Language Without Borders

Our industry produces a wide variety of titles across a range of platforms for equally varied audiences. Any language we develop has to acknowledge this breadth and get at the common elements beneath seemingly disparate genres and products. We need to be able to put our lessons, innovations, and mistakes into a form we can all look at, remember, and benefit from.

A design vocabulary would allow us to do just that, as we could talk about the underlying components of a game. Instead of just saying, "That was fun," or "I don't know, that wasn't much fun," we could dissect a game into its components, and attempt to understand how these parts balance and fit together. A precise vocabulary would improve our understanding of and facility with game creation.

This is something we already do naturally with many technical innovations, since they are often much easier to isolate within a product or transfer to another project. A texture mapper or motion capture system is easily encapsulated. When everyone at the office gathers around some newly released game, major technical "evaluation" is done in the first five minutes: "Wow, nice texture mapping," or "Those figures rock" or "Still don't have a sub-pixel accurate mapper? What is their problem?" or "Man, we have to steal that special effect." But when the crowd disperses, few observations have been made as to what sorts of design leaps were in evidence and, more importantly, what worked and what didn't.

Design is hard to point at directly on a screen. Because of this, its evolutionary path is often stagnant. Within a given genre, design evolution often occurs through refinement. This year's real-time strategy (RTS) games 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.

These concerns lead to the conclusion that a shared design vocabulary could be very useful. The notion of "Formal Abstract Design Tools" (or FADT, as they'll be referred to from here on) is an attempt to create a framework for such a vocabulary and a way of going about the process of building it.

Examining the phrase, we have: "formal," implying precise definition and the ability to explain it to someone else; "abstract," to emphasize the focus on underlying ideas, not specific genre constructs; "design," as in, well, we're designers; and "tools," since they'll form the common vocabulary we want to create.

"Design" and "tools" are both largely self-explanatory. However, some examples may help clarify "formal" and "abstract." For instance, claiming that "cool stuff" qualifies as a FADT violates the need for formality, since "cool" is not a precise word one can explain concretely — various people are likely to interpret it very differently. On the other hand, "player reward" is well defined and explainable, and thus works. Similarly, a "+2 Giant Slaying Sword" in an RPG is not abstract, but rather an element of one particular game. It doesn't qualify as a FADT because it isn't abstract. The general notion that a magic sword is based on — a mechanic for delivering more powerful equipment to the player — is, however, a good example of a FADT, so the idea of a "player power-up curve" might meet the definition above.

Let's Create a Design Vocabulary — What Could Possibly Go Wrong?

Before we start investigating tools in more detail and actually look at examples, some cautionary words. Abstract tools are not bricks to build a game out of. You don't build a house out of tools; you build it with tools. Games are the same way. Having a good "player power-up curve" won't make a game good. FADT are not magic ingredients you add and season to taste. You do not go into a product proposal meeting saying "this game is all about player power-up curves." As a designer, you still have to figure out what is fun, what your game is about, and what vision and goals you bring to it.

But a design vocabulary is our tool kit to pick apart games and take the parts which resonate with us to realize our own game vision, or refine how our own games work. Once you have thought out your design, you can investigate whether a given tool is used by your game already. If it is, are you using it well, or is it extraneous? If it isn't used, should it be, or is the tool not relevant for your game? Not every construction project needs a circular power saw (sadly), and every game doesn't need every tool. Using the right tools will help get the shape you want, the strength you need, and the right style.

Similarly, tools don't always work well together — sometimes they conflict. The goal isn't to always use every tool in every game. You can use an individual tool in different ways, and a given tool might just sit in a toolbox waiting to see if it is needed. You, the designer, wield the tools to make what you want — don't let them run the show.

Tools Would Be Useful — Where Do We Find Them?

So we need a design vocabulary, a set of tools underlying game design practice. There is no correct or official method to identify them. One easy way to start looking is to take a good game and describe concretely some of the things that work well. Then, from concrete examples of real game elements, we can attempt to abstract and formalize a few key aspects and maybe find ourselves a few tools.

There isn't enough space here to exhaustively analyze each tool or game — the goal here is to give an overview of the ideas behind and uses of FADT, not a complete view of everything. With that in mind, we'll start with a quick tour of some games, tools, and ideas. Since we are looking for examples of good game design, we'll start by examining Mario 64. Once we have explored some concrete aspects of the game itself, we'll step back and start looking for things to abstract and formalize that we can apply to other genres and titles.

Article Start Previous Page 2 of 7 Next

Related Jobs

Disbelief — Chicago, Illinois, United States

Senior Technical Artist
Klang Games GmbH
Klang Games GmbH — Berlin, Germany

Senior Game Designer
Infinity Ward
Infinity Ward — Woodland Hills, California, United States

UI Artist (Temporary)
HB Studios
HB Studios — Lunenburg, Nova Scotia, Canada

Senior Game Designer

Loading Comments

loader image