Pill Engine: Rethinking the Game Engine

---

Links:

• Pill Engine Home
• Pill Engine Discord

Introduction

It is time to reveal my greatest endeavour - Pill Engine, aka Pill - a modern, free and blazingly fast game engine that I have been designing and developing for many years now.

I have been working with game engines for over 10 years. I have been through the trenches of AAA, AA, indie, dozens of game jams, the demoscene, the hackerscene - oh boy, I have seen a lot. Along the way I have made a ton of extremely valuable connections and gained even more valuable knowledge, experience and perspectives. Currently, I work as a Technical Artist at CD PROJEKT RED 🐦, developing and maintaining huge-scale game production pipelines used by hundreds of amazing content creators.

With all this experience, and with all the talented people I met, I decided to embark on the endeavour of making a new engine from scratch. An engine that avoids the weaknesses, limitations and mistakes I have seen in existing engines, while taking the best ideas from all of them - features, workflows, architecture, tooling, developer quality-of-life improvements and all the small things that make working with an engine simply feel good. Then add some unique flavour to the mixture and put everything together into a single… Pill 💊

I know this may sound utopian and pretty vague for now, but bear with me :)

In this post I would like to introduce Pill, the idea behind it, the story of how it came to be, and its goals.

What is Pill Engine?

Pill Engine is an advanced game engine written in Rust.

This is not a random “yet another game engine” project. Pill is designed around a small set of very specific core values, shaped by years of experience, observations and feedback from highly experienced game developers and engineers.

Core values

• Anti-bloat, modular architecture philosophy - Pill is built to stay general-purpose without turning into a bloated, heavy or difficult-to-maintain engine. Its architecture is split into independent modules, so you include only what your project actually needs. That keeps the engine easier to extend, easier to reason about and significantly leaner at runtime. It also helps keep final builds extremely small - in some cases even below 1 MB. This lightweight foundation directly supports the next point.
• Zero-friction developer experience - Pill is meant to feel as snappy as possible. Runtime performance matters a lot, but so do iteration speed, responsiveness, developer quality of life, and the simple enjoyment of building things. Hot reloading, project sandboxing that prevents crashes from taking down the editor, fast startup and loading times, and instant feedback are treated as core engine features rather than secondary conveniences. The goal is to remove as much friction as possible between making a change and seeing the result.
• No-compromise performance - Pill is designed to support both small indie games and huge AAA-scale projects while offering extremely high performance to all of them. Its core is data-oriented and powered by a unique hybrid, archetype-based ECS architecture that aligns precisely to the way modern hardware actually works. Performance-critical code is optimized down to the assembly level, making it possible to simulate hundreds of thousands - and in some cases millions - of objects efficiently on the CPU. Importantly, this is not smoke and mirrors. Performance is continuously measured by automated benchmarks and development pipelines, so regressions can be detected instead of guessed.

Concrete goals aka flagship features

The ambitious goal is simple: fix the bad stuff and make the good stuff even better.

Of course, “all” is too big of a word. And everyone has their own opinion on what is good, what is bad, and what actually matters. Pill’s definition of those things comes from years of observations, discussions and feedback across gamedev, demoscene, hackerspaces, embedded systems and communication industries - backed where possible by research, measurements and real-world experience.

To make that ambition concrete, here is a clearly defined list of goals:

• 100% free and open source - The whole idea is to empower people to make amazing stuff. Out of passion. For the community, by the community.
• C# and Rust scripting languages - You get a real choice between convenience and maximum control. Pick C# when you want to move fast, iterate quickly and just get things done. Pick Rust when you want full low-level control, predictable performance and maximum efficiency. Both are first-class citizens.
• Hot reloading pushed to the max - Edit your code and see the changes running in around 1-2 seconds. When only functions change, reloads can be even faster - less than a single second. The goal is simple: keep the feedback loop short so everything feels instant.
• Crash-resistant with full project sandboxing - Your code has an error or crashes? The engine and editor don’t. Project code is isolated, so failures stay inside the project instead of taking the whole engine down with them. You get a clear error, fix the code, and keep going without restarting everything and waiting for the entire project to load again. Pill itself is written in Rust, adding strong memory-safety guarantees on top.
• Hybrid Entity Component System architecture - Pill is built around a high-performance, archetype-based ECS designed for cache locality, parallelism and raw throughput. Simulating hundreds of thousands of objects on the CPU should not be an issue. What is more, Pill’s ECS is hybrid. You are not forced to program in a data-oriented way. You can put logic directly into components to use a classic object-oriented style when needed, or freely mix both approaches. Underneath, the data stays packed, predictable and automatically optimized by the engine.
• Proven performance - Pill does not just say “I’m fast”, it proves it with real numbers. Each update to the engine goes through automated continuous integration and benchmarking systems. The Pill Labs initiative is in charge of benchmarks and researching dark-arts performance improvements.
• Anti-bloat, modular architecture - The engine core is intentionally tiny - holding mostly lifecycle and infrastructure logic. Everything else is a module. Rendering, physics, audio, networking, tooling. Just plug in what you need and leave out what you don’t. You can even remove the renderer completely and run Pill headless. This way we can keep the bloat and technical debt in check.
• Next-level error logs - Finally useful errors instead of cryptic walls of text. Deep, descriptive and configurable call stacks with enough context to understand what went wrong, and even with the tips on what to do in order to fix the issue.
• JSON asset format - Pill uses JSON for all the assets’ data, making them easy to read, edit, and version control. No more binary blobs that you can’t understand or modify.
• Live game + scene editing workflow - Run your game in one viewport while continuing to inspect and edit the scene in another. Changes can be made while the project is running, without constantly switching between play and edit modes. Project code is fully sandboxed, so crashes stay contained and do not take down the editor. Super convenient.
• Tiny build sizes - In the era of monstrous bloated games, builds produced by Pill can be as small as roughly 1.0 MB - that is around 1,000 times smaller than 1 GB! Small binaries mean faster downloads, faster deployment, less storage and access to platforms where traditional engines simply do not fit.
• Absolute streaming beast - It is often a case that not everything fits in memory, especially for large projects. Pill is designed to very efficiently stream huge amounts of assets, scenes and world data only when it is actually needed.
• Blazing startup times - Huge project? The editor should still open in seconds, not minutes. The target is to keep startup times in a relatively sane and healthy range even as projects become large and complex.
• Embedded device support - Pill is designed to scale far beyond desktop PCs. The goal is to run Pill projects even on constrained hardware such as ESP32-class microcontrollers with just 0.5 MB of RAM.
• Secret ingredient - There is also a meta-level advantage that cannot be revealed publicly yet. Maybe someday. Who knows?

The community

Yet, Pill is not just a software. It is a vibrant community of passionate people that want to participate in something special, learn from each other, share knowledge, build things, and simply have fun doing it.

Things do not always have to be about business. Pill engine is free and opensource. Fueled solely by passion.

Rendering engineers trying to push computer graphics domain forward? Indie developers building weird games during a weekend jam? Demosceners squeezing the binaries to unbelivable memory sizes? Everyone is welcome

Come join us on Discord and shape the future of Pill! Invitation link: Discord Pill Community

Are we there yet?

This section is updated to reflect the current state of the project.

I won’t lie - the current version of Pill does not meet all these promises yet. However, the very good news is that there is already a research project proving that the core ideas work (proof of concept). It is called “Project Golden Pill”.

Current development is focused on transferring its architecture, design and concepts into the main Pill codebase. Once that work is complete, Pill will be released as version 1.0. The targeted release date is Q1 2027.

(Future me, please put the link to the Pill v1.0 post-mortem article here)

A huge advantage of Pill is that it was started from scratch. There is no need to carry years of technical debt or work around architectural decisions made a long time ago. The idea from the very beginning was to avoid mistakes and limitations that can be observed in existing game engines by defining the architecture in a very specific and clear way before building everything on top of it.

For now, development is focused on establishing strong foundations. The shiny features will come after that.

You can find the roadmap and follow the progress here: Pill Roadmap

Motivation

Interestingly, my motivation behind developing Pill has changed several times over the years, and with each change, the vision for the project was reshaped as well. It first started as a student project, then became a pet project I worked on for fun, and eventually evolved into something much more ambitious - an attempt to address the problems I have seen in existing game engines.

Student project

Originally, Pill started as my Bachelor’s thesis project. It is also a spiritual successor to PolyEngine which was an engine I was co-developing in the “Polygon” Students’ Association of Game Developers at my Warsaw University of Technology. If you want to learn more about those ancient times, you will have to read “Origins of Pill” section at the end of this page. Pill served its original purpose (I graduated 🎓) and then, for a few years, it was left sitting in a drawer.

Pet projects

It is especially common among engineers to have a pet project that you work on in your free time. The same is true for me. I really enjoy using my skills to build something cool, so every now and then I would come back to Pill and implement a feature, experiment with an idea or change something here and there.

To be honest, at some point I realized that game engines are perfect candidates for pet projects in general. They are basically infinite playgrounds for experimentation and learning. You can explore rendering, architecture, low-level optimization, tooling, asset pipelines, networking, physics, scripting, you name it.

And what makes them different from other software pet projects, they can display nice graphics (assuming you can make nice graphics). Graphics are also something you can actually show to other people! You can show them code too, of course, but that tends to be a little more painful.

Then I realized there are even more advantages to homemade game engines projects. They are never-ending, living projects that do not have to be developed solo. They can attract a community of passionate people who share similar interests - people you can learn from, grow with, build things with and become friends with.

In general, the more I thought about it, the closer I was to the conclusion that custom game engines are the promised land of pet projects. I found this topic interesting enough that I even gave an hour-long talk about exactly that at the GDD conference in Budapest in 2025.

Someday I will link the written version of this talk here.

But yeah, I have to admit that one of the biggest reasons I develop Pill is simply because I enjoy it. It is fun. Simple as that.

The pain

That gave me exposure to a LOT of different domains, workflows and problems, and just as many opportunities to observe what people struggle with and what they actually need. And not only in game engines. I worked and seen people working with custom renderers, web development hot-reloading pipelines, hydration mechanisms, 3D printing, embedded systems, and huge production pipelines built around Blender, Maya, MotionBuilder, Substance Painter and Designer, Photoshop, Illustrator and many other tools. Pretty much all of these areas have some frameworks always used.

All of that gave me a pretty broad perspective on tooling, iteration speed and the way users think in general. And when it comes to game engines, I used them a lot, tried a lot of them. I was never fully satisfied. There was always something missing, something awkward, something too slow, something too rigid, or some tiny detail that kept annoying me.

I will not lie - I am a perfectionist. That can be both a blessing and a curse. In every engine I had the opportunity to use, I eventually found something I was unhappy with.

Sometimes these are really small things. For example:

• I love when my code crashes but the editor itself stays alive and I do not have to restart everything.
• I love when asset files are human-readable and I can just open them in a text editor, understand what is inside and change them manually if I want to.
• I love that Unity has a separate Scene view where you can comfortably keep editing the world while the game is running in the Game view. It sounds almost negligible, but for me it makes a huge difference.
• I love hot reloading that prevents me from constant context-switching.
• I love fast startup times (like everyone I guess).
• I love responsive, tactile tools where pressing a button feels instant and iteration does not constantly get in your way.

There are so many things like this. The problem is that I have never found a single engine that has all the things I am looking for. And there is an even bigger problem. Many existing engines cannot simply add features like these or fix some of their deeper issues, because those issues are often rooted in architectural decisions made years ago. At some point, changing those becomes enormously expensive. You have compatibility to preserve, projects already depending on existing behavior, tooling built around it, pipelines built around it, and years of code sitting on top of it.

Sometimes it can genuinely be easier to build something new than to replace the foundations underneath an existing engine.

This is also why maintaining proprietary engines can become incredibly expensive over time. Studios can reach a point where paying for another engine is simply cheaper than fighting years of accumulated technical debt, rebuilding entire systems or introducing something fundamental like proper hot reloading into an architecture that was never designed for it.

And this is not really specific to game engines. Any large piece of software that is developed continuously for long enough will accumulate technical debt and there are no exceptions to that.

Every engine started somewhere, with some initial assumptions, constraints and priorities. Years later, those assumptions may no longer match what developers actually want from the tool.

That is one of the biggest advantages Pill has: it started from scratch. There is no need to preserve decades of legacy decisions. No need to work around architecture designed for a completely different era. It gives me the chance to look at all these problems, all these little quality-of-life things, all the architectural pain points, and ask a very simple question: What would I do if I could design this again from the beginning?

A lot of these thoughts come from my own experience, but definitely not only from it. They are also the result of hundreds of conversations about engines, tools, rendering, pipelines and production with many extremely talented and experienced developers I was lucky enough to meet throughout my career. Still, these are my observations, my conclusions and, at the end of the day, my personal opinions.

It is very tempting to use this section to vent a little and start pointing fingers.

But I will not do that.

Pill vs other engines

Note: Pill currently in heavy development, and some features in this comparison are currently targets rather than completed implementations.

Note: This comparison reflects my own research, experience and interpretation of each engine’s architecture and workflows. Some ratings are inherently subjective and may change as the engines evolve. I have tried to keep the comparison as fair and factual as possible.

• 🔥 Standout strength / core design focus
• ✅ Strong support
• ⚠️ Supported with trade-offs
• ❌ Not meaningfully supported
  
  

Origins of Pill

Here, I would like to tell how Pill actually started.

This section probably belongs somewhere at the very beginning of this post. But I wanted to first introduce what Pill actually is and catch your attention, instead of immediately forcing you through somike to present here how Pill actually ste long, passionate story about its beginnings.

This section is mostly here for the sentiment.

Generally, it didn’t happen in a way where one afternoon I suddenly got an idea to develop a game engine, sat down at my PC and just started building it. Things in life usually don’t work this way.

Studies and Bachelor’s thesis

It was the fall of AD 2021, and the last thing standing between me and earning my Bachelor’s degree in Computer Science at my alma mater, Warsaw University of Technology, was the Bachelor’s thesis. There were tons of topics to choose from, and some of them were actually pretty feasible - a few weeks of work and the thesis could be done. But for some reason I have always been rather ambitious. I’m not quite sure why to be honest. So I thought that instead of killing two birds with one stone, I would go on a rampage and take down four of them:

• I would write my Bachelor’s thesis.
• I would make a project about something I was genuinely interested in.
• I would learn the Rust programming language.
• I would have a nice project for my portfolio.

All these things required a lot of motivation - especially learning Rust, as at the time it felt like a truly tough beast. Sometimes it still feels like that. It is hard to tame it.

However, I had discovered that I could trick myself a bit The plan was simple: declare a project with no easy way back, no possibility to change the topic halfway through, and - most importantly - a deadline, and deadlines work especially well for me. So instead of picking something like “make a small lamp that reacts to something”, I challenged myself with: “Design and Implementation of a Computer Game Engine in the Rust Programming Language”. I had worked on custom game engines and renderer projects before, so I already had some knowledge. It is also worth mentioning that Łukasz Zalewski was helping me with the project.

…aaand after five months the thesis was completed and I had something that could be called a game engine - and more importantly - something I was genuinely proud of.

Well… it definitely does not look impressive. But try to achieve it… back in the days before coding agents - ECS, meshes, textures, materials, shaders, a rendering pipeline, sound, input and window handling - all combined into a single architecture.

In projects like this, the code itself is only one part of the work. There was also an actual multi-page paper describing all the technical details, architecture, design decisions, explanations of why certain things were done the way they were, and so on. A lot of what was behind the engine came from the unique architectural ideas I had learned while helping with the development of PolyEngine in the “Polygon” Students’ Association of Game Developers.

And then there is one number from this whole story that still sounds a bit ridiculous: This thesis took me roughly 1,400 hours of work over five months. (Yes, I really counted it. Pretty precisely, actually. With an estimated error margin of around 10%.) It turned out that it was too much for one human organism and I had a pretty serious mental crash after that whole marathon, so I definitely do not recommend such hardcore endeavours.

After handing in the thesis and earning my degree 🎓, quiet times came for Pill. I focused on professional work, personal life, etc. Building a game engine is a huge investment of time and focus after all, and at that point I simply could not afford it. But I always felt this urge. I felt like I was missing a proper pet project, and I kept seeing all these issues and inconveniences of the engines available on the market. So eventually I carefully dug Pill out from the pile of things and shyly implemented some features here and there, just for fun.

Slavic Game Jam 2025

Nevertheless, fast forward to Slavic Game Jam 2025.

(You need to know that I’m a huge fan of game jams. I have attended over 25 of them, but that is a story for another article.)

I once again joined my game jam forces with Jakub “Celeborth” Duchniewicz. We are both huge enthusiasts of tinkering with custom tech, and we still very sentimental for PolyEngine, so I proposed that we make a game using Pill - almost the exact same version I had left untouched around three years earlier.

Over a single sleepless night (the day was sleepless too, BTW), we implemented centralized server networking in Pill and built a multiplayer “racing game” we called Tiny Trucks.

The moment when three instances of Pill finally connected in a multiplayer session, with the sun rising outside at around 6 AM, was purely magical. The whole atmosphere, the exhaustion, the overwhelming dopamine hit - all of it just confirmed for me that Pill was a project I wanted to keep developing. Even if only for my own satisfaction.

EuroRust 2025

Around two months later, Celeborth and I attended the EuroRust conference in Paris and came back even more hyped about the vision for Pill. At that point I knew we needed to bring more talented people into the project, so I reached out to Michał “Sp0lsh” Kłoś - another PolyEngine veteran and a very talented rendering engineer with a great artistic eye - and asked if he would like to contribute to Pill as well. And he gladly agreed!

This marked the moment when things started to get serious. I would say this is where the development of Pill as an official project really began.

A few months after that, the bigger idea for Pill started to mature in my head. Over the previous 10 years, both professionally and as a hobbyist, I had worked with many different game engines and repeatedly run into the same kinds of problems, limitations and frustrations. So I thought: why not challenge them? Why not take all those issues I had experienced over the years and try to fix them in Pill?

That changed the project significantly. Pill was no longer just a fun engine I wanted to develop for myself. It became something much more serious.

Fall of 2026

And now we are here.

Fall of 2026.

A new chapter for Pill begins.

💊