top of page

Design Patterns - Megagame Design Mini

Wikipedia says “a design pattern is the re-usable form of a solution to a design problem.”

The idea was created in the 60s for architecture, but has since been expanded to other areas including software engineering (where I first came across them) and, most notably for our purposes, game design.

There are three books I’m aware of, all excellent in their own right and well worth a read, that deal with game design patterns.

  • Building Blocks of Tabletop Game Design (2020) by Geoffrey Engelstein and Isaac Shalev - probably the best of the bunch that presents a comprehensive list of design patterns from board games and I’ve found it very useful when designing mini-games.

  • [free] Pattern Language for LARP Design by Jason Morningstar and J Li - somewhat higher level than Building Blocks, but does encourage you to think about some things that we don’t often consider in Megagame Design.

  • [free] Design Patterns of Successful Role-Playing Games (2009) by Whitson John Kirk III - this book is quite exhaustive and low level, but a little too detail focused for my tastes, it can be hard to see the wood for the trees, but your mileage may vary.

In megagames we have little in the way of formal design theory, instead relying on borrowing from other types of games where appropriate and asking the collective wisdom of the community. Both are excellent resources, but they are not complete. I propose that design patterns could have a great positive effect on the standard of megagame design.

If we are going to describe megagame design patterns we first need to know what is needed to describe a useful one. There are several approaches but I’ve boiled it down to 4 essential questions to answer and two ones that aren’t strictly necessary.

  • What does the pattern look like?

  • Where is it appropriate to use?

  • What pitfalls are there?

  • What games include this pattern?

  • [optional] What simple variations are there and what effect do these variations have?

  • [optional] Are there any related patterns?

It is also worth noting a good pattern will help with a common problem, and describe solutions that already exist. This could cause a problem for describing megagame patterns, since the majority of game rules are unavailable and it can be hard to attend games outside of your neighbourhood.

With all that in mind though, it’s time for a simple example so you can see what a pattern might look like. Design Patterns really need wide discussion and review before they can be considered done, so this would be a draft.

Hierarchical Teams (Draft)

Description: A hierarchical team is a group of allied players with a single leader who usually share a brief and goals.

Discussion (Applicability and Pitfalls): A hierarchical team is good if you want simple goals, shared between a team of tight allies. It is also very easy to understand and a well run team can make life easy for newer players.

One of the main problems with hierarchies is that the leader can become a single point of failure for the team, or at least an individual’s game, should they fail to delegate properly or mismanage team funds.

Examples: (1) Watch The Skies teams consist of a Head of State who is in charge of their Head Scientist, Defence Chief and Foreign Minister. (2) Den of Wolves ships have a Captain who commands a First Officer, Council Representative and Chief Engineer.

Variations: (1) Should a team’s internal structure be interesting enough you can have an NPC-led team - particularly if the leader is supposed to act against their own interests (as in the Steel Empire team in Relics of the Fall). (2) Teams can also have multiple tiers of hierarchy, as in Urban Nightmare: London Calling where each local police team is coordinated by a city wide police team.

Related Patterns: Non-hierarchical Teams, 2IC Role


Creating a pattern language for megagames would have to be a community effort, no one person knows enough to write a comprehensive guide. That said, if the idea seems popular I may draft some proposed patterns in future blog posts.

Would you use a collection of design patterns? What would you add or change about the Hierarchical Team pattern as presented?


bottom of page