Hacker News Reader

Comment by m_myers | Hacker News Reader

One of Red Alert's hacks was making dogs (the unit) distinct from dogs (the projectile). That is, a dog was a dog until it began its attack. At that point it transitioned into a dog projectile, which looked like a leaping dog but wasn't targetable. Then when it collided with the enemy (infantry only), the enemy was insta-killed and the dog transitioned back into an interactible unit.

What this meant is that you could use rules.ini to make an anti-infantry submarine that launched dogs, if you so desired. Or a dog artillery. Or a dog man that used his dog gun to shoot dogs at men.

View on HN

I took advantage of that to defeat a hacker in an online game once.

the hacker had changed his infantry so they were very cheap, and fired different weapons. he planned to win by building a barracks and spamming out his super soldiers. but there's one thing he hadn't counted on: dogs.

not only did they have the dog projectile behaviour, but infantry also had a behaviour where they had a few seconds when emerging from a barracks where they had a running animation, we're targets, but couldn't fire.

by spamming dogs, and sitting one directly outside each barracks he built, I effectively plugged each inflow of super soldier, as the dog would turn into a projectile and instantly kill all emerging infantry.

good times. and that was a particularly satisfying rage quit...

So which rules.ini does the game follow? Whoever hosts I would think? Were you hosting the hacker?

I would have thought the multiplayer code would assume deterministic consistent calculations on all clients, and only share human inputs with a cycle delay to mask the network delays. If that were the case, though, then things would get weird very quickly, and likely end with a failed assertion somewhere and the game erroring out.

Perhaps instead all calculations are performed on one client, and the full game state is transfered to the rest, perhaps with some sort of delta encoding? That seems like a fairly high bandwidth approach for the 90s, but I suppose it depends on how clever they were with the state representations.

Explicitly sharing one client's rules.ini would of course be a reasonable hypothesis. Maybe there was a good reason for that during development, perhaps so that gameplay designers could quickly iterate without having to copy files back and forth with coworkers?

sorry, was what, 20 years ago now? can't remember the details (or how the multiplayer aspect/engine worked back in the day) other than the story. I do remember I probably wasn't hosting, but I also didn't have insight into what the hacker was doing except what could be observed in-game :(

If it was the DOS version of Red Alert 1, it used the host rules

As I remember, for direct-dial-up games, both players had to have an identical rules.ini file or the game would instantly announce a desync error when the second player joined the game.

I wonder if this means that if a dog is the last unit alive, it can't attack without triggering the loss condition.

That's the sort of bug you suddenly wake up and think of a week after the game has shipped.

Deep man. Deep.

Should be quite easy to test in a multiplayer game.

But what does a dog attach if it's the last unit alive?

The parent comment meant your last unit alive. If the enemy had no units, you would have already won.

You could also make a dog that would turn into a bolt of lightning (and then back into a dog)

https://en.wikipedia.org/wiki/Raij%C5%AB ?

Or a fireball.

Reply on news.ycombinator.com