Overview on networking a 2D Shooter

Started by
0 comments, last by hplus0603 10 years, 9 months ago

Hey everyone, im looking for some help as im starting to network the crap out of my single player 2d shooter into the world of multiplayer games. What im using and what's already done:

C++, DirectX9's sprite interface for rendering, Visual studio 2010 express as an IDE, and Enet library for networking purposes. Here is a gameplay video which im providing for relevance purposes only.

[media]http:

[/media]

My questions are:

Assuming they work completely asynchronously, how would a normal game cycle look on server and client. Let's think clientside for a moment:

- commence:

- get into the real-time network event loop

- receive ( or not ) an accept-message from server to move the player one pixel by the X axis.

- update ( or not ) local player position client-side

- render

- check for player input. In case of a "W" button pressed send a packet to the server informing it that we want to move one pixel by some axis.

- repeat

Any corrections/additions or a complete overhaul possibly to that list would be appreciated.

Now let's look at the server side. We don't need rendering here so the server life cycle would look like:

- commence

- get into the real time network event loop

- receive messages asking for permission to move players

- prepare new updated game state

- broadcast the game state to everyone

- repeat

Is this how it should work?

How many packets such game (vide: the yt movie above) should send per second and what should each packet contain? a complete structure describing the game state?

What kind of server should i buy to host my game server. Estimated minimum processor tickrate, memory capacity?

And most importantly how do i organize the bloody mess caused by the constant, asynchronous flow of packets, packet losses and bandwidth rate?

Advertisement

The FAQ for this forum has a pretty good collection of links.

In brief, though, you will typically run the physical simulation at a fixed time step, and have the size of that time step be the same on server and client. Note that this means graphics is asynchronous from physical simulation.

The physical simulation is then expressed as "input for step number (N+1) + state at step number (N) => state at step number (N+1)." Clients send input to the server "ahead of time." Server forwards inputs from all clients for each step back to clients. Clients can then simulate "behind time" and either display old, correct, data, or forward extrapolate "guess" for rendering purposes.

There are some alternatives, such as sending object position/velocity rather than inputs; these snapshots will then serve instead of "simulation" for the display. The main draw-back is that you'll either have a lot more network bandwidth usage, or you won't be as precise as with distributing inputs.

enum Bool { True, False, FileNotFound };

This topic is closed to new replies.

Advertisement