> rebuilding all the game logic in the server-side
Start with the server side. This doesn't actually have to be a server application with no gui, but start with the simulation of an entire world. Then 'rebuild' the logic on the client side. This lets you be a little bit sloppy—though not too sloppy, obviously—because it's ok if the server 'cheats', since it has no ulterior motives (except for yours) and there's only one of it.
Real client-side verification and prediction is usually more complicated than just replicating game logic, you have to be able to restore the world to a correct condition after a wrong prediction in an elegant and unoffending way.
It depends on game/implementation but client wouldn't really roll dices on their sides. Someone shooting a bullet that does 5-10 damage would tell server to shoot bullet and server would reply "you did 7 damage"
Especially on an mmo, there is no point telling a player that his next fireball spell will also trigger a "random chance to put a burn status on target". The client would start casting a fireball, which takes a second to cast and in that 1 second duration the server would decide what is the damage and if the spell is going to apply burn and by end of 1 second, you would get that information so you can see the damage values and burn icon on enemy
Presumably nothing! But I imagine it was might have been impractical, given lockstep method is kind of predicated on "Do it because you can't afford to only compute and transmit from a central node."
In the era it was used, server chips weren't really a thing. So it was really just "the current decent CPU."
It's also a fascinating historical artifact of "when internet play meant orders of magnitude higher latency and jitter... as a base assumption."
Per memory, there's a bit where they've ferreted out all the sources of randomness, except one. And any source of randomness corrupted the downstream calculations, as they used global random generators.
There was some reason they couldn't just trace calls directly.
It turned out there was a line of code somewhere that said something like "if {rare condition} then rand.next {to figure out where to place an ornamental rock/tree}."
That was specifically related to their networking/syncing architecture -- deterministic lockstep simulation -- in which every client is running their own local instance of the simulation, and the only thing being passed around are interactions with the simulation.
So everyone has to have the same results and calculations at all times, because there's no authoritative simulation.
It's a common architecture for RTS's (interactions are far less numerous than individual entities) but not for general multiplayer games due to issues like everyone must be on the same timestep at all times -- so a single slow player slows everyone down. See https://gafferongames.com/post/deterministic_lockstep/
If you have an authoritative server, so the client is mostly a presentation/view of current game state, you don't need to be as careful about maintaining game state/randomness, since there's only one source of randomness (your authoritative server)
Ofc, if in an mmo you have multiple authoritative servers, you're back to the same problem, though I believe the more common solution is to have 1 server - 1 universe, and you just have more game instances (shards/servers) to connect to
There's a reason there were no complex-state MMOs at that time -- there simply wasn't the residential bandwidth to perform continual full state updates (latency aside).
E.g. grid & turn-based vs 3-D free-motion worlds
They say they specifically made the deterministic lockstep choice because it was the only option that (a) allowed the multiplayer gameplay they wanted and (b) fit within the computing and network resources of the time.
AoE uses classic lockstep simulation, as far as I remember. For a variety of reasons, most importantly, latency, this approach is not usable for genres other than strategy.
Right, so that's the challenging part about building a client. But you still want to build the server first, and let that be the authoritative source of gameplay design, because a desync for one person is not as bad as a desync for everyone but one person. (And that only becomes more true as the number of people on your server grows.)
note that in rpg you don't stimulate the physics. every tick of combat you send an effect packet that describe that turn action result and the client side plays whatever effect is needed
once a combat session is initiated you don't need that much prediction going on because where you move is uncorrelated to where a fireball hit or not, only player stats.
the real exception are are effect, as the client need to reconcile them, but the client can chat as much as it wants as long as the presentation matches the server player stats: it can for example position area effect that hit on the server in a position such as the player hit was in range.
the client only had to make sure action result are in sync, not the world physical station whole
That works for something like WoW, but there are exceptions: in EVE Online for example, damage depends heavily on the relative movement of player ships.
It's true for WoW, but many more modern MMORPGs have solid characters, attacks tied to animation (remember infamous Conan thing with female characters having lower DPS because of that), raycast hit mechanics, and yes, real physics.
Usually these mechanics are not as advanced and detailed as in single-player action games, but they do exist.
Start with the server side. This doesn't actually have to be a server application with no gui, but start with the simulation of an entire world. Then 'rebuild' the logic on the client side. This lets you be a little bit sloppy—though not too sloppy, obviously—because it's ok if the server 'cheats', since it has no ulterior motives (except for yours) and there's only one of it.