Representing geography in SGS

[c4scroller]

Hello,

I was wondering if someone from the SGS team could give some advice regarding how a physical game world could be represented within the SGS framework (i.e. in terms of GLOs etc).

I understand the tutorial well, and the idea of having GLOs representing entities (players, NPCs, etc.) but what approach should I take if I want to create, say, a mulptiplayer/RPG-type city with buildings and roads, i.e. one in which there is real space and coordinates etc. Does one try and divide it up into GLOs, or have one big GLO? Obviously I don't want to start out on the wrong foot, and I'm sure my query is a common one. I especially don't want to hard-code the design of the world into the source code, clearly, rather I'd like to have the world created on startup by, for example, parsing an XML file representation (created in a world designer program etc.)

Any suggestions, examples or pointers would be greatly appreciated. Thank you and keep up the good work.

Greg Scott

[Jeff]

Happy to kick some ideas to you.

It realy depends on what you are really doing on your server. In the "swordworld", being a text mud, the world is broken up into "rooms" each of which has a text description.  In a complete text-mud you woudl have the parser recognize statements like "go north" and move you to a new "room".

BattleTrolls is a simple 3D graphic battle-mud.  Its absed on the JNWN soruce base which uses the NWN data set.  NWn describes wordls as a set of areas.  Each area is made up of 1 or more 10x10 tiles of geometry.  Each tile also has a "walkmesh" associated with it which is a simplified geometry used just for blocking detection. 

The full tiles are deployed on the client.  The walk mesh is deployed both on the client and the server.  On the server it is one tile's mesh per GLO.  The tile-map is also deployed on both.  Its also part of a region GLO on the server.

The client builds the visible world from the tiles according to the map.  The server checks movement against the walkmesh.

Really, the first question you have to ask is what you are going to be doign on the server?  The second question then is how ar you going to access the data? Then based on that you divide the data into your GLOs.

In the case of Battle Trolls, all the server needs to know about is collision and location of players, sot he GLOs are designed to support that.

[c4scroller]

On a related note, could someone offer guidance as to a reasonable approach to maintaining consistency between players in a physical/geographical world (such as a small multiplayer game). In particular, does one

* Have a player broadcast information about their whereabouts and movements directly to all other players, bypassing the server or
* Make sure every such thing goes through the server?

Thanks for any help
Greg

Games published by our own members! Check 'em out!

[aldacron]

On a related note, could someone offer guidance as to a reasonable approach to maintaining consistency between players in a physical/geographical world (such as a small multiplayer game). In particular, does one

* Have a player broadcast information about their whereabouts and movements directly to all other players, bypassing the server or
* Make sure every such thing goes through the server?

Everything should go through the server. The server is the final authority when it comes to game rules. Otherwise, you run into possible client cheats.

Generally, each avatar in the game world will have a 'sphere of influence'. Imagine a sphere with the avatar at the center. Any game world object outside of that sphere of influence is not visible to that player. When the player moves, the sphere moves with the avatar. Move packets are sent to the server when one of the movement states change (heading and velocity, but not necessarily position), then the server verifies that the move is legal (no obstructions, no speed hacks, etc...), all clients that have avatars within the moving player's sphere of influence (i.e. all clients that can see the moving avatar) receive an update if the move is valid.

Things tend to become more complex though when you start factoring in response time (the amount of time between user input and visible client response), natural network latency and lag. There are many factors to consider and it's quite complex to do justice in a forum post. Some useful terms to Google for would be dead-reckoning, client prediction or client side extrapolation and interpolation. A good article to read is Torque Network Library Fundamentals, particularly the section "Strategies for Dealing with Latency". It's a nice introduction to the topic and should give you enough ammunition for further research.

This is all general information. I don't know how this applies to SGS, or how much of this SGS does for you, as I haven't delved into it yet. But it's still nice to know how this stuff works.

[Jeff]

On a related note, could someone offer guidance as to a reasonable approach to maintaining consistency between players in a physical/geographical world (such as a small multiplayer game). In particular, does one

* Have a player broadcast information about their whereabouts and movements directly to all other players, bypassing the server or
* Make sure every such thing goes through the server?

Everything should go through the server. The server is the final authority when it comes to game rules. Otherwise, you run into possible client cheats.

I'd slightly disagree.  You *can* go client-to-client IF you let the server override.

In an architecture like this the server is "listening" to all the movement and only speaks up to correct/stop a cheat.

The server has to be aware of the information though one way or the other.

Generally, each avatar in the game world will have a 'sphere of influence'. Imagine a sphere with the avatar at the center. Any game world object outside of that sphere of influence is not visible to that player. When the player moves, the sphere moves with the avatar. Move packets are sent to the server when one of the movement states change (heading and velocity, but not necessarily position), then the server verifies that the move is legal (no obstructions, no speed hacks, etc...), all clients that have avatars within the moving player's sphere of influence (i.e. all clients that can see the moving avatar) receive an update if the move is valid.

This agai ncanbe organized many ways.  In a region bsed game such as NWN you can simplify and just communicate among those in a region, so long as youa re assured that regions are reasonably small and wont be over-loaded with players.

More sophisticated schemes can actually reduce the visibility range based on load, depending on how complex you want to make things....

This is all general information. I don't know how this applies to SGS, or how much of this SGS does for you, as I haven't delved into it yet. But it's still nice to know how this stuff works.

SGS makes no assumptions about game model.  Thats up to the game developer.  We give you chann els as a building block, above that its up to you how to use them.

I expect we will eventually see both commerical and open source libraries and engines that do some or all of that building for you but today what you have is a base platform.

[hplus]

In an architecture like this the server is "listening" to all the movement and only speaks up to correct/stop a cheat.

I don't quite understand what the benefit is of that.

If the clients send data to each other, and a copy to the server, then the client can send different data to other clients than to the server; this may (depending on game design) lead to advantages to the client. The server wouldn't know, because the client would send unmodified packets to the server.

If the distribution to the other clients goes through the server, and the server "listens in" on this stream, then the server might as well be in the loop, and discard illegal data before it's even distributed. What would be the benefit of only broadcasting a correction after the fact, when the server is already involved in the distribution of the data?

[Jeff]

In an architecture like this the server is "listening" to all the movement and only speaks up to correct/stop a cheat.

I don't quite understand what the benefit is of that.

The benefit is reduced server load.

Its a question of what is 'critical' v. 'noncritical' data If you have a design that sends a monmement packer per player 10 or twenty times a second and the server has to respond to all of that on the logic level, you will hit a scaling wall pretty fast.

OTOH if it effectively "p2p" then it deos not invovle the GLE and has a much lower system load (negligable in comparison) on the back end.  Keep in mind that the world of the GLE is fully rpesistant wherase the comm layer is not,.

If you really have a need to filter a comm  layer stream its far mreo efficient to do it by plugging in a com-layer filter (next revision of the API will have this alon with the extension docs.  We already have it in our development code base.)

But in the end thre is no such thing as a 100% cheat proof game that scales massively and doesnt require obscene levels of hardware to do so.  What you need to do is asses the real "threat risk" of various kidns of cheats and if they ar worth the power it will take to make them impossibole. Threat risk is a combination of how easy a cheat is to accomplish, how much damage it does  to the game AND how easily noticable it is.  If the damage is low they probably arent worth scraficing play expereince for.  if the chance of beign detected is high then any cheaters will get caught and delt with promptly so damage is mtigated.

And as you say, it really coems down to game design on those points.

If the distribution to the other clients goes through the server, and the server "listens in" on this stream, then the server might as well be in the loop, and discard illegal data before it's even distributed. What would be the benefit of only broadcasting a correction after the fact, when the server is already involved in the distribution of the data?

The advanatge is that *critical* things ARE dealth with server side, for instance comabt.  and access to rewards.  Lets take an example with and withotu the detector:

(1) Without the dettector, I disabl;e wall collision on my server.  Now I can go around combats and straight to rewards.

(2) With the detector, when i try, I get reset to where I was befoer the cheat.  MOnsters and rewards still know me as beign at my correct place even if I try to cheat.

Wait, you say, you are sending everyones motion to the GLE arent you?  yes, but with two key differences: (1) It can be much lower resolution then what I send to players because how it "looks" is not important, only results are and (2) it can "lag" in its response under heavy load  without effecting apprent game play of non-cheating players.

This all comes down to game design,. There are NO easy "one size fits all answers" that look good, don';t lag, and maximally scale.  Designing MMOS is very much a world of balancing trade-offs.

This is just one desigtn above, ofcourse, there are mahy others.  But overly simplistic "Im just gonna make the serve do everything" approaches don't succeed for any serious size with any kind of serious load.

[hplus]

overly simplistic "Im just gonna make the serve do everything" approaches don't succeed for any serious size with any kind of serious load.

Nothing overly simplistic ever scales :-)

You can combine server-side real-time physics, input-synchronous networking, and scalability, as long as you're prepared to add cheap compute boxes to serve the player load. You can easily simulate hundreds of physical entities on a single machine, so scalability on the back end in this regard is mostly a matter of figuring out how to spread simulations over multiple machines while still allowing interactions.

I agree that massive designs are all about the trade-offs, though. You forgot "engineering effort" and "art production" in the trade-off tuple, btw :-)

[Jeff]

overly simplistic "Im just gonna make the serve do everything" approaches don't succeed for any serious size with any kind of serious load.

Nothing overly simplistic ever scales :-)

You can combine server-side real-time physics, input-synchronous networking, and scalability, as long as you're prepared to add cheap compute boxes to serve the player load.

That simple, huh?

You can easily simulate hundreds of physical entities on a single machine, so scalability on the back end in this regard is mostly a matter of figuring out how to spread simulations over multiple machines while still allowing interactions.

And landing a man on the moon was mostly a matter of figuring out how to get there....

[swpalmer]

And landing a man on the moon was mostly a matter of figuring out how to get there....

Yeah but the computing power on the Apollo rocket could easily be outdone by a Commodore 64

Games published by our own members! Check 'em out!

[aNt]

i thought it was a Apple Computer? isnt a Commodor64 still faster then a Mac? 
/runs and hides! all intel now anyway.... javaspaces (object store) workers are the
GLOs, snapshot, take, write, read is the rest... SGS? hummm... /hides a bit better!

[Jeff]

You are correct that the design was somehwat inspired by Javaspaces and similar tuple space systems.

BUT none of the ones out there have the kinds of performance we need so the SGS rolls its own.  In the process we also simplified the model as we have no need to search based on anything other then ID or a name-table that maps names to IDs (Primary Keys in all cases.)

[aNt]

surely an apache licence then? hehehehe