Order of Operations
What is the right sequence when it comes to designing a game?
My good friend and perennial co-conspirator Ian Hardingham said something interesting to me this week:
"Game design is 90% about working out what order to do things in."
This is a massive struggle on every project, particularly when aiming for more innovative gameplay. It’s also related to a classic chicken-and-egg problem which is particularly apparent when working on highly systemic games: you can't play the game until the systems are working…but you don't know how the systems should work until you play the game.
Here are some thoughts on how you could approach this…
Construct the Core
In every game there is a minimum feature-set required to get the darn thing functioning. In most cases, the design starts to become more immediately apparent when you are at least able to get your hands on it in some form.
Plunging in head first but then stopping to get a sense of your surroundings (perhaps even reverting to design documentation) is one way to break through the choice paralysis of early design phases. The musician Mr Bill describes his process as “reactive” - he starts with the basic building blocks of a sound or sequence, then follows the branching choices from there.
Intention and Obstacle
Just as in narrative, push and pull matter hugely in game design: what is the player's compelling goal and what is the seemingly insurmountable challenge they must face in order to achieve it? How does that boil down to moment-to-moment gameplay? If you know the answers to those questions then you might be able to prove out your assumptions with a relatively minimal testing setup.
Just Roll the Dice
A sufficiently complex game system readily devolves into a random number generator.
You can use this phenomenon to your advantage early on by replacing systems which you expect to be meaningful later on with bounded randomness. When this becomes annoying or broken in the context of gameplay, you'll have some good feedback on how the system should eventually be shaped.
Mission Complete
Many older games were built around linear levels or missions. We tend to think of more freeform gameplay these days, with roguelike structures and rich open worlds becoming endemic. It can still be helpful to create a limited, linear gameplay unit - such as an arena or mission - for the purposes of testing. What is the arc that the player will need to move through and what will they do once it's complete? Does this unit of progression feel like it's made a difference during the next mission? Once you’re happy with one, try building another with different content to test the limits of your assumptions.
I have seen a lot of overly complex game prototypes where just a single simple mission would have foregrounded most of the ongoing design concerns - if your game has combat and a single combat arena isn’t fun without relying on context from outside it then you’re going to have a serious problem.
AI Agency
Enemy AI is one of the trickiest things to schedule - again, you often can't play the game properly until it's there but you may not know exactly how you want it to behave from the outset. It's hard to discuss this in abstract, as requirements will be hugely different depending on your project, but often a very straightforward approach early on can help. Yes, there might be some inexplicable behaviour and poor strategic choices but sometimes even just having enemies moving around and vaguely interacting with the player can give you an insight into where you need to go.
On several of our older Mode 7 projects, we built the multiplayer version of the game first - this gave a really clear indication of desirable enemy AI behaviour. This tactic certainly won’t work with every game but it’s something to consider.
Contentment
One of the most common design traps is building too much content before you're clear on the core gameplay - this is extremely hard to avoid. One of the best antidotes to it is to stop periodically and take a critical look at the design using just a subset of content - are you still hitting your design pillars and getting the feeling you want from the game? Not getting too attached to early content or going too in-depth with it can also help. Instead of trying to build a large amount, aim for a wide range - test the limits of what the game can sustain as early as possible.
Last Orders
Game design schedules are as diverse as the designers who employ them, so there is no prescriptive solution to this problem.
Personally, I think building up in the following order…
Fundamental interactions
Confronting an obstacle - might involve a minimal amount of AI or scripted enemies
Working through a series of such obstacles, or combination of challenges
A mocked-up "mission" with a clear objective
A progression loop
Exploring the range of possibility in the above
…is a decent enough place to start. All of the gnarly details will depend on your own game, your design priorities and your subjective preferences - perhaps it just helps to know that every team struggles with this!