Easy and Fast UDP Gaming Library - is there a need for it?

General Discussions
#1

For our upcoming game www.asteroidfight.com I put a lot of effort into making a well-documented library which has an easy API for fast and reliable UDP communication and can use different serialisers (kryo) and other networking libraries (netty) as well as java-only.

The library is specifically designed for games and I also plan to integrate the logic for lockstepping and client-side-prediction - depending on your type of game you can choose the technology you want to use. Also an out-of-the box general-use lobby server (written in kotlin though) will be included.

I’m in a little bit of a dilemma here. Brief background information: I quit my day job to develop games on my own :wink: Hence no money for me right now and living of of my savings. Now the idea came to me to put even more work into this library and try to sell it as a product. But on the one hand, I don’t know if there is a market for it and on the other hand I would gladly give something back to the open source community.

It would be perfect to even combine the two: open source the library and make money of of it. (maybe dual-licensing? idk)

Well, any thoughts on that?

#2

It would be cool to see a lightweight TCP server/client library.

That simply manages the multi-threading of the selector and worker threads. Other libraries are awesome and all but have too much going on the backend for me.

I started working on one but I’m too busy with other things for my game at the moment.

#3

Maybe tengi is of interest for you, still in development but Java server and client are working: https://github.com/noctarius/tengi

#4

What exactly would you like better in a TCP library compared to an UDP library?

#5

I need the reliability of a tcp connection.

However, I’ve already started to implement Java NIO into my game dev suite.

#6

Well, maybe I made this not clear enough, but my library allows you reliable and in-sequence transmission of packets. :slight_smile:

You can use different strategies to achieve this. The most bandwith-saving would be the sequence numbers, but you can also use acknowledge packets.

#7

UDP is connectionless and does not guarantee that the data will arrive. And if it does arrive it will most likely be out of order.

So I guess I’m interested in seeing how you accomplish this.

#8

There are many ways to build a thin layer on top of the UDP client that actually sorts and keeps requesting packets until they are received just like a TCP based client. As far as I know, Kryonet utilizes one.

#9

There are a boat load of ways to do this man.

The REAL problem is implenting it as good as TCP does (when making it into a library for other people to use). You can pretty easily make your own little reliablity layer of UDP that suits your needs specifically to what you are working on and make it work well, but to actually make it good enough for other people to implement with their projects is a challenge.

@OP, I would run some benchmark tests on your reliablity layer and see how it matches up with TCP.

#10

I know it’s possible. But is the overhead of transporting extra data and processing worth it?

Ultimately, I feel that the speed increase would be negligible.

Also, how can you tell if you missed a packet, without some crazy work around?

#11

For your last question; timestamps or a variable included in the packet to indicate which packet number it is.

For your other questions, many game engines and major games use a UDP system with a TCP layer on top. It’s definitely worth it in some cases.

#12

Alright you guys win.

I just don’t need that kind of speed. Tcp tends to do it for me.

But I guess in AstroidFight and SoulFoam’s game the shaved milliseconds makes a huge difference.

#13

The queing of packets is the reason I use UDP. My game is pretty fast paced, so the slight stutters TCP COULD cause would be pretty detrimental to gameplay. Slight stutters to other games that aren’t fast paced won’t even be noticeable really.

TCP works for 99% of everything, it really comes down to YOUR GAME’s needs.

#14

@KudoDEV: of course it strongly depends on what game you’re making. But if you want fast paced action and be packet-loss tolerant then I’d suggest you use UDP with a custom reliability layer.

Glen Fiedler wrote a nice article about this: http://gafferongames.com/networked-physics/deterministic-lockstep/

If you don’t want to read the full article scroll down to the fourth animation (counted from the top). In this example he uses deterministic lockstepping (like Asteroid Fight does) and compares the UDP + reliability layer to the TCP version. With increasing latency and packet loss TCP will perform increasingly worse compared to UDP.

[quote=“KudoDEV,post:10,topic:55075”]
You don’t need a crazy workaround. Like Soulfoam said, there are a few ways to accomplish this. Right now in my library you can decide if you want to use a sequence number for ordered, reliable transmission or ACK packets for reliable transmission (without the ordering).

With a sequence number a missing packet is easily detected. So if peer1 sends 1,2,3,4 and peer2 receives 1,2,4 it will buffer message #4 and ask peer1 to re-transmit message #3.

With an acknowledge packet the sender sends the message and wait for the receiver to acknowledge the receipt of the message. If this doesn’t happen after X ms it will just retransmit it again, until the message is acknowledged.

And there are more ways to do it. Also a combination of the 2 mentioned here. Usually a sequence number will be all what you need. ACK packets increase the bandwith usage.

@Soulfoam: No, I don’t need to be as good as TCP, because the library is designed specifically for something else than TCP. If I’d need TCP then I wouldn’t implement it another time, but just use it.

But I agree with you that I should make benchmarks to compare my library against TCP :slight_smile: This will yield some interesting numbers for sure :slight_smile:

#15

Have you really looked at tengi (noctarius’ suggestion)? It implements SCTP, it would be far better than driving UDP more reliable by yourself.

Both Tengi and Kryonet are interesting for me, I wouldn’t create yet another network library.

#16

It doesn’t yet implement it but it is on the roadmap. Unfortunately I think there is not yet any experience to use it on WAN systems but it’ll also feature RUDP and TCP transports. The main idea is to find the best transport possible between server and client.

@TO: Sorry doesn’t wanted to hijack your thread.

#17

@noctarius: No worries - it’s related, so it really is ok.

The features and the API look interesting, but it is designed for a lot broader purpose than what I intend. My library has a very specific use-case to which it can be optimized and for which it works well. That doesn’t mean tengi wouldn’t perform well in the specific game context, but it would probably need more work to fit better for gaming purposes. :slight_smile:

I will have a look at tengi. :point:

#18

Cool I always look for interested people :slight_smile: Feel free to contribute too :wink: