Hello dear reader, this series of posts will follow my journey in seeing if the old addage is true about net code. I'm going to completely build a wow-like game engine and document the experience with code, dev builds and the process I use to make the game here. This project goal is one of learning and seeing just how far along I can get.

The Tools Copy link

For building this project I'm going to use bevy 0.19 and rust, a limitation I'm imposing is building everything I need from scratch (with LLM generated code for things that would make it difficult to do it in a timely manner). So your AI notice is here!

That being said I'll be aiming to build some interesting systems the old fashioned way specifically a simulation / presentation boundary. The LLM usage will be minimal when the generated code is more for speed then implementing anything foundational.

Mechanics? They'll rip you off! Copy link

The core mechanics we'll be building are:

1. Wow's snappy combat systems
2. Hook's
3. Event based networking with snapshots
4. Multiple clients
5. NPC's, both friendly and enemy.
6. Asset packing

These systems are a great base and will prove to myself and hopefully to you just how hard building a online game from scratch actually is.

The big question, why not X engine. Copy link

Well theres a few reasons for why I'm not using <YOUR_FAVOURITE_ENGINE_HERE>, the main one is that I've simply spent a lot of time in bevy and I'm a programmer in my career. I know code, I know systems I don't really like using gui's and I don't love the complexity. But bevy isn't a perfect engine, it's main drawback is that it takes a long time to compile. And this is a trade off I'm willing to sit with for access to rust's glorious ecoystem around networking and serialization. I suspect this will be a core area.

The next reason is I already have bevy projects which I can borrow code from, specifically I have a way to package assets into a single binary file I lovingly call flock. This gives me an opportunity to make a bevy plugin in parralel with this project for asset loading in a distributed manner. So it's a win-win!

The third and most important aspect for me is how well LLM's work with bevy, given I don't have experience with LLM's usage in Unreal or Unity this maybe less a super power then I think it is but my experience so far is everything being text in a single project makes using codex or claude a breeze.

Some less important features is bevy can package for the web which will allow inline demo's placed in my blog posts which can help me and any readers understand the concepts I'm building in a dynamic and interactive way. I can build examples that will isolate and demonstrate each system.

So if I haven't lost you yet welcome to the journey! We're building something we shouldn't in a engine that's not even version 1 for fun and a distinct lack of profit.

Step 1, getting our project ready Copy link

To begin our project we're going to make some assumptions, namely that having a presentation and simulation distinction is going to make building our online capability far more achieveable. So my idea here is to have 2 packages in a rust workspace, simulation (our actual game, with events for player interactions), and client our presentation layer and client that can display to the user what's going on and connects to our sim.

Given we have a client / server model we're also going to need a server package and a net package for shared data definitions so our client / server can communicate together.

This layour opens the door for also having a completely offline build of the game, where the simulation runs with the client creating a single binary.

• client: presentation and connection logic
• server: The interface and interaction handler for mutating our game world
• sim: Where the game actually runs, using a fixed update we can maintain a tick rate and send mutating events in a CQRS pattern to have an auhtorative server maintain our game state.
• net: Shared structures with their serialization and deserialization logic both client and server depend on this.

You can find the tag here

You'll notice I've added a few dependencies, the two most important are quinn and postcard. These will be our transport mechanism for communicating online, using QUIC as our transport allow's us to leverage some powerful UDP which works with the event based networking model I want to use. Postcard is a leightweight serialization that will be a great starting point for a small footprint.

Final Thoughts Copy link

So everythings now in place to start building some logic, stay tuned for next week's first challenge, writing out a character controller in our simulation!