GAME PROGRAMMING RESOURCES

MULTIPLAYER GAMES

In this tutorial we assume you understand this document.

With 3Impact you can develop games that run simultaneously on different computers connected by a Local Area Network (LAN) or by the Internet.

Multiple connected users can see the same simulation from different point of views and interactively influence it with the keyboard, joysticks, etc. They can chat during game action and send/receive any kind of data.

In short, you can develop multiplayer games!

3Impact network system is client/server based. It means that one of the connected computers will work as a central server, while all others will work as clients. Client machines can only exchange data with the sever.

You can run a computer as a server by calling the iNetServerStart() function in your DLL code. On all other connected computers, your DLL code should call iNetClientStart() instead. After that, connected computers can start exchanging data.

BODY SYNCHRONIZATION

Specific functions allow you to synchronize physics simulations running on different connected computers. For example, imagine the interactive ball demo running on the server and all client computers.

By synchronizing the ball body you ensure that any behavior performed by the ball on the server is replicated on all connected clients. All connected users will see the same simulation at the same time.

The simulation, synchronized at regular intervals, will tend to run identically on all computers. It means that only small and infrequent adjustments will be necessary to keep it the same for all users.

The whole simulation, including collision detection, sound effects, game logic and so on, is performed locally on each connected computer.

This approach minimizes the amount of data to share, thus ultimately maximizing the number of simultaneous players.

VARIABLE SYNCHRONIZATION

While body synchronization data can usually be exchanged infrequently, other game specific data may need to be shared often and immediately.

Imagine a scenario in which, on a certain client computer, the user presses the left arrow key. The arrow key state is saved into a float variable named, for example, LeftKeyState (0.0f if not pressed, -1.0f if pressed).

Because a force is applied to the ball while LeftKeyState is -1.0f, we should immediately share LeftKeyState variable among all connected computers, in order to ensure that the ball will have the same force applied and behave the same in all running simulations.

Specific functions allow you to share (synchronize) float variables at any desired frequency.

LOW-LEVEL DATA TRANSFER

Additionally, the engine provides functions to transfer binary data from clients to the server and from the server to each specific client.

You will typically use low-level data transfer functions to implement chat systems, to upload/download files, to share game databases and even to code custom synchronization systems.

SAMPLE CODE

Fully commented source code, showing how to synchronize the default ball demo simulation, can be accessed, modified and compiled as follows. Note that we just needed to add 11 (eleven) function calls to transform the original ball game to a network playable demo!

Open, compile and test the NetBallGame project by following the procedure described in the Quick Start Tutorial for the BallGame project.

The source code is fully commented and examining it is strongly recommended!

Don't forget to refer to Reference document for details on all functions called in the source code!

See the last section of this tutorial for more on running/testing network projects.

NETWORK CHAT SAMPLE CODE

Fully commented source code, implementing a simple multiplayer chat system, active in the foreground, with no need to stop the game simulation, can be accessed, modified and compiled as follows:

Open, compile and test the NetChat project by following the procedure described in the Quick Start Tutorial for the BallGame project.

The source code is fully commented and examining it is strongly recommended!

Don't forget to refer to Reference document for details on all functions called in the source code!

See the last section of this tutorial for more on running/testing network projects.

FILE UPLOAD SAMPLE CODE

Fully commented source code, showing a technique to transfer a file from the server to a client, can be accessed, modified and compiled as follows:

Open, compile and test the NetFileUpload project by following the procedure described in the Quick Start Tutorial for the BallGame project.

The source code is fully commented and examining it is strongly recommended!

Don't forget to refer to Reference document for details on all functions called in the source code!

See the last section of this tutorial for more on running/testing network projects.

MULTIPLAYER GAME SOURCE CODE

The fully commented source code of a simple multiplayer ball-fighting game can be accessed, modified and compiled as follows:

Open, compile and test the NetBallArena project by following the procedure described in the Quick Start Tutorial for the BallGame project.

The source code is fully commented and examining it is strongly recommended!

Don't forget to refer to Reference document for details on all functions called in the source code!

See the last section of this tutorial for more on running/testing network projects.

REMARKS

When developing multiplayer games, the gold rule is minimizing the amount of data that clients and server need to exchange. The less data exchanged the more players connected and better playability.
  • For simple simulations, where bodies rarely collide with other bodies, setting a 1 second frequency for body synchronization (iNetBodySyncCreate() function) and 1/20th second for input data synchronization (iNetFloatSyncCreate() function) should be fine, even for 30+ synched bodies and 16+ players, on a fast Internet connection.
  • For complex simulations, where bodies move fast, collide frequently and are linked together by constraints and springs, a stable implementation will require body synchronizations as frequent as 10 per second, which means fewer synched bodies and players.
  • There are 3 main network connection scenarios to consider: LAN (very fast), fast Internet (i.e. broadband) and dial-up modem. For each scenario you should provide a different game configuration. It's very unlikely that a 16 player game that runs smoothly on a LAN will run fine on a dial-up modem connection too.
  • For each connection scenario, start with a reasonable number of synched bodies. Set 0.5 seconds frequency for all bodysyncs and 0.99 for all floatsyncs. Then increase bodysyncs frequency by 0.1 at a time, stopping right before the simulation gets unstable. In order to ensure a smooth synchronization, the frequency should be identical for all bodysyncs. Finally decrease frequency for those floatsyncs that require immediacy (i.e. movement controls, etc) and increase it for those allowing infrequent updates (i.e. score counters, etc).


    • TESTING NETWORK CODE

    In order to test compiled network DLL code samples, you need at least two connected computers, both with DirectX8.1 or greater installed.

    1. Compile and make a stand-alone executable version of your .dll, as explained here (5.).

    2. Copy the stand-alone demos to all the connected computers.

    3. Launch the demo on a computer and, when asked, choose to run as server (host). Then launch it on all other computers and choose to run as client.

    4. On client machines, you should be able to join the demo session by clicking 'Start Search', selecting it from a (one-item) list and clicking 'Join'.

    5. On a LAN, you don't have to specify any IP address to join a session. On the Internet, you should specify the IP address for the server followed by the port number to use (25857). For example:

    66.189.234.12:25857