Gamified Learning

I wanted to find a fun and passive way to dive into the mechanics of systems design for enterprise systems. It felt like an impossible ask but I remembered three things:

1. AWS already began building game-based learning to upskill and recertify
2. I loved playing video games growing up
3. Every serious programmer plays video games

Correlation isn't causation, and I know playing video games wouldn't automatically make me Linus Torvalds or Demis Hassabis, but I wondered if something was there in this situation (Programmers being Gamers, but Gamers not always being Programmers). The question was: could I actually find a game that would teach me real engineering principles without feeling like work?

The Search

So I started digging for a needle in a haystack. I had no idea where to begin looking because the games I played growing up were sports or first-person shooter games. None of those were going to teach me about distributed systems architecture.

But somehow, I discovered this game that drew my attention for how great it looked and the purpose of it: Satisfactory. It's a factory building game and the entire premise is to build an efficient factory — aesthetics get you brownie points.

I watched several hours of reviews and gameplay to help me decide if this would be a massive waste of time and money or not. The skeptic in me kept asking: is this actually going to teach me anything useful, or am I just justifying buying a gaming console?

I decided to give it a shot. I figured if I felt it's wasting both time and money I'd return everything.

I didn't want to be limited to a TV or my laptop. Naturally, I went down the SteamDeck vs Switch 2 vs ROG Ally rabbit hole. In the end, I went with the 512GB OLED SteamDeck. It's gorgeous. It arrived in about 3 days and I was excited to get everything installed and test it out.

Still cautious. Still skeptical. But curious.

Gameplay

I'm ~10 hours deep across a week of gameplay now. While trying to optimize the factory I’m building, I have to think about resource management, factory architecture, machine placement, and most of all — throughput.

Some machines produce faster than others. Here’s a real example from the game:

• My iron ore miner outputs 60 ores per minute.
• My smelters can only process 30 ores per minute each.
• My constructors that turn ingots into plates only process 20 per minute each

The math doesn't add up cleanly. You can't just chain them together.

My first thought was to use a combination of "splitters" and "mergers" to balance the production lines. Two smelters to match the miner output. Three constructors to match the smelters. It worked, but it felt... clunky. Like I was just brute-forcing the problem with more machines and more complexity.

I kept building, kept optimizing, kept trying to make the numbers work. But something felt off.

When it Hit Me

It wasn't until the last 30 mins today that everything clicked. I’m pulling down copper ore from another remote location when I didn’t have any particular use for copper beyond turning them into copper ingots.

Okay, so after that, I don’t always need copper wire — at least not yet. So instead of further refinement like I did with the iron, I put them straight into a storage unit.

Each storage unit has 24 slots and each slot holds a varying amount depending on material and refinement. But what’s great about storage units is they don’t just accept items but can also allow for items to flow through them. I do that with the iron plates (the final product that leaves the smelter) because the slots are filling up so quick, especially without any particular use for iron plates yet.

It was serendipitous when I thought “Hmm, what if I used the storage unit to kind of slow down production by allowing material to flow through but the store the build up of items?”

It felt like a feasible thought and with 24 slots that could hold between 1 to 500 (the max I’ve seen so far) of material, it would be a long time before it got full. In the very least, I could cut down how many machines I’m using.

It was a simple idea to save on resources and energy distribution. I latched my dog to my hip and went for a walk.

That's when my brain started connecting dots.

"Wait. Isn't this load balancing? Isn't that exactly what a buffer does?"

I pulled out my phone mid-walk and searched it up. And sure enough — that's precisely what it is. Except instead of conveyor belts and storage containers, real systems use message queues.

The storage containers I wanted to place between each production stage? Those are buffers. They decouple the producer from the consumer. The miner doesn't need to know or care how fast the smelter processes. It just dumps ore into the storage container. The smelter pulls from storage at its own pace.

This is asynchronous processing. This is how Kafka works. This is how Amazon SQS works. This is how every distributed system at scale handles throughput mismatches.

I’m discovering that my janky factory optimization problem was teaching me the exact same patterns that power Netflix's recommendation engine, Uber's ride matching, and every modern microservices architecture.

As I researched terms during my walk, the benefits hit me all at once:

• Decoupling: Each stage operates independently. I can upgrade my smelters without touching the miner.
• Elasticity: Storage absorbs the throughput mismatch. If I want to scale later, I just add another machine pulling from the same buffer.
• Backpressure handling: If downstream slows down, the buffer fills up rather than everything grinding to a halt.
• Resilience: If one stage goes down, the others keep running. The queue just builds up.

Holy shit. I wasn't just playing a game. I was literally building distributed systems with conveyor belts.

What Now?

Between balancing work, study, fitness, etc. — I've found a small pocket where I can passively learn and gain a fundamental understanding of building distributed systems at scale without picking up another O'Reilly book.

The skepticism is gone. This wasn't a waste. This was one of the smartest learning investments I've made.

Because here's the thing: reading about message queues in a textbook is one thing. Actually feeling the problem they solve — watching your production line back up, realizing I need a buffer, implementing it, and seeing everything flow smoothly — that's different. That understanding sticks.

I'm not saying Satisfactory will make me a senior systems architect. But I am saying that the pattern recognition skills I’m building by optimizing factory throughput will absolutely translate when I’m thinking about data pipelines, API calls, and how information flows through real systems.

And honestly? It's way more engaging than documentation.

Thank you Coffee Stain Studios ☕️