PRDeving

How to Write a Physics System for a 2D Engine: Dynamics, Kinematics, and Motion in ECS

Welp, it’s Sunday again. Some weeks later but I haven’t abandoned my new project (yet). So here we go with another post nobody asked for.

Every game has physics, even if you don’t treat it as a first-class citizen. Mine does.
I’ve spent some weekends building small chunks of systems and started separating my project into core, client, server, and engine layers.
Naturally, one of the first things that popped up on the engine side was a very primitive physics engine. So here we are.

In this post, I’ll walk through how I’m building the physics foundation for my 2D ECS engine in C++ with EnTT. Focusing on dynamics (forces, acceleration, velocity) and kinematics (movement).
Collisions will come later, they deserve a post of their own.

The META Trap: Why Chasing Trends Will Leave You Behind and How AI Is Giving Real Engineers Their Moment (Again)

Every few years, the software world goes through a wave of obsession.
A new language, a framework, a paradigm shift that promises to change everything, micro-fucking-services…
Rails did it. Then React. Then Kubernetes. Now, it’s LLMs, AI agents, copilots, assistants, the whole new alphabet of tools that seem to rewrite the rules of what it means to be an engineer.

And every time, you see the same thing happen. A rush.
People racing to learn the new syntax, the new abstractions, the new “must-know” patterns. Everyone trying to catch up, to stay relevant, to not get left behind, to not be the COBOL guy.

But here’s the sad truth, you can’t outrun the META.
It’s not a finish line you can cross. It’s a living, moving target shaped by thousands of brilliant minds working faster than you can keep up with.
Trying to chase it is like trying to catch the horizon.

The engineers who survive and thrive aren’t the ones who chase but the ones who understand. They see the patterns underneath, the ideas that keep showing up no matter how many new frameworks or technologies we invent.

And that’s why the AI revolution feels different. Because for once, it’s not about replacing engineers. It’s about exposing who actually knows what they’re doing.

Building a flexible stock allocation system in pure ECS

In this post, I’ll walk through the design of a flexible stock allocation system built using pure ECS principles in C++ (with ENTT). We’ll go from problem definition to implementation details, discussing elasticity, priorities, and resource management in a simulation-like environment.

From time to time, I start a new project only to abandon it a few weeks later. That’s been my life for the last 20 years, I’ve grown to accept that I rarely finish them.

I started a new one this weekend. It’s going to be different this time (no, it won’t), and I’ve decided that even if I’m not going to finish it (yes, I won’t), my effort will still be worth it if I can at least extract a few posts for my fancy blog. So here we are.

I’ve been obsessed with Shadow Empire and Aurora 4x for years, and I’ve finally decided to build my own (as an MMORTS, just as God intended, because I’ll probably abandon ship eventually anyway, so… why not?).

Here I am, documenting my journey and sharing my work. Enjoy my failure. ❤

RNG, PRNG and Entropy: Why Your Softwares “Chaos” is Probably Broken

A game developer proudly claims their procedurally generated worlds are “infinitely unique”… until players find the same mountain repeating on level three. A blockchain touts “provably fair” randomness… until someone exploits predictable seeds to drain $170,000. A security team deploys “military-grade encryption”… only to discover their keys were generated by a Mersenne Twister.

Here’s the brutal truth: there’s no real randomness in software. Every “random” number you generate comes from a pseudo-random number generator (PRNG)—a clever algorithm pulling numbers out of a very predictable hat. It’s like watching a magician perform card tricks: it looks random, but behind the scenes, it’s all carefully scripted.

Welcome to the paradoxical world of randomness in software, where the foundations of fair games, secure encryption, and reliable blockchains hinge on something that’s fundamentally fake. Let’s dive into why entropy management is so often a disaster and how to build systems that don’t fall apart under their predictability.

MMO Architecture: Area-Based Sharding, Shared State, and the Art of Herding Digital Cats

More on MMO Architecture:
- MMO Architecture: Source of truth, Dataflows, I/O bottlenecks and how to solve them
- MMO Architecture: client connections, sockets, threads and connection-oriented servers
- MMO Architecture: Optimizing Server Performance with Lockless Queues

Building an MMO feels a lot like herding cats, noisy, frantic, unpredictable and forever on the brink of half of them running into the road. The question is how to keep everything from descending into chaos when tens of thousands of players decide to storm your virtual castle at the same time.

In Massively Multiplayer Online (MMO) games, ensuring a seamless and immersive experience for thousands of players simultaneously is a monumental chore. At the heart of this challenge lies the architecture that governs how game servers manage player interactions, world events, and resource distribution. A pivotal component of this architecture—and the main focus of this post—is area-based sharding, a strategy that divides the game world into manageable sections (often called “zones”), each overseen by dedicated servers.

So, your players are laying siege to a castle, and your servers are silently screaming for mercy. How do you handle this digital nightmare without devolving into a lag-ridden slideshow for everyone in your online world?

The F.U.C.K Paradigm: A Hostile Approximation to Clean Code

F.ail fast and make it cheap
U.nderstand your domain
C.omply with standards and idiomatics
K.now when to split

We’ve all wasted days debugging a supposedly “clean” Java class named something like AbstractFactoryVisitorParserStrategyCSVImpl. Its only real function? Parsing a CSV file. After hours spent navigating through endless layers of inheritance, polymorphic delegates, and unnecessary abstractions, you realize there’s only one CSV file—and it contains exactly twelve rows. Twelve. The only thing truly “clean” about this code is how neatly detached it is from reality.

Welcome to the cult of Clean Code, the empire of a lumpy naked king, constantly hitting everyone around in the balls with his not-so-abstract scepter, where everyone pretends their destructured life is justified. Every time they plan to build a new neighborhood, the entire town is forced to uproot and move 200 miles up north to start from scratch again, constrained by the strict existing urban plans and convinced they’ve finally found the “right” location to implement their newly design perfect layout_(2)_new_new_copy(3).map—only to repeat the cycle indefinitely. This is the inevitable outcome of blind devotion to abstraction, indirection, and dogma. It’s time we dismantle this orthodoxy and propose a new paradigm: F.U.C.K. Clean Code!

Swarm Intelligence: How Dumb Agents Create Smart Systems

Have you ever walked into a kids school class as an adult and just wondered how that many complex relationships, dynamics and behaviors can naturally emerge from such an stupid crowd?

Swarm intelligence (SI) refers to the collective behavior of decentralized, self-organized systems where its individuals just reacts to simple and pretty specific impulses – think of ant colonies, bee swarms, bird flocks or children leaving class for break, acting as if guided by an unseen hand.

No one’s issuing commands or drawing up a master plan for these groups. Instead, each individual agent (an ant, a bee, a bird, a kid, or even a simple software process) operates based on simple local rules, with no global overview or leader. Remarkably, from these rudimentary interactions emerges a form of “intelligent” global behavior that none of the participants fully understand.

In plainer words: a bunch of pretty dumb parts somehow band together to appear downright smart.

Shortcuts always causes delays: The importance of learning and the perils of AI assistance.

AI coding assistants like GitHub Copilot and ChatGPT have stormed into our workflows, promising to turn weeks of grind into minutes of “magic.” Who wouldn’t want a tireless sidekick that writes boilerplate, debugs code, and answers questions on demand? Early experiences often feel like a superpower – describe a feature in plain language and out pops “functioning” code (ikr).

The old mantra of “A couple days of trial and error saves you lots of minutes reading documentation” has dead, today the temptation is real: why slog through all that when an AI can serve up a solution instantly?

When the abstraction bites your ass.

I once found myself knee-deep in an “elegant” framework that was supposed to solve every future problem. Spoiler: It was this weekend, and it didn’t fix shit.

I remember dozens of times seeing someone (myself, more times than I’m willing to admit publicly) performing beautifully complex architectural dances around a simple software idea. All you needed was to parse a config file, but a little voice whispered to build a grand abstraction capable of parsing any file format ever conceived, adhering strictly to the SOLID principles—those sacred tablets handed down to us mere mortal developers directly by God in Mont Sinaí.

There you are, one week later, buried under layers upon layers of boilerplate, with an impressive total of ZERO real features actually working. Then a tiny change comes to mind (or perhaps Satan personally sends it via his favorite messenger, the PM), and suddenly your beautiful castle of abstractions collapses, leaving you to spend days refactoring instead of delivering value.

Sound familiar? Sometimes the fanciest hammer is just overkill for a simple nail.