During the first stage of Blupoli Puzzles we spent a lot of energy expanding the catalogue, trying different puzzle families and learning what should be shared between games that do not resemble one another. That work gave us engines, reusable components, onboarding, localization and an architecture capable of supporting many mechanics. But a platform is not defined only by how many things it contains. It is defined by what happens between one session and the next.
This week we focused on that connective layer. The Home page no longer simply displays cards. The progress area no longer simply counts plays. Underneath both, games have started producing normalized results that the platform can understand without knowing the internal details of every engine.
Home stops being a front page and becomes a lobby
The new Blupoli Puzzles Home is built around a more useful question than “what games do we have?”: “what do you want to solve today?”. It looks like an interface change, but it actually changes the role of the entry page.
It can now bring back recent games, favorites, local recommendations and small selections that change with the day. It also surfaces continuity through streaks, activity and direct access to progress. All of this works locally in the browser and does not require an account.
Keeping it local-first is deliberate. We want the platform to be useful from the first session, before introducing registration, profiles or synchronization. An account can add value later; it should not be a prerequisite for the basic experience to remember what you just did.
My Progress is now a dashboard, not a counter
The second piece is the new progress dashboard. We could already keep simple aggregates such as plays, wins, times and activity. The new layer adds detailed history, evolution, records, activity by day and data export while keeping the browser as the primary source.
This changes the relationship between games and the rest of the product. A session no longer disappears when the board closes. It can become part of a history: what you played, when, how long it lasted, whether you finished it and which measurements made sense to keep.
The system is designed to grow without inventing history. Previous aggregates remain available, but we do not manufacture dated sessions or durations that were never measured. Detailed history starts when we can actually record it.
The invisible change: every game starts speaking the same language
The most important technical change in this batch is probably the least visible. We introduced a shared contract called GameResult. Its purpose is easy to explain: every game can have completely different rules, but when a session ends it should be able to describe the outcome in a structure the platform understands.
That result can say a puzzle was solved, a competitive session ended in a win, loss or draw, or an attempt was abandoned. It can include duration, moves, hints, resets, board size, difficulty, puzzle identifier and score when those measurements exist.
Mechanic-specific data is not forced into one enormous universal schema. Each game can attach serializable metadata for information that only makes sense in its own domain. That keeps the core stable without pretending PolyPivot, Sudoku and Ataxx need exactly the same statistics.
Recording abandoned attempts matters too
A progress platform should not confuse “opened the game” with “completed it”. The shared host opens a platform session when a game mounts and can close an unfinished attempt as abandoned when someone navigates away.
That distinction makes future statistics more honest. It also helps us understand friction: a puzzle that is opened repeatedly and abandoned immediately tells a different story from one that is completed frequently.
Persistence uses a durable queue before writing detailed history into IndexedDB. The goal is to reduce the chance of losing the last result when a tab closes or navigation happens just after completion.
Why build this before accounts?
A few days ago we asked whether daily challenges and streaks should wait until registration and profiles existed. The useful answer was to separate two problems that initially looked like one.
We do not need an account to measure a session correctly. We will need identity when we want to synchronize progress across devices, recover history from another browser or associate community systems with a person.
That is why the current architecture prepares the ground without pushing the product ahead of itself. Detailed history remains local. Results have stable IDs and a versioned schema. The documentation already maps a future Firebase Auth and Firestore synchronization path, but remote sync is intentionally not part of this release.
The benefit is important: when accounts eventually arrive, we should not need to teach dozens of engines how to save their results again. A synchronization layer can work with the same contract that already powers the local dashboard.
One integration point for what comes next
When a normalized result is safely accepted into local persistence, the platform emits one shared event. It sounds like a small implementation detail, but it prevents one of the most expensive growth problems: coupling every new feature directly to every game.
A future achievement system can listen for results. An official daily challenge can mark a specific session. A streak system can consume activity. A remote sync service can upload results without knowing how each engine renders its board.
The rule we want to keep is simple: games describe what happened; the platform decides what to do with that information.
And yes: PolyPivot is now part of Blupoli
Alongside these platform changes, a new game arrived. PolyPivot is an original Blupoli spatial puzzle built around polyominoes that can only move by rotating around one or two pivots.
Some pieces have two axes, which lets them “walk” across the board by alternating rotations. Overlaps are allowed while solving and are shown by visually mixing the colors of the pieces involved. The final goal is to fit everything inside the target frame without gaps or overlaps.
PolyPivot deserves its own story, so we will not repeat it here. We have already published the dedicated PolyPivot article in Spanish, covering the mechanic, reversible generation, dual pivots and the design decisions behind the game.
A new game also tests the new platform
PolyPivot has another value: it forces us to verify that a new title enters Blupoli through the current contracts rather than through inherited exceptions. It has onboarding, localization, shared-host integration and the same requirement as every available game to produce results compatible with the common layer.
That is exactly what we mean when we talk about turning Blupoli into a platform. Adding a game should mean building its mechanic and its specific character, not solving navigation, progress, persistence, translations and statistics from scratch again.
Home, dashboard and GameResult are one story
Seen separately, these changes can look like three features. Together they form something more interesting.
Home helps decide what to play and remembers context. The engine runs the session. GameResult turns the end of that session into shared information. The repository keeps it. The dashboard turns it into a readable history. Future layers — challenges, achievements, accounts or synchronization — can then sit on top without drilling into each individual game.
That journey is the difference between having many experiences inside one website and starting to have a product that connects them.
We are still avoiding systems we do not need yet
Preparing the architecture does not mean we are immediately turning on registration, public profiles, leaderboards or cloud sync. We still have games to complete and review, designs to define and foundational product work to close.
We would rather use this stage to ensure that data is born correctly at the source. When we add identity, we want it to solve real problems — cross-device continuity, recovery, personalization or community — instead of existing simply because a platform is “supposed to have accounts”.
What changes today for players
The most visible improvement is that Blupoli Puzzles now has a much more play-oriented entry point: recent games, favorites, recommendations, daily selections and progress shortcuts. The second is that the statistics area can start providing a richer view of activity.
The third will take longer to notice, but it may unlock the most possibilities: from now on we have one common way to understand what happened in a game session.
That contract is not a flashy feature. It is infrastructure. And precisely because of that, it can become the foundation for many visible features without requiring a different integration for every puzzle.
The next stage of Blupoli looks less like adding cards
Recently we explained that we wanted to move from “more games” to “more finished games”. This update continues the same idea. Platform maturity does not depend only on how many titles are available, but on how much they share when sharing makes sense and how much identity they can retain when it does not.
PolyPivot adds a new mechanic. The lobby improves discovery and return visits. The dashboard turns activity into continuity. GameResult creates a shared language. They are different pieces of work, but they point in the same direction: making Blupoli Puzzles a broad collection without feeling like a pile of isolated projects.
If you want to follow the more technical side of the work, we will keep documenting it in Devlog. And if you are interested in the new game, the best next read is our dedicated PolyPivot article.