Una decisión cromática propaga restricciones
Colors is a connected-region puzzle: you control the component starting in the top-left corner, choose a new colour each turn and absorb adjacent connected cells of that colour until the board becomes one region.
Current engine status
The native engine exists and is tested, but the game manifest is still coming-soon. This article documents implementation without pretending that implementation already means public availability.
The board is a graph of components
Colour is the visible representation; connectivity is the structure. Two equal-colour regions can have very different strategic value when one touches the frontier and another remains isolated.
Size and difficulty are independent
The engine defines 8×8, 12×12, 18×18 and 24×24 boards. Easy uses four colours, Normal five, Hard six and Expert seven. Challenge adds eight, five, two or zero moves of slack relative to a known guide.
Challenge proves reachability, not optimality
The current guide is greedy. The limit proves that a known sequence fits inside the budget; it does not prove a globally minimal move count. Zero slack on Expert means matching or improving the reference, not proving the optimum.
Seeds make generation reproducible
Keeping a seed makes it possible to rebuild a run, reproduce a bug and compare a new heuristic on exactly the same board.
The self-test exercises sixteen combinations
All four sizes are tested against all four difficulties. The test replays the guide, requires completion and checks that movement limits and colour counts match the selected profile.
The right correctness property is not uniqueness
Colors can legitimately have many successful sequences. What matters is completable content and a reachable Challenge budget. This is one reason one solver does not fit every puzzle.
Strategy lives on the frontier
Capturing more cells immediately is not always the best move. Strong play looks at which components become accessible, which remote areas move closer and which colours may have to be repeated.
Difficulty can eventually measure topology
Two boards with the same colour count can feel very different. Internal tooling can compare stable seeds, greedy guides and bounded search to improve calibration without making every browser run expensive.
Accessibility is a functional requirement
Colour carries game state. Before publication, contrast, alternate palettes and complementary non-colour cues deserve product review.
The complete product has more layers
An engine and self-test do not solve onboarding, responsive layout, persistence or common results. The distinction mirrors finishing a puzzle is more than making it playable.
The catalogue should describe territorial planning
We can accurately describe component expansion, sequence comparison and frontier planning without turning the game into an unsupported cognitive-training claim, following our catalogue taxonomy.
The frontier is the strategic object
Percentage owned tells us what already happened; the frontier describes what can happen next. Two positions with the same captured area can have completely different futures when one touches four colours and the other is constrained to two. Strong evaluation therefore begins with access rather than area alone.
This makes Colors a planning puzzle rather than a simple sequence of colour taps. The visible board is a map of future connectivity.
Large components do not always need to be captured immediately
A large reachable region is tempting, but absorbing it can reshape the frontier so another important area becomes several changes away. Sometimes preparing a bridge between two components is stronger than consuming their shared colour immediately. Capture value depends on sequence.
The known guide is a witness, not an oracle
A guide that completes the board proves Challenge is feasible. It does not need to be optimal to fulfil that role. Keeping “feasibility witness” separate from “best possible route” allows future solver work to improve calibration without changing what the current engine honestly guarantees.
Greedy heuristics deserve regression tests
Small scoring changes can alter many seeds. If component size, frontier diversity or colour repetition receive different weights, a fixed benchmark set should compare guide length, runtime and retry count. Otherwise a visible improvement on a few boards can hide a systematic regression.
Generation retries are part of performance
It is not enough to measure the final successful call. The number of discarded candidates matters too. Rising retries can reveal that a filter or heuristic is making generation brittle before average latency becomes obviously bad.
An explicit time budget protects interactive play
If future search becomes more sophisticated, client generation still needs a clear budget. Once it is exhausted, the product can try another seed, use a cheaper guide or fall back to a known case instead of freezing the interface for an optimization the player never requested.
Memory belongs in the budget as well
Search can duplicate boards, owned sets and frontier state. A 24×24 board magnifies that cost. Compact representations, bitsets or rollback may eventually matter as much as CPU time. We should introduce that complexity only when measurement supports it.
A Web Worker does not repair an inefficient model
Moving expensive work off the main thread can preserve responsiveness, but it adds serialization, cancellation and stale-response problems. If the player changes size while an old generation is running, that result must never overwrite the active session.
Cancellation prevents correct answers for obsolete sessions
When the player changes difficulty, starts another run or navigates away, previous work is no longer useful. A heavier generator should be cancellable so obsolete computation does not waste CPU or race with newer state.
Persisting a seed improves support
A materialized board may be enough to resume visually, but the seed adds provenance. It can reconstruct the origin of a run, help reproduce reports and compare generator versions. Durable saves may still need the board because future algorithms can reinterpret the same seed.
Generation versions keep historical runs stable
A result created today should remain understandable after the engine evolves. Size, difficulty, mode and generation version provide enough context to explain what logic created the run even when implementation changes.
Casual and Challenge results should remain distinct
A Casual completion in thirty moves and a Challenge run with a twenty-move limit do not represent the same objective. Common results should preserve mode, size, difficulty, seed, moves and limit so statistics do not mix incompatible contexts.
Statistics should explain what they compare
Moves can be compared against the limit for the same seed, against a previous attempt or against personal history. Those are understandable references. A global number that mixes unrelated boards may look precise while saying very little.
A hint can expose opportunity without playing the move
The internal guide makes hints possible, but simply replaying its next colour would automate the puzzle. A better hint might identify a component that could be opened or explain that one option narrows frontier diversity. Solver evidence needs a pedagogical policy.
Hints need their own correctness contract
A hint must be legal in the current state and remain relevant after undo or a route that differs from the generator guide. That can require local recomputation instead of blindly following a precomputed sequence.
Onboarding can teach prediction
A strong first lesson can present three colours and ask which one will absorb two components. That exercise teaches both the rule and the idea of frontier. The tutorial does not need to teach optimization; it needs to make the state transition predictable.
The UI must distinguish owned territory from matching colour
On a large board, cells can share the active colour without belonging to the connected component. The visual system needs to communicate ownership or connection clearly. Otherwise the player cannot reason correctly about the frontier.
Feedback should explain causality
Recolouring, absorption and move count should update coherently. Animation can help reveal which components entered, but it should respect reduced motion and never delay the next interaction merely for decoration.
Responsive design turns 24×24 into a product question
A grid that is readable on desktop can become tiny on a phone. The product may need zoom, different sizing rules or viewport-specific availability. Technical engine support does not automatically make a configuration a good experience everywhere.
Light and dark themes need functional palettes
A colour set that works against a dark surface can lose distinction in light mode. Because colour is game state, each theme needs verification for cells, focus, selection, controls and completion feedback.
Keyboard play is part of accessibility
Colour choices should be reachable with visible focus and predictable order. Optional shortcuts can improve speed, but standard controls still need to support complete play without a pointer.
Catalogue categories can evolve independently
The manifest currently associates Colors with patterns and regions. Those labels belong to discovery, not rule logic. Taxonomy and recommendations can change without touching the engine when metadata remains external.
Changing the palette should not change a seed
Logical colour identities should remain separate from visual hues. That lets accessibility and themes improve without causing the same seed to generate a different logical board simply because presentation changed.
The shared shell should stay outside the algorithm
The engine needs colours, components, moves and completion. It does not need to know how a modal opens, where results are stored or which URL renders the page. Those are platform responsibilities, and keeping them separate makes isolated tests possible.
What I would verify before marking Colors available
Beyond a green self-test, the release checklist should exercise every size and difficulty on desktop and mobile, keyboard navigation, themes, reduced motion, restored sessions, Challenge, undo and redo, onboarding and common results. Several stable seeds should remain as visual smoke cases.
Colors demonstrates why a platform surrounds the engine
The core rule code is small compared with everything required for a coherent user experience. The game shell exists to absorb repeated responsibilities so the engine can remain focused on its mechanic.
Future optimization should remain explainable
If stronger search is introduced for Challenge calibration, the system should retain understandable metrics such as guide length, lower bound, retries, time and memory. An opaque score can improve one result while making regressions much harder to diagnose.
The final criterion remains simple
A finished Colors should let the player understand what they control, predict the effect of a colour, trust that Challenge is possible and receive the same quality of surrounding experience as any other Blupoli puzzle. Seeds, heuristics, workers and benchmarks all exist to support that contract.
Publishing should preserve the evidence
Changing coming-soon to available should be the consequence of integrated quality gates rather than a manual label change. Public status should mean that the surrounding experience has been tested as deliberately as the engine itself.
Discovery should explain why a player might like it
Colors can be recommended to people who enjoy spatial planning, compact rules and movement optimization. That is more useful than simply calling it a “colour game,” because it describes the decision pattern the player will actually encounter.
Comparison with other games should be structural, not superficial
Ataxx, Hex and Dots and Boxes all make future space matter, but they do so through completely different rules. A good related-games system explains the shared planning flavour without implying mechanical equivalence.
Difficulty copy should stay tied to evidence
Easy, Normal, Hard and Expert currently correspond to colour count and Challenge slack. If future calibration begins to incorporate topology, the UI and documentation should evolve with the implementation. Labels should never outrun the data that supports them.
Challenge failures deserve reproducible reports
If a player believes a limit is unfair, a support payload containing seed, size, difficulty, engine version and movement history can turn the report into a testable case. That is far more useful than a screenshot alone.
Move history can support both undo and diagnostics
A compact action log makes it possible to restore state, implement undo and inspect how a run reached an unexpected position. The same underlying data can serve several product features when its semantics remain clear.
Replay should be optional, not a hidden dependency
The engine should not require a full replay just to validate current state. A saved board needs enough materialized information to load directly. Replay is valuable for diagnostics and visualization, but it should not make persistence fragile.
Completion feedback should not obscure the final board
When the board becomes one region, the product can celebrate without immediately covering the state the player just created. Results, movement count and next actions should appear clearly while leaving the completed pattern understandable.
A new game action must respect the same seed semantics
If “New game” promises a different board, it should advance or replace the seed deliberately. If “Retry” promises the same challenge, it should preserve it. Small labels become part of the reproducibility contract.
Testing should include boundaries, not only typical runs
Smallest and largest sizes, every difficulty, zero-slack Expert, repeated undo, rapid new-game actions and theme changes all stress different product boundaries. Retaining those cases prevents the happy path from becoming the only path CI knows.
The engineering goal is not infinite content at any cost
Procedural variety is valuable only when generation remains fast, reproducible and fair. If a candidate cannot be verified within budget, rejecting it is better than weakening the Challenge guarantee. Quality is part of generation, not an optional pass afterwards.
Colors is a compact example of the Blupoli philosophy
The rules can fit in a few sentences, but a trustworthy product requires explicit contracts around generation, difficulty, interaction, accessibility, persistence and publication. That gap between simple mechanic and complete product is exactly what the platform exists to manage.
Difficulty can measure freedom of manoeuvre
A short known guide does not automatically make a board easy. One layout may allow many equivalent routes while another demands a narrow sequence. That freedom changes perceived pressure. Internal tools can estimate it over stable seeds and use the result to tune generation without moving expensive search into every browser session.
QA seeds should become a case library
Whenever testing finds an especially good, bad or unusual run, retaining its seed creates reusable knowledge. Over time the library can cover late islands, forced repetition, open frontiers, large boards and configurations that stress the heuristic. Future changes can then be reviewed against known structures instead of waiting for chance to recreate them.
Generation failure needs safe degradation
If repeated attempts cannot produce a verifiable candidate, the product can switch seed or use a previously validated fallback. Repeating less content is preferable to weakening the Challenge guarantee or leaving the interface blocked indefinitely. Fallback behaviour should preserve the properties the player was actually promised.
Casual can share the engine without sharing the budget
Removing a visible limit does not mean accepting unverified boards. Shared generation with different session policy avoids maintaining two engines that slowly diverge. Mode differences can live in presentation, result semantics and objective rules rather than duplicated generation code.
Logical colour should be independent from visual colour
Colours can exist internally as stable indices and map to visual hues later. An accessibility theme can then change presentation without changing the logical board produced by a seed, and domain tests do not depend on concrete hex values. Visual design can evolve without changing puzzle identity.
Visual tests only need a few representative seeds
Thousands of screenshots would create noise. A small set can cover sizes, intermediate states, focus, completion, themes and mobile layout. Stable seeds make those references reproducible between commits. Logic tests cover variety while visual tests cover composition; each form of evidence answers a different question.
The meaning of “move” must remain stable
If a future release decides that selecting the active colour no longer costs a turn, or changes undo semantics, historical results become less comparable. Counting rules should be documented and versioned when they change incompatibly. A statistic is only trustworthy when the measured term has stable semantics.
Challenge needs a clear policy after the limit is exceeded
The product may allow play to continue outside the target, mark the attempt as failed or offer a retry. Any choice can work if it is communicated before the moment arrives and engine, UI and results interpret the counter consistently. The budget should not become a surprise after several minutes of play.
Retry and New game should mean different things
Retry should preserve the seed and target so the player can learn from the previous attempt. New game should create another seed. Small labels become part of the reproducibility contract and give improvement between attempts a clear context.
Completion should be idempotent
Once the whole board belongs to the region, duplicate events or late asynchronous work must not record multiple results. The shell should treat completion as a one-time transition. Restoring an already completed save should not replay completion sounds, confetti or analytics either.
Publishing should add evidence rather than remove it
When the manifest eventually becomes available, the tests that made the engine trustworthy should remain. Shipping increases the value of those guarantees; it is not a reason to relax them. A large catalogue stays healthy when every game keeps its own evidence as it evolves.
Procedural variety is subordinate to trust
Generating many runs only adds value when they are fast, reproducible and fair. If a candidate cannot be verified within budget, rejecting it is better than weakening the contract. Quality belongs inside generation rather than being treated as an optional stage afterwards.
Colors summarizes the Blupoli philosophy
The rules fit in a few sentences, but the finished product needs explicit contracts around generation, difficulty, interaction, accessibility, persistence and publication. That gap between a simple mechanic and a trustworthy experience is exactly the kind of problem a shared platform is designed to solve.
Publication does not end the work
When Colors eventually leaves coming-soon, quality will still need to be measured after every meaningful change. New palettes, difficulty tuning, performance work or statistics integration can break contracts that are green today. Retained seeds, self-tests and representative visual cases turn release into the beginning of maintainable operation rather than the moment verification stops.
That is the real goal of this architecture: letting the game evolve without returning to intuition and ad-hoc manual testing every time a shared layer changes.