Hacker News Reader

Comment by lamacase | Hacker News Reader

> Cheating to reveal information locally was still possible, but these few leaks were relatively easy to secure in subsequent patches and revisions.

I don't understand this. Running the whole simulation locally on both ends means that a modified client would have access to the whole game state, and I don't really see how you could patch that out.

Anyone have any idea what they actually did? Try to detect modified clients? Obfuscate the game state to make it harder to interpret?

View on HN

In age II, it was CRC checks of game state that prevented cheating! Games would get out of sync if there was a mismatch, which could happen for various reasons.

I worked at MacSoft during the Age2 and Age3 days. The ports were faithful to the windows versions, but cross platform hadn’t been solved at the time because of this problem.

It also made long game play sessions longer because the calculated state kept getting more complicated.

There was one particular Mac OS X update that broke math interoperability for multiplayer because they changed how math worked on the OS. This meant we had to bundle a common math library to ensure the game the game states would line up, preventing unnecessary CRC checks.

In the Definitive Edition, there has been observed cheating in online ranked mode where players give themselves infinite resources. Evidently there's a way to do that without going OoS. This was probably the same in the original. This is besides the less complex cheat, removing fog of war. Seems the only thing stopping most people from cheating is, they don't want to.

Also, I used to play the Mac version a lot. It was great! Shame they made the remakes Windows-only.

You can call the command creation functions yourself, making the game think it's part of the simulation [1]. These types of cheat have been around ever since the original game, and the HD edition [2].

[1]: https://redrocket.club/posts/age_of_empires/ [2]: https://www.youtube.com/watch?v=3tl8AjDfnBk

I was thinking of reverse-engineering the game's calls out of curiosity, but I figured someone else already did it and wrote a nice article about it... and there it is.

> Shame they made the remakes Windows-only.

They run brilliantly through Steam on Linux, fwiw.

Sorta. You have to mess with the DLLs and Proton settings to make multiplayer work, and even then it's laggy. It also works in Wine on Mac in some cases, but for me it always had problems.

Never had to mess with anything for multiplayer AoE (or any other so far). That was in the before times, remember transgaming?

But CRC checks wouldn't prevent things like revealing units through fog of war right? The presentation of the game state couldn't be CRCd because each player has a different view of it. And the cheat client doesn't have to modify the actual game state to get that information out.

The game actually tracks this too, what is visible for each player, which gets slightly complicated with diplomacy changing. Of course this doesn't prevent you from just patching other parts handling this, but you cannot just simply modify this value, it will desync as well.

He wasn't asking about that - as far as I can tell - but rather about read-only cheating.

Which would let you know what your opponents are up to, without impacting state.

There is whole slew of cheats you can do without changing games state.

From maphacks to automatic reaction and microing units

Do you still remember what actual toolchain you used to build Age2? I have been looking into these games for some time, and the Mac build has been helpful, but has some oddities, like very weird floating point argument passing to functions, or unpredictable vtable placement ... knowing which exact compiler toolchain was used, would be incredibly helpful! I know it's probably some VisualAge C++ version because of the name mangling, but not exactly which.

How does that address map hacking?

One of the unofficial solutions used in Warcraft 3 was to spawn an illegal 3D model object in the corner of the map by a trigger as soon as the map begins, or during random spot checks during the map gameplay.

The model would crash the game (and world editor, that's why we have to spawn it during runtime) when displayed, but it wouldn't get displayed when under fog of war, so you'd put it in a place that is impossible to be seen by a player under normal circumstances. But if someone uses a fog of war cheat or a maphack, it'd crash for them.

Of course it won't prevent you from more advanced hacks which e.g. modify the client and display an overlay of the enemy units rather than just revealing the fog of war.

Similarly, a common technique used within notably the DotA community (of which's map didn't have such a tripwire) was to analyze the replay for what were termed "fog clicks", since for whatever reason object selection is part of the command stream and those using maphack would often, intentionally or inadvertently, select objects otherwise under fog.

That's cool. AoE2 scenarios sometimes had a different kind of anti-cheat, preventing players from deleting buildings that would otherwise count as points to enemies who raze them. That relied on a lot of complex triggers that I think involved spawning birds to keep count of things.

As long as users are running the game on their own computers, preventing that type of read-only cheating is not possible. "Solutions" to this problem come in the form of invasive spyware, such as Warden (Blizzard), Easy Anti-Cheat (Epic), Vanguard (Riot), etc. These are programs that run with the highest possible priviledge, inspect all memory/storage/devices/input, and report what they find to a server.

Ok, so option 1) is to make internet multiplayer run on a game server, not peer to peer, but that's not exactly running the game on their own computers.

Another option would be for the peers to only send data that the other should know (fog of war), but that's a lot trickier. Because you then need to figure out how to validate the unseen data wasn't cheating, too. You might be able to do something with this today, because storage, computation, and bandwdith has grown so much.

Maybe store all the local state changes, and when a block becomes visible, send its current state first, and then stream the history as time permits; the other side would accept the state initialy, until it could fully validate it. You would need some way to keep the randomizers in sync and fair, too.

But that only protects from seeing what should be invisible; you could still have computer enhanced movement and maybe enhanced display of data attributes that weren't supposed to be human visible.

And here we are using tech to try and solve social problems again :)

Well sure. You could just play with your friends. But some people insist on playing with strangers?

There's no social solution to getting players to not try to cheat in competitive games.

Yes, not having the entire game state on the user's computer in the first place is a solid choice. And for many games, that's exactly how multiplayer works. They run all the logic on a server, "never trust the client" (that is, validate all the input that clients send to the server), and only send data the user needs to know.

However for something like an RTS, the amount of data in game state updates can be prohibitively large to transmit to clients. The deterministic lockstep networking model described in the article is a solution to that problem. In that system, the only data transmitted is input, and each client updates locally, so it does require them to have a copy of the entire game state.

So you're saying that in order to avoid the "elitist" nightmare world of "just play with your friends, and people you trust" and "normal people are never going to want to be able to run their own servers!" all we have to do is hand over unlimited powers of surveillance to games corporations and succumb to their daylight banditry, paying a premium price for the privilege of being able to play call of duty with the teenage edgelords you may know from such online wonders as "youtube comments"? Sounds like a bargain! Sign me up! :)

Run entire game on server, send stuff to clients, get inputs from clients. Or full-on stream the game like Stadia (RIP). Which is hard with low-spec hardware.

Reply on news.ycombinator.com