Author: {wf}shadowspawn <shadowspawn_at_shadowspawn_dot_net>     Reply to Message
Date: 2/24/2004 4:20:17 AM
Subject: A study: client side vs server side physics

It's rumored (got to say rumor) that doom3 is going client/server like q3, as opposed to what they fed us for 2 years as being 100% server-side.

During this period of wondering exactly how the hell ID was going to pull a magic bunny out of their hat, especially after playing d3 at Quakecon and watching 4 comps lag up to the 'host' server, and having plenty of experience with synch clients from university days, i kinda was always wondering if those that made doom actually played it in school.

And had someone trip over a cord.

Or had the experience of having a host on a coaxial cable that had been repeatedly crushed in a door jam.

Or stepped on by girls in stiletto heals at a party.

I figured none at ID ever actually played the games in Real Life client/server environments, only controlled ones. You HAVE to separate the client from the server. There is no method to achieve a decent end result that you cannot separate them, unless someone created some ESP code (esp.gif).

Anyone who ever worked with servers in any IT field knows what the deal is, its not rocket science. Well maybe it is, but it's something that is sorta inbred with admins: you got to separate the clients from the server; you have clients running code that means server is running less code. If it's a java app, a cgi app, anything that's a fact of life; less load on server more clients that can connect. Clients are important, but not as much as a server when it comes to a centralized point.

Well I got to thinking: there is these 'shrapnel' snippets of code from quake devils in the wf source. The fact it's from quake devils means nothing, since everyone that ever contributed code to wf wound up putting a tute on the site, so whatever, it's wf code. But there was this code that threw gibs as well as chunks of debris everywhere.

See the way things work, ok for anyone who's played any Q3 engine game (yes, any) with debris on a server that had a limited connection or processor there is always a little bit of a lag when debris is spawned. Not only does the function spawning debris cause a huge hit on the server, but the fact that all these new chunks of debris have to be coordinated and handshake, talked about between server and client, well it takes up tons of memory for both the server and the client. The server needs to keep track of it in order to tell the client it's there and what to do and how to display it.

That got me to thinking; there was this code that Jalisco wrote to help me debug the nodes for the ai. Because of the method it passed over these client-side interpretations of nodes, i could use that for even more stuff. All i needed to do was duplicate the server-side collision detection on a client and poof it'd work.

Wasn't that easy.

Client runs 10x more frames per sec then the server, so collision detection on velocity of objects is more precise. Q3map2 does some really whacked things with meshes. Its definitely nothing that anyone ever encountered, the only answers to any questions are inside the code itself and will not be found on any google search.

See my theory is that the majority of clients are going to have more horsepower to run what's in their current view the server to run (send, translate, calculate, allocate) the same entities. So what's important that all clients get? Not debris, not non-collision detection entities, not ones that are discarded.

So i decided to shift allot of entity effects from the server to the client. As a bonus, when the client does something that the server needs to interpret, the entity data of these entities is sent to the server as well as the player state; so the server can just produce an end result and all the other clients interpret it. The method literally becomes a whacked p2p and non-synchronous client/game relationship.

Now this opens a whole new can of whoop-ass on performance, but it also creates a serious flaw if a client drops out. Which is fine, there is different code for ents that make a difference for everyone else (in my eyes) and those that don't.

All clients might interpret it differently.

After Quakecon i pictured a group of computers in a row, allot of people playing. Yes everyone might see a crate, a box in a different position then the person next to him or her; but the bounding boxes would be lerped to what the last client who affected it did. If the client dropped out before the last instruction, it would just end its lerp to where it was last. (Lerp is the difference between where it was and where it's going, and everything that it entails).

Anyway, here's a divx under a meg.

http://www.shadowspawn.net/temp/client_side_debris2.avi

Its not much visually because it was a test on the actual client/server communication code and collision detection, but I spent the last 2 hours of a sleepless night cause of a thunderstorm making the end result effects the same on a slow client running 30fps as a client running 200fps.

Just kinda cool. Now it uses the blaster effect, but now a whole new door opened up for client-side physics for effects that will not degrade server performance, and can be client-side tweakable for those that have less then a 1.3ghz machine.

Its all numbers, not necessarily rendering speeds, but rendering speeds do count so hence the tweak variables. It's also mostly irrelevant for most people to read this far, but the end result is about 90% less load on the server for client-side debris effects, and the artistic freedom of adding in as many effects as any client can handle without the fear of bogging down the server with too much crap.

  


_