Hello Everyone! This is just a short post to reveal our latest teaser video! Enjoy!
This past week has been tremendously busy, as we’ve been preparing for a big build and demonstration tomorrow (May 23rd). The majority of my time this week has been spent on designing and building our third, and currently our hardest, puzzle. It makes use of our laser splitter and merger pieces, forcing the player to experiment with color combinations while navigating multiple lasers.
When I was first tasked to make a hard puzzle, I quickly realized that the more lasers the player has to deal with, the harder the puzzle becomes, just because they can’t touch the laser without tipping the alarm. With this information in mind, I first made a full laser grid, that consisted of double the lasers you see above. I quickly realized this idea was overkill, and would annoy the player rather than pose an actual challenge, regardless of the lasers/checkpoints color.
While building this level in Unity, we ran into multiple issues with our laser / pedestal code. The biggest being that I wasn’t correctly handling all of the possible laser combination in the splitter’s main switch statement. This was causing every laser that passed through the splitter to have the wrong color information. Another issue was that the prefabs that I had made and set in the level kept getting re-written or changed in strange ways. This is likely due to issues with Unity Collab causing my files to de-sync from our cloud build.
I also had a little extra time to add to the main menu, including making the options screens “Break” when hit, complete with shattering glass sounds!
Thank you for reading, be sure to check out the other developer’s posts, and tune in next week for more updates!
Hello! The second week of our second month has been pretty interesting. We’ve achieved many goals in a short time, but it seems like for every goal we reach, three more appear, along with several bugs new bugs. I mainly worked on the Splitter piece, which separates an incoming laser into multiple lasers. The interesting part of the Splitter is that it separates the colors of the incoming laser, for example : if a white laser hits the Splitter, it will output three lasers, red, blue, and yellow. If a blue laser hits the Splitter, it will output two blue lasers. One of the biggest obstacles I faced this week was learning the code my teammate Jorge wrote for the laser system. I often found myself making mistakes / creating small bugs simply because of misunderstanding his code. After about an hour of reading his code, and asking him several questions, it was easy enough to implement the Splitter logic.
Sometimes as a programmer, it feels like I run into every bug and issue imaginable. When testing the Splitter we realized that there was a race condition in the laser system. Because we were doing certain operations in the start functions of most of the laser scripts, lasers were initializing and sending messages in a random order. We fixed this bug by moving most of our initialization code to awake functions, that way we could better control when each game object is initialized and updated. The rest of my time was spent squishing other bugs and building the second level of the game.
We also purchased some art assets, and we’re in the process of overhauling all of the art in the game:
Thanks for reading, be sure to stay tuned for more updates!
Hello everyone! These last few weeks have been a series of debugging nightmares. I spent the majority of my time designing and developing the options menu, and the save/load system for Data Thief. Unity actually makes handling data really easy, and neither of these systems were all that complicated. I spent more time simply researching the best way to build a functional options menu than I spent actually building it. I encountered my biggest roadblock when I started testing my save system in combination with my options menu. The first portion of the problem was the fact that the player had no way to interact with the Unity UI canvas. The SDK that we are using is still in development, so the controller’s UI interaction code simply didn’t work. It took an entire afternoon just to debug this problem, which we fixed by changing the prefab’s hierarchy. My fellow team member Caliber found that our version of the SDK was outdated, once we updated, it was just a matter of changing the game object’s hierarchy to work with the new format. Once we finally solved that, I found my save system wasn’t working properly. After multiple test builds, and adding a bunch of debug code to log each step of the saving and loading process, I discovered I had a typo in my load file path. It was really frustrating to spend an hour debugging a problem, when the cause was a single wrong character in a string. I was loading from a different file path than I was saving too, so my load function was always looking for a file that didn’t exist. All I had to do to fix the issue was fix my typo, and then the system worked fine, the player’s settings preferences are saved, and we can save and load any data we may need in the future.
Despite that frustration, I feel I exceeded my goals for the week, and I gained a lot of debugging experience along the way. The issues we encountered this week made me come to the realization of just how new VR still is in development. Every time we made progress, something else would break, usually due to an update. Its a great feeling to know that we are pioneers on the virtual reality frontier, despite the amount of technical obstacles we encounter every day.
Here is a picture of the latest version of the options menu, keep in mind that this is a work in progress:
As part of my options menu, I also set up our audio mixer, and added some music and sound effects into the game. Stay tuned for another game-play video, which will include in-game audio!
We’ve reached the end of our first month, and we have a pretty good foundation. Here is some in game footage of Data Thief, enjoy Walker’s play-through of the first level!
This is just a quick update on Data Thief, as I wanted to show off some of the cool textures we are using. I was getting pretty sick of just default materials and bland colors, so I took the time to find good free textures ( and I made a few myself ) and now our virtual reality game is starting to look more like reality!
So far I’ve mainly been working on the main menu and gathering assets for the game. I’ve been having a lot of fun learning about the HTC Vive’s capabilities, and how Unity and Steam VR work together. I’ve encountered a lot of issues with assets having an absurdly high polygon count, free, beautiful assets are great, but there is a lot of art that have extra unnecessary triangles. We decided that we want less than 100,000 polygons in frame at a time. My advice to artists : keep in mind that a coffee cup doesn’t need to have more than 10,000 polygons, no matter how good it looks.
Since this is my first project in virtual reality, I have been learning about the different ways the player interacts with objects, and the dos and don’ts in VR. I got a few free asset packages off the Unity Asset Store to use as temporary game objects for the player to mess around with in the main menu. We may or may not keep them, but I like the package of Dice, from 4 sided to 6 sided, they look great and have a really low poly count.
The biggest challenge I’ve faced so far has just been with testing my work. Since I don’t have an HTC Vive (or a rig with high enough specs to run one), I have to wait until I meet with a team member who has a Vive set up to test my content. I usually don’t have many issues, but I’ve had to correct my scaling several times after loading in and objects being too large / small.