• Advertisement

Archived

This topic is now archived and is closed to further replies.

running the client/server on the same computer

This topic is 5131 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''ve read that a lot of high quality game engines have a client, and server system. there is a client running per player, and one server for the game. with single player, there is a client and a server on the same computer. luckily, I decided to go for a heavily OOP style game core, so at this point it wouldn''t be too terribly hard to convert to this client/server system. the problem I have with it is the fact that many things involving game updates would be run twice, once for the client, once for the server. collision detection is the big one I''m worried about. assuming it takes 15 ms to render, and 4 ms to run a game update, that is potentially 4 ms completely wasted, as it will be run twice on the same computer. I guess you could get away with only doing collision for the player for clients, but I imagine there would still be a LOT of things ending up where they shouldn''t between packets my question is how do you make as little single/multi mode specific code as possible, without doing too much twice?

Share this post


Link to post
Share on other sites
Advertisement
Guest Anonymous Poster
well there are many ways to solve this problem

ill tell you how im doing it on my game, not to complicated.

basically what the client tells the server are the players input, IE left,right, and jump(its only a side scroller). so on the server i just keep a state of what keys the player is holding down, etc. the server tells the client where all the players are. server does all the game mechanics, client does all the drawing.

in my game state update, i tell the client x,y,dx,dy and a state for how each player is facing, running, ticky takc stuff like that. x,y are obvious, the dx,dy are for client side prediction. now im not going to end up doing prediction on this incarnation, but someday i will.

its not fool proof, its not perfect, but it will work.

Share this post


Link to post
Share on other sites
i understand this much, but you will need to have the client do more than be a dumb terminal, because you don't get packets often enough. this means you have to do collision detection twice, once to make sure the client doesn't do anything stupid between packets, and for the server, because it has the definitive game state.

edit: forgot to say, basically my question is how to eliminate this redundancy, either with single player games, or when a network game is being non-dedicated servered, and the client is running on the same computer as the network server.

[edited by - billybob on February 7, 2004 2:16:42 AM]

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
well you asked how to reduce the redundancy and then ignore what i say and that you want to do everythign twice? server does most of the work, thats just how it works. having a fat client, and a fat server is where happy horse doodie comes from, and having a fat client alone... well thats just making it easy for a cheater. so if you want to get practical experience id suggest not doing that.

clients dont need to do all the game mechanics, its called client side prediction. they make a best guess where the player would be, but by no means do you have to do everythign twice. quake sure doesnt do everything twice. thats why you get clipping on clients, the clients dont register collisions.

maybe your game is different, i dont know, no one knows but you. (helps if you give bkg info) you may need the client to be less thin than fat, but try to avoid it if you can, you will end up hating yourself in the end.

afa not enough packets, you cant make TCP/IP games work well without a good connect. if you are doing it on a lan (or on the same box), well then you can have all the packets you would ever want.

quake buffers input by 50ms or so to work out some of the inconsistencies, you might consider soemthing like this.

Share this post


Link to post
Share on other sites
Maybe I didn''t make it clear, I am making the client and server both fat, this is done. all I want is to reduce the things done twice when and ONLY when the client and server are both running on the same computer. I realize things are going to happen twice when there is an internet connection involved, but this is fine with me.

Share this post


Link to post
Share on other sites
The only real way to elimintate that is to have a fat client, and have the sever do nothing but pass messages between different clients. The client will do everything and the server just makes sure everyone knows where they are.

You''ll run into cheating in no time if you do that.

What AP is saying, is the client doesn''t move at all, the client doesn''t do anything except draw and pass messages to the server. The server updates where the client is, so the player cannot do anything stupid.

Share this post


Link to post
Share on other sites
so what you guys are saying is that when there is a client and a server running on the same computer, there is no good solution to remove the redundancy? Two instances of the bsp/octree/(your space partitioning here)? Two instances of every game object? Do collision detection twice? Physics twice? Just to make it clear one more time, I KNOW this will happen when there is a network connection between the client and server, I just want to eliminate it when there isn't.

it just seems like this is one of those problems there is a really clever solution to that I'm missing.

[edited by - billybob on February 7, 2004 3:06:06 AM]

Share this post


Link to post
Share on other sites
The only way I can see around it is to add special case code all over the place.


if (listen_server)
whatever;
else if (dedicated_server)
whatever;
else if (client)
whatever;


That''s basically how Unreal does it. At least that''s what it exposes through its scripting language. It''s not pretty, although it makes sense within their architexture.

Another option is to make your game peer to peer, if the type of game lends itself to that.

Share this post


Link to post
Share on other sites
yeah man, it kind of brakes your OOP bubble, but it''s the simplest way to do it. Unless you want to derive specific client entities for that matter (one set for dedicated servers, doing nothing, one set for client and server on same machine, doing very little, one set on pure clients machine, doing predictions and lag compensation).

Share this post


Link to post
Share on other sites
Theres no need to not use OO.

// Global
server * networkServer = NULL;

// Initialization
if( gameType == singlePlayer )
networkServer = new singlePlayerServer();
else if( gameType == multiPlayerAndImNotServer )
networkServer = new externalServer();
else if( gameType == multiPlayerImServer )
networkServer = new imServer();


// All updates etc just do
networkServer->Update(...);

That way the code will always use update, and depending on the type of game it''ll send a packet, or update itself, or...

Share this post


Link to post
Share on other sites
These last 3 posts are what I was thinking of, but I really wanted to avoid special case code. oh well

Share this post


Link to post
Share on other sites

  • Advertisement