Trickshots: A VR Arcade Sports Game
Development Process Deep-dive
This page covers my approach to:
Early project planning.
Prototyping. Lots and lots of prototyping.
Pivoting from Multiplayer to Single player.
Finding the fun.
Finishing and publishing the game.
Project Goals
I wanted to make an extremely accessible VR arcade sports game.
This was probably the biggest objective for the entire project. I have designed a lot of sports games, and to me the biggest barrier of entry is accessibility. A lot of sports games rely on the user’s preconceived notions of how that particular sport works and how the sport is played. For some sports games, that can be extremely overwhelming. I played football in college and yet trying to pick out the best defensive package to run on a 3rd and 5 from my opponents 32 yard line with 3:43 left in the 3rd quarter just was too much.
Instead of trying to recreate a live sporting event, I wanted to recreate how a kid feels when playing in their backyard. Instead of having a massive crowd of people, jumbotrons, sports tickers, play UI or commentary - why not let the user just enjoy the sport itself?
I wanted to make everything is diegetic as possible. VR is extremely immersive, but seeing menus in VR really takes you out of the experience. So I didn’t want a single menu in the entire game. If the user needs to use UI, it needed to be grounded in the world somehow. Sports games are 50% menus, and that’s okay! I just wanted to try and diverge this game away from that and really focus on the fun.
Fun over everything else
I wanted the player to have fun instantly, and by instantly, within the first minute. This wasn’t going to be easy, but it was the most fun part of the process.
0 attributes. Having this as a design constraint really helped solidify how equipment and balls would work. If one bat hit further than another, then why would a user even pick up the first bat? Then would you have to design wasted content around a bat that you briefly use? If all bats hit the same, the the user can use whatever bat they like with every course - and that seemed way better to me (on paper)
Simple to learn, tough to master
As a massive fan of Rocket League, I had always wanted to make a game that anyone can pick up and play, but it takes a long time to master. This meant simple controls that had dynamic results. In Rocket League, (not to simplify it too much), you are a box that hits a ball - but that ball can go anywhere, based on how you are hitting it. So I wanted to do the same thing, but with a bat and a ball.
If something couldn’t be performed over and over again with the same results, it was booted. If you couldn’t reliably predict where a ball was going to go, then whatever mechanic that was driving that go the back seat.
Where to start?
The initial idea for the project, and well into it’s development, was to create a “Sandlot Sports Environment” where kids could go play multiplayer games together. But you have to start somewhere right? Here was my plan of attack:
Get a basic baseball mechanic working
Get 2 users in the game together
Get 2 users in a game together hitting the same ball
Build out other sports mechanics
???
Profit!
Needless to say, the initial plan of attack diverged a lot from it’s original plan - but man I learned a lot. As the project went along, there were a lot of new challenges and new ways to think about planning - which I took in full stride.
Below is the first video of the first prototype I made - A box shooting a ball, that could be hit with a bat.
Prototyping prototyping and more prototyping
Backyard and other sports prototype
After the initial basic prototype was done, I wanted to build out a little backyard environment so I could start to see what the world would be like.
I also needed to make a fence “homerun zone” that the user could hit a ball over for a homerun to count.
After a basic backyard was made, I started to see what other sports I could put in the backyard that used the same “grabbing and throwing” mechanics that were including with the basic XR package.
This led to “basketball” and “cornhole” and trying other sports.
Once I had some of these basics in, I decided to start exploring other game mechanics, like golf and hockey.
Both were not the easiest to work with, since the collider of the stick would prevent the club some swinging smoothly BUT it did teach me how to create a ball spawner.
The first sandlot prototype
The original idea of the game was to make a “sandlot” multiplayer environment that kids could play in. Each user would be able to have their own backyard to put games and decorations in, while being able to visit their friend’s backyard in their neighborhood. The sandlot would be massive, while the backyards would be smaller - users could build games together in the sandlot, while building their own games in t heir own backyard.
I started off by making an extremely large sandlot, and then populated the space around them with 16 houses. I wanted to see what it felt like in VR, and it actually felt great! Not too big that you didn’t want to cross the sandlot to go to your friends house, but not too small that the area felt cramped.
I added a lot of trees to really mask the emptiness behind the houses, and also added some textures to the ground to create and baseball field in the corner. This really was a huge step and it started to feel like an actual sandlot environment.
Pitching different balls & neighbor houses prototype
This was one of the “ah ha” moments.
I decided to put a soccer ball and basketball in the pitching machine, instead of the baseball.
I also tweaked its physics properties to make it go extremely far, and boy was this fun.
There was something extremely cool and exciting about seeing a ball go so far, so I put in some neighborhood houses to really recreate being a backyard.
Different sports prototypes
After the sandlot has a nice feel, I wanted to see what mini-games felt good both in the sandlot area and in a backyard.
I added a bunch of crates stacked on top of each other to see if it felt good to knock them down, and it did!
I then tried to make hockey, and it just did not feel right. I would have needed to make the collider physics layer not interact with the ground and then animate the stick to move above the ground layer - and for now that was not in the cards.
Tennis was next - and that was great. I added a pitching machine to pitch tennis ball so I could hit them over the net and it worked out pretty well!
Sportsballs!
I had a crazy idea that I wanted to test - what if you could throw a ball and an object would appear where it landed. Kinda like a combo between a poke-ball and capsule from Dragon Ball. So I started testing it out, and it was really neat! I thought it would be really cool if kids could collect sportsballs, store them in their backpack and then take them out to show their friends while finally activating them by throwing them on the ground.
Essentially you could have 1 item or as many as you wanted contained with 1 sportsball. I thought it would be cool if the user could could customize what was in their sportsball and even get “rare” sportsballs from a giant sportsball gacha machine.
I also added in the ability for the user to “collect” equipment by throwing an empty sportsball at an object. This would be the way for the user to store things quickly, without going into a menu.
All in all, the sportsballs idea was so strong that I started to pivot the future of the game around them. It was, to me, the most accessible and diegetic way for a user to create and customize their backyard.
Backpack and ball selector
Another perk of getting HVR was that it came with a backpack! You could grab any item in the game, grab your backpack and drop it in. Then you could pull it out in the same fashion. I ultimately didn’t end up using this, but it was a great prototype.
The ball selector was a HUGE part of prototyping. I wanted the user to be able to switch between different balls with different physics properties to plau different games.
Once I had both of those working pretty well I wanted to make enough bats to fit in the backpack to see what it was like to pull out each one and play around with different balls in the pitching machine.
This was quite the learning time, as I started to add different physics materials to the balls and bats
I also added the ability to switch between the pitching machine and a basketball goal, so you could switch between sports really easily.
Mini-game prototypes
Now it was time to make some mini-game prototypes and find some fun. I had a pretty good mini-game template made after I created the first game “3 Point Shootout” and then used that template for the others. It was a great way to re-use elements of the game that each game shared like UI, scoring, sound, start/end elements and other things.
I wanted to make a game with each of the pieces of equipment that felt good at the time: baseball, tennis/pickleball/basketball/bow & arrow. I also wanted to see what it would be like to throw a zombie in the game.
This was an incredible learning process, as I was understanding how to make modular games and game logic with each mini-game prototype I made. At this time, I was still searching for the fun.
Making sure the game passes all of the VRCs
Meta has a decent amount of VRCs, but as I was developing the game I tried to make sure I was staying in line with each of them.
I have worked on VR titles in the past, so I knew about most of them but the one I was most focused on was the performance VRC. It states “The app displays graphics in the headset at the requested refresh rate of the display. Interactive applications must use a refresh of 72 hertz (Quest 1 + Quest 2), 80 hertz or 90 hertz (Quest 2). Media applications can target 60 hertz.”
When I checked the performance of the game, it was incredible on Quest 3, but was dipping to 60ish FPS on the Quest 2 in certain areas. I tried lowering the overall render scale of the game down to .7 instead of the 1.0 I had been running on, and the game just didn’t look the same. On the quest 3, you can see all of the houses and police station with crystal clear graphics and it really immerses you in the game. I didn’t want to take that away, so I decided to cut the Quest 2 version. I know there are 20 million Quest 2 users, but I wanted to make sure the game was true to it’s form.
Submitting the game
I have heard horror stories about submitting games through the meta store, and to my surprise it was much easier than I had heard.
I made one final check for all of the marketing assets, the build itself, all of the VRCs and hit the the submit button at 11:30PM.
I woke up at 8:15 the next morning and it was already accepted!
I had accidentally checked the “early access” button, but with a quick re-submission to fix that, it was approved within minutes
Future plans of the game
At the time of writing this, the game has been out for only a couple of days. I wanted to write this blog with the project as fresh on my mind as possible.
Once I start getting feedback from users, I am extremely excited to get back into the game and add more content for them.
I really want to make more courses, and plan on making at least 2 more!
Along with more courses, I will definitely be making more bats.
But for now, it’s time for a nap.
Voice recognition prototyping
After working at multiple sports video game companies, I had always wanted to utilize the microphone more when it came to getting and giving feedback in the game.
At Status Pro, I helped design a prototype where the user could say “hike” in the Meta Headset and the ball would be hiked. I had much bigger plans for what we could do with that, so I wanted to see if I could put those ideas into this game.
I started off by checking out which voice detection toolset would be best for the game. I wanted the users to be able to give a command, the game understands that command, and then something happens. For example, the user could say “I want to play home run derby, with a green bat and tall fences.” To do this, I would need more than voice recognition - I would need AI to help parse the command and much more.
I got wit.ai working within the game, but after many many many hours of debugging - I couldn’t get the game to load without a 2 minute startup. So I ditched the AI part and just started to use the dictation part of wit.ai while also using the Meta Voice SDK.
The main goal was to make to make the more accessible by allowing the user to use voice commands instead of going to a menu.
Animals
I love animals so I wanted to make some voice commands that the user could say that would trigger animations in an animation tree.
Both the dog and the cat had their own voice command lines and I created a lot of audio snippits for things that they were doing.
Equipment
Leaning into the accessibility design, I created a way for the user to spawn all of the equipment they had stored in their backyard - bats, balls, pitching machines, etc
This was all just making the objects enable and disable, but in the future I could really streamline the process.
I also hooked up the pitching machine to voice commands so the user could say “pitch me a _____” and the pitching machine would pitch that type of ball. This was an extremely accessible way to be able to play the game.
Skyboxes with audio
I wanted to see what it would be like to play the game at different parts of the day, so I created a Skybox Changer that would change the skybox/lighting/audio based on what command you gave it.
I also made it so that the videos played by the video board, when home runs were hit, were changed with every environment the user went to
This turned out to be an extremely cool way to set a different mood for the user. If you wanted to just chill out and hit homeruns without the video board going off - go to the “night” mode, or if you wanted to see what it’s like to hit homers in space - go to the “space” mode.
Pickle-ball Panic
The idea was super simple. Grab a racket and hit the ball back onto the opponents side. The catch was that the balls were coming from a 6 different machines and kept getting faster as the game went on. This game was a ton of fun and I plan to add it back into Trickshots here in the near future
Arrow Poker
Okay, this was by far the coolest mini-game I made and I might have to make it a completely separate game. There was an NHL All-Star competition in Los Vegas where the NHL stars would try and hit giant playing cards in the air to create blackjack hands. I really wanted to make a game like that, so I create a bow and arrow version of it. The user has 60 seconds to make as many poker hands as they can by shooting cards that are circling around them. It sounds easy, but due to the randomization of the cards and how they are bouncing up and down - it became super challenging. To make it a little easier, I added in a way to “shuffle” the cards which would not only randomize the cards but it would also spawn back all of the cards that you had already hit - but the user could only do this 3 times per game. I put the UI on 2 “crunchy” ps1 style monitors and then everything was put on a poker table.
3-Point Shoot Out
This was the first mini-game I made, just because I thought it would make the most sense in a multiplayer environment. Unfortunately the shooting mechanic itself was terrible. Out of the box HVR did not work well with shooting basketballs but I did wind up using the game template for the rest of the games.
Crate Knock Down
I went back to the crate tower prototype that I had previously made and hooked up “knock down” logic which detected when the crate had been turned past a certain angle which resulted in that crate being “knocked down”. This was was a lot of fun and there is a lot more I want to do to it in the future, which levels, crate weights, different size crates and more.
Home Run Derby
The classic. The holy grail of backyard mini-games. My brother and I were constantly playing homerun derby in our backyard growing up, so adding it into the game was a no-brainer. The gameloop was simple - you have 60 seconds to hit a certain amount of homeruns and each round that the amount you have to hit goes up!
Sound effects, video board and ball trail prototypes
After I had enough mini-games made, I decided it was time to return back to the original back yard to start make a vertical slice of what a “shipped” backyard could look like.
The first thing I did was really improve the hitting of the balls from the bats. This required creating new physics materials for each of the bats and each of the balls, but it made the hitting much better.
I had yet to add any audio to the game (other than countdown audio) so I made a script to add to the bat that detected which ball it was hitting and made the audio for that particular ball. It also picked from a list of audio samples and then would randomize each sample while not playing the same sound twice.
I also added audio for when each ball hit the ground and made a script that lowered the volume by 20% each time the ball hit the ground - simulating a ball bounce fading.
To make the backyard feel like it was a baseball stadium, I added in a video board that played a homerun video every time the user hit a homerun. This got repetitive really quickly so I made a script that randomized each video played while also never playing the same video back to back.
Through playtesting, I found out that the ball was hard to see once it got past a certain distance - which led me to adding unique ball trails to each of the balls. This solved a problem while also making the balls look really cool.
I finally bought a model of a real pitching machine to replace old version I had been using. I animated the wheels, added a wheel-spin sound and a pitch sound. All sounded great and really added to the immersion.
I thought it would be neat if there was a dog in the backyard that would react to the user doing well, so I bought a dog-pack and added a puppy to the scene that barked every time the user hit a home run.
HVR implementation
At some point I wanted to switch away from using the default XR controller and switch to hands. But I am not an animator nor am I a modeler, so I decided to buy a license for Hurricane VR (HVR)
This was, by far, the best decision I made in the entire project. After I installed the package, I went to work reading all of the documentation on how to set it up in the project and after a couple of hours I had hands!
Hands really made such a difference in making the game feel more immersive. Picking up a baseball bat with the XR controller was fine, but picking up the baseball bat with your hands and seeing your fingers wrapped around the bat was incredible.
HVR came with a lot of features that I would keep throughout the whole project, but the hand and finger posing was incredible. I could manually hand and finger pose around an object, and I could also put a collider in the object to use the auto posing.
There was a lot of learning when it came to the hand posing, in terms of how to access poses and save them off correctly, but I created a lot of hand poses for different prototypes
Once I had messed around enough, I started to make poses for objects that I had in the game, like the baseball bat and basketball. Shooting the basketball using HVR was nice, but wow was it not accurate at all.
Then I experimented with using two hands to hold the bat. HVR has a neat feature were you can set 2 grabbable spots on the bat and it will put your hand pose anywhere in between those 2 poses. But unfortunately, hitting a VR bat with 2 hands was terrible. I am glad I did the experiment, because I had always wondered if 1 or 2 hands would be better. 1 hand isn’t the “proper” way to hold a bat, while 2 hands looks “cooler”. So accessibility wins again.
I also decided to add some “wacky” bats in for the first time, to see what it would be like to have a bread bat or a wiener dog bat. It was fantastic.
The prototype that eventually became the game but i didn’t know it at the time
So late one night while my friend Jorge was over, I was showing him the game but in Unity.
Jokingly I said “I wonder what it would be like to be in a giant house in VR", and he said “do it”.
I did it, and it was neat - but nothing really stuck out. The ball was small and you couldn’t see if after it went too far, so I shelved the idea.
But this was part of the process - I wanted to be able to quickly try something new out and see if it stuck.
Finding the fun
At this point, I had 2 options.
1. Create as many mini-games as I could and ship the game as a mini-game compilation
2. Find a game that stood out from the others, and build around it.
So I decided that I would try and do both. I would create as many mini-games as I could, while also seeing if one of them stood out from the others.
I was going to use the template I made from the previous mini-games to make these news one even quicker, and it worked - I was creating a mini-game a day.
A big constraint I put on each game was that they all needed to be extremely easy to understand and just as easy to play. Sure they can be hard to master, but I didn’t want the user to have to read a lot before playing the game. Just pick a game, play it, and play it again to get better.
Creating all of the marketing and store assets
I wanted to create a trailer for the game that really showed how hard the game was to play, but also how exciting it was to make a shot. So the trailer wound up being very simple. 2 minutes of me trying to make a shot and the finally getting it, teleporting to the next hole and showing the title screen with the “available now”.
To show off everything within the game, I made 4 videos that are in the game description that show off the key aspects of the game: 1 mini game video, 1 video showing a course being unlocked, 1 video showing a shot go in and 1 video showing off a wacky bat.
For the store screenshots, I didn’t want to give away too much about the courses or mini-games that weren’t already in the videos on the store page. So I decided to put in some pictures of some of the interiors of the game, a picture of all of the mini-game start buttons and a picture of the starting course info.
Keypads for gates, new bats & blimp prototype
So at this point in the project, I was starting to finally add some much needed features for a multiplayer game. The keypad was a way for users to be able to create a code for their own backyard so they could get in and out without people being able to get in. The idea was that you could have your own code, but also create a “guest” code for other users to go in and out.
I also started to mock out some of the backyards with different games to showcase what different backyards would look like. This was a neat exploration in trying to come up with as many different “themes” as I could.
I added a blimp with a gif billboard attached that I eventually wanted to use as a messaging system for all of the users within the sandlot. Users could send up their own gifs or they could use it to communicate with everybody else.
And then I started creating some really interesting bats. My rule was that each bat needed to be fun and also sound fun. That meant when a ball hit the bat, it needed to make a noise other than the normal noise when a ball hit it.
Making a golf course
After making beirut, I wondered if it would be fun to try and do the same thing (hit a ball into a cup) but from a longer distance. Like the trick shot videos that run rampant all over social media.
I didn’t really have the space to do something like that in the backyard or in the hourse, so I went all the way back to the “Tiny Human in Giant House” prototype and tested it out.
I took the existing how that the user could walk through and made it 15x scale. I setup a pitching machine, put a cup at a distance and tested it out. It was both parts fun and frustrating. “Funstrating” as my friend called it after playtesting it.
I had a lot of space to work with within the giant house, so I created teleporters that took the user between each of the spots.
I wanted to make each hole unique and also fun to play in - something you could never do in a normal sized house.
My first playthrough of all 9 holes took 45 minutes and it was the most fun I had in VR in a very long time.
Polishing the game
At this point I had all of the courses made, and needed to polish up the mini-games. I decided to continue the TV UI theme, so I made all new info tickers for each of the games. I also forced the other start buttons to go away if one of the games was running, and made them all reappear when the game ended. I also added a “quit” button for the Beirut game.
I went through and added music to each of the courses, trying to use the same artist as much as I could. I found two amazing artists on pixabay and wound up using 5 great tracks for each.
Speaking of using music, I made a credits room for the songs that I used and the 4 bat models I used.
The gif billboard prototype
While I was in the middle of making all of the voice recognition prototypes, I wanted to have some fun and make something that I had never seen before - A Gif Billboard
The gif billboard used voice recognition to hear what the user was saying and dictate it out into words. That was the easy part. The harder part was going to be putting in a gif api that would work with this.
I found out that tenor allowed users to have free access to their API - so I hooked up my API token to the wit.ai and bam - the Gif Billboard was born.
This was honestly a blast to make and it only took a couple of hours from start to finish.
I wound up using this up until launch, but took it out - because I want to use it in another project!
Challenges & store prototype
With mini-games in, fun bats in and a giant blimp in, I decided to make a challenge system prototype.
The idea was that users would be given challenges via a clipboard and whenever they cleared the challenge they would receive a prize.
I made a pretty in-depth prototype here that used a whole lot of lists to make prize tiers, challenge tiers, challenges themselves and clipboard tiers.
Depending on the tier of the clipboard, it would have a certain amount of challenges. That clipboard tier would also dictate the challenge level of that challenges given.
Each clipboard would also have different kinds of challenges, pulled from a list, that would never duplicate or show the same type of challenge.
To pull it all together, the challenges would only be activated upon the user picking the clipboard up. This prevented other challenges from being counted while the current one you were doing was active.
All in all it turned out really well and I really wanted to add currency to the prize pool so users could have a currency pool of some sorts.
And that’s when I decided to make an extremely diegetic store themed after a “Yard Sale”. You could pick up any item, bring it to the register, drop it in and it would give you the total of the items you had placed in.
The next steps were to tie in the currency to the challenges, add a storage box for the user to store their items and bam - a complete purchasing program.
Pivot from multiplayer to single player
At this point in the development of the game, everything was multiplayer. I had a former colleague that wanted to start a new company and take the game that I had made, pitch it to investors and build out the big full version of this game. After a couple of months of not hearing much on the investment side, I decided to take what I had made and turn it into a single player game. This was not an easy decision at all, because everything in the game so far was designed towards being a multiplayer sandbox game. So I had to sit down and see what was really needed and what I needed to shelve for later. This is what I called the “pruning” process.
The first step was to go back to the single backyard environment I had made months ago. There was no need to go to neighbors backyards, plus this would really help performance.
The next step was figuring out what the actual gameplay loop was. Previously it revolved around playing new games > earning points through challenges > buying new equipment and games with currency > back to playing new games.
The biggest constraint I created at this point was that the game was going to be 100%. Before this, it was going to use microtransactions to buy equipment. And since this was going to be completely single player - I wanted the user to be able to play the game and unlock everything.
And finally I needed to “find the fun”. What was the most fun the user could have in this game? Did I have anything already that I could lean on?
Home Run Zone
After playing around with the bow and arrow games a lot, I decided that it could be fun to play a game where you had to hit a ball into a certain zone to get points.
After playtesting with some friends, it was pretty clear that everybody only wanted to go for the higher point values, so I added in a multiplier that stacked for consecutive hits of that multipliers zone. This worked extremely well as you would want to go for the multiplier, instead of the highest point value every time.
I also added some “polish” to the game with zones growing and expanding when hit, so the player had feedback on which zone they were hitting
I plan to improve it more by creating a “negative” point value where if you hit it into a certain zone, you will lose points.
Zombie Invasion
I had a really weird idea of trying to create a zombie game where you have to hit home runs to evade the zombies.
So I grabbed the gun prefab from the HVR example scene, put it in my game and re-did the raycasting so it worked on hitting the zombies. But I really really was not about the idea of having a gun in a kid’s game, so I replaced the shooting sound with me saying “pew”. I put an ammo counter on top of the gun as well, and rewrote the gun logic to be able to have as many bullets as the user needed.
The game was pretty simple - hit homeruns to earn more ammo. Use that ammo to shoot zombies. The longer the game goes on, the quicker the zombies spawn. It was a ton of fun.
I also used the skybox changer prototype to change the skymap to a darker scene and gave it a spooky zombie soundtrack.
Basketball Jones
Since I wasn’t ever going to use basketball shooting, I wanted to make a basketball hitting game.
This one was pretty straightforward in premise - hit the balls into the baskets to score points. The higher the basket, the smaller the goal and more points you would get.
This risk-reward was pretty fun and playtested extremely well.
I also decided to use a bigger ball that was lighter and easier to hit further. This was much more fun and easier to play with than using a smaller ball and smaller goal.
After making the big ball, I wanted to make more big ball games, because I felt that there was something really neat about hitting a big ball that moved slow. It was easier to hit, it was easier to track and it broke reality enough to make it fun to do.
Beirut
I played a lot of Beirut in college, so after making the basketball game - I thought this was a no brainer to try out.
All of the games before this were time-down games. There was always a clock going down and you had to do X within X seconds. This one was different - the clock counted up and you had as much time as you needed to complete it.
The goal was simple, hit the big dodgeballs into each of the cups. The setup was extremely easy too - just a collider in the bottom of the cup that detected when the ball was there.
As I was playtesting Beirut, I found out that you could hit the ball on the ground first and hit it into the cup - almost identical to how beirut is played. And that’s when the lightbulb went off.
This was the game mechanic. Maybe not in beirut form, but this is when I knew I was on to something really really fun. It was extremely addicting to try and get all of the balls in the cups as quickly as possible - opposed to the other games where you were trying to get a certain amount of points
Making a lot of golf courses
This was the idea I wanted to go with, but I needed a lot of content.
I decided to make 5 courses with 5 giant indoor houses. Each house had its own unique personality in how it was laid out, and the color theme that went into the sign UI.
I also used the basement as a “Mario 64” hub world so the user could enter a password into the keypad to unlock the door and then go to that course.
I spent the next week building out all 5 courses and after they were done, I wanted more!
But before I made more houses, I wanted to polish what I had. I created a scoreboard that showed how much time you spent at each hole, how many shots you had at each hole, how much time you spent on the entire course and how many shots you had on each course. I didn’t want to put leaderboards in, but this was a way for users to see how well they did and try and get a better time with each playthrough.
I used the skybox changer prototype to make each house switch to a different lighting/skybox and also a different music track.
I started to add personal touches, like pictures of my cats - to make it feel more personable.
The police station and elevator system
The house pack that I used was extremely valuable. I used all of the assets that came with it to make all of the courses - but didn’t want to make too many courses with the houses.
I got another asset pack, and this was made by the same creator and it had a ton of police station assets in it. So I started to do the exact same thing I did with the houses, but everything was going to be contained within just the police station.
I got to work making courses within the various parts of the police station - trying to make each themed as possible. After a couple of days I had another 5 courses!
This is when I started to really polish everything. I polished the UI by using a tv screen that came with the asset pack, and then creating the UI on top of that. It was much better than just having a 2d plane hanging out in the environment.
I also removed the ability for the user to select which ball they were going to use to try and complete the hole. After a lot of playtesting, the bigger balls were king. The smaller balls were very hard to control and were hard to see at long distances. This really simplified the game and made it extremely straightforward. Pick up a bat, pitch the ball to yourself, try and hit it in the cup.
The police station assets also came with an elevator asset, which I wanted to use. I animated the doors to open and close and while the door was closed, i enabled the course teleporter along with the UI used to show it. This was great because I didn’t have to find 5 separate elevators to use for each course. I then hooked up the keypad so that when the user put in a unique code, that particular course teleporters would should up in the elevator. I added some elevator opening and closing sounds and the elevator was brought to life!
The elevator was so good in the police station, that I brought it back to the basement of the house and used it as a way to go to the house courses - instead of the 5 separate doors I had previously. This was great because it thematically connected all of the courses together.
Instead of having the police station be accessible from the basement elevator, I made a “secret” room in the bedroom where you could “teleport” to the police levels. This was actually loading the police scene - and was needed because the games performance was at a crawl when both the police station and houses were all in the same scene.
I added some polish to the loading parts, showing a basic loading bar and the scene loading worked perfectly!
Finishing and Publishing the Game
Creating the new backyard
If there was one thing I knew, it was that the game needed to be in a backyard. The whole premise of the game started in a backyard and I really wanted to keep that. I have way too many amazing memories spent in my backyard playing games with my brother, so this was extremely important to me.
I went back to one of the previous backyard ideas I had made, where the neighboring houses were closer - and it was great because you could hit balls off of their houses. This let me create a cozy backyard environment that felt much more personal and grounded in reality.
I also put every single prototype I made into this backyard. I knew it was going to be cramped, but I wanted to see what worked and what didn’t work.
I had bought and used a housing asset pack from the Unity Asset Store in the multiplayer version of the game, only to use the outdoor props/houses. So I decided to see what it would be like to use the inside of the house to talk around in VR - it was great. With the backyard being cozy and the inside being not too small but not too big - I knew I was on to something.