Submariner

TDEMO Game 5

This is our final first year piece for TDEMO and for this one we were allowed to create our own teams for the first time. This was a very nervous time for many of us including myself. I always work hard and have the best intentions but even still I wasn't sure that would secure me a place on a good team. I was lucky enough to be asked by a few people to work on projects with them and for that I was incredibly honored. Among the few offers was a rather mysterious offer in the form of being added seemingly randomly to a group chat of some people I had worked with and some I hadn't. I must say it was the first offer in fact and thus I did feel a sense of obligation towards it. That and the mysterious nature of the project added some extra appeal.

I soon found out that the team I had been selected for was to be working on an external client project organized by the university of Portsmouth and The Royal Navy. The mission brief: Create a royal navy submarine simulator from the perspective of a planesman and periscope-man. The simulator was to be made VR compatible and two player, one planesman and one periscope-man. The purpose of the simulator was to be used for recruiting purposes and thus should be relatively short but very appealing.

We begun by creating a discord server with text channels for different aspects of the development process.

These are: - Programming

- 3D modelling

- Art / UIUX

- Sound

- Video assessment work

- General project discussion

We all got together and had a meeting about how we would be approaching the project and the details of the project. At this time it was actually still unclear if we would be doing the external client project or not and so there was a large amount of disorganization and confusion all around the team. We eventually got confirmation that we would be having a meeting with the navy contact to discuss the project brief. During the time leading up to this meeting there continued to be a large amount of confusion from many members of the team. We had begun to create planning and design documents but without hearing the brief first hand it was hard to say for certain what the client was looking for. Due to this uncertainty we were hesitant to commit fully to any tasks which could require a lot of time and then become unnecessary.

Many of us turned to simply researching which was really the best thing we could do in the situation. I personally feel I should have done more research and gotten more involved in helping to plan the project at this stage, but at this point I was only expecting to be working on the audio for the simulator/ game.

Once we had the meeting with the client we were a bit closer to truly getting started. Unfortunately we were already so scattered and out of sync with each-other it wasn't until some time later that we really managed to make any significant progress on the project and get out of the research and design phase. Unfortunately for me the meeting did not really aid me in my research or design. This was unlike anything I'd ever done before, the usual comical, retro sound effects and music I was getting used to making wasn't going to work for this project. The audio needed to be realistic and accurate to a submarine and the music would need to be fitting of a war simulation. 8-bit, upbeat, chill, Lo-Fi music wasn't going to work for this and so I was going to need to try to create something with a sense of suspense, tension, urgency and authority. Something that sounded a little more official and fitting of an armed forces simulation game.

I didn't truly make much progress until we undertook what we called a game jam, but could effectively be compared to a sort of pre-emptive crunch. The idea here being that because we had spent more time on research and design than any of us had really wanted, to make up for this lost time we would come together to develope a prototype of the game. During the game jam I dedicated a couple days and nights to finalising my research. I had create a reasonably comprehensive list of ambient sounds that could be found on board a submarine. I used

various clips from submarine games, submarine scenes in movies and some clips from the royal navy submariner recruitment video advertisements which are available on YouTube, during my research to help build a sense of what being on a real submarine would sound like. I made note of these on a miro board created by Amy Elliot. Pictured bellow are the sounds concepted during the game jam.

For me the next phase of the game jam was spent researching and learning Fmod for unity. Fmod being a tool used for more easily implementing and manipulating audio in games, and in this case specifically into the unity engine via their plug-in system. Fmod seemed to be a really promising software which could allow me to focus much more on the sound design and overall immersion rather than the implementation and coding of the audio. Unfortunately once we implemented fmod into the project it very quickly begun to give us errors and we were spending a lot of time trying to correct them on a regular basis. At the same time as this we realised that the liscence for fmod was going to potentially be an issue too. Fmod will issue a free liscence to some small or independent devs for projects but the specific circumstance of our project was arguably not within the specifications of the liscence. Given that Fmod was already causing us isses we decided to axe it from the project.

I needed to code the audio into the game myself, something I hadn't done before so with a few pointers from other members of the team I spent a short period of time researching the basics of Unity audio implementation. I watched a few basic tutorials found on youtube and also looked through the Unity documentation on audio clips, audio sources. I learnt about the different ways you can play an audio clip through an audio source and how you use scripts to create logic for even greater control over how and when audio is played. Once I was happy with what I'd learnt I went back to sound design.

It's at this point which it is worth mentioning that due to personal issues our previous team lead decided to step down and I took over as team lead. This was the biggest team and the biggest project I had lead and I was taking over at a late stage with a team who were relatively splintered already. As I took over the role I needed to get up to speed on the whole project and everyone's individual roles within the project. I knew roughly who had been working on which element of the project but Ihadn't been keeping up to date on the ins and outs of what they had been doing. We agreed that going forward we would try to emulate a studio environment where we'd all be on call at the same time and we'd begin doing "stand-up" inspired progress meetings to share what we've been doing and try to keep everyone working coherently and cohesively.

As mentioned previously the team was relatively fractured or splintered when I took up the role of team lead. I believe this was largely due to differences in ideals surrounding how quickly work was being done and how it was being communicated. I believe that the online working element of our project had a significant impact on the situation as where we were working closely together for long periods of time with more than a few creative differences and no possibility to meet face to face for either work or leisure, the tensions rose and stresses mounted. Without in person face to face work there are many nuances of human communication which are lost, for example non verbal communication in the form of facial expression, hand gestures, posture and other subtlties are all lost. High resolution video cameras paired with high speed internet may be a suitable solution however it's hard to imagine anything will ever beat in person communication with respect to ability to convey accurately the intention and meaning behind our message.

Ultimately the environement and atmosphere of the whole team changed throughout the project as we headed towards our deadline. The modellers consistently delivered high quality models which were easily imported into the project, with little to no issue. The only challenge with the modelers was finding new tasks they could complete as they were rapidly completing any of the tasks I threw at them. Eventually we got them into the project and had them working on non modelling tasks, such as lighting in the scenes as well as other post processing visual effects like making the screen change colour from blue/ green when under water to clear when at a safe height above water then to red when you are in a dangerous area either out of bounds or simply too high risking detection of the submarine. This was a real task delegation / resource management problem which has taught me the value of reassigning team members to tasks they may not be completely proficient at but are willing to start work on it if there is no more work to be undertaken in their primary speciality.

The programming side of the project presented different issues. There were a few key programming tasks as well as a few minor tasks. Some of the biggest main tasks were things like networking and VR implementation. We had one programmer attempting to tackle both of these tasks while our other programmers tackled UI implementation and game logic / functionality. It turned out that the VR and Networking were presenting particular difficulty due to the remote/online working and therefore restricted access to addiquate technology, such as VR headsets or multiple machines to run the simulator on for multiplayer testing. The result of having our programmers working seperately and often at different times meant that there was a lack of communication and the communication which was there was often through me as a buffer adding time delays and often losing detail due to the difference in my personal level of understanding of the programming and the programming teams understanding. Despite my efforts to encourage the programming team to work within the time slots which were decided after careful consideration of the teams personal schedules and daily routines, then pushed to each team member with notifications through google calender, the programming team were rarely able to work during the scheduled periods. In future I will strive to have the programmers work more closely if at all possible, this may require more planning and also regular reassesment of the needs of the team and their schdules.

There's a special mention here for the work of our general handy man and all rounder Ethan who'm was afforded to us unexpectedly and although he had a slow start he was onboarded and full of enthusiasm, ready to tackle any task we threw his way no matter how much or how little he already knew. Ethan is a great example of how when it comes to building teams, it's much more about the willingness to learn and work together than raw skill and knowledge.

Finally I have learnt an invaluable lesson that in order to both manage a team and project while also takcling one or more of the developement roles alongside this, one must set aside time specifically for project management and time for developement. This is the unfortunate solution to the problem of underdelivering on the game audio when trying to tackle project management, sound design and sound implementation.

Ultimately Submariner was a unique experience and the biggest challenge I've faced in my game developement career so far. I have not been put off by any of the hurdles we faced and I am determined to continue to do better by my future teams using the knowledge and experience gained from this project.