TCP can be used for the vast amount of MMOGs, the only time you really need to look at UDP is if you are doing something more immediate fps-like or more realistic physical simulations. You described moving tile by tile which is actually what Ultima Online did and that uses TCP... also note other small games that use TCP such as World of Warcraft :)

Hi. I'm new to these forums but I've been working as a pro game developer for almost 14 years (Including 3 mmo's)

You should definitely go with TCP/IP.
Using a simple string based protocol is a good solution.
You might want to encrypt the transfer later for safety, but for now it should be fine. Remember to put all validation on the server. Never trust the client :)
But again. That's advanced stuff. Just get your game up and running and you can worry about the other stuff later.

Funny enough I did a free java crossplatform TCP/IP server that can be scripted in &#106avascript. If you are interested you could try it out at http://www.furi.dk/socky<br><br>Also, if you have any network game specific questions, just drop me a PM :)<br><br>With regards to WoW they might use UDP for quick movement, but you are better off to implement some kind of interpolation as it saves bandwidth. <br>But again in a turn based game (as mentioned already in this thread) it's just not needed. <br><br>Regards<br><br>/Ozak

Quote:Original post by Blodyavenger
Thanks a lot for your answer, that helps me a lot :)

But, let me correct if I'm wrong, doesn't WoW uses UDP and TCP mixed?

I'm pretty confident that WoW uses only TCP.

To elaborate a bit. It's my opinion that UDP is simply not needed. Even for action games.

You are going to need some kind of movement interpolation/prediction anyway if you are doing an action game.

This will also ease the load on the server/bandwidth :)

/Ozak

I completely agree with Ozak on the protocol to use. I've just gotten our TCP client/server modules working about a week ago. Watch your architecture and make sure it is simple.

I went through 3 iterations of architecture only to realize that I had too many abstracted layers which really slow everything down. I would also recommend that you stick to using the base Socket class, not TcpClient/TcpListener. Those are classes that inherit the Socket class and while you can have a high-performance server using them, it is yet another class that takes up resources.

Finally, my last piece of advice is to, at the very least, use asynchronous processes on the server. I would recommend using the same async processes on the client as well. Using async will reduce thread implementation on your part as async automatically threads at the system level (and therefore much more reliable - so they say...).

At this point, our server is nearly 100% free of anything event driven. And, we will be implementing async UDP processes. With the product we are developing, we simply want to provide the game dev the option of using TCP or UDP as both have their uses. UDP could be useful for the mundane chat messaging between players.

Have fun and don't hesitate to PM me if you have any questions.

One thing I forgot to mention using TCP. I believe the maximum packet size is 1500 bytes, although you can set your buffers higher. I set my buffers to a default of 1024 bytes. Because the client/server will queue outbound data, I can check the byte size of outbound messages to try and fill the entire 1024 bytes.

Yes, TCP may be a little slower than UDP, but, if you take advantage of your buffer and fill it, then the appearance of being slower will greatly diminish.