Domain Model for Game Design Part 2


Yesterday I listed the domains for the design model; today I'll list what they're used for.  In later updates I'll post more specifics on these uses, but for now, I’d just like to scope things.  This list is not final, and there are probably additions as I discover things with the case studies.


 


What the domain model does:


·         Identify weak and strong interactions between domains for a particular game.  These interaction values act as a risk assessment metric and general iteration focus.


·         Identify a set of standard interchangeable standard domains for games. This will help speed up the design process by creating standard placeholders that are easily understood.


·         Identify low-level constraints on domains due to fiscal, time, and resource constraints.


·         Identify logical divisions of human resources, design efforts, and specification.  Combined with the interactions and constraints, interaction between members of large teams can be safely and efficiently structured.


·         It is a descriptive terms in a design document, to clarify concepts while they are still on paper, or being discussed at meetings.


·         They are useful as categories for comparing two or more games.  This, in turn, can be used to evaluate the familiarity or differentiation offered by a title in development.


·         They can be used for structuring pitch sheets or short specs.  They provide a way to instantly describe the efficacy/feasibility of a design by matching with criteria from known other games.


·         They are a framework for designers who have basic game concepts, but need to flesh it out to discover any flaws early in the process. 


What it doesn’t do:


·         Is not appropriate for structuring large design docs at this time.  More research needs to go into this subject.  The reason is, a design doc will tend to discuss the flow of a game, and lay out the individual elements as they come up.  This is very useful when designing a game, as it simplifies the design process by utilizing a chronology (timeline) or hierarchy (flowcharts).


·         Does not provide rules, mechanics, dials, or other “automatic” mechanisms to tune games in progress.


 

Skip to main content