91–100 of 189 posts
This site used to be Gamasutra didn't it?
They renamed it because they decided being a pun on "Kama Sutra" was just weird and unprofessional. (Same for the NIPS conference. But oddly not for the science journal PNAS.)
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" number…
Oh man I discovered Spring about 15 years ago. Never dug into the engine but wrote a couple Lia scripts. Great engine. Good times.
Earlier quoted context omitted.
That sounds terrible. I'm pretty sure the next game in the series, Age of Mythology, didn't permit missed shots.
Archer micro is a huge part of the competitive AoE2 scene. AoE4 had auto tracking arrows and I think folks didn't like it as much as it lowered the skill ceiling
It's relatively easy to spot when a game has a problem with low skill ceiling: the very best players have difficulty distinguishing themselves from other top players. So if the top player plays the 100th best player, in a game with low skill ceiling the top player might have a 55% chance of winning or so.
This is very much not the case in AoE4. And if AoE2 would add auto tracking arrows tomorrow, you wouldn't see the skill ceiling drop appreciably. You'd see players with strong micro but weaker macro and strategy fall in the rankings, and slower players with better macro and strategy rise.
Who remembers tourneys for Age of Empires at Sunnyvale Fry's.
Earlier quoted context omitted.
I understand what was said. I'm saying that sucks. I don't really care about the tiny minority of people who care about the skill ceiling within a super low level micro. RTS entices people into a strategy game. But the games are so similar that everyone but the top 1% of players will do better by simply following a predefined strategy and executing it as tightly as they possible can. And that sucks. Nudging guys a fe…
> I don't really care about the tiny minority of people who care about the skill ceiling within a super low level micro. I'd argue that most people that kept playing aoe2 online and kept it "alive" all care about that. > I'd like to see RTS games that randomize game parameters each time, requiring you to actually strategize. aoe2 already has randomised maps, I think that's why you actually get less strategy (in a sen…
I'm more of a fan of the in-game, on the spot strategizing that randomized maps force you to do, than the out-of-game meta-strategizing of fixed maps, where you do comparatively limited in-game strategizing.
Maybe a 2001 in the title would help?
The 28.8 was more than enough for me to place the article in time.
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" number…
If the randomness is deterministic doesn't that mean players could peek into the future?
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]
Earlier quoted context omitted.
I understand what was said. I'm saying that sucks. I don't really care about the tiny minority of people who care about the skill ceiling within a super low level micro. RTS entices people into a strategy game. But the games are so similar that everyone but the top 1% of players will do better by simply following a predefined strategy and executing it as tightly as they possible can. And that sucks. Nudging guys a fe…
Get ballistics!
- The AI system is not part of the deterministic simulation. This was surprising to me, and after contacting one of the original programmers it was explained that it was due to a desynchronization bug that the "AI and network programmers weren't able to fix it in time".
A consequence of this design regression is that, due to the AI now being authoritatively run by the designated host player, network congestion issues arose which lead to a clear series of progressively more aggressive optimizations to reduce egress traffic. This primarily consisted of a very simple filter (mentioned in the article) which dropped duplicate commands in the common submission path, meaning it applied to both local user and AI commands, along with batching of AI-submitted commands which would be flushed at rather arbitrary times.
I'll note that I've restored AI being deterministic in my project.
- A rather obscure determinism bug resulted from their compiler's implementation of a few CRT routines, namely fsin/fcos and a few others, which leveraged the specialized ISA instructions of the same name. The problem being that these transcendental functions are beyond the scope of the IEEE 754 spec. and ergo are hardware implementation-dependent. In practice, contemporary Intel/AMD chip families produce bitwise the same result, however those around the time of AoE are known to diverge on results to some small margin (as confirmed by an Intel engineer on a thread I came across while researching).
- The game employs a dirty-update system for rendering, not only that it's at a scanline granularity. This was something I was very pleased to see, as it's a exceedingly rare to see such an important optimization in games of this era (although common in earlier eras)
- There's some "interesting" naming conventions, one being prefixing member variables names with "value" -- there's even a "valueValue". Very little consistency in general in this regard, a reflection of independence between teams working on different components.
- While there are attempts at validation of input into the simulation (albeit woefully inadequate), it relies on ad hoc inclusion of PID (player ID) fields within commands. This is entirely useless, as this information is not authoritative and controlled by the players, permitting them to "spoof" the contextual information required for validation.
This is one of the more perplexing aspects of the engine, especially given the necessary information about the origin of a command is ofcourse available.
(As this information was later publicly published by other individuals I don't see a problem with elaborating on it here as I have)
- An example of missing the wood for the trees: session information goes through an ad hoc compression for its wire form (just bitpacks fields) to conserve bandwidth, however the architectural choice is to synchronize this session state by just having the host broadcast the state --dirty or not-- every 200ms, flooding the network pointlessly (atleast in the 18.8k days)
- While Age of Empires is somewhat notorious for its poor multiplayer performance (notably when contrasted with say, the recent "Definitive Edition"), and while its implementation of this synchronization model is certainly rather juvenile, it should be understood that the final MP gameplay issues are primarily due to the choice of a peer-to-peer topology over the public internet, which at the time was the most reasonable.
While superficially P2P may seem like it should achieve the lowest latencies for instance, the reality is that the primary determinant is the characteristics --jitter, delays and packet-loss, reordering, ect-- of the path between two hosts and a P2P architecture means there's n*n paths (network egress/ingress paths are typically asymmetric). In contrast, a server/client model you not only have far fewer routes, but datacenters are located at critical points in the network, roughly analogous to comparing travelling A->B along a freeway versus via the maze of residential streets.
- The state checksum "algorithms" involved are bordering on useless, atleast for state-tracing (such as when debugging desync. bugs.). They appear to have been devised by way of believing doing "a bunch of random bitwise ops" constitutes sufficient mixing -- a quick test demonstrated that csum collisions were not just possible, but occured sometimes for over 80% of inputs.
--
There's a lot more that could be said but I feel that's enough for now.