Dispatches From The Development Front

For a brief moment, we thought we were finally settling into stable ground after the World Partition migration and hardening work. That feeling lasted approximately five minutes. Once the World Partition side of the project started becoming stable, another realization hit. If Cinder State is going to support the kind of persistent large-scale multiplayer environment we’re planning long term, we needed to migrate away from Unreal Engine’s legacy replication system and move to Iris Replication instead (honestly we didn’t even realize it existed for a long time because it remained experimental). Which, naturally, meant voluntarily reconstructing another major piece of backend infrastructure in the middle of development.

"I am Jack's broken spirit."

Why We Switched to Iris Replication

Replication is one of the most important systems in any multiplayer game. It’s responsible for synchronizing information between the server and connected players. Everything from movement and combat to inventories, interactions, actor state, and streaming behavior eventually depends on replication behaving correctly.

Initially, the project was still running on Unreal’s older legacy replication architecture. And to be clear, legacy replication absolutely works. Plenty of successful games still use it. But after deeper testing with World Partition, large-scale streaming behavior, persistent systems, and Join-In-Progress support, it became obvious that continuing to build on the older architecture would eventually become a limitation.

At some point we stopped asking “Can we make this work?” and started asking “Are we building on the right long-term foundation?”

The Migration Process

The migration itself was not particularly enjoyable. Some systems transitioned smoothly. Others immediately broke in infuriating and surprising ways. There were several moments where replication appeared to function correctly until dedicated-server testing exposed synchronization problems that only occurred under real multiplayer conditions. Which is always fun. Nothing builds confidence like a system working perfectly right up until actual players exist.

A huge portion of the last several days has involved:

• Reworking replication architecture
• Verifying replicated actor behavior
• Validating Join-In-Progress behavior
• Correcting desync scenarios

In other words: a lot of backend work players will hopefully never notice.

Which is honestly the ideal outcome for networking infrastructure. If players are actively noticing replication systems, something has usually gone catastrophically wrong.

Testing and Verification

The good news is that the migration was ultimately successful. At this point, the project has now successfully verified Iris replication integration, dedicated server functionality, inventory/container replication, and replicated interaction systems across multiplayer testing. Several systems have now been tested repeatedly both manually and through dedicated-server workflows to ensure stability under real multiplayer conditions instead of isolated editor-only testing.

Why This Matters Long Term

The recent development work has not been particularly flashy from the outside (sound familiar?). There are still no cinematic reveals, no heavily scripted gameplay trailers, no fake “vertical slice” pretending the project is secretly finished. Instead, most of the work has focused on making sure the project’s technical foundation can actually survive long term once the world becomes more populated, more persistent, and significantly more chaotic.

Persistent multiplayer worlds place enormous pressure on networking systems, especially once inventories, streamed actors, persistence systems, infrastructure, and future gameplay mechanics all begin interacting simultaneously. A lot of recent development has essentially been preventative maintenance for disasters that have not happened yet. Which is less exciting than adding fifty gameplay systems immediately, but dramatically more important if we want those future systems to actually function reliably.

What Comes Next

Now that both the World Partition migration and Iris replication transition are successfully integrated and verified, development can finally begin shifting back toward gameplay systems and larger persistent-world infrastructure. That said, networking and replication stability remain the highest priority moving forward. At this stage of development, almost every new system eventually leads back to the same question:

“Does this actually replicate correctly under real multiplayer conditions?”

Because in a project like this, replication is not just another backend feature sitting quietly in the background. It is the foundation everything else eventually depends on. Inventories, interactions, persistence, streaming behavior, containers, player-built systems, future logistics infrastructure, all of it ultimately succeeds or fails based on whether the multiplayer architecture remains stable as complexity increases.

The goal moving forward is not simply to add more systems as quickly as possible. The goal is to build systems that continue functioning reliably once large numbers of players begin interacting with them simultaneously inside a persistent world environment. That is a very different challenge than building isolated gameplay mechanics in controlled testing environments.

A lot of games can look impressive in carefully edited trailers or short gameplay demonstrations. The real test happens later, when players begin spending hundreds of hours inside the world actively trying to stress, exploit, overload, or unintentionally break every system they interact with.

So now, with two very large pieces of the backend infrastructure implemented and verified with the future in mind, we can return to the "normal" development path.

- Greg (lead Developer)
- Logan (co-founder)

For the last several days, development on Cinder State has looked... less exciting from the outside. Development on gameplay systems and game design was completely paused. Instead, we've been deep in the kind of work that determines whether a multiplayer game actually survives contact with real players or crumbles under the pressure. And honestly? It has been one of the most important phases of the project so far.

Why We Temporarily Paused the Roadmap

A few days ago, we hit a point where we had to make a decision: Do we keep adding gameplay systems on top of the existing architecture... Or do we stop, harden the foundation, and make sure the project can actually scale? For us, the obvious choice was the latter. A multiplayer game filled with gameplay systems and flashy maps but lacking solid backend architecture is not a successful project. It's a prototype held together by optimism and temporary success.

After long hours, late nights, rigorous testing, and evaluating large-scale map performance, World Partition became the obvious direction for the long-term future of Cinder State. The scope we're aiming for simply doesn't fit comfortably into traditional single-level workflows. That meant the roadmap had to temporarily shift away from feature expansion and toward infrastructure validation. It may not be the most exciting work to the average player, but it is absolutely necessary if we want the project to scale properly long term.

Converting the Project to World Partition

One of the biggest undertakings this week was migrating the project's active maps and workflows into a World Partition pipeline. That process was not smooth. At all. For the past four days, the average time I went to bed was around 8 AM.

World Partition in Unreal Engine is incredibly powerful, but it also introduces an entirely new category of problems involving multiple systems and technologies, touching everything from cell streaming behavior and spatial loading to replication and data ownership structures. In other words, there are a lot of opportunities for things to explode in exciting and dramatic ways. I remember spending nearly six hours one night debugging why replication suddenly broke after deploying a new build. The maps loaded fine, but clients could no longer see anything the server saw.

After several long debugging sessions, we successfully converted the project's active maps into a World Partition workflow and began hardening systems specifically for large-scale multiplayer support.

The Infrastructure Work

Most of the recent work has focused on backend gameplay architecture rather than player-facing features. Some of the major systems and infrastructure currently being stress tested and hardened include:

• Multiplayer replication stability
• World-state identity systems
• Dynamic actor tracking
• Server/client synchronization
• Streaming-safe gameplay logic

We've also started building out the framework needed for future persistent world systems, which will eventually allow the world to maintain meaningful state over time. Because frankly, static worlds that never change or remember player actions get boring fast. Players discover the "meta" within two weeks and then start complaining that there's "nothing to do."

Large Scale Multiplayer Testing

The biggest milestone this week was our first successful real-world multiplayer stress test on the new infrastructure. We had six simultaneous players connected remotely to the dedicated server while testing replication, server travel, Join-In-Progress functionality, and overall infrastructure stability. The results were honestly better than expected. The server remained stable throughout the test, and several systems I fully expected to break, including Join-In-Progress, replication, and overall client connectivity, held together successfully under live multiplayer conditions.

Clients ranged anywhere from around 20 FPS on older hardware to roughly 150 FPS on high-end systems, which is a very acceptable spread for an early-stage UE5 multiplayer test running on a large World Partition environment. Most importantly, we did not encounter the kind of catastrophic networking failures that often appear once real players connect under real internet conditions.

That does not mean the work is finished. Far from it. But it does mean the project's core multiplayer foundation is beginning to prove itself under actual real-world testing instead of isolated local development. That's a major difference.

Why This Matters

A lot of multiplayer projects fail because they build content first and infrastructure second. That approach works right up until persistence breaks, replication collapses, streaming begins desyncing, or scaling exposes architectural weaknesses buried underneath months of gameplay work. At that point, teams either spend enormous amounts of time rebuilding core systems... or the project quietly dies.

We're trying very hard not to become one of those projects. So while these last few days may not have produced flashy screenshots or exciting feature reveals, they may end up being some of the most valuable work we've done so far. Once the foundation is stable, everything built on top of it becomes dramatically safer, more scalable, and far easier to maintain long term.

What Comes Next

The current focus remains on continued World Partition hardening and persistence architecture. That includes runtime world-state persistence, streamed actor safety, dynamic item persistence, performance validation, and continued multiplayer scalability testing. Once those systems are stable and verified, development will shift back toward gameplay expansion on top of a much stronger technical foundation.

It may be less exciting than announcing "we added guns with animations," but it is considerably more important if we want the game to continue functioning properly once large numbers of players begin interacting with the world simultaneously. Players are extremely good at finding ways to break systems in ways developers never expected. Building strong infrastructure early is how we prepare for that reality instead of reacting to it later.

- Greg (Lead Developer)
- Logan (Co-Founder)

Quick shout out to all of the non-developer testers who helped with today’s test:

• Bolt Action Rard
• Chungus
• Løadþ
• duckyhicks
• linus (for watching and giving input)

Thanks again for helping us stress test the project during this phase of development. Your time and feedback genuinely helped a lot.

If you've somehow landed here already, welcome to Cinder State!

This project started the same way a lot of dangerous ideas do: late nights, too much caffeine, frustration with modern multiplayer games, and the realization that most online worlds feel weirdly lifeless once you look past the surface. Everything is polished. Everything is optimized. Everything is monetized. But almost nothing feels alive anymore.

So instead of sitting around complaining about it forever like every other burned-out gamer on the internet, we decided to try building the kind of game we actually want to play. Which is honestly either inspiring or incredibly stupid. Probably both.

What Is Cinder State?

Cinder State is our attempt at building a large-scale online sandbox where players create the stories instead of just consuming scripted content and waiting for the next battle pass or server wipe timer to reset.

Our world is meant to feel unstable, reactive, and human. Not "theme park MMO" human. Actual human.

We want builders, traders, medics, scavengers, transport crews, mercenaries, industrial workers, organized groups, lone wolves, infrastructure projects, territorial conflicts, supply chains, survival pressure, weather systems, resource scarcity, and player-driven chaos all existing together in the same ecosystem.

The important part is that none of those systems are supposed to feel disconnected from each other. If resources become scarce, it should matter. If logistics routes fail, players should feel it. If someone builds something important, other people should rely on it. If a road, bridge, rail line, or supply route exists, it should exist because players physically built and maintained it.

And yes, that also means players can sabotage or destroy infrastructure. Because apparently we looked at humanity's entire historical track record and decided, "Let's replicate that online."

What We've Accomplished So Far:

The biggest milestone so far has been getting the actual multiplayer foundation working correctly. Not fake "it works in editor with two local windows" multiplayer. Real dedicated-server testing.

We now have:

• A functioning dedicated server build pipeline
• Remote player connections tested successfully across multiple states
• Join-in-progress functionality working correctly
• Replicated terminal/document systems
• Stable multiplayer sessions running for extended testing
• World partition maps successfully loading and switching
• Initial launcher/update infrastructure tests working
• Core replication architecture holding together under real-world testing

That may sound small if you're used to seeing giant cinematic trailers from AAA studios with fake gameplay and twelve years of marketing behind them, but technically speaking, this is one of the hardest foundational stages of multiplayer development.

A lot of multiplayer game ideas die before they ever survive this phase, especially projects trying to support persistent systems and larger-scale interaction.

We've also started experimenting with actual gameplay direction and world concepts instead of just backend systems. One thing we're especially excited about is the idea of player-built infrastructure.

Roads.
Railways.
Bridges.
Supply routes.

Not decorative props, but real gameplay infrastructure that matters to the economy and movement of the world. The long-term vision is for players to physically shape logistics and transportation networks themselves instead of everything being static developer-made scenery forever.

We're also exploring a voxel-based underground mining area system for rare resource extraction. The current plan is to include one contained voxel mine in the alpha as a proof-of-concept rather than trying to voxelize an entire world. Voxel mining and terrain deformation will start small in scope, with future expansion in mind.

Scope control matters. Eventually you learn that every "cool feature idea" arrives with a cost. That cost is time, work, and frustration. Each new system has to be meticulously replicated, tested, and verified thoroughly.

The Reality of Development

A lot of game development gets romanticized on the internet or through social media. People see polished trailers and dramatic music and imagine some beautiful creative process.

The reality usually looks more like this:

"Why is replication broken again?"
"Why did this work yesterday?"
"Why is Unreal Engine angry at me THIS time?"
"Who touched this setting?"
"Why does fixing one thing break six others?"

Then eventually, at 3:17 AM, something works, and for a moment all the frustration, debugging, and setbacks finally feel worth it. That's been the reality of most nights over the last few weeks.

But honestly? It's been exciting. Because this is the first point where Cinder State stopped feeling like just an idea and started feeling like an actual project with momentum behind it.

There's still an absurd amount left to do:

• Player Construction and Building Systems
• Economy Implementation and Balancing
• Survival Mechanics
• Community and Gameplay Systems
• World Systems (think Day/Night Cycles and Seasons)
• Animation Systems
• Audio and User Interface
• Networking Expansion
• Persistence and Replication
• Backend Infrastructure
• Anti-Cheat Considerations

The list basically never ends. Each system needs to be designed and developed as its own independent component, allowing it to function reliably on its own while still integrating naturally into the larger game ecosystem. But the foundation is finally starting to take shape. And that matters.

The Goal Going Forward:

Right now, the focus is not graphical perfection, pretty cinematics, or cinematic audio design. The focus is building a functional alpha that proves the core ideas actually work and are genuinely fun. Gameplay foundations matter first. If the systems are good, visuals and audio can evolve later. We'd rather have rough visuals with deep systems than gorgeous environments hiding shallow gameplay loops.

The plan over the next stretch of development is to continue expanding multiplayer stability, player interaction systems, player building/construction concepts, infrastructure mechanics, survival elements, and world persistence while slowly shaping the actual identity of the game.

We're going to document both the Diet Coke-filled, up-all-night 7 AM binge sessions where everything breaks and all we want to do is stare at crash logs in silence, and the moments where persistence finally pays off and a new system actually comes together without destroying three others in the process.

- Greg (lead developer)
- Logan (co-founder)