drop-in basic networking for artemis-odb

[DaanVanYperen]

Authoritive server/client setup.

Leverage Artemis' design and make networking accessible out of the box for ecs/networking newbies. High level convention/annotation based networking of components, on top of some networking systems with a nice example or two, client/server system reuse. The actual networking framework can be completely outside ECS.

Take an existing network framework, integrate it in Artemis ECS pattern like you would any externalized framework, and provide enough sauce so it both becomes a drop in solution and a great reference for prototype networking with Artemis.

https://github.com/junkdog/artemis-odb/issues/103

Epic ticket, break up as we go!

\ Reworked list **

• [ ] udp (lossy) channel
• [ ] tcp (robust) channel
• [ ] client packets
  • [ ] keyboard input packet
  • [ ] network event
  • [ ] refusal handling (client futures, basically a rollback request)
• [ ] mirror entity + component to clients
  • [ ] create from archetype
  • [ ] transfer component state
  • [ ] developer codes component <-> packet
  • [ ] subscribing clients to components
    • [ ] configurable lossy attributes
    • [ ] configurable lossy update interval.
    • [ ] configurable robust attributes
    • [ ] configurable robust update interval.
  • [ ] removeFromWorld
• [ ] subscribing clients to entities

Core

• [ ] authoritative listener server on client.
• [ ] component delta updates (server to client)
• [ ] scoping (what entities to network)
• [ ] entity network-id
• [ ] entity level networking metadata (what fields do we sync, how do we sync)
  • [ ] manual entity serialization helper & dirty state detection
  • [ ] automated reflection based (de)serialization helpers & dirty state detection
• [ ] dispatching networked events (see #4)
  • [ ] remote entity instancing
  • [ ] remote entity destruction
• [ ] customizable lifecycle management.

Not right now:

• Component or template level networking metadata.
• support for diverging systems, where client and server have different implementations of the same component.
• dedicated server
• component level networking metadata
• Interpolation
• Extrapolation
• gain/loss, min/max caps on fields.
• UDP support (error correction on lossy protocol)
• GWT support
• Ready system
• Lobby system
• Component recording (rollback for hitscanning)
• Client agnostic networking frameworks / swappable networking frameworks

[Namek]

For "delta updates" I'm currently porting https://github.com/benruijl/quakemonkey to use KryoNet. Not sure if I'll get it done before holiday.

If I can ask. I'm still not convinced to that auto sync thing, how it may work. Could you provide me with some example (besides "position sync")?

[DaanVanYperen]

If I can ask. I'm still not convinced to that auto sync thing, how it may work. Could you provide me with some example (besides "position sync")?

Very high level it would attempt to keep the client and server in sync as much as possible. What that translates into functionally depends a lot on the implementation, and what the developer actually desires to delegate to it.

Would be something like: perform a dirty check on data with a shadow copy, package it sensibly, and push it out to clients. (for Artemis, this may include entity composition and lifecycle). It would mean writing or generating delta checkers and (de)serializers. Generating and scoping would be based on convention or some metadata the developer provides.

Main use would be correcting client predictions (like who picked up a gem and is currently holding it, is that door open or not, what is the score) and syncing the different clients (who is playing with me, active weapon and location of the other players, are they currently shooting, how much ammo do they have? is one of them currently in a paused state?).

Manual server->client events will still be a big part of it. is everyone ready to play, are we switching level? Client->Server will be almost exclusively be events.

Developers who do not care for using this feature, can just go pure events instead.

But all in all, eventually just got to start building to see what works in practice. I think the whole networking thread helped a lot.

[Namek]

Hey, how's your research on this topic? Any proof of concepts?

[DaanVanYperen]

Some basic scaffolding is done on the develop branch. Just ticking the basics one by one, so not much there yet. Right now dealing with a three week work crunch, and hopefully the Ludum Dare in between, so contrib will have to wait for a bit. Looking at a big chunk of free time after that.

[Namek]

I just finished porting of that library to be using KryoNet: https://github.com/Namek/quakemonkey

My unit test works, not sure about real use. It still needs some optimization because there's pretty much buffer allocation done without pooling. Also needs some more useful form, I think. Will it be useful to you, anyway?

EDIT: pooling is probably done. I'm not sure if there are any leaks or whatever. VisualVM is not as good as it looked like.

[DaanVanYperen]

Ah cool! I´ll certainly take a closer look when my schedule clears out.It will be educational at least!

[Namek]

Another one port: C++ EPIC (Entity Position Interpolation Code) library ported into Java: https://github.com/Namek/jEPIC

Supports interpolation of immutable values like Float, Double, Float array, Double array and custom classes like Vector2. See unit tests.

[motconvit]

I think the capability to rewind and replay is important if we want smooth networking.

Our world will process with a fix delta time, such as 0.015. So we can store inputs and states with their frame number. On client, we will calculate the new state based on local input immediately (prediction). On server, we will calcuate the new state when there is a new input sent from client. If the input is sent with smaller frame number than current server frame, server will rewind her state to that smaller frame then replay to the current frame with all the inputs. Correction on client can be done with state sync (so we only need to rewind and replay on server, server will send state delta to client). Or it can be done with rewind and replay too (client receives validated inputs from server). We can annotate systems we want to rewind to exclude those we don't want to rewind (e.g. render systems) and the problem left is just saving and loading state.

[Namek]

Hi @motconvit ! Do you have any experience in implementing such feature? I feel that it's useful for higher pings, like more than 50ms. Gaming on LAN without rewinding server would make no difference, do you agree with that?

[DaanVanYperen]

Depends on the game I'd say, 50ms for a high speed shooter might benefit from a rewind. That's enough time for a player to move several inches, or for a leg to shift out of a reticule.

[motconvit]

All the game projects I participated in aim to enable gaming over internet where 200ms ping is possible. On LAN, the ping is much better (3~4 frame), we can even turn off prediction, the players still have the same experience, the inputs will be considered sent at the frame server receives them. At 50ms ping, players still can feel the difference and see some buggy physics.

But in most cases, we want to support internet gaming, right? I have some experiences implementing those, using ECS architecture. The problem is always serializing/deserializing the state. The rest is quite simple.

[DaanVanYperen]

@motconvit Wouldn't mind seeing some reference code or getting hit with some good keywords to google. Still new to most of this.

Your solution bounds the client to a certain simulation speed as well, correct? How do you sync up the client and server frame counts initially? (say for a late join).

[motconvit]

I think I can port some part of my old project to be used as example, maybe next weekend.

http://gafferongames.com/networking-for-game-programmers/what-every-programmer-needs-to-know-about-game-networking/ http://gafferongames.com/game-physics/networked-physics/ Those are some good reads. He provides code/binary examples too. (the comment section has a lot of good references too)

And about the frame count, I don't think it's necessary for client and server to share exactly same number, numbers in a small window are ok. Server can even advance passively or go ahead in time. If we're using Kryonet here, I believe this method can help with the frame count sync.

[Namek]

I think I can port some part of my old project to be used as example, maybe next weekend.

Would be awesome if you did so.

[DaanVanYperen]

For reference later https://github.com/junkdog/artemis-odb/issues/219

[Namek]

http://bitbucket.org/dermetfan/libgdx-box2d-multiplayer

[DaanVanYperen]

Putting in freezer! Spring cleaning.