Q1 2026 Dispatch
Welcome to the third quarterly dispatch. This update follows directly from the Q4 effort to push the build toward a more coherent playable slice and bring its systems closer to a single version of the truth.
Before we begin, I would like to clarify that I’ve previously referred to this build as a web MVP, but as the project has matured, a playable prototype has become the more accurate term. While the prototype is deliberately being developed with a web stack to allow for faster iteration at this stage, the primary purpose is to de-risk and validate The Vizier’s core experience before full production. As a result, systems and mechanics are subject to change, and its current visuals are temporary rather than representative of the game’s intended final visual direction.
Q1 at a glance
-
Company: No major operational changes this quarter; focus remained on product execution.
-
Websites: No major public-facing site changes.
-
Community: No major outreach push yet; broader exposure still depends on the build reaching a stronger level of cohesion, presentation, and player role/fantasy.
-
Production: Major cohesion pass across simulation, UI, and player feedback, alongside early restructuring of labor, needs, and household sentiment systems.
-
Direction: Continued commitment to the web prototype as the fastest validation environment, while reworking parts of the project’s internal spine to better support the long-term design.
The Quarter In Reflection
Q4 was about getting the board on the table and making the first major systems interact. Q1 was about finding out which parts of that structure could actually survive contact with rigorous testing.
As the quarter progressed, it became increasingly clear to me that some of the project’s underlying assumptions were no longer a good fit for the game I am actually building. Earlier prototype decisions had their purpose, but deeper implementation started exposing where some of those inherited assumptions were now creating friction instead of clarity. Part of Q1 therefore became a broader refactor of the project’s internal spine, affecting how systems resolve, how the city evolves over time, and how future layers of the game will sit on top of the simulation.
It’s also worth mentioning that narrative did not disappear from the quarter. Some time in Q1 was spent shaping early narrative and character direction, both from a writing standpoint and from a structural one, and the deeper refactor now underway is helping clarify what kinds of narrative opportunities the prototype can realistically support.
What Changed In Q1
The central theme of Q1 was cohesion, and it included meaningful changes across simulation, player feedback, and how the city communicates with the player. Earlier assumptions around the needs of the people (food and clothing), their household conditions, neighborhood structure (interfaith relations), and player-facing sentiment were revised so the city behaves in a way that is more coherent internally and more legible externally.
That effort also touched the interface more directly. Parts of the UI and UX were revised, new feedback surfaces like the alert system began taking shape, and older patterns that were adding confusion rather than clarity were simplified, removed, or rebuilt.
In parallel, further work was done on early labor and population systems, including more directed worker assignment and the first movement toward migration-oriented levers. Much of this remains first-pass territory, but it reflects the broader Q1 push to make the prototype easier to read, easier to pressure-test, and easier to refine.
Placed side by side, these two overview screenshots show how the prototype’s presentation evolved from Q4 into Q1. The core city logic is still present, but the newer layout does more to surface the city’s state in a readable and structured way through a stronger top bar, a new alert system, and a more developed living quarter panel. In a way, it was less about adding complexity for its own sake, and more about making the prototype’s existing systems communicate with greater clarity and cohesion.

The production view above shows that same direction applied to a more specific system. This first-pass textile workshop panel is designed less as a static info dump and more as a diagnostic view. The updated panel layout now surfaces worker assignment, output state, production mode, and missing inputs in one place, while the wider HUD and world-space elements help show how local production problems connect back to the city as a whole.
Measuring The Work
As in the previous dispatch, I’m including development metrics not as a KPI, but as a way to make invisible work more legible. The chart below shows code churn on the main branch by runtime area across Q1, measured as lines of code added plus lines removed. It should not be read as a measure of quality, progress, or project size in isolation.

What this chart shows is where the prototype was actively changing, which matters in a development quarter shaped less by flashy new surface features and more by rewiring, refactoring, and consolidation. The clearest signal is March, where the heaviest churn landed in UI & HUD, State & Data, Tests, and Infrastructure / Other. That lines up with the real focus of the quarter around improving legibility, restructuring underlying logic, and pressure-testing the prototype’s foundations.

The second chart above adds context to the blank month on main in February. This month was largely a recalibration month, and much of the work that did happen was done in long-running branches rather than merged directly into main. Some of that work only landed in March, which is why March appears unusually dense in the churn chart above.
In other words, these charts taken together show a development quarter defined less by steady outward expansion and more by integration, correction, and consolidation. That kind of work can look quieter from the outside, but at this stage it is the work that matters most, because it determines whether later milestones are built on something durable or on a stack of assumptions waiting to collapse.
Looking Ahead
The journey so far continues to confirm a real challenge that is likely to remain part of this project for some time: I need to get the build playable enough to support funding and broader validation, but getting it to that point still requires difficult design decisions under real time and resource constraints. AI-assisted programming helps me implement faster, but it does not remove the slower work of designing, testing, and sometimes rethinking systems that do not hold up once they are exercised. Some of the milestones I had hoped to reach by the end of the quarter, especially around narrative, have therefore moved back while the foundation continues to be strengthened.
Despite the frustration, I’ve learned a lot about what works and what doesn’t, and I think all of this made the path forward clearer. The prototype is not where I want it to be yet, and some of what exists today will survive into production more directly than other parts. But the project is in a more honest position than it was at the start of the year, and that is the condition it needs to be in if later progress is going to last.
With all that said, the immediate priority now is to finish stabilizing the cohesion work underway so the next layers of development rest on a clearer and more durable foundation. In parallel, early narrative and character work will continue taking shape, both creatively and architecturally, with the goal of making the vizier role more directly felt in the playable slice. Beyond that, the project still needs more tuning, more balancing, and more pressure-testing before it reaches the level of clarity I want.
Thank you for following along and for reading the third quarterly dispatch.
Sincerely,
Mohammad
Links: Founder LinkedIn | Mizan Interactive LinkedIn | The Vizier | Community Discord