Below are some gifs of our core gameplay mechanics working for the first time. Since these are the first times a lot of them have evolved since they were taken. What I find interesting about mechanics working the for the first time is that something may work exactly how it’s supposed to technically, but you can tell that it doesn’t feel at all how you thought it would.
Something as simple as putting cake batter into a pan and moving that pan has a lot of moving parts and mechanics that you need to tweak in order to feel just right. Everything also has to fit well with each other too. You should be able to establish a flow that feels good to the player. That’s just a couple of mechanics though, we’ve got a whole game to build..
The dispenser is what we use to dispenser both batter and icing for the player. In this gif the player has chosen to dispense some chocolate batter into the cake pan. We initially had the cake batter not parented to the cake pan like it is in the gif. This caused the player to have to slowly balance it as they were carrying it into the oven. We found this to be really annoying as the physics didn’t work how they would in real life. It felt annoying and frustrating when the batter would fall out. Also batter usually isn’t a solid enough object to just fall out without being poured out..
The oven is what is used to bake the cakes, obviously. There’s a single button that open/close the oven door. The oven would turn on automatically as soon as the oven door shut. If the player left the cake in too long, it would burn and become unusable. The first model of the oven that was done was HUGE due to the fact that we thought we wanted to start off by baking at least 4 cakes at a time.
This is the dispenser dispensing icing for the first time into the icing cup. In this gif you can see the icing appearing on the spatula and with a single touch covering the entire cake in icing.
Getting frosting working was a little more tricky than the other mechanics. Kyle did the programming for it and I believe what we’re doing is a raycast from the tip of the frosting bag down to the frosting ring. There’s 20 pieces of frosting that can be “activated” once the raycast hits the collider. As you can see in the gif, it’s too precise and can be really annoying for the player. This is why you test your mechanics early. You need to find out early if something isn’t working how you thought it would, and what you can do to improve it.
Using the scooping cup, players are able to scoop up toppings and pour them onto their cake.
The upgrade menu is the menu that the user can use to upgrade items in their bakery. We needed to design a menu that was easy to navigate, the least amount of effort for the player, and something simple and not over-complicated. We would have to think about how many items we can show at a time. Would we have to have a paging feature? How small is too small?
The idea for this first sketch was to put all of the upgrade menu items on the counter top. This would allow the player to easily touch and interact with the menu without ever fearing that they would have to reach too far. Once the player had gone through some menus, they would eventually see the 3D objects of what they wanted to upgrade. Basically like a hologram on top of a table. After pitching this idea to Kyle, he gave me feedback suggesting that putting anything where you have to look down can be potentially a poor experience for the user. This would be due to the fact then when you look downwards in VR it can feel like the headset is going to fall off. Another reason was because when you look downwards in the headset, sometimes you are able to see outside light coming in and it makes the experience a lot less immersive. So it was back to the drawing board.
This time it would be the same idea, but on our order board. I quickly made an animation that would bring the order board closer to the player. I also ended up scaling it smaller to ensure the edges were all reachable by the player without having to stretch. The background of the order board would also have to change to something transparent as it felt very intrusive to the player. Having it more transparent would also allow the player to see things they were upgrading (such as the wallpaper) more clearly.
There was still one issue we were having with the upgrade menu layout. Everything felt too small and too far apart. I was afraid that if the elements weren’t far enough apart, then players could accidentally press the wrong buttons. Kyle sent over a solution to all the issues we were having troubles with though, and we haven’t looked back since.
Initially when Kyle showed me his concept I thought to myself “..that’s a lot of iconography… that’s going to take awhile due to how many things we have to include…” BUT THEN I REMEMBERED HOW AWESOME UNITY IS!! So I just took 3D models and slapped a flat unlit white material on it and BAM, looks like an icon with 0 effort.
This menu system was built in a single day though, so throughout some more dev time it’ll probably change more (for the better) and we’ll ensure that the readability and interactions are exactly how we (as players) want them.
The average day for the both of us is dramatically different. I <Trevor> don’t have a day job at this time so I work on the game full time. Kyle on the other hand has a full time job he goes to during the day, and a wife and kid to tend to when he gets home.
Trevor’s Average Day
An average day for me goes somewhat like this. I wake up after 8 hours of sleep. I don’t have a set time that I wake up at because some days I end up working far too late into the night/morning. It’s kind of a weird cycle, some days I’ll be on a normal work schedule of waking up at 7am and then be in bed at a normal time. Other days I’ll end up working until 7am and sleeping during the day. Whenever I wake up, I have an energy drink and some instant oatmeal to start the day.
I’ll put on my headphones and listen to some music while I start development for the day. I either pick up where I left off from the day previous, or I can look at our rough schedule and see what’s still there to be done. Sometimes Kyle and I have messaged each other throughout the night and some emergent tasks have come up that I need to work on instead.
After working for a couple hours and completing a task or two, I’ll go and take a 15 minute shower. The shower is basically my thinking tank where 99% of my good ideas come from. I think there’s something to be said about that though. When you take a moment to stand away from your work to analyze and give your full uninterrupted attention towards something, really cool thought process begin to happen. After I get out of the shower I’ll usually make something to eat and then keep working until my girlfriend Tashia gets home from work around 6pm. I cook some dinner, we sit down at our desks and watch some Netflix together while she tells me about her day. Then I end up tweaking or finishing up things I worked on during the day that I want to submit to git before Kyle starts working. I’ll try and write a blog post at the end of the day before I wind down for the night. Usually end up watching Netflix in bed and falling asleep some time after midnight. Sometimes I can’t sleep though… So I’ll just go back to work and work until I’m tired. Some days that’s only 2am, some days it’s 10am.
Kyle’s Average Day
I work a full-time job as a backend web developer, in addition to having a wife and newborn, so I have to be aggressive with my time scheduling 😉 . My average day starts off doing a bit of research/chatting with Trevor about the day’s goals while I’m in transit to work, bouncing a few ideas off each other during the work day as I find time (sometimes there are 20-30 messages queued up for me when I check Slack), winding down on transit on the way home. After I get home I spend some time with my amazing wife and bouncing bundle of joy. The baby goes down around 8pm and then it’s quiet time for my wife and I until 10 or 11. After she’s gone to sleep I hit the PC and get working. With the chatter of the day, I’m usually pretty keyed into my goal for the evening, I give myself about an hour or so of work before I force myself to go to bed, otherwise I’ll be up all night tweaking and hacking at things. My goal every night is to finish something: that could be re-organizing a menu, finishing a specific player action, or whatever, but I find the key to keeping motivated and happy is to consistently push out small atomic pieces of work, instead of having things constantly in a half-done state. One trick is that only one of us has a Vive right now, so some nights are purely just running through use cases and writing up bugs, but it’s never dull when you’re in VR so it’s a happy chore 🙂 So, my progress is definitely slower than Trevor’s, but I try to pace my coding work so that he never is blocked by me.
We ended up being pretty aggressive with the scope of Batter Up! Initially we just thought we were going to make a super simple baking game, with a progression system, nothing too fancy. We just wanted to learn more about developing for VR and try and get something onto Steam people would enjoy playing. But the thing about scoping a game is it’s SO hard not to over scope… and that’s what we did…. but it wasn’t intentional… we just kept coming up with so many cool ideas and it just snowballed into what it is now. Because of the scope and not wanting to end up in an endless cycle of development hell, we can’t waste a lot of time on tasks.
I can’t spend a week making a single game object look like the most realistic thing you’ve ever seen.. The game would take years to complete with just the two of us working on it. So I end up creating most of the art assets within a single day, and then going back to them later to polish them up. Going back to them later has proven to be really useful though because we end up testing things and then changing our design to make the game better. Also as we both work on the game more and more, we get a better feel of how things should look and feel and we find new ways to make the player have a better experience.
Since Kyle is the only one with the Vive right now, he ends up doing a lot of the testing. Every week I end up dumping a ton of testing work on Kyle while he has tasks he’s already trying to get done. To help though, we have found it super useful to get together and address a list bugs together. Sometimes we luck out and can change some designs a little bit to save us from creating a ton of extra bugs.
Since we’re working in VR, everything has to feel perfect. As soon as something doesn’t look or feel right, the player is immediately removed from the immersion or worse they could feel sick. This also means putting a lot of effort into making this the most bug free cake baking experience possible.
In the end it’s giant balancing act of trying to get everything done in a timely fashion while making it look and feel perfect.
The one thing that is awesome, but can be difficult sometimes is we’re always thinking about the game. All day every day, every hour, every minute. We just want to make the best possible game that we can. We’re constantly communicating and bouncing ideas off each other. Always thinking and asking if that’s the best way to do something, if we can improve it, or if we imagined the design differently. When you have two people who work really well together, this makes all the features and designs in the game 100x better. Everything just gets layered with more and more good ideas and in the end we both get super pumped about it. One thing that I learnt while working with Kyle is that there is no way I could make as amazing of a game by myself as we have made together. Without having that good communication stream of building on top of every idea and every design, everything wouldn’t be nearly as well thought out just from a single brain.
Playing other games that are similar to the one you’re working on is ESSENTIAL to game development. It helps you find things that are designed well that you may want to implement into your game. Or more importantly, you will find things that you don’t like which then gives you the ability to design something better.
For us we found the difficulty curve in VR Diner Duo starts off really easy (which is nice cause you’re just learning the game). It then gets a little bit more difficult and challenging ( which is also perfect because you don’t want the game to feel too easy or else players won’t feel engaged enough). But then…. it jumps from just a little difficult to SUPER DIFFICULT WHAT DO I EVEN DO TO KEEP UP and it just feels like you’re working and loses all the fun. It’s like if you start walking down stairs, then start jogging cause you learn’t the rhythm, and then you trip and fall all the way down into a brick wall. It’s not a good feeling..
When we started thinking about our difficulty curve and the general progression we wanted the player to experience, we initially thought of each cake order having a countdown timer. If the countdown reached 0 then the customer would be mad and leave meaning you failed the order.
Having this kind of design alongside the other systems we were designing made us think about that chaotic hopelessness feeling that we felt in VR Diner Duo*. Taking out the countdown timer means the player doesn’t really have anything driving them to bake cakes faster though. So to encourage the player to bake cakes faster we added a tip modifier to every cake order. What this meant was that the faster the player baked the cake, the bigger the tip they would receive on top of the base amount of money earned for each cake baked. This made players not feel incredibly rushed, and added a more positive experience overall.
Designs change a lot though, from when they are conceived to making their way into the game to internal testing and play tests. We are still thinking about adding a (non visible) timer for each cake, but making it so that cakes don’t fail unless the player has taken 3x the amount of time to bake it than they should have.
* Despite what was said in this post, we actually love VR Diner Duo! It was a huge inspiration in the creation of Batter Up! If you haven’t played it yet then we highly recommend you play it, especially with a friend!!!
The order board is what we use to display to the player the cakes they need to bake.
We knew that text in VR can be risky as it can be difficult to read. Knowing this risk made us aware that whatever we designed for the order board, had to be perfect. As you can see in the screenshot above, we started off with the text being as close to the player possible. This would ensure the readability was the best it could possibly be.
After working on the game more and continuing to design more and more systems, we realized this wasn’t going to work anymore. We felt that the player needed a logical reason for why they were baking these cakes. There wasn’t just some invisible cake lord who spoke to the player telling them to bake these cakes. So instead there would be customers that would come into your bakery and place orders. After they would place an order they would go stand under their order. This meant that we had to move the order board farther away from the player to give room for the customers.
The screenshot above displays just how far we moved the order board away from the player. Even though the order board was farther now, the text in game is actually still crystal clear (thanks to Unity’s “Dynamic Pixels Per Unit” setting on the Canvas Scaler).
After getting the order board fully functional, we started playing around with different fonts. We initially were going for the aesthetics of looking at a recipe, but we felt that it didn’t suit the mood of the game as a whole that we were creating. You can see below the font we ended up choosing (so far)
It’s all still a work in progress so expect to see updates in the future about what we changed and why.
The first moment we realized that we wanted to create a VR baking game, we knew that we wanted something more than what we were seeing on the market. Progression is something that the both of us value in games the most. We knew that it would be a major feature in whatever game we created. We found that a lot of VR games had no real progression besides a couple of levels or an endless wave mode.
Keeping progression in mind, we first had to think about the core gameplay loop we were going to create. The player would be baking cakes, but what does that actually entail?
How to bake a cake (simplified)
Getting batter into a pan
Putting the pan in the oven
Turn on the oven and wait for the cake to be baked
Once the cake is baked, open the oven and set the cake down on the countertop
Put icing on the cake
Put toppings on the cake
Put frosting around the edges of the cake
After outlining the steps above, we began thinking about the space we need in order to complete the actions above. Should we have the player move around in their room? Should we have them only need to stand in one place and pivot around? In our initial prototype, everything was about a single step away from the player in any direction. We thought this would help with immersion in comparison to other games we had played. We were wrong.. It was just super tiresome and it made us not want to play as it became too much effort.
After figuring out the player space we had to figure out when baking a cake, how many machines, tools, and other interactable objects do we need?
Oven – Bakes the batter into cake
Dispenser – Dispenses both batter into a cake pan and icing into an icing cup
Frosting bag – A bag full of frosting that the player can squeeze to frost the edges of the cake
Spatula – A spatula is needed to dip into the icing cup, and place on the cake to apply icing to it
Scooping cup– A container used for scooping toppings up and pouring them onto the cake
Core interactable objects
Cake pan – Holds the cake batter in it. First dispense batter into it from the Dispenser machine, then place in oven to bake the batter into a cake
Scoopable container – Container that contains various types of toppings to top the cake with
Plate – Cake must be placed on a plate in order to complete the cake order
Bell – Used to finalize / send out a cake order
Core non-interactable objects
Order board – Used to display cakes the player needs to bake
Customers – The reason why there’s cake orders on the order board
First draft of some of the basic machines and objects needed to bake a cake
We tackled progression with a system where you’re able to upgrade various items in the bakery. The machines, tools, interactable / non interactable objects, as well as adding extra visual aesthetics.
Players go through a day cycle of running the bakery. As they go through the day customers will come in and order various cakes. The quicker the player bakes the cake the bigger the tip they get. After the day is over the user is shown a tally of all the money they have earned for the day, and then they are taken to an upgrade menu. In this menu the player is able to see the various items they are able to upgrade, the descriptions of what they do and how they’re better, as well as how much they cost.
Going back to earlier in the post where we mentioned that we didn’t want to do just an endless wave mode. We did initially plan to have it as a means of testing various different gameplay elements as well as getting the feeling of flow in the game. If it ended up working well, then we were going to include it in the release as well. We thought that it would be quicker and easier than diving into the kind of story mode that we needed to build as well. It ended up being a bunch of misguided effort though as the time spent fixing bugs and implementing it exactly how we wanted it was becoming a lot of work. It was eating into the time we needed to focus on the actual gameplay mode that we needed to build, so we ended up scrapping it.