I’m not convinced solving the data replication technique once, as briefly alluded to, is not a good idea vs. this model of addressing multiple “presences” and having different messaging topologies.
In particular, doing synchronization for realtime gameplay (not an adventure-style game like Habitat) requires a lot of tricks (like prediction, rollback, etc) and I think it makes a lot of sense to extend that synchronization over all gameplay, not just the physics state of object. Although I suppose you could have a hybrid system.
Further, there’s not really a reason you can’t have your data replication mechanism replicate inputs (with states as a fallback) rather than just states (which would indeed take more bandwidth).
It’s interesting to read about the “division of responsibilities” (paraphrasing). I think in a “modern” game, this would simply be done by specifying that components in an entity-component-system have a policy that say whether they are local-only or if not, who they should be replicated to (everyone, just the player who owns the object, etc). This would give you the “data-hiding” (the player shouldn’t know what’s in the treasure chest, the player shouldn’t know exactly* what the monster is going to do next, etc, player shouldn’t be able to read each other’s chat log, etc).
All in all, I think I’d definitely take a more data-driven approach than an “objects sending messages to each other ala Smalltalk”, at least in a game I’d like to write. The describe system likely works great for what it was meant for, though.
I do think it is enormously useful, re: unums, to pick the right vocabulary or even pick “new” words, within reason. Even if you’re just thinking in your own head, it can make things more clear.
* This is actually an interesting one. Having a “dummy” AI for clients that doesn’t know/do everything the server version does seems like an option
> One obvious pattern to look into is a pure peer-to-peer model, where all presences are equally authoritative and the “true” state of reality is determined by some kind of distributed consensus mechanism.
Makes me wonder if you could model Mage: The Awakening as a distributed reality consensus MMO. Sybil attacks would be the primary weakness. Though, if it was a paid game you'd _somewhat_ mitigate that.
The thoughts about clients being authoritative on different unums is very interesting. For larger worlds, it could lead to some interesting scalability results. If I'm exploring a region with no one else, the server can simply let the client decide whats happening and offload that work. For more dense situations, clients would need to communicate with each other. A server could detect cheaters via sampling, maybe? Of course, the problem might be that a cheater might only need to cheat a proportionally small amount of time. For sparse situations, you could just do the full computations later and punish harshly if cheating is detected. For dense situations, it becomes difficult to determine how you could roll back fairly.
It's very interesting. I'd love to build something like this. I think it could have very compelling, novel gameplay mechanics. Not quite sure what the story would need to be to drive players into those mechanics though.
"World object" seems pretty self explanetory to me, implying the holistic embodiment of an object in every dimension in which it exists. It's in the same family as "world model" (for robotic systems) or "world reference point" (for dynamic systems), etc.
Introducing a new term "unum" seems an unnecessary abstraction, but I like thinking about the superpositional nature of virtual objects. That's a pretty fascinating topic and probably an area that can be mined to achieve efficiency improvements.
"world object" is the new term you introduce. It is, admittedly, more common than "unum" and not new in the sense that its parts are familiar, but you're already defining a new term.
It is a bit odd, but I think I like it.
Also, world object could be the 'object' for the 'world', as opposed to the unum of an item in the world.
If you find all of this fascinating and want a bit more history, Chip and Randy's original game, Habitat, is now playable at neohabitat.org
You can even sign in with an original C64 if you have one! Probably easier to emulate though, and https://neohabitat.org offers everything you need to witness their incredibly revolutionary creation in the flesh, today, live and free.
In particular, doing synchronization for realtime gameplay (not an adventure-style game like Habitat) requires a lot of tricks (like prediction, rollback, etc) and I think it makes a lot of sense to extend that synchronization over all gameplay, not just the physics state of object. Although I suppose you could have a hybrid system.
Further, there’s not really a reason you can’t have your data replication mechanism replicate inputs (with states as a fallback) rather than just states (which would indeed take more bandwidth).
It’s interesting to read about the “division of responsibilities” (paraphrasing). I think in a “modern” game, this would simply be done by specifying that components in an entity-component-system have a policy that say whether they are local-only or if not, who they should be replicated to (everyone, just the player who owns the object, etc). This would give you the “data-hiding” (the player shouldn’t know what’s in the treasure chest, the player shouldn’t know exactly* what the monster is going to do next, etc, player shouldn’t be able to read each other’s chat log, etc).
All in all, I think I’d definitely take a more data-driven approach than an “objects sending messages to each other ala Smalltalk”, at least in a game I’d like to write. The describe system likely works great for what it was meant for, though.
I do think it is enormously useful, re: unums, to pick the right vocabulary or even pick “new” words, within reason. Even if you’re just thinking in your own head, it can make things more clear.
* This is actually an interesting one. Having a “dummy” AI for clients that doesn’t know/do everything the server version does seems like an option