Actual local development capture
01 / Rickshaw Rush
The challenge
Make a three-wheeled rickshaw feel responsive on a phone while giving Dhaka’s streets a recognizable identity.
Reading the problem / Rickshaw Rush
The player has to read the road and the response.
Vehicle physics, traffic and mobile input share the player’s attention. Controls and HUD feedback need clear priorities.
Dhaka-inspired racing combines vehicle physics, traffic and mobile-first input. The published game link and development visuals define the project scope.
How can mobile controls communicate vehicle behavior without competing with the race?
Evidence: the project account and the attributed artifacts on this page. Process drawings and interaction studies are reconstructed explanations; numerical research or business results are included only where separately supported.
02 / Rickshaw Rush
The approach
Three WheelColliders support the vehicle controller, with anti-roll, speed-sensitive steering and configurable handling. A spline-based track, chase camera and race systems connect the driving loop. Editor generators rebuild maps, prefabs and mobile settings. The agentic workflow connects scoped subagent tasks to editor validation jobs, gameplay captures and device smoke scripts. Automated checks cover defined scenarios; manual review remains part of the workflow.
03 / Rickshaw Rush
My contribution
- Game design at Ridmik Labs for the Hatirjheel driving experience: player controls, HUD and feedback, explored through Unity prototypes.
- Vehicle handling, touch and tilt controls, drifting, boost and recovery behavior.
- Race checkpoints, traffic, passenger rides, HUD and reusable configuration assets.
- Blender-to-Unity environment workflows and iteration using Android and iOS device captures.
- Agentic development workflow PoC: multiple subagents coordinate scoped implementation, asset generation and validation.
- Automated editor jobs, autonomous scripted testing, Play Mode validation and screenshot review support repeatable checks.
The process / Rickshaw Rush
A direction.
A way to build it.
The race loop joins mobile control, vehicle response and clear feedback in a moving Dhaka-inspired environment.
A schematic of sequence and overlap, not a dated project schedule.
Frame the player’s attention
Decide what the player must learn before the road and traffic become the focus.
Define control and feedback
Connect input, vehicle behavior and the HUD information that cannot be inferred from motion.
Explore the playable loop
Iterate on Unity gameplay, traffic context and mobile-first interaction.
Review the run and recovery
Inspect what a new player understands after a collision, finish or restart.
How can mobile controls communicate vehicle behavior without competing with the race?
A new player enters a Dhaka-inspired race while vehicle behavior and traffic compete for attention. The interface should help establish control, then recede enough for the road to become the focus. Results and recovery belong to the rhythm of another run.
Journey map / Rickshaw Rush
See the whole task in context.
Choose a step to connect the person’s intent with the interface and the design decision.
Current intent
Enter the race
Dhaka-inspired racing combines vehicle physics, traffic and mobile-first input. The published game link and development visuals define the project scope.
- Interface context
- Race entry
- Review question
- Which feedback belongs on the HUD and which should be communicated through the vehicle or environment?
Representative task sequence and recovery path, not a measured emotional curve or historical research map.
Behind the experience
A playable moment needs a connected system.
For Rickshaw Rush, this map connects “Enter the race” to “Review the run”. Read across to follow the task, then select a layer to inspect the interface, design and delivery references behind it.
| Layer | Enter the race | Learn the controls | Navigate traffic | Review the run |
|---|---|---|---|---|
| The task | Enter the race | Learn the controls | Navigate traffic | Review the run |
| Visible interface | Race entry | Race entry | Gameplay HUD | Run results |
| Design checkpoint | Dhaka-inspired racing combines vehicle physics, traffic and mobile-first input. The published game link and development visuals define the project scope. | Introduce the run and the relevant controls. | Protect the view of the road during active play. | Explain the run result and make recovery accessible. |
| Implementation reference | Decide what the player must learn before the road and traffic become the focus. | Connect input, vehicle behavior and the HUD information that cannot be inferred from motion. | Iterate on Unity gameplay, traffic context and mobile-first interaction. | Inspect what a new player understands after a collision, finish or restart. |
| Recovery | Collision or failed run → give clear feedback → offer a restart | |||
A reconstructed delivery map: the implementation row summarizes design-process dependencies, rather than claiming to document the original backend architecture.
Combine game feel with selective HUD signals.
Reconstructed comparison of design approaches. These are review studies, not a claim that both directions were historically tested or shipped.
What this direction changes
Combine game feel with selective HUD signals
Lets motion communicate vehicle behavior while the screen carries essential state.
Use the HUD to support the race, not explain everything.
The entry, gameplay and results studies allocate different amounts of information to different moments. Setup can introduce the activity; play needs immediate, legible feedback; the result view can explain the run and offer a restart. Putting all three responsibilities on the racing screen would overload it.
01 / Race entry
Race entry
←Learn the controls→
Learn the controls
Introduce the run and the relevant controls.
02 / Gameplay HUD
Gameplay HUD
←Navigate traffic→
Navigate traffic
Protect the view of the road during active play.
03 / Run results
Run results
←Review the run→
Review the run
Explain the run result and make recovery accessible.
Try the interaction
Rickshaw Rush / Control & feedback study
Rickshaw Rush01 / 03
View 01
Race entry
Introduce the run and the relevant controls.
◈
Illustrative input-to-feedback relationship, not a simulation of the game’s physics.
Starting context
Enter the race
Race feedback has to survive a moving background.
Prioritize race feedback, control labels and result information. HUD text needs to remain readable against moving scenery.
Illustrative type-role specimenRickshaw Rush
Enter the race.
Review the run.
HeadingGameplay HUD
24 / 30 px · regularBodyHow can mobile controls communicate vehicle behavior without competing with the race?
16 / 26 px · regularLabelReview the run
12 / 18 px · regularStateCollision or failed run → give clear feedback → offer a restart
12 / 18 px · regularPortfolio-font hierarchy illustration; the source does not establish the exact client font or token scale.
Choose between interface feedback and game feel.
Which feedback belongs on the HUD and which should be communicated through the vehicle or environment?
Some vehicle information is better communicated through motion and environmental response than another HUD label. The screen should reserve its strongest signals for information the player cannot infer from the race.
How quickly can a new player understand steering, progress and recovery?
A first run needs a legible relationship between input and response. Steering feedback and recovery should support learning the vehicle rather than adding instructions that obscure the road.
Specify controls through playable behavior.
My contribution is game design at Ridmik Labs, using Unity prototypes to evaluate controls, player feedback and the HUD. A gameplay handoff needs to describe the control, vehicle response, traffic context and feedback together. A static HUD mockup alone cannot communicate the feel of steering through a run.
When using agents to support a gameplay change, keep the request specific to the control or feedback behavior being adjusted. Review the playable result and development capture before extending a change across the racing loop.
Rickshaw Rush has a Google Play listing; promotional artwork remains distinct from actual development captures.
Accessibility & standards
Access belongs in the design.
For Rickshaw Rush, carry accessibility requirements from the core user journey into component states, prototypes and engineering acceptance criteria.
WCAG 2.2 AA · EN 301 549 · APCA · WAI-ARIA · Platform guidance
Keep controls and feedback understandable
Review control discovery, remapping or alternative inputs, HUD scale and redundant visual/audio cues. Explain failure and recovery without relying on color alone.
Protect readability and motion comfort
Assess menus and HUD against relevant WCAG 2.2 AA criteria; use APCA as an additional text-readability tool. Plan reduced camera motion and non-flashing feedback.
Evaluate the playable experience separately
Use native platform accessibility guidance and player testing for gameplay. A readable menu does not establish accessibility of every mechanic, input method or device.
Review scope & standards references
These are design references and review priorities, not a claim that this historical project passed a WCAG audit. Record criterion-level evidence, assistive-technology and device results, unresolved issues and retest outcomes before making a conformance statement.
APCA supplements the WCAG 2.2 contrast checks; it does not replace them. WCAG 3 remains a draft. EN 301 549 v4.1.1 is the latest published edition checked on 6 November 2026; its publication and its formal EU legal citation are separate matters. Confirm the applicable procurement or legal baseline with the client.
Outcomes & scope
What the work delivers.
- The Android game has a public Google Play listing. The accompanying development image is a local capture; the current Hatirjheel build may differ from the store version.
Results are described within the documented project scope. Illustrative studies are identified separately from original project artifacts.
Review & next iteration
What needs to hold up in use.
Use these questions to review Rickshaw Rush against the behavior the design is intended to support.
- 01
Can a new player connect steering input to vehicle response?
- 02
Is the restart path clear after a collision or failed run?
Project-specific acceptance questions for a future review, not reported usability-test results.
Reflection / Rickshaw Rush
What I’d carry forward.
The city gives the game its character; readable controls make that character playable. Continued tuning should protect feedback and control clarity while the scene becomes busier.