Re:MMO Architecture: Source of truth, Dataflows, I/O bottlen...
by Stevvo on Friday September 29, 2023 @03:04PM
(#37708790)
How did they get the architecture so wrong on that "open-world game that involves driving cars and running pedestrians over"?
Re:MMO Architecture: Source of truth, Dataflows, I/O bottlen...
by dmoy on Friday September 29, 2023 @04:35PM
(#37709789)
I assume that is a tongue-in-cheek description for Grand Theft Auto (whichever one they made online). That game series has had various moral discussions / controversy surrounding it since before the first game came out like 25 years ago.
Re:MMO Architecture: Source of truth, Dataflows, I/O bottlen...
by anon56 on Friday September 29, 2023 @06:11PM
(#37710697)
Not Carmageddon?
Re:MMO Architecture: Source of truth, Dataflows, I/O bottlen...
by aleph_minus_one on Friday September 29, 2023 @07:41PM
(#37711421)
> Not Carmageddon?
Carmageddon is not an MMO. :-)
Re:MMO Architecture: Source of truth, Dataflows, I/O bottlen...
by BossingAround on Saturday September 30, 2023 @11:05AM
(#37716121)
Well, neither is GTA to be honest, at least not by default.
Re:MMO Architecture: Source of truth, Dataflows, I/O bottlen...
by PsylentKnight on Friday September 29, 2023 @06:54PM
(#37711047)
I assume he got that and he was referring to the jankiness of GTA Online.
For example, it took 5+ minutes to load for years, until some random guy fixed it for them [1]. Though I suppose that had little to do with the overall architecture.
Re:MMO Architecture: Source of truth, Dataflows, I/O bottlen...
by Stevvo on Friday September 29, 2023 @08:49PM
(#37711845)
It uses a client-authoritative peer-to-peer architecture, which has surely led to billions in lost revenue. I'm surprised selling GTA money has done as well as it has, considering anyone could get as much as they wanted for free.
Re:MMO Architecture: Source of truth, Dataflows, I/O bottlen...
by kaliqt on Saturday September 30, 2023 @03:45PM
(#37719032)
Could be APB honestly.
Re:MMO Architecture: Source of truth, Dataflows, I/O bottlen...
by doctorpangloss on Friday September 29, 2023 @06:03PM
(#37710643)
Let's say that among developers there was a history of how-to-implement gameplay traditions (like how to implement third person player movement, "gameplay ability systems", etc.) in programming languages besides C++. Like C# & Java, the memory managed friendly ones with good tooling. And let's say you're forbidden from reinventing C++ inside C# or Java, like Unity's Burst does (so called HPC#). But you can "do ECS," there are C# and Java ECS frameworks, that even use those languages respective arena allocation techniques well. You just aren't allowed to reinvent C++, but you can use a high performance middleware that does, like Netty.
Would you choose to author an MMO backend in one of those friendlier ecosystems?
Do you think there's value in having access to other Java applications, to embed as libraries of your grander "in memory" ideas?
Re:MMO Architecture: Source of truth, Dataflows, I/O bottlen...
by gabereiser on Friday September 29, 2023 @09:23PM
(#37712022)
On the backend, you aren’t limited to sub 16ms frame rates and can use languages that provide more productivity vs performance. I have infinite cloud compute, but you only have 4ghz and 16gb ram. I’ll send you highly optimized c++ and use ruby as my cloud language, it doesn’t matter.
You’ll frequently find Java, C#, Go, and Python as backend rpc/tcp game servers.
Re:MMO Architecture: Source of truth, Dataflows, I/O bottlen...
by jfim on Saturday September 30, 2023 @12:21PM
(#37716951)
Interestingly enough, Jeff Kesselman was working on Java middleware for MMOs at Sun Microsystems before the Oracle acquisition. See https://en.m.wikipedia.org/wiki/Project_Darkstar
There's definitely some value in using more productive languages for the backend services, as they're not as latency sensitive as rendering.
There's concerns around race conditions as you pointed out, message passing from client to server, and server to server, client hand-off between sharded servers. Those synchronization problems will haunt your dreams.
I think the biggest issue I still struggle with is tracking those ephemeral problems that only happen on one shard, or only when going between this shard and this shard, but not the other way. One useful trick is obviously message prioritization and different messages heading to different servers - though these days I'd put a message router in front of the shards and the router handles persistent connections other than the usual technique of direct connection I've employed in the past.
Contributed to an MMO game that involves waving light sabers around, another where you defeat the ultimate prime evil (though I was more on the fraud detection on that one), an unpublished MMO that unceremoniously died during the 2008 financial crash, a "shared world" game that involved animals, an open-world game that involves driving cars and running pedestrians over, a few "internet scale" websites, and am currently lead back-end on another MMO - though our database requirements are relatively simple this time around, but it is still again, read-at-start-up, write-only-when-necessary.