Shootformer - An Experimental Game Development Log

In this post I am going to be noting down my process for designing and developing a small experimental game title called Shootformer. This project is created as my submission for the GAM704 - Experimental Game Design module during my MA Game Design course at Falmouth University. I will be updating this post as I develop the game.

I will be detailing my ideation and research process as well as my design process in chronological order and discussing any issues or interesting points that arise during development.

First I should give an overview of what Shootformer is, so here is my elevator pitch for the game:

"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 level, collect coins, kill enemies and solve puzzles!"

The project will be created in the Unity engine using C# as this is the engine and programming language that I am the most capable in for prototyping games.

Ideation and Research Phase

For this project I wanted to experiment with genre.

The game is experimental in the sense that it aims to combine two genres that don't usually get put together.

To come up with this concept during the ideation phase I put many genre names into a hat and drew them in pairs until I found a pair that I haven't seen tried before and that could yield some interesting new gameplay.

Figuring out how to combine these two very different styles of gameplay into one game was my first obstacle to overcome. I was inspired by game designer Matt Stark on twitter who is currently developing a game that involves an interesting use of perspective shifting using a Polaroid camera. I started to think about how I could realize my game idea using a kind of perspective shifting mechanic.

Here is a post showing his experimental mechanic in action:

https://twitter.com/mattstark256/status/1399775988112924673

I scoured the internet for games that combine 2D Platforming and FPS mechanics but I couldn't find a single one. This was when I knew that I needed to try this concept as it seems like it hasn't been done before, which means that I could come up with something truly original and interesting in terms of gameplay.

I also researched into other games that aim to combine two genres together for inspiration and came across an article online by Chris Reed which listed examples of games that successfully combined two genres to make a new experience.

One of these games, Valkyria Chronicles (2008), stood out to me as it uses perspective swapping to combine Real Time Strategy mechanics with Third Person Shooter mechanics. The player must position and organize their units from a top down perspective like in an RTS title, but they must then dive down into the action and control each unit from a third person perspective to actually engage in the shooting combat.

This further inspired the camera swapping idea and made me think about how I could make the transition smooth so that the player isn't taken out of immersion by sudden camera changes. The camera swapping in Valkyria Chronicles is very smooth and features a kind of blend animation to make the transition as smooth and visually pleasing as possible. I will be utilizing some kind of similar camera animation.

I also looked at Portal (2007) and Paper Mario (2000) as these are considered to be very successful games in their given genres, so I could see what elements from each define the 2D Platformer and FPS genres. This is because I want to strip back the two genres to their basic forms and mechanics before combining them as the experimentation for this project is to come from the combination of the core mechanics of the two genres rather than seeking to experiment with the mechanics within either genre. It's all about how they interact with each other rather than how they play on their own.

I chose Portal (2007) as a research reference over other FPS games as my game will have a heavy emphasis on puzzles with a lesser amount of focus on the killing of enemies, although this will also be present.

The game level should play like one big puzzle that needs to be solved by utilizing the perspective swapping mechanic.

Before diving into development I considered whether or not this project will have any ethical, legal or social issues, however the only thing I can think of is that it may offend purist fans of either the 2D Platformer or First Person Shooter genres. However, I don't think that this will be a huge issue as these social groups are relatively small and the game is not aiming to please fans of either genre and merely intends to experiment with the two genres to see what will come of it.

Any criticism from these groups may be a sign that the experiment is a success as often, innovators and innovation is frowned upon and scoffed at before it succeeds. The aim of my experimentation is to go against the grain so criticism or praise from either of these groups may be indicative of my experiments success.

A More Detailed Look at the Game Mechanics and Concept

In this section I want to explain the different intended mechanics and systems that are going into the game before I begin my development log, so that the reader fully understands the game's concept.

Depending on the player's perspective in game, 2D or FPS, there will be different mechanics available to them that will allow them to overcome different obstacles and puzzles in the level.

The main mechanic is the ability to freely swap between camera perspectives. Here is a list of the mechanics and limitations that the player will face when using each perspective:

• Player can’t shoot in the 2D perspective - this means that the player can't kill enemies or complete puzzles that involve shooting, requiring them to swap perspective.

• Player can’t move on the 3D axis (Z) whilst using the 2D perspective - left/right movement only. This restricts what areas of the level are accessible to them whilst using this perspective.

• Some jumping puzzles can only be completed in 2D mode using perspective shifting.

• Player can use the 2D perspective to see obstacles or enemies ahead that they would not be able to see whilst in the FPS perspective.

I wanted to experiment with challenging the player through limiting what actions they can take, rather than providing them with total freedom at all times, as seems to be the current trend in video games. Some players enjoy being limited and challenged by a tighter set of rules, and this is the mindset that I aim to tap into by limiting the player.

This will make the level like a puzzle that the player has to solve using a combination of the different mechanics.

Game Features and Systems

These are the features and systems going into the game:

• Perspective Swapping - swap between Orthographic 2D Camera and 3D Perspective Camera

• 2D Side-Scrolling Movement (2D Platformer)

• Jumping (2D Platformer)

• Coin Collecting - three hidden coins to collect, Mario style! (2D Platformer)

• Shooting (FPS)

• Killing Enemies (FPS)

• Dying to Enemies - resets level (FPS)

• 3D Movement (FPS)

• Target Shooting Puzzles (FPS)

Here are some example diagrams of puzzles and situations the player will find themselves in:

In order to keep scope down I will do the following:

• Create one level only

• Maintain simple blocky/prototype art style

• Use simple, basic mechanics and conventions from each genre

Development Phase

This section of this post will detail my development process in chronological order.

Player Controller and Game Manager

Firstly, I began to prototype a camera shifting mechanic that allows the player to utilize both the 2D and 3D perspectives. I decided to prototype this first as it is integral to the game's success and playability.

I have bound the button to swap camera perspectives to the [F] key as this is easy to reach when using the standard WASD controls on a computer.

The game is made entirely in 3D despite having 2D platforming mechanics. All art assets are in 3D. To make the game look 2D and flat when in the 2D perspective I have used an Orthographic camera that makes the 3D assets appear to be 2D when in this mode.

This mechanic works well and has the cameras swap between the orthographic 2D camera and the perspective based 3D camera easily. This is handled through a game manager script that will also handle what controls are available to the player and change certain properties of objects in the world depending on what perspective the player is using.

At this stage I also programmed the movement mechanics and the shooting of projectiles from the gun.

Here's a quick gif showing the camera swapping:

As you can see I also programmed the 2D camera to follow the player with some smoothing to get the sidescrolling effect.

After testing this for a few minutes I realized that the player looks like it is walking backwards when moving left and that vision when moving left is very restricted.

I iterated on the camera offset so that it is centered more on the left side of the screen when the player is moving left and I've made it look like it are facing the other way so that it don't appear to be walking backwards.

Here's a gif showing that change:

In order to have different movement mechanics when in each perspective the game manager controls a boolean that checks whether the player is in first person. This boolean is checked by the movement script and will only allow the player to move left and right when in 2D mode.

It also resets the player to the middle of the platform again so that they are in line with any obstacles later on with the level.

This boolean also controls the active status of the gun object seen attached to the player in 2D mode. The player has to be rotated based on which perspective is being used to make the controls translate well between 2D and 3D mode, so this gun is activated for aesthetic purposes when in 2D, as the gun seen in 3D mode is actually positioned on the other side of the player.

The isFirstPerson boolean also controls whether or not the player can shoot.

Here are some screenshots of the code used to control the perspective swapping and movement using the isFirstPerson boolean:

This part of the game manager (above) also controls which camera the UI canvas is parented to, which will show the player how many coins they have collected later on.

As can be seen here, the player movement is different depending on the value of the isFirstPerson boolean.

The movement was difficult to program at first as I had to figure out which mode of movement would be best, adding impulse force to a rigidbody on the player or using the controller.Move function inbuilt to Unity using Vector3 positions.

I decided that using the controller.Move approach was better as it resulted in more efficient code and less physics calculations for the game to run, resulting in a more optimized player controller.

Level Design

With the movement mechanics, game manager and perspective swapping working, I decided to move onto the level design, as once I have my level into engine I can start to iterate on the movement by play-testing the level and changing values such as jump height and movement speed accordingly. Having the level implemented at this stage will also allow me to start playing around with perspective based puzzles.

I developed my first prototype of the level on paper, as my graphics tablet that I'd usually use to make this process faster and easier was not working.

Here are some images of my paper level design prototype:

These designs detail the locations of enemies, perspective puzzles, coin collectibles and door puzzles.

I then got down to implementing this in engine. I used Unity's ProBuilder plugin to build the level quickly using simple geometry. This greatly reduces development time and allows for quick modification and iterations on the level.

Here are some screenshots of the level in engine:

The whole level seen from the side.

A perspective jump puzzle seen in 3D.

The same jump puzzle seen from the 2D perspective.

The final section of the level where the most enemies will be. I decided to add some more objects in here to act as cover, to provide the player with cover from enemy fire that they would expect from an FPS game. This differs from my paper prototype as it was an after thought.

This is a door puzzle where the player must shoot the red targets on either side of the cube to open the door. I originally planned for the target to be hit by having the player lob a grenade over the door. However, due to programming issues that I could not fix without significantly eating into my development time, I had to remove grenades from the game as they did not function properly. Instead the player may now use the platforms to the side to look around the door and shoot the targets. This work-around is also used later on in the level when the player would've shot a grenade over a wall to hit and collect a coin.

Perspective Jump Puzzle Functionality

Next, I programmed the jump puzzles to allow the player to stand "on top" of the cubes in 2D mode, even though the cubes are rendered off the center path that the player occupies when in this mode. I did this by having colliders attached to each cube that extend out into the middle of the level that are only active when the player is in 2D mode. These colliders are tagged as "PerspectiveCube" which allows the game manager to find them, add them to an array and activate/deactivate them in the scene depending on the value of the isFirstPerson boolean.

Here are some screenshots showing these invisible colliders and the code that makes them work, along with a gif of them functioning in game:

Invisible collider, activated when in the 2D perspective.

Game Manager code that finds and sets the active status of the colliders.

Player completing first perspective jump puzzle by swapping perspectives.

After making these colliders work I iterated on these cubes by adding functionality for them to move. Some puzzles in the level require that they move between two points.

I initially attempted to achieve this by animating each cube using Unity's in-engine animation tool, however this was way too time consuming as it meant I needed a different animation for each cube because they are in different locations in the level.

Instead I decided to use the lerp function in C# to have them move smoothly between two different points that I could define by plugging game objects into the inspector. This also meant that I could control the speed of the lerp for each individual cube which will come in handy when play-testing as it makes it very easy to change the difficulty of puzzles using these cubes on the fly.

Here's a gif of these cubes working in game:

Enemy AI and Shooting Changes

Next, I programmed the enemy AI.

I wanted to make an AI that was relatively simple to save on development time and that serves the prototype nature of the project. It must be able to shoot and kill the player and navigate the level.

I first programmed it to behave as an FPS enemy only, that can fire projectiles and kill the player. It patrolled between two points when the player was not in view, chased the player when not in range and shot the player when the player was within a certain distance.

I found that this was great for the FPS perspective but it seemed strange and disconnected from the gameplay when the player is in 2D perspective and so I felt they needed to be iterated on. I decided to make the AI behavior change depending on which perspective the player is using.

Now, if the player is in the 2D perspective they will behave like a standard 2D platformer enemy and simply patrol between the edges of whatever platform they are on. When in 2D mode they will not actively chase the player or shoot, but if the player comes into contact with them, they will die and respawn at the beginning of the level. They behave much like a Koopa from the Mario franchise.

This feels much better and helps the game to feel distinctly different depending on which perspective the player is using and feels more intelligent to play against.

I implemented a simple health system for the player and enemies so each can die if they take a certain amount of shots. These health and damage values will be tweaked when I playtest the game with other people.

I also found when playing against these enemies that the enemies would sometimes not detect the collision from a projectile from the players gun. For some reason, making the enemy hit boxes larger did not fix the issue and I could not figure out why this was occurring.

To get around this I decided to change the player's weapon to a raycast based weapon instead of projectiles. Not only did this fix the issue but it also serves as a more optimized way to handle shooting as it means Unity has to handle less physics calculations because fewer objects are being spawned in the scene which reduces lag. I added a small muzzle flash particle effect and line renderer to show when the player shoots. Visual feedback is important to ensure that the player feels they are having an impact on the game world.

Here is a gif of the enemies working, shooting the player and navigating the level:

Door Puzzles

Next up I added functionality to the door puzzles. These are puzzles that the player must overcome by swapping to the FPS perspective and shooting targets that allow the door to be open.

This was quite simple to achieve as the targets simply detect when they've been hit by the player's raycast and pass this information onto the door script as boolean values. When all of the targetHit values are true, the door will be destroyed and the player can pass through. The targets are red like the enemies to signify to the player that they can be shot at, and they turn green when shot to show that they have been hit.

Here's a gif of the door puzzle working and a screenshot of the code that makes it work:

As you can see here, the code will only require two targets to be hit for the variant of the puzzle with only two targets.

Coin Collectibles

After the door puzzles I implemented the coin collectibles along with a UI element on the canvas that shows how many coins the player has collected out of three. My hope is that having this shown in the top corner will encourage the player to explore the level in full and want to collect all of them. The player may walk into the coins or shoot them to collect them. Two of the three coins positioned in a way that they must be shot in order to be collected because they are out of reach.

I added a shiny gold material to the coins to make them look attractive and valuable to the player, along with an animation that makes them slowly rotate. I also added a crosshair to the canvas at this point to make aiming easier for the player as I realized this is something I had forgotten.

Here's a quick gif of this system working:

As you can see, this part of the level realizes my earlier diagram where the player must enter the FPS perspective to get to a coin that is inaccessible in 2D.

Game Wrapper and Win/Loss State

Next I implemented the game wrapper and a win/loss state to the game.

I've used very simple menus to save on time and to keep scope down. After all the game is a prototype and does not need incredible graphics to show off the experimental mechanics.

The menus are easy to navigate and the main menu shows the player the controls needed to play.

Here are some screenshots of the menus:

The win/loss states are now complete. When the player takes too much damage or falls out of the level they will die and the level will instantly reset. I decided not to implement a loss screen as this breaks the game flow. Players tend to want to retry immediately without having to go through menus to get back into the game.

The win state when the player reaches the goal (the green area seen in the screenshot below) they will be taken to the win screen where they may return to the menu, replay the level or quit the application.

The goal area is green as this is commonly associated with something good in colour theory. The flag also signals the end of the level as it is a popular trope in platforming titles to end the level at a flag, which was started by the Mario franchise.

First Build and Identified Bugs

Now that all of the base elements are complete, I have created a first build and will begin thoroughly play testing the game to look for bugs after implementing Cinemachine for the camera transitions. I will do this on my own to start with and identify bugs and glitches as well as iterate on the game's level and mechanics depending on what is needed. I will then hae it playtested externally and gather feedback that will help me iterate on the game.

Here are the bugs/problems that I have identified in the first build listed in order of importance:

• Enemies after the first one will not shoot the player in first person mode.

• The player will not stick to moving platforms and appears to glitch around when in contact with them.

• Camera follow mechanic stutters slightly, needs to be smoother.

• Player can skip part of the level by jumping down from the area containing the second coin.

Before I move onto fixing these bugs I am going to attempt to implement Cinemachine camera animations to make the camera swapping much smoother and less jarring to the player.

Cinemachine Implementation

Implementing Cinemachine took far longer than expected. Having never used it before, it took some experimentation before I could achieve the camera blend that I wanted. I had to rework the entire camera system in order to get it to work. I had to delete the player camera and replace it with a Cinemachine virtual camera and add another virtual camera for the 2D gameplay. This is because Cinemachine works by having the main camera asset in Unity swap between these two virtual Cinemachine cameras.

It took some time playing around with different values in the inspector before I figured out how to create the camera blend.

Here's a gif of some gameplay featuring the new camera animations:

I eventually achieved it by having the game manager script change the priority values of each camera depending on the perspective. This allowed Cinemachine to identify which camera should be in use and play the corresponding blend animation.

I also had to figure out how to change the projection mode of the camera depending on the perspective, as it must change between orthographic for the 2D gameplay and perspective for the 3D gameplay.

Cinemachine has its own built in camera follow function so I adapted my camera follow script to make use of this. The Cinemachine camera follows the player on its own but my script changes the offset values of the Cinemachine component depending on which way the player is facing.

Here are some screenshots showing the changes made to the game manager and camera follow scripts and the blend settings in the inspector:

With these changes the game feels smoother and less jarring to play. It was definitely worth the time and effort it took to learn Cinemachine and implement these changes.

With this added, the game is mechanically complete. Next I must go through the game and fix the bugs as mentioned before and have the game playtested so that I can make iterations based on player feedback.

Player Feedback

I put together a feedback form to see if players feel like the game is sufficiently experimental and plays well. I wrote this with my success criteria in mind too. Here's a reminder of my success criteria:

I conducted the playtesting remotely by sending out builds to 10 players of both genres included in the game so that they know what they're talking about when it comes to each genre. I tried to include questions that would yield both qualitative and quantitative data so that I can get a good picture of how successful the game is as well as how players felt about it.

Here are the questions on my form:

These questions should allow me to gather the data that I need to make effective iterations to the current build of the game.

Here are the responses:

These answers have provided me with valuable data that I can use to improve the game.

It also showed me that the game has so far met most of my success criteria. Most players felt that the game was experimental, that the mechanics work well together and that the level served both sets of mechanics well. Most also felt that the game was just the right difficulty for them and that the shooting mechanics and camera switching feel good to use.

It has also showed me that I need to add sound effects and music to make the game a more pleasant experience as well as fix some important bugs such as the player not sticking to moving platforms and the AI shooting bug.

However, due to time constraints I may not be able to implement all of these changes. The AI bug is going to be especially difficult to fix so I am going to attempt this last if I have time. I think the game has already proved to be a relative success in relation to my success criteria so these changes are mainly for polish and player satisfaction. Someone suggested more levels that take the experimentation further but there simply is not time to do this.

First I am going to implement music and SFX, then fix the glitchy moving platforms. If these are completed in good time then I will move on to the AI shooting bug. Iterations Based on Feedback

I have now completed my final iterations for the game and made the final build. I was able to add in sound effects and background music that adds to the mood of the game and gives the player some audio feedback.

I was able to partially fix the moving platform code so that the player does not shake about as much but the player still moves slightly when on the platform.

The AI bug was actually easily fixed. The reason they weren't attacking was because their "time between attacks" value was set too low. Adjusting this allowed them to shoot at the player again.

The final build can be downloaded from this google drive link: https://drive.google.com/file/d/1iikP0KRZ3_IDN5C7KhEq6s-FlHLrfYUy/view?usp=sharing

Conclusion

With the game completed and the feedback gathered I am happy to say that I think the game is a success. I have delivered on all of my success criteria. The game successfully mixes the two genres of 2D Platforming and First Person Shooter in a way that is experimental and interesting. I think I've made a game that isn't like anything else out there in terms of its concept. I have made a level design that accommodates both sets of mechanics and plays like a puzzle that the player must solve with the use of every mechanic. I have overcome problems using creative and experimental techniques and I have definitely grown my technical skills and my design knowledge through this project.

If I had more time I would add/change the following to the project:

• More visual feedback like screen shake and red overlay when player is shot.

• More levels to further explore the mechanics and how they could fit together in different ways.

• Fix bugs like the moving platform issue.