Devlog #12 — Event to Packet Overhaul, Client Packet Parsing, and Inventory Packets

Over the past few days I focused on something that isn’t flashy on the surface, but massively improves how Pixel Odyssey works under the hood: a full Event → Packet → Event pipeline.

This system is the backbone of how the server talks to the client, and how the client updates game state in a way that’s clean, fast, and scalable. The goal was to reduce tangled dependencies, make new features easier to bolt on, and prepare for future systems like NPCs, shops, and quests.

Here’s what changed.

Server Events Can Be Subscribed To

The server now uses a much more robust event-based architecture.

Instead of directly calling other systems or injecting references everywhere, the server generates domain events like:

• InventoryOperationEvent

• BalanceChangedEvent

These events get published into a lightweight event bus where other systems can subscribe. That means features no longer have to know about each other. For example:

• The inventory system doesn’t need to know about the outbound network system.

• The movement system doesn’t need to know about the map system.

• New systems can “listen” without rewriting old code.

This makes everything cleaner, more testable, and much easier to extend.

It also fixes the classic indie-dev problem of one system needing to call another which then accidentally calls back into the first. No more spaghetti.

Events → Packets: A Smarter Packet Builder Layer

Once the server emits events, a packet builder layer transforms them into outbound network packets for the client.

This layer:

• Takes a domain event

• Looks up any extra data needed (like item definitions)

• Builds a serialized, versioned packet

• Queues it for the correct player/client

It feels like a proper translation layer now instead of one-off logic scattered around.

The packet builders also support delta updates, full-sync messages, batching, and versioning, so the game can scale without drowning the client in packets.

Client Parsing Rework: Packets → Client Events

On the client, I rewrote the inbound parsing system so packets become client events, just like the server.

Instead of the client directly mutating game state in 10 different places, it now:

1. Parses the inbound packet

2. Emits corresponding client-side event(s)

3. Subscribed systems react accordingly

This keeps the front-end predictable, debuggable, and modular. If I add new UI windows later (like quests or achievements), they can subscribe without modifying any networking code.

Inventory Operations Now Flow End-to-End

A big part of this devlog: Inventory operation event/packet handling is now implemented end-to-end.

This includes:

• Adding an item to a slot

• Updating the quantity

• Slot versioning to prevent desync

And for the first time, I successfully tested item pickup → inventory packet → client slot update.

Right now I only tested the “add” case, since item pickup is using that path, but the foundation is solid and all other operations will plug right in.