Technical Portfolio - Journals

Product

This week:

• I worked on making the final touches to our game

Process

Final Touches

There was still one issue left to resolve, which we found out through the user feedback last week which was that the application is notoriously prone to crashing. Some more information on the specific issues and bugs themselves was gathered by Kieran during his exploratory testing, which he wrote into a document.

Most of the issues were based on the stability of the game and on the HoloLens only - the Windows version had never crashed. I was able to debug by plugging the HoloLens into my PC with a USB cable and launching the HoloLens build project (the one exported from Unity). I was able to put breakpoints in while running the game on the Holo.

I learned that some exceptions thrown won't cause crashes in the Unity editor, but will in the HoloLens, so I wrote fixes while playing through the game several times to ensure that these were fixed.

Another issue was that for some reason an issue would occur on the HoloLens where you wouldn't be able to start a game after clicking Quit or Clear, both of which go back to the select scenario menu. Through debugging I figured out that a weird error was happening where after clicking the Start button, the function for the Quit button would be called immediately afterward. I didn't have enough time to find the root cause of this so a quick hot-fix was implemented where the Quit function wouldn't be able to run unless the game had properly started.

After these changes, the stability of the application was significantly improved.

Product

This week:

• We met with ABB to get some user feedback
• I used this feedback to make tweaks to our game

Process

Meeting with ABB

We had previously organized a meeting with ABB in order to get some user testing for our game. This was key as the software had progressed significantly since the last time we met. While the user testing was ongoing we recorded the conversation in case we needed to go back to the key points that were raised.

The first thing to note as that the game was very buggy and prone to crashing, I myself had not experienced this in my testing. This highlights the importance of getting someone other than yourself to test your software. Secondly, while Brian was able to progress through the puzzle with relative ease, another member of the ABB team had an extremely difficult time getting through the puzzle as he was not an engineer. We quickly realized that this meant that only those with a certain level of baseline knowledge would be able to play the game. Ideally, anyone should be able to pick up the HoloLens, launch the game and then develop some engineering skills.

After the user testing, we recorded Brian saying a few words about the applications of Augmented Reality in industry, which we will use in our documentary/trailer.

Implementing tweaks

As previously mentioned, one thing that we took from our meeting with ABB was that a player with no training will have almost no idea how to play the game. Before each step is processed by the event system, I implemented functionality that first checks if the step was correct or not. If the step was incorrect, it is not completed and a GUS sound is played which tells the player which step he should do instead. This ensures that a player with no knowledge will be able to complete the puzzle and is actually a better system overall as the player is immediately told what the correct procedure is.

Points are still deducted for incorrect answers, and this also solves an issue where the player could get lost in the puzzle and not know which step he needs to complete in order to finish the game.

Product

This week:

• I completed the game loop
• Updated animations
• Polish

Process

Game Loop

The game loop is a key aspect of any game, this is the difference between a bunch of mechanics, models, scripts and a functional game, and allows a player to finish a level in the game, get feedback, and then play a different one, and so on.

A key aspect of this was the Scorecard. Using the design that Ciaran had created for the scorecard, I updated the functionality by:

Fixing some bugs with the EndGameCanvasBuilder (which is the script used to control the scorecard)

I implemented logic so that the EndGameCanvasBuilder dynamically constructs the list of correct/incorrect steps based on the steps provided to the StateMonitor. I implemented ToStrings for the various puzzle steps which would be displayed at the end, this allows for each individual puzzle step to have its own description, e.g. "Plugged out the VDC24 cable" or "Turned the power off". As the player progresses through the puzzle, any steps that they get wrong are marked as such in the EndGameCanvasBuilder, causing them to appear as a red X when the Scorecard is displayed.

I also fully implemented logic that would allow a player to return to the main menu upon exiting the scorecard, this involved resetting the scoring system, the event system, and the scorecard steps themselves. This allows a player to do multiple playthroughs without having to turn off the game.

Animations

I tidied some of the animation code to allow for transitions between focus mode and non-focus mode while setting the binary on an ABC.

I also created animations for the scorecard appearing and for each step that appears in the endgame menu. This was aided using Cormac's UI Summoner to call my animations in the correct order and with a delay.  Each step has a tick or cross image displayed to the left and a stamp sound (created by Kieran) played during the animation. I also animated the time elapsed to be flashing.

 Scorecard and step animations

Polish

Began updating some of the buttons for better aesthetics.

Implemented particle effect pack which would allow for spark/smoke or other effects, these spark effects are triggered when the user plugs out a cable but the cabinet is still powered on.

This week I and some of the other members of the team took advantage of the time off on our Easter break and took a week off work and went on a holiday to Spain. As we couldn't get any work done this week, we had previously made a few hours of extra work during the previous weeks.

This holiday gave us a much-needed break and we are now refreshed and ready to jump straight back to work and finish the final few weeks of our release.

Product

For this week:

• We began our beta release
• I started writing code documentation
• Learned and used the unity animation system

Process

Code Documentation

In the previous release, I would be handling the implementation of team members scripts into the scene, which would take up a lot of my time. In this Beta Release, team members will be working on the scene themselves, freeing up my time to focus on polishing the existing scripts. This requires them to have a decent understanding of the scripts and architecture of the codebase, so I created a google docs file and wrote up about what the various scripts do, how they work, and how they integrate together into what is our game; which should give them a base level of knowledge.

Animation

Beforehand, the animation of the door opening and the ABC coming out of the cabinet was done using Unity's Coroutines (programmatical animations).

I looked up some tutorials on the unity animation system and after practicing a little bit I used it to create animations for the game. I created various animations for the ABC, and I also created the controller for these animations which, depending on various states which can be changed in-game, handle the transition between animations.

Animation controller, the various parameters and states can be seen

Additional

I finished functionality to allow for the ability for wires to be taken in and out of an ABC through our EventSystem.

I implemented all cable models from Charlie, this includes the Ethernet, CommsDB9 and VDC24 cables, which are plugged into an ABC.

The finished ABC

I made some changes to scripts to allow for a full run-through of our first puzzle, this includes:

1. Turning the power off
2. Taking the three wires out in the correct order (Ethernet, CommsDB9, VDC24)
3. Replacing the faulty ABC with a new one
4. Setting the binary address on the new ABC (VDC24, CommsDB9, Ethernet)
5. Plugging in all three wires in the correct order
6. Turning the power on

Issues

Source Control

This week, a team member did not follow the recommendations for source control, where before making a commit, you stash your changes, pull the latest code, pop the stash, and commit (allowing for minimal conflicts and almost no need for merges).

This caused the live version of the project hosted on bitbucket to be corrupted and is affecting the workflow of the team. so steps are being taken to minimize the effect of this. Team members were advised that they can continue working, but not pull the new version until this issue is resolved.