Some megagame design lessons I learned the hard way
Credit: Very Large Huge Games
Ed Silverstone helps run Megagame Makers and Reading Megagames in the UK as well as designing his own megagames in his spare time
A couple weeks ago was the first run of my fourth megagame. It went pretty well, thanks for asking! Looking back to the first megagame I designed, I realise I’ve very much learnt megagame design by trial and error - often, repeating the same error many times. Designing a megagame is a massive, complex undertaking and there are myriad traps waiting for the unwary. So for anyone else mad enough to give it a try, here are some of the things I learnt the hard way. Hopefully, they make the road a little easier for you!
Learn by doing
This one should be obvious, but it’s surprising how often people miss it. If you want to get good at designing megagames, play a lot of megagames - ideally, a lot of different megagames. Play in a range of roles - even if you prefer diplomacy, request a mechanics-only role. Lead a team, be a small cog in a larger machine, be a solo player. Volunteer to control - and again, aim to do a range of different control roles. If possible, run a game someone else has designed.
Oh, and then think about what you’ve experienced. Ask what worked, and why; what didn’t work, and why not. If possible, chat to the game runner or designer. If there are players who didn’t have such a great time, try to understand why - what frustrated them? What would the designer change about their game, if they could have another go around? (But maybe don’t ask a designer to critique their game immediately after it’s run, or at least check in with them first).
If you don’t have the luxury of regular megagames running in places you can easily reach - the online community is generally supportive, and designers are usually happy to share their game handbooks and talk through the choices they made. But given how many hours you’re going to pour into designing your game, it may also be worth a bit of extra travel to open yourself up to some of the other options available.
Outsource
Designing and running a megagame needs you to be a writer, an engineer, an artist, a graphic designer, an administrator, a marketer and an emcee (and a host of other skills besides). I’ve yet to meet anyone who ticks all of those boxes.
This means that to design a good megagame, you need help. Be honest with yourself about your strengths and weaknesses and don’t suffer unnecessarily. Understand that the tasks that you dread, others will see as easy and fun. Between your local nerd scene and the online megagame community, you will find someone willing and able to help you.
With that said - it’s up to you to work out exactly what you need and communicate it clearly. So “can you design some components for this minigame” needs to be “I need six different unit tokens, they need to be this size and shape, they should look futuristic/whimsical/beaten-up, they need to display this information”. “Can you write the player briefings” needs to come with bullet-point descriptions and objectives, and ideally a sketched-out example of one to show what you’re hoping for.
Finally, you need to be able to say no if something won’t work for you. It’s still your game, your vision, and your call. If someone has a great idea for changing it, by all means hear them out, but then make your own decision. To that end, check in early and often, so that someone doesn’t end up spending weeks going down a blind alley (not least, because it’s that much harder to say no at that point!)
Make a choice
This is a project that will consume 200+ hours of your life. You can start off by just playing with the idea, having an ideas document that you jot a few paragraphs in when you’re struck by inspiration. But there comes a tipping-point where you need to make a choice: “I’m going to try and make this one real”.
That’s not to say you can’t bail if it just isn’t working, if work gets busy, or for any reason you want. This is your free time, it’s up to you how you spend it! But without concentrated evenings and weekends spent working on this project, it isn’t going to happen. Do you have that kind of time available? Are you excited enough about your game idea to put that sort of time in (and still be excited about it afterwards)?
If so, it’s time to make a plan. Everyone works differently - you might want to list everything you have to do, with timings and dependencies, or just list your big milestones and then work towards the first one. You might even want to ask a friend to check in with you on how the work is progressing. The key point here is to set yourself small, achievable goals, that let you make tangible progress towards your next milestone - which might be a feedback session with some fellow designers or a mini-playtest. Where possible, get dates attached to the nearest couple of milestones (but make sure they’re realistic).
Now you’ve decided you’re actively working on this game - make it your primary spare-time activity. If that’s not feasible, at least carve out periods where it’s the primary focus. If you’re struck by an awesome idea for another game - write it down in your ideas document, as quickly and simply as possible, and then get back to the current focus. You might come back to it in the future, but right now you’ve made a choice to work on this game, so that’s where your focus is.
Iterate
Credit: Johan Soh Olofsson, Gothenburg Megagames
There’s nothing so dangerous as over-committing to one part of your game while another is still three words on a sticky note somewhere. The more time and effort you’ve spent on a game mechanism, the more resistant you’ll be to changing or scrapping it; the same can be said for art assets, lore documents, and so forth. Certainly don’t spend serious money on game components until every element of the game is thoroughly designed.
The problem here is that no one part of your game exists in isolation (unless you did something very wrong). That means that each part of the design can and should create requirements and constraints for the other parts. Similarly, you may hit a problem in design which is best solved by changing the game’s lore, or vice versa. A mechanical change may lead you to swap out character cards for basic meeples. You don’t want this sort of chopping and changing to throw away hours of work.
Instead, sketch out the whole game at a high level, and then flesh it out one layer at a time. Start by literally writing a single paragraph describing each area of the game. Then, list the interactions you think should happen in each area. Start to enumerate the inputs and outputs of those interactions, how often they’ll happen, what decisions players need to make. By the time you get down to brass tacks, you’ll likely have removed entire game areas and added others, found complexity and interest in some places and avoided make-work in others. And everything in your game will be there for a reason.
Speaking of iteration, get feedback as often as possible. At early stages, this will look like having people read over your design documents and ask questions - later on, run playtests, of each individual area or of the whole game. Getting outside eyes on your game keeps you from getting stuck in a rut, and challenges problems you’d otherwise be tempted to ignore. Don’t wait to do this - the more work you’ve done since you last got feedback, the less receptive you’ll be to the feedback you receive.
Logistics
Remember your game has to happen in a real, physical room, being played by real, physical people. This unfortunately means you need to think about some boring logistical constraints. What information do people need? How and where will you display it? How far away is it legible/visible from? Are different components clearly visually distinct? What information should be private to only a few players, and how will you segregate it?
What components are in a player’s inventory? Will some players be walking around with fifty plastic coins in their pockets - will that get cumbersome? If a component needs to be carried around or kept in a pocket, is it large enough that it won’t get lost? If a card needs to be carried around a bunch, it may well get scuffed or bent, at which point it can no longer be used for random draws from a deck.
A massive map feels awesome, but bear in mind that people have to be able to reach the middle. A long, thin map can be more practical than a square one (depending, of course, on what makes sense in the game’s world). The size of the map also constrains how many people can stand around it at once - more or less one person per 50cm/2ft of perimeter.
I could go on, but hopefully you get the idea. For every bit of design, think about how it will work in physical space, what components will need to move around and how. Make the practicalities of the game simple and smooth, and it’ll feel a lot better to play.
Perfect is the enemy of done
You know this. Everyone knows this. The game’s never going to be perfect. It’s especially true in the world of megagames, where even the best game is dependent on the team running it and the mindset of the players. But you’re still going to be tempted to delay, delay, delay so you can keep making tiny tweaks to the game.
Stop it. Just run the thing. People will have fun, things will go wrong, you’ll learn loads, and the world will keep spinning afterwards. And the next time you run it - or the next time you design a megagame - you’ll know more, and it’ll be better. But to reach that point, the game has to be played - perfect or not.
You’ve got this!
Would you like to add a megagame article to our blog? You can do so via this link!