Поделиться через

Back on the Blog

  • Статья

River’s End is mostly complete. It’s not much of a game, but it is a very relaxing experience. It just needs some polish, a few new graphics systems, and a little more content and it’ll be ready to go. However, I don’t know yet how or if I can distribute it, so understandably, my enthusiasm for the project has waned somewhat.

To avoid the issue for my next project, my focus will be on game design. And I’d like to be inclusive though my blog or through the XNA.com forums on how I reach my design decisions – both technical and creative.

River’s End was a superb way for me to familiarize myself with the shortcomings of a tech-driven design. As I began to ramp up to my next project, I was very near the same mistake, but I was fortunate enough to have colleagues and friends who could comment on early problems and identify another possible false start.

So I began to study the subject of general game design. Like any good research topic, trying to assimilate the greater body of game studies is truly epic amounts of work. One of the major problems is a seeming lack of clear goals, or at least, shared goals on the part of the leading academics. Game Theory seems to me a strictly academic pursuit, but it contains nuggets of wisdom that transcend its specific focus. Game Studies appear to focus on the impact or rationalization of games.

On the other side of the Game Design coin is the practitioner’s approach. This is the domain of designers like Noah Falstein and Marc LeBlanc. There are the contributors to books like Game Design Perspectives and Game Design Anthology. Some of these are unyielding rules about what makes a game enjoyable. One extreme example of these approaches is the 400 Project. Others are general guidelines to encourage new thinking about game design.

There’s more too – far more. There are almost as many ways of talking about game design as there are game designers.

I’ve thought critically about aspects of the problem, and like so many sideliners before me, I have come up with my own addition to this theoretical stew, which I will call a Formal Game Design Model for lack of a more discrete term. My fundamental goal is to make something that makes my games more fun. I refined the difficult tasks to three goals for a design model. My goals for a model are to:

Refine game designs by identifying, isolating, and surfacing all specific aspects of a game’s end-to-end experience.

Evaluate game designs by understanding the interplay of game systems and their impact on the overall experience.

Inspire new features or game elements to establish goals earlier in the process.

The model I developed is called “A Domain Model for Game Design” or Domain Model for short. I have identified 8 domains that are common to all computer and video games, and even many board and card games. Each domain is describes an aspect of a game that ultimately influences a player’s enjoyment of the game. The essential quality though is that the model’s static component is the domains themselves. The dynamic part is the interactions between domains, which, I’m finding are highly regular.

There are lots of ways to use the model, but let me give a quick example. The Domain Model includes a domain called “Response” which deals with the display of information to the player that informs their choices. The Response domain interacts strongly with the “Presentation” domain, which covers aesthetics and art design for a game. Here we can begin to identify areas that are contentious in the design of your game. Following this example, you might identify aspects of the in-game artwork that makes the UI in the response domain untenable.

This probably sounds like common sense, and much of it is. The formalism may seem unnecessary and that it may stifle creativity. However, I don’t see the model as a template or specification mechanism for game design. I see it as a tool for doing the three things I identified above.

Now, those of you who have read up on this subject may have already seen a striking similarity between this model and the MDA approach by Hunicke, LeBlanc, and Zubek. I developed the groundwork and the core principles of my model before ever reading about MDA, and I was both surprised and pleased that my system mirrored so many of ideas presented in that paper. Of particular interest are the interactions between Mechanics, Dynamics, and Aesthetics as the essential part of the iterative processes described by the system. However, my focus is on more discrete “parts” of a game, and an idea of strong and weak interactions between domains. Domain Model’s goals are similar, but I’ve chosen a slightly different attack vector.

I can’t presume to have the authoritative background any of the authors of MDA have, and as such, I would never say that it’s right for everyone. I plan to offer it “as-is”, another tool for a designer’s toolkit, and nothing more. I’ll be vetting this model with my next game project, and I plan to provide case studies that show how several different games can be evaluated with the model. I’m a technology worker, not a professional designer with decades of experience, so everything I write must be approached as such.

In the coming months I plan to talk more about the model as I refine the concepts. I’d like to present it as a paper initially. This is largely something I’m working on for my own hobby game projects, but in the off chance that anybody may find this useful, I’d like it to be generally available. Perhaps someone out there struggling with a game that just isn’t fun might find ways to improve their title using the little bit of structure I’ll provide in the Domain Model.

Comments