DDExtreme | Vadim Borovskoi

4 Designers, 6 Artists,

4 Programmers

Mobile

Online Co-Op

22 Jan - 16 Feb '24

Tools Used

Game overview

DDExtreme is a semi-realistic arcade racing game which has 2 players end up in the same tiny boat and race against time in the tricky swamps of Australia.

The game is based on an existing extreme sport, with one racer being in charge of operating the lever of the engine (Skipper/Driver), and another racer (Navigator) using the weight of their body to make maneuvering easier.

On top of the boat simulation, add speed boosters and force shields, and you’ll get the ultimate mobile racing experience! (How does it sound?)

2 players 1 boat

Vehicle Design & Documentation

After having settled on a chosen sport, the team defined the player experience that we wanted to achieve

Speed is Everything

Players should get extreme satisfaction from keeping the momentum

Arcade with a pinch of Realism

The game should focus on casual target audience
Controlling the boat should be playful

Greed is a Sin

Releasing the gas pedal should be a good choice sometimes

Players are Equally Important

No distinct leader of the group

The latter pillar became a primary challenge for me straight away.

The Driver's role reminds of the classical racing gameplay, while the Navigator was a complete grey area.

To reach to the core of the Navigator's role, I used my teammates’ insight (shoutout to Basil’s knowledge of water physics and Patryk’s memory of old-school games) and looked deeper into the selected sport & potential game references.

Driver's Role

Start and End the boat's movement (!)

Steer the boat

The Driver can finish the race themselves (!)

(Hover to see the Spoilers)

Navigator's Role

?

Activate the collected Power-Ups

Change the Max-Speed & Acceleration of the Boat

Add Steering Potential to the Boat

The Navigator makes sure the race is mastered (!)

After a pretty chaotic brainstorming process & getting the degree in water physics (I rather failed, though), I created a matrix of

how the player's cooperation would affect the vehicle.

Then, I simplified & systematized the parameters of the boat which the players could impact.

This Documentation became a source of communication between me and the boat programmer - we agreed on what parameters would be later available to tweak, with the physics calculations taking place behind the curtains.

2 players 2 controls

Controls Design & Documentation

Having decided on the vertical phone positioning, as well as the established pillars, led me to these principles when designing controls

Playable with 1 Thumb

And the controls should not cover important parts of the screen

No Going Back

Both players can only go forward, steer, and release their controls

Sell the Fantasy

Controls have to feel smooth and have the players immediately understand their role

The driver

It felt natural to make the controls stylized as the actual lever
A rule was introduced for the character on the level of controls – the Driver can steer only when they accelerate.

"Arcady" lever controls

"Realistic" lever controls

"Arcady" lever controls

1/2

My documentation of 2 versions of Lever controls

In-game Lever controls

Pipeline

Slider as the initial prototype - made by programmers

Lever's art asset - created by Lena

Bigger slider as the final solution - programmed by Filip

The Navigator

The main goal was to visualize their movement inside the boat while also emphasizing the discrete nature of their actions. I suggested 2 versions of the navigator’s controls.
The designers agreed on the combined approach, and I also added a power-up button in the middle of the construction

Navigator's Base Controls

Navigator's "Joystick" controls

Navigator's Base Controls

1/2

My documentation of 2 versions of Navigator controls

In-game Navigator controls

Pipeline

An artsy sketch of Navigator controls - made by me

Navigator's art asset - created by Lena

The hidden joystick lets slide along buttons - shoutout to Basil

2 problems 1 solution

Camera Design & Implementation

During the production, issues with the physics engine began to arise. We couldn’t have the boat’s physics provide predictable outcomes, and it was almost impossible to tweak the values and fulfill the initial design without breaking the fragile realism.

The Navigator’s functionality suffered the most from the problems with physics. Two significant issues arose

The impact of the Navigator was barely comprehensible & insignificant.

The game did not feel fast, with the highest parameters that the designer team could balance.

I am a huge fan of the concept of dual-purpose design. Some great designers suggested that good solutions are the ones which solve multiple problems. I got inspired by it this time and decided to experiment a bit.

The initial version of the camera was supposed to have a slight lag which, in essence, meant that it would have zoomed-in and -out based on the boat’s velocity.