Picture of LUQMAN AZEEM

LUQMAN AZEEM

Game Designer

Contact

Racing Ferocity

  • Google Play Store Metrics:
(4.2/5 of 196k Reviews)
  • 100M+
Downloads
  • Genre: Racing / Arcade / Casual
  • Type: Mobile
  • Studio: Terafort
  • Team Size: 7
  • Engine: Unity
  • Role: Game Designer
See on Google Play →

1. Merged different game modes and their systems to increase novelty

Result: Made the content feel more polished and exciting, increasing avg playtime by 20 seconds for 100k daily active players, via a new game loop.
Problem: The abundance of unpolished content in the different game modes was causing a lack of retention.
Cause: Lack of game feel and elements that captured the fantasy of driving at high speeds.
Solution: I created a mock-up animation of faked gameplay, demonstrating what screenshake would look like when designed with finesse.
(Preview of the entire process detailed below)

1. I did a first pass on fleshing out the Pursuit encounter, listing possible triggers and success/failure criteria

Phase 2: Encounter Trigger System

1. First, I had to figure out how the quest was going to trigger in the heat of the fast-paced gameplay. I dug into the quest’s narrative themes for that, researching some inspirational gameplay from other racing game pursuits.

2. This lead to my discovery of the quest transition system: speed cameras. It fit well with the gameplay too, since if the player was driving at high speeds already – they needed a bigger challenge.

Phase 3: I based the encounter around action and combat. To do that,

1. I created a combat system and revamped enemy behavior. This obviously meant that the player could lose the combat encounter, and in turn also lead to game over.

The leadership was concerned with loss condition will increase player churn.

2. Brainstormed alternative solutions to make sure the loss condition doesn’t lead to game over to retain the players. I referred to the Cop Chase narrative to discover a penalty for the player.

Rough brainstorm on potential features with the Pursuit encounter

3. Redesigned the penalty to speeding ticket that deducted a % of the player’s earnings. It was a justifiably punishing condition that directly fueled the players’ motivation to win the encounter.

4. To introduce some exciting narrative elements into this encounter, I designed the cop character to be an over-the-top, goal-driven anti-hero.

<em>A breakdown of all the different story beats for the cutscene</em>

5. This led to the intro sequence. The cop car jumps out of an aggressive looking flying plane, to chase you down.

6. Final cutscene sequence:

2. Redesigned the pursuit encounter to reduce player churn

Result: The combat made the encounter exciting while using minimal development time. It allowed the modes to be merged together, reducing player churn.
Problem: The feel of the enemy AI and interactions for action-esque Killer Cop narrative was boring and causing churn.
Cause: Rules for a combat system needed to be designed and shaped to fit into the game's existing systems.
Solution: I designed collision-based damage and made the Killer Cop behave aggressively.
(Preview of the entire process detailed below)

Phase 1: AI Navigation System
1. For Killer Cop’s Navigation system, I repurposed the Racer AI Navigation system that I designed for the Race mode, by doing some tweaks.

2. I tuned it’s acceleration criterias to reactively and closely loom around the player. I relied on this heavily to create the illusion of aggression, since a design constraint was to avoid actively bringing about game over.

Phase 2: Damage Mechanic
1. I introduced a health stat for Killer Cop and designed it to be damaged through collisions.

2. To avoid complexity and scope creep, I designed discrete collision reactions rather than allowing physics to take control of the health. Starting with a simple damage on collision, I iteratively added further collision reactions to Killer Cop.

3. Ultimately, this shaped up to be 2 types of reactions for each of the both head-to-tail collisions and side-to-side collisions.

4. I also ended up damaging the cop whenever it rubbed across a body, to remove the frustration from interlocking collisions and incentivize it instead.

3. Implemented screenshake to improve immersion

Result: The gameplay feel was satisfying and captured the speedy thrill feel of high speed driving, boosting player retention.
Problem: The gameplay felt monotonous regardless of how much the car sped up, making it feel less challenging in spite of the difficulty of the encounters.
Cause: Lack of game feel and elements that captured the fantasy of driving at high speeds.
Solution: I created a mock-up animation of faked gameplay, demonstrating what screenshake would look like when designed with finesse.
(Preview of the entire process detailed below)

Phase 1: Timeline prototype to get team buy-in
1. When I pitched the feature to the team, they had a strong negative perception on it. Their previous attempts led to user feedback that the car felt jittery rather than satisfying.

2. I started creating a prototype mockup to enlighten them, without spending the time to develop the feature. I added a start position and an end position for the player car, to animate through some time.

3. Then I did the same thing for the traffic cars, only through a smaller gap to make them move slower. This was enough to create fake gameplay.

4. I similarly moved the camera diagonally over a very short period, looping it throughout the timeline. This resulted in the shake.

5. I layered another animation that still shook the camera, but only slowly and over a much wider gap. This created a cinematic sway/hand-movement.

Phase 2: Documentation, implemenation, and iteration

1. After the team was fully sold on this, I documented the parts of the gameplay where screenshake was to be added, alongside it’s rough parameters.

(Document pointing out all the points for screenshake with its respective economy design direction)

2. Collaborated with the programmer to implement it, going through rapid iterations to perfect the feel that looks like this:

vs

3. We also added a few interesting dynamics to the mix (like changing the intensity based on car speed) to make screenshake feel more reactive to gameplay.

4. Designed speed boosts to keep players satisfied and in flow

Result: The players were driven to achieve new high scores because they were kept in the flow channel alongside a taste of speedy thrill.

This increased player retention and reviews.
Design: I added speed boost pickups that allowed the player to achieve a high score at their own pace, at their desired difficulty.
Before: The game felt boring after a certain point because the traffic obstacles weren't difficult enough of a challenge anymore.
Problem: Player car eventually reached a max speed so the steady stream of traffic wasn't difficult to avoid.
(Preview of the entire process detailed below)

Phase 1: Coin pickup redesign
1. I was working on a different design problem: the immersion-breaking and unclear coin pickups. When picked up, they vanished without a trace, as their irritating sound effect played

2. For the redesign, I introduced a temporary burst of speed on each pickup, increasing camera Field-of-View to add the feeling of the boost.

(Simplified visualization of gameplay with speed boosts)

Phase 2: Affording speed pickup chains
1. Boosting through coins as an activity itself was quite fun. Playtests somehow encouraged chaining speed boost pickups with the upcoming set of pickups.

(Players attempted to chain speed boost clusters)

2. I extended the time it took to return to normal speed, so players could chain them them together.

(Before tuning boost-related metrics vs after tuning boost related metrics)

3. The player would lose the speed equally as fast as they gained it. So whenever they couldn’t steer comfortably towards the next set – they would lose the chain anyways. This created a natural return to the default intensity of the difficulty.

5. Reworked racing gameplay systems to improve immersion

Result: Even losing felt satisfying but also immediately put the player back in action, ultimately reducing player churn by keeping the player in flow.
Problem: Bumping into enemies left players stuck in an awkward deadlock, killing momentum by creating too much downtime.
Cause: Crashing into enemies created a deadlock with them. Meanwhile, regaining momentum by accelerating back to high speeds, took way too long.
Solution: I made enemies bounce away on impact and slowly disappear. I adjusted acceleration curves to help players recover speed faster.

1. To get the player upto… SPEED, I tuned acceleration graphs for each of the car’s gears to stay in slower gears shorter. My familiarity with animation curves enabled me to plot them out exactly as I wanted to perceive the gameplay, so I did this myself in Unity’s editor.

2. Then I tuned the faster gear graphs to stay in those for longer, so that there was no point where driving felt monotonous.

(Approximation of how I tuned it inside Unity)

3. As for time in the deadlock against the NPCs, “Non Player Vehicles”, I reduced that to an instant by pushing it out of the player’s way, and then dissipating it after a delay – making it disappear slowly.

4. Playtested the emerging gameplay to verify whether the gameplay felt more satisfying.

Responsibilities