Need Advice/Insight on Client/Server game design..
Author
I''m currently working on a game project which will hopefully support at least eight players. The game world will be relatively small and populated with few objects. The game is planned to be a 3D space shooter with a focus on dog-fight style combat (using OpenGL/SDL/C++). At most there will be a handfull of asteriods, several players ships, and various projectile fire to keep track of. My intention was to allow the server to do a majority of the game logistics, etc. and make the clients very thin (mostly user interface).
What I would like to know is if this approach is a good one? What are the alternatives? And what complications should I be aware of before hand?
P.S. If anyone has any good articles on Client/Server design comparisions please toss them my way.
you really need to put all collision detection (well most of it) on the server...ESPECIALLY the weapons collisions with player ships. if you make this client side then i guarantee they will find a way to cheat. well there is always a way to cheat even if it is server side but is alot easier to cheat with the more things you put on the client.
what exactly are you planning on making....i might be interested in helping out.
"A soldier is a part of the 1% of the population that keeps the other 99% free" - Lt. Colonel Todd, 1/38th Infantry, Ft. Benning, GA
what exactly are you planning on making....i might be interested in helping out.
"A soldier is a part of the 1% of the population that keeps the other 99% free" - Lt. Colonel Todd, 1/38th Infantry, Ft. Benning, GA
I too need some advice in this area at the moment.
More about where to split the game logic, data and resposibilities when moving from the single-computer design to the client/server model.
I''ve found this paper so far, which looks quite good:
http://www.infospheres.caltech.edu/papers/danger/danger.html
More about where to split the game logic, data and resposibilities when moving from the single-computer design to the client/server model.
I''ve found this paper so far, which looks quite good:
http://www.infospheres.caltech.edu/papers/danger/danger.html
Author
The the quick and easy of it was explained above. But to get an idea the game will be a clone similar to Atari's 1993 Arcade classic Space Lords or 4Play/Scatologic's 2002 Jaguar game Battle Sphere.
What I am really concerned with, as far as the client/server aspects go, are ease of implementation, smoothness of game play, and flexability to change. I recently came across this FlipCode article and the last two paragraphs made me start to wonder about load balancing and what game logistics should be handled client side, and which server side. And after the fact how the two should interact...
so I've been Googling the web for info and articles that compare various design frameworks, but haven't found anything too indepth that does so.
[edited by - Xorcist on February 20, 2004 2:33:57 PM]
What I am really concerned with, as far as the client/server aspects go, are ease of implementation, smoothness of game play, and flexability to change. I recently came across this FlipCode article and the last two paragraphs made me start to wonder about load balancing and what game logistics should be handled client side, and which server side. And after the fact how the two should interact...
so I've been Googling the web for info and articles that compare various design frameworks, but haven't found anything too indepth that does so.
[edited by - Xorcist on February 20, 2004 2:33:57 PM]
If you want to avoid cheating, you should think of your game as happening on the servers. The clients have two responsibilities:
1) provide input from the user to the game, going on on the servers
2) display output from the servers, indicating to the user how the game is going, on the servers
There are all kinds of things you can do with extrapolation, latency hiding, prediction, re-simulation and whatnot to hide the fact that there''s probably 400 milliseconds between the server and the player, but that''s the basic gist of it.
1) provide input from the user to the game, going on on the servers
2) display output from the servers, indicating to the user how the game is going, on the servers
There are all kinds of things you can do with extrapolation, latency hiding, prediction, re-simulation and whatnot to hide the fact that there''s probably 400 milliseconds between the server and the player, but that''s the basic gist of it.
I know it''s not exactly what you were looking for, but here is an article on the network architecture of Unreal:
------------------------------------------------
Helping five ounce birds carry one pound
coconuts....... one Swallow at a time.
------------------------------------------------
Helping five ounce birds carry one pound
coconuts....... one Swallow at a time.
Author
Actually the section on player prediction was extremely helpful. If anyone has any other articles like this, or knows of any good books that cover this type of client/server setup, please let me know. I have but only a short time to finish researching and referencing before I push the concept into production. I just want to make sure I''m well informed before I do so.
P.S. Thanks
P.S. Thanks
Muppi here, just got my password at home so i cant login 
ive never done a network game before, but i would put all game code on the server, and only leave the drawing to the clients. maybe if your even really extreme, if you press forward, send it to the server, who stores it, sends it back, and lets you repaint ^^
ive never done a network game before, but i would put all game code on the server, and only leave the drawing to the clients. maybe if your even really extreme, if you press forward, send it to the server, who stores it, sends it back, and lets you repaint ^^
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement