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 →

Responsibilities

1. Overhauled enemy racer AI and decreased boredom

Result: Kept the players in the flow channel throughout all 10 levels by completely overhauling the enemy racer AI behavior.

This ultimately helped increase avg player retention.
Problem: Players immediately got bored because enemy racers fall behind early and never catch up, making winning feel guaranteed.

(The moment I played the game, I noticed this glaring problem)
Cause: The enemy racers (AI) behavior accelerates at a fixed pace (always slower than the player's acceleration).
Solution: I mapped the enemy racer AI behavior based on how well the player is performing. So the player feels like it's a close race, but they can either win or lose, which creates excitement.

Here is my process:

1. I mapped the enemy racer AI behavior based on how the level progression (similar to a beat sheet), so sometimes the players feel like they’re winning sometimes feels like they’re losing, but either outcome is possible.

(My flowchart with pre-determined racer (AI) behavior mapped to the progression for the first 3 levels)

2. Got implementation feedback from game programmer (Hamza) and collaborated towards an idea which creates the same results with half of the work.

3. Pivoted from mapping enemy racer behavior to level progression to react to the players performance based on the following rules:

NPC Rules
If the player is
Then enemy racers
Rule 1:
Far Ahead
Rapidly catch up
Rule 2:
Closely Ahead
Gradually take the lead
Rule 3:
Far Behind
Rapidly slow down
Rule 4:
Closely Behind
Gradually fall back

4. Playtested the results to get a feel for whether the design was impactful enough

2. 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 with traffic left players stuck in an awkward deadlock, dragging out downtime and delaying their return to engaging gameplay.
Cause: Crashing into traffic trapped players in place, and accelerating back to high speeds took too long.
Solution: I made traffic cars get pushed aside and disappear on impact, and I adjusted acceleration curves to help players recover speed faster.

Here is my process:


1. To get the player upto… SPEED, I tuned acceleration graphs for each of the car’s gears to stay in lower gears shorter. My readability of the graphs allowed me to directly visualize their gameplay, so I did this myself in the editor.

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

3. As for time spent bumping against the traffic car, I reduced that to an instant by pushing it out of the player’s way, and then dissipating it after a delay – fading it out of the moment.

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

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.

Here is my process

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. Merged different game modes and their systems

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.

Here is my process

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:

5. 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 is 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.

Here is my process

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.

6. 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 while fully immersed in the game's sense of speedy thrill. This increased player retention and reviews.
Design: I added satisfying speed boost pickups that allowed the player to achieve a high score at their own pace, at a difficulty they were looking for.
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.

Here is my process

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.

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.

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

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.

Responsibilities