|Engine Module Type String||Network|
|Module Type Usage||Single Type|
Network Modules enable the Drag[en]gine to communicate with another game on a remote system. Network Modules are a particular kind of modules since they have two interfaces to satisfy instead of only one. All other modules interact on one side with the Drag[en]gine and have to match the interface there and on the other side they interact with hardware where they are free to organize themselves in the best way. Network Modules though have to respect a network protocol to be able to communicate with other Network Modules another user is using. Network modules are Single Type modules since only one can drive network communication at the same time. This module is one of those modules most important for the end user and server maintainers. The right choice is important to get the best performance. Depending on the network game type different approaches deliver better performance. Networks gaming nowadays is still a big headache since a vast amount of different network connections exist from plain old modems up to hard wired connections. Furthermore many users suffer from restrictions of their internet providers or their hardware calling for specialized Network Modules to allow them to play. You can and have to use for different games different Network modules. Launchers usually do not download Network modules on their own since games do not request them. Pick from the list of available Network modules the one which matches best your game. Games tend to specify a certain requirement a Network Module has to provide and the game launchers do their best to help you pick the right module.
As mentioned there exists a lot of different network connections a player can be using to play a game. This makes it very difficult for game developers to produce an optimal engine working well on all possible setups. With the Drag[en]gine you can pick what works best with your particular network situation as well as the kind of connectivity your games require. Choosing the right Network module is an important task to play online games smoothly and requires some testing. Each Network module is written for a certain number of players as well as certain network connection types. Whereas with other module types finding one good module works for all games this is not the case for Network modules. Games though of similar characteristics can be used with the same Network module. For example all kinds of first person shooters with player counts up to 32 players work well with one Network module whereas MMO type games require a different Network module to run as good as possible.
How many players?
The main property of a Network module is the number of players it supports. In general there are four kinds of games that can be classified. The first class is the 1-1 class known well from sports games. With only 2 players the communication is based on a Peer-To-Peer scenario with high bi-directional throughput. The second class has players up to 64. Such games are typically shooters based on a Client-Server principle with community servers. The third class are MO games ( Multiplayer Online ) with a player count of many tousands. MO games are based too on a Client-Server concept with proprietary servers using zoning/clustering. The last class are MMO games ( Massive Multiplayer Online ) which have a tremendous player count with Client-Server, proprietary servers and zoneing/clustering. The last two classes look similar but the resources required by them differ. Often you can get away with a Network module for low player counts covering the first two classes and one for the other two.
How fast is my connection?
Although broadband is common amongst hard core gamers modems and dial up networking is still very common. Usually connection speeds vary a lot from one player to the other and often game engines are only optimized for high connection speeds kicking all other players in the butt. Network modules can be written for fast or low connections allowing you to optimize the game for your connection speed. Check the lag monitors that many games come equipped with to verify the performance of your chosen Network Module. Getting a good connection speed is not only important for you but also all other players.
NAT problems? Restricted ports? Other ISP problems?
Internet providers are a funky breed and more than not they suddenly restrict ports or place stupid caps on your connections for no obvious reasons. Many players are unable to play online since game engines in general are not flexible enough to cope with all these situations. If you have problems of this kind look for a Network module written to solve them. NAT is also a common problem if people intent to host games. Certain Network modules have the ability to punch through NATs.
Launchers will provide you with a default choice for a Network module. Usually this is a reasonable choice based on the requirements by the game. Often though you have to test other Network modules since games vary in network demand.
Generalizing network programming is a problem since there exist various types of games with very different demands on the underlaying network. 1-1 games have a completely different structure than an MMO. To cope with this situation as well as possible a simple system has been chosen for the Drag[en]gine. The system is based around three main objects: deConnection, deNetworkState and deServer.
The deConnection object provides a connection between two players, a player and a server or two servers. In general this is a pipe between two parties allowing you to send messages as well as linking states. Messages are send by default unreliable. This means that a message is tried to be send as fast as possible but without the guarantee to be delivered successfully. Reliable messages on the other hand are delivered to the other end for sure and in the right order as they have been send. Unreliable messages are send with a maximum delay. Often it is better to delay a message a little bit to collect enough messages to send them as a batch instead of individual data packages to maximize throughput. The maximum delay indicates how long in milliseconds a message can be delayed before being send. Important messages usually have a small value down to 0 whereas unimportant messages like chat messages can have delays in the seconds range. Reliable messages do not have delays and are send as soon as possible since they occur far less often than unreliable messages. Messages are designed to be used for infrequent game events. For frequent updates use network states.
The deNetworkState is the main work horse for a game. They are designed for frequent updates of game objects. A network state bundles a bunch of network values representing properties of a game object like for example the position or orientation. These network states can be linked between the two connection partners. Whenever the state changes the opposite host is notified and the changes propagated to the script. The Network module is responsible to track the changes and to minimize the network traffic to keep them in sync. Dead Reckoning is provided by the Network module to relief the game scripts of doing dead reckoning themselves. Various functions can be used to define the dead reckoning behavior.
Finally there is the deServer object which simply represents a connection endpoint on a host. Other players can connect to deServer object to obtain deConnection objects. More than one deServer can be used if required. In general the network module is responsible to update all connections, network states and server objects.
One important thing is the network protocol. Since different Network modules are required to communicate with each other a unique protocol is required. The protocol is defined by the engine and has to be used by all Network modules. Theoretically a Network module could define extensions to this protocol or its own protocol but this results quickly in a big mess therefore stick to the given protocol. It is anyways a rather simple protocol scalable enough to cope with various game scenarios.
Another important thing is cheat prevention and security. The game scripts are responsible to ensure that no cheating is done on the game level. The Network module has to provide security and cheat protection on the network layer as well as possible. Communication between peers has to be protected to avoid others tampering with the data send. Also invalid data send has to be reported immediately to the game script.
To get you started on Network modules have a look at the deBaseNetworkModule module.
Note: The network system is still work in progress and will change until the first release. Missing are currently dead reckoning and encryption. The rest is defined and not changing anymore.