MMORPG - Advice

**Gadget** · 25-09-2003, 12:49 PM

I am working on a MMORPG and seem to have hit some problems using Indy TCP/IP components.

Does anyone have any experience in this area? I have been advised by 2 developers to use IO Completion Ports, but the API for this is a nightmare to say the least... Indy 10 will support IOCP, but it's still heavily in development.

Can anyone recommend any IOCP wrappers, or other TCP/IP components that are good? I think the problem I have with current Indy components is that they use a thread per client, which seems to be causing me some timing issues.

**Alimonster** · 29-09-2003, 08:47 AM

Here's a bump for your post, young man.

**Gadget** · 02-10-2003, 08:09 AM

Thanks for the bump, here another... *bump*

**Zanthos** · 03-12-2003, 06:55 PM

What problems have you run into?

**Gadget** · 20-01-2004, 03:12 PM

Originally Posted by Zanthos

What problems have you run into?

Tearing my hear out lol...

OK, the game is looking really good. The client is now pretty stable and bit by bit I am adding in new functionallity.

The main problem I have is tracking player movement, I can't work out where the main bottleneck is. I suspect there are a few problems:-

1) Using normal NMServerSockets. Don't I need to use IO Completion ports? Are they non blocking and what are the implications when using blocking or non blocking sockets for MMORPG.

2) Should I be using UDP? If so, how much different are the UDP components than TCP/IP?

3) The creature and player tracking currently consists of a 2D array of TList.

eg. Array [0..399,0..399] of TList (Infact it's actually a dynamic array, but to simplify the explanation...)

ie. [X,Y].Creatures.Items[n]

The TList is the floor position, and multiple creatures can occupy one floor space at the same time. (maybe this is a bad idea on its own, and I should just have a Pointer instead of TList.

4) When a player moves I am scanning in the X, Y visible range, so I can see if any new creatures to inform the player about. The downside to this is that I am effectively running a for loop of X := 0 to 30 and Y := 0 to 30, which is 30 x 30 x checking the TList at each that spot and if its not vacant, and if the player doesnt already know about the creature then send packet.

So... The scanning isn't the best way and I am looking at replacing this with a Linked List, BUT will that be more or less effective? Having done timing tests I have determined that TList opperates faster than my Linked List. The benefit of using the linked list is that when a player moves, I wont have to delete and entry from one TList and insert into another TList on another tile, I can simply update the X and Y of the player. The downside is that I will have to scan the whole Linked List and check every single creature to determine if its visible.

There must be an easier way of coding MMORPG

**Zanthos** · 23-01-2004, 12:45 PM

I'll start with the UDP versus TCP...

UDP, unlike TCP, is connectionless, that is, there is no persistent connection between the client and the server. When data is recieved by either end, they can determine which IP the data was sent from, and therefore can incorporate a quasi-session based system. UDP has the advantage of being able to send data faster, because it has no overhead associated with packet sequencing, re-sending, etcetc. FPS games have an advantage over other games, that is, the speed at which the game is being played, missing the odd packet or two is not a worry, as the data lost will soon be masked by the new data arriving almost instantly after. Of course problems arise when large amounts of packets are lost, and this is often usually the case.

To keep the game simple, I would suggest TCP, as it makes the network layer simple, and allows you to concentrate on getting the rest of the system working

. Something that might interest you is that DirectPlay incorporates UDP transmission methods with its own management for packet loss and packet re-sequencing.

IOCP may be a good idea for the server, as they allow Windows to manage the thread pool for active connections over multiple processors(should they exist), instead of you having to do the work yourself. Some information on IOCP can be found here: http://www.codeproject.com/internet/iocp.asp

As for the client, non-blocking sockets are suffient, as you will probably be only handling one or two TCP connections.

The world array that you've created is definitely not the best way to go about it, as you're having to scan through this every time a player moves, so you can send information to them. A better way to create the map is to pre-segment it, that is, split the map into 6x4 tiles for example(note: the size of the segment should be no smaller than the area of tiles visible on the screen). So when a player steps into another segment, you simply send the object data for this segment. When a creature moves around, check to see which players are currently in the segment the creature resides in, and send the new position of the creature. The client will also need to recieve updates on the surrounding 8 segments, so that transitions between segments are not visible by a hoarde of creatures suddenly appearing.

**Gadget** · 25-01-2004, 06:57 PM

Originally Posted by Zanthos

I'll start with the UDP versus TCP...

UDP, unlike TCP, is connectionless, that is, there is no persistent connection between the client and the server. When data is recieved by either end, they can determine which IP the data was sent from, and therefore can incorporate a quasi-session based system. UDP has the advantage of being able to send data faster, because it has no overhead associated with packet sequencing, re-sending, etcetc. FPS games have an advantage over other games, that is, the speed at which the game is being played, missing the odd packet or two is not a worry, as the data lost will soon be masked by the new data arriving almost instantly after. Of course problems arise when large amounts of packets are lost, and this is often usually the case.

To keep the game simple, I would suggest TCP, as it makes the network layer simple, and allows you to concentrate on getting the rest of the system working

. Something that might interest you is that DirectPlay incorporates UDP transmission methods with its own management for packet loss and packet re-sequencing.

IOCP may be a good idea for the server, as they allow Windows to manage the thread pool for active connections over multiple processors(should they exist), instead of you having to do the work yourself. Some information on IOCP can be found here: http://www.codeproject.com/internet/iocp.asp

As for the client, non-blocking sockets are suffient, as you will probably be only handling one or two TCP connections.

The world array that you've created is definitely not the best way to go about it, as you're having to scan through this every time a player moves, so you can send information to them. A better way to create the map is to pre-segment it, that is, split the map into 6x4 tiles for example(note: the size of the segment should be no smaller than the area of tiles visible on the screen). So when a player steps into another segment, you simply send the object data for this segment. When a creature moves around, check to see which players are currently in the segment the creature resides in, and send the new position of the creature. The client will also need to recieve updates on the surrounding 8 segments, so that transitions between segments are not visible by a hoarde of creatures suddenly appearing.

Thanks for the reply

I will change the server to work using segments, I don't know why I didn't do that sooner. I still have a problem that is related to the TCP components, I posted under General.

The server socket won't have just a couple of connection, the aim is to handle say 1000 at least, so I am going to have to try and implement IOCP.