Embedded Files
This page will function as something between a postmortem from each group member and an explanation of what this project actually was. From the outset, we wanted to create something that could emulate the feeling of the classic breakout/brick-breaker game from decades ago, but we also wanted to add something to the formula that only VR could permit. During the development of this game, though, we learned a lot about expectations of feature development and the reality of development time.
Breakout VR gives you the opportunity to be that paddle from the classic 2D game. The way you interact with the ball and keep it bouncing in play is by using the VR wands to hold paddles that bounce the ball back down the corridor. The objective is to eliminate every brick from the level, and that is done by hitting each brick with the ball. There are a few types of bricks to break as well. First are the basic bricks that simply disappear when collided with. Next is the flying brick, which when broken, will fly at the player and they must dodge it and move out of the way in order to see the ball moving around the scene. Lastly is the eponymous explosive brick, that will destroy itself and another brick in its proximity. If the ball hits the wall behind you, you lose a life. Lose three lives and its game over.
Game over. Score of 0. What you don't want to see.
Michael Lederer:
Michael Lederer:
On the technical side, my responsibilities ranged from scripting to testing and bug-fixing and optimization. Having a Vive of my own made demoing and testing the project significantly easier, as it allowed me to emulate the real conditions under which someone would be using our game. My experience with developing this project could be summed up in one word: "Physics". Never did I anticipate (foolishly) that the hardest and most important thing when developing a Breakout clone would be sensible and intuitive physics. This threw a monkey-wrench into our development timeline and caused us to nix several features and quality of life improvements that we otherwise would have wanted to implement. Our ball physics mechanics went through a few different iterations.
First, we attempted to have the ball speed up after each brick collision. This proved to be a poor idea when we wanted to create levels with large amounts of bricks, as the ball would speed up at an unreasonable pace to an unmanageable top speed. I tried playing around with the vector math, but couldn't find any scalar values to add to the velocity vector of the ball that felt appropriate. The iteration of ball physics that I settled on were the simplest, but seemingly most stable. I decided that maintaining a constant ball velocity proved to be most appropriate for keeping a reasonable difficulty, while not being too easy. Additionally, a consistent problem I observed was that the ball would constantly get stuck bouncing back and forth between corners or walls. I remedied this by adding capsules outside of the game corridor that acted as rounded, convex boundaries to keep the ball in the area we wanted. Ultimately, this project taught me a lot about how Unity physics works, so that was a good learning experience.
The monstrosity that the player doesn't see
Where, not one, but both controllers must sit at the start to even be close to matching the Vive wands.
Physics were not the only problem I dealt with, though. In addition to the above issues, what proved to be the most frustrating issue during development for me was trying to replace the default Vive controller models with the custom models I designed. Surprisingly (though not to me), it was nearly impossible to find any documentation covering this feature in any of the VRTK4 resources. There apparently used to be a relatively easy way to do this, but...not anymore.
This led to a lot of "guess and check" for trying to line up the controllers in the scene, which felt really frustrating and inelegant. After a few hours of testing and playing around, I was able to get "close enough," but I had no guarantee that the orientation would be correct if I were to try the game on any other VR set up.
I think the main lesson learned from this project is that if I ever want to do a project that uses VR, I'm not sure VRTK will be my go-to for VR development kits (at least until the documentation improves).
Brent Yurek:
Brent Yurek:
I created the play room, as well as did some scripting. For most of this project's time in development, my laptop was out for repairs, making it difficult for me to work on this project. I was able to use a desktop PC outside of home to work on, but I was not able to work anywhere I pleased. Therefore I did not get as much work done as I would have liked to. Another obstacle for me was my lack of a VR setup, making testing my contributions myself difficult at best and impossible at worst. There were times where I would just hope that my code worked and left it to Michael to test. A good example of this was ball physics, which I started but Michael had to finish due to the sheer amount of testing required throughout.
The room I made was composed of planes. This was done to keep the polygon count lower than it could have been. It also had the positive side effect of being able to "see through" the other side of the planes (since they can only be viewed one way) which helped with editing and was not noticeable when inside the room. I used a bright blue to indicate where the player can stand and the wall the ball should be hitting, and used a dark gray for the other walls and floor. This was a simpler design than I had in mind but asset creation is not my forte.
A room based off of the one I created, at two different perspectives to show the one-way visibility of the walls.
The score and live counters I made. The lives counter doesn't show a number in the editor.
I have not done much C# programming so scripting was a learning experience to me, fortunately it was close enough to languages I am already familiar with, specifically C and Java. The biggest scripting challenge I came across was making the score and lives counters, which I used static variables for.
All in all, I think we did the best we could given our time and resources.
Mansur Shawabkeh:
Mansur Shawabkeh:
For my responsibilities, I mainly jumped around from place to place but primarily focusing on making the bricks and having multiple brick power / types the effected the game as the player continued. So because we were using the VRTK we had access to multiple prefabricated interactables that made item placing and design much easy in placing and abilities to not have to re-map scripts each time. I will also talk about a number of cool effects we added to the program called particle effect used to capture the inherent fluidity and energy of the 3 dimensional object. and scripting it in a way that it behaves only when the ball interacts with it.
To start off I will talk about the brick designs and different brick types and how they interact with the environment around them. like i said before I took advantage of the prefabricated interactables that VRTK has to offer to structure the bricks in a way that allowed it to have consequential interactions within the scene without the multiple setups needed without it. Having the object with an already established rigid body and easier to manipulate. After making the putting on the prefab and matching it up correctly I then moved onto the script which had to account for a number of things as the project development pushed further. One was addressing the speed of the ball as it collides with the brick because of the unity physics the ball continuously slows down after each collision and adding to much speed evidently made it to fast pushing it out of the scene. Two was the effect it had on the game and the players score and life bar. To compensate for the first problem this was addressed by taking in the brick assuming the ball never changes speed, because after multiple failed attempts to manipulate the ball speed and its inevitable demise we ended up adding velocity after each paddle hit making the game correct itself over time. In addressing the single brick I basically made the brick disappear after a collision.
The second brick is the explosion brick in which uses and works on prefabricated made by the particle pack available on the unity assets store (also have the link available on our sources page). The idea was to have a dynamic fluid effect when the explosion went off. And so making it emit for a small period of time added a cool flare to it. Unfortunately it doesn't show as often as it should in VRTK and with lack of available VRTK resources the problem it very consistent but luckily it does happen because of sound playing after it is hit so it makes its way across.
The final brick type is the flying brick and it was difficult in terms of production. One big hurdle was that the brick needed to transform and move towards the player so the ending direction is opposite by shift the z value to the negative direction making it fly at the same rate as the ball. So the actual script doesn't handle making the brick disappearing that gets handled by the back wall behind the player disabling the object from the game once it hits it. we wanted to add a sort of real life feel to the game that made it more personal and more enjoyable to play.
In the end this project had a lot of complications along the way but brought out really intuitive and unique work around that each member of this team contributed to as well as enhanced in a way that not only help speed up development but also made great game be not only more Virtual Reality like but also made it feel more retro in its game design. Though we have more ways and ideas to expand on this concept more further, we developed a game that will keep you entertained.
Page updated
Google Sites
Report abuse