Most people don’t know how to ask a question effectively, don’t be one of them. An important part of learning is figuring out how to ask for help, and how to do it properly.
In part three of this series we’ll take a look at greybox prototypes.
This is a series of posts on prototyping where we will cover
- Why you should prototype (Part 1)
- Paper prototyping (Part 1)
- Wire Frame Prototyping (Part 2)
- Grey Box Prototyping
- Various games that started as prototypes
Just about every major development studio does some form of greybox prototyping. In our previous posts, we covered various prototyping methods which were mostly low tech. Eventually, though, you’ll want to prototype using the tools that you will be developing with. Greybox prototypes can be particularly effective because they can be shared with others in order to playtest immediately. If developed well, they can also be iterated quickly.
As I mentioned in the previous post covering paper prototypes, games that rely on quick actions are difficult, but not impossible to prototype with paper. However, things like physics and time can significantly impact your game, which is why it’s important to turn those low tech prototypes into something that can run in your development environment. Like all prototypes, the greybox prototype aims to give you insight about your game ideas so that you can make an informed decision before committing time and energy to implementing a feature. Greybox prototyping can beused for many things (UI tests, to develop game feel, etc), but in this post I’ll cover two of the most popular reasons that you might want to create a greybox prototype: to develop mechanics and to design levels.
One of the most famous casses of a videogame that started off as a grey box protoype is the legendary Mario 64. In an interview for the Mario 64 strategy guide, Shigeru Miyamoto states that he spent months of Mario 64's development just moving Mario inside of a test room. At the time, no one had really translated platformers from a 2d setting to a 3d setting successfully. Miyamoto believed that the key to this translation was to get the player movement perfect. During this time no other assets were created. While testing, Miyamoto requested that his team create numerous animations in an attempt to make Mario's movement fluid. Miyamoto's reasoning for this was:
"... as players got good at the controls, they’d want to try out more and more button combinations, and if there was nothing past the basics it would be disappointing for them. So we created movements for all button combinations—of course, that means a few useless ones got left in too. (laughs)"Miyamoto continued to grey box test until he felt that simply moving Mario in 3d felt fun. At the end of development Mario had a whopping 209 unique animations, and Mario 64 became a prime example of how to do do 3d platforming right.
If you’re designing a new mechanic that relies heavily on a physics engine, you’ll probably want to develop something inside of your game engine to really get the full effect. For example, the gravity gun from Half-life relies on several aspects of the physics engine to work. The various items that can be picked up and moved by the gravity gun have different variables like size and weight that changes their effect inside the game. At some point each of the interactions available in the game had to be tested and one of the quickest ways to do this is with a greybox prototype.
As mentioned above, in a greybox prototype you generally don’t want to focus on the aesthetics just yet. Instead, focus on the player interaction and use placeholders for the final objects. If it’s early in production you may have placeholders for everything including the playable character. In cases like these, it’s not uncommon for a player to be represented as a capsule or cube.
Greybox prototypes are also helpful for testing things like emergent complexity. A videogame will have many rules that govern play. Some of these interactions may not have been deliberate and might result from an unforeseen interaction. This is also known as emergent complexity. A good example of emergent complexity can be found in the now classic “Rocket Jump”. IF you play an FPS long enough you’ll come across a trick that players use to jump much higher than normal by using the knock back from an explosion. Though rocket jumps are pretty standard now, they were not intentionally programmed at the time. Instead both rules (knock-back from an explosion, and how much damage a player could take) were developed individually and were later discovered and used together by players. When you introduce a new feature, or variable it’s helpful to test those changes quickly in an isolated environment to make sure the rest of your game won’t change substantially as a result.
changes to your core rule set will change the way people interact with your world. So, keeping levels blocked helps because you can check the stage and make changes\ BOTW dev changes the wind speed in the dudgeon and it broke the wrold!
Example: There’s a form of prototyping that says you should focus on the gameplay and mechanics before you invest on any of the art associated with the game itself. Several games have used this process with good results such as braid
In this example we can see the early version of braid, and the final published version. although it wasn’t finished, it played well and people were able to give feedback about the mechanics. With the mechanics well done, art could be produced to create a more polished game.
One of the best alien games to come out in recent years, started life as an internal prototype. The developers of Alien Isolation found that playing a quick game of hide and seek with one player controlling a human, and another controlling the Alien, was not only fun, it really captured the feeling of being hunted. Unlike other alien games where you play a marine with an endless supply of guns, Isolation makes it very clear that you are unmatched forcing the player to hide from Alien. This design leads to terrifying confrontations and tense moments in the game that really deliver the tone of the original Alien film. If it wasn't for the success of the initial prototype, this game may have never been green-lit. - Source via internet archive
Another common use of greyboxing is to produce and iterate over levels quickly. The idea behind this is that rather than spending time and money to create assets for a new level you create the same geometry or general shape in order to try it out with playtesters before create the final assets. This can be helpful to test stuff out like gameplay stuff - like if platforms are far enough apart for a jump, or if platforms are at the appropriate height. Another thing might be to test out other game systems like camera angles. Especially for 3d games, camera work is notoriously difficult to get right.
Examples of how this is used can be found in the roms of several older games. Thanks to channels like beta 64 and websites like the cutting room floor, we now have unprecedented access to unused assets that didn’t make it into the game, but were still stored in memory. Mostly this includes tools used for development and debugging. In many cases these include tests grey box rooms themselves.
For example, in the game Kirby’s Adventure thanks to debug tools we can see several rooms that use temporary assets. In many cases these levels correspond to finalized versions that were included in the completed game. Again this was done to prototype the level, getting things like platform placement and enemy AI correct before implementing them in the final game with final assets.
Challenge: create a greybox protoype
For this challenge try to create a greybox prototype for an experimental idea you have. For this challenge prevent yourself from using any assets other than basic shapes such as spheres, cubes, and capsules for a 3d game, or squares circles and other polygons for a 2d game.
Till next time, game on!