From a Photoshop Spark to a Finished Game: The Chromax Journey

It began with a simple question in Photoshop and ended with an impossible bug and a lesson in what truly makes a game feel "fair."

Chapter 1: The Spark in the Color Wheel

The idea for Chromax did not arrive in a flash of inspiration. It was born from the mundane. I was working on a project for a client, deep inside Photoshop, meticulously creating assets. My task was to select appropriate background colors, and I had the color wheel open, my cursor hovering over a sea of hues. In that moment of intense focus, a stray thought sparked: what if this was the game? What if you had to find a specific color under a time limit, like throwing a dart at a spinning, multicolored dartboard?

The concept was simple and compelling. The core game elements came together quickly in my mind. There would be a target color displayed for the player, a full color wheel for them to choose from, and a small preview window to give a visual sense of their selection before they locked it in. It felt elegant, minimalist, and perfectly aligned with the LazyDevLabs philosophy.

Chapter 2: The Ghost in the Machine

I built the first prototype quickly. The logic seemed sound, the interface was clean, and it worked. Or so I thought. As I began play-testing, a frustrating mystery emerged. I would be shown a target color, say a bright, sunny yellow. I would carefully select what looked like an almost identical yellow on the wheel. My brain told me I was close, that I should get a high score. But the result would come back surprisingly low.

At first, I thought my eyes were deceiving me. Then I thought my code was broken. I would select a muted green that looked very different from a target yellow-green, yet it would sometimes score higher than a color that looked much closer. The game felt arbitrary and unfair. It was the kind of experience that makes a player quit in frustration, and I had no idea why it was happening.

Chapter 3: The Lightness Revelation

After hours of debugging and questioning my own color perception, I finally found the bug. It was not a bug in the code, but a flaw in the very concept of the game. The problem was "lightness."

My code generated the random target color using the full spectrum of possibilities for hue, saturation, and lightness. However, the color wheel on the screen was hardcoded to a constant lightness of 50%. I was asking players to hit a three-dimensional target while only giving them a two-dimensional tool. It was like trying to find a specific spot in a room by only looking at a floor plan. It was literally impossible for a player to ever get a perfect score, because the target color often didn't even exist on the wheel they were using.

Once I understood the problem, the fix was obvious. I modified the target color generation logic to always produce colors that also have a 50% lightness. This single change transformed the game overnight. It was no longer a game of luck; it was a game of skill. The playing field was finally fair.

Chapter 4: The Art of Fair Scoring

With the core mechanic fixed, a new challenge emerged: the scoring system. My initial algorithm was based on Euclidean distance in the color space. While technically accurate, it felt far too generous. A player could make a very noticeable mistake and still get a score of 80 out of 100. It did not adequately reward precision.

This is where modern tools can be a solo developer's best friend. I decided to consult some advanced AI models to explore more sophisticated scoring algorithms. I explained the problem and was introduced to the concept of Delta E, a standard for measuring perceptual color difference. The AI suggested several models: a stricter linear model that made each point of difference count for more, a non-linear model that heavily punished large mistakes, and a normalized model that scaled the score within a maximum meaningful difference.

The process was a fascinating dialogue. I would take the logic suggested by one model and discuss its reasoning and potential flaws with another, refining the approach with each step. It was a powerful collaboration that allowed me to rapidly prototype different "feelings" for the scoring system without weeks of manual research.

Chapter 5: From a Problem to a Feature

This deep dive into scoring algorithms led to the final breakthrough for Chromax. I realized that the different scoring models were not just different solutions; they were different ways to play. This was the birth of the game's difficulty modes.

For "Normal Mode," I implemented a stricter linear formula that feels fair but challenging. For "Hard Mode," I used a normalized scoring system and added a new layer of difficulty: the target color is only shown for five seconds, forcing you to rely on memory. What began as a scoring problem had evolved into a core feature that added significant replay value to the game.

This journey from a simple idea to a finished game was a powerful reminder that game development is an iterative process of discovery. Sometimes the most frustrating bugs and complex problems are actually opportunities to make your game even better.

Think you can master the color wheel? You can play the latest version of Chromax right here!

← Back to Blog