Forum :: Game Development :: Network DO's and DONT's for Game Engines - IT Hare

Recently read this blog series on game networking. Not a lot they say I can disagree with.

Link: Part I: Client Side of 64 Network DO's and DON'Ts for Game Engine Developers

I think I saw this posted on /r/programming a while ago, it's a good read.

I really wish I'd researched this a bit more before implementing the network logic for my EO client. Most of the ideas in this article (part 1 at least) I've implemented, but I think I could have done it better with more research and design. Especially considering there were a couple major refactors involved to get where I am now.

The way I decided to handle network traffic is as follows:

1. Socket layer handler receives messages and dispatches to thread pool
2. Thread pool function picks appropriate handler function from callback hash table (keys are Family/Action pairs)
3. Handler function processes EO packet into meaningful data values and calls event callback function
4. Client defines callback function that uses processed data however it wants.

Steps 1 and 2 are more Socket/system API level, while 3 and 4 are implemented in an API object.

The biggest thing I'm missing is an event processing thread (outside the implicit loop from receiving on a socket), as suggested in #2. Instead, every message is dispatched to a thread pool which causes problems when multiple messages are processed simultaneously.

This isn't necessarily bad since the thread pool is always separate from the network processing thread - however, I think if I were to do it again I would have a separate event thread instead of using the thread pool in order to process messages.

---
class EOSERV {
Programmer | Oldbie
Open source EO Client: https://github.com/ethanmoffat/EndlessClient
};

You probably don't want to thread your "packet handlers", in fact, you should aim to completely minimize the amount of logic in them. Like is emphasized heavily on this site, you want to split up threads in logical ways that minimize interaction between them. Packet handlers, at least the way they are in EOSERV, all touch random, different parts of the game state in a way that would be impossible to change directly in to a thread-pool based system.

In the case of something like EOSERV, you'd keep packet handlers as short functions which post queues to logical game structures (e.g. send a command to the current map that player X has attacked). This is what they talk about with splitting things by "nodes". Each map could theoretically execute all its actions in isolation from every other map (but communicating safely with some system to handle transferring characters between them).