Carrom Legends
Bringing the classic carrom experience to mobile, with support for up to four players.
A quick look at a live match — aiming, striking, and pocketing.
The Spark
Carrom has always been a game I enjoyed playing with friends, but I noticed a gap in the mobile experience: major carrom titles largely focused on two-player matches, while other classic board games offered four-player gameplay. I decided to build Carrom Legends to bring that familiar, social experience to mobile, combining support for up to four players with a clean interface and a premium visual style.
Project Brief
Carrom Legends is a mobile adaptation of the classic tabletop game, built in Unity with C#. The goal was to preserve the familiar mechanics of carrom while making the experience approachable, visually refined, and easy to navigate.
The core loop
Choose a game mode and ruleset → Configure the match → Take turns aiming and striking → Pocket coins → Score and progress through the match.
Game modes
Audience
Casual players and carrom enthusiasts across age groups, particularly people who want to enjoy the game with friends or practise against AI.
The interface follows a simple, screen-based navigation structure: Play, Practice, and Profile. Play was prioritised for the initial release, while Practice remained marked as coming soon.
My Role & Responsibilities
I independently developed Carrom Legends from concept to Play Store release, covering the complete development cycle.
- Game design: Defined the core gameplay loop, supported player configurations, match modes, and rulesets.
- UI/UX design: Planned the screen flow and built a clean, accessible interface for mobile users.
- Gameplay programming: Implemented striker controls, coin interactions, pocket detection, turn management, scoring, and match rules.
- System architecture: Organised gameplay into modular systems connected through event channels to reduce direct dependencies.
- AI programming: Developed board-aware bot shot selection, with distance-based candidate ranking and rule-aware decisions.
- Audio integration: Selected sound effects and background music, then centralised playback through a dedicated audio controller.
- Testing and release: Tested gameplay, refined the experience, prepared the Android build, and handled Google Play publishing requirements.
Development Process
Research & UI flow
I began by researching the visual direction and defining three primary navigation areas: Play, Practice, and Profile. I prioritised the playable experience first rather than delaying the initial release to complete every planned screen.
Gameplay & physics
I built the core carrom interactions around the striker, coins, collisions, and pockets. Separate gameplay components handled striker control, carrom-piece behaviour, pocket detection, turn progression, and scoring.
The main engineering challenge was making these components cooperate without coupling every gameplay script directly to every other system.
Event-driven architecture
I structured the gameplay around modular systems and ScriptableObject-style event channels. Rather than having every component directly manage the others, systems could communicate through defined events.
This separation made the gameplay easier to reason about and gave individual systems clearer responsibilities.
Making the bots think beyond random shots
The AI was one of the more interesting parts of the project. Instead of choosing arbitrary directions, the bot evaluates the board before taking a shot.
-
Board perception: Collect the available coins and their positions.
-
Pocket evaluation: Compare coin and pocket positions to calculate candidate distances.
-
Candidate ranking: Sort coin–pocket combinations by distance to prioritise promising options.
-
Controlled variation: Randomly select from the top five candidates instead of always choosing the mathematically shortest option, reducing repetitive behaviour.
-
Rule awareness: Consider the active ruleset and avoid obviously invalid colour choices in Black & White mode.
-
Queen handling: Give the queen special consideration when it is the only coin remaining, helping the bot avoid a shot that would create a foul under the applicable rules.
This approach balances simple heuristics with controlled variation. It is not a full physics-planning AI, but it produces more deliberate decisions than random shot selection.
UI/UX — Keeping the game approachable
The interface was designed around clear actions and minimal navigation friction. Players can move from the home screen to match configuration without navigating complicated menus.
The visual direction pairs a restrained layout with purple primary actions and a premium presentation. I prioritised readability and predictable interaction over adding unnecessary UI elements.
Audio — Separating sound from gameplay
I explored free online audio libraries to find suitable sound effects and background music. Playback was centralised in a dedicated AudioController, allowing gameplay systems to request sounds through a shared interface instead of managing audio responsibilities individually.
This kept the gameplay scripts cleaner and made audio settings and playback easier to manage.
Final polish & publishing
After integrating the gameplay systems, I tested match flows, controls, rules, and audio, then refined the build for release.
Publishing introduced a different set of challenges: Android build preparation, Google Play Console configuration, testing tracks, age-rating requirements, and policy declarations. It was my first experience taking a game through the store's testing and release process.
Results
Google Play
Carrom Legends progressed from a personal idea to a publicly available Android game, reaching real players beyond my local development environment.
The result was not only a playable product, but also a complete release experience covering gameplay engineering, interface design, AI behaviour, audio integration, testing, and distribution.
Retrospective
Carrom Legends taught me that building a game and shipping a game are two different responsibilities. A mechanic can work perfectly in the Unity Editor, but releasing it to real players introduces new expectations around usability, device behaviour, testing, and store compliance.
I also learned the value of designing systems around clear responsibilities. The event-driven approach helped separate gameplay concerns, while the bot AI showed me how even simple perception and decision-making heuristics can make an opponent feel more intentional.
If I revisit the project, I would put more emphasis on systematic device testing and gameplay performance validation earlier in development, rather than treating them primarily as final-release concerns. I would also use player feedback and gameplay analytics to prioritise the next improvements instead of relying only on my own testing.