Codename: Pariah
ROLE
Game, Combat, Systems & Level Designer
Producer
DESCRIPTION
Codename: Pariah is a fast-paced First Person Shooter wher the player controls and ethereal being from beyond our solar system. The creature has no weapons or abilities and can't survive outside a host for very long.
Players must use enemies as hosts, turning their own health, weapons and ammo against their comrades in order to escape the facility.
Codename: Pariah was a Major University Project at AIE Melbourne that was nominated for best project.
I was the sole designer and producer on this project.
YEAR
2021
GENRE
Single-Player Action FPS
PLATFORM
PC (Windows)
PROJECT TYPE
Capstone University
GAME DESIGN
On this page I will discuss the Game Design choices that I made for this project including features that were ultimately cut from the final version.
Overview
Here are the key features of the game design that made it into the final product.
Player Controllers
As we were building a movement shooter taking inspiration from modern Doom games I knew that the 3 C's were going to be the most important aspect of the design feeling good in the hands of the player.
The challenge was with the concept is that the player controls both the Ethereal version of Pariah and the Possessed Hosts, which meant 2 separate player controllers.
This is one area that I believe was an incredible success for this game. The Controllers feel great to just move around the space, especially during prototype and greybox phases where we didn't have any performance issues. This is one area that got the most positive feedback from the team at Sledgehammer Games Mel who reviewed our project at every milestone (a gamble I took knowing we had to deliver on time and heed their feedback or we would shoot ourselves in the foot in getting hired at one of the major studios in Melbourne)
As Pariah, the player was able to float as if gravity didn't effect them, the player's POV increased slightly which scaled with the POV options in the menus but this change made the movement feel more ethereal and accentuated that you were not human.
As Pariah the player was still able to use their dash ability which we used a Pariah arm animation to ground the movement in reality wiht the player pulling them-self through the space at speed. This with the short delay on the dash made for a very satisfying dash that felt very powerful.
As a host the players could Dash, Double Jump and crouch slide, including crouch sliding off a incline/ramp (which sadly I toned down from early prototype as it was a bit much) but it meant that for players once they got up to speed you could crouch slide off a ramp, dash twice before using the in air jump of the double jump, all without touching the ground.
This meant alongside some animations and voice lines made you feel like you were using your meat puppet to get around arenas at beyond human speeds against the will of the host, whilst shooting. It really allowed for true power fantasy of being more than human.
Enemies
My intent with the enemies was to have clearly defined enemies in which you knew how they would act and how you can beat them.
I very much used the Combat Chess idea that is used for Doom and Wolfenstein as the core pillars of how I would design the AI.
First we had the Scientists who were supposed to be weaker that soldiers but would drain twice the HP per tick of their health as Soldiers. Scientist were also originally designed to be the ones who could interact with items such as the turrets, which mean that you wanted to keep them alive to quickly refill you health if it became depleted and use them to remove the turrets. I also debated making the scientists the only enemies that could target you whilst outside the host but as these were the weaker enemies used immediately in the tutorial I decided this would have been used as a later feature if the game continued past our intended experience.
With the Turrets removed this had the effect of rendering the scientists a little useless with their slower attack so I bumped up the damage so they have a semi-auto shot which if the player controls recoil they can kill faster with the pistol than the assault rifle.
The Soldiers had more health, were more aggressive and dangerous as enemies whilst also being the only hosts able to use the dual wield AR pickup. This was designed as such that it made it a tactical choice to leave some alive during battles so that you could jump into another with full health and ammo and the option to use pickups if it got a bit hectic (or wanted the power fantasy of using two ARs at once). i designed so the players would.
The turrets would have been stationary turrets which would only be able to track and target you whilst you were in a host, giving another sorely missed reason to leave and switch hosts. This was something thew team at Sledge said to cut to reduce scope but as we had it basically done I wish we hadn't. The other option I wanted to explore with the turret was to have a HAL 900 like targeting sensor which you could target as a weakpoint that would either disable the turret or set it on a frenzy before it self-destructed.
Recoil System
As an FPS game, one of the core elements I wanted to focus on was the shooting, especially with the project getting feedback from the name in FPS games in Melbourne. If everything else failed but we had good movement and the shooting then we'd still have hit the core aspects of what makes an FPS game fun.
Providing useful feedback to players during gameplay and removing pain points were things i wnated to focus on when i set off to design how the firearms would feel. So this lead to the removal of bullet bloom/spread (excluding hipfire where it would be used sparingly) and providing recoil patterns that could be mastered, which meant repeatable recoil patterns.
So I decided on a system using curves with a +/- curve for the X Axis (Horizontal Recoil) and a + only curve for the Y Axis Recoil (Vertical Recoil). I gave this to Daniel who was working on the combat system from the code side and what we got done together allowed for each weapon to have distinctive recoil patterns.
I also designed variables for how long to reset to the original shooting position so that for semi-auto weapons you could either control the recoil and shoot again or wait and have it return to the original crosshair location.
The system would have been further refined but we noticed that once we added it the player movement slowed down so whilst it is in use the recoil was toned down to very minimal levels. This meant the current system was more than enough but it would go on to be used and refined by the two of us in future projects.
Ammo, Health and Pickups
Player Health was split into Pariah Health which would slowly deplete whilst outside the body and take damage if the player remained inside a host as they died, and the Host Health that the player would use to take damage whilst inside a host but also is the damage they are inflicting on enemies to kill them.
The idea behind this was that you didn't really want to almost kill and enemy and then go inside that weakened host so the idea was that players would have to be strategic with their choices, leaving options as to which host they wanted to possess next.
Same with Ammo, there are no in game pick ups to refill your ammo or health so you needed to swap between hosts when you're out of ammo but if you forget which host you might end up returning to a host with low health and no ammo. The plan was to have this secondary level shell game as you prioritise targets based on their danger level and if you will need them later in the fight.
The Akimbo Pickups gave soldier hosts the ability to go Assault Rifles Akimbo, but it would remain on the host who grabbed the pickup, making it a tactical choice of when to pick them up and requires the player to be in the correct type of host to make that tactical choice.
Checkpoints & Puzzles
Venting Puzzles were one of the earlier aspects I designed after inheriting the concept.
The idea of leaving a body of a host using a vent to escape and enter a new host on the other side was not only a way getting the players into a new host with fresh a health and ammo pool, it reiterated the idea to player as a way of suggesting it be used in combat which was the original intent.
With the limitations of the final behaviour system this ended up not having the same appeal in arenas but was still incredibly useful tool to prepare the player for a new combat space, provide the players with checkpoints and load/remove level data.
I also knew that player might have forgotten to use the hosts to top up Pariah health during combat so we added Stasis pods which the players could drain to directly top up Pariah's health in the incidental spaces between arenas, usually before or after puzzles so that players are expecting on with the other when they appear again later in the game.
The puzzles are some of the areas I'd like to have another pass at knowing what I know now as I think I could have made additions here and better integrated them into later arenas to keep the same length of gameplay and general content level but with a much more engaging final half of the map for players whom the novelty of our solid movement and shooting had worn out its welcome.
Tutorial
For the Tutorial I used several techniques where getting to the gameplay took centre stage whilst Narrative was relegated to a secondary consideration just like the modern Doom Games, especially Doom Eternal who was a focus for me to impress after already impressing them at a previous Design test.
Our Tutorial Begins with the player entering a rift in space on the menu and coming through that rift and directly into a host who draws there weapon and combat begins. We were designing for FPS game developers so we didn't need to patronize them with Mouse and WASD controls. We used the floating text as recently seen in Deathloop to give the player purpose and as a way of moving the tutorial along without pop-ips or prompts.
Kill and Escape was all the player needed to know but as we go through the tutorial we introduce our mechanics with text saying "control your slide" which if the player takes more than a few seconds will change to "CTRL to Slide". This continued through a few small sections of level ending in 2 small arenas where we introduce different enemies, then add everything together as a test of what players had learnt.
This Test was my favourite battle as i think it uses the mechanics we had in the final build the best whilst others were relying on mechanics that were ultimately cut.
Cut Features
Below are the cut features that were in place during the production of this game that ultimately didn't make it into the final product.
Environmental Dangers
Using our previous project Bellum Apparatus as a test bed for Explosive Red Barrel tech we had always planned to get environmental dangers into the game and had the script ready to add.
Unfortunately due to performance issues with the AI and lighting alongside delays in the behaviour system that tied up the programmer of the Red Barrel script this never actually made it in the final build. The red barrels (canisters) would chain and send the canisters across the room to explode which made for a tactical choice as it wasn't just the initial area of effect but a series of explosions that could decimate a group of enemies or cause a careless player to have a canister explode in their face.
The other major environmental danger was containers in the Portal Arena, which the player was to shoot the chain/hook and have it drop as cover or on enemies.
Unfortunately whilst everything was ready for these I was tied up with lighting issues which hindered my ability to get these working in the final version.
As a result of the barrels being cut so late in development that they were already used in the level design, players would shoot the red barrels but they wouldn't explode. I also felt that the lack of these and additional enemy types means for the experience we made can start to feel somewhat repetitive toward the end and would need for the reintroduction of cut features if we were going for a longer experience.
Monster Closets
As this game was heavily inspired by Doom and Wolfenstein the original plan was to have monster closest to extend the length and change the pace mid battle in each arena.
This was something that was designed into the Laboratory Arena as the first arena built but as it was subsequently cut at the suggestion of the team at Sledgehammer Games Melbourne who were giving us feedback at each milestone these were cut from the rest of the game.
The design intent was to have the monster closets be used as a lever for the level designer to increase the difficulty, intensity or pacing of an arena. Currently with all enemies spawning at the start the arenas gradually get easier which was not the initial intent.
The other secondary use of monster closets was to have them change the physical arena layout itself, such as an elevator raising in the middle with a new raised platform which can still be seen in the Laboratory Arena.
Looking back now whilst it was the correct decision to remove them I would have like the option to add monster closets as way of increasing difficulty, intensity and pacing of the arenas especially for those that had other cut features.
Tactical AI Behaviours
The AI system was being worked on for a while before we started development on the project itself and having that to jump off we had behaviours such as chasing and defending nodes working early.
The Intent for the enemies was to have the soldiers chase, with a percentage of them who would keep their distance who would shoot at you from a distance or use Acid Grenades as an area denial before those also were cut early during development.
The Scientists would then defend vents, sliding doors and shoot from a further distance so that they player was moving around the arenas to avoid long distance fire and obtain new hosts with fresh weapons and health as well as knowing that if they used a vent there would be a new host they could jump into on the other end.
Unfortunately we started having issues with the behaviour system and had to kneecap it to save performance. This cut feature is the one I feel hit us hardest as it took up time and computing resources that mean we had to hold back on other already built systems.
The oly reason we went for this style of AI behaviour was that we had it working super early before project commencement otherwise i would have designed around all chase enemies to save the performance.
Enemy Turrets
Enemy Turrets where part of the first design I do for the game and were in place until the first Milestone where I was told we should cut it by our friends at Sledgehammer. with Hindsight i wish i had listened to the underlying reason for this feedback and not the feedback they gave per say as the Turret was the scissors in our game of rock paper scissors.
The Turret would rapidly deplete the health of any possessed host after a short telegraph period as it locked on and prepared to fire. The Turret was only line of sight operated and could not follow the player once outside of a host.
The Turret was only able to be disabled by a scientist performing a takedown on the turret or by shooting the targeting sensor enough that it breaks, making the shot placement count as you had to shoot the weakspot or be in the right kind of host to perform the takedown.
As the turret couldn't be possessed it made for an enemy type you had to deal with and due to it's effectiveness once firing made it a priority. It was sorely missed in the final product in my opinion and is my greatest regret and lesson from this project, sometimes you need to stand your ground when you know it's in the best interest of the game but have strong reasoning/evidence and a plan to mitigate the underlying concern..
Double Barreled Shotgun
The Double Barreled Shotgun was a design homage to Doom and the modern Wolfenstein games.
To me a fast paced action shooter or "Boomber Shooter" isn't complete with two smoking barrels.
Whilst always on the wishlist this wasn;t part of our original scope but with a few of the artists and programmers ahead really early in the project and having cut the turrets I needed something that was fairly quick and used existing systems and assets to fill in the blank spot that was missing in the combat puzzle and the Double Barrel shotgun seemed to fit.
So I greenlit the weapon artist, who was very ahead of schedule, to blockout a shotgun from a photoshop mock up I threw together. This was incredibly successful and was looking like we were going to have a soldier variant with a colour swap texture as a rushing enemy but with other artists and programmers falling behind and the behaviour system being revamped this was again cut.
I likely shouldn't have greenlit us working on it at all and tried to get the rest of the content done and polished before additions but i knew i needed something else which was the reasoning behind my decision making.
Boss Battle
The Boss Battle was design for our initial pitch to the lecturers where they said to reduced scope so it was cut among other aspects and it was moved to our only listed stretch goal.
The Boss Battle would be introduced in our final arena and would allow me to show of my cinematic skills with a cut-scene as the security robot came through the Portal. It would also act as the final challenge of the level with a mobile enemy that could not be possessed by the player and had to be destroyed by targeting an explosive canister on its back.
The thinking was this was the introduction of a new enemy type that would later appear as part of the regular rogues gallery of enemies but was used as a boss battle for it;s introduction, something that is frequent in DOOM and Wolfentstein games.
We were given an extra artist at the start of the project which we hadn't planned for, they were a hard surface artists who we had been told was good with Robots so we greenlit this feature and then struggled with creative differences and skill level of the artist.
we eventually move them onto props and used another artist to work on this concept and the mesh before realising it was better to cut our losses here with minimal loss of time to the artist who jumped across to save this.
Whilst I would have loved to have these enemies and that badass cut-scene on my portfolio and to have that extra lever to use to give the game it;s sense of combat chess i knew that it was better to cut this even thought it would be one of the first things i'd add if I was to ever turn this concept into a fully fledged single player experience.
Prototyping
Prototyping for this game began well before we pitched it for the Keystone Project. We knew it was ambitious but had a solid core loop and if we could get that core loop feeling good it would put us in a great place for Game Dev Jobs.
So we started working on this along side projects we were doing in scool getting the behaviour system, and a basic prototype of the 2 controllers (Pariah & Host) and host swapping done early.
We then had multiple people of our Keystone team end up on another group project for the VR unit of study (Bellum Apperatus) which was unfortunately using deprecated hardware and software. This was a stroke of luck as we didn;t select these teams, so we decided to use it as a test platform for several mechanics we wanted to get into the Keystone project, namely explosive barrels that chain together and have physics.
Although we had to actually cut this due to performance issues toward the end of the game's development cycle using that game as a test helped us figure out how to get the controllers and gunplay working really well in time for the all important industry pitch.
The success of this pitch allowed us to be able to form relationships with some of those industry developers to get feedback at every milestone, which was a gamble, if we succeeded we will have made a name for ourselves with industry insiders, fail and we might be shooting ourselves in the foot.
We decided upon prototyping systems individually then adding them together also had the effect that we never had any serious issues with our git repo as we all adhered to our branch system. Working remotely for the majority of the project due to covid we manage to avoid all repo/commit issues due to how we prototyped/communicated between myself, as the sole designer, and the 3 programmers implementing the designs.
POST-MORTEM IMPROVEMENTS IDEAS
Removal of Death Incarnate Mechanic
One of the Mechanics I inherited from the Programmer who pitched the idea to me was the Death Incarnate mechanic and I was told it was one of 2 non-nonnegotiable mechanics that must make it into the final product.
The Mechanic was a charged AOE attack where players would be able to detonate the host they were in and kill all nearby hosts
From about half way through the project I did go back to them and ask if it was still a non-negotiable item as even early on it never felt good to use, it'd have to be used in a horde mode which was his original intent for the game but as as we gathered our team decided that that wasn't best for all of our personal development/talents.
But as it was a non-negotiable I had to try to make it fun in the game we were making... and in this respect I failed and wish I had spent the time elsewhere.
If I had to make it work the shotgun soldiers were going to be my only real hope of selling it. Having them come at you and be devastating at close range with other enemies holding back just outside the Death Incarnate kill range.
However with the behaviour system and lighting issues taking up time and stopping the guard/hold position behaviour from making it into the final product it was almost impossible for me to make it fun as you either killed all enemies near you or never felt the need.
The fact the double barreled shotgun was a a stretch goal which we actual greenlit when were super ahead early in the project but the later cut as a few issues arose showed that I tried to save this mechanic but i'm still not sure I'd add it back if i were to return for a full single player experience on this concept.
Reactivation of Turrets & Better Puzzles
One of the Cut aspects I truly wish we hadn't cut was the turret as it was part of my original design to have the rock paper scissors gameplay and if you take out the scissors in that game it doesn't work at all.
The cut was done at the suggestion of the industry panel and as we'd signed on devs at Sledgehammer to give feedback ignoring it ouright was not something i was prepared to. But looking back at the game now I feel that with the scientists lacking the ability to interact with the turret or turret controls mean the paper of the soldier was really the only choice in combat as it won out every time.
This also mean that puzzles only used the vents which mean that they were all essentially the same and needed additional elements that i could add together in different ways to make unique puzzles between the combat arenas. The pacing felt that the incidental spaces between each arena were largely forgettable.
Top the left I have some of the puzzle sketches used during my original pitch to the lecturers for greenlighting the pre-production on the project.
These with more crouch sliding and the the additional of laser gates (see below) I think I could have really improved the puzzles between the combat arenas and made better arenas with their additions into arena combat as well.
In Hindsight I would have taken their feedback on board but only at the base level which was about scope and I would have reduced it elsewhere whilst keeping the rock, paper, scissors gameplay that was essential to the combat chess I was going for.
Behaviour System Overhaul
We had some tech issues with our AI behaviour system and lost multiple behaviours that I was relying on to make the enmy AI work as part of my combat chess.
This meant that multiple aspects of my intended enemy design didn't really end up working without that feature such as the vent system as really didn't work any more without the guard nodes and was never used by players in combat as it was originally intended.
We ended up having to pivot to an entirely node based system which also excluded the VIP nodes. With this restart of the behaviour system having less features and only using nodes the AI no longer had the same dynamic feeling as they would all rush to the node they had choose ignoring you standing in front of them.
This lack of AI abilities felt very obvious in the final arena.
Knowing what I do now I would have like to have solved this a different way much earlier with a VIP nodes, distance from player and rush behaviours only rather than waiting on tech that ultimately never came and then dealing with whatever we could whip up in time for our deadline.
Add Laser Gates
The Elevator Puzzle didn't end up working as the player could remain in their original host. I needed a way to kill the host the host in the elevator on the way down so the player is forced to evacuate that host and enter into a new one inside the final arena.
I test a bunch of ideas but none worked, only after we had finished the project I figured out that we could have had a laser gate that the ethereal being can pass through but not hosts.
This would also have made for a good puzzle early on as well as an introduction to the gates and reinforce host jumping.
These gates could have also been used in arenas toward the end of the level to increase the difficulty without more enemies.
