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.<p>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.<p>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).<p>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).<p>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.<p>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.<p>* 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