Shootformer Continued: My GAM705 Major Project

mattbaileygamedesi
Aug 21, 2022
28 min read

Introduction

This blog post is here to allow me to document my iterative process and critical thinking throughout the final major project module of my game design masters course, GAM705. After explaining what the project is and some key details, I will be documenting my process and critical thinking in chronological order.

Project Specifics

For this project I will be expanding upon Shootformer, the experimental prototype game that I created for the experimental game design module. This is because I am undertaking this project by myself and having a prototype ready to build from drastically reduces my scope.

Here is my elevator pitch for the game to remind you what the game is all about:

Shootformer is an experimental game that merges the 2D Platformer and the FPS into one game! Use perspective swapping to change between 2D and 3D modes to access all parts of the levels, collect coins, kill enemies and solve puzzles!

Here is a gif that shows how the perspective swapping can be used to traverse the levels:

For more information on how the perspective swapping mechanic works, please read my previous post - Shootformer - An Experimental Game Development Log.

This will be a digital game for PC and it will be playable with a mouse and keyboard.

It will feature three levels; a tutorial level (the level already created within the prototype), a forest based level with more open space and a craggy level with many narrow tunnels.

This is so that I can properly experiment with how the gameplay from both genres merge with different styles of level design and different spaces in order to fulfil my main research question which is "How can FPS and Platforming genres be merged?".

I will have a heavy focus on playtesting and iteration during this project to refine the levels and mechanics to a publishable quality. I will be doing this by holding in person playtests where I will take notes of how the players play the game as well as online playtests. I will have playtesters fill out forms to determine whether the game needs improvements and if it has successfully answered my research question. I will be using some free and paid assets from the Unity Asset Store in order to create the game before the deadline and to reduce scope. After all, in a professional setting as a systems designer or level designer I would be working with assets produced by others in my team and building the game in engine using these.

The aims of this project are to:

Create a cohesive and playable experience that is potentially marketable.
Experiment with level design - How can I innovate with my level design to accommodate both the FPS and 2D Platformer Genres?
Push my design skills to create a great portfolio piece that shows off my game design skills within Unity.
Create a casual gameplay experience that is interesting and fun.

My stretch goals for the project are as follows:

Mobile Release
Published on Steam
Controller Support

In order to stay on track when making design decisions I have created some design pillars to adhere to.

These are as follows:

Perspective Swapping
1. Everything hinges on how the mechanics play around the perspective swap.

Innovative Level Design
1. Every level should be conducive to both playstyles - FPS and 2D Platforming.

Exciting Combat
1. AI should behave differently depending on the perspective and should provide a challenge.

Interesting Visuals
1. The game should be visually interesting with plenty of “juice” to keep the player interested.

I will be creating this game over five two week sprints using agile methodology.

Here is my sprint plan for the project that features the main goals of each sprint with a time scale for each and concise bullet points:

Sprint 1 - Planning (13/06/22 - 24/06/22)

Trello Board Set Up
Sprint Plan Complete
Version Control Set Up
Proposal Presentation Finished
UI Designs Complete
- Flowchart
- Sketches
AI Behaviours Designed
Design Document Finished

Sprint 2 - Pre Production (27/06/22 - 08/07/22)

Level Blockouts Complete
- Level 2
- Level 3
Player Mechanics Tested and Iterated On
AI Tested and Iterated On
Blocked Out Levels Playtested and Iterated On
Game Feature Complete
Source Free Art Assets
Build 1 Complete

Sprint 3 - Production 1 (11/07/22 - 22/07/22)

Iterate on Levels
Iterate on Player Mechanics
AI Implemented in All Levels
All Level Functionality Implemented
Menus and UI Fully Implemented
Implementation of Some Free Art Assets
Lighting Pass 1
Build 2 Complete

Sprint 4 - Production 2 (25/07/22 - 05/08/22)

Continue Implementing Free Art Assets
Ensure Camera Swap is Working Well Across Both Levels
Ensure AI is Working As Intended - Seek Free Assets or AI Expert Help
Build 3 Complete

Sprint 5 - Post Production (08/08/22 - 23/08/22)

Final Presentation Complete
Itch.io Page
Lighting Final Pass
Bug Testing
Bug Fixing
Game Fully Polished
Final Build Complete

Without further ado I will get into documenting my process, starting with Planning and Pre-Production.

Planning and Pre-Production

Planning has gone very well so far. I have been spending most of my time in this section of the project creating documentation such as a GDD to adhere to when making design decisions, flow charts for AI and UI, creating the sprint plan and sorting the projects Trello board and version control. After this, I now have a solid base for the project and I can start working on it.

I feel that I have planned the project effectively and that the scope is low enough that the game will be achievable to create. The documentation that I have created will support me throughout the project.

Pre-Production has also gone very well.

Gathering Art Assets

Firstly I have sourced many free art assets from the Unity Asset Store to use throughout the project. I will reference these fully at the end of this document and in the credits of the game.

Level 2 Blockout

Next I created the blockout for level 2 of the game. This area is to be forest themed and feature some larger open spaces to allow me to experiment with the perspective mechanic in a more visually interesting and open space.

Here is a screenshot of the level so far:

This level contains three more open spaces that accommodate both FPS gameplay and 2D platforming. They provide lots of cover for the player to use when fighting enemies in these areas they feature locked door puzzles with targets to shoot as well as perspective jumping puzzles that allow them to collect coins, gain the high ground on enemies and progress through the level. There will be more cover in these areas when I implement some of the free tree and rock assets that I have sourced from the asset store.

Here is an example of a locked door/target puzzle within the level:

The player must shoot all of the red targets in order to unlock the door and progress to the goal. They may also use the perspective swapping mechanic to complete jump a jump puzzle to reach higher ground to gain an advantage over the enemies that will be in this area.

For the major project I have decided to utilize a more organic method of prototyping levels that I discovered works well for me and my process in previous modules.

Instead of planning out my levels using paper or digital level designs I am creating my levels by going straight into engine with a blockout tool (ProBuilder) and seeing what inspiration comes to mind, making new areas of the level spontaneously. I feel that this allows me to be more creative with my level designs and that it creates a more organic level that flows well, as I playtest the level with the player controller after the addition of every new section.

This helps me to see exactly how the player controller interacts with the level as I go, which means I don't need to keep designing and redesigning the level on paper which saves a lot of time.

The blockout is complete and I have tweaked and iterated upon it to ensure that the player can navigate it effectively, eg. the jump puzzles are completable and the perspective swap works with the cube assets well.

Player Controller Iterations

Next I performed some iterations on the player controller. I found that when roaming a big open space, the player needs to access the perspective mechanic on more than just "0" on the Z axis. In the previous level, whenever the player switches into 2D platforming mode, they are reset to "0" on the Z axis in order to be lined up with the perspective objects in the level that allows them to traverse gaps and solve jumping puzzles. To work around this, I implemented some code that detects whether the player is in the second level. If they are then the player will not be reset to "0" on the Z axis when in 2D mode, allowing them to line themselves up with perspective puzzles anywhere in the level, as the level requires this.

Here is a screenshot illustrating what I mean:

Level 3 Blockout

The level 3 blockout went very smoothly. I used the same spontaneous and organic technique of going straight in with ProBuilder so I could change my design and how it flows into itself on the fly, so it didn't take as much time as predicted. It is a fairly linear level but with some areas where the player must explore and go off the beaten path to complete puzzles or gain a collectable coin.

This level aesthetically is going to be quite craggy and rocky featuring underground tunnels. Because of this there are many tight spaces which will promote the player's use of choke points during FPS gameplay, allowing them to strategize more. This should lead to more meaningful and challenging combat encounters.

Here is an aerial view and a side view of the level in its current blockout state:

As you can see, the level features many sprawling tunnels for the player to investigate. These tunnels are going to be full of enemies so the player is going to have to conserve their health and make use of cover where possible, as well as strategize using chokepoints as mentioned earlier.

A particular challenge when creating the level was figuring out how the player can be seen from the 2D perspective when inside these tunnels. If the player cannot see inside the tunnels when in 2D mode, they may become frustrated as they would not be able to accurately control the player or see enemies up ahead.

The solution to this was relatively simple. I made the faces of the geometry facing into the tunnel solid and removed their back faces, meaning that the player cannot see out of them when in FPS mode but can still see into them in 2D mode. Here are a couple of images that explain this visually:

Background Music

I commissioned a friend who is a musician and producer to create a piece of music for the game to serve as background music. He got back to me with the finished piece sooner than expected. It is an upbeat/inspiring melody created using 16 bit instrumentation to fit with the games casual feel. It also evokes feelings of nostalgia so it should help the game to appeal to an older audience.

I had to get back to the musician as the track did not loop seamlessly when it was first sent, but this issue is now fixed and it is implemented in the game.

Blockout Playtesting and Level Functionality

Next I added all of the level functionality to the two new levels. I added the deathbox to kill the player when they fall out of the level, the pause menu and the collectable coins to each. After doing this I playtested both levels again to ensure everything was working properly. I repositioned some targets that could be shot from an unintended position, some moving cubes that weren't quite aligned properly and added some small tweaks to the level geometry where I found that the player could fall off the map or see too much of the level ahead from first person mode.

At this point in the project I am experiencing a bit of an issue with the moving blocks. The player doesn't seem to stick to the blocks as they are moving and must constantly adjust their position when on top of one. I am attempting to find a solution through C# but so far the problem remains. I am going to be seeking some assistance from colleagues and lecturers in the next couple of days to solve the problem.

At this point in the project both new levels are fully functional and playable. The next step is to get AI into the levels so that I can playtest them with enemies as they will form an integral part of gameplay and really affect how the player navigates the levels. I am currently waiting on the university to get back to me regarding an AI asset pack that will make development of the AI far quicker and easier on project scope. Whilst I am waiting for this to be confirmed I will start to populate the levels with art assets.

I have gathered many free art assets from the Unity asset store in order to reduce project scope and development time. At this point in development I have gathered enough to move into the production phase of development, especially as every feature to be present in the game is now implemented in some shape or form. I must now move on into production, iterating and playtesting as I go.

Production

Art Implementation

For the purposes of art implementation I am using a plugin called 'Prefab Brush' by Archie Andrews. It is a tool that allows me to place prefab art assets in a more organic and simple way, as it allows me to add an element of randomness to the rotation, scale and angle of prefabs when they are placed, making the environment look more natural to the player. It also allows me to implement grass much faster as I can simply paint it over the level geometry as if I was using the terrain function.

Prefab Brush - Grass Brush Example

Moving Cubes Fix

Whilst waiting for the AI package to be approved by the university I found a work around for the glitch with the moving cubes. The issue was that the player would not move with the cube, despite my code that parents the player game object to the cube that it is on. This resulted in them being rather difficult to stay on as the player had to move themselves along with the cube.

Instead of parenting the player to the cube, the cube now detects whether the player is on top of it using a trigger, it then gets the cube's position in the last frame and moves the player's character controller to that position. This allows the player to stay steadily on top of the cube. This is within the Update function, so it happens every frame that the player is in contact with the moving cube.

Here is the code that allows this to happen:

This is a great relief as this issue has been plaguing the game's development from the prototyping stage.

AI Package Implementation

Shortly after solving the moving cube issue, I received the Unity package from the university containing the AI that I needed to add more compelling and smarter enemies to the game.

These enemies are complete with NPC models, weapon models, animations, blood splatter particle effects, smart state machine, location damage and sound effects.

This has helped me to add some much needed "juice" to the game as the visual and sound effects that come with the package help the game to feel more alive and this helps me to achieve my design pillar of "Interesting Visuals". The locational damage and their smarter behaviour helps the combat to feel more exciting and it adds more strategy as they take cover. If the player is accurate enough these enemies can be killed instantly with a headshot, making the skill ceiling slightly higher, contributing towards a more satisfying experience.

The package was slightly challenging to implement as I had to figure out how to make the player's weapon and controller give and receive damage to and from the enemy AI. After some sifting through the AI code I found that I simply needed to reference my scripts in the AI scripts so that they could receive the information from the player scripts.

Here is what the enemies look like in-game:

They fit in with the game's simple low-poly visuals and are coloured red, which shows the player that they are dangerous.

After implementing them in the second level, I playtested the level and made some tweaks to the enemy and player damage. I also added a player health regeneration timer along with some red damage effects to be overlaid on the screen when the player is taking damage. The red border gets larger the more damage that the player takes and gradually disappears as they regain health. This adds some more "juice" to the game and it helps the player to gauge how much health they have left without an intrusive health bar UI element.

Here are some images showing the damage overlay in action:

The player will begin to regenerate health when they have not received damage for five seconds. They will recover health at roughly 10 units per second up to 100 maximum health.

After playtesting this thoroughly I have found that this makes the combat challenging, but not impossible, contributing to my "Exciting Combat" design pillar.

Of course I will gather some playtesting data from a group of external playtesters to confirm this when I have a more up to date playtesting build available.

After testing the AI in Level 2, I am satisfied with how they are working and I will now implement them in levels 1 and 3.

Level 2 Art and Lighting Pass

After implementing the UI in all of the levels I began to add more art assets to Level 2. I added textures, added a better skybox and built lighting for the level. It is now at a point where I am satisfied with how the level looks. I may add some particle effects to make it more visually interesting to the player, but for now it looks far more polished. Here's a screenshot showing how the level looks now.

The level now has more of a fantasy forest clearing feel, and I feel that it contributes to my "interesting visuals" design pillar.

The levels art assets are mostly static so that the lighting can be baked without rendering too many real time shadows, saving on extra calculations and making the game more optimised. This may assist me in reaching my stretch goal to port the game to mobile. In order to optimise the game further I will eventually have the game only render in assets if the player is looking at them.

Project Goals Re-Considerations

After the amount of time it took to get this one level looking like this I have had to reconsider some of my projects goals. I no longer think that the game will be at a marketable stage by the end of the project. This is mainly because I doubt that I will be able to create and animate a better looking player character by the deadline, there are too many other more important considerations that I need to prioritize such as the gameplay and amount of visual and audio "juice" across the levels. Because of this, my new project goal is to have a more polished vertical slice or "demo" that I could upload for free on itch.io. This could then be used to market a kickstarter campaign to further develop the game. It will essentially be a more polished proof of concept upon completion which should convey the core mechanics of the game and deliver a gameplay experience that shows the player what the game could end up being if given more time.

Level 1 Platforming Changes and Coin Changes

Up to this point in the project, the player has been able to shoot coins in order to collect them. However, in the more recent levels of the game I have placed more of an emphasis on platforming to collect coins. This is because I received some feedback from a lecturer stating that the game, in parts, feels more like an FPS with some 2D platforming features rather than a marriage of the two and suggested that shooting the coins brings too much of the FPS mechanics into the 2D platforming aspect of the game. I am inclined to agree with this statement, as after all, the collectable coins are typical of the 2D platforming games that inspire that side of the game.

Because of this I decided to remove the player's ability to shoot coins to collect them, and replaced these puzzles with jumping puzzles instead, so that the player has to engage in platforming gameplay to collect them.

If you read my previous post, Shootformer - An Experimental Game Development Log, you will see these puzzles as they were.

Here some images of the changes I've made to the first level to accommodate the change in game mechanics:

A perspective jump cube puzzle to reach the second coin.

A moving platform jumping puzzle over a hazard to collect the third coin.

Level 1 and 3 Art Implementation

After making the changes to the coin jump puzzles, I had enough free assets gathered to start populating levels 1 and 3 with art assets so that they better reflect my design pillar of "Interesting Visuals".

Level 1 has an abstract "sci-fi" theme to it. I used low poly space rock assets, a blue skybox and blue lighting to achieve this. It has a very simple look to reflect the level's simple nature as it is the introductory level to the game and it features less complex geometry and puzzles to reflect this.

The large rocks look like they are from an alternate dimension and spin on the spot as they float around the level to provide some more interesting visuals and juice for the player to look at. The lighting has been fully built with global illumination to give it a lovely stylized look.

Here is what it looks like now:

Level 3 has a craggy canyon sort of feel. I found some really useful free rocky ground textures and cliff face textures with great normal maps that make the environment pop out a bit more. I also added some low poly "lava plant" assets that give the level some nice mood lighting and more visual juice. I feel that the level now looks far better and that the whole game now fulfils my design pillar of "Interesting Visuals". If I can find the time before the end of the project I would like to implement more particle effects, however the game is looking great as it is now and I need to prioritize other things first, such as polishing the camera swap mechanic and adding a coin counter to the end screen so that the player can see how many coins they missed during their playthrough, potentially adding some replayability to the game.

Here's what Level 3 looks like now:

Level 3 Geometry Improvements

At first, level 3 had very simple geometry. It was very blocky due to the fact that I had prototyped it using ProBuilder quite quickly. I thought it didn't look very craggy and canyon like because the surfaces were all very smooth. To change this, I used ProBuilder to subdivide the faces of some of the geometry assets and manipulated them to create less straight lines and a more craggy appearance in the level.

Here is an example of this:

Menu Improvements

From here, the only thing to improve visually was the menu system. I found a free font that best suited the game's nature and applied it to the menus to make them pop out at the player a bit more, as well as a blue colour when the player hovers over a button to make it obvious that it can be interacted with. I also added a pixelated video of the first level to the background of the main menu and the new control screen to give it a more polished feel.

The new control screen features short videos of each major action that the player can take in the game as well as the controls used below it. This helps the player to visualize the action talked about instead of it just being explained through text. I wanted to avoid an intrusive tutorial at the beginning of the game, so these controls can be found in the main menu for the player to look at as they choose.

I also added a few simple hints to the main menu screen, as I am anticipating some players may need them due to the fact that the game combines mechanics and genre from FPS and 2D platforming and they may take a second to wrap their minds around the new concept. This also reduces intrusive UI whilst in game and the player can read them here if they wish.

Here are some images of the improved menus:

As mentioned above, as a stretch goal, I will be adding a coin counter to show the player how many coins they missed in the levels, and maybe even how many enemies they killed to add some replayability to the game.

Player Hit Sound Effect

The last bit of audio juice that I need to add into the game is a sound effect whenever the player is hit. This not only signifies to the player that they are taking damage but also gives their character a more alive feel (despite being a capsule) and may help the player to feel more connected and immersed in the game.

To achieve this, I simply made a collection of grunting sounds into my microphone and set them up in unity using C# to play whenever the player takes damage. I used audacity to improve the overall audio quality and reduce noise.

So that the player did not grunt every tick that they took damage, I had to use a timer, a "hasGrunted" Boolean and the "isTakingDamage" Boolean from the player's Health Manager script to determine whether or not the player had grunted in the last few seconds. This avoids a mess of sound and spaces the sound effects out nicely.

Here's the short script that I wrote to achieve this:

Optimisation

As the game is now asset and feature complete I will be looking at ways that I can optimize my game. This is important, as I have been using a very powerful gaming PC whilst playtesting the game and it is possible that it will not run as well on other systems. This will also help me to realise my stretch goal (albeit after the module is over) of porting the game to mobile.

In order to achieve this I used Occlusion Culling. Essentially what this does it tell the game not to render anything in unless the camera is looking at it. Everything outside of the players view is not rendered in which drastically reduces the number of tris and objects that the game has to render at once. I applied this across the levels and immediately saw a more stable FPS.

First External Playtesting Build and Questionnaire

At this point in the game I am happy to create the first build intended for external playtesting. Thus far, I have been playtesting the game myself through each stage of development and with every change made so that I could iterate on it quickly. Now I must playtest it with an external audience to gauge whether or not the game answers its research question, "How can FPS and Platforming genres be merged?" and to identify any areas of the game that could be improved or polished before it is complete.

To playtest I will be using a mixture of observing players play the game and a questionnaire to gather qualitative and quantitative data. I will make judgements from this data about what I need to change about the game so that it best serves my concept, answers the research question well and has the right amount of polish. The changes I decide to make will also take scope into consideration. I will not be making any changes that drastically overhaul the game or changes that would take too much time to implement as, at the time of writing this section there are only three weeks left of development time.

I observed some players testing the game in person as this helped me to see where people got stuck and how the mechanics play for someone who has never played the game before. I observed that some changes need to be made, particularly surrounding the difficulty of the game. Players struggled to get to the end of the game because of this.

I gave the playtesters a questionnaire to fill out alongside the build.

The questions mainly pertain to ease of use, whether or not the game meets it's design pillars, and how the game merges the two genres.

Here are some screenshots of the results:

From this I can glean that the players felt that the game successfully combines the FPS and 2D platforming genres into one cohesive title. This satisfies the main goal of the project. The feedback also shows that players enjoyed the visuals and felt that they added to the experience. One player didn't read the controls page and as such struggled to get past the first platform as they did not fully understand the camera mechanic. Despite most players claiming in the questionnaire that the game had just the right amount of difficulty, from observing them I could see that many found it quite hard.

One player also commented that the grenade launcher doesn't work. The grenade launcher has not been an intended feature since the first prototype but I gather that this player saw that the gun had an underslung grenade tube and tried to use it. I will remove this from the models to avoid confusion.

Only one player finished the game which highlights the need for checkpoints and mechanics to make the game easier.

I need to ensure that all collisions and platforms are working.

Players tended to get stuck on some of the jumping puzzles in the second level, mainly when puzzles required that the player line themselves up with the obstacles in 3D mode before engaging with the puzzle. I need to use lighting to guide the player's eyes towards the perspective objects. I could also use triggers that automatically align the player with the obstacles on the Z axis when in the area of the puzzles. This would not be obvious to the player as they would only be moved a small amount and it would feel like they had figured the correct alignment out themselves.

Another change that would make the game less difficult would be adding checkpoints throughout the level. Some players became frustrated when they died later in the level and had to restart from the beginning. This would help the game to be less punishing and would create a more casual and easy going style of gameplay. I underestimated how challenging the game is to new players so I need to help players out by using checkpoints.

Some jumping puzzles proved too difficult and need to be made easier. One player suggested adding "Coyote Time" which is a term coined from the Crash Bandicoot franchise.

This refers to the small window of time in which the player may still jump after going off the edge of a platform. This allows the player to jump slightly late and prevents them from falling as often. This is usually not noticeable to the player but allows them to traverse the level more easily and creates a less frustrating experience.

Other changes could be made to the level's geometry. This is because some players found ways to jump around some puzzles and snipe enemies across the map in level 2. I need to block off these areas and angles to prevent this.

Some players often found that when faced with a sudden group of enemies they didn't have time to react before being shot and killed. I may increase the player's health so that they have more time to react to enemies. However, many scripts depend on exact health values, such as the damage overlay and player grunt sound effects so I may simply reduce the damage of enemy weapons instead.

Here is a concise list of the changes to be made:

Fix Leap of Faith in Level 2
Add Checkpoints
Add "Coyote Time" to Player Controller
Add Z Axis Alignment Triggers
Block Off Sniper Angles and Unintentional Jumps
Increase Player Health or Reduce Enemy Damage

Here is a list of bugs that players found that will be fixed:

Moving targets in Level 2 are too fast
A moving platform in Level 3 does not move
A ledge in Level 1 is not lined up properly with the Z Axis, allowing the player to fall

As I fix these issues I will provide screenshots to show my iteration.

Firstly I fixed an issue where players were having trouble lining themselves up with the third coin in the second level in FPS mode. To fix this, I gave the coin an extended trigger that goes out on either side so that in 2D mode the player will collect the coin no matter where on the Z axis they are. This is instead of adding a trigger that resets the player on the Z axis as it takes far less code and time to implement and solves the problem just the same. It will still appear to the player that they lined up with the coin correctly. Here is what the coin's trigger looks like now:

Also in level 2 I fixed the leap of faith near the end. Players were making it to the final block of the jump puzzle but their momentum carried them forwards and off the other side. To fix this I simply extended the platform so that there is no longer a gap after that platform. Here is a before and after of the change made:

Next I fixed the issue where players could snipe enemies across the map and also bypass a jump puzzle at the start of level 2.

Here you can see where they were able to jump around the rock and the angle at which they could pick off enemies in the distance:

I fixed this very simply by putting another rock wall in the way as you can see here:

Checkpoints

Next I moved on to creating the checkpoint system.

As the second level especially has a relatively high load time compared to other levels and writing data to a script to have it reloaded at a checkpoint would take far more time to code, I opted to have the checkpoint system work by simply resetting the player to the checkpoints location in the scene rather than reloading the whole scene.

I do this by detecting whether or not the player has reached the checkpoints using triggers and booleans, then making the player's transform the same as the checkpoint's transform when their health reaches 0 or they fall off the map.

I had an issue whilst programming this however. I found that, although my code moving the player to the checkpoint locations was sound in terms of logic and syntax, the player still would not move. I then realised that this was because the player's own movement script was updating its transform on update, meaning it was being changed every tick. To get around this I added a section to the checkpoint code that disables the player's movement script for a short amount of time upon death, allowing the checkpoint script to move them, then re-enabling it.

In order for the checkpoint code to work, I had to implement the checkpoint code across multiple scripts. The death box script that checks whether the player has fallen off the map, and the player health script that checks how much health the player has in combat.

Here are some screenshots of this code in each script:

After testing this thoroughly, I found it to work 100% of the time across all levels. I am glad that I thought to do it this way as it saved me a lot of time messing with save data.

Coyote Time

After implementing the checkpoint system, I asked some players if they felt the game still needed Coyote Time as well as the checkpoints. They said that the game was now much more forgiving and that the more challenging platforming mechanics without Coyote Time make the puzzles more gratifying to complete as they don't have to go all the way back to the beginning of the level when they slip up. For this reason I will not be implementing Coyote Time, as at the the time of writing this section, the project deadline is rapidly approaching and I need to be getting on with wrapping up the project.

Minor Bug Fixes

Next I set about fixing some minor bugs.

I slowed down the moving cube target puzzle in Level 2 so that the player can hit the targets more easily. I also widened a ledge in Level 1 that players were consistently falling from so that it doesn't provide a source of frustration. Lastly I fixed a moving platform in Level 3 that didn't move as it had been marked as "static" despite it needing to be mobile.

Final Playtesting

After implementing these changes I have conducted a final round of playtesting. I watched players over the shoulder as well as asked them to fill out an updated questionnaire after they finished playing. I used a larger sample group and used some of the previous playtesters to see if any of their answers had changed.

From watching players over the shoulder, I gathered that they were having a much better time with the game. This was mainly due to the implementation of checkpoints making the game less frustrating to play. Players seemed to get stuck far less and the vast majority actually completed the game because of this.

Here are the responses to the questionnaire:

This time around I received an overwhelmingly positive response. The vast majority of players felt that the game offered a new an interesting experience, that the game successfully combined the two genres and that it was a resounding success. Some players felt the game was still a bit too hard, however these were players that were used to playing with controllers. Controller support is one of the project's stretch goals, however I will not have enough time to implement this before the deadline. It is something I will look at implementing if I continue development of this game, which I may well do, as one play tester said that with more dev time they would consider buying the game!

The game doesn't seem to have any major usability issues either. Most players completed the game and felt that the combat mechanics and visuals were up to scratch.

From this feedback I can gather that the game is in a great state to be submitted. I will be fixing the bug where the pause menu buttons in Level 2 are broken, but other than this I can declare the project complete!

I will now be cleaning up the project files, deleting unused assets, finalizing lighting builds and creating the final build for the project.

How Has My Primary Research Answered My Research Question?

The primary research that I conducted through watching people play my game and having them answer the questionnaire allowed me to provide some answers to my research question of "How can FPS and Platforming genres be merged?".

The vast majority of my playtesters agreed that using perspective shifting and thoughtful level design worked very well to merge these two genres. They felt that it allowed the game to contain and blend these two genres within one title. They also felt that an equal amount of the mechanics that are core to each genre were included.

Based on this feedback here is how FPS and Platforming genres can be merged:

Use a mechanic that acts as a go-between for the two different genres. In this case, I used perspective shifting as it allowed me to use a different set of mechanics in each perspective or mode.
Include areas in each level that are conducive to both playstyles. Is there enough cover in the FPS heavy areas? Are there enough platforming elements like coin collection and jumping puzzles?
Blend 2D and 3D space together. I used art assets that changed their behaviour and how the player interacts with them in each perspective mode. This created interesting puzzles and gave the same object a different use depending on the mode. It may be cover in FPS mode but act as a jumping platform in 2D. I think this blend specifically is what made the game so compelling to players as it was seamless and players thought that this was quite clever.
Don't try and do too much. Less is more. When developing this game I ensured that I didn't feature mechanics that were too complex from either genre. I used the bare bones core mechanics from each so that the player did not get confused or overwhelmed. This helped the game to remain simple and casual as well as providing a fresh and innovative experience to the player. It made the genres easier to blend and ensured that the player was not overwhelmed by too many complex mechanics. It would have been substantially harder to blend the two genres together if I had added too many mechanics.

What Have I Learned About My Development Process?

Here is a concise list of the things that I have learned throughout developing this project:

1: Always Review Scope!

After every sprint I reviewed how it had gone and made changes to the project scope accordingly. Yes this meant some things were left on the cutting room floor or altered from the original plan, but this is all part of the agile development project. The developer should always be prepared to cut and change things in order to be fluid and adaptable to reach their project goals.

2: Don't Be Afraid to Use Third Party Assets!

The use of third party assets really saved this project. I absolutely would not have had time to explore the main research question of the project and how the mechanics and level design work together if I had not used third party art assets and AI. I am not a one man army, and very few developers these days are. I operated in a way that reflects how a designer would in a studio team, using assets created by others to build a great experience in engine. This massively reduced scope for me and turned out to be the right decision!

3: Playtest! Playtest! Playtest!

This goes without saying but playtesting was a massively important part of my development process! As per the agile methodology, I would thoroughly playtest every iteration I made to the game. I would do this myself until I had a more cohesive build to show players. At this point I relied heavily on external playtesting to iron out and polish the gameplay experience into something that really smashed my project criteria! Seeing other people play your game is hugely important, as you, the dev have a twisted view of you game. You may be biased on some aspects or blind to things like difficulty curves as you have spent a while playing it yourself! Always get outsider perspectives!

4: The Simplest Solution is ALWAYS Best!

When operating on a short timescale, the simplest solution to a problem is always best. I took some shortcuts when developing this title, such as not using save data on the checkpoint system and extending triggers around coins so that I didn't have to write an extensive amount of extra code which would have impacted on development time. Always consider what the simplest and quickest route is to achieve your goal. The agile methodology allows you to revisit this later and iterate upon it to improve it, so just go with the simplest and fastest route to your goal to start with as this will drastically reduce scope and dev time! If it throws up issues, these can always be addressed later!

And with that I can declare this project complete!

List of Third Party Assets Used Within Shootformer:

18 Seamless Normal Maps 512 Free by Ninety Nine Works https://assetstore.unity.com/packages/2d/textures-materials/18-seamless-normal-maps-512-free-3063

Fantasy Skybox FREE by Render Knight

https://assetstore.unity.com/packages/2d/textures-materials/sky/fantasy-skybox-free-18353

Free Low Poly - lava Plants by EmacEArt

https://assetstore.unity.com/packages/3d/environments/fantasy/free-low-poly-lava-plants-145043

Lowpoly Environment - Nature Pack Free by Polytope Studio

https://assetstore.unity.com/packages/3d/environments/lowpoly-environment-nature-pack-free-187052

Low Poly Space Rocks by Infima Games

https://assetstore.unity.com/packages/3d/environments/sci-fi/low-poly-space-rocks-58385

Low poly styled rocks by Daniel Robnik