I'd wager a guess that getting players will be the most difficult part by far, at least in the beginning. Make an MVP and focus on building a playerbase first, then come back to architecture when you're suffering from success if you get that far.

> then come back to architecture when you're suffering from success if you get that far.

Then it will be too late because you will essentially have to rewrite half of your project while your userbase is leaving due to unplayable game. Better to make good architectural decisions from the start, and make small optimizations when needed.

Just keep it simple and avoid optimization like the plague. you can spend 1 month building a prototype or >3 months perfecting a single piece. Just know that it is all smoke and mirrors and don’t worry about that.

I've some other posts planned about this topic, I don't know when or even if im going to deliver, but you are free to follow the blog and receive the update if I ever do.

I made a video series on networking theory for virtual worlds that has been well received: https://youtu.be/0wOZusuMIIM

I've also been working on an engine for the past few years if you want some code examples: https://github.com/Net5F/AmalgamEngine

Wow that series is really good! Please do more, you explain things very clearly and the visuals are easy to follow.

The basic advice in the article is sound really, make writes to db very async and keep all your state in memory.

Also important for most online games: any core gameplay relevant actions need to be server authenticated - usually you do RPCs from client to server, resolve the result, then broadcast it to the relevant clients.