Carrom Trick Master Project Report
1. The Concept
Carrom Trick Master is a lightweight, browser-based 2D physics challenge game inspired by classic carrom gameplay and modern casual puzzle games. Players position a striker along the baseline, aim, control shot power, and use accurate physics to pocket coins through direct shots, angled hits, rebounds, combos, and multi-shot challenges.
I chose Carrom Trick Master for this one-day sprint because the concept looks simple on the surface but requires several systems to work together correctly. The main challenge was not only building a playable carrom board, but making the shooting physics, aiming, level progression, responsive controls, and premium 2.5D presentation feel like a real game instead of a basic browser prototype.
The game was designed around short challenge levels that gradually introduce more advanced mechanics. Early levels teach direct shots and angles, while later stages use multiple coins, bank shots, chain reactions, limited shots, target-order rules, and more strategic board layouts.
2. The Stack
The Stack: HTML5, Vanilla CSS, JavaScript, HTML5 Canvas, custom 2D physics, and PNG/WebP visual assets.
The project intentionally avoided MVC architecture, frameworks, external game engines, and external physics libraries. The gameplay physics, collision handling, aiming system, level state, responsive behavior, and rendering logic were implemented directly with JavaScript.
The visual direction combines technically 2D gameplay with premium 2.5D presentation. Transparent PNG/WebP assets, polished wood textures, teal playing surfaces, gold accents, shadows, highlights, particles, and premium UI elements were used to create depth without converting the game into a true 3D project.
The AI Assist: ChatGPT handled the initial game analysis, gameplay planning, level structure, physics requirements, UI/UX direction, and technical prompting strategy. Cursor was then used for the coding phase, translating those requirements into the actual HTML, CSS, JavaScript, Canvas rendering, game logic, and project assets.
3. The 1 Day Sprint
Morning (Hours 1–3): We began by analyzing the gameplay structure of Carrom Masti Challenges and identifying what made the game satisfying: simple drag-and-release controls, predictable physics, short challenges, clear progression, and immediate feedback. From there, we created the Carrom Trick Master concept and planned the project architecture around separate JavaScript modules for game state, physics, input, rendering, levels, UI, audio, particles, and LocalStorage.
The first goal was to build one stable playable level before expanding the campaign. We focused on the core interaction flow: position the striker, pull back to aim, control shot power, release, simulate collisions, wait for all pieces to stop, and evaluate the level objective.
Afternoon (Hours 4–6): The main coding and gameplay phase focused on building and tuning the carrom board. Cursor implemented the Canvas-based board, striker, coins, pockets, collision system, friction, wall rebounds, aiming controls, and level state.
Several issues appeared during testing. The striker initially felt too weak, strong shots traveled only a short distance, and friction or damping made the gameplay feel slow. We had to review the full shot pipeline from drag distance to normalized power, initial velocity, collision momentum transfer, friction, and stopping thresholds.
Level design was another problem. Early versions relied too heavily on one- or two-shot levels, making the campaign feel repetitive and too short. We changed the progression toward larger multi-shot challenges with more coins, bank shots, chain reactions, blockers, target order, combos, and shot limits.
At the same time, we redesigned the visual style around a dark navy, teal, wood, and gold theme. The Home screen, gameplay HUD, level cards, buttons, icons, and board presentation were upgraded toward a premium 2.5D casual-game look.
The Finish Line (Hours 7–8): The final hours focused on polish and QA rather than adding more systems. We reviewed responsive layouts, gameplay power, level progression, icons, modal consistency, music, audio behavior, and visual hierarchy.
The Home screen was redesigned with a stronger Carrom Trick Master identity, a larger hero board, premium gold Play button, level access, sound controls, settings, and collection progress.
Gameplay received a larger premium board, clearer shot information, retry and pause controls, improved striker feedback, and more readable objectives. Popup designs were standardized across Victory, Failure, Pause, Settings, Rewards, Locked Levels, and other modal states.
We also added background music suitable for the game's premium carrom atmosphere and reviewed audio behavior so music could loop without restarting unnecessarily between screens.
The final pass concentrated on preventing regressions: keeping gameplay physics separate from UI changes, checking touch and mouse input, avoiding duplicate popups, preserving level progress, checking asset paths, and keeping transparent PNG/WebP artwork consistent across the game.
4. The Roadblocks
Roadblocks: The biggest difficulty was balancing physics, level design, and visual polish at the same time. A carrom game can technically work with very simple collision code, but small problems in shot power, friction, momentum transfer, or stopping behavior immediately make the game feel weak.
One major issue was that strong shots initially did not feel powerful enough. Increasing maximum power alone was not a good solution because the problem also involved damping, friction, velocity limits, and momentum transfer. The full physics pipeline had to be checked instead of simply multiplying striker speed.
Another roadblock was repetitive level design. Having many levels does not automatically create progression. When most levels required only one or two shots, they felt almost identical. We had to rethink the campaign so later levels contained more targets and required several meaningful turns, while still keeping early tutorial levels short and understandable.
Visual consistency also required repeated adjustment. Some early UI elements looked too much like normal website cards instead of game UI. Icons, buttons, popups, and board artwork needed to follow one shared premium design language. We also had to enforce the use of transparent PNG/WebP image assets instead of white-background images, SVG artwork, emoji, or inconsistent placeholder graphics.
Another challenge was preventing visual improvements from damaging working gameplay. Changes to Canvas size, responsive scaling, UI placement, or board artwork could accidentally affect pointer coordinates or physics alignment. Because of this, later prompts were intentionally scoped to one system at a time.
5. Key Takeaways
What was the part that worked the best? The strongest part was defining the architecture and gameplay flow before expanding the game. Separating physics, rendering, input, level data, UI, audio, and progression made it easier to identify where problems actually came from. Building Level 1 first also helped reveal physics and input problems before they were copied across the full campaign.
The premium visual direction also improved significantly once the game adopted one consistent identity: dark navy backgrounds, teal playing surfaces, polished wood, gold trim, transparent image assets, strong typography, and simple primary actions.
What was the part that worked the worst? The weakest stage was asking the coding AI to improve too many systems simultaneously. Large prompts that mixed gameplay, UI, levels, physics, and assets could cause working systems to regress. The project improved more reliably when Cursor was instructed to focus on one area at a time and explicitly told which systems must remain unchanged.
Level progression was another important lesson. More levels do not automatically mean more gameplay. Each stage needs a reason to exist, an intended solution, and a new decision for the player. Later levels became stronger once they moved from simple one-shot targets toward multi-shot puzzles involving several coins, rebounds, combos, target order, and efficiency goals.
My final thought: If I had one more day, I would spend it almost entirely on gameplay balancing and full campaign testing rather than adding new features. I would play every level from beginning to end, tune shot power and friction using consistent physics values, redesign any repetitive level, improve advanced multi-shot challenges, balance the three-star requirements, and test the complete game on several mobile screen sizes.
If I could redo the project, I would establish the physics tuning values, reusable level objective system, and final visual asset style even earlier. This would reduce repeated redesign work and prevent later UI or level changes from affecting already-working gameplay. The biggest lesson from Carrom Trick Master is that a simple casual game becomes convincing only when **controls, physics, level design, feedback, and visual consistency all support the same gameplay experience.
**