Skyshot Golf Project Report
1. The Concept
Skyshot Golf is a browser-based 2D physics golf game built around a simple but replayable distance-launch loop: charge the swing, hit the ball, watch it fly across dynamic terrain, earn coins, upgrade the golfer, and try to beat the previous best distance. The game was inspired by the fast, easy-to-understand style of casual distance golf games, but it was redesigned with its own name, visual identity, characters, ranges, progression systems, and premium fantasy-sports presentation.
I chose this concept for a one-day sprint because it looks simple at first but actually requires several systems to work together correctly: swing timing, ball physics, bounce behavior, camera tracking, terrain collisions, upgrades, character selection, range progression, responsive landscape layouts, sound, visual effects, and persistent save data. It was a good test of whether AI-assisted development could move from a playable prototype to something that feels closer to a polished mobile game.
2. The Stack
The Stack: HTML5, Vanilla CSS, JavaScript, and HTML5 Canvas.
The game was built without React, Vue, Three.js, or another application framework. Canvas and JavaScript handle the main gameplay, including the ball, physics, camera, terrain interaction, effects, and distance calculations, while HTML/CSS handle interface elements and responsive layout.
The visual direction relies heavily on generated PNG/WebP assets rather than CSS-drawn game artwork. Standalone assets such as golfers, golf balls, clubs, icons, effects, and decorative objects were required to use transparent backgrounds with no white boxes or visible white halos.
The AI Assist: ChatGPT handled concept analysis, gameplay structure, progression planning, UI/UX direction, debugging strategy, asset requirements, responsive requirements, and step-by-step technical prompts. Cursor was used for the main implementation and repeated coding/polish passes, translating those requirements into the working HTML, CSS, JavaScript, Canvas systems, and asset integration.
3. The 1 Day Sprint:
Morning (Hours 1–3): We started by analyzing the reference gameplay and identifying the core loop: hold to charge, release to swing, ball flight, bounce, landing, reward, upgrade, and immediate replay. We then created the original Skyshot Golf direction instead of directly copying the reference. The first implementation focused on the project structure, landscape viewport, golfer, swing meter, basic ball physics, camera behavior, distance tracking, and the first playable range. The first visual result exposed major layout problems: duplicated backgrounds, black empty space, oversized terrain blocks, weak screen composition, and mismatched character/UI artwork.
Afternoon (Hours 4–6): Most of the development time went into repeated gameplay and visual refinement. We rebuilt the responsive landscape presentation, improved terrain scaling, adjusted golfer placement and character poses, refined the power meter, upgraded the HUD, created a result flow, and added the Clubhouse with upgrades, Strikers, Orbs, and Ranges. We also added progression systems including Power, Speed, Bounce, best-distance tracking, coins, objectives, unlock conditions, multiple range environments, and persistent selection/save behavior. A large amount of time was spent auditing generated assets because some golfer, club, ball, and effect images had bad crops, white backgrounds, white halos, inconsistent proportions, or incomplete full-body poses. Bad assets had to be removed, cleaned, or regenerated.
The Finish Line (Hours 7–8): The final stage focused on making the game feel less like a static prototype and more like a premium casual game. We refined button padding and text fit, improved Home and Result screen hierarchy, added range-specific environmental motion ideas, strengthened gameplay feedback, and planned matching fantasy-sports music and sound effects. We also performed responsive checks across multiple landscape phone sizes and larger desktop resolutions. The final priority was stability: preserving working physics and progression while fixing visual inconsistencies instead of repeatedly redesigning the entire game.
4. The Roadblocks
Roadblocks: The biggest challenge was visual consistency. Individual generated assets could look good by themselves but still look wrong when combined. At different stages the game mixed a cinematic painted background, cartoon golfers, ornate fantasy buttons, modern dark HUD panels, transparent terrain strips, and unrelated decorative assets. This made the game feel like several different art styles pasted together instead of one finished product.
Responsive landscape design was another major problem. Early builds produced duplicated backgrounds, black gaps, oversized grass rectangles, cropped UI, and layouts that only worked at one resolution. The terrain also repeatedly looked like a long floating ribbon rather than a believable playable golf landscape, so both visible terrain and collision geometry needed careful adjustment.
Asset generation caused additional delays. Some images claimed to be transparent but still contained white backgrounds, white matte edges, badly cut body parts, missing clubs, inconsistent poses, or excessive empty space. Golfer animation was especially difficult because idle, charge, swing, follow-through, and victory images needed to look like the same character with the same scale, anchor point, clothes, and proportions.
The gameplay itself also needed more depth. A pure “hit right and measure distance” loop became repetitive quickly, so the project expanded to include bonus rings, coins, terrain variation, objectives, unlockable ranges, Strikers, Orbs, sand, water, boosts, and milestone progression while still keeping the controls simple.
5. Key Takeaways
What worked best was the structured, step-by-step development approach. Breaking the game into smaller systems—responsive shell, golfer, swing timing, physics, bounce, camera, distance, upgrades, terrain, progression, Clubhouse, audio, and final QA—made it much easier to identify which part was actually broken. The game improved most when only one system was changed at a time and working logic was explicitly protected.
What worked worst was broad visual prompts such as “make it more premium” or “redesign everything.” Those instructions gave the coding AI too much freedom and often caused one improvement to create several new problems. The most successful iterations used strict scope, for example: fix only terrain, fix only buttons, fix only Clubhouse, or preserve physics while improving game feel.
Another important lesson was that generated assets must be treated like production assets, not automatically trusted. Every image needs to be checked for transparency, crop quality, consistent scale, clean edges, and matching art direction before being added to the game.
My final thought: If I had one more day, I would spend it almost entirely on gameplay balance, environmental animation, audio mixing, performance profiling, and full-device QA instead of adding more content. I would also standardize every character pose and asset canvas earlier in the process so character switching and animation alignment were consistent from the beginning. If I rebuilt the project, I would lock the art direction, responsive coordinate system, and asset specifications before generating the first large batch of visuals, because those decisions had the biggest impact on how polished the final game felt.