SecTech is the world’s premiere manufacturer of cheap and reliable security. You have been selected by our rigorous screening process to become a factory worker at SecTech. To determine if you have what it takes, our top scientists have created a simulation of a workday here at SecTech. can you succeed in the SecTech Employment Trials?
SecTech Employment Trials is a VR game made together with about 8 people during the span of 4 weeks. We worked in Unreal Engine 4 alongside a Oculus Rift headset and motion controls to create this puzzle experience.
Sectech marked our teams first venture into the land of VR, so suffice it to say that we had many new challenges ahead of us. I was primarily responsible for the puzzle and interaction design. In other words, I spent most of the project time with the VR headset on.
Apart from collaborating on the overall game design itself, I was responsible for most of the functionality of the puzzle itself: The security dog robot, and the modules. I created a system that assembles a random puzzle based on a list of modules (the properties of which are themslves randomized, e.g whether they are presolved) which then ties into the system that spawn the scrap parts the player has to solve the puzzle with, ensuring the player always has at least one solution.
The overall game is to repair as many robots as you can in 10 minutes by putting pieces of scrap into modules found on the robot. As mentioned every puzzle except the first three will be fully randomized. The first three are predetermined to spawn in a certain way, like a tutorial of sorts. This makes sure the player becomes familiarized with all the possible modules and what to put in them.
We spent a lot of time during this project trying to design around the possibilities of VR. Much of our conventional gamed design knowledge did not apply here. As an example, things that would quickly become monotone and dreary in a regular game are still fun in VR. Our players (and we ourselves) simply loved the feeling of throwing things around, or just holding the robot and looking it over. Thus our primary goal with the game was to make sure that the player felt immersed and that the things they tried to do actually worked.
Some examples of things we added:
- Breakable coffee cups that the player can throw.
- A wastebin the player can throw things into, receiving a voiceover when they do.
- Spawning new scrap is done by pulling a clotheshanger
- All HUD elements are diegetic
- Notably, the main computer can be moved around in the scene.
- Scrap can be put into modules in any way the player wishes, not just into sockets.
- The central hoverbeam can hold any type of objects.
We found that a lot of things we added weren’t really necessary, or even that they added much gameplay. The important thing was that a VR game doesn’t operate on the same axis as a non-VR game. Seemingly simple actions can be very enjoyable, just because they are in VR. Thus, our focus was to make sure these things felt good.
This of course required a lot of testing. We spent a lot of time making sure the workspace felt properly scaled and positioned. We added a lot of different object for the player to fiddle with, most notably the scrap. We tried to make everything as visceral as possible, and to make sure the controls didn’t feel laggy or imprecise.
Overall, during playtests, this was much appreciated. While the gameplay itself was very basic, most people still enjoyed themselves simply moving things, throwing things, listen to spatial audio, or in general just goofing around.
This was a core aspect of the game design: we tried to not take ourselves too seriously. We owned the fact that we were VR rookies and designed a game that was intentionally a little rough around the edges. To be more precise, we set our game in a low-budget security firm where you repair robots using potato batteries and forks. We designed our HUD computer as an old CRT screen and we put posters and decorations into the game to reinforce the feeling your working in a crapsack low budget factory.
Not only did this aid the experiece, it also made players overlook some flaws in the gameplay itself. if something freaks out, or clips through a table or whtever (as things tended to do in VR) people found it funny or endearing instead of frustrating. Nevertheless, we never abandoned conventional game design altogether. We still made sure puzzles were solvable, that the difficulty wasn’t too hard, that information was accessible, that players knew how to interact with the game and that they couldn’t get stuck incase something weird happened.
Another large part of the design was to work in failure as a natural part of the game world. We noticed, as mentioned, that players loved simply throwing things around and goofing around with trying to fit 5 calculators into the security dog. This often meant players lost track of the game objective, or they simply weren’t fast enough to hit the quota. This was why we decided to market the game as a “work trial”. In other words, you weren’t necessarily expected to succeed, but you certainly could if you did well. And you could always just try again.
In summary, SecTech was a wonderful learning experience. Although often filled with heated discussion of what we wanted the game to be, many issues that plagued the devvelopment, and being in unfamiliar waters, we still delivered an enjoyable VR expeirence. I don’t think any other project to date has forced me to challenge how I think about design as much as this project. Most importantly, I’ve learned to appreciate the non-obvious things players do in games that they find fun. One should lose sight of the small details.
Oscar Wirz 