WEEK TWO (Part 2)
White Boxing and Tweaking Parameters.
WHITEBOXING
Once you’ve finished the above procedure, you now have to build your own white box to replicate the feel of the researched game or the prime comp as much as you can.
Most people are afraid to white box because they feel like they need to know everything about a game before making one. This generally leads to long meetings and uncertainty that take up a lot of time. But trust me, a lot of these assumptions and uncertainty, that were unnecessary in the first place, will not exist if you start white boxing immediately. So stick with a Game Designer’s mantra, “Fail Fast and Follow the Fun”. Create a white box to get the crappiest version and uncertainties out of the way.
With this first white box version, you can now follow the same procedure as researching the prime comp and gather the same data for your white box.

As you can see, this was the most frustrating game ever made. The player’s first death was at 4 seconds and the consecutive ones were 20 seconds apart in a 42 seconds gameplay. They never made it past 20 seconds of the game because the player would respawn at the start of the level. Whereas in our prime comp, the player got to experience most of the game before their first death. They could experience a solid 1 minute 24 seconds of gameplay before they had to stop.
What is the point of having a good level design in the rest of the game if the players cannot go beyond the first 20 seconds of it? This was the first thing that we learned only because we were able to compare the data between our prime comp and white box.
Whiteboxing is extremely crucial before you start preparing for pre-production phase. It helps you get terrible ideas or common mistakes this genre already faced out of the way. Your prime comp has already done a lot of playtesting and spent time on making the most perfect game according to them and you need to get past that phase as quickly as you can to be able to add your own +1s by going one step further.
IDENTIFYING AND TWEAKING PARAMETERS FOR THE WHITEBOX
Once you have your whitebox ready, it’s time to start naming the parameters that are used by the core mechanic or influence the core mechanic in some way.
For the cube runner whitebox, we recognized the following parameters:
-
Forward Speed
-
Deceleration Time
-
Player Size
-
Turning Speed
-
Start Position
-
Camera FOV
-
Player height on the screen
Interesting findings that we did not anticipate:
-
Originally, instead of changing the player size, we moved the camera further away or closer to the player to give the illusion of change in size because changing size meant changing the spacing between the obstacles. However, this was a terrible idea as the obstacle would sometimes block the camera.
-
Changing Camera FOV can create an illusion of change in speed. Lesser FOV means slow speed and larger FOV makes it feel like you’re moving fast without any change in the actual speed. However, if the FOV is too large, it can create a distorted mess. So a smaller FOV is like looking through binoculars, whatever exists within the screen is clear but it shows very little content on the screen. Wider FOV shows maximum content but objects farther away from you are not clearly visible.
-
The actual change in speed makes the players want to take more risks. I observed that changing the speed from 80 to 150 created, what my teammate calls, a “Badass Effect”. It encourages the player to take on more risks and try out newer ways to maneuver through the same level. Whereas a slow speed did not encourage moving around the level too much meaning there was an absence of thrill.
These are a few examples of how recognizing and tweaking some parameters in our game led to some interesting discoveries that none of us predicted.