- William Torkington
- torkinwill
- Lead Developer
I made all of:
- The Fly Zone
- The Zone Controller
- The Healthbar
- The Main Menu
- The Death Screen
- Static Ground
I also made all of the following, which unfortunately did not make it into the final game:
- The Battery Bot
- The Charging Station
- The Charger
- The Battery Port
- The Battery Bot Movement Triggerable
- The Zeuthian Level Two
I made most of:
- Fly Bot
- The Level Blueprint (in charge of character death)
I made some of:
- The Button
- The Hold Lever
- The Timed Lever
- The Toggle Lever
- Standard Bot
- Gas Bot
- Heavy Bot
I touched:
- The Constant Elevator
My favourite code contribution of mine to the project was Fly Bot's hover script. I found my love for mathematics last year and rediscovered the beauty of trigonometry, so when I heard that they wanted Fly Bot to hover I was more than happy to do it.
I did not use as many comments during development as I would have liked, but I was quite proud of this one. If I did it again, I might remove the formula for the sine wave because that to help myself understand what the function should be doing. After the fact, I understand other developers might get just as little benefit from reading the formula on a comment as they would trying to parse the blueprint as is, but that would eventually come down to the particular set of developers I would be working with.
Quite ironically, the piece of code that I think is ugliest is in the same blueprint: the zone adjustment function. The excerpt below shows the massive pile of spaghetti that checks first if Fly Bot is above the zone bounds, and to move it down, then it checks if Fly Bot is below the zone bounds to move it upward.
There are two main ways this is a bad blueprint, poor connection readability, and too much going on in one method. The first part is because I hadn't realised that you can double click at the point of the creation of this blueprint. If I had it would be better to minimise the number of overlapping wires between nodes in order to provide a clear idea of linearity from one point to the next. The second is that there is a lot of repeated code in here that could be refactored into seperate functions which would make the code much more reasonable.
Because this project is written mostly in Unreal Engine blueprints, what I learnt falls into the realm of video game development, or the abstracter nature of project development at large.
Using Unreal's blueprint system has been a refreshing look at programming, especially when contrasted to the moments of frustration plunging my hands into C++ that punctuated my experience. As time went on, I learnt not only to parse the webs of computation that controlled the stage and actors, but also to translate that visual knowledge into a better understanding of the program itself. What I found most shocking to begin with is the non linear nature of blueprints - the program bend and flow, branching out and creating confluences of data. To be more precise, I learnt to look at the familiar programming objects I know, the variables, the functions, the classes, casts, and calls, in Unreal's dialect of C++.
That is not to say that I am not glad to have refreshed my knowledge of C++. Even the morsel of time I got to spend stepping back into the harshly typed environment of C++ programming taught me volumes about the language. It wasn't until this class that I truly understood what those pragma directives meant, this class where the dot, arrow, and double colon finally clicked, and not just what header files are for, but why they’re needed. It might be obvious but I should note that this did not come from the course website, or the pages of UE4 documentation, but the long hours of reflection trying to piece together what my teammates had done in the last commit, and how I can incorporate that into my own work. I did not mention my contributions to the C++ that we used because my contributions were insignificant - a variable here, a fix there - but what it taught me, and why I learnt it, was worth the work of the entire class.
Finally, I think the most important thing I learnt doing this class were the ins and outs of actually working as a team. Of course I have used GitHub, and made the occasional Trello board, but the use of GitHub's project system and the use of its smart commits changed how I see the platform.
I spent a lot of my time creating issues, or telling my team mates to throw up issues, or telling them to close their issues, or tagging the issues in commits. Something that until this project I did not use, but I now feel would be impossible to program as a team without it. Not to be too overdramatic, but it felt profound realising that instead of trying to condense hours upon hours of work into a single commit message, filled with trailing hashtags, I should work on one thing at a time in order to make the commit messages cleaner. This in turn made my workflow more focused, and I gained a better understanding on what I should be doing throughout the project. Half way through the project I looked at the number of commits by teammate, and I noticed I had almost double the number as the second highest teammate, which absolutely did not reflect the proportion of work we contributed, I only see it as a reflection of the focused work that I was doing; a reflection of a process that made many smaller changes rather than a few heavy ones. This ideas value became extremely clear when I had to revert to a commit Where some progress had been swallowed by a merge somewhere.
Resolving merge conflicts in this project was some of the most gruelling work I have done at university. I learnt the hard way you cannot merge binaries the same way as code. I learnt that GitHub desktop has a hidden but lifesaving feature that makes merging much easier than the vim-like merge tool on my command line. I learnt this all after many hours of hair pulling in the computer lab. I will be forever thankful I looked like an idiot trying to merge binaries in front of my student colleagues instead of in an internship.
My final note on GitHub is that this project taught me that there is still a lot of stuff to learn. I had a hard time using the milestones functionality, and it is still a mystery how to merge Unreal files in a way that means I can delete things off of the levels without the engine crashing, which was a very large issue.
In terms of working on a video game project specifically, there was a moment that I realised I could spend every day on the project and still have more to add at the end of the trimester. A video game is a large undertaking, and there are many emotions involved. Our lead designer, bless his heart, felt very passionately about the project, and I felt like it was rude at the beginning to tell him, no, we might not be able to produce everything he had planned. So, as time went on, it felt like I was falling farther and farther behind on where we should be. This also meant that I spent a lot of time and energy working on frivolous features that did not make it into the final hand in at the expense of polishing off the good work we had put so many hours into. It also ate into time we should have spent on doing more elements of our actual assignment, such as the video, README, and packaging the project. The first two of which were only completed days after the hand in day because we were up until 2am on hand in day finishing off a part of the game that ended up not being complete enough to put in the final game.
What I can take from this project is the confidence to tell the next project manager that we want something small and good, or else we will end with nothing at all. This is a common sentiment that I have heard from other people before, but this is truely a case of learning from ones own mistakes.
I hope you will forgive me for not highlighting one point in particular, and taking a more anecdotal, prosaic approach to this section of the report, but I truely believe all that I have learnt over the course of the past few months have been incredible. This course has been of immeasurable value to me as a developer, and it has been a pleasure and a highlight of my university career.