• entry
1
0
• views
577

# VR Puppy Chef Academy Devlog #01: Where VR, cooking, and education overlap

1304 views

Hello, and welcome to Puppy Chef Academy!

Puppy Chef Academy is a Virtual Reality cooking experience designed to help you learn how to cook without the stress and mess of a real kitchen. The game blends the simple controls of Job Simulator with the innovative gameplay of Cooking Mama, with a splash of visual novel storytelling. Throughout your adventure you’ll cook tasty recipes, learn about cooking, and even make some friends along the way!

Today I'm going to talk a little about Puppy Chef Academy as not only a game, but how it helps players learn the one skill that everyone wants: Cooking!

The idea for Puppy Chef Academy stemmed from my dissatisfaction with Job Simulator's "cooking" segment. While the control scheme was excellent and held so much potential, unfortunately it didn't satisfy my itch to make actual recipes and felt more like playing with an adult-sized toy kitchen set. I decided to make my own VR cooking game, and thus, Puppy Chef Academy came to be!

My main goal for the project was to help less culinary-inclined players overcome their fear of the kitchen. You know who I'm talking about, the ones who've never chopped an onion, boiled water and burned it, and swore never to cook anything again. What those people don't realize is that anyone can cook! Like anything, it just takes time and practice, which unfortunately means you'll inevitably have to clean eggs off a stove top, throw away burnt pasta, and languish in the utter defeat that is seeing your loved one smile through their teeth to tell you your Penne Flambe was good while scraping the rest off into the nearest potted plant when you aren't looking. Puppy Chef Academy is designed to help you feel the accomplishment of gaining culinary skills, minus the risk of failure.

The beauty of VR as a medium is that skills you learn in VR carry over into real life, and vice-versa. Surgeons are looking into VR as a training tool to perform life-or-death operations. One of Owlchemy's earlier videos showed one of their team members happily juggling in VR just like he does in real-life. It's incredible, because when the headset is strapped to your face, it truly does become your reality, if only for a brief period of time. Fostering a safe environment to experiment with a skill without the risk of failure is what Puppy Chef Academy aims to do, and how it strives to accomplish that is explained further below:

Firstly, the techniques. As far as I know, no one has mentioned anything about the gravity feeling strange in Puppy Chef Academy, which is great. It means that I've done my job correctly. What players don't realize is that the world in Puppy Chef Academy seems to be a little smaller than ours, resulting in a lower gravitational pull. I'm joking, the gravity is set slightly lower than "real" physics. But why is that? Isn't the point of learning to cook in VR supposed to be a "realistic" experience?

No! The slightly lower gravity is a very deliberate choice. The reason being is that the "realism" isn't as important as learning the movements and techniques. Did your elementary school have "juggling days" where you and 20 other kids were corralled into the gym to learn how to juggle scarves? No one juggles scarves professionally, that's not what juggling scarves is about (and if you do juggle scarves professionally, thank you for making me feel better about my career choices), it's about learning the movements that transfer over to juggling other things. Juggle a scarf, juggle two scarves, three, then juggle one ball, two balls, three, so on and so forth. It's about technique, which for the most part, the lowered gravity (and higher air friction, in the case of scarves) helps you learn. Like juggling scarves, Puppy Chef Academy helps you build confidence in your cooking techniques.

The day I flipped an egg through the air and landed it in the pan perfectly was the day I realized I had made something truly unique, as up until that point I had never flipped an egg like that before. It wasn't until I reached several hundreds of hours playtesting Puppy Chef Academy and trying to nail the pan flipping technique in VR (juggling the metaphorical scarf) that I finally felt the confidence to do it in real life. I didn't even think about it, because subconsciously I had flipped hundreds of omelettes and eggs already! When you hear about the untapped potential of VR that so many devs, users, and analysts talk about when they discuss VR’s future as a medium, that’s what they’re talking about. And by that, I mean the skill learning, not the egg flipping (though egg flipping is pretty cool though, at least it impresses the missus!).

So we covered how VR as a medium can help build the player’s confidence to learn new skills. Unfortunately, that alone isn’t enough to keep players engaged. What else can we cram into each recipe to make players feel excited to learn about cooking?

Simple. Story, and history. From recipe to recipe, a story unfolds that bridges the recipes together and keeps players on the edge of their seat, excited to see what happens after each episode. Between steps, the characters will give an abridged summary of the dish’s history; sure, you may have ordered miso soup at your favorite Chinese restaurant before, but did you know that miso soup used to be a luxury consumed only by nobles? In Puppy Chef Academy, you learn interesting facts like that about every recipe you make. The combination of story and history tying together interactive segments make for an experience that is not only engaging, but also educational (without the boring homework assignments!). What better way to learn than to have fun while you do it, right?

What I’m trying to get at here is that by interweaving gameplay, story, and history, Puppy Chef Academy helps players learn how to cook without even realizing it! While there may be some who don’t find the idea of visual novels, culinary history, or even VR at all appealing, I believe Puppy Chef Academy has hit the right balance of the three to bring something truly unique to the medium; both as an educational experience, and as a game. With any luck, hopefully future home chefs will pick up the game and feel the same way about it too! And of course, I'll add an option to play without the story.

Anyway, thank you for taking the time to read the first devlog for Puppy Chef Academy. If you'd like to find out more about the game, feel free to take a look at the links for the game below!

Until next time,

- Tom

Discordhttps://discord.gg/tJ6aZdV

There are no comments to display.

## Create an account

Register a new account

• ### Similar Content

• Concept for Delayed Shots in a Fast Paced Shooter

The base for this concept is that with each click or trigger pull there is a X-second delay before the gun would actually fire. This would make it alot more difficult to time shots and could create unique design elements that would cater to this delay. (i.e sharp corners and hallways where it would be hard to time when to click in such a tight enclosed space). Ive had this concept for a minute and i know we could code it to work but my main concern with this is, would it be a good design choice?
• By mujina
What could be a way of avoiding using inheritance and virtual methods when designing components for an entity-component-system?
I'll be more specific about my design issue:
I currently have different classes for different kinds of colliders (let's say, CircleCollider and LineCollider).
My system that checks for collisions and updates the positions and/or velocities of my entities should be something like:
for entity_i in alive_entities { collider_i = get_collider_of_entity(entity_i) // components of same kind are stored contiguously in separate arrays transform_i = get_transform_of_entity(entity_i) for entity_j in alive_entities { collider_j = get_collider_of_entity(entity_j) transform_j = get_transform_of_entity(entity_j) if check_collision(collider_i, collider_j) { update(transform_i) update(transform_j) } } } my problem is that I don't have a generic get_collider_of_entity function, but rather a function get_circle_collider_of_entity and a separate one get_line_collider_of_entity, and so on. (This happens because under the hood I am keeping a mapping (entity_id -> [transform_id, sprite_id, circle_collider_id, line_collider_id, ...]) that tells me whether an entity is using certain kinds of components and which are the indices of those components in the arrays containing the actual components instances. As you can see, each component class is corresponding to a unique index, namely the index position of the array of the mapping described above. For example, transforms are 0, sprites are 1, circle colliders are 2, line colliders are 3, and so on.)
I am in need to write a system as the one in the snippet above. I can write several overloaded check_collision functions that implement the logic for collision detection between different kinds of geometric primitives, but my problem is that I am not sure how to obtain a generic get_collider_of_entity function. I would need something that would get me the collider of an entity, regardless of whether the entity has a circle collider, a line collider, a square collider, etc.
One solution could be to write a function that checks whether in my internal entity_id -> [components_ids] mapping a certain entity has a collider at any of the indices that correspond to colliders. For example, say that the indices related to the collider classes are indices 10 to 20, then my function would do
get_collider_of_entity (entity_id) { for comp_type_id in 10..20{ if mapping[entity_id][comp_type_id] not null { return components_arrays[comp_type_id][entity_id] } } return null } This could turn out to be pretty slow, since I have to do a small search for every collider of every entity. Also, it may not be straightforward to handle returned types here. (I'm working with C++, and the first solution - that is not involving inheritance in any way - would be returning a std::variant<CircleCollider, LineCollider, ... all kinds of components>, since I would need to return something that could be of different types).
Another solution could be having some inheritance among components, e.g. all specific component classes inherit from a base Collider, and overrride some virtual collide_with(const Collider& other) method. Then I would redesign my mapping to probably reserve just one index for colliders, and then I would actual colliders in a polymorphic array of pointers to colliders, instead of having a separate array for CircleColliders, another for LineColliders, and so on. But this would destroy any attempt to be cache-friendly in my design, wouldn't it? That's why I am looking for alternatives.
A third alternative would be to just have a single, only, Collider class. That would internally store the "actual type" ( aka what kind of collider it is ) with dynamic information (like an enum ColliderType). Then I would have all colliders have all members needed by any kind of colliders, and specific collision detection functions which I can dispatch dynamically that only use some of that data. (Practical example: a "Collider" would have a radius, and the coordinate for 2 points, and in case its type was "circle" it would only make use of the radius and of one of the 2 points - used as the center -, while if it was a "segment" it would only make use of the 2 points). My gut feeling is that this would bloat all colliders, and, even if the bloat could be reduced - using unions in some smart way for storing members? I wouldn't know how -, then still the design would be pretty brittle.
I'm clueless and open for ideas and advice! How do you handle in general situations in which you have components that can be naturally modeled as subclasses of a more generic component class? Inheritance? Smart hacks with variants, templates, macros, custom indexing? Dynamic "internal" type?