Hey folks! That's an interesting topic Mr Cheaterman Sir! I have designed an RPC-like system for big scale simulation last year, using CapnProto.
I had a very different approach. Long story short: Don't expose the whole game engine in your protocol. Concentrate on your particular problem you want to solve and design the interfaces. ;) Longer version: I don't find that modeling the full ECS in CapnProto to be an optimal way, due to the amount of data that needs to sychronized. You might be biting the wrong end here. ;) I personally find top-down approach in this case to be more effective, and possibly more optimal. I think you should really consider modeling the interfaces for the exact actors you need. No unions, no optionals. Just pure interfaces to encapsulate all the possible actions an actor can make. 1) Identify the actors/agents that you want to model. 2) Identify the amount of actors/agents that need to be synced, to consider how much you should care about optimisations and batching. The more data to be synced the more latency. And choose the design properly. 3) Define the actuators and interfaces (which you will implement in your "systems" later) for your praticular synchronizable objects (which will become your "entities"). Do not model components in the protocol, it's usually wasteful. Use interfaces in a true RPC fassion. 4) Group and model the interfaces in CapnProto. Groupping of interfaces will give you option of batching, so you won't need to sync every object separately. You can then process all the received data in a "system" inside your engine. 5) Implement your RPC handling systems as a layer on top of your ECS. The net sync systems will set internal states of your entities to be processed by different systems in a continous fassion and hopefully seamless fassion. I do hope it helps somehow. Cheers! -Paweł On Tue, 12 Mar 2019 at 12:29, The Cheaterman <[email protected]> wrote: > > Hi Kenton, > > Thanks for the great and detailed answer! I'm very happy to learn that you > think Capnp is a good fit for games. > > About the partial updates that you mentioned - I'm reeeally not sure how much > it would matter in real life scenarios (the overhead of IP and TCP/UDP seem > like they would cost more anyway), but I also implemented this in my current > proof of concept: that's why I mentioned generating capnp files from Python > in my second post, since the fields would be defined by the user of my > library. > > In my case, I do it like this: > > entity.capnp: > ``` > @0xd904b3a7471d0981; > > interface EntityHandle { > # Can dynamically add props that were initially absent > update @0 (property :EntityProperty); > } > > struct Entity { > type @0 :Type; > > # Initial state, may not contain all props, must not contain duplicates > props @1 :List(EntityProperty); > > enum Type { > player @0; > bomb @1; > item @2; > } > } > > struct EntityProperty { > # Should describe all possible properties of all Entity.Types > union { > name @0 :Text; > coords @1 :Coords; > movementSpeed @2 :Float32; > radius @3 :Float32; > } > > struct Coords { > x @0 :Float32; > y @1 :Float32; > } > } > ``` > > The idea here is that the anonymous union inside EntityProperty should > contain all possible properties an Entity can have, and I'd only transfer the > ones that change (basically those that are used) over the wire. > > I don't want to bother you too much with this until I get something more > concrete on the entity property generation thingy, but when my stuff starts > to look serious enough, I'd absolutely love it if you could take a quick look > to my capnp schema - I'll have documented it by then to make it even easier > to read. > > Thanks again! > > > Le lundi 11 mars 2019 21:58:45 UTC+1, Kenton Varda a écrit : >> >> Hi, >> >> In my blog post, when I said "Authors' preferred use case", I meant the >> respective authors of the various serialization frameworks -- NOT the author >> of the blog post (me). That is to say, the author of Flatbuffers had gaming >> in mind when he designed it. >> >> I think Cap'n Proto would be a great fit for games. However, I'm not a game >> developer myself, and it's possible I don't recognize what's important >> there. Some people have told me that it's extremely important for games that >> optional fields don't take space on the wire -- if you agree with that, then >> Flatbuffers may be a better choice for that reason? But, this claim seems >> bizarre to me. Why would games rely so much on optional field compression? >> The suspicion I get is that games tend to use poorly-organized data >> structures with excessive optional fields, rather than designing a proper >> information hierarchy. I suspect that you could find an alternative design >> that works well with Cap'n Proto and results in cleaner code, too. But this >> is just my intuition; I haven't looked closely at the problem. >> >> -Kenton >> >> On Mon, Mar 11, 2019 at 1:09 PM The Cheaterman <[email protected]> wrote: >>> >>> Another bit of extra info that I forgot to include - I'd be using the RPC >>> system for that, I like the idea of giving players ownership of the >>> entities they are allowed to edit/control by simply sending the handle to >>> the remote version! >>> >>> >>> Le lundi 11 mars 2019 20:58:07 UTC+1, The Cheaterman a écrit : >>>> >>>> Hi Kenton, long time no see! :-) >>>> >>>> I'm trying to build a very basic entity synchronization system over the >>>> wire, basically videogame netcode, out of Capnp. >>>> >>>> The only info I found when I search "Capnp for games" online is a post >>>> where you compare Capnp, Protobuf, Flatbuffers and SBE. You seem to >>>> recommend Flatbuffers for games there - can I get some insights into your >>>> rationale? >>>> >>>> As you might expect from me being here, I'd really like to use Capnp for >>>> this, because I really like it. Do you see any particular reason why I >>>> wouldn't want to use Capnp for that kind of purpose? >>>> >>>> Thanks in advance! >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Cap'n Proto" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to [email protected]. >>> Visit this group at https://groups.google.com/group/capnproto. > > -- > You received this message because you are subscribed to the Google Groups > "Cap'n Proto" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > Visit this group at https://groups.google.com/group/capnproto. -- You received this message because you are subscribed to the Google Groups "Cap'n Proto" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. Visit this group at https://groups.google.com/group/capnproto.
