White Boxing Your Game

Midnight Hub is a Swedish indie studio run by former Mojang and Paradox developers. Right now we're hard at work with our story-driven mystery game Lake Ridden. Feel free to reach out on Twitter if you got any questions! This post was originally posted on our developer blog.
 

In this post I’ll share how we at Midnight Hub go on about making our first game Lake Ridden. Since this is quite a broad topic, how to make a game, I’ll start with the very basics, and in coming posts we’ll talk about cool tools that help us with the day to day work, as well as habits that might make your own work easier! Since I’m the producer/studio manager, I’ll do this from my point of view, meaning I won’t go into nitty gritty details on code examples or custom settings in Maya.

By sharing our way of bringing Lake Ridden to life, I hope that perhaps I can offer some takeaways for you, or maybe you can give us some feedback! Like any creative process, making a game is a living thing, and best practices change over time. Consider this a case study if you’re curious on how games are made!
 

Why You Want A Workflow

Something that will help you focus, and that is absolutely vital for any serious games project, is having a good workflow in place. A process of some kind to follow when making the game (or hunting rabbits!). Time will never be on your side, and you want to know what to work on at any given moment. If you’re a one-man army, making an indie game at home, you can probably jump from part to part, working on whatever aspect of the game you feel like that day. If your team would do the same however, chances are the whole project will soon descend into chaos. 

All the post-its needed to make Lake Ridden's pre-production work!

Keep in mind that when I say “good workflow”, I mean something that fits your team, that helps them make the most awesome game possible. What works for one team might not be the best choice for another. My experience, as a producer, tells me that it’s very hard (and counterproductive) to bend a team to fit certain rules of a workflow or process. It’s almost always better to tailor the workflow to fit the team. After all, the process is in place to help them make the best possible game and have a nice time doing so! Listen to your team/yourself and figure out what they need to succeed. 
 

White Boxing the Game

Our game Lake Ridden is a first person mystery game, set in a Scandinavian forest. Much of the gameplay consist of puzzles, exploring, piecing together the story and finding important items. We’re making the game in Unity, for Windows and Mac. On average 6 people are involved in making the game, and we have a dedicated office space.

The game is a fairly linear single player game, so when our pre-production was done earlier this year, we sat down and looked at the game’s rough story, dividing the game into manageable “chapters” that made sense from a developer perspective. The pre-production is the stage before production, needed to assemble our team, set up all the tech, decide what game idea we want to work on etc.

This is how we're approaching pretty much everything in the game. It usually starts with a drawing (u.l), then we draft a quick 3D version in Maya or Unity (u.r), white box it out in the game and do a play test.

After chopping up the outline for the game we have been white boxing the chapters, one after another. White boxing for us literally means placing out white boxes and placeholder items instead of final props and beautiful 3D art. The goal for this is to get the backbone of the whole game in place as quickly as possible, it’s almost like doing sketches before you paint a canvas. What we want to do here is to test the story pacing, puzzles and the core game mechanics. This is quick and dirty, but it helps us build the game in an organic way, and we can test things straight away.

At the beginning of this project Johan made a tool that builds the game several times a day, automatically, so it’s always possible for us to play the game at all times, which is awesome for testing! It also tells us if something we committed into the project breaks the game.

The old camp fire site. Step 1: white box where we need the important items to be.

I have never worked in a games project where the first idea, drawing or line of code was the best, nor where developers haven’t needed to go back and rebuild, tweak or redo a lot of the game at one point or another. This is simply because it's almost impossible to tell if something is fun to play before you have tested it. If there was some kind of magic way to know if a game was fun before you built it then multi million dollar games would never be delayed or scrapped...

By working our way, by naturally building the iterations into the workflow from the start, we hope to minimize the amount of time we invest into each part of the game before we know if that part is final or needs additional changes. Only when we are absolutely sure on the foundations and the core do we level up the art, game play and sound to final versions. Throwing away stuff you have spent days or weeks working on is extremely demoralizing for the team, so let’s avoid that by not investing too much time into something we haven’t tested first, yes?

Step 2: Replace the white boxes with new, quick 3D assets.

When the majority of the  white boxing is done after the summer, we’ll go through the whole game again and this time “dress it all up” in the intended art, and start fine-tuning the gameplay, dialogues and everything else. 

Step 4: Most of the items are in the scenen, but are still far from final regarding look, feel and lights.
 

Step 5: Erik did an over paint of the screen shot in Photoshop, to show the vision for the final art that should be in-game. We'll use this image when going over the game after the summer, replacing stuff to make it look sweet!

Project Management Process
 

We have divided the 8-9 “chapters” of Lake Ridden into sprints, which tells us what we are actually going to white box. One “chapter” equals roughly one or two sprints, and one sprint takes us a week to complete. Our goal is to have a way of working which allows us to stay iterative and focused at the same time. One of the advantages of a  small indie studio is that we can make decisions quickly if needed. We have a short turnaround time, enabling us to react and adapt to new tech, ideas and feedback. We don’t need to get a gameplay change approved by ten different managers before we implement it. This iterative, organic process is one of the cores of what makes Midnight Hub what it is.

A shot of our old fashioned post-it board. Tasks move from left to right.

With this in mind we decided to go with a modified version of Scrum as our main project management process. After toggling trough tools like Trello and Taiga, we decided to do things the old-fashioned way and simply go with colored post-its on a big whiteboard at the office! As long as you have a small team you can do this, and there’s something very satisfying about moving a physical post-it from “in progress” to “done”! 

So, we stocked up on post-its and decided that our sprints would last one week. Each Wednesday we sit down together and review the latest sprint and make a new one together, based on the next "chapter" of the game. We name each sprint something descriptive, like “First Iteration of the Lake” and start dividing it into user stories. The user stories are the milestones we need to achieve, in order to make the sprint done. Naming stories and sprints descriptively helps you stay on track and focus on what you actually need to get done at the end of the day.

A very scientific illustration showing our project management process with Lake Ridden!

Our user stories typically look something like “as a player I want to stand on the shoreline” or “as a developer I need a new computer”. These stories are further divided into minor tasks, bite sized chunks that should not take more than a day to complete. An example of a task is “make five 2D concept art pieces of the lake to capture mood and colors” and then “make a rough 3D sketch of the lake and its surroundings”. This helps us uncover all the steps necessary to achieve the goal stated in the user story. We then list all relevant tasks under its big user story, assign the tasks to certain team members, and place the stories in the field named “not started” on our whiteboard. 

When you start working on a task you move it to the column “in progress”, and when it’s finally done you place the task, and eventually the story, in “done”. This way the whole team can see who's currently working on what. To improve the communication within the team even more we start every morning with a 2 min stand-up meeting where everyone tells the team what they were working on yesterday, and what they'll do today. This is a nice way of keeping the whole team in the loop of what’s going on, and to catch any miscommunication early on. On the following Wednesday we sit down and go through all the tasks together, check that they are actually done, and that we have completed the user stories and the sprint. Then we draft the next sprint together and start slicing it down to user stories and tasks. Rinse and repeat!

This is a fairly standard project management workflow for minor teams, and I guess we have modified this to fit our needs. When our latest coder Malin joined our team we decided to be cool and go digital (there's a point when keeping track of dozens of manual post-its on a wall won't work anymore), so at the moment we have hacked Favro to fit our project management needs! It works very much lika a digital board for post-its, but with added functionality.

Roles In Our Team
 

There are a hundreds of reasons a games project can fail, but two of the main threats are lack of creative vision and failed communication within the team. To mitigate these risks, we have assigned clear roles to everyone in the team. 

Johan is the creative director, lead coder and CTO. He makes the final call on all things game design, story and code. It’s his responsibility the game is fun and does not crash. He decides what tech we should use. Erik is the art director. He makes sure we have a distinct art style, that everything looks kickass. I’m the producer and studio manager. It’s my job to make sure the team is moving forward, to make sure the studio as a whole has what it needs to make the game come to life. I’m also the one who deals with 99% of the non-gamedev task like meetings with non-team members, make sure the rent is paid, that our market research is on point and that our budget doesn’t crash. 

When you give people clearly defined areas of responsibilities chances are much higher they take accountability of their work, which is gold for team work! Then there’ll always be things that fall in between two areas or decisions where art might have one agenda, but game design another. To help guide us on these difficult decisions we always think of the team first, game second. If something's bad for the team but good for the game, we simply should not do it. A game is only as good as the team making it.

Version Control 
 

So how do you organize a team working on tons of different files at the same time, all belonging to the same game project? A really important tool to help you make a game is a version control software. Examples are Tortoise SVN, Plastic, Git or Perforce. A version control software allows the team to work on all kinds of files at the same time, and to store changes and multiple versions of the items/code/text. This prevents you from accidentally deleting the whole project if you spill a cup of coffee on your main hard drive. We have chosen to go with Plastic, mainly because we have very large files. 
 

Two rabbits on my desk, reminding me to focus at one task at a time.

As I mentioned at the beginning of the post all studios and projects are different, and the most important thing is to find a way of working that makes sense to your team, that enables them to craft the best possible game. A recent, big study confirmed that the type of project process doesn’t really matter, you can use Scrum, Kanban or even the much loathed waterfall, and still achieve great success as long as our team knows why and how you are doing it!

This was a primer on the very basics behind making games in teams, and in the next posts we’ll go into more detail on how we’re working with Lake Ridden : ) Did I miss something? Do you have something to add? Are you usinh white boxing? Tell us in the comments! Thanks for reading!

Cheers,
Sara