The food cannon is a game mechanic we added where once a day (a day being 6 minutes of real time) you have to go on lunch break. During this break we have implemented various minigames for the player to experience to break up the gameplay a bit. As you can see below, there’s a cannon shooting hotdogs at you. Your goal is to grab them and eat as many as you can in order to increase your tip modifier.
The model of the food cannon was based off of those elementary/high school TV carts that your teacher would roll in whenever there was a video to be watched. Every kid looked forward to that moment. When the giant 500lbs 25″ TV rolled through the door and the teacher would play one of those really old educational VHS tapes.
While designing the progression system, we had to think about how exactly we were going to make each level of an item upgrade feel. There had to be more than just a visual upgrade. Each upgrade should feel more efficient, more fun, as well as look prettier.
This is where the flamethrower comes in. The flamethrower is one of the upgrade levels of the oven. We thought it should feel more efficient than taking the time to put the batter into the oven. It should feel a lot more fun considering guns feel pretty awesome in VR. Last but not least, it should look badass cause it’s a freaking flamethrower.
I find it handy sometimes to draw what I want to model before I 3D model it. Whenever I’m creating an art asset, I NEED to look at references. It helps with visualizing what I want the final version of my model to look like. It also helps me find ideas that I really like and want to include in my model.
So this version of the flamethrower made it all the way into game before I realized one major flaw….If the player uses the trigger button to pick up the object, and they’re holding that trigger button to keep that object in their hand…How are they going to “shoot” the gun… Both of us HATE when VR games use the Vive’s grip buttons to pick up items, so it was back to the drawing board to design a better functioning flamethrower.
The solution was easy, I just needed to add a push button on the flamethrower (and any other gun type object we design) to replace the pulling of a trigger. It was a really silly oversight.. But sometimes I guess I imagine so hard in the back of my head exactly how something will/should look that I forget to question how it’s going to work exactly.
So this is what the flamethrower looks like today so far. The texture/materials aren’t final at all. Nothing is ever really final until we ship.. This design should hopefully feel intuitive enough to the player that they press on the pad on the Vive controller instead of pulling the trigger in order to shoot. But that’s something we should be able to figure out with some quick play testing.
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.