Swamp Escape (January - May 2014)
For second semester, we were placed in larger teams and given a brief from a client. The MProf team consisted myself and another coder, 2 artists, 2 designers, 2 audio producers and the same producer from the first semester. We also had 5 coders brought on from the Masters CGT course who had been working in UDK during semester 1, which was one of the reasons that it was predetermined that we would use that to create the game.
The game it turned out was for the mobile platform. I felt that using UDK was slight overkill but continued to try to learn it regardless. Two weeks in and I was only frustrated with the stifled progress, UDK's documentation is piss poor: not particularly helpful but also riddled with grammatical errors and other oversights, I felt like I was constantly having to battle against unrealscript to the point where it felt depreciated by kismet, and a semester of that wasn't something I was particularly looking forward to. One of the worse parts of UDK was the work flow, it was such a ball ache to create a distributable package. I decided to pitch to the team the possibility of moving across to use Unity instead. The art/design/production side were happy enough as it was a learning experience for them either way, the problem was whether the CGT coders would be ok with the change. It turned out that 3 of them were already familiar with Unity and one of those who hadn't were familiar with C#. With the team backing the idea, I created a list comprising of my argument for the switch and then went about spending 3 hours of that afternoon recreating what I'd managed in UDK. It was so easy that I actually ended up adding in improvements. When it came to pitching the idea it was surprisingly easy, to the point where I didn't even need to argue my case, the decision ended up falling on whether UDK was integral to the CGT's syllabus. Fortunately we were given the go ahead and I began to feel more confident in our ability to deliver on the excessive promises made by our producer for frequent builds.
Going into the second semester, I had been tasked on keeping an eye on the other MProf coder as it hadn't been clear in first semester whether he was competent or just full of it, as he was very adamant to make himself heard. I too struggled to place whether he was a capable coder, I found working with him difficult because he was quite passive aggressive, which was irritating and he was terribly disrespectful of other peoples property, I lost a number of pens to him. The role of keeping an eye on him ended up being evolved into being the code lead and being given the responsibility of making sure all the coders kept on track with their tasks as well as dishing out said tasks. I grew to hate this position. My perfectionists nature lead to me feeling responsible when other people weren't capable of keeping on top of their tasks. Semester two was ridiculously stressing work-wise: on top of the group project, I had my part time job, 4 other modules and also 3 other projects I had taken on outside of Uni. Other people were in similar positions, so I could understand them being bogged down, but didn't feel it excused them nor resolved them of their responsibilities within the team. On numerous occasions this lead to me working until late trying to bring the builds up to scratch and fix other peoples mistakes because I couldn't rely on them to fix them in good time. As I learnt of the varying capabilities I tried to move around the work load accordingly.
My experience during the second semester wasn't a pleasant one, which was a shame because if I was less miserable and stressed, I might've been prouder of the work that I produced. I mainly worked on the procedural generation aspect of the game, which was an integral part of the game. Not only was a pleased with the solutions that I had come up with, but also how I was able to adapt those to accommodate the design requirements laid out by the game design document.
The game is currently under NDA so I can't actually show anything, but I'm hoping to be able to in the near future.
The game it turned out was for the mobile platform. I felt that using UDK was slight overkill but continued to try to learn it regardless. Two weeks in and I was only frustrated with the stifled progress, UDK's documentation is piss poor: not particularly helpful but also riddled with grammatical errors and other oversights, I felt like I was constantly having to battle against unrealscript to the point where it felt depreciated by kismet, and a semester of that wasn't something I was particularly looking forward to. One of the worse parts of UDK was the work flow, it was such a ball ache to create a distributable package. I decided to pitch to the team the possibility of moving across to use Unity instead. The art/design/production side were happy enough as it was a learning experience for them either way, the problem was whether the CGT coders would be ok with the change. It turned out that 3 of them were already familiar with Unity and one of those who hadn't were familiar with C#. With the team backing the idea, I created a list comprising of my argument for the switch and then went about spending 3 hours of that afternoon recreating what I'd managed in UDK. It was so easy that I actually ended up adding in improvements. When it came to pitching the idea it was surprisingly easy, to the point where I didn't even need to argue my case, the decision ended up falling on whether UDK was integral to the CGT's syllabus. Fortunately we were given the go ahead and I began to feel more confident in our ability to deliver on the excessive promises made by our producer for frequent builds.
Going into the second semester, I had been tasked on keeping an eye on the other MProf coder as it hadn't been clear in first semester whether he was competent or just full of it, as he was very adamant to make himself heard. I too struggled to place whether he was a capable coder, I found working with him difficult because he was quite passive aggressive, which was irritating and he was terribly disrespectful of other peoples property, I lost a number of pens to him. The role of keeping an eye on him ended up being evolved into being the code lead and being given the responsibility of making sure all the coders kept on track with their tasks as well as dishing out said tasks. I grew to hate this position. My perfectionists nature lead to me feeling responsible when other people weren't capable of keeping on top of their tasks. Semester two was ridiculously stressing work-wise: on top of the group project, I had my part time job, 4 other modules and also 3 other projects I had taken on outside of Uni. Other people were in similar positions, so I could understand them being bogged down, but didn't feel it excused them nor resolved them of their responsibilities within the team. On numerous occasions this lead to me working until late trying to bring the builds up to scratch and fix other peoples mistakes because I couldn't rely on them to fix them in good time. As I learnt of the varying capabilities I tried to move around the work load accordingly.
My experience during the second semester wasn't a pleasant one, which was a shame because if I was less miserable and stressed, I might've been prouder of the work that I produced. I mainly worked on the procedural generation aspect of the game, which was an integral part of the game. Not only was a pleased with the solutions that I had come up with, but also how I was able to adapt those to accommodate the design requirements laid out by the game design document.
The game is currently under NDA so I can't actually show anything, but I'm hoping to be able to in the near future.
What did I actually do?
For the second semester of my Masters course, I worked within a team of 14 to create an iPhone endless runner game. I was the lead programmer and tasked with organising the 6 other coders to make sure that the game's functionality was on track with the schedule. I was also responsible for the procedural aspect of the game, including the path generation.