Projects I’ve worked on, large and small, have often demonstrated similar issues with game design in their later stages. Beyond having me in common – which is hard to do anything about when you’re me – one issue has been that the role of game designer changes throughout the project but not all game designers adapt to this change.
When they don’t, they can be part of the cause for delays, miscommunication, and overtime.
To illustrate why, let’s sort a whole game’s creation from idea to launch from the perspective of what a game designer should do. (In my opinion that is – remember subjectivity!)
Many designers thrive on ideation. Coming up with crazy mechanics and clever solutions to theoretical problems. Having ideas and working through them at breakneck speed. But ideation has a time and a place, and it’s not a full-on brainstorming meeting three weeks from launch.
Keep it short, sweet, and early.
With all those ideas done ideated you take them to your media of choice and you explore them. In-engine rapid prototyping, storyboards, one-pagers, session prototypes, role-playing game prototypes – there are countless ways to explore the fruits of your team’s ideation. This is where you do it.
What needs to come out of this is a means to communicate what your ideas are actually about. Not just material for more ideation.
This headline looks scary. Maybe it is. But the thing is that you need to commit to the things that work during exploration and abandon the rest. This is where you do that. In the best of worlds, you can commit gradually through a revised exploration process. More realistically, whatever you have time to explore will also have to be what you commit to. The sad truth is that most games have very little budgeted time for exploration.
The word ‘commitment’ in the previous section is no joke. When you’re done committing you’re committed. What you have by now is some final form for your game. On paper, in prototypes – something. You absolutely cannot go back to exploration or ideation once you pass this line:
If you read this, you’re on the other side of the line. Just remember you chose to cross, wipe the whiteboard clean, and get to it. If you’re caught ideating or exploring on this side of the line, you should be (humanely) punished for it.
Design is still needed. Ideation and exploration isn’t needed, but figuring out what to do when a button combination doesn’t work or focus testers can’t figure out where to go next is needed. Solving real problems demonstrated by the playable game.
As a game designer, you play your game every day at this point. Focus on finding problems with the design – don’t report bugs and glitches. I mean, you can do that too, but it’s a bit too easy to put your tester goggles on and lose the holistic perspective. Instead, make up personas and play like they would. Do dumb things and see what happens. Make checklists of which steps you have to go through to make standard tasks like changing the resolution or looking up which button to press – then try to remove as many steps as possible and to filter information in an understandable way.
After solving problems for a while you’ll know all the sliders and variables and spreadsheet details you have to work with. This is a more fine-grained process than problem solving and assumes that you’ve mostly moved on from that stage.
You’re still playing and watching others play but you do so to observe the results of your balancing. Look at this as a polishing phase. By this point the game fundamentally works but it’s not quite ready for mass market.
The state of the game outside of the designer’s responsibilities may still be lacking content or features, but you’ll have to be able to look past the most glaring faults and focus on the balancing.
Once a game is out in the wild, you’ll realise how wrong your balancing assumptions were. Consider the 10,000 hours from a different perspective. Your game will be subjected to people’s first hour 10,000 times or more. There’s just no conceivable way that you can predict how thousands of people will try and succeed in breaking your game.
Most players will probably do just as you thought they would, or correspond to one of the personas you devised during problem solving, but some will get stuck, misunderstand something, or just plain dislike everything you’ve tried to do and think you’re a moron. Sometimes loudly.
You may be forced to go back to problem solving at this stage, but it should only be in extreme cases. For the most part, designing at this stage is an effort to rebalance things so they fit with practical reality. Tuning them just so.
Of course, balancing and tuning will be the same thing if your game is run through Early Access or similar process.
It’s relevant to note a few things:
- Not all game designers are as comfortable at each stage, or even as good at the work at each stage. Some are fantastic at having or communicating ideas, while others may be better at problem solving.
- Not all design disciplines have equal need for all of the stages. If you’re a systems designer you probably need less pure ideation than a narrative designer but you need a lot more balancing.
- How much time you focus at each stage will depend on preferences, budgeting, staff availability, and many more things.
The only takeaway you need to have from this is that you should know where your design currently is and what that means for the work you need to put in as a game designer.
During ideation, you don’t need to balance anything. During problem solving, you shouldn’t explore new crazy mechanics. If you respect that line you chose to cross before, your game design work will become a lot more predictable and you won’t encounter as much eye-rolling from your colleagues.