Hello Citizens,
We hear you, and we know many of you are eager to see more mechanics and features from Frostpunk 1886. As mentioned in our previous update, we’re currently focusing on the artistic side of development and giving you a glimpse behind the scenes. We already have plenty in the works and will start revealing more in 2027, once everything is properly polished and ready to show.
Today, we’re focusing on another important topic: our transition from the self-developed Liquid Engine to Unreal Engine 5.
To help explain this change, we invited Aleksander Kauch, Technical Director, a long-time friend and member of 11 bit studios who worked extensively on the Liquid Engine that powered the original Frostpunk.
Aleksander will share his experience with proprietary engines, the challenges of developing and maintaining them, and why studios increasingly turn to commercial solutions like Unreal Engine 5.
So, let’s hear from Aleksander!
What is a custom engine, and what is our story with it?
A custom engine is a game engine developed in-house by a game studio and not available for commercial use. It is built to meet the specific needs of the games the studio creates. In contrast, commercial or "ready-made" engines such as Unreal Engine and Unity are designed to support a wide variety of games and therefore aim to be as versatile as possible. Liquid Engine was the foundation of every 11 bit studios game, and It's worth remembering that when development of Liquid Engine began, the industry looked very different. Commercial engines were far less common and offered significantly fewer features than they do today. Fun fact: it was written mostly by one person - Bartosz Brzostek - during many lonely nights with a glass of liquid keeping him awake, if you know what I mean.
Aleksander has worked with it for many years and is now developing Frostpunk 1886 on UE5. Why did we shift our development strategy?
There were two things that made Liquid Engine inoperable for us anymore: The first was trying to refactor everything at once - a new UI system, a new tools interface, additions to the serialization system, and new object management. Those features were not production-ready when we needed to start production of Frostpunk 2. The engine became unstable and almost impossible to work with. The second was trying to make the engine a jack of all trades — something capable of supporting every genre, from strategy games to third-person action-adventure games. This was simply not possible within our budget and capabilities. Moreover the industry shifted towards commercial engines, and we couldn't effectively hire people who wanted to work with a custom engine, especially artists. In general, developers want to keep improving their skills in widely used technologies rather than learn an in-house engine specific to a single project or company. I think that when the time came, it was a practical necessity. We made some mistakes when choosing a strategy for Liquid Engine. Instead of keeping its focus on strategy games, we wanted to make it universal. This led to an unstable engine that we couldn’t fix within our production timeline. Moving to Unreal Engine gives us the opportunity to develop more versatile games, but in the case of Frostpunk 1886, it requires some additional work to turn it into a proper strategy game engine. When I look back Liquid Engine was a fine piece of technology, and most of us, especially programmers, loved working with it. The thing I miss most is that Liquid had text-based assets, while in Unreal Engine everything is binary. Keeping configuration files and asset parameters in plain text — in our case, XML — makes development much easier than keeping everything in binary format, which is hard to merge and impossible to read with your own eyes.
So, how does Frostpunk 1886 benefit from it exactly?
In many ways. First of all, it’s a well-known technology in the industry, so finding developers to hire or co-dev teams to work with is much easier. Unreal is also a mature technology, so we don’t need to implement new rendering features or build various tools ourselves. Instead, we can fully focus on reimplementing the game in a new way - not only adapting it to Unreal, but also finally making it extensible and moddable. That said, still many features need to be rebuilt differently. The AI system in Unreal Engine works very differently from Liquid’s. The same goes for save compatibility, the user interface, ECS architecture (code architecture allowing to focus on processes in the game instead of individual objects), and many other systems. Basically, every core system needs to be reimplemented. What we try to keep intact are gameplay logic systems such as the economy, citizen states, story events, etc. But even those need to be adapted to the new engine.
What are the challenges of transitioning from Liquid Engine to UE5?
The biggest challenge isn’t really related to one technology or the other. It’s the specific requirements of this project - we need to effectively transfer the gameplay logic from Liquid Engine to Unreal Engine while also making the game moddable and ready for future expansions. It’s a constant balancing act between preserving the old ideas and rewriting them to make them more flexible. It’s a struggle, but it’s definitely not impossible. Our goal is to make the game feel like the original. We want players to look at Frostpunk 1886 and say, “That’s how I remember it! Nothing has changed!” and then, when they actually compare it to the original, see a huge upgrade in quality.
How important is the underlying engine to a game's creative vision?
Aside from that, a video game is a work of art. The engine is just the canvas and the paints. There are plenty of unique paintings created with oil paints on linen canvas. Let’s look at the rendering system. There is something often referred to as the “Unity look” or “Unreal look” because the rendering system is responsible for the final look of the game, and there can be similarities between games using the same engine. However, some games are able to use the same technology and still achieve a very unique art style, despite relying on the same renderer. The principle applies to all other technical aspects of a game.
How have coding and technology evolved over the years?
The core principles of good programming haven’t changed much. Of course, we have new technologies, new trends, and new ideas, but writing quality code remains largely the same. It’s getting easier and easier for programmers to actually start making games - back in the day, you had to work really hard just to make a pixel move on the screen; nowadays, it’s like three lines of code. One of the challenges we’re facing right now is how to properly handle generative AI. We want to strike the right balance while using AI, where it genuinely increases the speed and efficiency of our work, while at the same time maintaining full control over the solutions. We should understand the code and decisions generated with the help of AI, consciously control, and verify them ourselves. Personally, I’m focused on expanding my toolbox of known patterns, architectures, and specific solutions that I can apply to every project I work on.
Are there any games you’ve looked at and thought, “Wow, this coding is awesome”?
I haven’t seen the code of many projects, so keep in mind that my opinion is based on presentations and articles rather than the actual implementations. :D I think I’m always impressed by modular architectures that give designers as much freedom as possible. I was particularly impressed by the StarCraft II engine and map editor, which allowed the community to create an actual MMO like World of Warcraft using StarCraft’s engine. That is simply amazing. Minecraft, even the original, and Paradox games are also very impressive in that regard. In terms of game architecture, I’ve seen the ECS implementation in Overwatch - a pretty clever approach. I also like the idea of having an in-house engine underneath a commercial one - imagine Liquid Engine with Unreal handling the rendering and editor at the same time! I also love smaller games and the ideas behind them. Baba Is You has a clever architecture for handling its game rules. Kingdom has a cool water reflection effect. Dead Cells has an amazing character movement system. And let’s not forget the classics! Another World with its revolutionary virtual machine approach, and Doom, which can be ported to everything from modern consoles to calculators and washing machines.
How do you think the future of game engines will look?
I think most games will use commercial engines. They make development easier and let developers focus on gameplay features rather than the technical infrastructure behind the game. That doesn’t mean custom engines will die, though. Keep in mind that behemoths like Rockstar, Ubisoft, and Activision use their own technologies. Smaller indie teams that like to experiment with gameplay (and the technology behind it) will also continue to use custom engines.
Can you share what you're playing currently :D?
Rogue Trader and Quake: Dawn of the Machine on PC, 007 First Light on PS5, and Darktide and Heroes of the Storm with friends. Oh, and we’re going to play The Lord of the Rings: War in the North Legacy Edition in couch co-op on PS5 with my wife =).
Voices of the City
As with every upcoming episode, the City is calling for your feedback! If you have any questions, suggestions, or ideas about this update, share them in the comments or on our Discord channel! Stay tuned, Citizens. And remember:
The City Must…
~ 11 bit studios Team