Food Fight is a VR game currently in early release for Oculus Rift, with planned versions on Vive & Playstation VR coming in the future. As the name would suggest, the game is a virtual reality food fight. A player is presented with a variety of choices and can pick which foods to eat themselves or which foods to throw at their opponent. Making healthy eating decisions will lead to power-ups and ultimate victory!
Our goal for the gameplay is to create a fun system that can use the ‘sandbox physics’ that successful VR games have demonstrated as a special feature of the genre, and then shape that gameplay to reward behavior that will have a “Real Reality” impact on their health. In the game-play, one or more Food Goblins will begin throwing food at the player. If the player can’t deflect or catch the food thrown their way, the food will splatter all over their visor.
The Issue: Catching in VR
In our play-testing, we often noticed that players who were new to VR took a while to learn the timing behind how to catch food that was thrown at them by our Food Goblin. Every VR game needs to account that it might be one of the first times the user has ever tried VR, and we wanted our game to be as accessible as possible to players at every level.
For the easier levels, we decided to give the players their own supply of food to throw or eat for power-ups. Initially, we just took the same generator for our power-ups and changed it slightly to allow it to generate Food Game Objects instead. We had also discussed giving the player a bit more ‘cover’ to avoid food that is thrown their way by the Food Goblin. It was through both of these that we arrived at the solution of a Conveyor Belt.
The Process: From Concept through Prototype
Our 3D artist worked up designs for a pipe from the ceiling, sections of a conveyor belt, and a trash can. We started out just arranging these in the scene. A parent object helps keep the individual sections neatly organized. The conveyor sections are all set along the Z-axis with the same X and Y positions. The “Conveyor” container is just an empty game object that allows them to be rotated and positioned altogether.
After getting them sized and positioned in our test scene, we next needed a way to work out the actual conveyor mechanics. There are potentially a lot of ways we could do this. We could attach a script to each item while it’s on the conveyor to move it along the Z axis, or another path that we give it. That would need some extra logic on the item to decide when it should be moving on the conveyor, when it’s been picked up, and when it should fall off. This could potentially be prone to a lot of bugs since we want our food items to be able to do a lot of different actions in the game already.
Another possibility might be to have the conveyor itself handle the logic, and decide what items are on it. This was definitely a better method — only the conveyor belt needs to ‘think’ about what to do. Unity’s Collider components can already be set to work as triggers for scripts, so we could set something up to move all items on the trigger over a small bit on the Z axis (or any other direction, or even a more complex path) each frame they were inside the trigger.
But this also has its own disadvantages. The conveyor would always need to switch items back and forth from “kinematic”, which means “this object ignores the physics engine and only scripts tell it when to move or rotate” or it would need to carefully nudge items along with the physics engine’s Add Force or Move Position function. Collider triggers and colliders themselves can sometimes get skipped if an object is moved fast enough through them, or if the user’s processor gets slowed down with other tasks.
We had to find a solution that would work for our purposes. Next week, we’ll delve into exactly which approach we took and how it helped to improve our overall game development as a result.