In the dark times of early 2020 I spent a time taking notes on videos from the GDC YouTube channel - a fantastic collection of talks about the design and development of games.
The talks that were the source of anything interesting in this post were:
Many of the principles and lessons in these talks on game development are general enough to apply to any creative process - they are fundamental to designing engaging products for human beings.
If you want to do anything for a lifetime, you need a process that doesn’t rub at you. You are going to have hard times - managing these in your own individual way is the only way to get through to the other side.
Some developers enjoy working on multiple projects at the same time (something I also enjoy). You should be aware of your preference for how you work best.
Takeaway - be clear and intentional about how you work best, don’t sacrifice it, and hold onto it during the bad times.
Game developers design for emotional experience. This design is driven by the specific kind of emotional response they are trying to create.
Emotional responses make gameplay relevant to players. Not only positive responses - negative responses have their place in good game design as well.
This design process can also work backwards - starting with the emotional response that the designer wants to achieve and working backward to the game features that will achieve it.
Takeaways - be specific about the emotional responses you want to create. Improve your designs by reversing them from effect backward to cause.
Gameplay occurs in the human brain. Game design must respect the irrational biases that effect our thinking.
One example is our asymmetric reaction to reward and punishment. Players have no problem with receiving rewards (even if they don’t deserve them!) but will react badly to punishment. Players want to feel powerful and have their influence be visible, and to feel smart.
It’s important to understand human perception. Aesthetics matter - we like to look at things in certain ways.
We like patterns - the brain loves to store and retrieve patterns. Fractals are recursive and repetitive patterns that can be used as lenses for a wide variety of design techniques.
The importance of story and narratives to people can’t be understated. Narratives come in three forms - explicit, implicit and emerging. Implicit story telling avoids using words. Emerging narratives develop from player choice - helping engagement.
Takeaways - design must take into account the irrational biases, perception, pleasure in pattern recognition and stories that we all share.
Learning and advancement get players committed and invested. The brain enjoys learning - learning is a rewarding form of progress. Scaffolding can be used as a teaching tool. A learning scaffold starts with a simple example and expands the challenge (a learning fractal).
Learning should be made easier by taking advantage of pre-existing knowledge - not teaching players what they already know. When you do need to give the player advice, tell the player what to do, but not how to do it.
Increasing the amount of explicit rewards at the start of games helps to get players committed and invested. This helps create anticipation of more reward in the future. Letting players explore helps with engagement - players are more interested in things they find or initiate themselves. But make the fun part of your game easy to find! This can also be read as - give your player choice, but not too much choice!
Takeaway - scaffolded learning is enjoyable and rewarding.
Letting players make the game their own by giving them choices that create an identity. Let players customize something that is unique to them.
Takeaway - customization creates ownership.
Quickly building and shipping a product to get user feedback is important in game development.
A minimum viable product tests a specific idea. The initial stages of design should be a wide creative process that finds out what works through playable prototypes. Risky designs should be tested through prototypes, not on paper.
It’s important to review often - to be honest, flexible and adapt. Expect and be ready for problems and failures. Don’t be afraid to be embarrassed by your early efforts. Don’t take user feedback as gospel - users are good at recognizing problems, but often bad at solving them.
While context can help to guide design decisions, introducing context too early can constrain a project.
When working on an iteration, focus on improving the worst 25%, while reusing as much as possible. Ask - how little do I need to add? What is the easiest thing to make? Often you don’t need to change much to change everything - small changes can have big impacts.
Takeaways - iterate honestly, be brave about crude initial implementations, think both about the source of feedback and the cost of future actions.
Lots of independent game development is done in small, multi-disciplinary teams working for two to three years. Crucial in small teams is awareness of your own weaknesses and having colleagues to cover these weaknesses.
Small teams must do things differently - they can’t compete with large companies by doing exactly what they do. Most of the time innovation isn’t need - small companies can focus on the niches that are too small for large companies.
Takeaways - small teams must do things differently - this can mean a smaller niche or a different way of working.
Polish refers to things like pretty graphics, controller shaking and sound. Usually this polish is added at the end of the development cycle.
Polish can also play a role earlier in development - as developer feedback. Building polish early allows the developer to better understand the game - what is working and what doesn’t work.
Polish gives the game the details that people fall in love with. Details allow emotional bonds between the player and the game, and also give opportunities for individuality.
Takeaway - Leaving the details to the end may be incorrect - consider the value of higher quality feedback versus additional development time.
Getting players to play the game again using powerful and interesting decisions - decisions that make the player want to play the other choice. Plant the idea of ‘next time’ in the players mind.
An interesting decision is an idea from Sid Meier, the creator of Civilization - one that:
Takeaway - give users a reason to come back again and make interesting decisions.
Many of the games covered at GDC are independent games - small niche products. Designers do not try to please everyone.
Trying to please everyone will mean you please no one. Often features that some users love, others hate. It’s important to design games that some people love, and not worry about the others that don’t. Fundamentally it’s about dominating a niche.
Design should be for the specific needs of a specific player - not averages across the entire audience. Focus should be placed on maximizing the positive responses, and not on minimizing negatives. If you design features that people hate, this is OK (as long as others love them). The worst case is features that no one loves and no one hates - this makes people bored.
Takeaway - focus on generating strong positive responses, not avoiding negative responses.
This idea had an immediate impact on how I work. The earlier you build tools to visualize what’s going on, the sooner you can use them to help development.
Ask - what would a picture of this system look like?
Useful visualizations include:
Game developers are often keen (or even forced into) displaying lots of information on a single screen. A common mechanism for this is the use of power bars to compactly represent the state of a large system. These power bars are low dimensional summaries that communicate a lot with a small amount of space.
Takeaway - build valuable visualization tooling up front.
Actionable documentation for specific people means:
Often we get stuck in developing documentation in the same default style - instead different documentation styles can help specific people in different ways. The most memorable was the use of a Civilization style tech tree to present a course curriculum.
One should not developing exhaustive or comprehensive documentation - instead develop documents as needed.
Consider using a different starting point or perspective when pondering a problem.
Takeaway - constraints make design easier.
Perfectionism - the inverse of simplicity - perhaps the problem of design. Design should only improve the player experience.
Game developers who let gameplay diverge between single-player and multi-player are avoiding the temptation of wanting to apply the same game experience (the one, true, perfect experience) in different contexts.
A more perfectionist approach insists on consistency (perfectionism by another name) to the detriment of gameplay.
There is another temptation to use design as a way to prove technical skill - avoid this! Keep the focus on the emotional experience of the player.
Takeaways - don’t let the perfect be the enemy of the good. Don’t let ego drive design.
Component reuse is a concept in game development & software development. Modular level design also offers the player a consistent experience, allowing the player to better understand and learn within a game.
Bi-directional level design is where a player first plays through a level, then plays back to where they initially started.
Modification of the level (say through weather or enemy types) can then give the player a different experience when playing backwards through exactly the same level.
Takeaway: can you re-use existing workflows with a fresh twist?.
In free to playIt’s also important to iterate and throw out documentation create new as needed.
Rules and principles are the sum of prior experience. Explicitly articulating these principles and using checklists can help integrate lessons learnt into future designs and expand your design vocabulary.
Takeaway - be specific and clear about your principles.
Break your design rules and principles. Being too strict with rules (a form of perfectionism) can lead to making the wrong thing - sometimes it’s correct to step back and challenge your in the context of what you are actually trying to achieve.
Takeaway - be willing to break your principles.
The brain reuses neural pathways when solving similar problems, stifling creativity. The value of constraints in design stem from forcing creative, exploratory and risky designs.
Consider using a different starting point or perspective when pondering a problem.
Takeaway - constraints make design easier.
Perfectionism is inverse of simplicity.
Game developers who let gameplay diverge between single-player and multi-player are avoiding the temptation of wanting to apply the same game experience (the one, true, perfect experience) in different contexts.
A more perfectionist approach insists on consistency (perfectionism by another name) to the detriment of gameplay. Design should only improve the player experience.
There is another temptation to use design as a way to prove technical skill - avoid this! Keep the focus on the emotional experience of the player.
Takeaways - don’t let the perfect be the enemy of the good. Don’t let ego drive design.
Component reuse is a concept in game development & software development. Modular level design also offers the player a consistent experience, allowing the player to better understand and learn within a game.
Bi-directional level design is where a player first plays through a level, then plays back to where they initially started.
Modification of the level (say through weather or enemy types) can then give the player a different experience when playing backwards through exactly the same level.
Takeaway: can you re-use existing workflows with a fresh twist?.
In free to play games most of your users will not be paying. You should not ignore these users just because they are not paying - free users give value to a game through publicity, gameplay, content creation and community management.
Test how the game feels from the free users perspective, and don’t put up paywalls too early. If the paywall comes too soon the player doesn’t have the chance to fall in love with the game. Early paywalls also create a expectation of having to pay often.
Converting free users to paying shouldn’t be about creating ‘whales’ - instead try to get the user to just spend their first dollar. Make that dollar efficient and valuable for the user.
Takeaway - understand your users, no matter the business model or their financial value to you.
Thanks for reading!