Domain Model for Game Design Part 1

I’m treating the Domain Model for Game Design like an unproven scientific theory. The Academy of Arts and Sciences states that a theory must have two properties:

1. It must be an explanation of a feature supported by experimentation

2. It must be able to make predictions

In this case, my “experiments” are the case studies I’m putting together and the new game I am developing. To support my model, these case studies should result in prescriptive insight into how these games could be improved, what features would be popular, and what features could be cut. Of course, most of these things could be determined intuitively once a game is released. The critical reaction to full game becomes the control case for the case study. The “experimental results” are the issues rapidly identified by domain interactions, which are identifiable during development.

I was originally going to introduce the domain model by talking about the benefits, but I’m not really trying to justify the model yet. It’s too raw – I’d rather be generating discussion and criticism than trying to defend an indefensible position.

Instead I’m going to present the 9 (or 8, depending on how you see it) domains that I’ve identified. In this post, I won’t be going into the justifications for them – there’s plenty of time for that. Instead, I’ll present the summarized domains within their two categories.

Originally, there were 5 domains. At this time the domain model encompasses 9 discrete domains. Each one has been scoped to make it’s interactions with other domains as useful as possible. The glue between the domains (which I call weak and strong interactions) are were the predictive qualities of the model come into play.

Domains are divided into two categories – Direct domains and Sympathetic domains. The Direct domains are easiest to explain – these are the elements of the game over which a developer has direct control. The Sympathetic domains are those which anticipate or attempt to understand a player’s experiences with the game.

<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p></o:p>

The Domains

Direct Domains

1. Response

a. This domain covers the display of game state, UI, and instantaneous reactions to player inputs.

2. Presentation

a. This domain includes aesthetic elements such as artwork, narrative, audio, and stylistic elements.

3. Achievement

a. This domain deals with win states, scores, progression, and all kinds of rewards that reinforce the rest of the game.

4. Simulation

a. This domain describes the game’s interactions with its own internal state. It covers AI, game world simulation, and other updates that are not directly tied to player inputs.

5. External

a. This domain covers everything that lives outside of the game. This could include packaging, manuals, web portals, advertising, distribution, and hype.

Mixed Domains

6. Physical

a. This domain covers the control surfaces, displays, peripherals, and general ergonomics of gameplay. This domain is considered mixed, as it is the actual interface between the developer’s game and the player’s body.

Sympathetic Domains

7. Skill

a. This domain deals with the rapidly changing skills that a player develops while playing a game. This domain influences how a player learns and hones short term (<30 sec) reactions to in-game situations at a reactive or instinctual level.

8. Management

a. This domain covers the expectation of player strategy. It includes conscious player contributions such as resource management, approach, and goal setting.

9. Immersion

a. This domain deals with a player’s emotional connection and concentration while playing a game. It is the domain used to manipulate the player into internalizing mechanics presented in other domains.

That’s still a somewhat raw list, and I expect it to change as I run more case studies. These domains do not imply any sort of hierarchy. There’s no strict structure that indicates that any given domain is deferential to another domain. That is purely something that would be scoped by a particular game.

In my next post, I’ll talk about the interaction model for the domains and start to explore the prescriptive properties of understanding weak and strong interactions. I’ll follow with some uses for the domain model, and then I’ll get to the meat of this topic: the case studies.