Sign in to follow this  

Designing networking into a game

This topic is 4198 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I am working on designing a basic game, however, From what I have been told, multiplayer must be designed from the beginning otherwise it is too hard to try to impliment later on. I have never made a multiplayer game before and I am having problems figuring out how the networking part falls into it. Currently, This is how I see it should fit together: Server: The server side should always be running and if the server and client are the same, we will just handle stuff locally instead of trying to send them over the LAN/Internet. This is where alot of the "stuff" happens and makes sure that all the clients are all in synch with us. The server is the one who is running the AI scripts, Physics portion, and all collision detection based on its clients. This is all based off a queue which we get from the networking or local side of the game. The local side and networking would use the same queue (am I right here?) to ensure everything is processed correctly (in order). Client: This constantly recieves information the server and handles them through *events?* which is translated into actions. These actions are of course viewable by everyone playing the game. The problems that I am encountering with this are as follows. Lets say player A (to make this simple, lets say this is a single player game) moves forward 2 units. Now from my understanding, this is sent into a queue which is then eventually sent to the server (which is located on the same machine). When the server gets this action, it does the checking, updates anything as needed and returns the feedback. Are these steps correct? Is there anything better/more optimal for speed reasons? What about AI, Physics, Collision detection etc? Are those all done on the server side and just the results and such sent to the clients? ie. if there are 4 players (3 of which are bots) their AI is all processed on the server (once per server frame? or once per X number of milliseconds??) and their movements/reactions (shooting, dodging etc) are all sent to the clients correct? Is there anything wrong with my understanding of how the networking should interface with the entire game? I am just trying to get a better understanding in my design before I move on to implimentation. Thanks for everyones help (Thanks for reading my novel)!! ME

Share this post


Link to post
Share on other sites
It all depends on what your game is. Is it an FPS? An RPG? An RTS? A skyscraper firefighting trainer? A licensed high-fantasy shooting-based kart racer with card mechanics?

Each genre makes a different trade-off between validation, response time, simulation complexity, bandwidth, ...

I also suggest going to the Multiplayer and Networking forum and checking out the FAQ, which has some pointers that might be of use to you.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster


There is also a major timing/delay difference between Internet and LAN (especially when you try to have a quick cycle reaction).

If a game is all on the same LAN subnet you can use the BROADCAST mode....

If you have alot of update data and players are far apart you may be able to
filter the events transmitted to only the ones near each player.

Share this post


Link to post
Share on other sites
@hplus0603: I am working on making an RTS. I did not know that the game type directly effects how to do the networking portion. Currently I have the source to RakNet. I will probably be writting wrappers for most of it, but I am not sure how to incorporate it into my state machine and update cycle. I am looking through the multiplayer FAQ now [grin]

thnx


Share this post


Link to post
Share on other sites
At the most basic level, here is how a client/server networked game works:

Server --
The entire game runs on the server. The server receives player inputs from the clients, it maintains the game, and it periodically sends the state of the game to the clients.

Client --
The client gets inputs from the players and sends them to the server. It receives the state of the game from the server and renders it.

Now, this is just a starting point. Network games aren't actually implemented like this because it is too simplistic. There are a lot of things that you must do to improve efficiency, robustness, and playability.

Share this post


Link to post
Share on other sites
I'm not the best at designing UML, but this is my basic layout for my game. The 4 basic Tasks that I have drawn out are, Physics, AI, Keyboard/Mouse Updater, and the Render State (which will tell the Graphics Engine that I have chosen {Ogre 3D} that it is time to render so that it can handle a lot of its internals and handle any state specific rendering/updating). The first two I am guessing will not be needed during a multiplayer game if we are not the server (is this correct?) That state machine will be in some form of inherited classes that will derive a common base class. The In Game State will do any of its updating and send whatever it needs to (i.e. Send unit X to {X, Y} ) which will then be submitted to the Message system which will probably be in a separate thread (and will of course have to be thread safe). This will process all the events that are passed to it as a QUEUE (First in, First out). In the case of a single/local game, it will pass the information to the relevant system (i.e., Physics, Collision Detection, AI {which I am currently thinking of using LUA right now} etc) or it will pass it along through the network to the server, which in turn will send us the response, which will be added to the queue.

Does all this make logical sense for a networked RTS game? I am still designing this before I dive into the code, so any input would be greatly appreciated.




thanks....me

Share this post


Link to post
Share on other sites

This topic is 4198 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this