Lenses for the Process

The Game Begins with an Idea §

• Inspiration comes from everywhere else. Find one key emotional experience to build your game around.

• Fall in love with the problem, not the solution. The first step to the game design problem is to recognize there is a problem.

• Pay attention to your subconscious mind. It is your friend when it comes to creativity ¹

  • Pay Attention to yourself — your thoughts, feelings and dreams.
  • Record your ideas all the time.
  • Manage the subconscious mind’s appetites judiciously. It cannot operate when it obsesses over something extensively.
  • Sleep
  • Don’t Push Too Hard. Don’t expect immediate answers from the subconscious.

• Brainstorming Tips

  • Write down the solutions that immediately pop into your brain. This frees up mental bandwidth for other ideas.
  • Sketch. Draw some pictures and express your ideas visually.
  • Use toys. Play with toys to engage with creativity visually and in a tactile way.
  • Change your perspective (i.e., your environment)
  • Immerse yourself in the problem
  • Crack jokes to loosen your mind (but make sure to reorient yourself).
  • Spare no expense. Don’t let materials get in the way of brainstorming.
  • Keep records of your ideas. That way they can easily be retrieved. Exploit the fact we have good spatial memory.
  • Don’t wait for the “one” idea, write everything down, even the stupid ideas.
  • Challenge and destroy your assumptions. Innovation can come from removing your assumptions.
  • Mix and match categories .
  • Talk to yourself or with a partner. Bounce ideas off of someone.
  • More tips here.

• Relevant lenses: Infinite Inspiration, Problem Statement

The Game Improves through Iteration §

• The Rule of the Loop The process of game design and development is necessarily iterative, or looping. The more you test and improve your design, the better your game will be.

  • The goal should be to maximize each loop and to make the loop as fast as possible. Software Engineering techniques apply.
  • Identify risks — problems within the current design. Eliminate risk as soon as possible via prototyping.

• Tips for Productive Prototyping

  • Answer a question. The prototype should be designed specifically for a design question.
  • Forget Quality. All that matters is if it can answer a question.
  • Don’t get too attached. The prototype is only temporary.
  • Prioritize prototypes that tackle higher priority problems and risks. Also consider dependence — if one prototype solves all other prototypes, do that first.
  • Parallelize prototypes productively. Do more than one at once
  • Prototypes do not have to be digital. Paper prototypes are low fidelity and enable faster iteration.
  • Prototypes do not have to be interactive
  • Pick a fast loop game engine. Use systems that are responsive to changes.
  • Build the toy first before the game. Let the game emerge from the systems (i.e., the rules)
  • Seize opportunities for more loops. When given more time, use it for more loops.

• The Loop goes as follows.

  • State the problem
  • Brainstorm some possible solutions
  • Choose a solution
  • List the risks of using that solution
  • Build prototypes to mitigate the risks
  • Test the prototypes. If they are good enough stop.
  • State new problems and repeat. Often these problems are more narrow in scope.

• The Method (by Mark Cerny) You are in preproduction until you have finished two publishable levels of the game, complete with all necessary features. Otherwise, you are still figuring out the fundamental design of the game.

  • The Plan to Cut Rule - when planning your game, make sure to build it in such a way that if 50% of the budget were removed, the game would still be shippable.
  • The 50% Rule - All core gameplay elements should be fully playable at the halfway mark in your schedule.

• Relevant lenses: Eight Filters, Risk Mitigation, The Toy, Passion

Additional Tips §

• These tips come from Adams and Dormans

• Start working on the mechanics once you know the essential experience.

• Know the three stages of development

  • Concept Stage - designers will decide on the general idea, the demographics and the player’s role. Usually there will be documented.
    • Here you create proof of concept prototypes.
    • Tip: Assume the prototypes are throwaway and you will have to redo them in the Elaboration Stage.
  • Elaboration Stage - happens when the game is funded. Here the mechanics, levels, story, art and other assets are created. The tips outline here are useful.
  • Tuning Stage - freeze the features. Do not add more and instead polish the existing features. Additionally, take out anything that doesn’t work for the game.

• Use software prototypes via game engines such as Unity or Godot. In doing so, also make the prototype easily customizable during play.

  • Spore’s prototypes might be good to investigate

• However, if the game doesn’t rely on physics, use paper prototypes instead. This is useful for certain mechanics such as economies or progression.

• Some example prototype focuses:

  • Tech demo - make sure the team can work with the technology involved in the game.
  • Game Economy — prototype the dynamics of the resources .
  • Interface and Control scheme - build a software prototype for the UI. Check for UX Design Principles.
  • Tutorials - build a good tutorial (in the late stages of the game). Test if new players can understand the game and how it should be played.

• Use a reference game: learn from their mistakes and successes. Favor games that are similar in scope as yours.

Good Games Are Created Through Playtesting §

• Playtesting is about getting people to come play the game to see if it engenders the experience for which it was designed.

• Playtesting may seem like an invitation for others to hate on your game. However, it is necessary to find the flaws of the game as soon as possible.

• It is a prototype for the game experience.

  • Because it is a prototype, aim to ask specific questions to get more out of it. Understand why you are conducting a play test to begin with.
  • Use the lenses to come up with good questions.

• Once a why for playtesting is established, determine who your target subjects will be. The choice is determined by what you would like to learn

Candidate	Pros	Cons
Developers	Always available	Too attached to the game
Friends	Highly available	May not want to hurt your feelings
Expert Gamers	Gives detailed account using technical terms	May demand more complex and difficult gameplay than what an average gamer would expect
Tissue Testers	Can offer a fresh viewpoint. Good for questions of initial impressions	Designing for only them may make the game too boring beyond its initial appeal

• Playtest as soon as possible to know whether the game is on the right track. You can playtest at any stage of the development process.
  • Playtest when it is useful but at least every week.
• Consider where the playtest session will happen.

Candidate	Pros	Cons
Workplace	Developers are right there and can observe	Playtester may feel uncomfortable. Asking the testers to bring friends may help
Playtesting lab	The lab is designed for playtesting.	Very expensive
Public venue	Low cost and you can have many testers.	Harder time to find the right playtesters fitting the demographic. Also high distraction
At playtester’s home	Can observe the game being played in its natural habitat	Playtest may be limited. Limited observation.
Online	Can playtest on many machines with different configurations. Natural for multiplayer games	Quality of playtesting may drop. May risk leaking the game.

• Know what you will look for in playtesting

  • What you know you will test is derived from the purpose of the test.
  • What you don’t know that you are looking for come with experience and being open to surprises, which implies that you have an idea of what the player’s experience.

• Consider how you will conduct the playtest.

  • If you cannot stay objective during the playtest and properly police your behavior so that playtesters can remain “pure,” you definitely should not be there. Find a way to be objective.
  • Begin with the right words. Do not nudge the player when it is not needed. Running multiple sessions lets you tune the instructions you give (just make sure to write it down). This can be the foundation of an in game tutorial.
  • Look not just at the screen but at the players and their reactions as well. Get cameras to get more eyes.
  • Gather additional game-related data (such as game events). Be mindful of the danger that relying only on quantitative design can dull the design.
  • Balance between getting the players to think aloud and letting them play.
    • Do not interrupt when the player is doing something surprising.
    • Think aloud protocol. Encourage the person to verbalize their internal thoughts. However, this may taint thought patterns.

• Consider what data you will collect.

  • Surveys - great for getting straightforward, quantifiable answers.

    • Use pictures whenever possible to refer to game elements
    • Use online surveys to save time.
    • Don’t ask a rating from 1 - 10. Give more decsriptive labels (Good, bad, excellent)
    • Don’t put too many question
    • Give the survey right after the game is played.
    • Have someone on hand to answer clarifying questions
    • Note the age and gender for demographics purposes .
    • Don’t take survey data as gospel. It may not be scientific.

  • Interviews - great for asking questions that are too complex such as sentiment.

    • Have a script of questions ready. Take notes, especially when the conversation takes an unexpected turn.
    • Interview privately whenever possible (prefer one-on-one). Group interviews come after private interviews.
    • Playtesters will avoid hurting your feelings. Give them permission to speak honestly
    • Avoid memory tests. Do not ask players to remember.
    • Don’t expect play testers to be game designer. In general, players want the game to be easier. Instead, ask for sentiment and general experience-based questions.
    • Ask more than what you need (instead of asking to enumerate one thing that stood out, ask three).
    • Consider a video closet. People will say thing on camera that they would never say face to face.
    • Set your ego aside. Resist the urge by asking clarifying questions.

• Another set of questions from Shawn Patton. Ask in order

  • What was the most frustrating moment of what you just played?
    • This lets the player vent.
  • What was your favorite moment of what you just played ?
    • This tells you the high points of the experience
  • Was there anything you wanted to do but couldn’t
    • This tells you about the player’s small desires
  • If you had a magic wand to wave and could change, add, or remove anything from the experience, what would it be?
    • This tells you about the player’s bigger desires for the game.
  • What were you doing in the experience
    • This tells you the player’s goal.
  • How would you describe the game to family and friends?
    • This tells you an overview of the player’s perception of the overall experience

• Relevant lenses: Playtesting.

Prototyping Tips §

• Taken from Gabler, Gray, Kucic

Setup: Rapid is a State of Mind §

• Embrace the possibility of failure — it encourages creative risk taking.
• Enforce short development cycles More time != More quality. One week is good for quick prototyping
• Constrain creativity to make you want it even more.
• Gather a kickass team and an objective advisor — Mindset is as important as talent.
• Develop in parallel for maximum splatter. During the middle stretch of a development cycle, Do not collaborate for the following reasons.
  • Risk mitigation - you have more prototypes
  • Friendly competition
  • Wider thematic exploration
  • Sharing understanding into a common knowledge pool.

Design: Creativity and the Myth of Brainstorming §

• Formal brainstorming has a success rate. You cannot expect Creativity to run on a schedule. But …
  • It gets you thinking about the problem.
  • It helps you critique a concrete feature of the game.
• Gather concept art and music to create an emotional target.
• Simulate in your head - Pre-prototype the prototype. Know the idea before even starting a prototype.

Development: Nobody Knows How You Made it, and Nobody Cares §

• Build the toy first. Start with the core mechanic of the game.
• If you can get away with it, fake it. It will save you time and money.
• Cut your losses and learn when to shoot your baby in the crib.
• Heavy theming will not salvage bad design.
• But overall aesthetic matters. Apply a healthy spread of art, sound, and music. Have a sense of art direction.
• Nobody cares about your great engineering. By overengineering, you can come up with generic tools that never translate into something playable.

General Gameplay: Sensual Lessons in Juicy Fun §

• Complexity is not necessary for fun. Prove the mechanic works and then make it pretty.
• Create a sense of ownership to keep them crawling back for more. The games with the greatest replay value had a sort of creation or customization aspect.
• Experimental does not mean complex. It is possible to be experimental but have intuitive UI.
• Build towards a Goal. The best goals are an innate part of the gameplay.
• Make it juicy.

Links §

• Design - processes in iterative design apply, particularly here Design Thinking

• How to Prototype a Game in Under 7 Days by Gabler, Gray, and Kucic

Footnotes §

1. The book alludes to a power nap technique by Dali who slept with a key in hand and a plate to catch the key. When the key dropped, it would make a sound to awake Dali. ↩