Again, I wish there was a solid answer here.
Back in Rules of Play, the book begins by defining the term game designer;
A game designer is a particular kind of designer, much like a graphic designer, industrial designer, or architect. A game designer is not necessarily a programmer, visual designer, or project manager, although sometimes he or she can also play these roles in the creation of a game.
The focus of the game designer is designing gameplay, conceiving and designer rules and structures that result in an experience for players.
Before a game is developed, it must to designed. The book emphasises iterative design, which is a design process. A game cannot be designed all at once, but is a drawn out process with a beginning and end.
Iterative design is a play-based design process. Emphasising playtesting and prototyping, iterative design is a method in which design decisions are made based on the experience of playing a game while it is in development. In an iterative methodology, a rough version of the game is rapidly prototyped as early in the design process as possible. This prototype has none of the aesthetic trappings of the final game, but begins to define its fundamental rules and core mechanics. This prototype is played, evaluated, adjusted, and played again, allowing the designer to base decisions om the successive iterations of the game. Iterative design is a cyclic process that alternates between prototyping, playtesting, evaluation and refinement.
I found this horrible little graphic demonstrating the Iterative Design process on Gamasutra, it’s not much to look at but it gets the point across. It’s something I want to constantly refer to, as I’ve previously attempted to evade making changes to my designs.
Jesse Schell says: A Game Begins With An Idea
1. Think of an idea
2. Try it out
3. Keep changing it and testing it until it seems good enough
In Jesse Schell’s book The Art Of Game Design, he uses cards which he calls “lenses” to convince the designer to look at game designer from different perspectives. In terms of conceptualising a design through an idea, he turns to the lens of infinite inspiration.
To you use this lens, stop looking at your game, and stop looking at games like it. Instead, look everywhere else.
Ask yourself these questions:
● What is an experience I have had in my life that I would want to share with others?
● In what small way can I capture the essence of that experience and put it into my game?
I’ve identified my “experience” as a desire to have an experience which I have not had yet! So, now I’m asking the question “how can I capture the essence?” Schell goes on to explain that every game is a solution to a problem. The problem could be a broad question, similar to ones I’ve already been asking myself. Something like:
“how can I make an fun, contemporary side-scrolling platformer?”
or more specific, like
“how can I make a videogame which represents Hanami?”
For the specialist project, I relied pretty heavily on the The Computer Game Design Course. The previous two books talk alot about designer, but this last book makes the transition from design to development. It’s almost a step-by-step guide for someone completely new to the industry, providing advice and frameworks for the entire process from conception to release. Once the game proposal is in place, it suggests that the following items are swiftly taken care of:
1. Asset Artwork
4. Level Design
5. Game Mechanics
The result of a realisation of these things makes up the basis of the Game Design Document, which “expresses vision for the game, describes its contents and presents a plan for implementation” (Gamasutra). These considerations should be made before the game goes into development, so for me the next step is to make a start on this, to make sure I know what the game is, how it works, what it’s going to look like and how it’s going to sound through a process of experimentation.