When AI Goes Wrong - A Weekend Lost to A Bad Assumption

Edit

I have since made a follow up post which changes this solution yet again. The dynamic resizing was a flawed approach, to see the correct solution check out this post: https://jeremypjohnson.blogspot.com/2025/12/solving-aspect-ratio-problems-for-good.html

Problem Context and Initial Architecture

This case study examines a critical architectural failure, ineffective LLM consultation, and the resulting implementation overhead that consumed an entire weekend of development time.

The application supports user-placed objects within a physics-based game environment. To ensure consistent level presentation across devices with varying aspect ratios and pixel densities, I implemented a "game units" coordinate system: 100 units wide by 60 units tall. This abstraction layer was designed to maintain visual consistency between iPhone and iPad deployments, where pixel-based positioning would produce inconsistent layouts due to different screen dimensions and pixel densities.

Issue Discovery and Initial Analysis

After two months of development, testing revealed a critical flaw in the coordinate system. While X-axis positioning remained consistent across devices, vertical object placement exhibited significant dimensional inconsistencies. Objects placed vertically occupied different amounts of space depending on the target device.

This presented an unacceptable constraint for a physics-based game where level geometry must remain identical across platforms. Inconsistent object dimensions would create gameplay disparities—holes in levels on iPad that wouldn't exist on iPhone, fundamentally breaking the user experience.

LLM Consultation and Misguided Solutions

Initial consultation with Claude involved several hours of problem explanation and solution exploration. The LLM suggested implementing black bars to force consistent aspect ratios across devices. This approach was rejected as it would significantly degrade the user experience.

The critical error occurred when I led the consultation with a preconceived solution: percent-based positioning for UI elements. When asked whether this approach would resolve the coordinate system issues, Claude provided affirmative confirmation without proper analysis of the underlying problem.

Implementation Overhead and Failure

Based on this flawed recommendation, I invested six hours migrating the entire codebase from game units to percent-based offsets. This positioning system defines object placement as percentages from the bottom-left corner (e.g., 15% horizontal, 50% vertical) with dimensions specified as percentage of screen real estate (10% width, 3% height).

The migration consumed an entire Saturday and ultimately failed to resolve the core issue. Level geometry inconsistencies persisted across devices, indicating that the fundamental problem remained unaddressed.

Root Cause Analysis

The breakthrough came through independent analysis rather than LLM consultation. The core issue involved object rotation within the percent-based coordinate system. While horizontal positioning remained consistent at 15% screen width, rotating objects to vertical orientation created dimensional inconsistencies due to aspect ratio differences between devices.

The 15% horizontal dimension translated to different vertical space allocations depending on device aspect ratio and pixel density. This rotation-based scaling issue had not been factored into the original coordinate system design.

Solution Implementation

The resolution involved dynamic object resizing during rotation operations. As objects transition from horizontal to vertical orientation, the system calculates appropriate dimensional adjustments based on device aspect ratio. For iPhone deployments, objects shrink during vertical rotation due to reduced vertical pixel availability, with scaling calculations maintaining proportional relationships (15% horizontal remains equivalent to 15% vertical after aspect ratio compensation).

This approach achieved consistent level geometry across all target devices, resolving the physics game requirements.

Lessons Learned

This incident highlights the limitations of LLM-assisted problem solving for complex architectural challenges. While Claude excels at implementation tasks, it cannot replace fundamental system analysis and solution architecture. The tool's tendency to confirm user-suggested approaches without rigorous evaluation can lead to significant implementation overhead.

Effective LLM utilization requires independent problem analysis before seeking implementation assistance. The six-hour implementation loss could have been avoided through upfront architectural thinking rather than immediate solution implementation.

Comments

Post a Comment

Popular posts from this blog

Solving Aspect Ratio Problems For Good!!

The Problem: Inconsistent Gameplay Across Devices BallBuilder is a physics puzzle game. Levels contain various components—triangles, rectangles, fans, portals—that players interact with to guide a ball to the goal. Consistency matters. A puzzle that's solvable on one device must be solvable on another, using the same approach. Early in development, I was building on an iPhone. When I used Xcode's device emulator to see how the game looked on an iPad, I was immediately disappointed. The layouts were wrong. Components appeared in different relative positions. The carefully crafted levels didn't translate. This was a fundamental problem that I needed to solve. First Attempt: Percentage-Based Positioning My initial approach used fixed pixel coordinates. This was obviously wrong—devices have different pixel counts, so a component placed at pixel 100 would appear in completely different locations across devices. The first real improvement was switching to percentage-b...
Read more

Designing a Scalable Community Content System

Problem Statement During development of the Ballistics puzzle game, I built a comprehensive level editing toolset for creating physics-based puzzle levels. This toolset enables efficient placement of game objects, configuration of gameplay parameters, and rapid iteration on level design. The natural progression was to democratize this capability—enabling players to create and share their own levels while maintaining quality standards and preventing abuse. The core challenge involved designing a system that would allow user-generated content while addressing several critical constraints: Ensuring published levels meet quality standards (solvability requirement) Preventing statistical inconsistencies when levels are modified post-publication Implementing efficient content discovery with multiple query patterns Mitigating cost concerns through strategic resource gating Pr...
Read more

Customizing the playing experience with special ball effects

Customizing the playing experience My original vision for BallBuilder was strict equality. Players would unlock balls through coins earned by playing, and every ball would be functionally identical—just cosmetic variety. Everyone competes on equal footing. Through discussions with my development partner and general brainstorming, I realized this approach left significant potential on the table. The ball system could offer much more than cosmetic choices. It could become a customization layer that changes how players approach puzzles. The concern with giving some balls mechanical advantages is obvious: pay-to-win dynamics. But I concluded that advantages can exist without breaking competitive integrity, as long as skill remains the primary differentiator. A better ball might make a puzzle easier, but it won't solve it for you. Passive Effects: The Core Concept Each ball in BallBuilder now has a passive effect that activates when equipped. These effects range from subtle ad...
Read more