GD4 TP2 Individual Technical Journal in GD4 TP2 Individual Technical Journal

GD4 TP2 Individual Technical Journal

Week 14 - End: Beta


  • Scrum release completed
  • Minor fixes based on user testing
  • Analytics and user testing assistance



So we overestimated our ability to manage our time slightly this sprint. A lot of this comes down to overestimating how much we would get done in the early part of the release, where we aimed to have most of the work done. Exams obviously took precedence for a large chunk of the release time, so we worked around these how we could. Unfortunately we had came to a point where we knew not all of the work would be done, and a lot of this was due to Mark being out of commission with his illness, so we took off what we knew wouldn't be done from the release, and continued to work. We were a day late on finishing our final sprint, which I take full responsibility for. This was purely down to laziness on my part, I've been relaxing a little too much this past week to try and recuperate for the presentation. I think overall though, given the circumstances, this release could have went much worse. I think it is bad we aimed too high, but it's still better than aiming too low and playing it safe in my opinion. We still reached our revised goal and I'm impressed considering the time constraints we had. On a more generally conclusive note, I've really enjoyed my role as scrum master, due largely to the fact that I have had one of the easiest teams in the world to manage. 

I did some minor fixes to the game that came up in the user testing issues. These were mostly controls related issues. These were making the reverse stronger, doubling up key bindings, and adding a quick restart button. See sprint 11 for more details and see our testing results document in the issues section for even more details on these. 

I set up the analytics trigger points in the game, effectively implementing the analytics system Shane had added to gather some sample data to demonstrate for beta. This was in sprint 12. In sprint 14 (the last one), myself and Brian visualised some of the data gathered from these trigger points to show them in action. Things like crash points and lines taken around corners for example. 

In Sprint 13, myself and Ronan worked on the user testing results by analysing the issues raised by users into the official issues format found in the document. This formalised all the data and issues raised by users into the official issues format found at the end of the results document. Were development to move forward, these issues would be turned into tasks on scrum to be addressed. 


Time mostly. We overestimated how much we had and how much we would get done, so the sprints and overall release didn't go as smoothly as we would like, but again, given the circumstances, I think we did fairly well. This was our rockiest release yet we still delivered on the vast majority of what we said we would, and the things that did not get completed were non-essential things that would be done in the future if work were to continue. 


As a final conclusion, I'd just like to say it's been a pleasure. I've enjoyed this semester immensely, I've learned a lot, I feel as though I have grown as a person, and I have most definitely made some friends for life through our shared anguish. My team has been exceptional, their productivity has been infectious, and I am certain I will miss working with them. 

Week 13: Beta Release


  • Release set up
  • Minor fixes 


We set up the release on scrum this week. This release was a fairly easy one to plan. We sat down and discussed what we absolutely had to do for beta, along with considering what else we could do feasibly. User testing was priority number 1 from the get go. Last week we tried to do all of the user testing before the release so we could make changes based on it, but essentially it became the sprint where we get a handle on user testing. We did the document and pilot testing last week, so for the release we now have a good system for how to do the user testing properly. After planning out exactly what tasks the user testing was made up of, we looked at each individual area of the game to see what else had to be done. So for example more work on dirtying up the track, as well as texturing the bike and hands. We planned the release to be done a day before the official upload, which is on the 19/5. We're fairly confident it will be done well before that, but we always try to plan for the worst case scenario, so we did this just in case we don't get the work all done well before then. 

The tasks I took on this week were based on some of the feedback from the pilot testing which was done with the gamers. So it was suggested to add face button key bindings for the controls because some people prefer them to the trigger buttons. Other feedback was that the reverse isn't strong enough, so I upped the force on this. Finally, it was found that the users were restarting the level often, so I added a button dedicated to this instead of having to pause the game and then select the option. These tasks took less time than I estimated them to. I estimated them to take an hour each but it was less than an hour for all 3. I did this on the off chance of there being bugs encountered, but I've learned for next time that small tasks like these are generally safe to estimate more harshly.


No major issues. Set up the release without any hassle. 

Week 12: User Testing Sprint


  • User Testing
  • Further constraints


The sprint didn't really go as smoothly as we would have liked this week. Essentially another subject that the team was working on together took up a lot more time and effort than we had expected it to, and as a result we didn't really have much time for team project until very late into the sprint. The burndown is very cliff dive like as a result, and some work that we were able to put off until release we did. The key work this week was the user testing and its document, which we got done.

For the user testing document, I helped Ronan with the script structure and content. There were no real problems here. 


Main issue was time, which we just didn't have enough of. 

Week 11: Alpha Results


  • Alpha presentation results
  • Planning



This week the team was very busy with other areas of the course. We decided it would be best for us all not to do a sprint, since we were simply too busy with other more urgent matters. 

We got our results back for the Alpha presentation. I think we're all really happy with how we did, and are proud to have done so well. Some of the feedback we got was to improve the sound and visuals some more, but mainly to focus on user testing. This is something we will have to do completely next week if we're to have a release. 

Although we were not on a sprint, we got to doing some initial work on the user testing document. We also planned out the backlog for release some more, though we were told not to try and do much more to the game which I think is good advice, since we have so many other assignments to work on. 



No issues this week bar the fact that we were too busy with other modules to really do much for the team project. 

Week 10: Alpha Delivery


  • Upload
  • Presentation
  • Last minute fix
  • Backlog filling out commencing


We had the sprint officially finished last week, but there were some things that were still worked on afterwards, which is perhaps bad scrumming but they were such minor and obvious changes that I didn't feel like a sprint was necessary. Most of the work this week was either preparing the material for upload or preparing for the presentation. 

I'd done the presentation material last week, so preparing was simply a matter of looking at the slides and going through them. 

On the upload day I helped with gathering some of the necessary upload material. 

There was a bug with the printing of the split times that we only noticed before the presentation that I helped fix. 


Finally we started filling out the backlog this week. The one thing I'm not sure of is how we are supposed to deal with user testing based tasks. I've contacted Gerry about this and it is something we are still in the process of ironing out. Further more, we are very busy this week and have decided to not do a sprint. Hopefully by next week the user testing scrum stuff will be sorted, and between now and then we can set up the rest of the backlog and start our Beta release. 



So firstly, we got very good feedback. One of the biggest criticisms we got was on the bike bell sound slightly breaking immersion when you get the next split time, which says a lot about how well we did. I was surprised to hear we were the only team to switch to hours for estimations, because we think it makes way more sense. The key points to take away from the feedback was to get working on user testing and feedback. I'm glad we did well again, because we worked hard this release. 


No real issues this week other than the bug fix which we sorted. 

Week 9: Sprint 9: Last Push


  • Scrum
  • Presentation Material


This week I didn't have very much to do. I'd planned for this to be the case on account of there being so many assignments due for other modules. 

Setting up scrum was no problem. We didn't have to meet, I just had a small few things to check with people individually which I did over facebook chat. Most of the tasks had been estimated out before, but I just wanted to confirm some of them with the group to be safe. Hassle free. At the end of the sprint, there was a task that Mark couldn't do, because he'd recently had health problems, so I took it off the release. Technically we fell short of our target by a point of work, but we'd have comfortably reached that goal were it not for unforeseen circumstances. 


The final sprint is also quite flatlined because the majority of the work was done in the last few days of the sprint. We all knew this is how it would be, as there were other modules demanding our attention. Furthermore, it's a fairly small sprint, so getting it done in a smaller number of days was something we knew we could do.  


For the presentation material, I had to prepare material for the bike features, along with the process material (i.e. how we got on with scrum this release). This was easy for me as all I had to do was go back over these journals and see exactly what I'd done for the Alpha release. I will need to wait for the sprint to finish to get the screenshot for the alpha release, but we all have a few little bits and pieces like this to do that isn't on the sprint before we submit, which I think is fine. 


No issues this sprint, and generally a much smoother release in my opinion. We made sure to scope realistically, and we went (expectedly) above and beyond this target. 

Week 8 - Sprint 8: Alpha Halfway Mark


  • Scrum
  • User testing
  • Physics based on timesteps instead of ticks
  • Customisation file saving and loading
  • Customisation loading into the bike properly


This week for scrum, since we felt we were ahead of schedule in terms of our progress, we decided to add more tasks to the release. We felt as though the extra work would not be a problem, and some of it was vital things we simply didn't have the foresight for needing. We discussed it firstly in the scrum meeting whether it was wise to incrementally add work as we felt it was doable, but agreed that this could get out of hand as a form of feature creep could begin to occur. We also didn't try to overextend ourselves in terms of what we did add. We had 194 points of work planned originally, and we added 14 more points, which brought us back to being exactly 50% of the way through the release, since we were ahead of schedule. 


This is our release as of the end of this sprint. We'd planned from the start for the last week to be slightly less work so we'd be ready if things went wrong. So as mentioned already we added some tasks, as can be seen in the bump in the release target line. Overall the release has gone well, and should continue to. It's a much more steady rise thanks to our reform in how we worked with scrum, and I'm happy that we managed to get things turned around. 

Moving on to my actual tasks this week: 

I was assigned the user testing task, mostly as a formality (but also because myself and Ronan were heading up the user testing to some extent due to being the so called "Bike guys") and this task basically entailed our key user (John) sitting down and playing the game to critique it. We have another user testing session planned for after Easter also. This was useful for getting some balancing things cleared up with how the bike behaves. 

I was assigned the task of investigating into whether changing the way the bike physics works was viable. So currently it is based on the number of ticks, so it makes the physics very much machine dependant. As a result, slower machines get a bike that just behaves erratically. Essentially though, it's not an option. It's actually a very difficult and arduous change, which I didn't expect. We'll stick to our compromise of requiring a powerful machine to play the game properly. 

Next, I worked on the file storage part of the customisation system. For this, I essentially took the same approach as I did with the split times. So since the customisation occurs in its own scene, I had to make a blueprint similar to the levelplayer that has all the save and load functionality. I simply called it CustomisationPlayer to stick with the convention we have going, and got to emulating what I'd done before. Myself and Ronan had been discussing what would be customisable on the bike and how it would be customised etc, so we'd already ironed out this stuff. This meant I had the 3 variables (brakes, tyres and frame) ready to work on. I made the CustomisationSave file and gave it these 3 variables. Then I made the save and load functions in the CustomisationPlayer. 


Speaks for itself really. The CustomisationPlayer has a reference to the CustomisationSave file, and it is written to with the 3 files that are set in the blueprint by the menu inputs done by Ronan. 



These pictures are the LoadCustomisation function. Again, mostly speaks for itself. The file is either loaded in, or created with the default values. 

The way these are used in the eventgraph can be seen below. 


So when the scene starts up, the load is called to use previous settings. When the scene is exited, whatever settings put in are saved to file. 


Next I had to link all of this up to the bike itself, in the HoverCar blueprint where the bike functionality is. This proved to be more difficult than expected. I expected it to be as simple as with the split times, where a reference to the CustomisationPlayer would be in the HoverCar blueprint and the values simply gotten from it. However (and it took a long time for me to realise this simple problem) because the CustomisationPlayer is destroyed outside of the customisation scene, it can't be used outside of it. So, (with the help and advice of Shane) I simply replicated the load function in the bike blueprint. 


This got the numbers being loaded into the bike, so now the customisation works. This task took more thinking than actual work, trying to figure out how to get this loading working properly was more difficult than expected, but I got there. 


The issue mentioned above with the load taking a while to work in the bike blueprint was the only real issue I had this week.

Week 7 - Sprint 7: Alpha Continued


  • Scrum
  • Fix first person camera
  • Improve first person camera
  • Force feedback (controller vibration)


This week I took a little bit less work than usual because I had other things to do at home, and I wanted to try and get more work done on other projects. 


So firstly setting up Scrum this week was fine. It's the first week where we estimated in terms of actual hours. This was fairly easy since we were doing this before PoC but just called them points. We weren't sure at the time of setting up the release when it was meant to be delivered exactly (we had a week number) so we aimed to have the release done early deliberately to account for problems during the release, as well as giving ourselves extra breathing room leading up to the delivery. We now know the actual date, and we are on target to be done on time, which is good. No real problems here really, I've been keeping an eye on each team member and everything is fine generally.


The first task I did this week was to fix the first person camera so it doesn't allow the user to rotate 360 degrees. I first looked up some things online, and found something that turned out to be exactly what I needed [LINK HERE]

I added a spring arm to the bike for the first person camera, as it previously didn't have one, and spent some time playing around with its location and the angle of the camera before I started developing the constraints, as it had to be in a good way to begin with. 

I essentially implemented what I found in that link, then played with the numbers until I was happy with the result. See below for the implementation. 


The key nodes here are the clamps, which basically limit how much the camera can move. This wouldn't have worked in the old implementations of the camera because they were based on incrementing the rotation rather than setting it. 


I also took a little bit of time to tidy up the bike blue print in general, which wasn't in any way necessary but I feel like it helps for finding things. 


My next task was to make the camera snap back to the default position, because it had to be readjusted manually before this, and this was found to be distracting and annoying, and generally not ideal. I'd been thinking about how I would do this task for a good few days now and had been bouncing ideas off other team members, and Shane suggested I try an RInterp node, which is a rotational interpolation. I definitely spent more time thinking about how I would do this than actually implementing it in the blueprint, which meant that the actual setting up of it only took a short while. See below for the implementation of this. 


So basically if the player is not rotating the camera (input values are 0) then the camera will interpolate back to its default orientation. 


My next task was to add some kind of force feedback (we went with the crash as it is most obvious) so we know how to add it in other places for later in development. Again, I spent more time investigating how to do it than actually doing it. It was much easier than anticipated. I did a bit of looking around online and found the Play Dynamic Force Feedback node in the UE4 documentation HERE


As shown above, I have simply connected the force feedback node to the crash code. I gave it a duration of 1 second for now, but later this will be set back to a negative number so the vibration is stopped dynamically. I've also given it a set intensity which will again be set dynamically down the line based on the intensity of the crash. Note also the ability to affect only parts of the controller. I can picture the controller vibrating on the side the player is steering into for example, and having the vibration change based on what type of terrain the player is cycling over, to name a few possibilities. 


Based on feedback from our key user, we were told to take one camera and stick with it, and we decided as a team to drop the 3rd person camera. This wasn't an actual issue because I agreed with the decision, but it just meant that a lot of the work I'd done on it was a waste of time. 

Week 6 - Sprint 6: Alpha Release Plan


  • Release setup
  • Camera bug fix
  • Timer saving and logic


This week we set up the release for Alpha. In the process of this, we had to have a major rethink about how we are using scrum based on the criticisms of how we use it. We also took on board the advice to be more strict about culling parts of development that are less essential. Finally, we made sure to break down goals and tasks as much as we possibly could, to ensure more transparency was there in our development process. 

Thursday (the first day of our release and sprint, the day after our presentation) myself and Ronan spent a good portion of the morning considering ways to redefine how we work. After a lengthy discussion, we ended up looking at it as "a week's work is 13 points at most". By week's work, we mean the effort a single sprint worth of work is given. This way, it ensures that nobody is doing too much, and because all the tasks will be broken down immensely, nobody will be doing too little either. Furthermore, if we aim for around 10 points a week each, it ensures that if something is underestimated, there is a spare bit of effort available to make up for that task being more difficult than expected. 

Later that day we had our meeting, and we discussed this new way of working with the rest of the group. We all agreed that it was a good idea to do Scrum like this moving forward. We then started breaking down the tasks we considered for Alpha from the presentation, as well as whatever bug fixes that needed done from PoC along with any other tasks that were required from us but not consciously planned, like the lighting document as an example. We all spent time looking over the story point estimates to see if there was any misunderstandings and ensured everyone understood what was involved with the tasks and sorted out any objections. Myseltf and Ronan had made a head start on the tasks earlier in the day, so we got all of our tasks planned, broken down, estimated and relatively prioritised, so we made sure to run these by the rest of the team. We spent the entire meeting planning and estimating tasks, but we ran out of time. I didn't think it was wise to try and continue over hangouts, so I just told everyone to look at estimating more of the work to be reviewed the next day, along with the prioritisation process that we were yet to go through. 

The next day, we continued our work at sorting out the tasks. We spent a lot of time brainstorming things out for what needs to go in the release, what would be nice to go in the release etc. The way we estimated the points is a more streamlined planning poker, where each individual still comes up with an estimate for the tasks, but the tasks are then scrutinised as a group until there is absolute clarity about what is involved and how difficult it will be. We found that this works very well, as it saves a lot of time but still works the same as planning poker. 

Our prioritisation process was very similar to this. I made sure to keep the backlog items roughly grouped together by area as the items got added, and this meant that each area of the game could be prioritised within its own section so that when we went to add it to the release we could clearly draw a line across that area for things that made it in to the release and things that didn't. Each person prioritised their specialist area, and then this priority was re-evaluated as it was added to the release by the team as a whole. Being able to see these changes made in real time made things easy, as everyone was on their own machine. 


I had the entire team in the same room on Scrum at the same time, so as things were being done we were watching and discussing it as a group. This process of individual development followed by group filtering sped the process up.

I'd estimate that we spent 4 hours over the two days working on this as a collective group, and an additional 4 hours being myself and Ronan discussing how to proceed along with individual people planning and sorting the tasks in their own time. I feel like this was a slow but necessary process, and now that it is done and prioritised the weekly meetings should be suitably brief. 


I spent the rest of Friday to Sunday working on things from other modules. 


On Monday, I started working on fixing the camera bug (after a little bit of help from Shane getting git to work properly). I essentially spent the time I had available for this on Monday pursuing dead ends however, as nothing was having the results I wanted. I spent my time trying to re-write the way the 3rd person camera worked entirely, and getting it to rotate and move while focused on the bike just wasn't working properly any other way I tried it. I went to bed and slept on it. 

On Tuesday, I started my work on it by trying to modify what was already there. I took the thing that had worked best from Monday evening, which was to modify the spring arm, and integrated that into what we already had. Essentially, I tried to rotate the spring arm by the same pitch as the bike is rotated as it goes down through the level, and this worked fairly well, so I put some constraints on this to make it behave even better. For example, when the player is on level ground, rotate it up further than usual to let the player see further down. 

Next, I changed the camera rotation to rotate around an arbitrary point that I set to be slightly in front of the bike, as I felt like the bike being the central point of focus wasn't working that well. I set up a variable, got the bike position, got the forward vector of the bike rotation, added them together, multiplied up the vector to be able to control the points' location, and used the LookAtPoint where I was using the bike position previously in the rotation code. 

I then moved on to working on the split times implementation. I first looked at Shane's saving code in the UMG Options blueprint, since saving and loading is the most important part of this problem. I essentially spent the rest of Tuesday evening thinking about how I will do it, and I wrote this down, which I will paste here:

"The bike overlaps with the trigger box, then get a snapshot of the current time into an array (using a doOnce?) and do this a number of times throughout the race up until the finish line (so these are all split times). Then you have the "best times" or whatever already loaded in or something, compare the corresponding times, get the difference and print that all out.. For the end logic do a simple check to see if you had a better best time overall and if you did then you overwrite what is in the "best time" file. "

I knew what to do but not how or where to do it properly. The "whatevers or somethings" were the areas I was less sure of, so I asked Shane and he said he should be able to help me on Wednesday so I retired for the night. 

Wednesday morning, I got a few pointers on how to do the saving and loading from Shane and got to working on the split time stuff. It took a good bit of help from him to get me started properly but once I got on track things started to go better. 

I'll explain my process in steps below:

  1. Make a SplitTimeSave class that extends the SaveGame class and give it the 4 time variables to be saved (3 split times and a final time)
  2. Make a SplitTimeTrigger class that extends the TriggerBox class. Give it a SplitTimePosition integer variable and a reference variable to the LevelPlayer
  3. In the LevelPlayer, make a LoadSplitTimes function that loads in the times from file or sets up defaults if there are no files and stores them in the SplitTimeSave file, which is referenced in the level player. 
  4. Create a SetTimeSplit function in the LevelPlayer and have it be called everytime the player triggers a SplitTimeTrigger. In the SplitTimeTrigger, the SetTimeSplit function is called and passes the SplitTimePosition (essentially which trigger box it is e.g. the first one etc) in, which sets the corresponding float in an Array of split times. If the box that is triggered is the finish line, then the FinishRace function is called. 
  5. In the FinishRace function, the first thing that happens is a FinishRaceEvent is fired to stop the timer as the player crosses the finish line. The player's final time is then compared with the time that was loaded in, and if it was a better time, the SaveSplitTimes function is called, which writes the times from the current run out to file. 

This is not the order things were developed but rather the order in which they are done to create the desired system. I will show below the different blueprints. 

This is the SplitTimeSave file. 

This is the SplitTimeTrigger class. Note the SplitTimePosition being fed into the SetTimeSplit function. 

Here, the local SplitTimes array is set based on which trigger box is triggered. If the final one is triggered, FinishRace is called. 

The FinishRaceEvent is for stopping the actual timer on in the event graph. The local time is checked against the stored time, and if it is less, it is stored to file in the SaveSplitTimes function. 

The local times are fed into the SaveSplit object which is then saved out to file. 

This entire process is prefaced by the LoadSaveTimes function, which is called at the start in the event graph. Here we see the times either getting loaded or set to their default values. 

Here we see the LoadSaveTimes being called on begin play, and the FinishRace event causing the Timer to stop. 


Scrum wise (heh), there were no issues other than on Wednesday, a few of us were behind schedule so we took some stories off the sprint to be done next week. This is a minor problem with planning in some way, but we feel as though we will make the time up next week to get back on schedule. My main issue was the camera bug fix taking too long and ultimately still not being very good even after all that. 

Week 5 - Sprint 5: PoC Delivery


  • Scrum
  • Group Mahara Page
  • Presentation content
  • Presentation


This week we had a big scrum meeting to address the issues discussed in last weeks issues section. We all got together and myself and Shane explained the issues more clearly to the rest of the group so everyone understood fully what the problems were, and we all talked about what we did and didn't agree with, as well as ways to improve moving forward. 

We also sorted out everything we needed in preparation for the presentation. We'd aimed to be basically done by this sprint because we knew firstly that if things went horribly wrong, we could use this sprint to recover our progress, and secondly that we wouldn't have much time to do much in this sprint, since the submission is 2 days earlier than the day we finish our sprints on. We got the sprint set up without issues, and made sure to put our planned improvements back into action here (for example, we did planning poker again, and ensured that the tasks we were doing were tangible and clear). 


The first thing I did this week was to do my presentation content up because Shane needed them for Saturday afternoon so I got to working on them on Friday. I essentially had to summarise what I had done and look at what we would do for Alpha with respect to these areas. This obviously would be hammered out more clearly when we plan the release after the presentation, but we needed plans for alpha in the presentation. I wrote down what I'd done on Friday and got to thinking of what could follow on from these areas, as well as look at what else would be needed for Alpha. 

The next morning myself and Ronan had an hour long chat on Messenger, and discussed a lot of what could be done for Alpha.

One of the things I considered investigating was the idea of having replays, which was written off earlier this semester as something that was unlikely to be possible. However that was where there was a Camera object capturing an actual video. I looked into it from a different angle, where instead of capturing a video of the player going downhill, we simply recreate it, by recording the player inputs and feeding them into the game again. This way, we make the same actions happen again, essentially showing what the player did. And then as well, we could have various cameras where the player can view their actions from different view points.

Ronan agreed that this was probably much more possible than the other way, but he looked into it some more and made some good points that recording the inputs would not be a small job, and neither would inputting them again to recreate the player actions. So we considered it as something that should be investigated, but not a priority. 

We talked a good bit more about things we can get done for Alpha, divied up who would send what to Shane (to avoid stepping on eachothers toes) and sent them on.


The next thing I did was the Mahara page. Myself and Brian took on the task of updating the Mahara page, and this is something we decided to work on together. We work very well as a pair and find ourselves to be more productive when we work off eachother. This was a fairly easy task overall but it took a bit of time. We had to gather images, videos and information to put into the page, along with links to the mahara pages of each team member. Again, this was easy, as we are in near constant communication with eachother through or group chat. 



The overall feedback from the presentation was very positive. The key points we've taken away from it is to be ruthless in our planning when it comes to what gets in for alpha and what doesn't. In terms of Scrum, we simply need to start using it properly again, because they can't see what is being done pretty much. 

We've already got to improving how we do scrum as it is, and we will have our release planning meeting tomorrow (Thursday, day after the presentation). It's been an essentially ongoing discussion among the group since the issues were brought to our attention so we are well prepared to fix the problems. 


 Any issues have been discussed above.