These include:

1. Not Structuring Time For Game Playing
2. Placing Too Much Importance On Paper Designs
3. Peer Review Not Taken Seriously
4. Decision-Maker Picked For His Producer Skills
5. Not Taking Advantage Of Placeholders
6. Allowing The Story To Control The Game Design
7. Not Giving Designers Enough Tools
8. Entering Production Without Something Fun
9. Not Keeping Design Documentation Up-To-Date
10. Not Making Outside Playtests Part Of The Process

Even though this is only one opinion and we may not agree with all of these points, the summary is very interesting.  Especially time allocation for gameplay, or more precisely idea research, and point 9 are worth to examine for.

First point seems to attribute the lack of systematizing research of ideas outside your own solutions at the industry. It is not acknowledged as an important part of the designers work to know what is out there. This knowledge comes with the designer, not as a part of the job. The conventions that are out there to utilize and good partial design solutions in other products are always worth to check for. This enables saving time of prototyping and prevents inventing the wheel all over again. The industry is changing fast and our products are heavily experiential. We all know what it feels like to keep the pace with this ever growing and expanding game space. It is almost impossible. We were once the enthusiastics reading all the webpages and playing for hours per day. Then we got a day job.

The documentation part is inherently complex. It is our target as well to try to find out what works and why it doesn’t if documentation is overlooked. At least from the point of view of game ideas and iterative process of the idea creation. For example, if the documentation tool is too slow, too uncomfortable to access and doesn’t support the nature of the design process, is it really wonder that documentation is behind? Our natural approaches are sometimes less time consuming in some parts, even though they may be not that effective or accurate in some other parts of the process. It is important that the tool is supporting the nature of the work and not feeling as a burden.

Another interesting piece on formal game design is the paper “An experiment in Automatic Game Design” by Togelius and Schmidhuber (find the paper in here).  The authors created a program that would automatically create new games based on an underlying schema (or “meta-rules” or “axioms” as the authors call it).  To evaluate the games, they had a genetic algorithm with a fitness function based on the idea of using learnability as a predictor of fun. Therefore games that are easy to learn but hard to master would get high fitness values with the algorithm, thus indicating a fun game.

The paper is very interesting and the approach novel and fun. However, even though this is admittedly just an initial experiment, there are two problems that really highlight the difficulty of formalising game design. Firstly, measuring (and formalising) player experiences. Learnability may be a necessary condition for fun, but it really is not sufficient. Like Salen and Zimmerman point out, game design is a second-order design problem where the designer only indirectly affects the players’ experience. Formalising the mechanisms that turn rules into great experiences can be really hard.

Secondly, attempts at formally defining game design lead easily into really complex structures. In this case, the problem was sidestepped by providing the base schema (i.e. “meta-rules” or “axioms”) for the design – the changes in the design would only occur within the parameters of the schema. However, this leads to question (as someone did in the authors blog) whether the experiment is about game design at all. I would be inclined to say that simple schema permutations do not constitute as game design. But then again, maybe its just a question of the complexity of the schema.