Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (106)
games submitted by our members
Games in WIP (533)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2
  ignore  |  Print  
  [SGS] DarkShooter  (Read 7169 times)
0 Members and 1 Guest are viewing this topic.
Offline dsellars

Junior Member




Need to write more games


« Posted 2006-03-29 11:56:50 »

First off, I don't know how far I will get with this Smiley  but I was thinking about a small home project to have a play with the SGS as it the the newest, shineyest thing around Smiley

I've read through the tutorials and think I pretty much 'get it'  howerver I do have a few questions in my mind.  I can see how you would do a MUD like game, (cos that is in the examle Wink ) or an EVE like game where the server is effectivly responding to user input in the form of commands.  To some extent WOW too but I'm not sure on collision with terrain (see below).

What I'm not sure about is how you would do a more action orientated game (with dynamics and colission server side).  I think this may be related to the physics question post sorry if I'm crossing topics.

With this in mind I have decided to try a little 2d shooter game (hence DarkShooter Smiley ), very similar I supose to something Kev wrote a few years ago (Astroprime) for reference for those of you that remember it.  I don't intend it to to be a 'game' more a learning experience.

What I basically have in mind is to fly a little space ship around and death match with other players/enemy ai's.  There will be a few seperate 'Sectors' that can be jumped too.  not much more than this.  Collision isn't intended to be very fancy, just circle to circle.

So my questions are:

  • how to regualary update position/perform collision on the server, as the examples I have seen so far just react to event from the client
  • how to regualary send info to the clients
  • how to get input (key presses) from the clients
  • how to keep the clients relativly in sync (to cut down on jumping)

From looking at the javadoc, my initial naive guesses about an approach are:

I think PDTimer is my friend to do regular updated server side (but I'm not sure how to use it, I think there may be a commented out example in the Hack code). 

Basic architecture is to have a 'Sector' GLO that contains a load of references to 'Actor' GLO's (space ships, asteroids, bullets etc).  Player and AI's will control the 'Actors' which will manage state (position, velocity, damage) etc

So to perform the dynamics (I hesitate to say physics) and collision on the server I would set up a regular timer to update these calculations. Basically for each sector the timer wakes up, gets all the Actors, update position perform collision, send any results to the players in that sector.  I think this would have to be a GET.

To send info the the players another timer that looks at all the positions of actors in a sector (PEEK?) and sends pos and velocity to the clients. (so the clients can interpolate).

I'm really not sure on sending info from the client tot eh server, I can't see that every keay press is viable but lets assume that for now.

keeping clients in sync.  hmm. may be if the positiont hat comes in from the server is different to that the client thinks it should be the client 'tends' towards the position it should be so it dosn't jump. (I think this has been discussed here before, probably by Kev).

So as I said this is pretty naive but is just initial thoughts from reading the docs and skimming the code examples.  Any comments on this approach to using SGS?

Sorry it ended up so long.

Cheers
Dan.

Offline mudman

Junior Member




Here we go again...


« Reply #1 - Posted 2006-03-29 14:28:45 »

Maybe a nice first step would be to separate what you can expect SGS to solve for you from things it can't possibly solve.
Synchronizing between server and client is not an SGS problem, all it adds to solve that problem is a protocol-agnostic and optionally reliable communication channel. There are multiple possible solutions to this problem like dead-reckoning etc. But to not bloat the thread it would probably be wise to concentrate on SGS related problems?
Offline mudman

Junior Member




Here we go again...


« Reply #2 - Posted 2006-03-29 14:52:01 »

I believe you're right that subdivision into different sectors would be optimal.
This subdivision could be conceptual or geographical in terms of the game world.
Each host could then assume "ownership" of one or more sectors.
Inter-sector get() operations should be kept to a bare minimum but can't be completely avoided as objects might move between sectors or otherwise influence objects in other sectors.
Old-skool sectors with "portals" are trivial: Only players and their attached objects (inventory, spell affects etc.) move between sectors. Seamless sectors are probably a must for any serious MMORPG. Obviously inter-section information flow management is critical here.

You're talking about jumping between sectors so let's assume we're talking old-skool sectors - this is probably a good place to start as [postulate] every old-skool problem must also be solved in seamless subdivision [/postulate], so why not solve those problems first?


 
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline endolf

JGO Coder


Medals: 7


Current project release date: sometime in 3003


« Reply #3 - Posted 2006-03-29 15:00:26 »

Hi

The problem with SGS is that you can't assume ownership on one server. The whole backend knows about every sector.

Endolf

Offline mudman

Junior Member




Here we go again...


« Reply #4 - Posted 2006-03-29 15:05:10 »

You're right, you can't enforce ownership, this is why I put ownership in quotes.
But a clever design could respect it as much as possible.

A paradigm-shift is needed to utilize SGS properly - patterns/concepts like game-loop etc. must be translated / rethought to create something that fits into the new framework.
Offline dsellars

Junior Member




Need to write more games


« Reply #5 - Posted 2006-03-29 15:34:23 »

Firstly thanks for discussing Smiley

I was thinking of 'Sector' as more a game concept as in teh area of space round this planet/sun/spacestation that can be jumped to through some sort of hyper-space.  I gon't care what server it is on or if it is split over many.  I don't think, from what (limited) amount I know about SGS, I need to.

I must admit that my post was  abit of a brain dump so not well organised.

What I wanted to try and discuss what SGS gives us all of  *this* how would I use it for this type of project.  My main question i suppose at this point is "Am I supposed to use PDTimer to set up reoccuring tasks from dynamics to collision to client updates?" and "How do I use it? Smiley"

The other thing about deadreconing etc were mor thing I *know* I'm going to need to look at.  I also assume that these scanario's have been thought about byt eh SGS designers.  I wondered if there was a reccomended way of approaching this type of game with SGS as a back end.   

Hope this make sense Im just trying to clarify my thoughts and hopefully promtoe some discussion around actually using SGS.

Regards,
Dan.

Offline dsellars

Junior Member




Need to write more games


« Reply #6 - Posted 2006-03-29 15:36:15 »

Quote
A paradigm-shift is needed to utilize SGS properly - patterns/concepts like game-loop etc. must be translated / rethought to create something that fits into the new framework.

kinda what I was trying to discuss with this, for now hyperthetical, DarkShooter project I want to try and write time permitting.

Offline Jeff

JGO Coder




Got any cats?


« Reply #7 - Posted 2006-03-29 21:28:31 »

First off, I don't know how far I will get with this Smiley  but I was thinking about a small home project to have a play with the SGS as it the the newest, shineyest thing around Smiley

I've read through the tutorials and think I pretty much 'get it'  howerver I do have a few questions in my mind.  I can see how you would do a MUD like game, (cos that is in the examle Wink ) or an EVE like game where the server is effectivly responding to user input in the form of commands.  To some extent WOW too but I'm not sure on collision with terrain (see below).

What I'm not sure about is how you would do a more action orientated game (with dynamics and colission server side).  I think this may be related to the physics question post sorry if I'm crossing topics.

Collision is a seperable problem from general physics.  BattleTrolls does server side collision cheat detection (I know, we'll get it otu to you soon.)  It does this using a WalkMesh, which is a simplified form of the geometry used just for blocking detection.  You cn think of it as a blocking map which, instead of a grid, is made up of free form tri-angles.  (Thsi is how NWN works and we just lifted their data for our demo, with their approval.)

In general, for responsiveness reasons, my sugegstion on any action game is to do local collision/physics and server side sanity checking for cheating.  This allows you to decouple the server side response from your game response and get better local responsiveness.


Quote
With this in mind I have decided to try a little 2d shooter game (hence DarkShooter Smiley ), very similar I supose to something Kev wrote a few years ago (Astroprime) for reference for those of you that remember it.  I don't intend it to to be a 'game' more a learning experience.

Soudns cool, one fo my gednaken experiments whiel designing the system was space-wars.  Be aware though that top-dpown 2D is actually harder  in many ways then first-person.  First person games have a much mor limtied view of the world at any given time and thus can "cheat" in ways that top down games can't.

In general, for top down internet games, momentuum is a life saver...


Quote
  • how to regualary update position/perform collision on the server, as the examples I have seen so far just react to event from the client
Use the PDTImer utility class.  My initial recomendation is to give each object, or at least scalable groups of obejcts, their own callback.  This will allow those callbacks to be spread about the back-end ona multi-server stack.

Keep in mind that in order to have parallel processing, you need to avoid common locks.  If every update needs to GET the board, then they cannot operate in parallel.  In space wars what I did was just keep the list of objects  in the board but let each object keep its own position.  Update logic looked like this:

(1) GET my ship and Calculate new location
(2) PEEK (not GET, PEEK does not lock the obejct) the board for the obejct list
(3) Iterator over the GLOreferences in the list and...
     (3a) PEEK each referenced object and compare with my new position for collision.
     (3b) IF Collision then GET other object and do explode() on both it and me

Note that there is a certain in-built indteerminancy here.  PEEK gets you the last comitted state, the object may in fact have moved from that location by the time you check.  This is similar to the point sampling problem in movign and collision detection on a frame byframe basis ona  client and the same solutions apply (eg dont move to much in any one update, calculate and check "in-between" positions, etc)


[li]how to regualary send info to the clients[/li]

Send the info as a result of the timed calculations above.

[li]how to get input (key presses) from the clients[/li]

I wouldn try to communciate key-presses, that kind fo low level info is very latency sensative. Instead, Id do it the same way 3D vehicle sims do and calculate currentr potision and movement vector  locally and to the serve along with  a time stamp.


[li]how to keep the clients relativly in sync (to cut down on jumping)[/li]
[/list]

Thsi really gets inot the same latency hiding tricks as a first person vehicle sim.  As i mentioend above, momentuum is your friend, if it takes time for the ship to respond to chnages in motion then it gives you a lot mroe 'slop" to hide things in.  Just like a 3D sim, you are going to do prediction based on last received position and momentuum and then correct at the next update.

Quote
I think PDTimer is my friend to do regular updated server side (but I'm not sure how to use it, I think there may be a commented out example in the Hack code). 

Shoudl be fairly straightfoward,a re there no Javadocs for it?  If not we'll have to create some and get that up...

Also there shoudl be soruce code for PDTimer in theSDK, so you coudl do a javadoc yourself  on it...

Basic architecture is to have a 'Sector' GLO that contains a load of references to 'Actor' GLO's (space ships, asteroids, bullets etc).  Player and AI's will control the 'Actors' which will manage state (position, velocity, damage) etc

Quote
So to perform the dynamics (I hesitate to say physics) and collision on the server I would set up a regular timer to
update these calculations. Basically for each sector the timer wakes up, gets all the Actors, update position perform collision, send any results to the players in that sector.  I think this would have to be a GET.

See above,  GETTing all the actors would work fine ona  single CPU, single slice system, but it will not scale.


Quote
To send info the the players another timer that looks at all the positions of actors in a sector (PEEK?) and sends pos and velocity to the clients. (so the clients can interpolate).

I believe you coudl do this as part of your update.  When you finish your update, send the new position and mvoement vector.  (and a time stamp)

Quote
I'm really not sure on sending info from the client tot eh server, I can't see that every keay press is viable but lets assume that for now.

See  my suggestion above.


Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline mudman

Junior Member




Here we go again...


« Reply #8 - Posted 2006-03-29 23:10:59 »

Quote
So to perform the dynamics (I hesitate to say physics) and collision on the server I would set up a regular timer to
update these calculations. Basically for each sector the timer wakes up, gets all the Actors, update position perform collision, send any results to the players in that sector.  I think this would have to be a GET.

See above,  GETTing all the actors would work fine ona  single CPU, single slice system, but it will not scale.

Well if you're doing an update of the objects I don't see any way around a GET ?
Offline dsellars

Junior Member




Need to write more games


« Reply #9 - Posted 2006-03-29 23:19:20 »

Excellent Jeff thanks this is just what I was looking for Smiley now all I need is time Smiley

With regard to PDTimer it is part documented.  I'll have a look itneh API fro soem more details just liftign from javadoc that is there:

GLOReference<PDTimerEvent>    addTimerEvent(SimTask task, SimTask.ACCESS_TYPE access, long delay, boolean repeat, GLOReference target, java.lang.String methodName, java.lang.Object[] parameters)

I assume that SimTask is the task you have grabbed when you set it up.

ACCESS_TYPE I assume is in the api (I'm guessign somthignlike GET, PEEK etc) but wat willthis be for?

delay time between updates I assume in millisec, what controls the time in the background the 1.5 high res timer?

repeat?  I assume ture to loop false to just be woken up once.

target: the GLOReference to wake ip on a timer event 

method name: the method to call on target when woken up?

parameters?  a list of arguments to pass to the method?


void    removeTimerEvent(SimTask task, GLOReference<PDTimerEvent> eventRef)
cancel the timer?
           
void    start(SimTask task, long heartbeat)
start the timer running?
           
 void    timerEvent(long eventID)
? not sure on this one.           

Also why do you create the PDTimer with a SimTask and then have to specify SimTask in most of the other methods?

Again thanks for answering I'll read through the post more to make sure i don't miss anything.

Cheers,
Dan.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline dsellars

Junior Member




Need to write more games


« Reply #10 - Posted 2006-03-29 23:22:11 »

Quote
So to perform the dynamics (I hesitate to say physics) and collision on the server I would set up a regular timer to
update these calculations. Basically for each sector the timer wakes up, gets all the Actors, update position perform collision, send any results to the players in that sector.  I think this would have to be a GET.

See above,  GETTing all the actors would work fine ona  single CPU, single slice system, but it will not scale.

Well if you're doing an update of the objects I don't see any way around a GET ?


I think you will have  doeen a GET on the object you are dealing with which you will update, you are just PEEK ing on the rest to read their position/bounds/whatever info you need.  I think.

EDIT :

Although if you do find you need to modify somthing you could always get it then I suppose
Offline Jeff

JGO Coder




Got any cats?


« Reply #11 - Posted 2006-03-30 00:49:09 »

Excellent Jeff thanks this is just what I was looking for Smiley now all I need is time Smiley

With regard to PDTimer it is part documented.  I'll have a look itneh API fro soem more details just liftign from javadoc that is there:

GLOReference<PDTimerEvent>    addTimerEvent(SimTask task, SimTask.ACCESS_TYPE access, long delay, boolean repeat, GLOReference target, java.lang.String methodName, java.lang.Object[] parameters)

I assume that SimTask is the task you have grabbed when you set it up.

SimTask is your current SImTask at the tiem you make the call (that which SimTask.getCurrent() returns.)

Quote
ACCESS_TYPE I assume is in the api (I'm guessign somthignlike GET, PEEK etc) but wat willthis be for?

There is an ENUM for these.  This is what klind of access the object the timer calls back will be called with. 
Think of it this way, the timer hodlsa  GLOReference to your object to be called, this is what it does with that reference  in order to call your object.

Quote
delay time between updates I assume in millisec, what controls the time in the background the 1.5 high res timer?
Actually I think its in seconds.  At the moment thats hardwired in PDT thpugh we've talked about setting it fro ma property.

The actual heartbeat timer in the current stack is using System.currentTime Millis().

When start is called, a numerb fo seconds for a tick is passed in.  This is the resolutionof PDTimer, so a 1 would be 1 second per tick, a 5 woudl be 5 seconds per tick.

You can alsways re-write the PDTImer as I believe source is included to use finer reolsution BUT you are going to risk putting much greater load on the system as a result.

Quote
repeat?  I assume ture to loop false to just be woken up once.

yup

Quote
target: the GLOReference to wake ip on a timer event 

method name: the method to call on target when woken up?

Yes

Quote
parameters?  a list of arguments to pass to the method?

yep

Quote
void    removeTimerEvent(SimTask task, GLOReference<PDTimerEvent> eventRef)
cancel the timer?
           

Exactly

Quote
void    start(SimTask task, long heartbeat)
start the timer running?
         

yes, your app calls this in its Boot method.

Quote

 void    timerEvent(long eventID)
? not sure on this one.           

Thats actually the callback from the heartbeat manager in the stack.  Its not a PDTimer user method.

Quote
Also why do you create the PDTimer with a SimTask and then have to specify SimTask in most of the other methods?

because the lifetime of a SimTask object is only for the life of that task in which it is fetched.  This is documented in the server coder's guide.


Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline hplus

Senior Newbie





« Reply #12 - Posted 2006-03-30 02:36:11 »

Quote
In general, for responsiveness reasons, my sugegstion on any action game is to do local collision/physics and server side sanity checking for cheating.  This allows you to decouple the server side response from your game response and get better local responsiveness.

It also allows for client cheating. If you want cheat-less physics-based games, you have to run physics on the server side. If you want non-physics-based games (like EverQuest or WOW), you can make them cheat-less without full server-side physics.

The non-determinism in simulation means that a lockstep communications model (as used in some physical MMOs like City of Heroes and in RTS-es like Warcraft III and Age of Empires) won't actually be possible. This means that you can't really fit a large world on a narrowband channel. What is the current thought about this limitation?

When it comes to scalability, keeping the entire collision mesh for the entire world on every physical server would be un-wise. You want objects that collide with a certain part of the world to be run on servers that keep that part of the world resident. Is there enough automatic object migration to make this happen? Can you talk about how objects will move between physical server processes, and what determines when this happens?
Offline Jeff

JGO Coder




Got any cats?


« Reply #13 - Posted 2006-03-30 07:07:13 »

Quote
So to perform the dynamics (I hesitate to say physics) and collision on the server I would set up a regular timer to
update these calculations. Basically for each sector the timer wakes up, gets all the Actors, update position perform collision, send any results to the players in that sector.  I think this would have to be a GET.

See above,  GETTing all the actors would work fine ona  single CPU, single slice system, but it will not scale.

Well if you're doing an update of the objects I don't see any way around a GET ?

The trick is not all object have to be updated by the same task.  By splitting it up you get parallelism.

Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline Jeff

JGO Coder




Got any cats?


« Reply #14 - Posted 2006-03-30 07:16:27 »

Quote
In general, for responsiveness reasons, my sugegstion on any action game is to do local collision/physics and server side sanity checking for cheating.  This allows you to decouple the server side response from your game response and get better local responsiveness.

It also allows for client cheating.


No it certainly does not. try re-reading the paragraph.particularly the part that says "sanity checking for cheating."

This is what we do in JNWN.  Client side collision test. Server side cheat detect.  Both test the WalkMesh, its just that the server is doing it after the fact.

Quote
The non-determinism in simulation means that a lockstep communications model (as used in some physical MMOs like City of Heroes and in RTS-es like Warcraft III and Age of Empires)

Um Ive played a LOT of COH.  I do not believe it is in any way lockstep based on the behavior Ive seen which includes reliably fast local responses to motion physics  and ocassional roll-backs on position when latency getts too extreme.  With CoV Cryptic brought in  Havok but it is STRICTLY local and purely for effects such as the shattering bank vault door.

If you have a hard reference to the contrary please present it.

As for RTS's, see Kev Glass's lock step approach discussed ina nother thread.  very clever and decouples you from latency spikes.

Quote
won't actually be possible. This means that you can't really fit a large world on a narrowband channel. What is the current thought about this limitation?

Please explain the limitation you think you see in greater detail and Ill be happy to address it.

Quote
When it comes to scalability, keeping the entire collision mesh for the entire world on every physical server would be un-wise.

The SGS does notkeep data in slice server memory.  It floats it through an extremely fast dsitributed database on the back end.

Having said that, one giant walk mesh would be a bad idea anyway and we dont do that.  In JNWN we store the walk mesh data on a per-tile basis.

Quote
You want objects that collide with a certain part of the world to be run on servers that keep that part of the world resident.

No server keeps any part of the world resident.  All the servers can access the entire data set,

This division of data by virtual space into memory of physical servers is exactly what causes all the worst properties of MMO design today.



Quote
Is there enough automatic object migration to make this happen? Can you talk about how objects will move between physical server processes, and what determines when this happens?

The ObjectStore is a very very fast distributed in-memory database.  The current full scale implementation is based on a Sun technology called HADB.  Tasks pull objects from the object store as needed and puts them back at the end of a task.  (An SGS backend has the agreeable property of running in a serious machine room with a nice wide back-end pipe between systems and full control over its useage.)

We also can move users between slices if there is too much contention between slices for common resources.
Much more detail Im afraid gets into Sun proprietrary stuff.

Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline mudman

Junior Member




Here we go again...


« Reply #15 - Posted 2006-03-30 10:52:14 »

Quote
So to perform the dynamics (I hesitate to say physics) and collision on the server I would set up a regular timer to
update these calculations. Basically for each sector the timer wakes up, gets all the Actors, update position perform collision, send any results to the players in that sector.  I think this would have to be a GET.

See above,  GETTing all the actors would work fine ona  single CPU, single slice system, but it will not scale.

Well if you're doing an update of the objects I don't see any way around a GET ?


The trick is not all object have to be updated by the same task.  By splitting it up you get parallelism.


Obviously you would only GET the objects that are updated - with sectors this would be objects "owned" by the sector to be updated (for object types that rarely change state an initial PEEk as you suggested before would probably be optimal) + objects from other sectors whose state is updated by interaction with objects from this sector.
Offline dsellars

Junior Member




Need to write more games


« Reply #16 - Posted 2006-03-30 11:24:39 »

Again Jeff  thanks,

Quote
When start is called, a numerb fo seconds for a tick is passed in.  This is the resolutionof PDTimer, so a 1 would be 1 second per tick, a 5 woudl be 5 seconds per tick.

So ont he server model would 1 second per tick be considered sufficient?  I would be expecting to the run the client side at about 60 ticks per sec, would this not lead to lots of difficutlies syncing up the server and client?
 
Offline mudman

Junior Member




Here we go again...


« Reply #17 - Posted 2006-03-30 13:27:19 »

Again Jeff  thanks,

Quote
When start is called, a numerb fo seconds for a tick is passed in.  This is the resolutionof PDTimer, so a 1 would be 1 second per tick, a 5 woudl be 5 seconds per tick.

So ont he server model would 1 second per tick be considered sufficient?  I would be expecting to the run the client side at about 60 ticks per sec, would this not lead to lots of difficutlies syncing up the server and client?
 

1 Hz is pretty good for a poker game...

On the other hand, 60 Hz is not needed.
In a graphical realtime MMORPG 5-20 Hz is probably more realistic - fluid movements on the screen should be handled by interpolation.
Offline Mr EEK

Senior Newbie





« Reply #18 - Posted 2006-03-30 13:37:17 »

It ought to be possible to get more than 1Hz by starting multiple timers that call the same GLO method, but staggered.  I dunno how you can ensure they are staggered evenly through each second, though.

Since the SGS guys are planning to allow sub-second resolution on PDTimer the problem does away anyway  Cheesy
Offline endolf

JGO Coder


Medals: 7


Current project release date: sometime in 3003


« Reply #19 - Posted 2006-03-30 14:01:01 »

Hi

I'm working on a 3d space based game and I'm working on 4 ticks per second. When the client rotates the ship thier client view rotates and then there is some 'thurster lag'. The client send 4 times a second it's average thrust vector for the last 1/4 of a second, and the server does some real simple checking on wether that ship type can do that quick a change, then it lets everyone know about it. At this point, the client is then allowed to move in that direction, along with everyone else. This will give the impression of sliding around the screen a bit, but hey, this is space, we don't have a road to grip on to, so some slide is allowed, and there is no real physics in this Smiley.

I don't know how well it will work, but it's home code, I can play Smiley

Endolf

Offline dsellars

Junior Member




Need to write more games


« Reply #20 - Posted 2006-03-30 14:03:54 »

I'd kinda got the impression from Jeff that a 1 sec resolution on the server was considered sufficient.  To me it seems a bit low for the dynamics model.  Ok Smiley maybe 60 Hz client side is a bit too high.  But it still wants to be a lot higher than supported by PDTimer as is.  You still end up with two simulations running at different rates.

Maybe I'm being  abit slow on the uptake or expecting more than is available.  I suspect I need to find some time to cut some code and then come back with some more questions. Wink
Offline dsellars

Junior Member




Need to write more games


« Reply #21 - Posted 2006-03-30 14:07:26 »

@Endolf

so basically in your game your not really running a duplicate simulation on the server, just checking that what the client says is reasobable and letting the clients control the dynamics?

Dan
Offline endolf

JGO Coder


Medals: 7


Current project release date: sometime in 3003


« Reply #22 - Posted 2006-03-30 14:21:03 »

Hi

Not quite.

The client sends it's average thrust vector to the server, the server send this to everyone, and they all interpolate that client to that location. The rotation of small objects will have no bearing on things, and larger objects will have much slower allowed rotation times (think small fighter, large wings, roughly spherical in general terms, v.s. large, long carrier type objects). This means that the client *feels* responsive, even though it's actually not doing anything different. by the time the client recieves an 'ok' to where it wants to go, at most 1/2 a second has gone by, but they are already looking that way, the thruster lag resolves itself and the current position is marked as the start point, and the then multiplied with the thrust vector, and the next position calculated. Then it's interpolated and the client moved. During this move, we are on to the next game cycle, and they can rotate and change the thrust vector again. Thruster lag takes effect and 1/4-1/2 a second later they start to move off in the new direction.

In Astroprime for example, a ship could rotate with no thrusters active and they would carry on the previous direction, traveling backwards or sideways. It's only when the thrusters kick in that things need to change.

Like I said, I don't *know* how it will play, it may be awful, it may make you seasick, but until I try, I don't know Smiley

Endolf

Offline hplus

Senior Newbie





« Reply #23 - Posted 2006-03-30 18:21:30 »

Quote
If you have a hard reference to the contrary please present it.

I've talked to Cryptic; I know some people who work there. They send user input from the client to the server (at least they did a year back), and simulate on the server. This amounts to lock-step per object. I don't think they use lock-step for the entire world. Other simulations actually use lock-step for the entire world (like www.there.com).

When you say that "no server keeps data resident," that's the conceptual model, right? In reality, the object store would not perform very well unless it could keep committed data resident on the "most probable" node for the next get, and only migrate the ownership of the state if the next get comes from somewhere else. Thus, locality in successive get-s is important for good performance. Even if you have a large, expensive NUMA machine, local memory is faster than ownership transfer.

Now, when it comes to walk meshes, well-performing collission detection data takes a little while to demarshal when you load it. You certainly don't want to do that each time you want to run another task on an object that references the mesh. Thus, assuming the objects stay alive between tasks, as long as they don't have to migrate, then that's what I meant by "keeping objects resident".

Now, consider the case where you're simulating something big -- the Earth, say. Clearly, you can't fit all the walk meshes of the Earth into RAM on a single node. Similarly, if you have a lot of entities that are distributed over this simulation, if you use stochastic distribution of entities across nodes, you will get a worst-case reference pattern: each node needs to load walk meshes (and other world date) for large parts of the simulated Earth. There is no way that such a distribution would perform well. Thus, proper load balancing MUST take locality of reference into account, such that things in New York City tend towards one node, and things in Kuala Lumpur tend towards another node, because the amount of duplicated or transferred objects between nodes goes down a lot, which means performance goes up a lot.

However, I see no way for objects to hint what localities of reference may matter. I also see no posts claiming that you can derive these localities automatically in a way that's actually sufficient to solve the problem -- but perhaps you can. You don't need to go into details about how it works, but if this problem is "solved" it'd be interesting to hear that it is; if it's not solved, then that'd be important to know, too.
Offline Jeff

JGO Coder




Got any cats?


« Reply #24 - Posted 2006-03-30 21:38:30 »

Quote
If you have a hard reference to the contrary please present it.

I've talked to Cryptic; I know some people who work there. They send user input from the client to the server (at least they did a year back), and simulate on the server. This amounts to lock-step per object. I don't think they use lock-step for the entire world. Other simulations actually use lock-step for the entire world (like www.there.com).

As it happens were talking to some cryptic people and I'll ask them too.

However I STRIONGLY doubt thats the entire model.  From what I see playing it, it CANT be because you would see control lags.  A true locks tep woudl also make everyones machine runa s slow as the worst one in the simulation and I don't see that effect, either.  A true lock-step woudl never need to roll-back the client's idea of character position but we DO see that happen in periods of mreo intense lag.

My suspicion is that what is **really** happening is that they are doing a local simulation for cosmetic reasons, but making key decisions such as combat and collision cheat detection based on the server's model of the world.  basically the same as JNWN.  The only real difference, and its a minro one,. is the level of data transfer.  (COntroller state v. object sstate).  That is more or less orthogonal to the issue of lock step v. open loop.

Quote
When you say that "no server keeps data resident," that's the conceptual model, right? In reality, the object store would not perform very well unless it could keep committed data resident on the "most probable" node for the next get, and only migrate the ownership of the state if the next get comes from somewhere else.

This gets into implementation things that I both cant discuss and are free to change under the hood.  Suffice it to say our initila POC got sub milisecond response times without such local caching.

Quote
Now, when it comes to walk meshes, well-performing collission detection data takes a little while to demarshal when you load it. You certainly don't want to do that each time you want to run another task on an object that references the mesh.

Deserialization times have proved to not be a performance raod-block.  That sub-ms time INCLUDES deserialization.

Quote
Now, consider the case where you're simulating something big -- the Earth, say. Clearly, you can't fit all the walk meshes of the Earth into RAM on a single node.

As already explained, its not all on a  single node.  Your starting from false premesis and thus drawing false conclusions.

Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline Jeff

JGO Coder




Got any cats?


« Reply #25 - Posted 2006-03-30 22:30:59 »

Again Jeff  thanks,

Quote
When start is called, a numerb fo seconds for a tick is passed in.  This is the resolutionof PDTimer, so a 1 would be 1 second per tick, a 5 woudl be 5 seconds per tick.

So ont he server model would 1 second per tick be considered sufficient?  I would be expecting to the run the client side at about 60 ticks per sec, would this not lead to lots of difficutlies syncing up the server and client?
 

Um  can I say this?

no no no bad bad bad.

The last thing you want to be doing is driving your server by "frame rate" as if it was a client and tryiong to synch at that level.  FWIK That was the disasterous mistake Sony made with SWG when they initially develoepd it and anyone who tried to play it can tell you what the results where like.

Such architectures typically come from game programmers trying to programs ervers the same way they knwo how to program clients and its fundementally wrong.  A well done server shoudl be as event/transaction driven as possible.  Now sometiem heartbeats are inevitable but if your designing you entire game around trying to make heart-beats match rendering frames your defintiely starting  on the wrong foot.

Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline Alan_W

JGO Knight


Medals: 8
Projects: 3


Java tames rock!


« Reply #26 - Posted 2006-03-30 22:54:11 »

A bit of thought about the bandwidth requirements for frame-rate server interaction will soon put things in perspective.

Assuming a dial-up connection, thats around 3k bytes/second maximum client->server & quite possibly less. (Remember 56k dial up is actually asymmetric, you don't get 56k upstream.)   If each game object is (say) 50 bytes, then you can transmit around 60 objects per second.  If you ran at frame rate, this would only allow 1 game object per client  Cry

So ... we have to reduce the update rate dramatically.  For SharpShooter Arena, I sent everything at 5Hz and used interpolation on the client to smooth things out.  I also reduced the amount of data per object to the bare minimum (position, velocity, object ID - less than 20 bytes).  Each client could only transmit 2 objects - 1 for the player, another for the player bullet.

Thus I was sending around 20*2*5 = 200bytes/second for each player.  If all the players were in close proximity, then you would need to be able to receive N-players * 200bytes/second.  So for 10 players, we are receiving about 2k/second.  With a server based architecture, this asymmetry in data transfer rates works with the modems higher downstream rate of up to 56kbps, so we would manage more then 10 players in one place.  However we also need to allow for additional server generated data for Non-player characters.  And so on.

To optimise this further, we need to implement variable data rates depending on how fast the entity is moving.  (I didn't manage this).  This is getting close to a transactional system, where you only update an entity when you have to.

So from my very limited experience, I totally agree with Jeff.  This does result in some game compromises, but when viewed in the light of the above issues, it becomes obvious very quickly that it is just tough Smiley

Alan

Time flies like a bird. Fruit flies like a banana.
Offline hplus

Senior Newbie





« Reply #27 - Posted 2006-03-30 23:10:35 »

Such architectures typically come from game programmers trying to programs ervers the same way they knwo how to program clients and its fundementally wrong.  A well done server shoudl be as event/transaction driven as possible.  Now sometiem heartbeats are inevitable but if your designing you entire game around trying to make heart-beats match rendering frames your defintiely starting  on the wrong foot.

Such architectures are also necessary for various distributed simulation systems (such as used in military wargaming, etc). Thus, I think it's fairer to say that running physics on servers makes sense for highly physical games where you want to make authoritative decisions based on physics state, but does not make sense for a typical MMORPG.

Can I read from this that you believe that SGS is not a viable technology for systems that look more like a military simulation, and less like an MMORPG?

Btw, when it comes to Cryptic: please ask them! Last I did, they said that they run physics at 30 fps on the server, and they send only controller inputs from the client. They RLE encode the last X seconds of input into each upstream packet, which will compensate for a fair bit of packet loss. I probably used the word "lockstep" wrong, as it's not an RTS model; instead, let's call it "input communication model" (as opposed to "state communication model"). I would assume that they send baseline state information every once in a while to get a client back in sync if there's been too much packet loss, or the server and client have de-synced; this would account for corrections/warping.

Last: if it takes "sub millisecond" for each get(), how can I simulate hundreds of close interacting objects in a physical simulation with 30 steps a second, per processing node? There's only 30 milliseconds per step, at that rate.

I actually have a specific kind of system in mind when I'm asking these questions -- is there another way of contacting you for more in-depth questions?
Offline dsellars

Junior Member




Need to write more games


« Reply #28 - Posted 2006-03-30 23:59:45 »

1  
2  
3  
Um  can I say this?

no no no bad bad bad.


yup you can and did Smiley

It wasn't quite what I was suggesting though, sorry it came acress that way.   I would never mean to suggest that update packets are sent every frame, that would be silly.

What I *meant* was( which is probably also wrong, so some clarification would be good) that I can't see how the server and the client can hope to be remotely in sync if the server is only updating it's model once per sec.  Actually sending data I was thinking around once per sec.  I guess what I'm thinking of is if  the server side checks on collision, are checking intervals one sec apart then it would be easy to *miss* collisions (I suppose you could sweep).

I guess the use case I am thinking of is: Client reports a hit, sends to server for clarification (or doesn't report damage til the server sends hit but does show fancy *hit* effect), server sim hasn't seen it (cos it's steps are too far apart), says no hit. 

now I'm thinking this still isn't the way I want to be looking at it, but I'm not sure what is.
Offline Jeff

JGO Coder




Got any cats?


« Reply #29 - Posted 2006-03-31 00:06:12 »

Can I read from this that you believe that SGS is not a viable technology for systems that look more like a military simulation, and less like an MMORPG?

Well it depends.  SimNet was highly destributed and basicly client based.  It would certainly work well cooridnating something like that.  Military Sims have the agreeable property that if someone cheats, you take him outside and shoot him.  Something MMORPG makers can't do. 

FLight and tank sim games all to varyign degree follow the SimNet model and should be prefectly implementable in an SGS centric world.
Cosmic Birdie is a good exampel of a game that does fast action.  It does client side physics because the resposne time of a persistant system, even one sucha s ours, woudl be inappropriate for what they are trying to accomplish.

I would definitely say it is not suited to nor intended for scientific simulation.  I had a nice chat with a  fellow from NASA a few GDCs ago.  They
simulate down to the flow of air particles and the ONLY thing that will do what they need is a big hunk of memory surrounded by 100s of directly coupeld processors.

Quote
Btw, when it comes to Cryptic: please ask them! Last I did, they said that they run physics at 30 fps on the server, and they send only controller inputs from the client. They RLE encode the last X seconds of input into each upstream packet, which will compensate for a fair bit of packet loss. I probably used the word "lockstep" wrong, as it's not an RTS model; instead, let's call it "input communication model" (as opposed to "state communication model"). I would assume that they send baseline state information every once in a while to get a client back in sync if there's been too much packet loss, or the server and client have de-synced; this would account for corrections/warping.

Okay that I believe Cool  I suspect if you aked them yould find they are ALSo runing loosely coupeld physics on the client.  The only other way they could get the kind of motion theya re getting (ex a smooth arc in a jump) and not do that was if they were actually sending back paramteric curves to the client and I kind of doubt that.

Frankly if you wanted to do that sort of continuos global physics thing in the SGS you would do exactly what you do today:  You would write a custom process that handled your real-time physics model and then talk to it through the SGS's RawSocketManager.  You would be responsible for scaling that yourself and any persistance you wanted from that.   Realisticly we arent going to be able to give you any better then O(.1) MS access time to data inside of the SGS (which is pretty damn good and good for most things, but this aprticualr problem its probably not fast enough for.)

As I mentioned above though, physics and collision can be decoupled and there are a lot more efficient and less demanding ways to do collision.
If I were creating a physics based game I woudl probably look at doing client-side physics and considering the physics model effectively a "controller" on the objects.  As  long as you know the limist of your physics model detecting unreasonable results isnt that hard and suffices for cheat insurance.


Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Pages: [1] 2
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

pw (24 views)
2014-07-24 01:59:36

Riven (22 views)
2014-07-23 21:16:32

Riven (18 views)
2014-07-23 21:07:15

Riven (21 views)
2014-07-23 20:56:16

ctomni231 (50 views)
2014-07-18 06:55:21

Zero Volt (45 views)
2014-07-17 23:47:54

danieldean (36 views)
2014-07-17 23:41:23

MustardPeter (39 views)
2014-07-16 23:30:00

Cero (54 views)
2014-07-16 00:42:17

Riven (54 views)
2014-07-14 18:02:53
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!