TNet roadmap?

[hippocoder]

Hiya,

Clients are wanting certain features and so forth, so we would love to know a rough idea of where TNet would be around December/new year. In particular we are wondering what features you may be adding as we are evaluating TNet (which we bought anyway because it's so cheap) and Photon.

In particular:

- TNet server reliability - does it handle situations where it is flooded with client requests and does not break
- TNet reliable UDP - is this planned?
- TNet forced UDP - don't fall back to TCP?
- Any extra ease of use functionality which would suit twitch gameplay types.
- Any advantages over photon cloud?

I feel currently TNet is ideal for mobile/general slower paced games, turnbased and games which aren't reliant on fast gameplay decisions, and it appears to be really great for those, however with so much realtime shooting and aiming going on, the client wants to know if TNet is the right choice hence request for your future plans since multiplayer takes a while to develop and we don't want to be caught pants down in a couple of months.

Thanks

[ArenMook]

Flooding - I would be curious what number of packets would actually cause it to get flooded. I'm sure it's highly hardware dependent. TCP already has built-in flow control so it's only an issue with UDP.

Reliable UDP - No new plans right now. The only true reason to add rUDP would be to be able to use NAT punchthrough. TCP+UDP combo is generally just as effective and I've yet to get concrete proof to the contrary. I've looked into adding rUDP support earlier this year and having to do everything TCP does -- flow control, reliable packets, connection control, etc -- is a massive pain in the ass. I never write code I won't use myself, so if I get a solid reason to do it, I will. If not, I won't.

Forced UDP - Not sure why you would want this. If the initial UDP packet doesn't arrive, it's highly unlikely that others will, so using UDP would mean that all packets will simply get lost -- and it's not ideal.

Advantages over photon cloud - You don't pay for hosting if your players themselves can start up their own servers and do their own hosting. With the cloud you're at photon's mercy there. Also, twitch game + cloud latency? I don't know the kind of game you're making, but generally if you're talking about UDP / twitch gameplay, latency is going to be key, so player-hosted dedicated servers should be a "must have" feature, no?

-----

My roadmap with TNet is simple: use it and add features that I deem necessary. That's what I did with NGUI and it has served me well.

I want to finish Bluetooth support. I want to make TNet even easier to use. I want to add a built-in user authentication feature.

But most of all, I want to add the ability for users to start up servers, and if the current server goes down, another can be started up automatically on one of the reachable clients. I already know how I'm going to do it, it's just a matter of getting some time in October.

[hippocoder]

Note: not trying to change or argue with TNet's direction - I feel it probably is better suited to TCP as well, but onto the discussion:

Sounds very awesome! Regarding UDP, there's a solid open source UDP here: http://enet.bespin.org/

As for first packet being lost via UDP - as you know if TCP has been in use heavily by the system, there is proof online that a computer using TCP will cause a higher rate of UDP traffic to drop. So you're authenticating, you're setting up a users, or a chrome browser is refreshing, or twitter client is refreshing, or any number of things on a typical system will cause that first UDP packet to fail a lot more than normal - something like 5% to any%. This means doing a single test for UDP then telling the system to be TCP only isn't a very good move overall. But that's only a bad move if the system really should support UDP.

Regarding photon latencies, I found europe tests and US tests (respectively) to be within the 40ms range. This is slower than TNet which saved 10ms on average (not worth worrying about in terms of difference). People will need to run a server somewhere that manages traffic. This is what Photon cloud does. So performance wise, I don't really see much of a difference if you want the game to continue after a host quits. I don't think currently, it's vital for a user to host the relay server, in fact it means more dropped games at this point.

The main point of contention is Photon can get expensive, and I think this is the valid reason TNet is so appealing   I agree with today's internet, TCP is much better than it used to be though.

If I'm running on consoles, I don't have a nat punch through issue, but I do have an issue where users might switch off their machines suddenly so it boils down to if I want to use azure or leaseweb to host the relay server or pay Photon to do it. In fact I was surprised and pleased that TNet was so full featured so early on vs say, Photon. TNet is 10x easier as well.

That's my current thoughts about it.