GD4 Team Project | 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.

Product

This week was all about preparing for the Alpha demo:

• I worked on implementing some work by the other members of the team for our demonstration
• We presented on Thursday

Process

Implementation

The majority of my focus this week was spent on preparing our demo into a decent state for the Alpha Presentation.

It was important that work from the other team members was included in our demo. I implemented several calls to Kieran's SoundManager as it was necessary to demonstrate some basic early version of user feedback, namely plugging in/out switches and a line where GUS explains what the ABCs do. For the next release, I plan on working with Kieran to fully implement the rest of his sounds.

I used Paddy's AnimationManager to trigger a GUS speech animation when the voice line started and stopped this when the line ended, this gives the appearance of GUS talking and demonstrates a basic version of the animations we intend to have for our final release.

I implemented some of Charlie's new cable models which are able to be plugged in/out of the ABC.

I also carried out some minor testing, made changes and fixes to multiple scripts to allow a smooth run through of existing functionality.

Presentation

The presentation gave us a good image of what we needed to work on. From a technical perspective, the presentation went well and the technical demo fulfilled it's purpose perfectly. Feedback was received on the sound/user feedback/gameplay aspects, as these weren't all there in this demo; this was something that we expected as the bulk of these features are yet to be implemented.

From a presenting perspective, it didn't go well at all. Cormac had written a script which some of us, including myself (as I was working on the demo) hadn't learned very well, and we ended up reading the scripts from our phones.

This proved to not be very engaging and the audio on the demonstration video that we played was far too quiet, all in all resulting in a poor performance.

We realised from this that for our next presentation, we really need to have everything down to a tee, by having the room, audio, video, and script prepared well in advance.

Product

This week:

• I worked on revamping the entire Input System 
• I polished and optimised the input system
• I created a narrated gameplay demonstration

Process

Input System Revamp

We've known that there would be issues with the input system for a long time, which are due to the constraints the HoloLens is putting on the game. With only one mode of interacting with components; the tap. It was simply unfeasible and overly complex for the user to move around components and their subcomponents,  and to interact with all the functionality of a component, all with a single tap.

In order to simplify things, the old system was mostly scrapped and a new system was implemented, where when an object is tapped, it's focused on and buttons appear around the object with whichever functionality it has. This involved the integration of HolotoolKit buttons and collections into our code. I implemented functionality where each interactable component would now have a set of UnityEvents (which, when invoked, activate attached functions) and strings (for button text) which it would pass into the buttons. This allows us to dynamically create menus of any component that's selected; giving the systems some modularity.

 Early version of the new input system

The first idea we had was that when a component was clicked, it would appear in a separate view with the necessary buttons. This solved the issues but didn't take full advantage of the potential of the HoloLens, and also lowered the framerate due to having to render two cameras (which is why in the picture above the second view is low resolution).

Work in progress of the new Input System

This new way of focusing on components involves making the cabinet disappear and the focused component scaling up. This allows a player to fully focus on a more detailed view of the component, with interactive menus appearing on either side of the said component. The video above also demonstrates how the binary will be set for the ABCs; through a separate menu to the left. Currently, the only issue here is the animations, as three asynchronous functions are run (the cabinet, component, and menus) every tenth of a second. This is somewhat intensive and causes a drop in framerate, but this will be optimised at a later time.

Polish & Optimisation

I added a few additional buttons which would allow the player to play and quit the game, these features are important as, for the first time, it allows a player to fully go through all of the features of the game without getting stuck. Optimisation of the game was key as any drop in frames is quite noticable in the HoloLens. I was able to increase the framerate by changing the stereo rendering from multi-pass to single-pass, and then even more so by building the application in Release, which increased the performance significantly.

Gameplay Demo

I recorded, narrated and edited a first draft of a Gameplay Demo. Currently this demonstrates all of the features I worked on, however, the next draft will include fully integrated features from all the other members, such as Kieran's sound programming, Paddy's animated GUS, and Cormac's speech recognition.

Alpha Demo

This week:

• I prepared the game demo for our meeting with ABB
• We met with ABB for a presentation of our game, and demonstrated its features.

Process

Demo Preperation

I worked on preparing the demo for our meeting with ABB, this involved implementing the binary switch puzzle and GUS into the scene, as well as ensuring the input system would work smoothly. I built the demo application onto the HoloLens and tested it several tiems, repeating the process until any remaining bugs were fixed.

ABB Meeting

We met at ABB the next day, where we presented to a room of ABB engineers and developers. First we ran through a powerpoint outlining some of the newer features of the game and then I demonstrated the game on the HoloLens. A few technical errors between Unity and the HoloLens livestream feature meant that there was a delay, and to go around this I ended up recording some of the gameplay and then playing it back while describing the features.

Although this was a minor hiccup, in future we'll have tested the recording functionality fully, and if needed I'll record a gameplay demo which we can demonstrate to all people present, and then allow anyone who wishes to play the demo to do so.

Overall the meeting went quite well, the feedback we got was very useful, among the things mentioned were scalability and usability. It was mentioned that the game itself could be a valuable tool to train engineers in numerous scenarios. After this presentation we talked about the next phase of the development of the game and realised that the input system in it's current state would not be able to handle the level of detail needed. The only input we have is the HoloLens tap, and to simplify interactions a reworking of the input system is needed.

Product

This week:

• I spent the majority of my time working on my individual portfolio, but...
• I implemented a system where GUS can assist the user if he needs help.

Process

GUS Hint System

It was necessary to develop a system which would aid the user in case they don't know what to do.

The State Monitor which can figure out if a puzzle step was incorrect or correct passes this information to the Hint System. If a user got the same step wrong twice, GUS' help level will increase from None to Normal, and in future, a sound will be played to assist the user in his task. If the user gets it wrong another time, the help level will increase again and GUS will give a detailed description of what needs to be done.

A string is built from what the user got wrong and GUS' help level, e.g. "GusHelpEthernetNormal" or "GusHelpVDC24High", these strings will be passed to a Sound Player, which Kieran is working on, which will then play the required sounds.

Product

This week:

• I implemented a system which keeps track of which components have live electricity running through them.
• I spent the majority of my time integrating the event system, a rudimentary scoring system and a state system together.

Process

Power System

Each component in the puzzle must be checked for whether it has live electricity running through it; this has been implemented in the Event System. Through an object hierarchy, if any component can be tracked back to a live source (the cabinet in this scenario), they are considered as powered.

The object hierarchy, in this example, if the cabinet is powered on; all these components are live.

In this hierarchy, even if the cabinet is powered on; the ABC is detached and so is not live.

Integration of Events, Scoring and States

After finishing the event system last week, there needed to be some way to actually track where in the puzzle the user is. I implemented a StateMonitor which takes and compares events to the ideal order of events. This is achieved by splitting the necessary events into two lists.  One list tracks the order of events for fixing the components. When all the components are fixed, the next list (the order of reassembling components) is used.

The StateMonitor detects whether a user has made a correct or an incorrect choice, and has the ability to weigh events; so if a user forgets to turn the power off before interacting with live components, this applies a higher penalty than taking cables out in the incorrect order. This information is sent to the ScoringSystem which makes the necessary changes to the users score.

A timer system has also been implemented so when the user finishes the puzzle, a time-based variable will be applied to make their final score.

Flow of determining how user's inputs effect their score