The Mighty Boards production pipeline

At Mighty Boards, we work both on game design projects coming from our own internal designers and on projects that we receive from external designers. This is a privilege: it gives us a greater pool of potential games to develop, and allows us to work specifically on projects that we really love. At the same time, it means it’s vital that we operate according to a clear and rigorous production pipeline, ensuring top-notch quality wherever the project is coming from. 

Our games go through a thorough screening process before they are even accepted within our production pipeline, where they are then developed, grown and rigorously tested to bring them up to the high standards we stick to. Our processes come from various different areas of expertise that our team brings together – from experience in the triple-A videogame industry (David has worked on Thronebreaker: The Witcher Tales and Cyberpunk 2077 at CD Projekt) to academic game studies (Gordon and Daniel are both faculty at the Institute of Digital Games). So, in our process, the production techniques of high-end, large scale video game projects are combined with our academic knowledge of research-based testing techniques. 

In this post, we’ll run through the process one of our games goes through, all the way from the prototype stage up until it reaches the shelves of your friendly local game store.

The designer-bashing-their-head-against-a-wall stage 

 Whether it’s an internally-designed game or a submitted design, the first part of the process is the most exciting and, at times, chaotic part of the process. Here, the designer goes from inspiration and game idea to the creation of the initial prototype, testing (and often solo testing), and building on the initial idea for a number of iterations, producing any number of  mock-ups along the way.  In rare cases, this process takes a month or so; for other games, this goes on for a year or more.  The designer checks in with the rest of the team who are involved in the internal tests and iterates until we are happy with both the fundamental structure of the system and the potential of the game as a product. The two aspects overlap, but there are considerations for each that don’t necessarily align fully, at least initially. It is our job to make sure that by the time we approve the game for full development the two DO align.

The first development stage

Once we’ve got the basic design down to a form which gives us all sorts of warm and fuzzy feelings, the game moves into the more structured production pipeline. At this point, two things happen: we appoint the main developer to the project, and prepare a prototype to test the game with our internal teams.

Every project we develop has at least one main developer, and often, in the case of bigger projects, one or two other developers focusing on specific areas of development. Developers work closely with the designer, and can contribute a non-biased perspective on the game, without the history, baggage and personal attachment that the designer usually has. Our developers are skilled in seeing the game from the audience’s perspective, and are able to give the designer insights on many potential aspects of the project that they may become blind to throughout the design process.

In order to produce our first batch of prototypes for internal testing, we need a clean graphic design that communicates the game elements clearly, without needing to be elaborate or aesthetically pleasing.  The main difference between the testing done at this stage and at the previous, designer stage is that the initial designer tests are aimed at shaping the game from the initial idea into a form we can get excited about, while our internal tests are focused on seeing the game from the player’s perspective.  We are thus emphasising streamlining the rules, improving the ease of learning the game, general usability and starting to work on the product design. The goal here is to identify any major issues that would hamper, or even break, the game’s general flow. This paves the way for us to move on to the first internal tests.

The first (internal) testing stage 

 Once we have ironed out any obvious issues and produced a prototype, the first round of testing happens. The priority, at this stage, is not on fine-tuning balance – it’s still a bit early for that – but on the iteration of the game’s basic systems. The kinds of questions we’d be asking are: is it fun? What emotions does it invoke? What images does it generate in the player’s mind? What stories does it give rise to? 

 This kind of testing is totally different than the more traditional balance testing, which comes later in the process. It requires a specific type of player – someone with a deep understanding of what makes a board game tick, and who’s eloquent enough to be able to put that into words. For this reason, for this initial round of testing, we bring in select groups of people we trust.    

The second development stage

The main thing we do in the development stage is trimming the fat off the game. For every mechanic, every component, every action the player takes, we’re constantly asking, “Does this add anything ‘necessary’ to the game?” If the answer is ‘no,’ then that element is cut.

These cuts can sometimes hurt – we often have to let go of elements or mechanics that our designers were particularly fond of. There are other difficulties too: since, in a well-designed game system, everything is tightly wound together, removing one element can have a knock-on effect that changes how the game as a whole works. Still, it’s a necessary step. As a result of this trimming, the game is eventually reduced to the bare bones of its system, free of any useless complications or adornments.

This is absolutely vital: it’s only through this editing process that we can identify the core of a particular game – the elements that are most important, and that make it fun. Once we’ve identified this core, our focus can shift towards strengthening it.

This is also the point at which we would start thinking about other aspects of the finished game, beyond the system. In particular, we’d start thinking about what we want the game’s art to look like, and we might begin looking for an artist who’d be a good fit for the project.

The second (external) testing stage

By this point in the game’s development, the artist would have been brought on board and would already be busy making the game look great. While that’s happening, we move on to external testing. 

While the initial internal testing round is geared towards helping us make high-level decisions about what the game will be, external testing tends to be a lower-level affair, focusing on fine-tuning the system until it runs like a well-oiled machine. For this reason, during these tests, we meticulously collect data on things like playtime, winning strategies, most and least used cards or items, and game arcs. For each game, we also create a custom questionnaire, based off our template which we then modify to suit the particular game. 

Since this round of testing is about data collection, quantity is important – the more tests we run, the more data we collect, the more polished the final game will be. For this final, professional round of user testing, then, we have regular test groups in three continents, situated in five different test centres and game design schools.  

The production stage

By the time the art is finished, so is the testing, and we proceed to the finalization of the product. Here, the game’s physical components take their final shape, and a lot of work goes into optimizing the contents of the box for shipping, and efficient manufacturing. Only when the last physical component is selected, held in hand, and agreed upon by the team, is there a finished product. 

After all this, we get to actually selling that product. But that’s an entirely different story for another time.