Take a Break#
Stuck on a problem? Feel like you’re grinding away but not making progress? Sometimes one of the best things you can do for your brain is to give it a break from the problem you’re working through.
Taking a walk can be a great way to help clear your mind and get a little exercise in the process. Going to get a coffee, beverage of your choice or a snack as part of that, can be a nice reward that leaves you ready to tackle the problem with fresh eyes.
Another option could be riding a bicycle or going for a drive. These activities tend to demand more attention but also let your mind work in the background, similar to how shower thoughts happen. I’ve found the time spent commuting has led to many ‘ah-hah!’ moments where I’ve found a new approach for something, or solved a problem.
And sometimes that old advice is still relevant: Sleep on it.
This one can be a little trickier because for many folks, trying to sleep with an unresolved problem floating around in your head can be difficult. That said, if you can put a pin in it, you might find that the next morning you wake up with a new perspective, idea or thought that lets you get past what was blocking you.
Yes, and…#
Most often, game development is a team sport. And, just like in all teams, every member needs to be able to recognise, support and maximize the contributions of their fellow team members.
Being able to interpret and expand on the ideas of team members in a way that aligns with the overarching project direction, regardless of their discipline, is a key skill for a designer.
When a team member offers an idea, listen and take a moment to find where it could fit within the established possibility space of the project - either as a whole, or by finding some aspect of their idea, a kernel or spark that can work - then continue with “Yes, and…” followed by your own idea that builds on from theirs. In some circles this is also called “riffing”.
Hearing what team members have to offer and being able to adapt it into the existing design or problem space lets you have a genuine conversation that reinforces their own investment in the game and lets them feel like a valuable team member, while also expanding your own view of what could be possible in the game as well.
Now, this isn’t to say that every suggestion should be taken wholesale and integrated into the project. There will be times when team members suggest things that run counter to the project’s direction or simply don’t fit for any number of reasons. However, by practicing “Yes, and…” you’ll more easily be able to find the core ideas that can elevate the game and give the team more ownership in the process.
It’s important to remember that game design isn’t about having ideas, it’s about solving problems. Sometimes those solutions come from places you don’t expect or you discover that team members have skills that aren’t their primary vocation.
Be Flexible#
It’s rare that everything goes exactly to plan. Sometimes you design the best version of a feature or mechanic and it ends up rescoped, deprioritised or cut. Other times things outside of your control have to shift and that impacts your work. These changes can generate stress or impact you emotionally, especially when you’ve invested a considerable amount of work into them.
In these times it’s best to remain flexible. Don’t take things personally and understand that cut or rescoped features don’t suddenly disappear from reality as though they never existed. Oftentimes there are aspects of these features that could be re-purposed or re-appear later, either in the same project or possibly a future project, and so they’re best kept in mind, or a document of things you can reference in future.
It’s also worthwhile to consider how existing features can be adapted to meet the needs of the changing conditions you’ve been presented with. Always remember that when working in a team it’s exceedingly rare that these types of changes are only affecting you and so the easier you make this process for your team, the better.
Play like a Player#
An important skill for a designer to have is to be able to perceive the game as a new player does.
To do this, pick up the controller and just look at what the game is asking you to do. Don’t do the thing that you know you’re supposed to do because you designed, built it or have played it a hundred times, but instead respond purely to what’s on the screen.
Hold the controller in your hands and don’t assume what any button does. A is not the confirmation button, X isn’t your primary interaction button - they’re just buttons and you have no idea what they do. Are there instructions or hints on-screen to help you figure it out? What happens if you press them? What does the game do and what does it look/sound/feel like? Respond to the stimuli the game is giving you. Be aware of what you intuitively understand and what feels confusing.
This is how a player will see your game the first time they pick it up, or if they come back to it after a long absence. How do you want that experience to be for them? How does that contrast with the expert player who knows everything about the game already?
This is what it means to ‘Play like a Player’ and it’s an incredibly valuable skill to develop.
Don’t Sweat the (Implementation) Details#
Early in the design process for a new feature, there will often be many different shapes it could take that accomplish the same, or similar, goals. At this stage, it’s best to let the design be ephemeral and focus on what it needs to accomplish based on its goals and player experience statements, without worrying about the details of how it will be implemented in game.
The ‘how’ part of fitting the design into the game never belongs in a written design.This is because that’s up to the experts who will do the work to decide. Maybe that will be you, maybe that will be someone else, but how the feature is ultimately implemented can have many different possibilities across the duration of the project, meaning that attempting to pre-define it creates a series of problems, places unnecessary restrictions and removes the agency of the team member doing the implementation in deciding how they do their work.
This also creates more documentation you need to keep up to date. You only want to update design documentation when the design changes, but if you’ve documented the implementation and that also changes, that’s an additional load for you to maintain.