Overcooked VR remake - Proof of concept
Another small project for masters degree. This time we had to design a VR experience, and of course this was a great opportunity to create a game! Discussed with my teammate what the topic could be, and after a while we decided to do a VR remake of Overcooked.
For those of you who don't know overcooked, here's a sample gameplay video:
Overcooked is meant to play in local coop mode, and has some very simple mechanics. But because of level design and the nature of cooperation, everything bursts into chaos and it's so much fun!
For our VR experience we wanted to recreate part of the main cooking mechanics, but of course we wouldn't implement any multiplayer features because of time constraints (just a few weeks, and not full time).
Dev challenges
The pot
Pot was involved in multiple mechanics as it's one of the central parts of the game. User needs to:
- Grab the pot by its handles.
- Put ingredients in it.
- Put it on the stove and detect an active fire to trigger the cooking process.
Many colliders were involved in the implementation of these features. On top of the colliders for normal collision with other objects, this is how the setup looked with all the necessary triggers that support these features I just mentioned:
Handles were necessary for detecting when the user grabbed the pot, this was integrated with the rest of the Oculus VR tools for Unity.
The collider in the middle detects ingredients falling into the pot, and the one under it checks whether the pot is on the stove and an active fire.
A nice set of layers were used in order to avoid unwanted collision detection. Pretty interesting scenario and use of colliders with this pot!
The fires
I thought this would be an easy one, but I had to spend hours trying to make it work as expected. The fire particles and triggers for detecting the pots worked from the beginning, but turning the stove knobs was a nightmare.
Lots of issues showed up when I tried to constrain the knob position and rotations a couple of axis. The Oculus tools would just grab the knob and move it around, and adding the constraints didn't just work as expected. Some custom grabbing logic had to be implemented so that the user could turn the knobs without pulling them off or making them turn in weird directions :D
The food crates
This is an interesting one. Using the Oculus tools for grabbing an object is pretty straight forward, but being able to instantiate a new ingredient when a user grabbed one from the box was a completely different story.
Creating the grab logic from scratch was too much effort and risk given the schedule, so I started reading the existing Oculus logic for grabbing objects and see what I could do with it. Fortunately I was able to extend the classes for the grabber and grabbables, and override the methods where the logic needed to change.
The first tests went pretty badly. The base logic operated on the current Transform component, but I needed the originally grabbed object (the crate) to be kept separately from the newly instantiated object. So I had to create a new reference to the grabbed object in order to have that new level of indirection. When player grabbed something, it would be the object itself when using the base implementation, or a newly instantiated object when using my new copy grabbable extension.
After some hours of testing and debugging, it was working and stable. I had lots of issues with colliders and the sequence in which stuff was enabled/disabled, created, etc. The final code looks hacky, but I added lots of comments to explain why I had to disable a collider or whatever in a weird location of the code.
Serving plates
Plates needed to collide with other objects, and be able to hold the food, that's why we used these two colliders for this purpose:
But how could I make the user transfer the pot content to a plate? A simple collision detection wouldn't feel good, I wanted the user to make the natural moves of tilting a pot and making the contents fall on the plate. On the other hand, making this experience too real might go in the wrong direction for a game that's meant to be casual.
So the intermediate solution was to use a little vector math. Using the dot product of the up vectors from the pot and plate, we could know if the orientations were good enough to interpret the collision detection as a food transfer. After tweaking the angle threshold and testing, the result was pretty good and felt so natural!
This logic was also used for the garbage bin, throwing something away is necessary in case you get a recipe wrong, and we had to let the user discard their progress.
Recipes and deliveryThis game is nothing without the recipes! This implied restrictions all around. No container could hold more than 3 ingredients, the ingredients should be copied from containers, or discarded in case of the garbage bin.
Recipes were defined in data, and our recipe manager would emit new orders randomly from time to time.
When a plate was delivered, I checked for a match in the ingredients, and from all the orders that matched the ingredients, marked the one with less remaining time as the one fulfilled.
Final result:
We're really happy with the end result. The game mechanics feel nice and you feel the urge like in the real game. It would have been awesome to have artists for 3D modelling and everything, improving the visuals of this prototype would totally change the experience for good. A multiplayer cooking game could be implemented some day!
Great news, here's the code if you wanna check it!https://github.com/gpiffaretti/ovrcooked
Comments
Post a Comment