Creating a DM multiplayergame with TCP or UDP?

[Rasmus]

As some of you may know I have started on a 3D DM AGAIN This one supporting multiplayer and beeing alittle bit more editing friendly (something I have been having difficulty with before)..
So now in the next months I will start some topics about some problems I may encounter and hopefully get some pointers from you guys

Now about networking:
As I see it every client is like a keyboard to a computer that is the server.
So if one client tells the server that he wants to go left, the server take this information and uses it to move the character left, then send back the the characters new position to all the clients.
It is just like pressing left on a keyboard: The keyboard presses left, the computer gets the signal and moves the character left, then uses this information when rendering the scene and sending it to the monitor.
So a client is somewhat a keyboard and monitor in one, and the server is the computer.

Does it make sense?

The problem here is that sending data between a server and client isn't as fast as sending data between a keyboard and a computer and a computer and a monitor.
When using TCP the server may be able to send out new information to the clients about 20 times a second (50 ms). Now lets say that a client sends the information that he wants to move left to the server, the server gets this information 50 ms later, then sends the information with the characters new position out to the clients 50 ms later.
This results in that after a person behind the client-computer pressing left on the keyboard woun't see the camera moving left until 100 ms later.
That doesn't sounds so bad for a traditional DM game that updates about 6 times a second. But imagine a realtime fps game having this constant lag, it would be very annoying!

UDP may solve this problem because it sends its data in a instant. But the thing about UDP is that some data may be lost or come in the wrong order, something that could be a disaster.

I was thinking about creating a realtime 3D DM game (as usual), and I am somewhat splitted about if I should use TCP and suffer the lag, maybe find some way to overcome it by using prediction. Or use UDP and create a way to ensure that the most important information always will be sent.

In the end I want the game to support up to 32 players in a dungeon at once. And that the gameplay should be in 3D and not with step by step movement or floating movment between steps. And I must say that I would prefere TCP before UDP because I have a feeling that UDP will create some bugs in the long run that would be hard to get rid of.

Maybe some of you have some tips about this or just want to discuss it and come up with more not already forseen problems.

One way to get rid of the lag is too "hide" it with some tricks.. Those of you that played warcraft 2 may have noticed that all the orcs says "Yes sire", "Right away sire" when giving them an order, I heard that this was something the developers inserted to hide the lag when moving the orcs. Now when one presses on the position the orc should move too, it says "Yes sire" and THEN moves. Feels natural for the player, but wouldn't be without the talking

[Bit]

The client just does all the action that is not relevant for other players.

Give it a try with UDP. If there are hangups, TCP/IP can hardly fill the holes too.
A timestamp or event number in UDP with some caching until the order is correct should do it.
With the time won you can send important things twice.

[Rasmus]

That is true, the best thing would be to let the clients handle all the their own character data. But still, the server would need information like a characters inventory, experience, health etc. Otherwise it would not be able to handle some gamemechanics like beeing on a trigger that checks if the firestaff is in the partys inventory..
One thing that would be great were if I could combine TCP and UDP, but this is NOT recommended according to several websites..
A eventnumber as you said would solve the "in order" problem, and a returning "OK" with the eventnumber from the reciver back to the sender would fix the "did it arrive" problem. But one thing that really bugs me is that some data sent can also be corrupted when reaching the reciver. I can imagine that a double sending and letting the reciver check so that the data is exactly the same would fix the "corruption" problem.

The streaming or less important data could be that the server constantly updates the clients with their dungeon surroundings. The worst thing that could happend there is that some items or players in the dungeon may flicker but come back to their right place directly afterwards, and if a client picks up an item that is corrupted, the server can check if it is okey and send back if it is or isn't okey.

Now I am getting too technical These are just ideas popping into my head, and they may not be completly well thought.
What I accually is worried about here is if it sure enough with UDP, is it posible to ensure that some data will arrive just by creating alot of saftycoding? I guess I will have to do alot of tests and check if it would work under extrem circumstances..

But I am leaning alittle bit more towards UDP now, thanks for your suggestion bit

Maybe I should have taken this topic to gamedev instead, but I am really interested in hearing what you all have to say, or if you have some experience of networking in general

[Bit]

I really think that there is no game around using TCP/IP - that's all UDP.
About corruption: a checksum is needed, that of course. There are already technics that can fix corrupted datas, just by good checksum technics.

[Babe Bridou]

The thing is, you really really don't need it to be real-time. The most successful fighting game protocol at the moment, GGPO, actually adds lag in order to create a better illusion of real-time.

[Rasmus]

Thanks bit, then I will use UDP Looking forward to testing and defeating all those "may happen" problems one by one

@Bridou: That sounds interesting, it is just that I want to use traditional networking and build my own ways to overcome the problem instead of inserting some extra addon library.
My experience tells me that if I use some others work that aren't applied for my specific needs, I would have to change the game after the networking posibilities and not the other way around.
Lets say that I later on want to create the posibility to be able to change who is controlling the server, just to make sure that the game continues if the server logs out.
Maybe this library supports that, but still, this is just one thing on the top of my head, and alot of new stuff always arrives. I just like knowing whats going on behind the scenes

[Babe Bridou]

Eh, I didn't link to the library itself for a reason No need to incorporate any third party code, just get some inspiration from the way they dealt with their own problems to help you deal with your own!

I haven't watched their implementation that closely but I'm not 100% sure they even use a server/client hierarchy. I think whoever is behind in game ticks at a given time acts as the server holding the truth, and the other one just makes assumptions and rollbacks when told, and uses a short & variable input lag to reduce the amount of rollbacks.

[Rasmus]

Yes, getting inspiration from others work by studying it is of course something I usually do before going into something new. Nothing is worse than discovering that things could have been done differently after months of work..

I get the implementation not using a server/client hierarchy, and this is somewhat interesting. Now lets say that I use UDP, as I understand it it doesn't use server/clients in the same way, it is just to send data between the computers that have been registered in the network. Now this would mean zero lag! Sounds very good, but isn't it very easy for things to go wrong then? Ofcourse everything can be programmed to perfection, but as I have been taught a server/client relationship is the best way to do things to ensure that nothing will go wrong. If I am going to discard the server/client relationship I would be absolutely certain that all information gets sent and nothing gets corrupted, and then I would be back using tcp/ip.. But it may require some more thinking here, the idea really appeals too me