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]
> <javascript:>> 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] <javascript:>.
>> 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.
