Hello! This is my first post on GD.net (I'm a long reader, but not poster) and I have some simple questions. Currently I'm developing a Private MMO RPG engine (in VB6) that uses Final Fantasy 1-6 style graphics (minus the 3D/isometric) and a FF3 battle system. The situation is I'm basing the engine around scripts (think Unreal Engine) so I can make it nice and flexable (and give 100% control to the server). The problem arises when I want to have different Server code and Client code communicate in harmony with each other and the native code behind it. I'm trying to think of a way to transmit things over winsock (a few winsock controls for ease :D) and not overuse the connection so (a) it is efficent with network, memory, and CPU resources and (b) doesn't require a DSL connection to use. With 5+ background scripts running and 18+ scripts per user (one in two approx. actually use the connection at all), it's not exactly easy as the server has to communicate on the ball all the time. On any remarks regarding compression, I'm trying to keep this (for the time being) 100% VB so I can tweak it myself and also it needs to be processor safe (ie. doesn't take 80% for one job). After this version, I plan to go to C++ for speed and better expandability :D so it won't be as bad then.

Okay, without knowing a lot more about your game design and underlying protocol, I'll stab wildly around in the dark...

Uhm... something like FF3 for combat should not really need that much compression! Entities are performing actions from a limited set of options (couple of bytes to index), there'll be some form of damage or heal (another couple of bytes). Server keeps track of HP / MP etc, you don't REALLY need to state snapshot this (I'd perhaps do that at the beginning of each combat round if you really have to).

So, basically bugger all traffic from 'pure' combat.

Movement, you're basically 2d. Snapshot positions on change should be fine. (4 bytes, sporadic)

Compressing text (for chat) is a pain in the backside. Best is not to bother, and make it relatively low priority traffic, highly localised (in terms of game area), and maintain a high-priority goes first principle.

All in all, you shouldn't have THAT much traffic (although as I've mentioned elsewhere I believe in most [non-physical simulation] games the majority of lag-causing traffic comes from chatter, which can be alleviated by a solid spatial partitioning system).

I'd suggest a TCP implementation (I know I normally wave the UDP flag, but hey, I don't think you need it, nor the headache of making it reliable) using nonblocking sockets in batches and use select() to determine incoming data.

Hope this helps.

Sorry for being slow :D

Ya, about the non-specific thing, I kinda' wanted to allow you to see a whole picture... but got carried away :P

Thanks! This help has been exceptional!