This particular project was a collaboration with the University of Portsmouth and the Royal Navy, in the hopes of creating a Submarine Simulator that could be showcased at Recruitment events. After my final TDEMO project of Teaching Block 1, a team of first years was devised and put together to approach this task, and as a member, I made a sizeable contribution to the project in terms of Project Direction (in the form of Game Design), User Interface Design and Programming, and also assisted with Quality Assurance at the end.
At the start of our project, we hopped in with our client to discuss the brief of our project. Unlike other teams, we had a real client and real expectations to be met, and this meant being in constant communication with the Royal Navy to make sure we’re reaching the necessary quotas for our task. Even throughout development, we needed to give updates on our work, and show good progress as we went to provide reassurance in the direction of the project.
Alongside our expectations, we were expected to sign an NDA for security reasons. While this was a pretty normal occurrence in my outside projects and industry in general, if I wasn’t fully aware of the importance of the project, I was now. We were working for someone, and this did mean that we’d need to assure we were organized and were meeting any of the scheduled dates. More importantly, if I had a lesson to learn about this experience, it would be the need for strong and robust communication among the team, and also the need for a team of consistent workers.
With all of this out of the way, the areas that follow will detail the specifics about what I did, and my reflection on the experience overall!
At the start of our project, we hopped in with our client to discuss the brief of our project. Unlike other teams, we had a real client and real expectations to be met, and this meant being in constant communication with the Royal Navy to make sure we’re reaching the necessary quotas for our task. Even throughout development, we needed to give updates on our work, and show good progress as we went to provide reassurance in the direction of the project.
Alongside our expectations, we were expected to sign an NDA for security reasons. While this was a pretty normal occurrence in my outside projects and industry in general, if I wasn’t fully aware of the importance of the project, I was now. We were working for someone, and this did mean that we’d need to assure we were organized and were meeting any of the scheduled dates. More importantly, if I had a lesson to learn about this experience, it would be the need for strong and robust communication among the team, and also the need for a team of consistent workers.
With all of this out of the way, the areas that follow will detail the specifics about what I did, and my reflection on the experience overall!
Basic Research
(Marco, 2016)
Predominantly with this project, we had alot more time to explore unique and creative methods to make our project pop! So I researched a variety of different fields, both before, and while developing to better educate and inform the choices in design I was making. To start, I decoupled the brief to get a better understanding of what we were being expected to do. They wanted to us to create a game for a recruitment event, but with that in mind, what does our game have to be?
Does it have to be exciting? Does it have to draw people in? These are all questions that were going through my head, which I decided to answer with the use of Mechanics, Dynamics and Aesthetics. MDA (MDA Framework- Unconnected Connectivity, n.d.) is a design methodology which breaks down a games consumability into 3 different factors
Later down the line, I would be undertaking the movement of the Submarine, so it was important to have an understanding of how they move, and the physics behind them. I looked into a video and article (How Submarines Work, 2000), (Science Channel, 2016) that served as very useful material to base my submarine movement off. It was also very important to do this research as in our brief, there was also a requirement to display specific information to our user, so using these videos, I devised a couple methods in which I could calculate this information through submarine movement.
I also needed to research the roles that the Navy wanted us to portray, those being the Planesman and Periscope. Luckily, thanks to the meeting we had with the Navy, I was able to build a solid understanding of the roles, and as a group, we even took steps to verify how realistic our experience was to that of existing sailors, by showing the Navy our project throughout development, to gauge whether our course was correct.
Among these key areas of research, I also needed to research specifics for the areas I was invested in, which I will go into in the different areas.
- Mechanics, which are the rules, algorithms, data structures and systems that make the game work.
- Dynamics, which are the real-time action of the mechanics, reacting to player input and the other systems
- Aesthetics, which are the emotions we want our player to feel when playing.
Later down the line, I would be undertaking the movement of the Submarine, so it was important to have an understanding of how they move, and the physics behind them. I looked into a video and article (How Submarines Work, 2000), (Science Channel, 2016) that served as very useful material to base my submarine movement off. It was also very important to do this research as in our brief, there was also a requirement to display specific information to our user, so using these videos, I devised a couple methods in which I could calculate this information through submarine movement.
I also needed to research the roles that the Navy wanted us to portray, those being the Planesman and Periscope. Luckily, thanks to the meeting we had with the Navy, I was able to build a solid understanding of the roles, and as a group, we even took steps to verify how realistic our experience was to that of existing sailors, by showing the Navy our project throughout development, to gauge whether our course was correct.
Among these key areas of research, I also needed to research specifics for the areas I was invested in, which I will go into in the different areas.
Game Design and Project Direction
Game design and the direction of the project were the first areas of the game I worked on, and these areas were a key point to observe. I would consider these areas primarily a cause for alot of the issues I experienced as a member of the team, and while I cannot speak for the other members, I can definetly say my productivity was dented by a lack of meaningful planning.
|
In fairness, in the early stages of the project, this was attempted. We frequently discussed the ideas that we had and I definetly took alot of initiative in breaking down our initial brief into what we specifically needed, and then assisting our team lead at the time with the direction of the game. As mentioned above, MDA (MDA Framework- Unconnected Connectivity, n.d.) was especially important in the devising of ideas and potential ways we can add value to our game.
|
|
A particular idea I came up with, and was planned for the game was the use of Leaderboards and timings. By creating an Aesthetic of Competition, and having a leaderboard, we could grant the Navy more added value, as they could pair our project with prizes to further intice people to compete, thus becoming more exposed to the naval experience we were emulating. As our project is going to be utilised for recruitment, any factors that we can add to our project to make the experience more attractive will make the goal of recruiting potential navy sailors more achievable, and would ultimately prove the success of our project. This idea in particular though didn't see the light, as we weren't able to fit it in on time. If we were to attempt this another time though, this would be something we could add.
|
Following on from this though, I developed a version-based game design document alongside the team, which detailed the expectations and direction of our project. As I wasn't always suited for things such as modelling, I left those elements down to the contributions of other members. I will note on the document though, that initially, this only covered the "simulator" elements of the game. We had decided early on to focus on the simulator aspect, as the game loop could be completed fairly quickly. However, what I didn't know, is how last minute this game loop would be planned.
Although we had spent alot of effort planning out the approach we would take, there were consistent points where members of the team were not on the same page on the direction of the project, and consistently throughout development, members of the team had differing ideas of what the game should be. |
|
Notably, I remember an instance where while working on the submarine that I needed to understand how we were going to trigger a losing state, with the submarine. As mentioned above, documentation of this was very minimal at the time, which in itself, is an issue as it should have been planned by this point. What amplifies the issues I had though, was that I enquired with members of my team, and I received mixed answers, meaning I had to take the team leads version and get on with my work.
For one, documentation on this area didn't happen, and although initially this wasn't a priority, it should have still been done earlier. It was done very last minute, and this had an effect on my productivity. Even so, the fact I didn't know what to do, and other people had mixed ideas of what to do, implies that we weren't on the same table about this particular element of the game, and we would have benefited from not only better verbal communication but written communication in the form of noting down changes to the original plan.
If we were to improve, it would be way more beneficial having everyone actively work on the document in one setting, and it would have been of benefit to get more hands on the design process as a whole. That way, we reduce the chances of going off book, and we keep to a central vision that we all collaborated to make.
For one, documentation on this area didn't happen, and although initially this wasn't a priority, it should have still been done earlier. It was done very last minute, and this had an effect on my productivity. Even so, the fact I didn't know what to do, and other people had mixed ideas of what to do, implies that we weren't on the same table about this particular element of the game, and we would have benefited from not only better verbal communication but written communication in the form of noting down changes to the original plan.
If we were to improve, it would be way more beneficial having everyone actively work on the document in one setting, and it would have been of benefit to get more hands on the design process as a whole. That way, we reduce the chances of going off book, and we keep to a central vision that we all collaborated to make.
My Approach to my Programming/UI tasks
In the project, I made and worked on a variety of different systems and assets that took on key requirements of our brief and tackled them in a robust and modular manner. When designing my own systems, I'd make use of MDA (MDA Framework- Unconnected Connectivity, n.d.) to initially plan out the specifics needs of the asset. I then followed a process of Rapid Prototyping (What Is Rapid Prototyping And Why Is It Used in Development?, n.d.), whereby I would seek critical feedback on system prototypes/mockups that I'd make and then go back and make alteration given the guidance I receive from my peers. The benefit of this approach is that alteration to my systems can be made the instant I'm working on it, so it improves my productivity overall, as I can spend my time dedicated on one task at a time rather than multiple.
A system that benefitted from this was my User Interface System, in which I went back and forth with members of my team to get the feel and representation of the Interface correct, and in line with the project brief. I also got feedback about the approach to the art-style and how we should attempt that, and received some valuable comments that I could work with.
A system that benefitted from this was my User Interface System, in which I went back and forth with members of my team to get the feel and representation of the Interface correct, and in line with the project brief. I also got feedback about the approach to the art-style and how we should attempt that, and received some valuable comments that I could work with.
|
Speaking of the UI, I had a specific set of guidelines that I assured my work followed while developing. A 2011 WHO report (World Report on Disability, 2011) suggested that 15% of the world lived with a disability, and thus this could potentially mean that 15% of people playing our game, could also have a disability. |
|
With scope in mind, we knew that our project was meant to attract fit and able-bodied men and woman to become sailors. However, there are visual and learning disabilities that our target audience might have, so in the effort to make the game suitable for the audience, I adhered my UI work to a set of Accessibility guidelines from notable sources used by the industry (Game Accessibility Guidelines | Basic, n.d.), (Hausler, 2015), (stevewhims, n.d.) , to assure our work would reach as many people as possible, without being confusing or unusable.
As a group, at the end of major development, we decided to vigorously test our game to find any bugs that might have slipped through the cracks, and part of this process was documenting bugs we located. With prior knowledge from my experiences outside of University, I designed a system on an excel sheet that could be used to inform everyone of bugs that were resolved, still existing or handled. In hindsight though, if this were an Industry project, I would try utilise a system such as Jira's Service Management(Atlassian, n.d.) which is a ticket-based support system we could use to effectively communicate issues to do with our code base. This also could mean we could link this to our existing Trello, and funnel all changes to the game in one place.
However, due to a very significant lack of documentation, I tended to seek feedback quite often on my work. Although I was heavily involved in the planning of the direction of the project, in late development, it was definetly clear that members of the team had their own idea of how the game should turn out, and this created confusion and had a impact on my productivity, due to not knowing whether my systems fit with the overall groups vision.
However, due to a very significant lack of documentation, I tended to seek feedback quite often on my work. Although I was heavily involved in the planning of the direction of the project, in late development, it was definetly clear that members of the team had their own idea of how the game should turn out, and this created confusion and had a impact on my productivity, due to not knowing whether my systems fit with the overall groups vision.
Reflecting on the systems I developed
|
I made 3 of, and contributed to 4 different systems, out of the 17 that were present in the final version of the games. Of those systems, the 3 that I made were all high priority systems that were required for the brief, while the other 4 were complimentary/minor systems that I made alongside other people or fixed bugs and issues with.
|
|
|
The first system I was tasked with creating was the User Interface Backend. In initial weeks, I drafted a greybox of the UI design at the time and started to plan out my approach. There needed to be a simple menu navigation system, while in the game, there would need to be support for displaying certain UI elements at certain times, for example, the Periscope HUD.
|
The brief also required values to be displayed in real time, so support was needed for the updating of UI elements that displayed things such as Speed, or Yaw.
Implementing all of this was relatively simple, and I centered my system around the use of Event Based Programming, which was an element of programming I researched. (‘Unity Events, Actions, and BroadcastMessage’, 2016). I decided to use custom Event Based Programming in this instance because it is an industry standard (Event-Driven Applications In Software Development, 2018) to utilise Event Driven Programming in graphical user interfaces. In Unity, it does this on a much simpler level with button or key inputs, but it also had support for custom events that I can determine myself. This meant I could set up a generalised "Value Update" event, that could be used by the Submarine to alter information on the fly, without unnecessary lines of code.
I then continued to work on displaying these values in a manner that'll make sense to the player, and this involved formatting any numbers received into things such as degrees, the course of submarine, or even into knots. During development however, there were bugs I needed to fix as . In particular,there was a particular bug raised where the course of the submarine was being outputted as degrees, rather than NSEW, and this was fixed fairly swifty, as all I needed to do was change a couple values to alter the value being outputted.
Implementing all of this was relatively simple, and I centered my system around the use of Event Based Programming, which was an element of programming I researched. (‘Unity Events, Actions, and BroadcastMessage’, 2016). I decided to use custom Event Based Programming in this instance because it is an industry standard (Event-Driven Applications In Software Development, 2018) to utilise Event Driven Programming in graphical user interfaces. In Unity, it does this on a much simpler level with button or key inputs, but it also had support for custom events that I can determine myself. This meant I could set up a generalised "Value Update" event, that could be used by the Submarine to alter information on the fly, without unnecessary lines of code.
I then continued to work on displaying these values in a manner that'll make sense to the player, and this involved formatting any numbers received into things such as degrees, the course of submarine, or even into knots. During development however, there were bugs I needed to fix as . In particular,there was a particular bug raised where the course of the submarine was being outputted as degrees, rather than NSEW, and this was fixed fairly swifty, as all I needed to do was change a couple values to alter the value being outputted.
|
My second system, the Submarine is fairly self explanatory. It was required to create a "submarine" that the player could move and see out of using the periscope. I was in charge of the movement aspect of the code, and I developed a system that controlled the acceleration, deceleration and velocity of the Submarine.
|
|
In planning, I realised, thanks to my research (Science Channel, 2016) , that it would take too long to simulate the physics of a full blown submarine. However, through the use of abstraction, I was able to get close to it without going over the scope of the system. I initially prototyped my work by creating a version of the submarine that I could control with WASD. This allowed me to show off my work to my team, so I could make adjustments to the acceleration and speed the submarine was capable of moving at.
|
From here, I setup the smooth deceleration of the submarine to simulate the motion after throttle has been set to 0. Depth and pitch adjustment were also setup, and I made turning dependant on forward force. At this point, I had reached a point where the wheel and throttle could now link to the system, and we could start attaching elements, such as the periscope camera.
|
Particularly, there was an issue where the script holder for Submarine Movement had a weird position in comparison to the actual Submarine model, causing issues as the relative spawn point of the Submarine would be very far away. This was fixed however, by realigning these two objects to the same position.
A bug I encountered with this system would be with steering the Submarine. I unintentionally had the yaw of the submarine incrementing at an extremely high rate, meaning that on one side, it would rotate completely fine, but on the other side, it would start to spin uncontrollably. This was a result of poor math calculations for turning in that direction, and part of fixing this issue involved going into that section and diagnosing the point in which the calculation was wrong. I discovered that there was effectively no cap on the turning force for that side, so I reimplemented it so that it would work the same as turning the opposite direction.
If I were to make this system better, I would try to create a bobbing affect upon the submarine surfacing, as this would ultimately add to the immersion that the player would have when playing our game, and would further improve realism.
A bug I encountered with this system would be with steering the Submarine. I unintentionally had the yaw of the submarine incrementing at an extremely high rate, meaning that on one side, it would rotate completely fine, but on the other side, it would start to spin uncontrollably. This was a result of poor math calculations for turning in that direction, and part of fixing this issue involved going into that section and diagnosing the point in which the calculation was wrong. I discovered that there was effectively no cap on the turning force for that side, so I reimplemented it so that it would work the same as turning the opposite direction.
If I were to make this system better, I would try to create a bobbing affect upon the submarine surfacing, as this would ultimately add to the immersion that the player would have when playing our game, and would further improve realism.
The third and final main system I worked on was on the Game State Manager This manager was solely responsible for handling winning, losing, pausing and restarting the game. Similar to how the UI worked, this system also employed event based programming, as I could setup events that not only are triggered on winning or losing (thus bringing up win/loss UI), but also setup other scripts to communicate using events, when a loss needs to be triggered, or a win needs to be triggered. I also used this system to implement a tutorial for the end user, in which we display a UI before the game starts, so that the player can get a good idea of what to do in order to win the game.
However, using event based programming for this system created complications when it came to attempt restarting. Previously the events would fail to disconnect after the player tried to restart, which meant that copious errors were being produced and values were being overwritten by scripts that shouldn't really exist anymore. This is luckily fixed though by disconnecting all the events at the end of the game, so there's no dependencies.
I also collaborated on code with other members of the team, and although these are more minor sections of the game, I have noted them below.
However, using event based programming for this system created complications when it came to attempt restarting. Previously the events would fail to disconnect after the player tried to restart, which meant that copious errors were being produced and values were being overwritten by scripts that shouldn't really exist anymore. This is luckily fixed though by disconnecting all the events at the end of the game, so there's no dependencies.
I also collaborated on code with other members of the team, and although these are more minor sections of the game, I have noted them below.
- Countdown Timer
- Throttle
- Camera Mouse Locking
- Fading System
- Periscope Camera (Implementing Submarine Movement)
Performance as a Programmer
In terms of all the tasks I’ve done for the team, programming is probably the more sizeable. I worked on crucial elements of the project that brought it to the stage it's at today, and you could argue that without some of them, the project definitely wouldn't hit the brief. In reflection, starting off on this area was very slow. Early on in the project, I was directed to approach alot of the design and direction of the game, and later down the line, we realised that I couldn't do that forever. Thus, it would have 100% been of benefit for me to have my hands in the decisions to do with programming earlier on.
As you may have noticed, communication was a very profound issue, and a running theme of my reflection. The difficulty I think we all had was that we weren't always on the same page, and this meant alot of back and forth about what needed to be done. In the context of programming, early on, programming tasks seemed very unplanned, and weren't clearly documented in a place where we could all access them. My productivity was definetly dented alot by consistently having to ask about what was needed, and I would consider this slightly unnecessary if we are making use of an effective project management software such as Trello.
To improve in this area, we could have planned our approach much earlier on. More importantly, its crucial that we stick to the plans we do make and discuss any changes to assure we're on top of them as a group. Consistency is key, and assuring we're all using the same things and aware of the same things will reduce the amount of confusion or surprise when a feature isn't as someone expected.
As you may have noticed, communication was a very profound issue, and a running theme of my reflection. The difficulty I think we all had was that we weren't always on the same page, and this meant alot of back and forth about what needed to be done. In the context of programming, early on, programming tasks seemed very unplanned, and weren't clearly documented in a place where we could all access them. My productivity was definetly dented alot by consistently having to ask about what was needed, and I would consider this slightly unnecessary if we are making use of an effective project management software such as Trello.
To improve in this area, we could have planned our approach much earlier on. More importantly, its crucial that we stick to the plans we do make and discuss any changes to assure we're on top of them as a group. Consistency is key, and assuring we're all using the same things and aware of the same things will reduce the amount of confusion or surprise when a feature isn't as someone expected.
User Interface Design
User interface design was also an area where I contributed heavily.
I referenced the Witcher 3’s HUD (CD PROJEKT RED, 2015) when planning to add hints on what controls to press when. Although I wasn’t going to follow the Xbox control scheme as our game did not XBOX controls implemented, I really liked how these hints were displayed whenever a weapon was equipped, and drawing from this, hints could be very helpful for our end user when trying to interact with the planesman controls . Following this, we implemented a section in the pause menu where you could see the controls, and we also provide a display above interactable areas of the Planesman and Periscope room, which indicate their purposes.
|
I also referenced Lego Universe’s Faction Selection UI (NetDevil, 2010) when planning, designing and making the initial whiteboard role selection screen (before we pushed for a single player experience over a multiplayer). The idea was that the player could select the role they wanted to portray, and then get some information about that role specifically.
However, later in development, this was condensed down to less information because of our switch in focus from Multiplayer to Singleplayer. It would not make sense to have information on two separate pages, if the player was going to be playing both at the same time, so it was all placed on one page and the redirection of the menus was simplified. |
|
If we had more time, and were able to broaden the scope, this menu would definetly have been a great addition, but it's important to reflect on the fact that sometimes, even if we do make assets for the game, they aren't always going to be added in. The decision to take this out was very last minute by those working on the final repository, due to a stark change in the way the game was going to be approached. The likelihood, is that this asset would have probably stayed if we had planned this out prior, and in reflection, I would have probably benefitted from this planning.
|
For the art style of the UI, I wanted it to be very consistent and elements needed to fit in with the rest. I spent a bit of time early on trialling with different styles, and settled on three, to use in different ways.
The first art style would be that used on the screens and the HUD. Typically speaking, I used Red as the colour scheme, but also used black for certain elements, such as the Planesman Screen. I wanted to produce a feel that these were "digital values", so I researched for a font (DS-Digital Font | Dafont.Com, n.d.) that gives the impression of a digital alarm clock. |
|
Original Main Menu
In-Dev Planesman Info Screen
|
The next art style was for a whiteboard. There was some initial deliberation over whether the whiteboard should be a digital whiteboard, or that of a marker, so part of this involved me going back and forth with the rest of the team to figure out the feel we wanted to go for.
In this stage, I drew heavy inspiration from games such as Phasmophobia, (Kinetic Games, 2020) which featured a Whiteboard Main Menu that is used to navigate into the game. In particular, we needed to make sure it was known that text was drawn by a whiteboard marker, so I again researched on Dafont and discovered a font (Google, n.d.). An important thing to note about the fonts as well, is that I took time to assure these fonts were either free to use, or had an Open Font License. |
I deliberately made this decision because as we were working for a client, it is our responsibility to assure they don't get into licensing issues because of the product we send them. An OTF License (‘SIL Open Font License’, 2021) allows us to bundle and embed this font with commercial products, and this would be ideal for a game like ours.
In applying this art style, I utilised the process I detailed earlier, to greybox some UI mockups, which helped communicate what I wanted to achieve with the UI with the rest of team, and allowed for input from other members. Upon doing so, I then implemented these into blender as a rough prototype, and then applied my styling.
The final art style I did was for the Pause, Win, Loss and Tutorial Menus. Previously, I had planned to use just one art style for the whiteboard and menus, and was not going to be using whiteboard markers. However, after feedback from my team, my approach to this changed. This need for styling could have been communicated alot earlier, as I had already started my working and was showing progress.
|
Luckily, I was able to recycle the previous art style I used, and applied it to the Pause/Win/Loss and Tutorial Menus. In particular, I made use of RN image archive (Royal Navy Image and Video Archive, n.d.) to showcase images of submarines, and naval soldiers. There were conditions to using these images, which involve giving notice of the license that came with them, so we very careful in assuring that our client knew this (although they can technically use these.)
|
Art Style Draft
|
Testing all my work, I utilised the guidelines (Game Accessibility Guidelines | Basic, n.d.) that I previously researched to guide my efforts in assuring my work would be visible to all. A notable method I used was testing for color blindness, in which I utilised a mobile app nicknamed VISIA (Budynski, 2019) and a Color Blindness Simulator called Coblis (Color Blind Vision Simulator, n.d.) which allowed me to simulate visual impairment conditions such as Tritanopia, Monochromacy and Protanomaly. I needed these to observe whether or not the colour I was using was contrasting enough to be visible to people with color-blindness, and it was very effective in identifying colours that we should avoid using.
Many of the changes I made to my work in accordance to the guidelines consisted of adjustments to elements such as text, where I may have needed to scale up the size on things or improve pixel clarity. As I had fleshed out the final design of my art, it was just down to finetuning the accessibility elements of the project and polish from here on out!
Many of the changes I made to my work in accordance to the guidelines consisted of adjustments to elements such as text, where I may have needed to scale up the size on things or improve pixel clarity. As I had fleshed out the final design of my art, it was just down to finetuning the accessibility elements of the project and polish from here on out!
Reflecting on my User Interface Work
In general, working on the UI was pretty interesting. I got to make use of Unity's UI system again, of which I had previously gained a understanding of in the prior weeks of TDEMO. I love how it turned out and I'm very proud of the reception it received with the rest of my team!
While developing the UI, I ran into a few logistical and graphical issues. For starters, the icons and images I drew in Adobe Illustrator would sometimes have this white board around it. This is an artefact caused by the Alpha surrounding the icons, which occupy the transparent areas around the icons. This meant that when I implemented solid white icons into Unity, I'd get this strange artefact around the border of my images, which is a result of Bilinear Filtering done by Unity and in Photoshop. (Courrèges, n.d.)
Luckily, I made use of software called PixelFix (Shae, 2018/2021), which I started using after I learnt about it from my projects outside of University. It works by changing the transparent pixels around an image to match the color of the nearest non-transparent pixel, and this would fix the artefact around the images that I drew, by making them "bleed" out their colours into the alpha. From then on, for the assets I did make, I assured that I applied it to this tool.
Later on additionally, there was a few complications where my team had made changes to the UI without me knowing (including the removal of some assets), and this had the knock on effect of scaling some of the Royal Navy Logos incorrectly. As part of my research (Applying the Brand. Rules for Using the Royal Navy Logo and Identity, 2016), I found out early on in the project that for the RN logo to be used, it must be kept at a certain size and aspect ratio, and I was very careful to assure that I abided by the usage terms. However, my team were not aware of this, and on pitching our game to the Navy, this issue was raised that the logos were more stretched than they should be. This would not have been caused if there was steady communication about changes to my work, and this could have been improved by keeping me in the loop, but also on my end, I could have communicated the importance of abiding by the use terms, and in the future, I will endeavour to make this publically known.
If I had something I specifically wanted to improve or add to the UI, I would have loved to design more button icons to associate with inputs. This would have benefited dyslexic end users who may struggle to always read text, and identifying icon they can link to actions will improve their learning curve of the game.
While developing the UI, I ran into a few logistical and graphical issues. For starters, the icons and images I drew in Adobe Illustrator would sometimes have this white board around it. This is an artefact caused by the Alpha surrounding the icons, which occupy the transparent areas around the icons. This meant that when I implemented solid white icons into Unity, I'd get this strange artefact around the border of my images, which is a result of Bilinear Filtering done by Unity and in Photoshop. (Courrèges, n.d.)
Luckily, I made use of software called PixelFix (Shae, 2018/2021), which I started using after I learnt about it from my projects outside of University. It works by changing the transparent pixels around an image to match the color of the nearest non-transparent pixel, and this would fix the artefact around the images that I drew, by making them "bleed" out their colours into the alpha. From then on, for the assets I did make, I assured that I applied it to this tool.
Later on additionally, there was a few complications where my team had made changes to the UI without me knowing (including the removal of some assets), and this had the knock on effect of scaling some of the Royal Navy Logos incorrectly. As part of my research (Applying the Brand. Rules for Using the Royal Navy Logo and Identity, 2016), I found out early on in the project that for the RN logo to be used, it must be kept at a certain size and aspect ratio, and I was very careful to assure that I abided by the usage terms. However, my team were not aware of this, and on pitching our game to the Navy, this issue was raised that the logos were more stretched than they should be. This would not have been caused if there was steady communication about changes to my work, and this could have been improved by keeping me in the loop, but also on my end, I could have communicated the importance of abiding by the use terms, and in the future, I will endeavour to make this publically known.
If I had something I specifically wanted to improve or add to the UI, I would have loved to design more button icons to associate with inputs. This would have benefited dyslexic end users who may struggle to always read text, and identifying icon they can link to actions will improve their learning curve of the game.
Reflection of my experience on the team
Submariner was an inciteful experience as to the importance of having a team that gels well together, communicates and plans ahead. My peers are extremely talented in the fields they specialised in, and we are all extremely effective given we are functioning in an environment which suits are natural work ethic. Frequently though, this was difficult to achieve due to the dynamic within the team.
The team was comprised of members who had a tendency to over work, balanced workers, and slight underachievers, which created an environment whereby work and progression was assumed by working at each others level rather than compromise. As a balanced worker, I believe this had a big detremental effect on my performance, as I constantly needed to tailor the hours I was putting into the module based on other members of my team, at times drawing more hours away from my other modules. This was difficult to manage, because even with good and effective time management, reaching the expectations that my team mates had for me was difficult sometimes. However, the biggest reflection that I could have over all of this was that sometimes you don't always get the pleasure of working how you want. Industry can be cruel and although there is the opportunity to bring forth greater change to this in the future, the likelihood is that you will not always be able to work as effective as you want to. I struggled alot with confidence in my ability, as through the peer review we received, my idea of work against other people's idea of work was very clearly different and this created alot of confusion and stress for me trying to meet the expectations of my peers. The interpersonal relationships of some members in my team also weren't great, so at times during high stress development, we really suffered from demotivation.
However, solving this is alot more easier said than done. Finding a team that you gel well with is very much pot luck, and at times in industry, the only solution would be to reorganise the entire team. That definetly wouldn't happen in a first year project, but this experience is definetly informative as to why teams don't work, and why they're swapped round in industry. The important moral/organisational obligations you have to weigh in these decisions are very profound, and having a fundamental understanding of the rationale behind these decision will make me more adaptive and pliable to change in the future.
Continuing on, our team greatly struggled with communication fallthrough. While excellent at verbal communication, getting all this down in writing and documentation was extremely poor, and it meant going back and forth with members of the team to discover what to do. The flaw with this is the risk of not being on the same page, as alot of things tend to be forgotten in conversations. This actually happened part way through development, where I was programming one of the loss conditions, and I recieved mixed answers as to what was expected of me. Ultimately, I went with the team lead's view, but even so, the fact that people made their own answers for themselves (and the fact I really didn't know in the first place) implies that this particular element of the project was not clearly documented somewhere. Thus, I believe if we were to attempt this again, I would take a key interest in documenting the conversations we have and writing a basic "transcript" over the points and concepts we discuss, thus allowing us to keep a record of what ideas we have that can be referenced later down the line.
On another factor of communication, programming tasks that had been "finished" had not been clearly displayed within the project files or Trello, so alot of tasks reassigned to other people involved redoing certain sections of the game. This is clearly unproductive, as time spent remaking systems that already exist could be spent making required systems that haven't been made yet. We would have greatly benefited from more vigourous communication within our planning Trello, but also from organisation of our workspace, to make all parties aware of the changes that have been made by an individual.
Finally, an immediate reflection I had was over the change of leadership we had midway through the project. The new team lead changed the working methodology of the group to be more reminiscent of a Waterfall Development Methodology (‘Waterfall Model’, 2021) ,whereby development was sequential and development is usually fixated on an initial plan we have at the start of the project.
This was very difficult to adjust to, as prior to the change, we were adopting a more Agile Development Methodology (‘Agile Software Development’, 2021) , whereby our work consisted of more polishing of the systems we developed through constants stages of analysis, design and testing. The benefits of this particular model, is that is suited for customer satisfaction, meaning we could easily meet the expectations of the Navy, through iteration of our project.
The knock on effect of this sudden change, however, was that Agile tends to have a lack of documentation and planning, and going into a Waterfall Methodology definetly required us to replan and reconsider aspects of the game. This however, didn't really happen. It was clear that in the later stages, the focus and direction of the project were created by "spur of the moment" decisions that weren't necessarily guided by the direction of the entire team. If this were industry, last minute changes to the plan, under this methodology, could be extremely expensive to cover, and if something goes wrong, the likelihood of restarting entirely is very high.
I even found out the hard way about these sudden changes to the plan, as in the final week of development, some of my UI assets were taken out of the game without the majority of the team knowing. With a team like ours, whereby the team lead is more decentralised, failing to discuss this with each other, if not the maker of the asset itself isn't a great pattern to adopt in a collaborative project. (Although, this happens in the industry quite often, such as with Borderland's iconic Cel Shading Style (9 Last Minute Changes That Hurt Video Games (And 11 That Saved Them), 2018)).
A way this could be improved is by avoiding a change in leadership. Sometimes, a change is necessary, especially if you are approaching the end of a product life cycle whereby finalisation and drawing things to a close is good. However, it wasn't ideal that this happened in the middle of the project, and it definetly threw my organisation into disarray, as there was more of a expectation to get an MVP done rather than polishing my work. Again though, sometimes, changes in leadership can't be avoided, and the natural leading tendecies of the team lead are usually the dictating factors in the methodology used.
Concluding this, my team were very fun to work with. I feel there were definetly times we didn't function cohesively, and this definetly showed in our performance throughout the weeks. However, I'm glad we managed to turn it around and get a awesome project our for our clients!
The team was comprised of members who had a tendency to over work, balanced workers, and slight underachievers, which created an environment whereby work and progression was assumed by working at each others level rather than compromise. As a balanced worker, I believe this had a big detremental effect on my performance, as I constantly needed to tailor the hours I was putting into the module based on other members of my team, at times drawing more hours away from my other modules. This was difficult to manage, because even with good and effective time management, reaching the expectations that my team mates had for me was difficult sometimes. However, the biggest reflection that I could have over all of this was that sometimes you don't always get the pleasure of working how you want. Industry can be cruel and although there is the opportunity to bring forth greater change to this in the future, the likelihood is that you will not always be able to work as effective as you want to. I struggled alot with confidence in my ability, as through the peer review we received, my idea of work against other people's idea of work was very clearly different and this created alot of confusion and stress for me trying to meet the expectations of my peers. The interpersonal relationships of some members in my team also weren't great, so at times during high stress development, we really suffered from demotivation.
However, solving this is alot more easier said than done. Finding a team that you gel well with is very much pot luck, and at times in industry, the only solution would be to reorganise the entire team. That definetly wouldn't happen in a first year project, but this experience is definetly informative as to why teams don't work, and why they're swapped round in industry. The important moral/organisational obligations you have to weigh in these decisions are very profound, and having a fundamental understanding of the rationale behind these decision will make me more adaptive and pliable to change in the future.
Continuing on, our team greatly struggled with communication fallthrough. While excellent at verbal communication, getting all this down in writing and documentation was extremely poor, and it meant going back and forth with members of the team to discover what to do. The flaw with this is the risk of not being on the same page, as alot of things tend to be forgotten in conversations. This actually happened part way through development, where I was programming one of the loss conditions, and I recieved mixed answers as to what was expected of me. Ultimately, I went with the team lead's view, but even so, the fact that people made their own answers for themselves (and the fact I really didn't know in the first place) implies that this particular element of the project was not clearly documented somewhere. Thus, I believe if we were to attempt this again, I would take a key interest in documenting the conversations we have and writing a basic "transcript" over the points and concepts we discuss, thus allowing us to keep a record of what ideas we have that can be referenced later down the line.
On another factor of communication, programming tasks that had been "finished" had not been clearly displayed within the project files or Trello, so alot of tasks reassigned to other people involved redoing certain sections of the game. This is clearly unproductive, as time spent remaking systems that already exist could be spent making required systems that haven't been made yet. We would have greatly benefited from more vigourous communication within our planning Trello, but also from organisation of our workspace, to make all parties aware of the changes that have been made by an individual.
Finally, an immediate reflection I had was over the change of leadership we had midway through the project. The new team lead changed the working methodology of the group to be more reminiscent of a Waterfall Development Methodology (‘Waterfall Model’, 2021) ,whereby development was sequential and development is usually fixated on an initial plan we have at the start of the project.
This was very difficult to adjust to, as prior to the change, we were adopting a more Agile Development Methodology (‘Agile Software Development’, 2021) , whereby our work consisted of more polishing of the systems we developed through constants stages of analysis, design and testing. The benefits of this particular model, is that is suited for customer satisfaction, meaning we could easily meet the expectations of the Navy, through iteration of our project.
The knock on effect of this sudden change, however, was that Agile tends to have a lack of documentation and planning, and going into a Waterfall Methodology definetly required us to replan and reconsider aspects of the game. This however, didn't really happen. It was clear that in the later stages, the focus and direction of the project were created by "spur of the moment" decisions that weren't necessarily guided by the direction of the entire team. If this were industry, last minute changes to the plan, under this methodology, could be extremely expensive to cover, and if something goes wrong, the likelihood of restarting entirely is very high.
I even found out the hard way about these sudden changes to the plan, as in the final week of development, some of my UI assets were taken out of the game without the majority of the team knowing. With a team like ours, whereby the team lead is more decentralised, failing to discuss this with each other, if not the maker of the asset itself isn't a great pattern to adopt in a collaborative project. (Although, this happens in the industry quite often, such as with Borderland's iconic Cel Shading Style (9 Last Minute Changes That Hurt Video Games (And 11 That Saved Them), 2018)).
A way this could be improved is by avoiding a change in leadership. Sometimes, a change is necessary, especially if you are approaching the end of a product life cycle whereby finalisation and drawing things to a close is good. However, it wasn't ideal that this happened in the middle of the project, and it definetly threw my organisation into disarray, as there was more of a expectation to get an MVP done rather than polishing my work. Again though, sometimes, changes in leadership can't be avoided, and the natural leading tendecies of the team lead are usually the dictating factors in the methodology used.
Concluding this, my team were very fun to work with. I feel there were definetly times we didn't function cohesively, and this definetly showed in our performance throughout the weeks. However, I'm glad we managed to turn it around and get a awesome project our for our clients!
Conclusion
I felt my personal performance on this TDEMO was greatly dependant on the environment that I was working in, but overall I think I conducted myself well. In prior projects, I was more used to a team that contributed equally to a project, both in the planning and development stages. What was exhibitted in this project however, was a unbalanced work dynamic, whereby there were members on the team who contributed large proportions of the project, while others had less to add.
I'm proud of my work and the process I took to make them. I attempted to be very adaptive with my work and this made working in a Methodology I wasn't used too more palettable. There were definetly times where I fell short, but these were great eye openers on the impact that can have on the team, and is a great deterrent against complacency. My communication could definetly have been better, and as I've gone through the project, my improvement in this area has definetly shown, and I'm happy I've picked up alot of experience that I can apply to my future endeavours.
I was apart of a team, with members that didn't necessarily see eye to eye. This happens everywhere, and it's not something to be discouraged by. Instead, we should push to take in everyone's vision, and culminate them together so that it becomes that of a group's vision. At times, it was uncomfortable, and I definetly exhausted myself frequently in this. But to say this experience wasn't something I could learn from, that would be wrong.
I'm proud of my work and the process I took to make them. I attempted to be very adaptive with my work and this made working in a Methodology I wasn't used too more palettable. There were definetly times where I fell short, but these were great eye openers on the impact that can have on the team, and is a great deterrent against complacency. My communication could definetly have been better, and as I've gone through the project, my improvement in this area has definetly shown, and I'm happy I've picked up alot of experience that I can apply to my future endeavours.
I was apart of a team, with members that didn't necessarily see eye to eye. This happens everywhere, and it's not something to be discouraged by. Instead, we should push to take in everyone's vision, and culminate them together so that it becomes that of a group's vision. At times, it was uncomfortable, and I definetly exhausted myself frequently in this. But to say this experience wasn't something I could learn from, that would be wrong.
FIN
Bibliography
MDA Framework- Unconnected Connectivity. (n.d.). https://www.gamasutra.com/blogs/TuckerAbbott/20101212/88611/MDA_Framework_Unconnected_Connectivity.php
Science Channel. (2016, April 29). How Do Submarines Dive and Surface? https://www.youtube.com/watch?v=BTis6GioP2g
How Submarines Work. (2000, August 17). HowStuffWorks. https://science.howstuffworks.com/transport/engines-equipment/submarine.htm
What is Rapid Prototyping And Why is it Used in Development? - DevSquad. (n.d.). https://devsquad.com/blog/what-is-rapid-prototyping-and-why-is-it-used-in-development/
World Report on Disability. (2011). https://www.who.int/teams/noncommunicable-diseases/sensory-functions-disability-and-rehabilitation/world-report-on-disability
stevewhims. (n.d.). Making Video Games Accessible Business Justifications and Design Considerations—Win32 apps. https://docs.microsoft.com/en-us/windows/win32/dxtecharts/accessibility-best-practices
Hausler, J. (2015, December 18). 7 Things Every Designer Needs to Know about Accessibility. Medium. https://medium.com/salesforce-ux/7-things-every-designer-needs-to-know-about-accessibility-64f105f0881b
Game accessibility guidelines | Basic. (n.d.). http://gameaccessibilityguidelines.com/basic/
Unity Events, Actions, and BroadcastMessage. (2016, October 5). Unity3D.College. https://unity3d.college/2016/10/05/unity-events-actions-delegates/
Event-Driven Applications In Software Development. (2018, September 13). Blueberry Custom Software. https://www.bbconsult.co.uk/blog/event-driven-applications
Marco. (2016, July 25). Mechanics Dynamics Aesthetics(MDA): Game design theory behind games. Gamedevelopertips. https://gamedevelopertips.com/mechanics-dynamics-aesthetics-game-design-theory-behind-games/
CD PROJEKT RED. (2015). The Witcher 3: Wild Hunt. [Video game]. CD PROJEKT.
NetDevil. (2010). Lego Universe [Video game]. The Lego Group.
Google. (n.d.). Google Fonts. https://fonts.google.com/
SIL Open Font License. (2021). In Wikipedia. https://en.wikipedia.org/w/index.php?title=SIL_Open_Font_License&oldid=1021006449
Royal Navy Image and Video Archive. (n.d.). https://imagery.royalnavy.mod.uk/
Shae. (2021). Corecii/Transparent-Pixel-Fix [JavaScript]. https://github.com/Corecii/Transparent-Pixel-Fix (Original work published 2018)
Courrèges, A. (n.d.). Beware of Transparent Pixels. Adrian Courrèges. http://www.adriancourreges.com/blog/2017/05/09/beware-of-transparent-pixels/
Applying the Brand. Rules for using the Royal Navy Logo and Identity. (2016). The Royal Navy. https://www.royalnavy.mod.uk/-/media/royal-navy-responsive/documents/reference-library/rn-brand-rules-2016-on-line-version.pdf?la=en-gb&hash=EAAF7622F9B3BEA09F2F67EFE68975B3
Budynski, D (2019). Visual Impairment (1.0) [Mobile app]. Apple App Store. https://apps.apple.com/bb/app/visual-impairment/id1515372809#?platform=iphone
Color Blind Vision Simulator. (n.d.). Pilestone Inc. https://pilestone.com/pages/color-blindness-simulator-1
Agile software development. (2021). In Wikipedia. https://en.wikipedia.org/w/index.php?title=Agile_software_development&oldid=1023834429
Waterfall model. (2021). In Wikipedia. https://en.wikipedia.org/w/index.php?title=Waterfall_model&oldid=1023844880
9 Last Minute Changes That Hurt Video Games (And 11 That Saved Them). (2018, September 20). ScreenRant. https://screenrant.com/video-games-last-minute-changes-hurt-saved/
Science Channel. (2016, April 29). How Do Submarines Dive and Surface? https://www.youtube.com/watch?v=BTis6GioP2g
How Submarines Work. (2000, August 17). HowStuffWorks. https://science.howstuffworks.com/transport/engines-equipment/submarine.htm
What is Rapid Prototyping And Why is it Used in Development? - DevSquad. (n.d.). https://devsquad.com/blog/what-is-rapid-prototyping-and-why-is-it-used-in-development/
World Report on Disability. (2011). https://www.who.int/teams/noncommunicable-diseases/sensory-functions-disability-and-rehabilitation/world-report-on-disability
stevewhims. (n.d.). Making Video Games Accessible Business Justifications and Design Considerations—Win32 apps. https://docs.microsoft.com/en-us/windows/win32/dxtecharts/accessibility-best-practices
Hausler, J. (2015, December 18). 7 Things Every Designer Needs to Know about Accessibility. Medium. https://medium.com/salesforce-ux/7-things-every-designer-needs-to-know-about-accessibility-64f105f0881b
Game accessibility guidelines | Basic. (n.d.). http://gameaccessibilityguidelines.com/basic/
Unity Events, Actions, and BroadcastMessage. (2016, October 5). Unity3D.College. https://unity3d.college/2016/10/05/unity-events-actions-delegates/
Event-Driven Applications In Software Development. (2018, September 13). Blueberry Custom Software. https://www.bbconsult.co.uk/blog/event-driven-applications
Marco. (2016, July 25). Mechanics Dynamics Aesthetics(MDA): Game design theory behind games. Gamedevelopertips. https://gamedevelopertips.com/mechanics-dynamics-aesthetics-game-design-theory-behind-games/
CD PROJEKT RED. (2015). The Witcher 3: Wild Hunt. [Video game]. CD PROJEKT.
NetDevil. (2010). Lego Universe [Video game]. The Lego Group.
Google. (n.d.). Google Fonts. https://fonts.google.com/
SIL Open Font License. (2021). In Wikipedia. https://en.wikipedia.org/w/index.php?title=SIL_Open_Font_License&oldid=1021006449
Royal Navy Image and Video Archive. (n.d.). https://imagery.royalnavy.mod.uk/
Shae. (2021). Corecii/Transparent-Pixel-Fix [JavaScript]. https://github.com/Corecii/Transparent-Pixel-Fix (Original work published 2018)
Courrèges, A. (n.d.). Beware of Transparent Pixels. Adrian Courrèges. http://www.adriancourreges.com/blog/2017/05/09/beware-of-transparent-pixels/
Applying the Brand. Rules for using the Royal Navy Logo and Identity. (2016). The Royal Navy. https://www.royalnavy.mod.uk/-/media/royal-navy-responsive/documents/reference-library/rn-brand-rules-2016-on-line-version.pdf?la=en-gb&hash=EAAF7622F9B3BEA09F2F67EFE68975B3
Budynski, D (2019). Visual Impairment (1.0) [Mobile app]. Apple App Store. https://apps.apple.com/bb/app/visual-impairment/id1515372809#?platform=iphone
Color Blind Vision Simulator. (n.d.). Pilestone Inc. https://pilestone.com/pages/color-blindness-simulator-1
Agile software development. (2021). In Wikipedia. https://en.wikipedia.org/w/index.php?title=Agile_software_development&oldid=1023834429
Waterfall model. (2021). In Wikipedia. https://en.wikipedia.org/w/index.php?title=Waterfall_model&oldid=1023844880
9 Last Minute Changes That Hurt Video Games (And 11 That Saved Them). (2018, September 20). ScreenRant. https://screenrant.com/video-games-last-minute-changes-hurt-saved/
Attribution Statements
Contains public sector information licensed under the Open Government Licence v3.0.
