Octopocalypse

Introduction

For my final project I intended to take on a design role for a newly formed team, intent on creating a new game with the goal of publishing to Steam at the end of the module.

The team formed from a joint desire to create a product that could be published and serve as a star portfolio piece to springboard members into industry job roles.

The team planned on splitting work time between the newly reopened studio and remote work, as had been the norm in the previous modules, however due to complications and difficulties with the restrictions on the studio environment the team switched to full remote work early in the project.

I chose to join this project as I saw it as the best opportunity to gain further game development experience in an industry style work environment, as I would once again be working with a moderately sized cross discipline team my hope was that I could further my team working skills alongside working on my design and technical abilities

As part of this group project, I chose to act as gameplay and UI designer as well as design liaison for the team.

Figure 1: Roles and Responsibilities Slide from Project Proposal

This was a wonderful opportunity for me to experience a small-scale version of what working on a project with cross team communication would be like and how different departments work together and individually. Whilst I intended to fulfil my role as UI designer and liaison to the best of my ability my primary focus was on the gameplay design as that is the heart of any good game and would require the most work to meet the project requirements.

My plan was to take a more active role in the production of the game and step away from heavy documentation work which had dominated the majority of my time on the previous project, where I would spend days writing up verbose design documents with word counts in the thousands that were barely used by the team and would sometimes still require further explanation when they were.

To this end I decided to take a more streamlined approach to design documentation using the post it method for brainstorming with the team and then taking those post its and creating mind maps that contained the design work for each feature, this allowed me to create designs much faster and forced me to be more concise with my explanations for how things needed to work.

Figure 2: Time estimation chart for project

I also decided to split my time between research, design work, liaison duties and game testing/balancing and technical work by doing this I hoped to have a better idea of the state of the game and the tools available at any given moment allowing me to make better decisions regarding design work and vision.

Figure 3: Initial game idea Miro Brainstorm

After initial team brainstorm sessions, the team landed on an idea to create a fast-paced platformer focusing on grapple mechanics and air movement. However due to communication difficulties – brought about by the remote work environment because of Covid-19 – the team was unclear on the vision for the game and motivation and faith in the project floundered. This led to an emergency meeting wherein the team, realising the full vision for the proposed game, decided that a major pivot was needed. This was mostly due to the programmers realising that the work required to create the proposed game would need, at most, 2 of the 4 programmers on the team.

Figure 4: Finished Main Menu Screen

As such the team pivoted halfway through week 3 of the project to a 3rd person arena shooter game which the team was much happier with overall.

The following portfolio will chronicle my journey with this team, explain and justify the design methodologies used and design work created using them, along with the choices I made during production and the additional roles and responsibilities I had to take on throughout the project’s lifespan. I will also take time to reflect and review my actions and work to determine what was successful, what was not successful and what can be learned from this and how future project could be improved and benefit from the lessons learned here.

Linked below is my project proposal, created near the beginning of this project just after the pivot in design occurred and which states my proposed intentions for this project and will be used to evaluate against my work done during this project.

Research:

As stated in my proposal I intended to conduct a large amount of research into varying topics throughout this project and while I was able to do a sizeable amount of relevant research the areas, I found myself researching were not always those that I had initially planned on focusing on.

I spent a lot of time researching relevant games and design methodologies settling on a method that combined the post it method from Savage and Greene (2021) and the design process used by NetSpeak to create a custom process that served me well throughout the project. They both focus on quickly generating ideas and creating concise design documentation to be able to quickly allow the prototyping of features. It is advised that each feature should take one day to design with this method.

I had also stated in my proposal that I would endeavour to research art and programming processes; however I was approached early in production by our then producer who asked that I take up the role of product owner/creative director to help make sure decisions were being made and the project didn’t stagnate with indecision. This, they explained, was due to their own research that had shown them that their previous method of trying to take on the role of both product owner and scrum manager could be detrimental to the production process and they wished to focus on being the teams scrum master and producer. As such I delved into research about the role of product owner focusing mainly on Cohn (2013) “Succeeding with Agile” which also outlined that the scrum master and product owner roles should be held by different people as they should naturally be at odds with one another with differing concerns that needed to be balanced out by each other’s opposing viewpoints. This was a great read and gave me a new appreciation for the differing roles in the agile framework.

Due to the pivot partway through the project and our producer leaving due to work I ended up taking on extra responsibilities and workload in order to try and help see the project over the line; as a result of this part way through the project my research focus switched purely to design.

Figure 5: Extract from Risk of Rain 2 Wiki

As a result, the rest of my research was carried out on games with relevant features. Much of the game research time was spent on Risk of Rain 2 (Hopoo Games, 2019.) as it was a heavy influence for the overall vision of the project. Research involved reading development blogs, technical breakdowns, reviewing feature breakdowns and review videos, Metacritic scores and player feedback and finally playing the game with the team. This all provided excellent insight into what made the game so successful and beloved by its fan base – such as the unique ways to build a character on each play through – providing quality reference material for features throughout the project.

I also found myself referencing back to research from previous modules especially when concerning UI design and general best practices from working in an agile environment and game development teams as a whole. I also revisited my research into reflective practices from this portfolio so that I could better evaluate my work and actions at each stage of the project and to reflect on the project and my overall experience.

Design Process:

One of my major focuses for this module was to create a process that I could use throughout the project to quickly and effectively produce designs for game features, which could be easily understood and used by the rest of the team. I especially wanted to create a system where the team could be more involved in the design process, my hope was that by having the team more involved in the designing of features they would be more invested in the production of said features and this would help aid in productivity and accountability.

Figure 6: Design Pipeline Slide from Project Proposal

I combined aspects of the “post it method” from Savage and Greene (2021) and the design process used by NetSpeak to create my own process for use in this project. Both methods use the same stages of brainstorming ideas as a team, then taking those ideas and creating user stories with them, defining problems that need to be solved based on the user stories, researching games with relevant mechanics and how they solve these problems, then using this research to synthesise how the feature will work and function. Finally this synthesis is used to create a list of assets, art, animation, sound, and VFX that are required for the feature; these can then be added to the art asset list. A technical requirements list, which lays out what the feature must be capable of doing, how it should interact and be interacted with and what characteristics and attributes it must possess and be accessible to the designers, wireframes, can also be created at this stage if appropriate.

Figure 7: Assets slide from Project Proposal

Once these designs have been made, they can be passed to art to prioritise, plan, and produce and to programming to begin prototyping.

Figure 8: Technical slide from Project Proposal

From the research I had done, and discussions I had with people working in the industry, I created a template to use with the design process after initial idea generation with the team (see figure 9) the following template would be used (see figure 10). As a team we decided to use Miro for our brainstorming and idea documentation – this was very useful as my process was based off the post it method and Miro has a built in sticky note feature, allowing us to use my process, based on the Post-it method, effectively.

Figure 9: Example of brainstorming session

Before using the template, ideas must be brainstormed; I consider this to be step 0 of the process as it is more free form and not constrained to a template. The standard way we would brainstorm would be to get as many team members that were available to jump into Miro and begin throwing out ideas using a similar method to the 100:10:1 (Blog.fogus.me. 2015.) approach though with far less rigid restriction on numbers, essentially we would all write down any idea that came to mind and after a set amount of time, usually around 20 minutes (so as to not take away too much from other tasks), we would narrow down all the ideas to the few best, discuss as a group and then pick the ones that were deemed best to be incorporated into the features design.

Figure 10: Design Template

As the project went on less and less team members would participate in the brainstorming due to issues that arose and eventually, I saw myself doing the brainstorming alone which was not ideal but did help to speed up the process which at the time was greatly needed.

The template consists of the features designation: this could be the name of a player ability or an enemy type, it can also be a system that the game will need – for example, the enemy spawn controller, etc

Figure 11: User stories Design Template

From this the linear process begins; the ideas generated while brainstorming are used to create user stories which define what the feature should accomplish in a “as the player I would want to be able to do this… with this feature to achieve this outcome” way. A second example would be: “I would like this feature to feel/play like…” for instance, “I would want to use the sniper rifle to take out enemies accurately from a long distance”.

Figure 12: Problems Design Template

Next, problems-based questions are created from the user stories, for example “How can we make the sniper accurate without being overpowered?”. These are then used later to help inform research and need to be resolved by the synthesis section.

Figure 13: Research Design Template

Thirdly, research is conducted into a few games with similar features (ideally games of a similar genre) and a screenshot or video clip can be included where appropriate along with a few notes on how that game implements the feature.

Figure 14: Synthesis Design Template

Then we move onto synthesis where we answer the design questions posed by the problems section, and describe how the feature will work in our game, what the player can do with it etc. This achieves our user stories at the same time.

Figure 15: Assets and Technical Requirements Design Template

Finally, we note down all the assets needed for the feature to work, art, animation SFX, etc and all the technical requirements which are needed for the feature to exist in the game; at this point future considerations should be taken into account when creating this list. This is also the point where a wireframe can be produced if appropriate.

Figure 16: Example of testing prototype

With the design templates handed off to the respective departments, I would continue working on other features templates and answer questions about ones already in production until the initial prototype of a design was ready to be tested. At this point I would go into the build with the team member responsible for the feature and test it with them; we would discuss how close it was to the initial vision, how well it achieved the intended functionality for the feature, variables that needed exposing, how it could be manipulated for testing and balancing in engine, etc. After this testing we would discuss any changes that needed to be made to the prototype and I would make any necessary changes to the features design template to reflect these. We would repeat this process until the feature was achieving the user stories in a satisfactory way, at which point the feature would enter the polishing, balancing and bug fixing stage.

My process for balancing a feature was to get as many people on and off the team to test it as possible; I would collect feedback and make changes as appropriate; for example if we were testing an enemy and the feedback came back with a consensus that the enemy was really hard to deal with and it felt like it was overpowering the player constantly, then I would look into reducing the enemy’s health so that the enemy could be dealt with more quickly. I would then reduce the enemy’s damage to see if that elevated the overpowering nature. Ideally, I would have made these changes independently and given them back to the testers to retest and then evaluate the results to help narrow down the root cause of the problems, but due to time constraints I made multiple changes at a time before sending them back to all the testers to retest.

Despite the reduced design time that this process produced when compared to previous processes I had used I, still found myself without enough time to complete all my assigned work, as such I began to do less testing and more solo design work. While this did allow us to rapidly create and implement new features I do feel that had we reduced scope to allow for the process to be followed properly throughout development that while boasting less features the game might well have turned out better and more innovative overall.

However, while the process was being followed properly, I did notice that enthusiasm on the team was higher, communication was more frequent and productive, and the quality of work produced seemed more polished and complete.

Introduction to Project Overview

The team I worked on for this project consisted of 4 programmers, Dan Price, Ysabela Bathan, Bran Middleton and Mia Hussain, 3 artists Laura Clarke, Ben Dodd and Jess Ancill, 2 designers myself and Jamie Morris and 1 producer Oliver Rockett.

Figure 17: Our Team Slide from Review Presentations

As a team we wanted to create a small but complete game that could be published to Steam at the end of the module; to that end our initial design for the game was a fast paced first person platformer in the style of Cluster Trucks but incorporating a grapple mechanic and use of levels populated with floating islands. However, after 2 weeks of working with this idea the team realised that the scope would be too small for four programmers and possibly too large for only two environmental artists as we realised, we would need at least 12 levels to make a viable game.

Figure 18: Early level design (by Jamie Morris)

This resulted, after much discussion and brainstorming as a team, in the pivot to creating a third person arena shooter in the same vein as Risk of Rain 2. As such Oliver was to act as scrum master and project manager, keeping our production documentation up to date, ensuring the team would have time to complete all their tasks and helping to organise stand ups, retrospectives, and weekly testing sessions. Bran, Dan, Mia and Ysabela decided to split the programming work evenly so that each would get a chance to work on AI, UI and systems features; this was both to aid in their personal goals and development but also to give everyone a general idea of how each other’s code was interacting with other systems to help with bug fixing later in production. Jess and Ben decided to evenly split the research and creation of assets for the levels, with Ben focusing on more organic aspects, foliage, dirt, trees, water, etc and Jess focusing more on man-made structures and solid surface objects such as rocks. Laura was our dedicated character artist responsible for the player character, all enemies and miscellaneous creatures in the game. Jamie was to be the sole level designer, with the initial target being 3 levels. I was to be the sole gameplay and UI designer designing all systems and features required for the game to play and all UI aspects from menus to the HUD, I also ended up with the product owner role as both with the initial game idea and the final one I was the primary driving force behind design decisions. I would also later inherit much of Oliver’s production role when he left the team.

Having worked with most of the team before, I was excited going into the project and believed that we could achieve what we had set out to do despite the two-week set back.

Figure 19: Early X Statement and Elevator Pitch

As a team we came up with the X-statement and elevator pitch for the game which we felt best encapsulated the vision the team had created for the game.

Figure 20: Razor Products

Our Razor products were fairly easy to decide upon: many of the game’s initial ideas spawned from a number of the team being fans of Risk of Rain 2, Hades was chosen due to the desire to have environmental aspects in the game in the hopes of recycling some work from the previous game idea and Immortals was brought over from the previous game’s intended razors as the art direction for the game remained largely unchanged.

Figure 21: Pillars of Design

Figure 22: Unique Selling Points

Figure 23: Meta Critical Breakdown of Gameplay

We then created Game pillars, unique selling points and laid out a meta critical breakdown of the game play as a team

Figure 24: Projects Minimum Viable Product

Our MVP was straightforward and very achievable we planned on having 1 fully polished arena with player projectile gameplay and 1 working ability, 1 fully functioning enemy with spawning system and working music/SFX. We ended up with one finished arena, one projectile weapon for the player, three working enemies a robust spawning system, two character abilities with a working upgrade system, 2 level hazards and a working UI including tutorial guide. We achieved this by following a production philosophy laid out by Oliver early in the project: we were to effectively create a fully working game at each milestone, with the first to effectively be the MVP. After that we worked on adding in new features and systems that built upon the simple foundation, with the goal being to have added on all the features required to make our idealised game. This did not quite come to be but the process did ensure that at any stage were we to find ourselves drastically over scoped or without team members to continue creating new features we could simply take what we already had and turn it into a working game.

Figure 25: Production Plan from Project Proposal

I created a personal production plan for my proposal which outlined the work that I would need to do for the team to ensure the project’s success. This was created to fit within the milestone targets the team had set.

Figure 26: Milestones from Project Proposal

Figure 27: Timeline from Project Proposal

Weeks 1-3:

The beginning of this sprint consisted of the team brainstorming ideas for the primary movement system for the initial game idea of a fast pace platformer. The team came up with six ideas that we wanted to test to see which would be the most fun and which we should take forward into production. As such, each of the four programmers and myself and Jamie were assigned one of the six ideas to prototype by the end of the first week, at which point the team would come together and review all the prototypes and decide which one would be carried forward. I was assigned the gravity flip prototype which allowed the player to walk on ceilings and potentially also walls.

Figure 3.

Figure 28: Gravity Flip Prototype(a)

I set about researching if Unreal 4 had a built-in way of doing this and found that in order to do this properly and effectively you had to create a new movement system, rather than using the built-in one in Unreal. This immediately raised concerns as this would be an enormous undertaking for the programming team; however, I still decided to make a prototype that could at least demonstrate the gameplay that a feature like this could bring. Therefore, I created a system whereby the player camera would invert so that the player was looking at the world upside down, and then set a movement force on them that would push them towards the ceiling. This allowed the player to walk along the ceiling – although the movement was very erratic due to the nature of the Unreal 4 movement system. This inversion could be achieved by the player pressing the hot key or by walking into a trigger volume which would automatically invert them. They could then walk into another trigger volume or press the hot key again to reverse the effect, returning their movement to normal and sending them towards the ground. I then created a small building to demonstrate how this could be used in a gameplay functionality by having a two-storey building, with a small gap in the ceiling being the only way up. The player would then have to invert gravity in order to get on the ceiling move to the gap and ‘fall’ up into the upper room.

Figure 29: Gravity Flip Prototype(b)

I then built another room blocked off by a wall which could only be accessed by a small hole. I created a floating platform that was moving between the room the player was in and the room on the other side of the wall. The player would have to time the inversion to land on that platform and be carried over to the other room. When we reviewed the six movement systems at the end of the week; while the team was intrigued by what I had made and came up with a lot of exciting ideas for how it could be used in a full game, we ultimately decided that the undertaking for the programmers held far too many risks as none of them had ever done anything like this before. Consequently, we elected to go with another one of the ideas which was the grappling hook which had been worked on by both Bran and Ysabela. Bran had created a grappling hook similar to those found in Spiderman games or A Story About my Uncle and Ysabela had created one similar to Pathfinder’s grapple in Apex Legends. The team liked the idea of combining these two movement systems to traverse a level and so the next task was to take this prototype and design a full grapple system for it for the programmers to create.

I learned a lot from this process as it was the first time I had done prototyping before full design work – in previous modules, we had forgone prototyping and gone straight into production, and all prototyping had come after initial rough design drafts. I found it very useful as it really helped to show where the fun would lie in such a mechanic and allowed better visualisation of how it would work in a game which in turn gave me more ideas for how to design it. This is something I hope to continue in the future as I think it’s an excellent way of finding the fun early in a project and ensuring that the end product will be entertaining. However, on reflection, the prototyping took too long – it was a full week before we could decide upon the movement system that we wanted to go with and this meant that it wasn’t viable to we prototype after the pivot because we simply did not have enough time to spend another week creating prototypes.

Figure 30: Grapple Design

Once the prototyping was done, I moved on to design and research.

Figure 31: Mechanics Brainstorm for Old Game

I managed to create designs for the characters movement, including: sprinting, jumping, how the character should fall, and the level of control the player should have while the character is falling, the grapple mechanics (both-Spiderman like and Pathfinder-like), a dash mechanic and a time-slow mechanic, which was suggested when team members raised concerns about the lack of control over the characters movements at high speeds and how that could become frustrating, as we were planning on having hazard avoidance be a major part of the gameplay.

Figure 32: Hazards Brainstorm for Old Game

I also managed to create designs for free hazards laser beams which were very versatile and could be used in multiple ways: they could move between fixed points, they could rotate, they were blocked by physical objects, and they could be paired together to create gates that would open and close. These were really exciting to work on because the designs reminded me a lot of the type of hazards that were used in games such as Clustertruck which were a big inspiration for this game. I also designed blocker and rock thrower hazards and moving platforms for the player to use while traversing levels.

Figure 33: Beam Hazards Design for Old Game

All these designs took approximately a week; while some of them had a lot of input from the team, towards the end of the week participation fell off in terms of idea sessions. This was quite disheartening for me as I was putting a lot of work into the designs and as the attendance fell off, I also felt that a growing discontent was forming in the team towards the game idea. I tried to get them come to more idea generating sessions to help instil a sense of investment and ownership of the game, but this didn’t materialise. I think in the future I would try and be more encouraging, positive and uplifting to try and get team members to speak up more about concerns so that they can be addressed and a healthier, more collaborative work environment can form.

On the Tuesday morning, two days before the review, the team had a meeting to discuss the vision for the game and the direction it was going and it was discovered that a fair number of the team were not happy with the creative vision for the game. In some cases, it was simply because they didn’t think the game would be enjoyable and they weren’t excited about working on the game. In others, particularly amongst the programmers, there were concerns that the game wouldn’t require four programmers to be made and it wouldn’t fulfil the criteria required for a final major project. With all this being brought to light, we made the decision as a team to go back to square one and find a new game idea to take forward and to make throughout the rest of the project.

As such, we held a brainstorming session for the whole of Tuesday to come up with a new game; eventually, after considering the experience on the team what people had made before what systems people were familiar with and what art assets people had made before, we decided to settle on creating an arena shooter. Due to us having a character artist on the team, we elected to go with the third person arena shooter.

This was very disappointing for me as I had grown attached to the vision of the previous game and believed that we could make a very entertaining game out of it. However, I could understand the concerns of the team – especially the programmers. While we all wanted to make a great game and a fun game we were all also on a Master’s course and that needed to be taken into consideration in any decisions we made. What this taught me is the when there is a lack of communication in a team it means problems get pushed back and not discussed until the point where they can’t be ignored anymore – at which point, options for mitigating the fallout are limited. If these concerns had been brought up earlier we could have potentially saved a week or more of development time; as such, going forward I will endeavour to make sure that people feel comfortable and able to speak up about any concerns they may have and encourage people to do so, thus these issues can be addressed earlier.

Figure 34: All completed design for old game

The review for this portion of the project was surprisingly positive, given that two days earlier we had pivoted on the entire game and only had one full day to come up with an X statement, elevator pitch, pillars, unique selling points, and MVP. Concerns were raised by the advisors about scope and the time lost but the direction we were taking was praised.

Overall, the team was very happy with the feedback as we had been expecting a far more negative response given our lack of work to show. We therefore entered the next phase in high spirits. We also took their feedback on board and as a team decided that we would continue the initial idea proposed by Oliver that every Sprint should produce a complete game loop, so that at the end of every Sprint if there were any problems later on we still had a full game loop that we could fall back on, polish and create a game around.

Weeks 4-5:

During these two weeks, the team was working towards creating a prototype and target visual for the game for the review; below are our milestone targets for the prototype. We were able to hit all bar two of the goals – those being a fully working UI menu and place holder sounds.

Figure 35: Prototype Milestone from Project Proposal

Below is a list of my tasks for the two weeks. I had estimated that I would be able to get all these tasks done in the time I was given to a high quality and while I did get the designs for all of these features done before the review as time went on I realised that I was spending too long on the designs and that I might not finish before the review. As a result, I started to cut corners where I felt I could to ensure that the rest of the team would have some design documentation to work from. During these two weeks the quality of the designs did not diminish significantly but it did set a bad precedent.

Figure 36: Production Plan for weeks 4-5

While this change in my process did allow me to produce design work at a higher rate, and the team was satisfied with the quality of my work, I am now aware that I could have done better had I followed the process I had laid out fully. I do believe that the work I produced was good and that it resulted in the creation of a good game, but had I followed the process thoroughly, I might well have been able to help design an even better game that would have been more innovative and more fun. Unforunately, due to circumstances that come up in the following weeks I was unable to both go back to fully following the process and fulfil all my roles and responsibilities on the team; as such I chose to compromise where I could. What I have learned from this is that I need to be willing to admit when I have too great of a workload and discuss that with my team to see if I can have my workload lightened or altered so that I can continue to produce the best quality work possible without impacting the game.

Below you can see samples of my design work for the two weeks:

Figure 37: Main Menu Design

Figure 38: Sprint, Jump, Dash and Time Dilation Designs

Figure 39: Knockback Design

While my work was well received by the team in terms of quality, I still received requests from team members to clarify my designs from time to time. This caused some minor delays in programming work, and was also quite upsetting to me as I was working very hard to get all of the design work done on time and believed that I had created clear and easy to interpret designs. My interactions with the team, however, showed me this was not the case. I used this as an opportunity to ask what about my designs was not coming across well. I discovered the many of the programming team found my wire frames difficult to interpret; this was likely because I did not have much experience creating wire frames for non-UI elements. To resolve this, I asked whether dropping them and simply pointing the programmers towards examples in other games that behave in the same way as my design would be more effective. They agreed and thus I forewent creating wire frames for future designs.

Figure 40: Weapon 1, 2 and Camera Designs

Figure 41: Enemy Spawn System Design

As the game was fully in production, bugs were now beginning to be found during testing and development. Initially, we had intended to use a bug tracking table created by Oliver to record bugs, to then be assigned and fixed by members of the programming team at later dates. However we found the when bugs were discovered they were most often reported to the programming owner of the feature who would then go and fix them the same day and as such the bug table did not get used very often. This was positive in that most bugs did get resolved the same day they were discovered; however, it did mean that any that did not get resolved the same day tended to stick around for a long time because there was no written record of them. In the future, I would insist on the proper procedure being followed as while it may be slightly more time consuming then simply informing someone about the bug and having them fix it, it does ensure that bugs do not slip through the cracks and end up creating a development debt at the end of the project that could cause problems when the game should be being balanced and polished and ready for going gold.

The review was primarily negative. Art was heavily criticised, and gameplay was questioned, particularly regarding whether it would be fun to play. The team was advised to create a static visual target for environment and characters and it was advised the enemy count be increased to create a more chaotic and frantic environment to help facilitate fun gameplay as well as the team focusing on the two enemies we already had and the gameplay mechanics, polishing them before doing anything else.

The team was very disheartened by this feedback but took it on board and discussed the necessary changes. For my part, I rebalanced the spawning system to spawn at a higher rate. This would later be reverted due to some technical issues, but it was noted by the team that it was more fun and would eventually be reinstated. The team did however elect to forgo the advice of halting the addition of new features as it was believed by the team that the features planned for the next review would help make the game more enjoyable.

Overall, we managed to get a lot of work done and these two weeks. I do however feel that we presented it poorly to the advisors in the review and the core appeal of the game was lost in the presentation, which has been a problem throughout the course due to the limitations of COVID-19 and remote work. I feel the best way to combat this would be to create builds ahead of reviews that could be sent out the morning before, giving the advisors a chance to play the game before coming to the review so they can have a better understanding of what they are seeing on screen.

Weeks 6-7:

The start of this section of the project marked the departure of Oliver and saw me picking up a lot of his day-to-day responsibilities as scrum master. This saw me running the daily stand-ups, the Sprint planning sessions at the beginning of each week, the retrospectives at the end of each week, the updating of the presentation for each review, and overall making sure the everyone’s work got done on time. This had a negative impact on me both in terms of my work and my mental health as I felt I was being overloaded with responsibility and tasks. This resulted in a lot of stress however I handled it as well as I could at the time. With hindsight, I should have realised that it was too much for one person to take on and requested either outside help or for other members of the team to share the burden with me. This would have helped reduce my stress and my workload which would have increased the quality of my work for this section of the project.

Here we see the team’s milestones for these two weeks. While the team was able to complete everything in the first playable section, we were unable to create the second level and tutorial and narrative elements for alpha. This would go on to affect our beta milestones and set the team back. which in turn caused a drop in morale. This was unfortunate as we had already met our MVP and while we were unlikely to be able to get more levels done, we were still able to work on an improve the game before the end of the project. 

Figure 42: First Playable and Alpha Milestones from Project Proposal

We can see here the tasks that I assigned myself for these two weeks. This was a higher workload than in previous weeks as I had hoped by this point I would be well into the flow of the work, and would be able to produce more designs per day. However, with taking on the extra responsibility left behind with Oliver’s departure, I was barely able to get all the designs done and fulfil my other responsibilities. Again this goes to show that I should have done something about the extra burden placed on me, as had this been lightened, I would have been able to complete all my design work within the time necessary, and focused on testing and balancing, which is the area that suffered during these two weeks the most.

Figure 43: Production Plan from Project Proposal

Here we can see my design work for the HUD. I looked at Risk of Rain 2, Hades and Ratchet & Clank: Rift Apart as my main inspiration both risk of rain and hades had minimal UI. With this research and working with the knowledge that we had neither a dedicated UI programmer nor UI artist, I elected to design a UI that matched these minimal designs taking heavy inspiration from Risk of Rain 2, due to its being the closest game to the one we were making and produced a wire frame to help with the team visualising the placement for the different elements of the HUD.

Figure 44: HUD Design

For the Options menu, I looked at Risk of Rain 2 and Hades as I was unable to find decent quality video or images of the Ratchet & Clank UI. I noted that both games use sliders for volume control and anything that might have a large number set like field of view. I also noted that they both use tick boxes for most of their options. I particularly liked Risk of Rain’s use of a tab system, which allows the menu to all be contained on one screen and the player can move through tabs, removing the previous menu section and bringing up the new one to the screen without the need to open a new window. I also liked that both games would display a description of what the option did if the player was to hover their mouse over it. As such, I decided to go with a design once again similar to Risk of Rain, using a tab system, and a description for any option that the player hovered over. This feature never made it into the game as the programmer assigned to the task was given a lot of other responsibilities and this was considered low priority and eventually got scrapped from the project. However, we did get the core options that we wanted into the game primarily volume control, and on-screen resolution settings, which used a drop-down menu as it was the most prevalent amongst games researched.

Figure 45: Options Menu Design

The upgrade system was going to be one of the biggest undertakings for the programmers, as it would involve coordinating with a lot of other systems in the game – chiefly the enemy spawning system. When looking at Risk of Rain 2, Hades, and Ratchet & Clank, one thing I noted about all three games was that the player brought their upgrades. In the case of Risk of Rain and Ratchet & Clank this was with a currency and in the case of Hades it was with time and skill by completing a room. At the time of first designing the system the team didn’t think it wise to try and incorporate a currency system into the game, as an upgrade system alone was complex enough. As a result, I opted to go with the player earning upgrades through combat and decided that after a certain number of waves, the player would simply be given an upgrade. Once they had earned this upgrade the game would pause and bring up a menu for them to select an upgrade from. In the spirit of the Roguelike genre which many of our research games belong to, I decided to make the upgrades that appear random – both in terms of which ones were made available each time and how many. This was later changed in the project so that’s the available upgrades were still random, but the number was always three unless there were less than three left in the pool. I also created a wire frame for the upgrade menu UI and created descriptions for each of the upgrades that we wanted in the game. Due to time constraints and me having fallen behind on my design work I had a meeting with the programmer assigned to the upgrade system and asked if they would need full design templates for each of the upgrades I had proposed, to which they thankfully responded that they understood what I wanted from each of them and that they would be fine working from these for the most part. If they had any questions they said they would contact me which they did and this actually helped to improve communication throughout the team, as they were having to coordinate with many other members of the team in the creation of the upgrade system and this communication filtered through to everyone and boosted team morale and coherency for a time. If I were to go back and redo these designs the main thing I would do would be to fully flesh out the upgrades as while the programmer was able to interpret my descriptions accurately for most of them, a few of them did require a lot of back and forth between the two of us before we reached a mutual understanding, and while I believe overall time was saved doing it this way I feel that the quality of the end results was diminished.

Figure 46: Upgrade System Design

Figure 47: Upgrades Brainstorming

Figure 48: Tank Design

When designing the tank enemy, I took heavy inspiration from Risk of Rain 2 and saw that it used the rock golem enemy as an anchor for fights. It was slow moving with a powerful ranged and melee attack. Due to its long-ranged attack and high amount of health players would need to focus their attention on it lest get too close and overpower them. Therefore, I designed our tank enemy in a similar fashion: high health, low movement with both a ranged and melee attack. However, in order to keep the tank more in line with other enemies in our game I reduced its maximum range for its attack and made the media attacking AoE around the tank rather than in front. This served to make the tank more dangerous and less of an obstacle to be avoided and more one to be confronted.

Figure 49: Floor Hazard Design

Floor hazards took heavy inspiration from Hades which makes extensive use of spike traps, lava, and other environmental hazards. Consequently, I decided to create a version of the two most common forms of hazards I found during my research, which were the static floor hazard (which is simply an area where should the player enter they will be damaged while they remain within the area) and an active floor hazard where the player enters a given space and the hazard activates usually with just enough time for the player to be able to avoid the hazard if they’re quick enough. This floor hazard was initially envisioned as a sort of geyser that would go off periodically but eventually it evolved into the eel that we have in the game now as our character artist created an eel model which the team decided would be a more thematic hazard, and we found that the active floor hazard wasn’t particularly fun to play around as it was hard to tell exactly when it was going to go off, whereas the redesign with the eel meant that it would go off whenever the player or an enemy entered the trigger box.

During these two weeks the team also began sourcing third party VFX and SFX; this was primarily done by myself and Jamie. I would give Jamie a list of sound assets that we needed and he would go away and source them and come back and we would discuss the ones that he found, whether they could be used if they would need to be modified. I also found a few sound assets here and there for ones that we either felt needed replacing or that we had missed first time round. I also sourced some visual effects for the game specifically the weapon bullets explosion effect hit markers geyser effect which was also used for the tanks weapon.

Figure 50: Equipment System Design

My largest task for this part of the project was to prototype a possible equipment system to be used alongside our upgrade system, to give the player even more variety in their character progression. This was assigned to me as I had expressed an interest in doing some technical design work and all the programmers were busy with other tasks. First I set about designing the system mostly looking at Risk of Rain 2 as the purpose for the system matched very closely to that of the equipment system in the game after producing the design template I moved on to prototyping in Blueprints.

Figure 51: BP_Equipment Spawner(a)

Above is the equipment spawner blueprint: at the start of the level it calls the spawn equipment function and creates a reference to all the spawn location actors which are placed throughout the level. These were used to denote the places where equipment could spawn; after having looked back at this I realised that I could have incorporated the spawn locations into the equipment spawner blueprint itself with an array of locations and were I to make something similar to this again that is how I would do it.

The function that is called on begin play finds all equipment location actors in the level and sets the array of spawn locations. This is done so that if this was to be used on a different level you can just drag and drop everything into the level and not have to set anything up manually. Next it finds all current equipment actors in the level and destroys them; this allows the system to spawn equipment for out each play session without the map getting overcrowded or duplicate spawns occurring. This also means that this function can be called at the beginning of play and at each instance when new equipment should be spawn without the need for two separate functions. Next, the spawn locations are put through a full loop which runs for the number of times equal to the amount of equipment we want to spawn – in this example it will spawn either two or three equipment for each loop. A random spawn location is retrieved from the array, which is then added to a new array called new spawns, and that spawn location that was chosen at random is removed from the spawn locations array to prevent it from being picked on subsequent loops. This is also why the function grabs all the spawn locations each time; it is called because some of them will have been removed on the previous spawning. Finally, for each of the new spawn locations that was decided in the previous section a for loop is called which spawns an equipment actor.

Figure 52: BP_Equipment Spawner(b)

Next, we will look at the equipment actors themselves. When they are created they set the array called available equipment to the same values as all equipment which is a variable stored inside the equipment base actor which holds all of the possible equipment that is in the game. Then we create a reference to the player character for use later and then from the available equipment array we pick an element at random and set the this equipment variable to the same as the randomly selected equipment this variable identifies the actor as the specific piece of equipment then the actors static mesh is set using the value obtained from the equipment array.

Figure 53: BP_Equipment Base(a)

When the player overlaps the collision sphere for the equipment base item, the function add equipment to player is called from the function library and the actor is destroyed. At one point I was attempting to use event dispatchers to handle the relaying of information that an equipment item had been picked up. This however proved more difficult than I anticipated and so I resorted to using a function library and having functions call other actors’ functions to set everything up properly. 

Figure 54: BP_Equipment Base(b)

Figure 55: BP_Equipment Base(c)

In the player blueprint when the player spawns the game checks to see if this is the first level or not. If it is the first level the game sets the players equipment variable to the all equipment variable from the equipment base actor. If it is not the first level, the game gets the player equipment variable from the game instance and sets the players equipment to this value. This was intended to be used to allow equipment to be saved when travelling between levels. There is also a function set up called save equipment which casts to the game instance and sets the player equipment variable to that of the player’s current equipment.

Figure 56: BP_Player(a)

Figure 57: BP_Player(b)

In the function library, the function add equipment to player is passed the equipment data for the item the player just picked up. We then cast to the player blueprint and get the players equipment variable. We use the passed information to increment the equipment amount value for the one picked up. This will mean that if the player has never picked up one of this equipment before it will go from zero to 1 and if they already have at least one of the equipment the number will be increased by 1. This will then call save equipment from the player blueprint so the equipment can be stored between levels a more then called the update player function from the function library.

Figure 58: FL_Equipment (Add Equipment to Player)

The update player function simply gets the equipment name that was passed to it by the add equipment to play a function and uses that to determine which function needs to be called before this prototype was scrapped I had only created 3 functions related to equipment.

Figure 59: FL_Equipment (Update Player)

Here we can see the function for the Sprint speed up equipment. This particular one works by casting to the player blueprint getting the character movement component getting the current Sprint speed adding 10,000 to it, for the purpose of testing, and then setting the Sprint speed to this new value. The intent was for each equipment to have its own function, hence the use of a function library to contain them all and they all would have in some way altered the player or the players weapon to create interesting gameplay mechanics.

Figure  60: FL_Equipment (Sprint Speed Up)

The prototyping of the equipment system was going well before we as a team decided to discontinue work on it due to there just not being enough time to fully implement and balance this and the upgrade system, and eventually some of the intended equipment items were merged into the upgrade system. This includes ones such as increasing dash and jump amount and giving the player the ability to critically hit. I believe that this was the right decision given the time we had on the project; however, I would have liked to have seen if I could have completed this prototype and got all of the equipment pieces working. I would want to find more effective and elegant solutions to a system like this were I to create one in the future. I already know that I would Incorporate the spawn locations into the spawn controller rather than having separate actors for it. Were I to make this again I would also want to find a better way of having all of the blueprints communicate with each other as casting all the time is not the most efficient.

The planned boss enemy design was scrapped before the first Sprint of these two weeks as the team was already very aware that time was short and that while we could create a boss in the time we had left we felt that time would be better spent working on multiple other features rather than focusing everything on getting a boss working and polished. In the same vein instead of having a separate enemy spawning controller and wave controller we decided to combine the two for ease of balancing as everything would be in one place and also to help reduce the overall workload for the team and so the enemy spawning system designed in the previous weeks was updated to reflect this change.

Despite rushing some of the work again in these weeks I found that my work was once again well received by the team,  especially the equipment system which while scrapped was praised for how much I was able to get done in a short amount of time. Once again though, I know that had I made different choices during the week to help reduce my workload and allow me to work through the design process properly I believe that the end result most likely would have been better.

These two weeks saw a turbulent time for team communication. First morale was low and team communication stagnated; however once I began interacting with programmers to pass off my design work towards the end of the first week communication began to improve as questions needed answering and discussions were hard about improving upon designs and tweaking existing assets. By the end of the two weeks communication was back on track, though the morale was still lower than it had been in previous weeks. This was upsetting for the team but to be expected given the stage of development we were at. I believe that had we had more bonding exercises such as playing video games or going out for food together, it would have really helped morale and bring the team closer together and helped us function better and work better together. I would have liked to have done this but given the amount of work I had I had almost no free time and so once again in the future I will ensure that I have an adequate workload which will then allow me to take better care of myself and the team that I am a part of.

For the review the team managed to get the HUD, tank, upgrade system, foliage, man-made structures, grunt model, new exploder model, and tweaked player model into the game. We also swapped the player’s weapon from a ballistic to a hitscan weapon as we believed that that would feel better to use especially in conjunction with the time dilation ability. This proved challenging at first due to the way that the weapon had been initially programmed but eventually we managed to come up with a solution where by the weapon word trace from the centre of the camera to the crosshair and then the projectiles would fire from the character’s hands to the point traced to.

The team got mixed feedback at the review. Advisors were still unconvinced by the game’s aesthetic and fun factor and we were advised to add in some form of tutorial or sign posting as the advisers also said that they had no idea what their objective was or what they should be doing in the game. One of the advisors had chance to play the game and said that the mouse sensitivity was too high and was at times disorientating, and that the screen shake effect was too intense. They also stated that they were confused by what the man-made objects were doing, and why they were there. They also said they looked too clean, like they were created very recently. They also said that the game needs something else for its loop, something that encouraged moving around the level and killing enemies beyond just the fact that they were attacking you.

The team was very upset by this feedback as we felt that the game was really starting to take shape. This led to some of the members becoming less and less invested in the project and more distant in the following weeks. The rest of the team however did pull together. We discussed the feedback and made a list of changes for the final build which included setting the game in a fish tank. This helped solve the issue of the buildings seeming out of place because they could be used as ornaments. It also helped to set up an implicit narrative. You are an octopus in a fish tank fighting for survival or dominance – either way it allows the player to create a story in their mind as it’s a much more specific setting for the game. We also decided that we would add damage numbers to the enemies for more visual feedback for the player and we also decided to add in a scoring system which we had previously discounted due to the amount of work it would need but at this stage the programmers had re-evaluated and said that if it was incorporated well it would actually be a simple matter to have a score system which we could then tie in to the upgrades. We also decided to increase the enemy count as that was another issue that the advisors brought up. We were going to add in a tutorial screen, and enemy death animations as it was noted that sometimes it was hard to tell whether the enemies had been killed or had just despawned. We were also going to have to get the AI to start using NAV links as there were places in the level that the player could exploit the enemies because they couldn’t reach them and couldn’t damage them. Finally, we also decided to add in time pools. We were going to add in a mechanic where instead of being timed on how long you can survive you would have a timer counting down and when the timer ended you would die and you would have to explore the map finding these pools of time that would spawn periodically and standing in them to gain time so as not to be killed by the timer reaching 0. This was obviously a lot of work to get done before the next review but the team also knew that we had one week of work after the final review and so were cautiously optimistic that we could get it all done in time.

Weeks 8-10:

These were the final weeks of production work on the project. The team had decided early on in the project that we would work for one week after the final review to make any last minute changes based on feedback received and so we went in to these weeks with the beta milestone from our original plan mostly completed. We had the full gameplay loop with core gameplay mechanics at a reasonable polish, we had our front end working, our endgame states, our AI working, sound and visual effects implemented and at the time of the review no class A or B bugs. We did however fail to get the 3 levels completed; we only managed one, however given that that was the MVP the team was not too disappointed.

Figure 61: Beta Milestone from Project Proposal

As can be seen by my personal production plan I should have been working on balancing and bug testing exclusively throughout these weeks, except for creating the credits UI. However, this was created by the programmer responsible for the main menu early on in development and so should have left me with polishing work. However due to the feedback received at the previous review I had additional work to complete. This included creating a timer and time pools design and blueprinting the feature. I also had to create a tutorials UI design and implement the feature I also created and you main menu background for the game I designed the school system that was to be tied to the upgrade system and adjusted the player camera this left less time for balancing then I had planned for and less time than the game really needed however I still managed to balance the wave system the enemy starts the player starts and the upgrades to a reasonable degree before we locked the build 

Figure 62: Alpha to Final Production Plan from Project Proposal

I created the new menu background by duplicating the playable level into the main menu level setting the view port camera in a nice location and disabling all gameplay functionality I believe that this gives a really nice introduction to the game after the scrolling text intro that was provided by Jacob Crawford for the team. I was inspired by Risk of Rain 2, which has its background for the main menu be an artistic representation of one of the first two levels that can be played. As we didn’t have time to get an artist’s rendition of the level, I decided to create a live background instead.

Figure 4:

When designing the tutorials UI I had an inspiration from a game I played a few years ago: Star Wars: The Old Republic. While this is an online multiplayer game it’s very much designed like a single player RPG, and has an in depth tutorial system to match that the system effectively pops up whenever the player reaches a point where they are interacting with something new for example at the beginning of the game the movement and basic controls tutorial pop up these tutorials consists of a large window in the centre of the screen with three columns each containing a different tutorial which is accompanied by words and images to help explain the feature to the player. The player can then cycle back and forth between tutorial sets using arrows on the left and right hand side of the window and can close the window at any time by pressing the X in the upper right hand corner. This is also effectively how our tutorial works, except I opted to use short video clips instead of images as I felt that better explain to the player how the feature worked and ours also fades in from left to right as soon as the window opens unlike the Star Wars one which you have to manually click to get the next tutorial.

Figure 63: Tutorials Design

Figure 64: BPW_Tutorial(a-d)

When creating the time pools and timer mechanic, the main focus was to give the player a reason to travel around the level and to explore at first we toyed with the idea of having the player have to traverse the level to find currency crates, which they would open and gain currency which they would then use for the operating system. They would have a timer on the level which would countdown to zero at which point the player would die and the only way to increase the time would be to kill enemies which would give you time. However the team didn’t like this idea as some of them pointed out that what a lot of players would figure out to do quickly would be to run around and collect as much currency as possible, and then return to an advantageous point in the level and just farm enemies for time. It would also be extremely hard to balance in the time that we had left with all this in mind what we decided to go with was that the enemies would give currency on kill this would give a reason to kill them beyond just defending yourself and was also much easier to balance than random spawning currency. As for the timer we decided to add pools that would spawn in the level that would give the player time for as long as they stood in them, but these would only last for a certain amount of time before despawning. This would force the player to move to them quickly and stand and defend them while they gained time. This would not only force the player to explore the map in order to get to the time pools but also forced them to stay in those locations and actually fight in different areas of the map.

Figure 68: Time Pools Design

After the design work was completed, I moved on to creating the timer and time pools using blueprints. It was decided that I would do this because the programmers were busy with other work and I had already stated that I could repurpose a lot of the work I had done for the equipment system to get the timer system to work. First, I started by creating the timer, I placed this in the game mode as it was the most obvious place to put it. On event begin play it calls the timer widget to the screen, sets the timer by event which is adjusted for by delta time on event tick this timer calls the event every second.

Figure 69: GameMode_Platform(a)

The function being called then gets the time min and time second variables stored in the game instance and based on what the current values of those variables are the function will deduct one second from the time second variable every second and when this reaches 0 will deduct one from the time min variable unset the time sec variable to 59 thus creating a rudimentary timer. 

Figure 70: GameMode_Platform(b)

if the timer reaches 0 then the function casts to the player and creates a new timer by event this one for the player drowning function which takes the player health and applies damage to them every tick, this tick is determined by the drowned tick variable. Originally when the timer reached zero the player would die and the game would end. However, when testing we found that this felt very unfair especially as there would be times where it would hit zero just before you made it to a time pool. This was very frustrating so by adding a drowning mechanic, whereby the player takes continuous damage and will eventually die if they don’t reach a time pool it feels more forgiving and you still have a chance even when the timer reaches 0. There are still instances where the time will be zero and there is nothing the player can do they will still drown but the timers are balanced so that this is a very rare occurrence.

Figure 71: GameMode_Platform(c)

For the timer widget itself I set a call to the game mode that would check the timer every second to see when it dropped below 25 seconds at which point the text that displayed the time remaining would start to flash between red and white and grow larger and smaller.

Figure 72: BPW_Timer(a)

Figure 73: BPW_Timer(b)

For the spawning of the time pools I used a similar method to that which I had done to create the equipment prototype, where blank actors were placed across the level to denote spawning points and the spawner would choose these at random and spawn pools there at a given frequency, again like with the equipment system were I to make a system like this in the future I would have the locations built into the spawner rather than having to use separate actors.

Figure 74: BP_TimePool(a)

It was brought to my attention early on in my work on the time polls that they were hard to see in the level, as originally they were just a pulsing orange circle, as such I decided to add more visual and sound effects to them to make it more obvious when they had spawned and where they had spawned.

Figure 75: BP_TimePool(b)

As part of this I set it up so that on creation the time pools would set a life span so that they would automatically despawn after a certain time. This would create a sense of urgency for the player as they would have a limited amount of time to go and collect the resources to stop themselves from drowning.

Figure 76: BP_TimePool(c)

When setting this life span I would also set a delay which would be used to turn off the visual effect for the geyser and then turn it back on 10 seconds before the end of the pools life span to give the player a warning that they were nearly out of time if they wanted to get to the pool. This would also play a sound effect in both instances to signify to the player that the pool had spawned or was about to despawn.

Figure 77: BP_TimePool(d)

To further increase the likelihood of the player noticing that pools have spawned and how long the pools have left I also made it so that the when the pools were active the timer text would be green, assuming it was above 25 seconds, and that when the timer pools had less than 10 seconds left on their life span the timer would turn orange to warn the player that they didn’t have long left. If the pools despawned or the player collected all of them then the timer would return to white.

Figure 78: BP_TimePool(e)

Once the player was standing inside one of the circles we didn’t want them to despawn, this is how they worked in one of their early iterations and the team felt it was unfair that they had managed to make it to the pool but only gained one or two seconds from it before it despawned. Therefore when the player enters the pool area the life span is increased by the amount of time the pool has left to give ensuring that they will never despawn before they’ve given all their time if the player is standing in them.

Figure 79: BP_TimePool(f)

While the player is standing inside the pool a sound effect loops to help signify to the player they are standing in the pool, and to help teach them that if they hear that sound they are gaining time, and if they believe they are in the pool but they don’t hear that sound either the pool has despawned or they have stepped out of the pool unknowingly. This was done to help with the fact that sometimes the circle denoting the pools radius can get lost on the ground.

Figure 80: BP_TimePool(g)

Time is added to the player by casting to the game mode and altering the time variables by increasing them by a value every tick which is determined by a variable inside the time pools themselves.

Figure 81: BP_TimePool(h)

If the player exits the sphere before the time pool has finished the life span is reset to the value it was at before the player entered it, unless that value would be less than two in which case it is set to two this is to add a form of coyote time to the pools in case the player accidentally steps out for a second and there was only 0.1 seconds left on the life span. We didn’t want the player to feel punished if they managed to make it back in straight away just because they stepped out for a brief moment.

Figure 82: BP_TimePool(i)

Figure 83: Time Pool in Game

With the timer pools design and creation along with the tutorials and score system being complete, I moved on to balancing. This consisted of balancing the number of enemies that would spawn and be on screen at any given time alongside the individual power of each enemy and how that played out when in large numbers, as well as balancing upgrades – both when the player would receive them and the values for the upgrades themselves. I also balanced the player’s abilities: their speed jump height, dash distance, weapon damage, etc. This led to a lot of playtesting which I was thankful to be able to get a number of team members involved with, though the participation waned as the weeks went on.

Figure 84/5: Enemy Spawner Variables

Here we can see the settings that I balanced for the enemy spawner. The system worked by spawning basic and elite enemies at different distances from the player. The elite distance is added on to the basic distance for the starting values. I left them low to allow new players a chance to get oriented in the world and get used to the timer mechanic and features that they would be interacting with before really having to be challenged by the enemies. I then balanced around the multiplier for how many enemies would exist in the next round, along with balancing the difficulty value: when the difficulty would increase and by how much. At first, I had these values very high as we were told the game needs to be more chaotic and we needed more enemies on screen, and while it was entertaining it went from being slow and easy to manage in the first wave, to hectic, fun and chaotic in waves three and four to completely overwhelming and very heavy performance hit on waves five onwards. As such I toned down the increases and instead had everything increase by a little bit so that multiplicatively the number of enemies would ramp up but at a steadier, more predictable pace. I also asked for there to be a cap placed on the number of enemies that can spawn at any one time. This feature was added, and I balanced these numbers around what I found fun to play as a player and what was optimal for the game in terms of performance.

Figure 86: Crit chance upgrade variables

I also balanced the upgrades. An example is shown of the crit chance upgrade. I would balance how powerful one instance of the grade was next to each consecutive upgrade, ensuring that they felt meaningful but did not become too powerful too quickly. This was then balanced against the score required to get the upgrade and the amount of score players would receive roughly between each upgrade. These were also balanced against each other. Through testing I was able to discover which of the upgrades were more powerful than the others and adjusted their score accordingly.

Figure 87: Tank Attack Variables

I also had to balance the individual enemies’ combat abilities. Here we can see a sample of the tank stats, primarily focusing around its attacks. These had to be balanced against the player’s defences, how many there would likely be engaged with the player at one time along with how fast the enemy was, through testing I found specifically for the tank it felt better to fight when you were punished for staying still or getting too close to it for too long but were only minorly inconvenienced if you kept moving. As such I set the melee attack damage to be fairly high to discourage players from getting too close and I set the damage per second value for the ranged attack to be quite high but the individual tick damage is quite low, this means if the beam only makes contact with the player for a very short duration they receive very little damage however if they don’t move out of the way quickly the damage rapidly ramps up.

Figure 88: Tank Score Variable

I also had to balance the score value for each of the enemies, given how difficult they were to defeat, how numerous they were, how many there would likely be between each upgrade and how much each upgrade cost. This was one of the more difficult balancing acts as there were times when, especially in the first few minutes of the game where you’re receiving your first upgrade, where you might potentially not be able to afford any of the upgrades because the enemies that spawned were worth less and you got high priced upgrades. I tried to balance this by knowing how many tanks roughly there would be between each upgrade and giving the tank the highest score by a fair amount, this ensured that at the very least they should be able to afford one of the upgrades. This is also the reason why the upgrade window can be closed so the player can save their points for another upgrade chance.

As stated before in my proposal I had expected to be focusing mainly on balancing and polishing the game during these weeks but in reality I spent much of my time designing the final features and implementing them into the game. This meant that balancing didn’t get the attention I believe it needed and while I am fairly happy with the state of the game as of now, I believe that if I had had these weeks to focus purely on balancing the game would have been more fun and the combat would have been tighter, improving the overall experience for the player. That being said I did enjoy the design and technical work that I got to do in this week; after the disappointment of having my equipment prototype scrapped getting to produce something that actually made it into the final game was very enjoyable for me and really lifted my spirits which helped towards my productivity for these last three weeks.

This all being said, ideally I would not allow this to happen normally at this time the feature should be locked down and we should only be bug fixing and polishing and this is something I intend to be more rigid with in the future if the game is lacking stuff then we should solve the problems with what we already have rather than inventing new tools with so little time left.

During these three weeks the team managed to get the main menu background implemented, intra scroll text before the main menu, tutorials, UI art, HUD art, the timer and time pools mechanics, the tank model, the fish tank, the room, the coral, the bubbles, the fish VFX, the eel model, the eel hazard, the death box, the score system, upgrades, camera adjustment, underwater post processing effect, floating damage text, enemy animations and nav link fix and the wave and enemy balancing done.

With this the team was very happy with the work we were able to do in these weeks. We had managed to make a lot of changes and additions to the game in a short amount of time and we were very happy with the finished product.

At the review the feedback was mostly positive. We were praised for the menus, the time dilation, the fish tank aesthetic, the post processing effect, and the bubble VFX. We were told that the music sounded more Egyptian than Greek and at the time we needed to be a bit stricter, along with the camera being a little bit low and acting strangely when near the floor and at the time of the review the room still needed to be finished.

The team was very happy with this feedback as a whole; we felt vindicated for all our hard work even if it was only just at the end of the project. We spent the last week making the final adjustments fixing the camera angle by pulling it up a bit and adjusting the boom so that when it came in contact with the ground it would act a bit better and show more of the player and be better orientated. We finished the room outside of the tank along with a few minor changes to inside of the tank just to make it more aesthetically pleasing. The timer was rebalanced to be a bit stricter and we got some new music in which we believe sounds closer to a Greek aesthetic than an Egyptian.

Product Review:

We achieved a quirky, fun, weird little game that surpassed our MVP in many ways. The team started out with a lot of promise but with an abundance of communication and attendance issues, the project suffered at many stages. Despite this working with them was rewarding, I learnt a lot about how to handle difficult situations, how not to handle being overburdened with work, the importance of clear communication and the negative impacts a lack thereof can have on development and people’s investment in a project.

The team really struggled when we lost our producer, and this has given me a newfound respect and understanding for just how crucially important the role is.

We set out to create one fully polished arena with art fully implemented, a gameplay focused on shooting, one enemy with a wave system, one character ability and working sound and music. We ended up creating that one fully polished arena, gameplay focused around shooting, and a time collection loop. We managed to get four enemies created, three of which made it into the final build, three character abilities and working sound and music for almost all assets. While this does fall shy of our intended target I feel that given the complications that arose during development and the fact that the target was very optimistic to begin with the team did an amazing job at packing the amount of features into the game that we did.

All this being said I feel I was able to have a positive working relationship with most of the team throughout this module and that I was able to fulfil my role as gameplay and UI designer to a high standard and work well with the rest of the team to create a solid game which while not ready for publishing would act as a solid foundation to develop upon in the future to create a fully realised complete game.

Conclusion:

During the project, I was able to create a solid design process which worked really well and meant that the team got designs quickly and with concise useful information, meaning vision was adhered to well.

The process is solid and sticking to it is important; times when it was rushed or skipped produced lesser quality features. I will not skip in future, and to help with this I will find a way to manage my time better so corners do not need to be cut.

During the project I created good well-researched designs; the designs themselves had a good research base. This led to designs working well together and complimenting each other, creating a better gaming experience.

I realised just how important research is. The last two modules I produced much better designs than the first due to conducting more in-depth research; I will continue to refine my method of research to keep effectiveness high while decreasing time taken.

I did multiple instances of technical work throughout the project, creating two prototypes and one full feature from scratch. My technical work was of good quality, which helped take pressure off the programming team that had a large workload. It also allowed for prototyping of potential features without taking time away from core features already in development.

I would like to continue developing technical skills; I believe I can use them to create quick prototypes for programmers to work from to give better understanding of how features should work.

Time management was an issue for me throughout the project as post pivot I had much more work to do and responsibilities kept adding up. This caused a decrease in the overall quality of my work and increased stress for me which affected home and work life and thus my communication and leadership abilities, which created a negative attitude that affected the team.

In the future I will make the team aware of the amount of work and stress it is causing and try to have the workload shared by others to free up more time to produce better quality work; I will also ensure I make good use of time off to destress and recover.

Lack of non-game research meant that I was unable to advance as much in my overall team collaboration effectiveness; this may have contributed to some of the communication breakdown that occurred.

I intend to find time to do this research, by doing the aforementioned load sharing, free time can then be used to research other development aspects.

Documentation quality declined as the project went on and more and more tasks were assigned to me. This did not bother the team much as they mostly used the asset and technical requirements list, which saw no noticeable drop in quality. But it did affect the quality of my research and synthesis work which informed these lists and my own sense of worth on the team, which negatively impacted my mental health and thus bled over to the team.

By resolving the time management and workload issues stated previously I believe that this issue can be avoided in the future as it is mostly caused by my inability to properly solve these other issues.

“My goal throughout this project and in relation to these roles and responsibilities is to research and create well thought out meaningful designs for gameplay mechanics and systems, building upon my current knowledge base, that can be used by the rest of the team to create a fun game experience and through this process to gain a greater understanding of design methodologies and philosophies, and to improve my ability to work collegially with colleagues to design and create better games.”

I believe I achieved my goal for this project. I carried out quality research into relevant games, increasing the amount of research I can get done in a given time and analysing games with a keener understanding of what makes features work well, and used what I learned to create meaningful designs for the game that used and expanded upon my previous experiences as a designer. These designs were then used by the team to successfully create a working fun game. While there were struggles within the team throughout the project, I believe these experiences have taught me much about how best to act and collaborate within a team to be the most effective colleague I can be, by staying positive, sharing concerns and admitting when I am struggling and ensuring that everyone feels safe and valued as part of the team.

This module turned out nothing like I expected; while I had experienced difficulties in previous modules this was by far the most challenging both on my abilities as a designer and on my mental health. I did not expect my final module to involve a complete pivot in game genre and scope 20% of the way through. I also was not expecting to have to take on production and team leading responsibilities while still juggling design work. But I have to say despite the stress created by all this I think it has been an extremely valuable and character building experience, I learned just how important the role of producer is to the smooth running of a team, how a strong design process can really enhance the quality of work and also that if it isn’t followed correctly its worth is greatly diminished. In addition, I have learned that clear, open and honest communication is by far the greatest asset a team can have; the team we put together was excellent but due to poor communication our work suffered. Through all of this I believe that I adapted well to the unknown and new experiences and learned a lot about time management, the design process and myself. My biggest take away from this project will be to take a positive attitude, active encouragement for my team and a newfound respect for design processes and sticking to them into my future career.

Bibliography:

Hopoo Games, 2019. Risk of Rain 2. [Game]. PC. Gearbox Publishing.

Supergiant Games, 2020. Hades. [Game]. PC. Supergiant Games.

Alexandra, H., 2019. Games Are Better With Double Jumps. [online] Kotaku. Available at: <https://kotaku.com/games-are-better-with-double-jumps-1835910803&gt; [Accessed 22 June 2021].

Room, R., 2018. Is it time to retire the double jump gameplay mechanic?. [online] Steemit.com. Available at: <https://steemit.com/gaming/@retro-room/is-it-time-to-retire-the-double-jump-gameplay-mechanic&gt; [Accessed 22 June 2021].

Insomniac Games, 2021. Ratchet & Clank: Rift Apart. [Game]. PC. Sony Interactive Entertainment.

BioWare, 2011. Star Wars: The Old Republic. [Game]. PC. Electronic Arts.

Pears, M., 2016. Setting the Tone: Main Menus are the Game. [Blog] Gamasutra, Available at: <https://gamasutra.com/blogs/MaxPears/20160421/270579/Setting_the_Tone_Main_Menus_are_the_Game.php&gt; [Accessed 12 July 2021].

Stanway, G., 2016. A Tale of Two Games: UI and Menu Evolution in Tiny Titan’s Titles. [Blog] Gamasutra, Available at: <https://www.gamasutra.com/blogs/GlennStanway/20160930/280293/A_Tale_of_Two_Games_UI_and_Menu_Evolution_in_Tiny_Titans_Titles.php&gt; [Accessed 12 July 2021].

Tokmakchiev, A., 2020. Deep Dive: Evolving the UX/UI of A Total War Saga: Troy using player feedback. [online] Gamasutra.com. Available at: <https://www.gamasutra.com/view/news/373860/Deep_Dive_Evolving_the_UXUI_of_A_Total_War_Saga_Troy_using_player_feedback.php&gt; [Accessed 12 July 2021].

Lovato, N., 2017. 5 Tips to Improve Your Game’s User Experience – GameAnalytics. [online] GameAnalytics. Available at: <https://gameanalytics.com/blog/5-tips-to-improve-your-games-user-experience/&gt; [Accessed 12 July 2021].

Cummings, A., n.d. The Evolution of Game Controllers and Control Schemesand their Effect on their games. Undergraduate. University of Southampton.

Bycer, J., 2016. 5 Tips for Designing Control Schemes – Game Wisdom. [online] Game Wisdom. Available at: <https://game-wisdom.com/critical/5-tips-for-control-schemes&gt; [Accessed 12 July 2021].

Dotsenko, A., 2017. Designing Game Controls. [online] Gamasutra.com. Available at: <https://www.gamasutra.com/blogs/AndrewDotsenko/20170329/294676/Designing_Game_Controls.php&gt; [Accessed 12 July 2021].

Rockstar Games, 2018. Red Dead Redemption 2. [Game]. PC. Rockstar Games.

Rockstar Studios, 2012. Max Payne 3. [Game]. PC. Rockstar Games.

Remedy Entertainment, 2016. Quantum Break. [Game]. PC. Xbox Game Studios.

BioWare, 2017. Mass Effect: Andromeda. [Game]. PC. Electronic Arts.

Hopeful Homies. 2017. Movement Mechanics – The First Building Block of Gaming. [online] Available at: <https://hopefulhomies.com/2017/02/18/movement-mechanics/&gt; [Accessed 21 June 2021].

Landfall Games, 2016. Clustertruck. [Game]. PC. TinyBuild.

One More Level, 2020. Ghostrunner. [Game]. PC. 505 Games.

Stout, M., 2015. Enemy Attacks and Telegraphing. [online] Gamasutra.com. Available at: <https://www.gamasutra.com/blogs/MikeStout/20150902/252736/Enemy_Attacks_and_Telegraphing.php&gt; [Accessed 6 July 2021].

Insomniac Games, 2018. Spider-Man (2018). [Game]. PC. Sony Interactive Entertainment.

Bradley, A., 2017. 6 examples of UI design that every game developer should study. [online] Gamasutra.com. Available at: <https://www.gamasutra.com/view/news/289637/6_examples_of_UI_design_that_every_game_developer_should_study.php&gt; [Accessed 9 July 2021].

Dakinedi, A., 2018. Top 5 Best Video Game UIs. [online] Medium. Available at: <https://medium.com/super-jump/top-5-best-video-game-uis-db941d6a9357&gt; [Accessed 9 July 2021].

Savage and Greene. 2021. The Post-it Method Step-by-Step | Savage and Greene. [online] Available at: <https://www.savageandgreene.com/post-it-method/&gt; [Accessed 21 June 2021].

Accessiblegamedesign.com. n.d. Head-Up Display (HUD) Guidelines – Accessible Game Design. [online] Available at: <http://accessiblegamedesign.com/guidelines/HUD.html&gt; [Accessed 8 February 2021].

Pluralsight.com. 2014. HUD Design That Works for Your Game. [online] Available at: <https://www.pluralsight.com/blog/film-games/designing-a-hud-that-works-for-your-game&gt; [Accessed 9 July 2021].

Janoschek, O., 2016. Key user experience insights gained during the creation of Dreadnought’s combat HUD. [online] Gamasutra.com. Available at: <https://www.gamasutra.com/blogs/OliverJanoschek/20160714/277048/Key_user_experience_insights_gained_during_the_creation_of_Dreadnoughts_combat_HUD.php&gt; [Accessed 9 July 2021].

Loomis, M., 2015. HUD Design: A Good HUD Is Hard To Find. [online] Game Rant. Available at: <https://gamerant.com/good-hud-design-229/&gt; [Accessed 9 July 2021].

Quintans, D., 2013. Game UI by Example: A Crash Course in the Good and the Bad. [online] Game Development Envato Tuts+. Available at: <https://gamedevelopment.tutsplus.com/tutorials/game-ui-by-example-a-crash-course-in-the-good-and-the-bad–gamedev-3943&gt; [Accessed 9 July 2021].

Medium. 2017. THE ONLY ADVICE YOU WILL NEED TO MAKE A GREAT GAME UI/UX. [online] Available at: <https://medium.com/ironequal/the-only-advice-you-will-need-to-make-a-great-game-ui-ux-74a0db8de642&gt; [Accessed 9 July 2021].

Tilford, B., 2016. Perceiving without looking: Designing HUDs for peripheral vision. [online] Gamasutra.com. Available at: <https://gamasutra.com/blogs/BobTilford/20160329/268648/Perceiving_without_looking_Designing_HUDs_for_peripheral_vision.php&gt; [Accessed 9 July 2021].

Gone North Games, 2014. A Story About My Uncle. [Game]. PC. Coffee Stain Publishing.

Cohn, M., 2013. Succeeding With Agile . Upper Saddle River, NJ [etc.]: Addison-Wesley.

Respawn Entertainment, 2019, Apex Legends. [Game]. PC. Electronic Arts.

games, P., 2020. Press A to jump: mobility in video games – Parallel Worlds. [online] Parallel Worlds. Available at: <https://www.parallelworlds.uk/2020/08/press-a-to-jump-mobility-in-video-games/&gt; [Accessed 23 June 2021].

Atkins, S. and Murphy, K., 1993. Reflection: a review of the literature. Journal of advanced nursing, 18(8), pp.1188-1192.

Muslihat, D., 2018. Agile Methodology: An Overview | Zenkit. [online] Zenkit. Available at: <https://zenkit.com/en/blog/agile-methodology-an-overview/&gt; [Accessed 28 August 2021].

Driscoll, J. (2011). Meeting Your Potential Through Reflection. [online] John Driscoll Consulting. Available at: http://www.supervisionandcoaching.com/ [Accessed 28 August 2021].

Doan, D., 2017. GameDev Protips: How To Kick Scope Creep In The Ass And Ship Your Indie Game. [online] Medium. Available at: <https://medium.com/@doandaniel/gamedev-protips-how-to-kick-scope-creep-in-the-ass-and-ship-your-indie-game-8fa3051500d1&gt; [Accessed 4 July 2021].

Lino, C., 2020. The Psychology of Teamwork: The 7 Habits of Highly Effective Teams. [online] PositivePsychology.com. Available at: <https://positivepsychology.com/psychology-teamwork/&gt; [Accessed 21 August 2021].

Ludema, J. and Johnson, A., 2019. Silence Is Costly: 4 Types Of Team Members Who Keep Quiet, And How To Get Their Voices Heard. [online] Forbes. Available at: <https://www.forbes.com/sites/amberjohnson-jimludema/2019/07/23/silence-is-costly-4-types-of-team-members-who-keep-quiet-and-how-to-get-their-voices-heard/?sh=54369fec21ae&gt; [Accessed 29 July 2021].

Marsh, E., 2019. How peer feedback helps build better teams. [online] T-three.com. Available at: <https://www.t-three.com/soak/insights/how-peer-feedback-helps-build-better-teams&gt; [Accessed 21 July 2021].

Moore, C., 2021. What Is The Negativity Bias and How Can it be Overcome?. [online] PositivePsychology.com. Available at: <https://positivepsychology.com/3-steps-negativity-bias/&gt; [Accessed 2 August 2021].

Blog.fogus.me. 2015. fogus: The 100:10:1 method: my approach to open source. [online] Available at: <http://blog.fogus.me/2015/11/04/the-100101-method-my-approach-to-open-source/&gt; [Accessed 24 June 2021].