techniques – 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.

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?

MMO Architecture: Optimizing Server Performance with Lockless Queues

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: Area-Based Sharding, Shared State, and the Art of Herding Digital Cats

I'm writing this article within the last 2 hours of 2024, so I guess I'm forced to say Merry Christmas ❤ Thank you for your time, I hope you enjoy it and learn something new.

In modern MMO (Massively Multiplayer Online) games, server performance is as crucial as any other part of the game’s architecture. You want your servers to handle thousands of player connections seamlessly, process real-time game logic, and keep latency as low as possible.

A common technique in building such systems (and any other high performance socket-based software tbh, you already know my obsession with MMOs…) is to separate the networking thread from the main game logic thread(s) so the application doesn’t stall on big net transfers. This separation goes a long way to improving performance, maintainability, and scalability, especially in high-concurrency environments.

In this article, we will explore the reasons behind this design decision, discuss race conditions and how they can occur in multi-threaded code, and see why lockless queues are often a great choice for handling messages between threads in.

Finally, we will present a working C++ implementation of a lockless SPMCQueue (Single Producer, Multiple Consumer Queue) and discuss the key concepts behind it. This queue allows a single producing thread to push data into the queue while multiple consumer threads can pop data concurrently.

Deep-diving into Entity Component System (ECS) Architecture and Data Oriented Programming

1–2 minutes

Some years ago I wrote the first article about ECS, at that time, in a comment, someone suggested that my solution was closer to a standard CS than to a real ECS.
Unfortunately for me, that anonymous internet person was right.

Entity component system (ECS) is an architectural design pattern used primarily in video game development. This pattern differs significantly from object-oriented programming (OOP), which has been the dominant paradigm in software programming for decades.

ECS offers significant advantages in video game development, especially in terms of flexibility, performance and ease of maintenance. This architecture is well suited to the dynamic and often complex needs of modern games, greatly facilitating phases as essential as complex as the prototyping of new features.