One clear mechanic before extra features
Each MiniWins page begins with a small rule that can be stated without a tutorial video. Match two known positions. Hit a target before it expires. Complete a row without gaps. Bracket an opposing disc. Stop an enemy before it reaches the fortress. If the objective cannot be expressed clearly, more visual effects will not rescue it.
The second step is to define state: what the game must remember during a turn, a round and a later visit. Memory Game tracks revealed positions, matched pairs, time and mismatches. Neon Blocks tracks a board matrix, the current piece, the preview piece, score, lines and level. Neon Fortress has longer-lived run state for waves, health, coins and upgrades, plus a separate local cosmetic collection.
Keeping those lifetimes separate prevents accidental promises. A score submitted to a leaderboard is not the same thing as a saved game. A cosmetic unlock stored in the browser is not an account purchase. A local two-player win counter is not a global statistic. The interface and the written guides identify those boundaries.
HTML elements and canvas solve different problems
The collection uses ordinary HTML for menus, instructions, buttons, status labels and most board interactions. This keeps text selectable and makes responsive layout possible with CSS. Games that update many visual objects or draw continuous motion use canvas for the play field while leaving controls and explanations in the document around it.
A game loop updates state first and draws the result second. Time-based movement uses elapsed time where continuous speed matters; turn-based boards only update after a legal action. This distinction avoids wasting a continuous animation loop on a game that is waiting for a player, while action games can keep enemies, projectiles and collisions synchronized.
Why no third-party game frames? Owning the playable code makes the rules, input, data flow and fixes auditable inside one project. It also allows every game page to include an accurate guide instead of a copied catalog description.
Input is translated into game actions
Mouse, touch and keyboard events should not each contain a separate copy of the rules. They are translated into actions such as move left, rotate, reveal, aim or fire. The game then checks whether that action is legal in the current state.
Neon Blocks is the clearest example. Arrow keys and on-screen controls call the same movement operations. Rotation is accepted only if the new block positions fit inside the board and do not overlap settled cells. A hard drop repeatedly checks the next row until the piece reaches its landing position. Pausing blocks play actions without changing the score.
Pointer games convert a screen coordinate into a position inside the play area. That conversion must be recalculated from the current element size because the same game may be played on a narrow phone or a desktop monitor. Touch targets and buttons also need enough spacing to avoid turning a control problem into artificial difficulty.
Input support is not uniform yet. The accessibility and controls guide documents which games currently support keyboard, pointer and touch, plus known limitations. Publishing those limits is more useful than claiming that every interface works equally for every player.
Scoring should describe the intended skill
A scoring formula is part of the game design, not only a number displayed at the end. It tells the player which trade-offs the game values.
| Game | Primary comparison | Design intention |
|---|---|---|
| Memory Game | Lowest time plus mismatch penalties | Reward speed without making random rapid guesses optimal. |
| Extreme Aim | Highest score within one difficulty | Keep target size and lifetime comparable; reward controlled combos. |
| Neon Blocks | Highest score | Value line clearing more as the level and fall speed rise. |
| Ball Explosion | Highest level, then score | Prefer sustained progress over farming points on an earlier stage. |
| Neon Fortress | Highest round, then enemies defeated | Measure survival first and combat output second. |
| Tic Tac Toe / Reversi | Local result only | Keep same-device board play simple and free from unnecessary identity data. |
Difficulty-specific boards matter in Extreme Aim because Extreme targets are smaller, disappear sooner and have a larger base value. Combining those results with Easy scores would create a list of numbers that look comparable but are not.
Optional identity and limited persistence
A MiniWins account is not required because there is no account system. When a supported game offers a public ranking, a player may choose a nickname or continue as a guest. The nickname is validated and is intended to be a public label, not a request for a real name.
Leaderboard submissions send only the fields needed to compare the result for that specific game, such as difficulty, score, cleared lines, level, round or defeated enemies. The server keeps a best result under the relevant rules instead of building a history of every attempt. Network addresses are not stored in the ranking tables.
Local storage has a different role. It can remember the selected visual theme, an optional nickname and game-specific items such as Neon Fortress cosmetic unlocks. Clearing site data removes those local values. The privacy policy lists the categories and purposes in detail.
This separation also improves failure behavior. If the ranking service is temporarily unavailable, the game can still be played as a guest. A public leaderboard is an enhancement to the game, not permission to start it.
Performance is a gameplay requirement
For a browser game, a delayed input or unstable frame rate changes the difficulty. The project therefore avoids a general application framework for the game logic and keeps each title self-contained. Assets are limited, interfaces are drawn with CSS or canvas, and the game pages do not wait for the ranking response before allowing play.
Continuous loops should do bounded work: update visible entities, remove expired objects and draw the current frame. Timers are cancelled when a round ends. Board games avoid redrawing unrelated interface sections after every move. Responsive CSS uses the available viewport instead of serving a second mobile page with separate rules.
These choices do not guarantee identical performance on every device. Older phones, power-saving modes, browser extensions and large zoom levels can all change timing. That is why rankings are best treated as friendly comparisons, not standardized measurements of human reaction or cognitive performance.
The release checklist
A playable build is not finished when the winning condition works once. Before a game or substantial update is treated as complete, the current checklist covers the following paths:
- The objective, controls, scoring and end condition can be reproduced from the written guide.
- Restarting clears run state without deleting unrelated local preferences.
- Guest play works when a nickname is absent and a ranking failure does not block the game.
- Touch and desktop layouts fit common narrow and wide viewports without hiding critical controls.
- Illegal board moves, overlapping pieces and actions after game-over are rejected.
- Text remains readable at browser zoom and links can be distinguished from surrounding copy.
- Canonical URLs, page descriptions and structured data identify the public page accurately.
- Privacy, contact, terms, accessibility and guide pages remain reachable through normal links.
Automated checks catch broken local links, missing canonicals, invalid structured data syntax and accidental loss of the editorial guide blocks. Manual play is still required for timing, feel and visual behavior.
What each game taught the project
Memory Game showed that an error penalty must be visible in the guide; otherwise a fast raw time can look better than the stored result. Extreme Aim showed that difficulty labels are not enough—leaderboards must be separated when base values and target behavior differ. Neon Blocks made the next-piece preview a design promise: the player receives information that should support planning.
Tic Tac Toe demonstrated how one changed rule creates a genuinely different game. Limiting each player to three pieces and adding unrestricted movement prevents the familiar nine-square ending, but it also makes an explanation essential. Reversi reinforced the value of legal-move highlighting and automatic passes. Ball Explosion and Neon Fortress both showed why progress needs priority over a secondary score when the real challenge is reaching later content.
The next work is less glamorous but important: improve keyboard access beyond Neon Blocks, provide more non-color cues, continue measuring mobile layouts and keep documentation synchronized with the playable rules. Those items are recorded openly in the accessibility notes.
Read the rules or try the implementation
The guide library links to the exact rules and strategy section for every title. The Strategy Lab uses those scoring systems in practical drills. To test the implementation directly, return to the complete MiniWins game collection.