Sit down with this game for the first time and one thing becomes clear fairly quickly: the two sides don’t share the same rhythm. The Corporation and the Runner have different priorities, different relationships with time, different ways of thinking about what a turn is for. Modelling that in code means understanding what each side does on their turn and why the structure of each turn exists in the first place.

The Basic Shape of a Turn

Both players operate on clicks. Each turn, a player receives a fixed number of clicks to spend on actions. The Corp gets three clicks per turn. The Runner gets four. That gap is intentional: the Runner needs the extra tempo to have any hope of keeping pace with a Corporation that is quietly building servers, advancing agendas, and layering ICE across its infrastructure.

A click can be spent on a wide range of things: playing a card, gaining a credit, drawing a card, advancing an agenda, making a run. Each action costs one click unless a card says otherwise. When your clicks are gone, your turn is over.

// Both sides share the same base click tracking
UPROPERTY(Replicated)
int32 ClicksRemaining;

// But start with different amounts
CorpClicksPerTurn = 3;
RunnerClicksPerTurn = 4;

The Corp Turn

The Corporation’s turn has a defined structure beyond simply spending clicks. It begins with a mandatory draw: the Corp draws one card before anything else happens. Then the click phase opens and the Corp spends their three clicks however they choose. The turn ends with a hand size check: if the Corp is holding more than five cards, they must discard down to five before passing priority to the Runner.

That mandatory draw is worth thinking about. The Corp doesn’t choose whether to draw. It keeps the game moving, ensures the Corp is progressing, and means the Corp’s hand size is in gentle flux throughout the game. It also carries a quiet cost: if the Corp's deck runs dry and they are forced to draw from an empty pile, the game ends immediately in a Runner victory. That threat sits in the background of every Corp decision. Playing cards too freely empties the deck faster. Holding too many cards means discarding at the end of turn, which accelerates it just as much. Knowing when to play, when to hold, and how many cards are left is part of what makes playing Corp different from playing Runner.

void UCorpActions::BeginCorpTurn()
{
    // Mandatory draw before clicks open
    DrawCard(CorpPlayer, 1);
    ClicksRemaining = CorpClicksPerTurn;
}

void UCorpActions::EndCorpTurn()
{
    // Discard down to maximum hand size if over
    EnforceHandSizeLimit(CorpPlayer, MaxCorpHandSize);
}

The Runner Turn

The Runner’s turn has no mandatory draw and no end-of-turn discard. Four clicks, spend them how you like, pass priority back to the Corp when they’re gone. That freedom is the Runner’s defining characteristic: pure agency, constrained only by resources and what’s been installed.

Where the Corp is managing a slow-building machine, the Runner is deciding when to apply pressure and when to hold back. Every run costs clicks and potentially credits. Every failed run costs tempo. The four clicks are a budget as much as they are actions.

void URunnerActions::BeginRunnerTurn()
{
    // No mandatory draw — Runner chooses everything
    ClicksRemaining = RunnerClicksPerTurn;
}

What the Action Manager Actually Does

Underneath the turn structure sits the action manager — the system responsible for knowing, at any given moment, what a player is and is not allowed to do.

This is more involved than it might sound. A player can only spend clicks on their own turn. Certain actions are only available to one side. Some cards open windows where the other player can respond before an action resolves. The action manager tracks turn ownership, validates every action request against the current game state, and rejects anything outside what the rules permit.

bool UActionManager::IsActionValid(EActionType Action, ANetrunnerPlayerController* PC)
{
    // Wrong turn
    if (!IsActivePlayer(PC)) return false;
    
    // No clicks remaining
    if (ClicksRemaining <= 0) return false;
    
    // Action not permitted in current game state
    if (!IsActionPermittedInCurrentPhase(Action)) return false;

    return true;
}

Nothing reaches the game state unless the action manager approves it. The server validates every request before anything changes. A client can ask to do whatever it likes but the action manager is what decides whether the game agrees.

Why the Asymmetry Matters

It would have been simpler to give both sides the same turn structure and the same number of clicks. The fact that the game doesn’t do that is part of what makes this worth building.

The turn structure communicates what each side is supposed to feel like. The Corp is methodical, accumulating, building towards something. The Runner is reactive, opportunistic, picking the right moment to strike. That difference starts in the click count and the mandatory draw and radiates outward into every decision both players make.

Getting that into code cleanly is one of the more satisfying things this project has produced so far.

Next week I’ll go deeper into the economy (“credits”) of the game, how they’re earned and spent, and how the game tracks the resource layer that sits underneath every decision both players make.

See you then.

Supporters

If you would like to appear here, you can support the project via the buymeacoffee or by subscribing to my substack to get extra content and preview of the posts.

Last week I left you with a project that was fundamentally broken and no fix in sight. Client-side ticks not firing, BeginPlay silent, timelines collapsing after a single pulse. Something systemic, something deep, and at that point something I hadn’t identified yet.

So let’s dive into the issue and solve it.

Getting Methodical

The breakthrough came from forcing myself to slow down and stop throwing solutions at the wall. I started completely fresh.

New project. Install the template. Copy my code across (thankfully I had structured everything as a self-contained module from the beginning, which meant moving it was straightforward rather than surgical). Then I began reparenting the classes one by one, reintroducing my code into the template piece by piece, and running the game after each change.

The idea was simple: keep playing until it breaks, and whatever I changed last is the culprit.

It broke. I found it.

The Culprit

The issue came down to a single class mismatch. CCG Toolkit uses AGameState as the base for its game state class. My code used AGameStateBase.

To anyone who hasn’t spent time in Unreal’s networking internals, those two things sound like they should be interchangeable, one just a more specific version of the other. In practice, the difference is significant.

AGameStateBase is the minimal foundation. It handles the bare essentials of tracking game state and replicating it to clients, but it deliberately leaves out higher-level functionality to keep things lightweight. AGameState, which extends it, adds the machinery that Unreal’s multiplayer framework actually depends on for a fully connected game: player array management, match state tracking, and critically, the replication hooks that keep clients properly synchronised with the server.

When you mix the two, a GameMode expecting AGameState behaviour sitting on top of a class that only provides AGameStateBase, the replication system quietly falls apart. Not loudly, not with an obvious crash. It just stops working in specific, baffling ways. Ways that look, from the outside, exactly like client-side ticks not firing, BeginPlay not triggering, and timelines dying after a single frame.

The entire disaster, traced back to one class hierarchy mismatch.

Why It Was So Hard to Find

Everything else was working. Spawning an actor on the server and having it appear on the client: working. Calling client RPCs and having them execute correctly: working. Players connecting, exchanging information, replicating data back and forth: working. The replication system was not broken. It was functioning exactly as it should across almost every surface I was testing against.

That’s precisely what made this so hard to track down. When most things work, you assume the foundation is solid. You look for the bug in the code you wrote last, not in a class you chose at the very beginning. The failure was surgical, specific enough to be invisible against the backdrop of everything that was functioning correctly, but catastrophic enough to make the thing I actually needed to build completely impossible.

And as for why my code was using AGameStateBase in the first place? There is no elegant answer to this one. When I created the class, I searched for “game state” in Unreal’s class picker and clicked the first result. That was it. No careful consideration, no cross-referencing with the template, no checking whether I was picking the right variant. I just clicked the first thing that looked right and moved on.

A two-second decision at the start of the project that cost me the better part of two weeks to diagnose. That’s the job sometimes.

The Part That Hurts

Here is the part I have to be honest about.

The answer was in the log file the entire time.

LogGameMode: Error: Mixing AGameStateBase with AGameMode is not compatible. 
Change AGameStateBase subclass (CardGameState_C) to derive from AGameState, 
or make both derive from Base.

Right there. Explicit. Named the exact class causing the problem. I had walked past that line repeatedly while I was actively dismantling the template, and I had dismissed it as noise, a side effect of the intentional breaking rather than a signal worth following.

It wasn’t noise. It was the answer, sitting patiently in the logs waiting for me to read it carefully.

Read your logs. All of them. Even the ones that appear while you’re doing something else.

The Honest Version of How This Felt

Before I found this, I was close to throwing in the towel. Not on the project entirely, but on the current codebase. I was seriously considering scrapping everything and starting a new project from scratch, accepting the loss and rebuilding with fresh eyes.

The methodical approach saved me from that. Going back, resetting, reintroducing changes one at a time rather than staring at a broken whole. That process is what made the answer findable. It wasn’t glamorous. It wasn’t fast. But it worked, and it saved me an amount of time I don’t want to calculate.

Not having tick working on the client is one of those problems that feels impossible precisely because it shouldn’t be possible. The framework is supposed to handle that. When it doesn’t, your instinct is to question everything: your code, your architecture, your life choices. The real answer, in this case, was far simpler than any of that.

Sometimes stepping all the way back is the only way to move forward.

What’s Next

With the project back on stable ground, I can finally get into the gameplay systems properly. Next week I’ll talk about the action manager and turn structure, how the game decides whose turn it is, what actions are available, and how it enforces the rules when a player tries to do something they shouldn’t.

See you then.

Supporters

I would like to extend my sincere gratitude to the following individuals who have chosen to support this project. Your contribution means a great deal and helps keep this work moving forward.

• Marcel Encarnação

If you would like to appear here, you can support the project via the buymeacoffee or by subscribing to get extra content and preview of the posts.

Some weeks you find out that something you thought was working never really was. My first major bug that nearly drove me to madness.

It started simply enough. I was wiring up the 3D card movement, the moment a card physically travels from one place to another on the board. Visually, one of the more satisfying things to get right. I had the card spawning correctly, data flowing from the server to the client, commands being received and acknowledged. Everything pointed to this being straightforward.

Then I tried to move the card and nothing happened.

There was no errors on the logs, no crashes… just nothing. The card sat exactly where it was, completely indifferent to the fact that it was supposed to be moving.

I started digging. The movement logic lived on the tick (the function that runs in every frame). So I did the simplest possible test: I dropped a print string into the tick on the client side. Just a line of text that would appear on screen every frame to confirm the tick was running.

Nothing printed on the log.

That was strange. The card was spawning correctly on the client, the server was generating it and the client was receiving it. RPC calls were going through. Data was replicating. But the tick? Silent.

I took a step back and checked BeginPlay (the function that fires once when an actor first enters the world). If anything was going to work on the client, it should be that.

Also silent.

At this point I was no longer looking at a card movement bug. I was looking at something deeper and considerably more unsettling.

Ruling Things Out

I went through everything methodically. Replication settings => checked and rechecked. Forced tick enabled explicitly in the constructor. Verified the actor was set to replicate. Tried variations, combinations, approaches I’d already tried once because I was running out of ideas.

Nothing changed. The client side remained completely unresponsive. Tick not firing. BeginPlay not firing. And yet any RPCs calls where working with data replicating, spawning correct. The contradiction made no sense.

Then I thought I’d found a way around it. If tick wasn’t firing reliably on the client, maybe I could drive the card movement through a timeline instead (a defined animation curve that plays out over time rather than recalculating every frame). Cleaner, arguably more appropriate for smooth card movement anyway. I wired it up and ran it.

The timeline fired once. Then stopped completely. No loop, no continuation, just a single pulse and then silence… as if something was actively preventing anything time-based from sustaining itself on the client. Tick broken. BeginPlay broken. Timelines broken. It wasn’t one unlucky system. It was everything that depended on time passing on the client side.

So I ran a final test. I created a completely fresh actor. No logic, no systems, nothing inherited from the project. Just a simple replicated actor with a single print string on tick that said “hello world”. I dragged it into the map, which is always replicated to connected clients, and pressed play.

Just the server printed the logs. The client printed nothing.

I was losing my mind a little by this point.

The Moment It Clicked

One more test. I opened a completely fresh Unreal project. Clean template, nothing carried over from my work. Created the exact same actor. Dragged it into the map. Connected a client.

It worked immediately. Tick firing. BeginPlay firing. “Hello world” printing on both ends exactly as it should.

The template worked. My project didn’t. We are now getting somewhere.

After more testing, the conclusion was unavoidable: something in my project is broken at a fundamental level. Client-side ticks and BeginPlay events are not firing at all. Not just for cards, not just for replicated actors, but across the board. A silent, systemic failure that had been sitting underneath everything, invisible until I tried to do something that depended on it.

Where Things Stand

I know what the problem is. I know where it lives. I’ve already found the solution, but I’ll save it for the next post. If you’re an Unreal Engine developer, I’d love for you to leave a comment guessing what the issue might be. It’s easier than you think! Based on my description, I’m curious to see if you can spot exactly what’s going on.

Supporters

I would like to extend my sincere gratitude to the following individuals who have chosen to support this project. Your contribution means a great deal and helps keep this work moving forward.

• Andre Fonseca

If you would like to appear here, you can support the project via the buymeacoffee or by subscribing to get extra content and preview of the posts.

There are moments where I can check on my progress, where something that didn’t exist a few weeks ago is suddenly there and working. And then I look at how far there still is to go, and the two feelings sit next to each other in a way that is hard to describe. Proud, but grounded.

That feels about right for where this project is.

Stage 1: The Codebase

It started with nothing visible at all. Just code. Data structures, card definitions, game state logic. The invisible foundation that everything else would eventually sit on top of. There was no board, no cards on screen, no interface of any kind. Just a server that knew what a card was, what a player was, and how the two related to each other.

This is the stage that is hardest to show and easiest to underestimate. Nothing looked like a game. But without this, nothing that came after would have been possible.

Stage 2: Pseudo Cards

Before real card data existed, I needed something to test against. I created a list of pseudo cards, just placeholders definitions that had the right shape without being the real thing. Enough structure to run logic against, enough variety to expose edge cases (hopefully, however, It never catches everything).

It’s unglamorous work. But it’s the kind of unglamorous work that saves you from discovering fundamental problems much later, when they are far more expensive to fix.

Stage 3: 2D Cards

This was the first moment it started to feel like something.

Cards appearing on screen. A hand that held them. A player that could look at what they’d drawn. The information flowing from the server → card names, costs, types → down to the client and into a 2D widget that displayed it correctly.

Seeing a card on screen for the first time, knowing that the data behind it came from the server and was filtered correctly before it arrived, was a quietly significant moment.

Stage 4: 3D Cards

The next step was the transition from hand to board. When a card is played, it stops being a flat 2D widget and becomes a 3D actor in the world, a physical presence on the table rather than a UI element in your hand.

Getting this right meant the card information had to travel cleanly from the server, through the 2D representation in hand, and into the 3D actor when it hit the board. The data pipeline had to hold together across that entire journey without losing anything or misrepresenting anything.

Stage 5: Board Layout

The board is taking shape. Zones for servers, the runner’s rig (still missing), the central areas where both players interact. The physical aspect of the game is becoming visible for the first time.

It is still early. There is no gameplay loop running end to end yet. But the table exists. The space where the game will happen is starting to look like the space where the game will happen.

Where This Leaves Us

Six weeks of work. A codebase, a card pipeline, a network layer, a board that is beginning to resemble something real.

There is a lot still to build: the full run system, ICE encounters, economy, win conditions, proper card art, sound, UI polish. The list is long and I am one person.

But the list felt longer when I was staring at a blank project and talking myself out of starting. At least now there is something to look at.

Next week I’ll get back into the systems: the action manager, turn structure, and how the game decides what you are and aren’t allowed to do on any given turn.

See you then.

Supporters

I would like to extend my sincere gratitude to the following individuals who have chosen to support this project. Your contribution means a great deal and helps keep this work moving forward.

• Jared Meritt

• Marcel Encarnacao

If you would like to appear here, you can support the project via the buymeacoffee or by subscribing to get extra content and preview of the posts.

There is a specific kind of satisfaction that comes from watching something work for the first time.

Not the satisfaction of a feature being finished, or a bug being fixed. Something quieter than that. The moment where a system you’ve been building in pieces, wiring together in your head long before it existed in code, finally does the thing it was always supposed to do. Both ends talking to each other. The handshake completing. The game beginning.

That moment happened this week. And it felt good.

The Problem to Solve

Before a single card can be played, before the first run is declared or the first credit is spent, two people need to find each other across a network, agree that they are both ready, submit their decks, and hand control over to the game. It sounds like very foreword . It is anything but.

This is the part of a multiplayer game that players never think about because, when it works, it’s invisible. You click a button, you’re in a game. What actually happened in between is a surprisingly involved sequence of events, and getting that sequence right, in the right order, with the right checks at each step, is the kind of work that quietly determines whether everything built on top of it is stable or fragile.

How Players Connect

When a player joins the server, Unreal’s networking layer fires a PostLogin event. This is the entry point: the moment the server becomes aware that someone new has arrived. From here, the network manager registers the incoming player controller, assigns them a role, and begins tracking their state.

Two players need to connect before anything else can happen. The server waits. It doesn’t assume. It doesn’t proceed until both seats are filled and both players have been properly registered. That patience is intentional, rushing past it is how you end up with race conditions that only appear in production, when two real people connect at slightly different times and the game state ends up in a place it was never supposed to be.

// Called by the server when a player successfully connects
void ANetrunnerGameState::RegisterPlayerController(ANetrunnerPlayerController* PC)
{
    ConnectedPlayers.Add(PC);
    if (ConnectedPlayers.Num() == 2)
    {
        OnBroadcastBothPlayersConnected();
    }
}

Submitting a Deck

Once both players are connected, each one submits their deck to the server. This is not a client-side operation. The deck data travels to the server, the server validates it (checking that it’s legal, that it’s complete, that it belongs to the right side) and stores it. The client doesn’t get to decide what’s in its own deck. The server does.

This matters more than it might seem. A client that could manipulate its own deck after submission is a client that could cheat in ways that are very difficult to detect. By pushing validation entirely to the server, that attack surface disappears before it ever opens.

The Ready-Up Flow

With decks submitted, each player signals that they are ready. The server waits for both confirmations (not one, both) before proceeding. When the second ready signal arrives, the server calls StartGame(), initialises the full game state, and fires a Client_GameReady RPC to each player.

That RPC is the signal. On the client side, it means: the game is real now. Draw your opening hand. The board is live.

void ANetrunnerGameState::Server_ReadyUp(ANetrunnerPlayerController* PC)
{
    ReadyPlayers.Add(PC);
    if (ReadyPlayers.Num() == 2)
    {
        StartGame();
    }
}

The full sequence - PostLogin → RegisterPlayerController → Server_SubmitDeck → Server_ReadyUp → BothPlayersReady → StartGame() → Client_GameReady - is wired end to end. Every step hands off cleanly to the next. Nothing proceeds until it’s supposed to.

Why That Moment Mattered

When I ran it for the first time and watched the log trace the full sequence without errors: both players registering, both decks submitting, both ready signals arriving, the game starting… I sat back for a second and just looked at it.

It’s not a card game yet. There are no cards on the table, no runs, no ICE to break through. But two players can now connect to a server, tell it they are ready, and receive confirmation that a game has begun. The skeleton is standing up. Everything built from here has somewhere to stand.

That felt like something worth noting.

Next week I’ll start getting into the gameplay systems themselves. The action manager, how turns are structured, and how the game decides whose move it is and what they’re allowed to do.

See you then.

Supporters

If you would like to appear here, you can support the project via the buymeacoffee or by subscribing to my substack to get extra content and preview of the posts.

I spent longer than I should have on this one.

If I’m being completely honest, this decision is part of why this project didn’t start sooner. It had been sitting in the back of my mind for a long time. The game I wanted to build, the engine I wanted to use, the rough shape of what it could be. But every time I got close to actually starting, this question was there waiting for me. Template or scratch. Shoulders or foundation. And instead of deciding, I’d just... not. The paralysis of it was quieter than I expected. It didn’t feel like fear. It just felt like not quite being ready. Not quite having the answer. And so the project stayed an idea for longer than it needed to.

Eventually I made a call. This is how I got there.

The Template in Question

There is a tool on the Unreal Marketplace called CCG Toolkit. It’s a multiplayer card game framework. A fully built foundation that gives you a working card game skeleton out of the box. Animations, menus, card previews, hand and deck management. The kind of scaffolding that takes weeks to build properly if you’re starting from nothing.

It’s well regarded. It’s actively maintained. And when I first found it, I was genuinely tempted.

The Case For It

The visual side of a card game is deceptively time-consuming. Getting cards to lift cleanly off a deck, arc into a hand, and land on a board in a way that feels satisfying is not a trivial animation problem. CCG Toolkit has that done. The 2D-to-3D transition (the moment a card moves from your hand into play and becomes a presence on the board) is already there. Card preview on hover, simple menus, basic UI chrome. All of it, already done.

For a solo developer with no dedicated artist and no unlimited runway, that is not a small thing. That is weeks of work handed to you on day one.

The Case Against It

CCG Toolkit is not just a collection of useful components. It is an entire card game system with its own opinions about how a card game should work. Learning to use it properly means learning how it thinks: its assumptions, its data flow, its architecture. That investment of time doesn’t disappear just because the end result looks faster.

And this game is not a simple card game. The rules are dense. The state machine is complex. The asymmetry between the two sides means almost nothing in a standard card game framework maps cleanly onto what I need. Every new rule, every new game state, every interaction I wire in is going to push against the edges of a system that was never designed with this specific game in mind. At some point… and I don’t think it’s a distant point… things will start to break in ways that are difficult to trace because the foundation wasn’t built for this.

There’s also a longer-term cost that’s easy to underestimate. Everything in CCG Toolkit that I don’t use is still there, sitting in the project, adding noise. Eventually there will be a reckoning. A cleanup pass where I strip out everything that doesn’t belong. That work doesn’t go away. It just gets deferred.

And perhaps the most uncomfortable truth: the time it takes to properly learn how CCG Toolkit works is probably not far off the time it would take to build the pieces I actually need from scratch. At a certain point, understanding a system deeply enough to bend it to your will and understanding how to build it yourself are nearly the same thing.

The Decision

I’m using it.

The reason is simple, and it took me longer than it should have to see it clearly: I am not trying to build a finished game right now. I am trying to build a vertical slice: a focused, playable demonstration of what this game can feel like. Something I can put in front of people and ask whether it’s worth continuing. Something that proves the concept before I commit to the full architecture.

For that goal, the visual polish CCG Toolkit brings on day one is genuinely valuable. If the vertical slice lands, if there’s traction and appetite for the game, then the deeper architectural work (the cleanup, the rebuild, the from-scratch systems) is a problem worth having. It means the project survived long enough to need solving.

If I spend six months building everything perfectly from scratch and nobody wants to play it, I’ve built something perfect that nobody wants.

The template gets me to the demo faster. The demo tells me whether any of this is worth it. That’s the logic. I’m committing to it.

Next week I’ll get into the network manager. How players actually connect, how the ready-up flow works, and what happens in the gap between two people joining a lobby and the first card hitting the table.

See you then.

Supporters

I would like to extend my sincere gratitude to the following individuals who have chosen to support this project or subscribed to my substack. Your contribution means a great deal and helps keep this work moving forward.

• Andre Lizardo

• Irina Ferreira

• Andre Fonseca

If you would like to appear here, you can support the project via the buymeacoffee or by subscribing to get extra content and preview of the posts.

Last week I talked about separating card data from card visuals. This week I want to go one level higher and talk about something that shaped the entire network architecture from day one, before a single line of multiplayer code was written.

The question was simple: when two players disagree about the state of the game, who is right?

The answer, it turns out, determines almost everything.

The Decision

Some multiplayer games trust the clients. Each player’s machine tracks its own version of the game state, and the server acts as a middleman. It passes messages back and forth, reconcile differences when they arise. It’s a reasonable approach for certain types of games. Fast-paced games where a few milliseconds of latency matter more than perfect accuracy can benefit from letting clients run ahead and correcting later.

A card game is not that.

In a card game (especially one as rules-dense as this) the state of the game at any given moment is sacred. Who has how many credits. Which cards are installed. Whether that ICE is rezzed or not. Whether a run is currently active and at which stage. These are not things you want two different machines to have two different answers to.

So I made a deliberate choice early: the server owns all truth. Always. Without exception.

The clients (your machine, your opponent’s machine) are displays. They show you what the server tells them is real. When you take an action, you don’t update your own game state. You send a request to the server, the server validates it, the server updates the state, and the server tells both clients what has changed. Your screen updates because the server said so, not because your machine decided it should.

Why It Matters for This Game Specifically

Most multiplayer games benefit from server authority. This one depends on it in a way that goes deeper than cheat prevention.

Netrunner is built on hidden information. The Corp’s hand is never visible to the Runner. Unrezzed ICE has a presence on the board but its identity is secret until the Corp chooses to reveal it. Agendas sit in remote servers, indistinguishable from assets or traps, until someone accesses them.

In a client-trusted model, enforcing this cleanly is genuinely difficult. If a client knows too much about the game state, even information it isn’t supposed to display, that information can be extracted. A determined player with the right tools could see the Corp’s hand before making a run. That isn’t a edge case. That’s a fundamental break in the game.

With a server-authoritative model, the problem largely disappears. The Runner’s client never receives information about the Corp’s hidden cards in the first place. The server filters what each client is allowed to know before it sends anything. There is nothing to extract because the data was never there.

// The server sends only what each client is allowed to see
// Corp hand and unrezzed cards are never replicated to the Runner client
void ANetrunnerGameState::FilterStateForClient(APlayerController* PC)
{
    if (IsRunnerController(PC))
    {
        // Strip hidden Corp information before sending
    }
}

It's a cleaner model. And for a game where secrets are mechanically central, it's the only model that makes sense.

The Trade-off

Server authority means every action has a round trip. You click something, the server processes it, the server responds, your screen updates. In a fast-paced action game that latency would be noticeable and painful. In a turn-based card game where actions are deliberate and measured, it’s essentially invisible.

That trade-off is, honestly, one of the reasons a game like this is well suited to this architecture in a way that other genres aren’t. That doesn’t always happen. When it does, you take it.

Next week I’ll get into the network manager itself: how players connect, how the ready-up flow works, and what actually happens under the hood between the moment two players join a game and the moment the first card is drawn.

See you then.

Supporters

If you would like to appear here, you can support the project via the buymeacoffee or by subscribing to my substack to get extra content and preview of the posts.

This week I want to talk about something that took me longer to get right than I’d like to admit.

It doesn’t sound glamorous. It’s not a feature you’ll ever see in a trailer or a screenshot. But it’s the kind of decision that quietly determines whether a codebase stays manageable or slowly becomes something you dread opening. And hitting the wall that led me here was, in a strange way, one of the more clarifying moments of the project so far.

The Problem

Early on, I made what felt like a perfectly reasonable assumption: a card is a card. It exists in the world, it has state (strength, counters, whether it’s rezzed or not) and it needs to be visible on the screen. So I built it as one thing. An actor. A physical object in the game world that held all of its own data and rendered itself.

This works fine. Right up until it doesn’t.

The moment I started thinking seriously about multiplayer layer, about a server that needs to track the true state of every card in the game, hidden information that should never reach the wrong client, cards that exist in a hand or a deck but aren’t visible yet, the single-object approach started showing its cracks. The server doesn’t need to render anything. It just needs to know the state of the game. Forcing it to deal with visual actors to do that felt wrong in a way I couldn’t ignore.

Then came the hidden information problem. In Netrunner, the Corp’s hand and unrezzed cards are never visible to the Runner. If every card is an actor that manages its own state and its own presentation, enforcing that cleanly becomes surprisingly difficult. You end up fighting the architecture instead of building on top of it.

So I stopped, stepped back, and split the concept in two.

The Solution: Two Things, Not One

The insight was simple once I let myself see it: a card’s data and a card’s appearance are not the same thing, and they don’t need to live in the same place.

UCardInstance is now the true representation of a card in the game. It’s a lightweight object with no visuals and no presence in the world. That holds everything the game logic needs to know. Strength, counters, rez state, which server it’s installed on, its unique identifier. The server creates these, owns them, and uses them to run the game. They exist whether or not anyone is looking at them.

// UCardInstance holds all runtime state
int32 CurrentStrength;
bool bIsRezzed;
int32 HostileCounters;
FGuid CardGUID;

ACardBase, by contrast, is now just a shell. A thin visual actor that gets spawned into the world only when a card actually needs to be seen. It reads from a UCardInstance to know what to display, but it holds no game state of its own. When a card is in a deck or a hand that shouldn’t be visible, there’s no actor for it at all.

// ACardBase is just the visual — it references a UCardInstance
UPROPERTY()
UCardInstance* CardData;

It’s a clean line. Data lives in one place. Presentation lives in another. The server works entirely with UCardInstance objects and never has to think about rendering. The client spawns ACardBase actors only for the cards it’s actually allowed to see.

Why It Matters

This is not the kind of decision that feels satisfying in the moment you make it. There’s no new feature to show. Nothing looks different. You’ve spent a day… or several… restructuring something that was already working, just working badly in ways that hadn’t fully surfaced yet.

But the alternative is building a skyscraper on a foundation that has a quiet crack running through it. You might not notice it for months. And then one day the building shifts, and you understand exactly why that crack mattered.

Getting the architecture right before the complexity compounds is, I think, most of what separates projects that finish from projects that don’t. I’m trying to stay on the right side of that line.

That’s the deep end for this week. Next week I’ll pull back out and talk about the network layer: how you build a server-authoritative multiplayer system for a game where hidden information isn’t just a feature, it’s fundamental to how the game works.

See you then.

Supporters

If you would like to appear here, you can support the project via the buymeacoffee or by subscribing to my substack to get extra content and preview of the posts.

Subscribe now

The game is Netrunner, or rather, it’s my take on it. A digital game deeply inspired by it, built around the same ideas, the same asymmetry, the same philosophy. I don’t hold the licensing rights to the Netrunner name or its cards, and I want to be upfront about that. What I’m building is a love letter, not a replica. Whether it ends up a faithful adaptation or something that grows into its own thing, I honestly don’t know yet. But Netrunner is where it starts.

A Friend Who Knew Me Too Well

I didn’t find Netrunner. It was handed to me.

A good friend sat me down one day with a very specific kind of confidence — the confidence of someone who has already done the calculation and knows exactly how this is going to go. “This,” he said, “is the exact type of game you’re going to fall in love with.”

He was right. Annoyingly, completely right.

I don’t think I fully understood what I was looking at the first time. Two players. Completely different decks. Completely different rules for each side. One plays a corporation hiding agendas behind layers of ICE, intrusion countermeasures, the digital walls that stand between a hacker and the secrets they’re after. The other plays the Runner, a hacker trying to crack through all of it with nothing but wit, credits, and whatever programs they’ve managed to install before the run begins.

It sounds complicated because it is. But it’s complicated in the way a good novel is complicated. Every layer you pull back reveals something more interesting underneath.

Not Another Card Game

I want to be clear about something, because I think it matters for understanding why this project exists.

Netrunner is not Hearthstone. It is not Legends of the Runeterra. It is not a game about building the biggest number or drawing the best card. And crucially, it is not a game that hides behind RNG.

RNG is the thing that quietly kills my interest in most card games. That feeling of losing not because your opponent outplayed you, but because they drew the right card at the right moment. Or winning and knowing, deep down, that luck did most of the work. After enough hours with a game like that, it stops feeling like a game and starts feeling like a slot machine with extra steps. It gets boring. It gets frustrating. It stops being worth my time.

Netrunner doesn’t do that. Every card you draw, you drew because you built your deck to draw it. Every run succeeds or fails because of decisions (yours and your opponent’s). There is no topdeck that saves you. There is no lucky pull that wins the game. What you bring to the table is what you have, and what you do with it is entirely up to you.

That is not a small thing. In a genre full of games that use randomness as a crutch, Netrunner treats its players like adults.

There is also no “meta” in the traditional sense where one deck simply beats all others. Every game is a conversation, a psychological back and forth where bluffing, timing, and reading your opponent matter as much as the cards in your hand.

The asymmetry is the point. The Corporation and the Runner don’t just have different cards. They have different win conditions, different tempos, different ways of thinking about the board. Playing one side teaches you almost nothing about playing the other. It is, genuinely, two games happening simultaneously at the same table.

That kind of design doesn’t exist anywhere else. Not like this (at least to my knowledge).

A Game That Refuses to Die

Netrunner has had a complicated life. It passed through the hands of companies who eventually decided it wasn’t worth their time. It was discontinued. Most games don’t survive that.

This one did, because its community wouldn’t let it go. Null Signal Games, a fan organisation, picked up the torch and has been developing and publishing new cards ever since. Entirely volunteer-run. Entirely out of love for something they believed deserved to keep existing.

That’s the part that got me. A game so good that when the industry moved on, the people who loved it simply decided to keep making it themselves. There’s something in that story that feels worth honouring. And it’s part of why I feel comfortable building something in this space. This is a community that understands what it means to make something out of passion rather than profit.

Whether what I build ends up being a direct adaptation or something that finds its own identity along the way, the heart of it will always be rooted here.

Next week I get into the architecture: what it actually looks like to try and model something this rules-dense in code, and the early decisions that are either going to save me or come back to haunt me.

If you’ve played Netrunner before and you’re reading this, I’d genuinely love to hear from you. And if this is your first time hearing about it, go find a friend who plays.

Subscribe to keep being updated. See you next week.

Supporters

I would like to extend my sincere gratitude to the following individuals who have chosen to support this project. Your contribution means a great deal and helps keep this work moving forward.

• Andreia Antunes

If you would like to appear here, you can support the project via the buymeacoffee or by paid subscriptions to get extra content and preview of the posts.

Last week I planted a flag. This week I have to start giving some content.

A quick note before I get into it: this blog is, at its core, a personal log. I’m documenting my experience, my ideas, and my journey as honestly as I can. I want to be upfront, this is an ambitious project for a solo developer, and there’s a high chance it hits a wall I can’t climb over. I’m not promising a finished game. I’m promising to show up every week and tell you exactly where things stand.

Let me start with the question I’ve already been asking myself: why on earth am I building a card game in Unreal Engine 5?

It’s a fair challenge. Card games live happily in Unity. Some of the best digital card games ever made were built in frameworks far lighter than UE5. There’s an argument (a reasonable one, I think) that reaching for Unreal to build something that is, at its core, about rectangles with text on them is like hiring an architect to build a bookshelf.

I heard that argument. I disagree with it.

The Alternatives

I did consider the obvious candidates.

Unity was the first thing I looked at. It’s the natural home for this kind of project. Unity have a huge community, mountains of tutorials, proven track record with card games specifically. But Unity and I have history, and not all of it’s good. The last couple of years haven’t exactly made me trust the direction it’s heading: a licensing model that left a lot of developers feeling burned, decisions that seemed designed for shareholders rather than the people actually building things, and a market that appears to quietly agree. For a solo passion project, I need to trust the foundation I’m building on. Right now, I don’t.

Godot genuinely tempted me. Lightweight, open source, a community that feels like it’s building something with real conviction. For a different project, at a different time, I think I’d be there. But it would mean starting from zero with an unfamiliar toolset, and I don’t have unlimited runway right now.

In the end, the choice was simpler than I made it sound.

The Real Reason

I know Unreal. Not perfectly but well enough that I can move fast when I need to, and debug confidently when things go wrong. Starting a solo project during an already uncertain period isn’t the time to also be learning the fundamentals of a new engine. I needed at least one fewer unknown variable.

There’s also Blueprint. Being able to move fluidly between C++ for the systems that need it and Blueprint for the logic that doesn’t is exactly the kind of flexibility a solo developer needs. I can write the architecture in code and wire up card behaviours visually without context switching into a completely different mental mode. That matters more than I expected it to.

But honestly? There’s a third reason, and it’s the one that feels hardest to justify on paper.

This game, the one I’m adapting, deserves to feel like more than a card game. It has atmosphere. It has a world. The aesthetic is dense and specific and alive. I don’t want it to feel like a UI exercise. I want it to feel like somewhere you actually go. Unreal gives me the tools to chase that, even if I’m the only one building it.

Whether I can actually pull that off is a different question. That’s what this blog is for.

Next week I’ll finally stop being mysterious about which game I’m actually building. I’ve been hinting at it long enough and it’s time to give it a name, tell you why it matters to me, and explain why I think it deserves better than what exists right now.

As always, if this is interesting to you, share it with someone who’d get it. And if you want to support the project while it’s still just a blog and a folder of C++ files, just subscribe to get extra content. Every coffee buys me another hour of not panicking.

See you next week.

Supporters

I would like to extend my sincere gratitude to the following individuals who have chosen to support this project. Your contribution means a great deal and helps keep this work moving forward.

• Azahar Machwe

• Sara

• Elisabete

• Isabel

I wasn’t planning to start a dev blog this month. Honestly, I wasn’t planning most of what this month turned out to be.

Life has a way of reshuffling your priorities whether you ask it to or not. Mine got reshuffled recently. And somewhere in the quiet that followed, I decided to use the time well.

I’ve been turning an idea over in my head for a while now. There’s a card game I’ve loved for years — asymmetric, deep, with a cyberpunk aesthetic that never really let go of me. One side plays a mega-corporation hiding agendas behind layers of ice. The other plays a hacker trying to crack through it all. It’s one of those games where every decision feels like it matters, and the design is so elegant it almost makes you angry.

Nobody has done it justice digitally. So I’m going to try.

This is going to be a weekly log of that attempt — the architecture decisions, the dead ends, the moments where it clicks. I’ll get properly into the weeds next week.

For now, this post is really just me planting a flag. Saying out loud that I’m doing this, so that I actually do it. That’s what week zero is for.

If any of this sounds interesting to you, I’d love to hear from you. Would you watch a stream of this being built in real time? If there’s enough interest, that might be the next step. And if you want to support what I’m making before it even has a name, you can subscribe and get extra content and preview post. It genuinely helps, and it tells me someone out there is paying attention.

See you next week.