SAN FRANCISCO—Developing virtual reality games requires a different perspective from screen-based video games, because everything in VR is seen through the eyes of the player; there’s no buffer between those eyes and the screen.
From that point of view, the whole world becomes the game, because you can’t look away. Add realistic head tracking and, in some cases, motion control that simulates the use of your own hands, and you have an immersive experience that must be carefully built to be accessible and functional to the user.
Shawn Patton, game designer at Schell Games, has a clever solution for designing environments and interactive objects before even touching a computer: brownboxing. Patton uses cardboard to put together different elements of a VR game, mocking up in reality the sort of obstacles and tools you want the player to use virtually in the game itself.
The term is a play on whiteboxing, the process of using simple and often untextured objects in a virtual space to design environments and puzzles before implementing finished in-game assets. Instead of a fully built vault with fully programmed guards, a whitebox demo uses default assets, ugly environmental textures, and little if any animation to figure out where everything should be placed and how the different parts of the game can mesh together.
Since VR games are fundamentally based from the user’s own perspective, real-life whiteboxing using physical objects like cardboard boxes allows rapid design changes and fixes. Hence, brownboxing.
“The fact that in VR the world is all around you, allows you to build the environment with items like chairs and desks and cardboard, and let players interact with it,” Patton said here at the Game Developers Conference. “Since VR interactions are 1:1, it turns out the best analog to VR is AR.”
Patton showed off some brownboxed versions of puzzles in I Expect You to Die, one of Schell Games’ major VR games. It’s a first-person puzzle/adventure game in the vein of escape rooms, based on classic spy movies. The player is given a mission and placed in an environment where a variety of puzzles need to be completed to accomplish that mission. For example, one mission involves escaping a locked car in an airplane by figuring out how to pry open a compartment in the dashboard, finding a way to protect yourself from the poison gas outside of the car, and using the car’s built-in cannon to safely shoot out of the belly of the plane because the car has a parachute.
In development, Schell Games brownboxed some of the game’s missions and puzzles. They built a telephone by putting lights and knobs on a cardboard box, then placing a telephone handset on top of it. They mocked up a water pump that needed to be repaired by writing “Water Pump” on another cardboard box and filling it with bits of hardware that needed to be combined by the tester. They effectively created the environments where some of the game’s missions would take place, in their own offices.
Brownboxing is full of advantages when designing a game. Obviously the game itself still needs to be programmed and go through the traditional development process, but brownbox demos and playtesting can identify potential problems and produce fixes and improvements without repeated code revisions and recompiling.
If you want to move a desk in a whitebox demo, you need a developer to change its coordinates in the game’s code. If you want to move a desk in a brownbox demo, you pick up the cardboard box marked “Desk” and put it down somewhere else. If your game depends on the player figuring out which nearby objects can be used to solve a problem, brownboxing can rapidly determine the best way to highlight those objects so the player gets on the right track.
According to Patton, two of five missions in I Expect You to Die were brownboxed. Those two missions required 23 percent less staff weeks of development to implement, saving Schell Games a good amount of money.
Certain game mechanics can require some forethought when brownboxing, in order to make those mechanics translate to the tester. I Expect You to Die features a telekinetic power that lets the player retrieve and manipulate objects that are far away from their stationary perspective. To make this clear in brownbox demos, Schell Games gave testers a laser pointer and relied on the moderator to physically pick up and move distant objects.
Brownboxing isn’t a perfect process, and certain aspects can be difficult to convey. Telekinesis by having a developer carry over an object is one thing, but combat mechanics with a gun or magic powers can be something entirely different (I’m quite partial to Nerf guns as a solution).
Patton also warns about making sure even ordinary elements are clear to testers, and that false results from varying levels of polish on your brownboxed elements are a risk. Since you’re putting your demo together with cardboard, hot glue (not duct tape; Patton warns that it isn’t nearly as resilient for brownboxing, especially when exposed to sunlight), and various pieces of junk, you need to keep in mind just what the junk is supposed to represent and how it will look in the game. If your puzzle requires unscrewing a vent, clearly indicating that those aluminum foil circles glued to the cardboard flap marked “vent” mean it’s locked until you can find a screwdriver is a necessary layer of abstraction, considering the level of resources used to build the demo.
According to Patton, a brownbox demo should be put together in no more than two days; a day of designing and planning, and a day of construction. The designing and planning step requires finding a suitable location for the demo, determining the different elements of the game you need to place in that location, like furniture and tools, and writing a script for the developers to use when walking testers through the demo. The construction phase requires a lot of cardboard, hot glue, thick markers, and any scattered objects, pieces of junk, toys, or anything else that will help you make a real version of the object you want to build in VR.
Once your brownbox demo is assembled, you need to bring in testers and prepare those overseeing the demo. Since there’s no game engine (that we’re currently aware of), testing needs to be actively managed by a developer who serves as the game’s dungeon master, in tabletop role-playing game terms. The developer explains all of the mechanics available to the player, gives them a goal, and clarifies how the environmental objects and tools in the brownbox can be used.
“The role you play as brownbox moderator is half dungeon master and half improv actor,” Patton said. “You need to know when and how to present your information. When to describe more detail, when to hold your tongue and let things play out in real time.”
Feedback Is Key
Through this entire process, Patton emphasized the importance of taking notes. Feedback from testers can pin down big design problems early, which can then be rapidly fixed and tested again in the brownbox phase before coding begins. He highlighted four specific questions he determined to be vital for productive brownbox testing:
- What was the most frustrating moment or interaction?
- What was your favorite moment or interaction?
- Was there anything you wanted to do that you couldn’t?
- If you had a magic wand to wave, and you could change, add, or remove anything from the experience, what would it be?
Patton emphasized that you can come up with more specific ones for your game, though you need to be careful not to overwhelm the tester. A fifth question he used when brownboxing I Expect You to Die? “When did you feel most clever?”
Patton’s full presentation on brownboxing is available on his website in PDF slideshow format. It goes over the full process, and highlights what is necessary to implement it and concerns that should be kept in mind.
Brownboxing is a simple, low-fi way to design and test VR games. I’ll pitching brownboxing to my editors in PCMag Labs. And we don’t even develop games. I just want a rad box fort.