Project Ghostrunner
Project Ghostrunner is a third-person sci-fi action runner game where you play as a cyberhuman and must navigate the facility by running faster and avoiding enemies by using various cyberkinetic abilities.
Here is the link to the GDD of the game.
Project Ghostrunner GDD
Prototype Gameplay
Conceptualisation and Prototyping Process
This is an untitled game (codename “Project Ghostrunner”). Here is my thought process while creating this game.
While learning to create a character controller in Unity, I wanted to develop a game centered around this character (Alien soldier from Mixamo). I started to prototype; however, I had many constraints.
​​
Initial constraints
​
-
Must use Unity.
-
Prototype-level programming skill.
-
The theme of the game must fit the player model (Alien model from Mixamo), like a cyberpunk setting.
-
Must be a single-player action game.
-
Must have AI enemies.
-
No Melee combat (Requires motion warping, slowdown effects, camera and visual effects)
and the player must not physically interact with other enemies. -
No shooting (Requires advanced AI behaviour and additional effects as mentioned above).
​
So I initialised the game around the player running away from enemies.
I created a base enemy called cyber ninja that spawned at a spawn point and had a chase radius.
If the player entered the radius, the enemy would chase the player until the player is killed (one shot if the player entered its attack sector) or leaves the range, after which the base enemy would return to its spawn point.
Also added a boost bar that would boost the speed of the player before it ran out.​​​​
Results
The game didn't offer any tactical skill expression that I hoped for; it felt like mindless running.
​​​​​​​​​​​​​​Iteration 1
​
Enemies could not chase the player out of their confined area; the boost bar generates if the player is idle. Added platforming, and on every platform, there would be enemies.
Results
Still felt almost the same, and the platforming broke the pace of running, and running was the main focus of the game.
Conclusion
Core design had to be changed, the linear path made it feel lackluster and void of tactical skill expression. I had to direct the player's movement through different paths and add breadcrumbs to the level.
Iteration 2
Added energy orbs, items scattered throughout the level which the player had to collect the finish the level.
​
Results
The player had a clear objective, and it was more intuitive to play. Placing orbs close to enemies made he player choose between collecting the orbs and risking being killed or distracting the enemy away from the orb and then collecting it. Also, enemies seem to have a harder time following the player if they keep turning; therefore, turning away can help lose the enemy, but be difficult to collect orbs and vice-versa.
Now that the base enemy is set, my thinking went towards creating a complementary enemy to the base enemy cyber ninja.
Iteration 3
Created a new enemy, EMP Crawler, inspired by the crawling animation in Mixamo. It has a large transparent sphere around it and moves more slowly than the base enemy, and cannot kill the player.
The EMP Crawler's transparent bubble, called the EMP Bubble, and upon the player entering it, will enter an impaired state, disabling all player abilities and reducing the walking and running speed of the player. When the player exits the bubble, a timer must run out before the player regains normal functionality. The enemy is intended to work with other enemies. and help them kill the player.
To counter this, the player has a force field bar that runs out by holding the key, keeping it active, thereby providing immunity from the EMP bubble. The bar recharges when the player is idle or walking.
Results
The recovery duration seems to be too long, hence reduced its duration. It is intended that the player must find it difficult to survive being in the impaired state, but not impossible. The intention is to create tension for the player, but with enough skill and luck, the player should overcome the difficulty and return to normal.
Iteration 4
​
With a base and a supporting enemy, I wanted a stronger and more challenging enemy. Found a large enemy model in Mixamo: The Mutant.
Mechanics
The mutant has a swipe attack that functions similarly to the base enemy's, but the attack sector is larger. I wanted it to have a signature attack, so I added a jump attack for the mutant.
The mutant has a min and max jump attack radius and would be able to attack the player only when they are in between them, and the jump attack happens randomly within a certain time range. When the jump attack starts, the mutant tracks down the player in the air and lands on them with the jump attack that can only be avoided with a timed dodge. (Green Circles indicate the Min & Max jump radius).
Results
Since the max jump attack radius is long, and the time of the jump attack is unpredictable, it creates a sense of tension within the player if they come close enough to the mutant and don't necessarily trigger the enemy chase. The jump attack's dodge time is indicated by an audio cue, which acts like a warning signal. Players are intended to always be ready to dodge, and slowly build up tension, and when they do, it feels huge.
​
This was inspired by the Souls games, but the way the mechanics are used varies.
​
In the Souls games, the players dodge to match the rhythms of the boss/enemy attacks, but over here, the tension is meant to build up and then release, giving players a dopamine hit.
​
The dodge mechanic is also different here, to match the flow of running and not break it, the player dodges forward with a speed acceleration, giving an effect of forward movement to help keep the flow intact. Also, dodging here means the player is committing to a direction of movement that they cannot change during the dodge and must follow a direction with no enemies in front, or they will end up dying. So, dodging is less frequent and more deliberate here.
Iteration 5
​​
With the three types of enemies available, I wanted to further improve the core loop, rather than having a dedicated speed boost bar that can run out, I made gaining speed the core of the game.
​
I wanted to make collecting orbs unlock things that will help the player since the progress in a level equates to the no. of orbs collected. After a certain threshold of orb collection, a boost point would unlock and passing through it would increase the player's speed streak, and a higher speed streak would mean more speed and make it easier to escape enemies. However, if the player stops running, then the speed streak is reset, giving players pressure to maintain their streak. The boost points must be used to increment the streak. Also, after the collection of all energy orbs, a Giga Orb would spawn, which would be required to complete the level.
Results
The speed boost feels like a satisfying reward and indicates the player's progression in the level; however, since the players had to use speed boosts in a specified order, it made the level a little too linear and stripped away player choice. Therefore, made changes such that the speed boost can be taken in any order.​​​​​​
Iteration 6
​
At this stage, the player seems to have few abilities, so I wanted another ability tied to the collection of energy orbs and the fact that the player can't fight back. I created a shock ability that is tied to the force field of the player. The player has to use the force field to activate the shock radius. When the shock ability is used, the enemies within the radius are temporarily stunned. However, the mutant cannot be shocked, making its presence in the game bigger.
Results
​​
Although there is no combat per se, the player can manage enemies through their abilities and the player can strategise and shock a group of enemies in an area.
Iteration 7
​
Now that the core loop is in its bare bones, I wanted to add another enemy that would test the player's core skill of evading enemies and since the player can now run faster using boost points, making it easier. I introduced a new enemy, the swift. This enemy will increase its speed with respect to the player's speed streak. It has better tracking and is far closer to the player's speed than the cyber ninja. Also, its attack radius is small since the enemy often gets close to the player while running. Also, this enemy will stop chasing the player under these three conditions: player dies, it gets shocked, and when the player crosses its leave range (which is much larger than the chase range).
Results
The swift provides more tension, making higher speed streak gameplay intense. Players generally shock them so that there's little resistance during the higher streaks.
Iteration 8
​
Level 1
​
I felt it was high time that I created a few beginner levels to see what I had created so far in action, so I sketched a layout (Blue for Orbs, Purple for cyber ninja enemies).
My idea was to have 9 sections that the player had to go around, all 8 sections, and then get into the middle section, which was where the Giga Orb would be located.
Results
The level felt too grand/big, I wanted to have a smaller one level where I could strengthen the level design on a smaller scale before scaling it up.
Results
The level feels too small and restrictive, and the enemies could easily kill the player. The level was claustrophobic.
Results
Now, the space for the player to move around feels enough, and the enemies have space. The level is quite simple and easy for the player to get. feel of the layout. I made sure that the level is divided into three sections that you can never see more than one section at a time, which allows the player to construct a mind map and find it reasonably complex. During the playtest, the players died a lot, but with each attempt were slowly making more and more progress. But still, the level didn't provide a strong hook and core loop, especially because of the lack of boost points.
Level 2
Here are some of the sketches for the second level, where I wanted to add the force field mechanic and EMP crawlers. (Black circles for cyber ninja, red for EMP Crawlers, blue for orbs)
Here are the final implemented levels. The second level has three sections. After completing each section, the previous one is blocked, and the next one opens. The game saves automatically once you complete a section. Also, between each section, the player has a choice to either collect the purple orb (for extra force field points) or the transparent orb (Shrink the enemy orb size).
Section 1
Here, the player is supposed to move in a zigzag fashion. When they have to pass through the bubble, they'll use the force field, and since there's a limit, they'll have to use it sparingly. The players intended to master this route.
Section 2
Here, I tried to make the route a bit more complicated and challenging. If the player finds it difficult and keeping dying they can always choose the other orb to make it easier.
Section 3
In this section the player can take multiple routes and circle around EMP Crawlers. In case the player dies here, when they spawn back they'll have 2 set of special orbs (purple (Extra force field points) and the transparent orb (EMP Crawler shrink size)) to choose from.
What's Next
After so many iterations, playtests, and ideas, here are some of the conclusions I arrived at.
​
The game requires really good level design, and I felt someone more skilled and with experience had to take over.
The game had a lot of technical limitations and required a proper programmer who could program more advanced features, optimise, and take care of managing Unity version control.
The game lacked art direction and its unique mood and tone.
A setting and story were missing for the game.
An active QA team was required to give feedback during the development process and work out any bugs.
The game didn't have a proper marketing and launch plan (whether the game was going to be launched on Steam or itch).
The core audience and market fit were yet to be analysed.
So I put together a team of 3 people, a level designer, a programmer and a 3D artist who also happens to be a designer. The game is in the next stage of development, where the concept is fixed and has to scale into a fully fledged action game focusing on vertigo. The goal was to build up my design philosophy and learn the process of making games on a deeper level, and create innovative concepts.
I wrote the initial version of the GDD and discussed the concept and themes of the game with the team.
Iteration 9
After a discussion with the team, we decided to remove walking and force field recharge from staying idle or walking. This is because we wanted to encourage players to be in the flow state and be incentivised to increase their speed streak rather than walk or stay idle. The force field can be replenished through force field orbs. Walking didn't fit in a running game.​
This is the progress so far. The focus now is to improve the first 5-10 mins (hook) of the game.