From PixelWar (r/place like) to Iron Pact, the story of Iron Pact

Hello Commanders!

It's now been some days since the game is available in Early Access, 3 nights fixing bugs without sleeping, lots of discord messages, lots of support and some criticism, lots of tasks ahead to continue to enhance Iron Pact...

In this article, I want to talk about my motivations, why do I created Iron Pact, how it all started, where are we going, and the future of the game as I imagine it at this time.

PixelWar: Iron Pact gradfather

First, let's talk a little about me, so you have context on how I was able to work on ZEvent's ZPlace (I'm going to talk about it later): I am a Solution Architect that started as a Backend & Multiplayer engineer in 2016 (tbf, I started in 2012 with a first company I created, Right'Heberg, but that's a story for another time), after getting my master's degree in computer engineering.

My first job was Multiplayer & Backend developer in a game studio founded by a french streamer named ZeratoR, where I worked on a small multiplayer game called dWARf for 3 years.

Through ZeratoR (who was my boss at the time), I was able to work, as a technical engineer for ZEvent (a caritative event regrouping lots of streamers to raise money for charity).

In 2022, ZeratoR had the idea of creating a clone of Redis r/place, but for the ZEvent. In that version of Place, you had to purchase credits through donations to charity that allowed you place pixels on the world. We gamified a little more that by adding upgrades to pixels, and for the ZEvent (this year) we even added boss fights and Achievements (you can find more about the technical side of ZEvent Place on an article I've written in 2022 https://medium.com/@alexmogfr/zevent-place-how-we-handled-100k-ccu-on-a-real-time-collective-canvas-71d3d346e0ab).

That's what gave me the idea, in december 2022, to create PixelWar: A MMORTS game where you capture pixels through troops and build on them to produce, maintain logistics routes and craft items! (looks familiar ? ːsteammockingː)

each icon is a building constructed within pixels, each pixels is captured and controlled by players, similar to our current Sectors system in Iron Pact

PixelWar was, in my opinion, a good game, but it lacked a lot of features that were inherently complicated to implement because of how I implemented the game.

[Warning: Technical explaination paragraph]

In PixelWar, everything is a background job, meaning that the main game is a big scheduler, that schedules tasks that gets executed in the background of our servers when they need to be executed.

As an example, if you start a movement from position X,Y to X1,Y1, the server will calculate the time your entity will need to arrive to X1,Y1 from X,Y, then schedule an "arrival" job to handle the arrival.

This was great for scalability purposes (I wanted to build a game where I didnt need at all an "active game loop" on the server-side, because I think first about scalability), it could handle 100k players (similar load to ZEvent's Place), but had a big flaw: It was impossible to collide entities while they are moving (without complexifying the code, and loosing all the scaling capabilities, and introduce complicated patterns that would have lead to lots of bugs to deal with), which means that intercepting moving units was not possible at the time (and so, making interception-based gameplay mechanisms (missile defence, interception squads etc) was not possible.

And, I also didn't liked the limitations that were due to having a 2D plane map, players in the corners are obviously simpler to defend than the ones in the middle, having more borders to cover.

That's why, in early 2024, I started to play with prototypes to create a hex-based 3D world.

The birth of HexGlobe

HexGlobe started as a prototype, I wanted to see what I was able to create as gameplay features with a 3D globe instead of a 2D plane.

This will obviously tackle one of the bigest problem from PixelWar: the corners and borders ability to defend themselves.

It also allowed me to experiment with real planet data (GeoJSON) to have a planet with earth-like features.

The first prototype looked like that:

It was beautiful, but had lots of performance issues. At the time, I was using ThreeGlobe to make it, and it was not really ment for a real-time game.

So I ditched it and started from scratch with WebGL. The WebGL part was made by a friend of mine (he wanted to stay anonymous, so I will not cite its name here), he made the full engine for the 3D globe rendering, thanks to him, I was able to prototype lots of gameplay features, and re-adapt the old PixelWar server for these new system.

Thanks to PixelWar, I didn't needed to start from scratch! (This is important too, because I reused the backend and frontend engine from PixelWar and HexGlobe to create Iron Pact). Here's a video of what the prototype looked like at the time (mid-2024):

Watch on YouTube ↗

But, it still had lots of limitations due to hexes: I didnt like the shape and limitation hexes offered, and I wanted to emancipate from this "one cell = one building" system, I also was still stuck with no possibilities to intercept entities while they move.

I did a lot of prototyping with this version, I tried a lot of things that I didn't liked at all. At that time, I discovered Luma (https://luma.gl/) a 3D engine for web-based apps that was very promising for the vision I had, so I decided to scrap this version for a new one, based on Luma: Thus, Iron Pact's development started (mid-end 2024).

The Iron Pact era

Luma was modern, and had great implementation of WebGL shaders, which would allow me to do things such as the current Fog of war system.

Few days later, I discovered DeckGL (https://deck.gl/) and that's what started it all: I had finaly found a great engine to make 3D globes that can be adapted for RTS games. That was the spark, DeckGL was still experimental, but I was ready to give it a try.

I experimented a lot with DeckGL, learned a lot about shaders during this time (I'm still relatively bad at making shaders, but I try to get better everyday), experimented a lot with the visuals, what I could do with the engine, what were its limitations and, most of all, what the game would feel like.

At that time, the game stack looked like that:

• The WebGL Frontend (React, Mantine, DeckGL)
• The API (NestJS, TypeScript, Postgres, Redis)
• The Workers (NestJS, TypeScript, Postgres, Redis)

The backend was an heritage from HexGlobe and PixelWar, and I still had the limitations associated with it.

So I decided to add a new backend service: Simulation.

Simulation's role was simple: It is a simple server-side 3D simulation of the full world, that simulates only the collisions and movements of entities. Nothing more.

The Simulation communicates the status of entities to the Workers, which role is to handle the gameplay state. These statuses are collisions between entities, vision entry/exit, movement ends, sector enty/exit, and so on.

This worked great, I could finally have systems that provide real-time data to my game systems, through real-time collision mechanisms: I was finally able to work on interception mechanisms (these mechanisms are now used for unit and building attacks, some projectiles are real collidable objects, that can even be intercepted mid-flight (ie. ICBM)!) any entity can now be intercepted, have a vision radius, know what are other entities in range, etc. PERFECT for real-time gameplay (we were early January 2026 when the full simulation was ready to use).

At the same time I also decided to switch to Tailwind, because I found the Tailwind style more modern for GUI, Mantine looks more like a dashboard, and I wanted to use something that has a bigger community behind it.

Now, the game stack looked like that:

• The WebGL Frontend (React, Tailwind, DeckGL, Electron)
• The API (NestJS, TypeScript, Postgres, Redis)
• The Workers (NestJS, TypeScript, Postgres, Redis)
• Simulation workers (Rust, 1 worker per active universe)

After all this engine work, I decided to focus on gameplay, from January 2026 to this day.

In July 2026, I started to share the game with friends and old players from PixelWar, so I can get feedbacks. Sadly, with that low amount of players, it was very difficult to test properly all that I added and, even if I got a lot of useful feedbacks during that time, I could not confront my systems to lots of players.

That's why I took the decision to open the game in public Early Access the 30th of September 2026. I needed more feedbacks and confront myself to real players, understand their needs, understand what needed how to make the game better.

I am not a GameDesigner or a UI/UX guy, I am a backend engineer at heart, and so I needed real-player data and feedbacks to understand what GameDesigners and UX engineers already learned during their studies: What works with final users.

That's why your feedbacks are so important for me, and that's also why my UI/UX looks really bad, I try to enhance them day after day, but it is still something I am learning on the fly and I am not that good at for now!

My current main focus, is to enhance as much as possible the new player's experience. I already got lots of feedbacks and help from our current codebase (I am very grateful for that, thanks everyone <3), and I need to work towards better, more solid and stable systems, and a complete rework of the Tutorial, to make it simpler for new players to enjoy the game. That's my short-term focus right now, after having stabilized the servers as much as I can.

The future of Iron Pact

Iron Pact is currently in a weird state: Because of my design choices (everything is a background job) I am making lots of database calls to my database, that can be avoided if I move more systems directly to the simulation worker instead of having them processed by external workers.

The Simulation should be my source of truth instead of my database, to avoid having calls to my DB.

That generated problems during peak hours when the game opened, lots of disconnects and server issues. That was because of the load that strained the database.

I did fixed it by scaling up my database, but it is not a long-term solution, and I need to find a proper long-term solution for it (the best candidate right now, is to move most of the gameplay logic directly into the Simuation workers and query the workers when I need hot data, keep the database for cold data).

That's a major undertaking and I cannot underestimate it, it will take me a LOT of time to implement properly, and to have a 1:1 version with the current in-game systems. I hope to have a fully functionnal implementation of it at the start of 2027, hopefully Q1.

Let's talk about features now:

I am someone who puts the community first, I love receiving feedbacks and work with my community to make choices for the game, this game is an MMO, by definition, it lives through its players, and I love the Schedule-I approach of making the community choose for the next features.

That's why I want to set up a way for the community to vote for the next features I will work on. These can be community proposals (through the #feature-requests channel on Discord) or my own proposals.

I hope to be able to deliver at least one new feature per month (I am talking about gameplay features, not enhancements, which are simpler to implement).

Hopefully, this will allow the community to shape the game with me to their liking. I have my own ideas, but confronting them with the rest of the community and the player's ideas is even better. I want to shape the game for the community to enjoy it, and build around this base to make it an enjoyable game.

About monetization:

Right now, I have no plans to monetize the game during the Early Access, it's not the goal of an Early Access to make money, and it's not my goal with that game in general.

I plan for the Early Access to last at least a year, so we have time to discuss with the community about how the game should be properly monetized.

I have one request tho: I will always refuse any proposals for P2W system. I dont like them, I dont want to make the game P2W, and I dont want it to be Pay 2 fast either. I want to keep the gameplay intact and balanced as much as possible.

Furthermore, I will not implement monetization mechanisms if the community remains small, if I can still payout the server cost myself without it being too costly, I will not implement any monetization system, but if the community grows, I might need to implement it to pay the bills. I dont want to introduce unncesseary monetization if it is not aligned with what the community wants.

That's all folks, hopefully this post will allow you to understand a little more why did I started Iron Pact, and what's the passion driving this project!

Thank you for reading, I hope to see you soon on Discord (https://discord.gg/MUUxP2Uthg), joining our community to make this game even better!

It's already been a big surprise for me, I wasn't planning to have 1600 players already, I am already very happy about this early state of the community.

Thank you everyone, see you on Discord and in-game!

AlexMog

PS: Sorry for my english, I am French