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!
So we just finished up week 3 and now we are pushing to get our Alpha build fully operational before Tuesday’s expo. So we are now adding in as many operational features as we can that will help assist the player in learning the basics of our game. My personal job is to handle the tooltips and help the scene transitions not be as jarring.
My primary objective was to create some environmental tips to help guide the user on some basic game play elements. I ended up creating these plaques that start off flashing red to get the players attention, then when you get into range will stop flashing, and finally when you complete the objective that pertains to what is stated on the side, the light turns green.
I had a lot of issues with this, but most of them looped back to my own use of Unity’s coroutine system in order to get the sign to run its blinking in the background. This was my first time dealing with coroutines so I had to do a lot of research on how to make them work. Turns out that coroutines need to use a yield return in order run and have a place to break when the next frame is ready to run.
I also took care of a scene transition, which repurposed the fade that was used in the teleport code into a basic transition between the scenes, providing a softer experience that would not jar the user as the scenes changed.
We have a lot more work to do before Tuesday so I am going to get back to work. Ill update everyone again really soon!
This week my focus was finishing the creation of a better lose condition. I aimed for it to be in basically its final form. Last week I started by making a general Time Display Class. All it does is take in a float in seconds and turns it into a digits that are then displayed. Next I created a light handler that can make the two cylinders strobe on and off like an alarm and then when the alarm escalates starts alternating between them. The last of the basic reusable pieces is an audio looping class that repeats any sound effect as often as you tell it to. With those three pieces I created an alarm class to tell them what to do during different times. However to be more efficient I created an alarm handler class that updates the times and keeps the alarms synchronized. The end result is this:
This is the alarm during the initial countdown. It strobes the lights ever 2.5 seconds and plays a sound effect that warns of an imminent system shut down. The clock continuously counts down 1 second at a time.
After reaching the ten second mark the time increases in size and accuracy, now counting down the centi-seconds. It also begins alternating the lights. The Sound effect ramps up into a resounding “System Failure” echoing across the room until the time runs out and the puzzle resets.
I also had to squash some bugs but they were small enough to not be worth talking about. Oh and I added a body collider to the player so that they can interrupt the laser to start the countdown. That was kind of important. Type again later. Bye
Hello everyone! I want to open up by apologizing for not making a post last week. But I promise I will make up for it. In the meantime, I have quite a bit to fill everyone in on.
I have been handling some major changes recently, one of the largest being the massive overhaul of level one. As a team, we came to the conclusion that we needed to have a more extensive first level that helped to teach the player about some of the basic mechanics of the game. I headed the redesign and chose to break down the level into three separate rooms, as opposed to just the one. While we kept the design of the original room that we had, we shrunk the overall size and placed it at the end of the other rooms. In the first room, we have a laser hidden behind a movable object that will let the user learn about grabbing objects and the activation of doors, while the second room is composed of a single re-director that will let the user learn about laser manipulation.
Speaking of the re-director, I made a serious change to the re-director, in the form of its rotation, a problem that has been plaguing this project for a long time. Originally, we were using the built in Unity hinge-joint, which allowed the re-director to spin in place, combined with the Unity fixed joint, which allowed us to actually grab the object at a certain point. This prior setup was causing some issues when the player did not keep their hand in the same place when they rotated the object, leading the object to rotate seemingly randomly. This presented quite a problem, and needed to be solved as soon as possible. After several different attempts to fix this, Caliber came up with a potential solution using vector math. While this solution didn’t work perfectly, it led me in the correct direction to actually fix the problem. In the end, we now have a re-director that rotates smoothly.
In other news, I have been squashing bugs as they pop up and working on some polish for level one. My current endeavor is to set up objects to snap to a set position when you grab an object.
I will update again soon, I promise!
I feel like we got a lot more done this week, but I guess it’s because we nailed down functionality and managed to work more on design (alongside level 2’s development). We managed to down our long-standing issue of rotating objects with the controller with better vector math. The original design only took the two points, without regards to the direction of those points from the objects origin. Now everything rotates smoothly.
Last week I got a new toy, Amplify. I’d mentioned it alongside a little side project I’d been working on. Now it’s become more useful, as I made a new shader to process an effect in our game.
The effect fades the object in as a wireframe-like version of itself, and then ‘dissolves’ into the full object, as though it’s being created from a computer. This effect should have many uses in our project. The USB-looking objects are our level transitions, which slot into the podium in order to process a transition. Coming up this week there should be a smoother transitions between scenes.
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!