Archived

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

skillfreak

engine design

Recommended Posts

skillfreak    160
With a client/server design - think more in terms of local code ( although the end result is the same ). I''m going to present a few thoughts (looking for commentary): client/server > when the client is running through a map he handles all his collisions? no. that is server side. --? > when the client fires his rocket launcher the server handles the rest?.. and sends packets ( netted enviro ) back to client of position changes ( wastefull? ) or of rocket detenation? > how about half-life server side mods, where you fire your shotgun and suddenly you have trace fire from your pellets. where is our client told these are the new rules and code setup? seems that in this same setup, your shotgun could also fire a rocket. despite my other post, i still just don''t seem to find the connection between the client and server as simple as hoped. this might clear some stuff up. thanks - andy

Share this post


Link to post
Share on other sites
superpig    1825
I would say that the client handles all phyics and movement specific to that *player* - everything else, every ''unowned'' entity, is handled by the server. The player''s position is calculated by the client, collisions etc are done, and then the minimum amount of information - position/rotation - is sent to the server.

When the player fires their RPG, that rocket becomes ''unowned'' and handled by the server (though it may have a ''fired by'' tag on it to work out who to attribute the kill to).

Superpig
- saving pigs from untimely fates, and when he''s not doing that, runs The Binary Refinery.
Enginuity1 | Enginuity2 | Enginuity3

Share this post


Link to post
Share on other sites
ApochPiQ    23000
The general relationship is that the server acts as a central point where all the clients can get information on other players, gunshots, etc. without having to necessarily keep track of all the other players themselves. However, you need to muddle the relationship to deter cheating.

In general, strip as much as you possibly can out of the client and put it on the server. A good rule of thumb as well: validate as much as you can in independent locations. If a player reports that he just walked through a space that contains a solid wall, validate his movement on the server, and if possible, on other clients as well. If the majority of the validations fail (i.e. the majority says he can''t walk through walls) then boot the player for cheating, or whatever. Independent validation is a very powerful (and very expensive) anti-cheating method, so be sure you streamline the network traffic, and make some judgment calls about what should/shouldn''t be validated in this way.

It is safest to keep as much as you can out of the hands of the client, so that hacked clients can''t do sneaky cheatful things. If you follow those principles you should be able to come up with a secure and efficient setup.

Share this post


Link to post
Share on other sites
skillfreak    160
quote:
how about half-life server side mods, where you fire your shotgun and suddenly you have trace fire from your pellets. where is our client told these are the new rules and code setup? seems that in this same setup, your shotgun could also fire a rocket.


ie. i join a server and the shotgun fires trace rounds like the 9mm_AR. My hl client didn't look like it downloaded anything on connect. How was this done?

[edited by - skillfreak on July 6, 2003 3:17:03 PM]

Share this post


Link to post
Share on other sites
shurcool    439
like ApochPiQ said, it's best to keep as much sensitive calculations done on the server as possible. that way a hacked client can't just tell the server that "i killed this guy," instead he'll say "i shot in this direction" and the server will decide who gets killed.

just keep this in mind - when creating a client/server system, design it so that it'd work well for over-internet games. that way, local games will work naturally, as well as lan games.

one way of doing this (one i prefer, i guess, and also the way half-life networking does this, iirc) is to have the client send the server input. so the client doesn't check whether he can move forward or not, he just sends the server a packet saying "i just pressed the following buttons: +forward, -left; moved mouse by (+6, +17)" and the server will then send a packet back saying "ok then, ur new position will be at (123x, 634y, 10z), ur direction is 67 degrees north-east, etc." this will work well on a local game, but waiting around 0.100+ seconds to see ur player move with a ping as low as 50 ms is unacceptable. that's where local-side prediction comes in (there's also server-side prediction for other players; it gets kind of complicated).

i'll try to find the article that covers this in detail.

one last thing... take a look at this article series, it will answer your question very well.

edit: here it is - Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization.

edit2: there's a forum here called Multiplayer and Network Programming, and this post belongs in there.

---
shurcool
wwdev


[edited by - shurcooL on July 6, 2003 4:06:00 PM]

Share this post


Link to post
Share on other sites
Brewdles    122
quote:
Original post by skillfreak
quote:
how about half-life server side mods, where you fire your shotgun and suddenly you have trace fire from your pellets. where is our client told these are the new rules and code setup? seems that in this same setup, your shotgun could also fire a rocket.


ie. i join a server and the shotgun fires trace rounds like the 9mm_AR. My hl client didn''t look like it downloaded anything on connect. How was this done?



Your client didn''t download anything at all. It doesn''t need to.
Same as Quake. When you fire, your machine sends a message saying "I want to shoot" then the server fires your bullet. The server keeps track of absolutely everything. Gamecode does not run on the client machine, only on the server - the client really only draws stuff where it''s told in network games. This stops the client from using a modified gamecode to cheat.

Share this post


Link to post
Share on other sites
shurcool    439
wow, totally ignored, like always. next time i won't spend 15 mins trying to help out 'beginners'. ;x

edit: fine, i won't be so mean. i was just pissed at the moment.

---
shurcool
wwdev


[edited by - shurcool on July 8, 2003 1:55:23 PM]

Share this post


Link to post
Share on other sites
Guest Anonymous Poster   
Guest Anonymous Poster
shurcool''s link does tell everything you need to know.

Share this post


Link to post
Share on other sites
unferth    127
RE: the way Half-Life handles bullets.

As far as I know, Half-Life uses "events", or pre-scripted sequences for most of the communication between client/server for visual effects. A client sends a keypress to the server, which then sends back a structure telling the client to play event #X at location (x, y, z). So the server only has to tell the client a very short message instead of lengthy information about individual particles and lighting, etc. Half-Life even goes one step further, at least in DM and TFC. When you fire a weapon, the client catches this, and displays the bullets shooting without confirmation from the server. So the bullet pattern the client sees may not exactly match what the server records, but it is close enough that players will generally not notice. This has the effect of lessening the appearance of "lag" to the client. Movement is another thing that is also predicted. Usually the client gets it right, based off the player's previous direction and speed, but the server has the final say (as I'm sure you've noticed in a very laggy game before).

I just noticed shurcool's post of those articles, but I don't want to waste all the typing I just did.

edit: oh wow, I didn't notice how old this post was

[edited by - unferth on September 4, 2003 2:36:12 AM]

Share this post


Link to post
Share on other sites