Hacker News Reader

Comment by Centigonal | Hacker News Reader

Seeing stuff like this on here fills me with nostalgia.

I basically learned to code thanks to a few helpful and extremely patient IRC members in the Spring RTS engine[1] community (some of whom I spot in these comment sections on occasion - hi!), and deterministic lockstep simulation for online play was one of the first ideas that totally blew my mind when I learned about it ("b-but that means all the "random" numbers on every computer need to be the same! and so do all the floating point calculations across different hardware!"). Of course, to me at the time, that was deep magic that I thought I'd never be able to fully understand.

[1] see https://springrts.com/ - or check out http://zero-k.info/ and https://www.beyondallreason.info/ for games on the engine that are still pretty active

View on HN

Yup. That’s how networking basically worked for Army of Two. We only sent controller input over the network. Everything else was deterministic.

That was more or less the case for Starcraft 1 as well.

It made for incredibly funny replay of matches if you happened to own a newer version of the map, as the game starts to diverge from reality and enter some parallel universe where players do nonsense actions and movements.

Just showing my appreciation for Army of Two. It was a cheesy, weird game, but my friend and I loved playing it regardless. The online multiplayer worked great!

If the randomness is deterministic doesn't that mean players could peek into the future?

Generally (I hope I get this explanation right), the PRNGs on all players' computers are the same algorithm, with the same seed, executing the same player commands in the same order. So as soon as the game starts, you can predict what all future calls to random() will return.

However, you can't predict the other players' actions, and those actions can insert an arbitrary (and unpredictable) number of random() calls between now and when your next action executes, so practically there is no gameplay advantage you can get from that avenue (AFAIK).

I'm gonna take an uneducated guess that though the simulation is in lockstep, the order of inputs from all players is not known ahead of time so you can't peek too far.

Though maybe a cheat engine could simulate a few branches of possible inputs a few steps ahead and adjust inputs when it discovers split-second advantages?

Everyone waits for your client's next step. Your client can basically pause the game whenever it wants, giving you time to do something.

But there are bigger exploits. IIRC, the client sends separate actions for buying a unit/tech/building and paying resources, and the other clients don't enforce that they go together. This allows malicious clients to buy without paying. It's been seen a few times even in the ranked mode of the Definitive Edition remake. https://www.reddit.com/r/aoe2/comments/fjjudp/cheaters_are_a...

This way of doing things made sense for the time, and the execution was impressive. It was pretty reliable, nobody wanted to cheat anyway, and yes lag was a big problem but there wasn't another good way to do it back then. Nowadays they should have something else IMO.

> Nowadays they should have something else IMO.

Finally found a genuine use for the blockchain, since the server is only used for the lobby!

Mine virtual AoE gold and record it in the distributed ledger. Primitive path finding is also AI, so now you just need some investors!

DE seems to use a relay server. Old version relied on P1 setting up port forwarding and always being present in the game, not an issue anymore.

That problem doesn't seem inherent to the model, it's a flaw in the selection of client steps. Is there any reason transactions like building and paying couldn't be atomic?

I don't know why it's that way. My guess would be complexity. Yeah, they could fix that later, but they can't fix the fog of war cheat, which would also be pretty powerful.

The problem is simply the lack of validation -- I detailed it a bit below in my top-level comment.

The only exploits that are inherently applicable in the case of a simultaneous deterministic simulation model are those of the information-revealing class (e.g, "maphack"). This is where a standard AH system comes in.

Deterministic multiplayer has an assortment of cheating problems that weren't really a big deal in the early days of online multiplayer, but certainly are now, in the days of ranking systems and very competitive gaming.

The obvious one is that the client knows where everything is on the map, even when hidden by fog-of-war - so client-side hacks can reveal that.

A hacked client can easily desync the game too, or stall it and cause it to time out if the player is losing.

Yes - and this can be AWESOME. In a deterministic engine, anything not affected by player input can be forecast accurately - by the computer, not the human user.

For NBA Inside Drive 2000, I developed all the ball physics to be deterministic and "reasonably" accurate (25 years ago, in a world without physics engines). This meant that after a player made a shot and the ball left their hands, the trajectory, scoring or bouncing off the rim, was purely controlled by deterministic physics. This in turn meant that we could foresee what was going to happen, and feed the player AI with that while the ball was in flight.

Obvious use was to move characters with high rebounds stats towards the place where the ball would bounce after not scoring, so they're more likely to pick the rebound.

[edit: for shooting the ball, the instant the ball would leave the player's hands I computed the perfect trajectory to hit a shot, and then based on the player stats, I'd nudge the trajectory off center. It was then purely up to the physics to determine if the ball went in or what]

You can reseed with player inputs every cycle

Not to any meaningful degree -- inputs (from humans) permutate the state. You can, however, compute say the initial world state, revealing the map/resources/ect. Ofcourse in this case you'd may aswell just look for some sort of maphack.

Hedgewars also uses deterministic lockstep. But due to the floating point problem, the main developer elected to write custom fixed point math instead. It works since the game doesn't use a lot of physics.

Oh man I discovered Spring about 15 years ago. Never dug into the engine but wrote a couple Lia scripts. Great engine. Good times.

You are not by chance the guy responsible for the commando-sneak widget? Computes the view circles of know units, sneaks a whole army single file into enemy territory by chosing a out of sight route?

No but that sounds fun! The best one I made was a really hacky script called followmouse that would constantly tell selected units to move towards the cursor. It was for microing around defenses and whatnot.

The random numbers I understand, because I’ve used a similar principle to make tests deterministic. The trick is to make the same number of calls to the generator and use the same seed. The floats are really thorny though, differing subtly across CPUs. Did they just rely strategically on rounding? Make heavier use of integers?

Don't use floats (it wasn't a 3D game) or if you have to, make sure every float is derived from an integer that's kept in sync. And don't do anything that affects simulation state based on those floats.

Age of Empires 2: Definitive Edition consistently de-syncs when playing across a M1 Mac (using Windows 11 Arm or Crossover) and an x86 machine, and I suspect the difference in floating point behavior described here is the culprit: https://developer.apple.com/documentation/apple-silicon/addr...

Doesn't sound unlikely.

LHC@Home had big issues[1] with AMD and Intel machines giving very different results to the same work unit. They traced it down to the exp() function behaving different, and ended up using a library[2] for anything more fancy than basic arithmetic.

[1] https://lhcathome.web.cern.ch/sites/default/files/OPENshort....

[2]: https://github.com/SixTrack/crlibm

Another reason for me to stay clear of the M1 for now. It’s really fascinating, but it’s not quite there yet. I’ll let others work the rough edges away before I give it a try.

Ditto - I use them to generate infinite mocks in GraphQL for local dev and staging: http://www.blankenship.io/essays/2022-11-30/

The id of the node acts as the deterministic seed. Really handy when building views that slice and dice data, it feels like you’re interacting with a database.

Reply on news.ycombinator.com