Introduction
After analyzing other games/mediums, holding in-depth conversations on the problem, and brainstorming, you should have identified a few top ideas that might work out. Now it's time to expand these ideas into designs. As stated earlier, ideas can't be part of the game until turned into mechanics, systems or rules.
How can we know which idea is best before understanding how each one will be integrated into the game? Instinct? Because one sounds cooler?
I've seen amazing ideas go to prototype that had major holes in how they interacted with other systems. These resulting prototypes can lead to weeks of wasted effort only to create bigger issues than they resolved. This step-designing the solution is what separates game design from ideation. When you begin the process of designing solutions you should follow three steps.
Ask yourself, “What problem am I trying
to solve?"
Never forget that this is the number-one question to keep in mind when designing. It's surprisingly easy to lose sight of this goal and the other goals you've built.
Understand the complexity of what you're thinking of adding to the game.
Is this idea a rule, mechanic, or system and how will it interactwith the other rules mechanics, and systems that already exist in the game?
- New rules can end up clashing with existing rules or altering how mechanics and systems function.
- New mechanics need to fit into existing systems and loops without creating holes. Make sure each connection makes sense, especially if a new mechanic is replacing an old mechanic.
- New systems can do the most damage and generally require the most development time typically because they require a host of additional rules and mechanics to be added. All of these added rules and mechanics must work in harmony while bridging to existing systems in the game.
Again, the goal is to understand the idea's complexity and to identify the primary systems and mechanics the new design will interact with. Don't worry yet about all the secondary interactions that aren't related to the problem or your goals. It can take a while to fully design a feature and fill all the holes. We don't want to go too far until we've proven the main components of the design are successful via prototyping and testing.
Design the gameplay experience in a
quick, easily presentable format.
This is where we finally plan how fantasy, mechanics, rules, systems, challenge and the player's goal all come together within our gameplay loops. Each designer will have their own approach in how to bring all of these together depending on their priorities and the focus of the game.
Every design must start somewhere. There is no wrong approach and the more we allow every designer to embrace their own perspective, the more success we'll see in the designs.
- Do you prefer to start with a focus on the player experience?
- Do you start with the emotions you want to push?
- How does this new design fit into the overall game
structure or loops?
- What does it add to the long-term player goals?
- What challenges will the player use this design to overcome?
Now it's time to share them with the team
and get feedback.
At the end of this process you should have a few basic designs that showcase how the top ideas solve the problem, achieve the goals, and successfully connect to the rest of the experience. It's impossible to narrow in on an optimal solution without feedback. Gathering feedback generally works best in quick one-on-one discussions. After this, you'll pick the best option to prototype. There are many criteria that can be used to determine what "best" means for you.
The following are a few things to consider:
A response from a product designer.
Richard Carrillo's book 'The Role of a Great Game Designer' is part of a handbook series delving into the definitions and skills of game design. In chapter 8 Carrillo discusses the steps which help the designer go from ideation to game design. He explores the questions we should ask ourselves before jumping into the time-consuming process of prototyping. Firstly, he reiterates the need for keeping the goal in mind. By asking ourselves "What problem am I trying to solve?", we can optimize our productivity and clarity. Secondly, designers must understand what is involved in adding this idea and how it will interact with other parts of the game. Finally, plan how we bring our ideas together to create the experience.
I want to explore how these two disciplines overlap, how they differ, but also how one could inform the other in how to design a solution. To begin with, we can draw some similarities between the product design and game design world. I believe from Carrillo's writing I can make the statement that both game and interaction design have the same overarching goal, to make great user experiences. Both designers should keep in mind the identified problem statement or hypothesis at hand when designing
When adding a new page or feature to a website, designers should be thinking about how this will seamlessly merge with the current user journey. Just as a game designer might question if a new mechanic fits in the existing system. However, if we think about responsive design this is where the two areas show their differences. Product designers have a heuristic approach of making responsive web pages. A game designer, especially for consoles, will be designing for a couple consoles in mind. The range of devices product designers have to consider is at a much larger scale. We might ask ourselves, how will this new design idea look on most common mobiles, tablets or laptops?
When it comes to game designers, it is common for them to work more closely with code, to ensure the mechanics and physics of the core idea work in game. In the practice of interaction design it can be easy to forget, when creating prototypes, the technological limitations. As a product designer, I would like to ensure that I'm aware of the constraints of HTML, CSS and Javascript and how I can effectively communicate my design ideas to developers.