Las ecuaciones se cruzan como palabras
Math Crossword turns a grid into a network of equations. Numbers are shared between horizontal and vertical expressions, so solving one local gap can immediately constrain another equation. The interesting object is not an isolated calculation but a connected system of variables.
Current status: real engine, publication still pending
The native engine exists in the repository with explicit size and difficulty profiles, but the game manifest is still coming-soon. This article can document implementation and verified behaviour without pretending the game is already a finished public catalogue entry.
The grid is a constraint network
A shared number belongs to two contexts. That makes every intersection a channel for information. Solving a horizontal equation can place a value that turns a vertical equation into a one-unknown problem, and that result can propagate again.
The four sizes are 5×5, 7×7, 9×9 and 11×11
The engine defines those four canonical sizes. Growing by two preserves the alternating number-and-operator structure while adding variables and intersections. Size changes approximate session scale; difficulty is controlled separately.
Difficulty changes range, subtraction and hole ratio
Easy uses small values, very little subtraction and fewer hidden cells. Normal increases all three. Hard and Expert expand the numeric range, subtraction probability and percentage of removed values. A large board can therefore remain approachable while a smaller one can be more demanding.
Generation begins from a coherent complete matrix
The engine first builds numeric values and relationships that define horizontal and vertical equations. Operators are derived consistently, and only afterwards are values removed to create editable gaps. The full solution exists before the puzzle is dug.
Removing values must preserve propagation
Hole creation is not simply a quota. The engine attempts to reconstruct the puzzle and restores removals that break the expected propagation path. The generator proposes missing values; the solver acts as a quality filter.
This follows the principle described in generation is not solving: creating a candidate and proving useful properties about it are separate jobs.
Propagation exploits one-unknown equations
When an equation has exactly one unknown, the engine can solve that value directly. Inserting it into the shared matrix can make another equation solvable. Repeating the process turns intersections into a chain of consequences.
The self-test covers size and difficulty
For every combination the engine generates a puzzle, runs propagation and requires the reconstructed values to match the original solution. It also verifies every equation and requires at least one editable cell. These checks mirror the visible product matrix.
The current solver proves one specific logical route
Successful propagation is a meaningful guarantee, but it should not be stretched into a claim about every human technique or a complete model of difficulty. The engine demonstrates that its own deterministic process can recover the generated assignment.
A known solution and uniqueness are different questions
A full matrix proves existence. Claiming uniqueness would require ruling out alternative assignments under all constraints. The current self-test focuses on recovering the generated solution through propagation. Before public copy promises uniqueness, the code should contain a matching proof or solution counter.
The project history includes an Android version
Math Crossword comes from an ArceApps Android experience, but the web engine is a native JavaScript implementation inside Blupoli. Functional parity does not require sharing every line of platform-specific code.
Port concepts, not platform coupling
A web engine should not inherit assumptions from Activities, ViewModels or Android storage. The useful migration work is identifying domain rules, serializable state and interaction contracts, then rebuilding those pieces in the destination architecture.
Equation semantics must be unambiguous
Operators, direction and evaluation rules need a precise contract. The current engine uses controlled linear relationships that keep solving understandable. Adding richer multiplication or division later would require explicit decisions about evaluation, allowed intermediate values and integer constraints.
Integer results are a generation requirement
A puzzle that expects integer entry should not quietly produce fractional deductions. The generator checks that solved values remain integers within the allowed range. Arithmetic semantics belong to the domain rather than presentation.
Difficulty should not mean only larger numbers
Increasing numeric range adds calculation load, but interesting difficulty also comes from how many equations unlock each other, how long propagation chains become and how often no direct one-unknown equation is available.
Hole position matters more than raw hole count
Two missing values placed at a critical crossing can create more dependency than four scattered gaps. Hole ratio is therefore only a coarse control. Topology of removed values strongly influences the solve path.
Stable seeds make generator changes measurable
If hole ratios, numeric ranges or digging heuristics change, fixed seeds can reveal whether runtime, propagation depth and puzzle structure improve or regress. Procedural work becomes much easier to review when the same cases can be reconstructed.
Tail latency matters on 11×11
Larger boards have more values and equations. Even cheap propagation can become noticeable if generation performs many digging attempts. Benchmarks should include worst cases, not only averages, because a single multi-second pause can make the product feel broken.
Cancellation matters if generation becomes asynchronous
If the player changes size while a board is being generated, the old result must not overwrite the new selection. Workers or asynchronous generation therefore need request identities, cancellation and stale-result rejection.
The UI must distinguish clue, input and operator
A dense arithmetic grid can become visually noisy. Given values, editable cells, operators and equals signs need separate hierarchy using more than colour alone. Focus and selection also need to remain obvious on keyboard and touch.
Keyboard input is a natural fit
Numeric entry becomes much faster with keyboard support, but focus order, deletion and arrow navigation must remain predictable. Optional shortcuts should not be the only accessible path.
Errors can be local without revealing the solution
The UI can mark a fully entered equation as invalid without immediately replacing the wrong value. This gives feedback while preserving deduction. Overly aggressive correction would turn the board into an answer checker rather than a puzzle.
Hints can point to an equation that is ready
A first hint does not need to insert a number. It can highlight a row or column with a single unknown. That mirrors the actual propagation technique and teaches the player how to find progress.
Advanced hints can explain propagation
A richer hint can show how solving one equation provides a shared value for another. That relationship is the core mechanic and therefore the most valuable concept to teach.
Onboarding should begin with a tiny crossing
A 5×5 practice scene can solve one horizontal gap and then show that the same value belongs to a vertical equation. Teaching transfer of information matters more than listing every control.
Persistence must separate solution from progress
A save needs configuration, generated clues and player entries. The full solution can remain internal and should not accidentally leak into presentation or persistence APIs intended for user progress.
Common results need size and difficulty context
A 5×5 Easy session is not directly comparable with 11×11 Expert. Duration, errors and hints only make sense when the result keeps enough metadata to explain the run.
Coming-soon gives the project room to close product gaps
The engine already has generation and tests, but uniqueness, mobile UX, localization, onboarding and persistence can still be reviewed before public availability. The status label is an honest boundary, not a dismissal of the technical progress.
A next quality gate should examine ambiguity
If the product intends to promise one solution, the implementation needs a solution counter or equivalent proof before that language ships. Copy should follow evidence rather than lead it.
Historical context needs cautious wording
Crossnumbers predate Blupoli and exist in many forms. It is fair to place Math Crossword in the wider tradition of numerical crossword-style puzzles, but our exact grid should not be described as a direct reproduction of one historical design without evidence.
Related numerical puzzles share constraints, not identity
Kakuro shares crossing sums, KenKen uses arithmetic cages, and Killer Sudoku combines arithmetic with Latin-grid constraints. Math Crossword is distinct because equations are written directly into a network of shared numeric variables.
The catalogue should describe relational arithmetic
The observable activities are solving, propagating and combining information across equations. That is enough to describe the game without unsupported cognitive-training claims, following Blupoli's catalogue taxonomy.
The editorial visuals model the crossing
The new cover and infographic do not recreate a whole board. They visualize two equations sharing a variable and the direction of information flow. That relationship explains the engine more effectively than a decorative screenshot.
Finishing Math Crossword means more than passing self-test
The engine must generate quickly, preserve arithmetic semantics and expose coherent difficulty. The product also needs onboarding, responsive layout, keyboard support, accessibility, persistence, results and an explicit ambiguity guarantee if we choose to promise one.
The central lesson is genuinely shared variables
Math Crossword works when the crossing is logical rather than cosmetic: the same number belongs to two equations and carries information from one to the other. Generation, UI and teaching should all protect that idea.
Difficulty calibration can record propagation depth
An internal solver can count how many direct equations are available at each step, how long a chain continues before another branch opens and how many values each deduction unlocks. Those metrics can complement hole ratio and numeric range.
Arithmetic mistakes and logical mistakes are different
A player can understand which equation to solve and still make a calculation error. Feedback and statistics should not automatically interpret that as a failure of deduction. The interface can help with legibility while leaving arithmetic responsibility intact.
Operator localization should not change mathematics
Symbols are mostly language-independent, but surrounding instructions and accessibility labels are not. The runtime should expose the same equation semantics while localized text explains them consistently.
Screen readers need linearized equation labels
A visual grid alone is not enough for non-visual navigation. Editable cells can expose row, column, current value and the equations they participate in. A useful accessible model may need a linear description of each equation in addition to spatial position.
Focus movement should follow both geometry and equation structure
Arrow keys naturally move through the grid, while Tab can visit editable cells only. The product needs a consistent rule so keyboard users can predict where focus goes without accidentally landing on decorative operators.
Undo should restore one semantic entry
If entering a value triggers derived validation states, undo should revert the player's action and recompute feedback rather than storing a fragile snapshot of every visual class. Domain state should remain the source of truth.
Auto-check should be optional if it changes the solving experience
Some players prefer immediate error feedback; others want to reason without knowing whether a partial entry conflicts with the hidden solution. The product can support a preference, but it should be explicit because it materially changes how much information the system reveals.
A saved result can record hints and mistakes without becoming punitive
Hints used or completed-equation errors can help a player understand their own session. They should be descriptive metadata, not moral scores. The goal is context, not judgement.
Retry should preserve the same generated puzzle
When a player wants another attempt, seed and clues should remain identical. New game should generate a different puzzle. Clear retry semantics make improvement meaningful and simplify debugging.
Generation version belongs with durable seeds
If the digging algorithm changes, the same seed may no longer produce the same holes. Persisting a version or materialized puzzle protects historical saves and support reports from future refactors.
Quality gates should include every size and difficulty
Just as the current self-test iterates across the matrix, integration tests should eventually sample rendering, persistence and completion for each family of configuration. Visible options are commitments across the whole stack.
Solution counting should be part of the final product gate
Current propagation proves that the generated assignment can be reconstructed through one deterministic logical process, but a public promise of “unique solution” deserves a different proof. A counter that stops at two can distinguish impossible, unique and multiple without enumerating every answer. That would be a valuable gate before the manifest leaves coming-soon.
Ambiguity can hide behind successful propagation
The fact that one solver recovers the original assignment does not automatically exclude another valid assignment that requires different choices. Generation and verification answer different questions. The constructed solution is evidence of existence; solution counting is evidence of uniqueness.
Completed equations can be the unit of validation
While the player is entering values, the interface does not need to compare every cell against a hidden answer. Once an equation is complete, it can check whether the visible equality is true. That feedback is grounded in rules the player can see and avoids leaking information the board has not justified.
Difficulty can record when the solve path stalls
A board where a one-unknown equation is always available feels very different from one that alternates long propagation chains with moments where several areas compete for attention. Instrumenting the solver to record the number of immediately solvable equations at each state can produce a richer profile than hole ratio alone.
Results should preserve hint and auto-check context
Two sessions played with different feedback policies are not directly comparable. Recording size, difficulty, hints used and whether automatic checking was enabled adds context without turning those signals into a moral score.
Internationalization affects mathematical teaching too
Symbols are largely shared, but words such as unknown, solve for, crossing and completed equation need consistent translation. A mechanic-specific glossary can keep rules, onboarding and hints from using different vocabulary for the same concept.
A round-trip test protects persistence
Serializing and reloading a run should preserve clues, player entries, size, difficulty and completion state. After the round trip, the same completed equations should still validate identically. The domain meaning, not merely the JSON shape, has to survive.
Visual state should be derived from domain state
Error, selection and completion classes should not be persisted as independent truth. On load, the UI can rebuild them from values and rules. Avoiding duplicated state makes saves easier to migrate and reduces impossible combinations.
A future worker should exchange compact domain messages
If generation or solution counting moves off the main thread, the worker should receive matrices and parameters rather than UI structures. The boundary should remain expressed in puzzle terms, never DOM nodes or presentation classes.
Publication should require evidence across every configuration
Proving a property on 5×5 Easy is not enough if 11×11 Expert uses different parameters. Size and difficulty are public choices. Any promised invariant should be verified across the matrix or through a documented strategy that gives comparable confidence.
Math Crossword should be hard because of relationships, not arithmetic fatigue
Expert should not simply mean doing unpleasant calculations with large numbers. The more interesting difficulty appears when a deduction travels through several crossings and the player has to identify the best place to begin. Future calibration should reward that structure.
Hints can preserve agency by naming the technique
A hint can say that one vertical equation has a single unknown, or that solving a particular row will unlock two crossings. This gives the player a next direction while leaving the arithmetic and final entry to them.
Hints should be reproducible in bug reports
If a hint points to the wrong equation, a support case needs enough state to recreate exactly what the hint system saw. Seed, puzzle version and current entries can turn a vague report into a regression test.
Undo should recompute validation rather than replay styling
When one numeric entry is undone, all equations that depend on it may change from valid or invalid back to incomplete. Recomputing those states from domain values is safer than storing a visual history of classes.
Redo should share the same semantic action log
A compact action such as “cell 12 changed from empty to 7” is enough to rebuild both undo and redo. The same log can support diagnostics without coupling history to the rendering implementation.
Completion should check the visible rules, then the product contract
Every equation must be valid, every editable cell filled and any uniqueness or canonical-solution requirement must be satisfied. Keeping completion expressed as domain conditions makes it easier to test than a UI event that merely fires when no blanks remain.
Restored games need engine-version provenance
If generation rules change, a historical seed may no longer recreate identical holes or operators. Durable saves should therefore carry either materialized puzzle data or a generation version that tells the loader how to interpret them.
Accessibility may need an alternate linear view
For screen-reader users, the visual crossing grid can be difficult to parse. An alternate list of equations with references to shared cells could expose the same puzzle structure in a more navigable form without changing the underlying engine.
Focus announcements should include equation context
Entering an editable cell can announce row, column, current value and perhaps which horizontal and vertical equations include it. Context helps non-visual users understand why a number matters beyond its coordinate.
Mobile input should avoid covering the equation being solved
A numeric keypad placed too close to the bottom can cause the browser keyboard or controls to obscure the active row. Responsive design needs to preserve both context and comfortable targets across viewport sizes.
Large boards need careful scroll behaviour
On 11×11, forcing the player to scroll away from intersecting equations can weaken the main mechanic. The layout may need adaptive scaling, sticky context or controlled panning so a crossing remains visible while values are entered.
Difficulty copy should follow solver evidence
If future calibration starts using propagation depth or branching rather than only range and hole ratio, the documentation should change with it. Difficulty labels should describe the implementation we actually ship rather than historical assumptions.
Related-game recommendations should explain the relationship
Kakuro is related because sums cross through shared cells, while KenKen and Killer Sudoku use arithmetic in different structural forms. Recommendation copy is more useful when it names the shared constraint pattern instead of simply saying “another numbers game.”
The release criterion can be summarized as trust
Can a player trust that every gap belongs to a coherent equation network, that the board has the solution property we advertise, and that every visible configuration survives mobile, keyboard, persistence and completion? When the answer is supported by tests, available will mean something real.
Related engineering context: generation is not solving, solver contracts differ by mechanic, and Sudoku as a UI laboratory.