First Playable: What Shipped and What Did Not
All News

First Playable: What Shipped and What Did Not

8 min read

We called it a playable. That was generous. What we actually had at the end of April 2025 was a build where five of the eight systems we considered core were in a state that a reasonable person might describe as functional. The other three were embarrassing. We shipped it anyway, by which I mean we handed it to ourselves in a controlled internal session and played through it with the explicit goal of documenting everything that was broken. This is that documentation.

I want to write this up honestly because game development retrospectives tend to select for the positive. Studios publish postmortems about challenges they overcame, not about systems they built to placeholder spec and shipped internally anyway because they needed external pressure to expose what was actually wrong. We are trying to be the kind of studio that writes the second kind of post.

What Worked

The networked architecture held. This was Lena's work across the first eight months and it was the thing I was most anxious about going into the playable session, because everything else depends on it. We ran sessions of up to eight clients against the internal build server and saw tick rates stay consistent above 60Hz throughout. There were latency spikes under connection stress that we documented but were not surprised by. The architecture was sound. The tuning was not finished, but the foundation was solid.

The basic movement and combat mechanics were playable in the direct sense: they did not interrupt the experience. A player could move, aim, fire, and navigate the environment without hitting friction points severe enough to distract from what we were actually trying to test. This sounds like a low bar and it is. But a first internal playable where the movement controls feel wrong is a session where nobody can give you useful feedback about anything else. Movement working cleanly was the necessary foundation for the rest of the session to be useful.

The core AI adaptation mechanic, which is the whole reason this studio exists, worked. Kofi and I played against it for a combined four hours on playable day. Both of us felt the adaptation. Both of us independently arrived at moments where we noticed the opponent was countering something specific about how we were playing. Both of us changed our approach in response. That feedback loop, that sense of being read and countered and then having to think about what you were doing differently, was present and real. It was not polished. The tells were too visible. The adaptation timing was not calibrated. But the mechanic worked and produced the experience we were building toward.

What Did Not Work

The matchmaking system was a stub. Not a rough version of the system we are building. A placeholder that assigned players to matches based on a static skill bucket and nothing else. We knew this going in. The real-time skill reading that we consider a core pillar of the game was not in the build because it depends on infrastructure that was not ready. The placeholder did what we needed it to do, which was put players in a match, but it did not give us anything useful to test about matchmaking.

The map was one environment, which was intentional, but that environment had significant geometry issues in the northern half that Yuki had flagged in the week before the playable and we had not fixed. Players consistently used a sight line in that area that the map was not designed to support, because the collision geometry was not complete. It made about thirty percent of rounds play out in a way that did not reflect the intended map design. We documented every round that used that sight line and excluded them from the adaptation data analysis, which was the right call, but it meant a third of our playable session data was partially compromised.

The feedback instrumentation was insufficient. We had built basic telemetry for player position and engagement outcomes. We had not built the observation infrastructure we needed to track what the AI was actually doing at the moment of each engagement. The result was that we could see what happened during the session but not why the AI made the specific decisions it made. That gap meant we could feel whether the adaptation was working but could not easily debug the cases where it was not. We spent most of the post-session analysis reconstructing AI decisions from player position data, which is backwards from how that analysis should work.

Why We Shipped It Anyway

The short version is that we needed the pressure. For the three months before the playable, we had been in a development mode where it was easy to reason about why any given system was not ready to test. The matchmaking system needed the real-time skill reading first. The real-time skill reading needed more instrumentation to validate. The instrumentation needed the map geometry to be stable first. Every dependency was real, and every dependency could justify three more weeks of internal work before the first test.

The playable forced us to cut that loop. We picked a date, accepted what was and was not going to be ready by that date, and committed to running the session with what we had. The stub matchmaking and the incomplete map geometry were not ideal. But the session gave us three concrete things that months of further internal development would not have: direct behavioral data from ourselves playing under conditions we had not controlled, a specific list of geometry bugs that would have been nearly impossible to identify from code review, and a calibrated answer to the question we had been avoiding: did the core AI adaptation mechanic produce the experience we were building toward?

It did. That answer was worth the embarrassment of the stub matchmaking and the broken sight lines. We shipped the playable because we needed to know, not because we were ready.

What Changed After

In the three weeks following the session, we fixed the map geometry issues, rebuilt the AI decision logging to capture the information we needed for post-session analysis, and started the architecture work on real-time skill reading that the matchmaking system requires. None of those things would have been prioritized correctly without the playable to expose why they mattered.

We are planning the next internal session for later this summer, with a wider participant group. We will write about what we find when we get there.