Schell starts off by defining the skills a game designer needs which are listed alphabetically as follows:
- Creative writing
- Public Speaking
- Sond Design
- Technical Writing
- Visual Arts
Yep. So thats it. Just those. No big deal. Except for the small inconvenience of all of them minus "brainstorming" being an entire major in and of itself.
This list isn't meant to scare. It's just meant to point out how interdisciplinary game design actually is.
However the most important skill that Schell mentions didn't even make that list. The most important skill he mentions is Listening. Schell goes on to say that it doesn't just require listening to someone's words when they speaking to you, but also listening to what someone isn't saying and being able to read between the lines to determine the message someone is actually trying or not trying, to convey through speech body language. You also need to listen to more than just other people. The different types of listening Schell describes are:
- and Game
The last two need a bit more explaining. Listening to yourself might sound simple enough, but accurate introspective analysis takes practice. Some do it through meditation and others do it by keeping a journal(or a blog). It is important because it can help you to be more creative, more empathetic, and ultimately help you solve the ever impending question of "how do I do that?".
Listening to the Game sounds stupid. It certainly felt stupid reading it. It felt stupid writing it. "What are we going to get all tree-huggin-hippy-there-is-no-spoon-zen now?" I thought to myself. The answer was/is "kinda". The analogy Schell used is listening(paying attention to) how your car runs. If the starts making a funny noise, or the engine light, comes on, or it just won't start you examine and assess the problem (or pay someone to) and then fix whatever that problem is. Whether your game needs a new fuse or it threw a rod, it's important to be able to recognize what is actually occurring during game play and not just what you see happening.
Schell presents 8 questions to test whether or not your prototype is "finished", "ready", "done", "complete", or any other term meaning "I'm not going to attempt to make this better any more (for now)".
- Artistic Impulse- This is your gut feeling or intuition in relation to your opinion of whatever it is you are working on at the time. How do I feel about this?
- Demographic- Is this right for my audience?
- Experience Design- Is the game well designed/is the player experience what was intended?
- Innovation- Is it a novel game/is it new or different enough to make it stand out/is it a clone?
- Business-Will it sell?
- Engineering- Is it technologically possible to create?
- Social/Community- Does the game meet its intended social requirements?
- Play Testing- Do play testers like it?
If at any time during the prototyping process you ask one of these questions and the answer is either negative or just not the answer you wanted, stop what you are doing and make a change to your prototype to get a positive answer, the answer you do want, or at least closer to the answer you want.
Note: If what you were doing at the time you asked yourself the question was attempting to answer that question or a different question finish what you are doing then move on to the next question if necessary.
These filters should be used after every iteration of a prototype until a prototype passes through all of them unscathed. It's important to understand that they aren't intended to create more work for yourself, but to make sure you are actually working towards creating the Experience you want players to have. Schell points out that point explicitly when he defines a Game Designer. Designing the actual game, whether digital or physical, is inherently secondary to what a Game Designer is actually supposed to do: Design and Experience. To that end the game itself could even be considered irrelevant. Just a means to an end. If a player experiences what I, as a game designer, intended them to experience then I win. Now the only downfall of that is that we as Game Designers can only directly design the game, not the experience. Which is why we still need to focus on the game itself in tandem with the experience, because without knowing how to change, fix, or design a game, the only way we could ever hope to design an experience is sheer unadulterated luck.
Which brings us to:
First of all, if whatever it is you do or did, if at any point you able to look back on it and say "I learned something", then that event, period of time, or action automatically becomes NOT a waste of time.
However, there should be a question that every iteration of a prototype should be trying to answer. I don't meant questions like "why are we here?" or "what is the meaning of life?". These questions are usually quite specific and should be answered one at time i.e. "what if we use dice instead of a spinner?", "will it still be fun if the theme is different?", "what happens if I add a time constraint?".
If at anytime during the creation of a prototype you cannot answer the question "What question is my prototype trying to answer?" with a coherent one-sentence question then you MUST STOP WHAT YOU ARE DOING because you are in fact currently WASTING TIME. A prototype should only be built if it is trying to answer a question, other wise what you make isn't really a prototype. It's just a thing.
After reading this out of Schell's book I immediately realized retrospectively that the last prototype I made had been a waste of time. However, because I realized that it was a waste of time, I now understand more what that looks like and how to identify it. So it wasn't really.
A waste of time.
...That it wasn't really wasted time