Jump to content

  • Log In with Google      Sign In   
  • Create Account

Game logic split between client & server - geometry


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
11 replies to this topic

#1 metamorph   Members   -  Reputation: 107

Like
0Likes
Like

Posted 21 April 2014 - 04:59 AM

Hi all,

 

I don't have any experience in gaming industry and I would like to do some gamin development for fun (initially on server side).

 

However, being the noob I am, it is not quite clear to me what is generally considered a good approach in the industry in terms of the split of game logic between server and client regarding the geometry.

 

For example, let's assume use case from Counter Strike: flash bang is thrown. Target position of FB is X, and its impact radius is R. Then, the question is, who does calculation which players will be impacted: client(s) or server? Calculation would be "for every player's location(which is represented as point in geometry) within radius R of impact point, if there exists straight line (i.e. is visible) between player point and impact point, then apply flashbang effect" etc.

 

To me it seems that for every map, server side has to keep some kind of representation of map geometry (without graphics part) and player location in order to at least prevent cheats, and also to smooth out gameplay i.e. decide and enforce total event order across all clients (i.e. decide which player got the actual headshot first in case they click around the same time etc).

 

Thanks in advance for any input.

 

cheers!

 



Sponsor:

#2 Alundra   Members   -  Reputation: 925

Like
1Likes
Like

Posted 21 April 2014 - 05:15 AM

You have to share some code on the client side and the server side.

You have to keep in mind all gameplay stuff has to be done on the server side.

When a gameplay state is updated you have to send a message to all client who is connected about the change.

You have to take care of the bandwidth, don't send information who is not needed and use timer for some state of transform.

About the flashbang it could be one message with ID FLASHBANG_LAUNCHED who just add the flashbang on server and send the ID on client.

Using this ID who is called NetworkID you can update object from server to client, Raknet has a replication system who handle all that.

You will have to handle the reconnection of client if you need to keep the game in state, for counter-strike state of player is not stored.

In a DOTA game, when you have a reconnection the player keep his position on the list and has kills/deaths stored.



#3 AgentC   Members   -  Reputation: 1413

Like
1Likes
Like

Posted 21 April 2014 - 05:29 AM

A typical approach would be that you have the collision/physics representation of the level geometry also on the server, which may consist of simple shapes like boxes, convex hulls, or simplified triangle meshes. In Unity terms, you would have all the Collider components of the level in memory, but not the Renderers. That way you can run the authoritative physics simulation and perform raycasts for hit or line-of-sight checks on the server.


Every time you add a boolean member variable, God kills a kitten. Every time you create a Manager class, God kills a kitten. Every time you create a Singleton...

Urho3D (engine)  Hessian (C64 game project)


#4 metamorph   Members   -  Reputation: 107

Like
0Likes
Like

Posted 21 April 2014 - 06:12 AM

Thanks on quick reply guys!

 

A typical approach would be that you have the collision/physics representation of the level geometry also on the server, 

 

 

I checked Unity documentation but was not able to find low level technical API. Unity seems to me  very client/graphics centric, without clear server side API.

 

Are there any open source or commercial libraries you would recommend to start with? I am looking for game-centric API similar to this one:  http://tsusiatsoftware.net/jts/javadoc/index.html, but with support for 3D and ideally with built in game abstractions (i.e. calculate bullet trajectory etc)

 

thanks!

 

edit: it does not have to be Java library, any language is fine.


Edited by metamorph, 21 April 2014 - 06:17 AM.


#5 ferrous   Members   -  Reputation: 2146

Like
1Likes
Like

Posted 21 April 2014 - 12:10 PM

What kind of library are you looking for?  If you're looking just for a network library, try RakNet?  It's what Unity uses under the hood.

 

Unity is easier to get set up as client/peer, but it's not that hard to make it client/server.  Though I haven't looked into how much work it would be to make it do a standalone server with no rendering.

 

My game logic split is basically:

 Players send inputs to server  (I pressed fire and I am trying to move forward)

 Server computes game logic and sends results/events to players (player X is at position XYZ, facing north, spawn a rocket at time T, etc)

 

Now, that works okay in a low lag environment, in a high lag environment, it's better to simulate the results of the input on the client, and then interpolate/fudge things to sync up with what actually happened on the server. 

 

And in an RTS, things are usually done differently.



#6 metamorph   Members   -  Reputation: 107

Like
0Likes
Like

Posted 21 April 2014 - 02:53 PM

What kind of library are you looking for?

 

Some kind of library/framework/product which offers API & implementation of common 3D geometry algos.

 

 Server computes game logic and sends results/events to players (player X is at position XYZ, facing north, spawn a rocket at time T, etc)

 

How to compute logic in your example is what I'm looking for (i.e. if trajectory of my bullet is line L, compute if head of any enemy is intersecting with that line, and similar to other situations, such as non-streaight line ammo in unreal tournaments Flak Cannon etc).

 

Since I ain't expert in geometry, don't want to spend time writing that first. =)

 

edit: the java library i posted earlier has almost the needed functionality except it is in 2D and has no abstractions for gaming.


Edited by metamorph, 21 April 2014 - 02:55 PM.


#7 ferrous   Members   -  Reputation: 2146

Like
1Likes
Like

Posted 21 April 2014 - 03:02 PM

So you basically want a math/physics library?  Try bullet?  The server in a client-server game is pretty much running the game itself.  Sure it's not rendering, but it's pretty much doing everything else, and then some, so, what you really need is a game engine with networking components.



#8 Norman Barrows   Crossbones+   -  Reputation: 2308

Like
1Likes
Like

Posted 21 April 2014 - 03:25 PM

really, you want to minimize packet size. so you need to have as much code and data one each end of the pipe as needed to do so. this assumes that packet size, and not transmission time is your bottleneck.  but give the average ping time for a poor internet connection, odds are, you bottleneck will be transmission time. in that case, lock step syncing pretty much goes out the door as a real time viable alternative, and you have to resort to inaccurate "prediction methods" uses in MMOs and other online games.

 

first step would probably be to do  a little research and find out how MMOs, arena games, etc  split the duties between client and server.  they've been out for a while, surely there's info available.   me personally, i'm still waiting for ping times under 250ms (IE more like 5-10 ms) so i can do a lockstep accurate internet based hard core simulator. i know, dream on...  

 

"Put a Cray on every user's desk, and i'll build you a REAL game!"  <g>

 

last time i did multi-user, it was semi-peerless, with any PC connected acting as "server". since it was semi-peerless, all clients and servers had the same code, but ran in either client or server mode. having identical code and data structures on both end of the pipe made it possible to minimize packet size. a good thing too since the game was totally non-deterministic, and therefore has to transmit combat results, etc, not just moves and input. since the title was non-deterministic, prediction methods were not an option - and would have been unacceptable due to the accuracy required by the simulation - IE no being denied a kill due to inaccurate prediction methods.

 

check into how MMOs and other online types games are built. you obviously have an interest. start with a google like "MMO game design". odds are it will lead you to all kinds of cool places! <g>.

 

and remember -  _LAG_ is the true enemy, when it come to multi-player!

 

combine lack of lag with a cool game, and you have a better mousetrap. let the world know, and they WILL beat a path to your door!

 

(been there done that, more than once! <g>        well - not multi-player - but i have done the cool game better mousetrap thing a couple times...)


Edited by Norman Barrows, 21 April 2014 - 03:38 PM.

Norm Barrows

Rockland Software Productions

"Building PC games since 1989"

rocklandsoftware.net

 

PLAY CAVEMAN NOW!

http://rocklandsoftware.net/beta.php

 

 


#9 metamorph   Members   -  Reputation: 107

Like
0Likes
Like

Posted 21 April 2014 - 03:47 PM

Ok, thank you all. I think I understand little bit better how things work (bullet seems to be good starting point).

 

Thanks for tolerating my noobness. =)



#10 ferrous   Members   -  Reputation: 2146

Like
0Likes
Like

Posted 21 April 2014 - 04:05 PM


a good thing too since the game was totally non-deterministic, and therefore has to transmit combat results, etc, not just moves and input. since the title was non-deterministic, prediction methods were not an option - and would have been unacceptable due to the accuracy required by the simulation - IE no being denied a kill due to inaccurate prediction methods.

 

So this is a slight derail, but metamorph seems to have gotten a lot of good info, and might also find it useful.  Would you mind expanding on what you were doing that was non-deterministic?  



#11 AgentC   Members   -  Reputation: 1413

Like
0Likes
Like

Posted 21 April 2014 - 04:16 PM

I checked Unity documentation but was not able to find low level technical API. Unity seems to me  very client/graphics centric, without clear server side API.

 

I don't necessarily recommend Unity for that kind of job, I just used the terminology in case you would be familiar with it. That said, Unity can run as a network server in a non-rendering mode, which they call "batchmode". Two typical choices with Unity would be to use the built-in networking, which uses RakNet behind the scenes, but doesn't give very good control into the messages being sent, or integrate a 3rd party networking library such as Lidgren, and build all the game-specific messaging yourself.


Every time you add a boolean member variable, God kills a kitten. Every time you create a Manager class, God kills a kitten. Every time you create a Singleton...

Urho3D (engine)  Hessian (C64 game project)


#12 Norman Barrows   Crossbones+   -  Reputation: 2308

Like
0Likes
Like

Posted 21 April 2014 - 06:28 PM

 


a good thing too since the game was totally non-deterministic, and therefore has to transmit combat results, etc, not just moves and input. since the title was non-deterministic, prediction methods were not an option - and would have been unacceptable due to the accuracy required by the simulation - IE no being denied a kill due to inaccurate prediction methods.

 

So this is a slight derail, but metamorph seems to have gotten a lot of good info, and might also find it useful.  Would you mind expanding on what you were doing that was non-deterministic?  

 

 

 

the whole game was made as random as possible as a single player game first. then co-op multi-player was added.  since the random number generators on each pc were seed  with a value derived from the time the game was launched on that pc (down to the millisecond), you couldn't just say "target x fires" and then rely on the same results from all "dice rolls"  on all pc's to take care of the rest. likewise, since you couldn't know what random number a given node would generate next, it was pretty much impossible to predict changes. as a  result, all non-deterministic stuff (IE dice rolls) were handled by the server, and the results passed to the client for application to the clients copy of the simulation. IE projectile "i" has exploded and done x points of damage to target y. I was able to get the steady state pack size down to just 34 bytes, and the worst case was about 250? bytes. the game ran in lock step synchronization, with a proprietary protocol so robust you could disconnect the phone line / cable / etc, plug it back in, and the game would keep right on going.

 

by contrast, the typical approach is to seed all pseudo-random number generators with the same value, and make sure that each node executes the same flow control code path and therefore the same calls to the random function. as a result, you only need to track and transmit  actions (input), not results (dice rolls). also, since future random events on remote nodes can be pre-determined (since the server's dice will return the same result, given the same seed and same number of calls), that leaves only changes in player input (i was going straight, now i suddenly side step left) as possible mis-predictions when lag times get long.

 

the down side to non-deterministic is that if each node is seeded with the same value each time you play, you get the same exact game each time you play it the same way. to avoid this, have the server generate a "random" seed value based on server launch time, etc, then send that to all clients to seed their random number generators, and then start the game. this way you get different results each play through, even with identical play. after lag, predictability is probably the next worst thing. a random seed shared between nodes can help avoid this - while keeping things deterministic to aid in lag prediction.


Norm Barrows

Rockland Software Productions

"Building PC games since 1989"

rocklandsoftware.net

 

PLAY CAVEMAN NOW!

http://rocklandsoftware.net/beta.php

 

 





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS