“Things Well Understood Are Explained Well”
The number one thing I learned from my years in engineering school is that “Things well understood are explained well”. Test how well you understand something by explaining it to others. Explaining them will help you understand them better. How many times have you been listening or reading something badly explained and reached the conclusion it was badly understood. Lead the way, learn to explain well to demonstrate you understand well. It will be to your benefit and to the benefit of your audience.
Sometimes designers are reluctant to explain the details of what they are thinking to others. I think they are missing an opportunity to measure how well they personally understand their design. In this document you will find many tools used everyday in our understanding of our designs at Electronic Arts around the year 2000.
First I wrote this as a document shared with other designers. Now it is a series of upcoming blog posts “Game Design toolbox”:
- Overview (this blog)
– Mental model
– State Landscape
– Stairs of Productivity
– User Actions
– User time investment
– Walk through – Narratives
– What is not in the game
– Symbolism – Granularity
– Data Structures and Algorithm
– Know your classics
– Memorable moments
– User Interface
– Kleenex testing
– Emerging Truths
– Top 10 ideas to steal
– Good and Bad practices
– Extra: How the eye and brain works
Build your own Toolbox, master your own techniques
If you want to be a designer, start assembling the tools you will use to be a great designer. Some of the tools you will find in this documents, some of the tools you will invent. Design is not black magic. It is a craft that can be learned, with techniques that can be mastered.
I suggest you try to learn the techniques used by others and teach your techniques to them. I believe that you will find through the process that you are become a better designer, better aware of your capabilities.
Project the game in well understood dimensions
I see the game design to be a complex and fuzzy shape in a space with a large number of dimensions. This makes it very difficult to understand it and therefore to explain it. A powerful tactic is to project that complex object onto a few well understood dimensions where we have a vocabulary and a set of expectations. This allows us to have a discussion, and to set objectives.
This is similar to what you can do in Architecture, where you will project a building onto 4 well defined two dimensional views (front, side, top, perspective).
A lot of the tools in this document are about doing such projections, we need to share them because they are establishing a vocabulary for game designers
It is all about what happens in the users’ head
Game design is not about graphics on the screen. Game design is about creating a very specific experience for the user, therefore it is about creating a “state” in the brain of the user.
The graphics, the programming, the sound, the user interface etc.. are only the elements the designer has to use to create that “state” in the user’s brain.
I wish all our milestones in our game development were centered around reaching such states.
A good milestone would be for example: “the user should feel that he is progressing in the game”. This can be tested on whether or not the users want to save their game when testing it.
Milestones that are defined by getting specific graphics or level done are missing the point. If the team is focused on such goals they are not going to understand why they are missing their milestone.
Because defining the solutions that will create the user experience is not a science, the designer cannot just write a design document. There is a need for many iterations to confirm that the success of the solution.
The responsibilities of the designer
The designer is responsible for describing the “states” that the game is creating in the head of the user. He is also responsible for describing the solutions that will be used in code, graphics sound etc.. to reach such states. This requires the designer to understand what can be done in coding, graphics and sound. The designer will have to describe how things are supposed to work.
Hopefully, as our industry matures, more and more of those solution are getting packaged into blocks that we only need to understand superficially. 3D engines, sound engines are moving into that category. Simulations, for strategic and action games are clearly not there yet and require a detailed understanding of the designer.
I have seen Kevin Hogan, Roxy Wolosenko and Joseph Knight develop extremely complex Excel spreadsheet to test simulation, and to communicate clearly to the programmers the details of the solution they believe is required.
Sid Meier mostly designs by writing code. He does not write design docs, he takes bits and pieces of existing engines, modify them and test what experiences come out of it. Because he is writing the prototype code himself, he is not afraid to switch solutions when they fail to generate the experience.
Will Wright used to code his games himself, but now has developed a higher level language to enable himself to craft solutions without programming in C++.
A designer needs to be able to describe his solutions in extremely detailed fashion. For some it means writing code in C++ or in Excel, for others it means very detailed flow charts.
Tools for Rapid Prototyping
As mentioned above, there is a need for many iterations in testing the solutions suggested by the designer. I believe that most of the development money we waste is lost before the design of the game reaches “completeness”.
We have to invent better tools to be able to test our solutions faster.
Ocean Quigley has developed a very effective tool using his proficiency in 3D modeling. He creates short animated visual mockups that represent his best understanding of what the game will do. Since this is a printed document, I cannot include an example here.
Ocean creates one 10 second animation every day. This feels at least 10 times faster than trying to code anything. Unfortunately, this is not very reproducible, since learning 3D Studio Max requires time and skills.
I am always searching for more example of rapid prototyping that have been shared…