For the last two weeks, in the limited spare time that I have after my kids go to bed, I’ve been picking away at building a VR game inspired by the classic Breakout/brick-breaker games.
I am a developer by trade, but I’ve never worked in the gaming industry professionally or even on a game as a hobby before so I’m eager to learn about this space. I chose to make a breakout clone because the core game mechanic seemed like something that was simple enough to implement, but with enough room to play with the nuance of VR and to build upon to make something somewhat unique and build something that would be worth bringing to market as a cheap game to get a sense of what all phases of the development cycle for a game is like. I primarily view this as an opportunity to learn the nuance of VR development in order to hone my skills as a developer in anticipation of the burgeoning VR/metaverse space, and if I happen to make something fun, then thats gravy.
Alright, enough about my motivation– I’m probably going to keep this dev blog really simple. I’m hoping to update weekly chronicling changes, with gameplay videos which would serve as bi-weekly demos. So without further adieu, here we go!
I didn’t take any week zero screenshots or video. For the most part my effort was focused on getting my development environment set up learning some unity basics, but I did take a week 1 video:
What you are seeing is a basic project with some janky collision/hit mechanics with an outrun style skybox and a wireframe shader on a little basic arena and some sound effects.
I think the main challenge that I ran into in week 1 (aside from getting my environment up) was trying to get the hit mechanic working properly. I was following this tutorial as a basic intro:
Now, the physics part of this intuitively made sense to me– separate the collider into multiple smaller colliders in order to make sure the velocity that gets applied to the ball is based on the mean of a smaller collider since the “hit” action is primarily rotation and the velocity at the tip of the object is vastly different from the one at the base, but one thing that wasn’t intuitive is why there is a need to instantiate a second “follower” cloned game object instance that has a separate script attached. While I’m still not 100% sure the reasoning, my best guess is that the unity controller objects that move through the world space kinda “teleport” through the world space as opposed to moving via physics and as such do not have velocity, so calculating it and applying it to the follower object makes sure the appropriate amount of velocity is transferred to the ball object.
The other key takeaway was how much sound effects and music make a difference in the overall feel of the game. This lead me to look note to look into “gamefeel” and “juicing” for the next week.
I spent the first part of the week playing around with trying to add juice to the game, and it definitely made it feel a bit more polished. I’m still pretty unsatisfied with the collision physics on the racket vs the ball, but it’s playable right now and not a blocker, so I’ll come back and try to address it once I have a bit more experience with unity.
My main goal for this week was to implement bricks and the brick field. The brick has a configurable amount of damage, and the amount of damage inflicted by the ball depends on how much velocity the brick was hit with. Currently the bricks are just set to a single hit point so it doesn’t really factor in, but in the future I’ll use it to have different brick types, and when I implement power-ups, the damage factor can be increased based on power ups.
For now, the brick field is just a configurable matrix of the number of bricks in the x, y z directions. I also implemented a breaking effect by creating a fractured brick mesh to swap in and explode when the brick breaks. It looks pretty good, but I eventually need to reduce the amount of pieces in the fracture, because if you break too many at once, there are performance issues.
One thing that happened while I was playing with the build, I somehow managed to mess up the camera offset when I returned to a game in progress and it ended up making me slightly taller in game than using the default offset, I played it for a bit like that and noticed that it added a lot of verticality to how the game plays. The default height resulted in almost exclusively playing standing upright and using my arms from a 90-degree angle and up, whereas being taller resulted in using a full range of motion and crouching to get balls, so I decided to incorporate it by adding a “hover-board” beneath the players feet.
My stretch goal was to hammer in a bit of a game flow. Click to serve was removed, and serving at start and after death was added, and then game start and end conditions were added.
Overall, a very productive week. I don’t anticipate sustaining this sort of velocity though.
In week 3, I intend to set up this blog, then add start and end screens that allow users to play again. Stretch goal is to start adding a really basic point system. I also bought the VR Interaction Framework since it was on-sale in the unity asset store. I’m going to play around with that a bit and use it first to implement the UI for the start and end screens, and then to see if it will maybe fix my issues with the racket collisions. Also, maybe decide on a name?