Game clients, game servers and scene graphs

I just read the official SpiderMonkey API docs and under the Creating Message Types section I see the following sentence:

Common message examples include transformation updates or game actions.

I’m wondering which would be applying the transformation updates/game actions: the client or the server.

It is my understanding that the client runs the scenegraph but allows messages from the server to modify the scenegraph (hence allowing each client to react to a change in the view based on other players’ actions or server actions).

It is my understanding that the server does not run/manage its own independent scenegraph.

Am I right on all of the above assumptions, or am I greatly misled?!

The server shouldn’t have or need a scenegraph, as a scenegraph used to organise and display spatials.

The server would send a message the client say, “move-player-to: 12, 14, 0”, the client is then left to interpret the message however needed: in most cases, updated the players spatial in the scene graph, however a different kind of client may actually command a physical robot in your room to move along the floor to that position, or it could place an audio node to that point if the client uses purely audio…

1 Like

The simple answer is… yes. Both of them do. In most cases you want your server to be authoritative - that is, your server is the authority on what’s what in the world. (If you don’t do this, you leave yourself wide open to all sorts of cheating.) In order to achieve this, you need two things (a) clients telling the server about what players want to do, and (b) the server telling clients about what really happened. For example… suppose you’re writing The Next Great MMO. In The Next Great MMO, players compete in a quest to see who can pick up the most golden apples. A naive (and, unfortunately, common one for new programmers) is to have the clients send messages to the server saying “My player picked up an apple!” The weakness here is that a cracked client (or network packet replays) can lie to the server about how many apples a player really picked up. What you really want is a server that spawns apples and tells clients where the apples spawned and clients that tell the server when their player tried to pick up an apple - which in turn tells the clients whether their player really got the apple or not. In short: yes. Both the server and client need to receive/apply/use information throughout the game.

Basically yes, but be a little careful with this one. Yes, each client does keep a scenegraph to display the world, and the objects in the scenegraph will wind up moving/changing/whatever based on messages from the server.

In general, yes. As @thetoucher said, a scenegraph is usually used for displaying the visual representation of the objects in your game so it doesn’t make much sense to have one on the server. However, there may be some rare cases where it does make sense (or at least it’s useful) to keep a scenegraph on the server. In my case, I’m planning to use a serverside scenegraph to handle doing raycasts through the scene for serverside visibility/collision checks. I should add a great big footnote here that I have not actually implemented this part of the project yet, and this might very well be a bad idea.

Thanks @danielp for the very thorough and thoughtful answer!

In general I’m following what you’re saying, however I have one followup question if you don’t mind. And, it probably stems from me just not being familiar enough (yet) with the jME3 API and its underlying concepts.

At first you answer my initial question (“I’m wondering which would be applying the transformation updates/game actions: the client or the server.”) as follows:

The simple answer is… yes. Both of them do.

But then you answer my last question (“It is my understanding that the server does not run/manage its own independent scenegraph.”) as follows:

In general, yes. As @thetoucher said, a scenegraph is usually used for displaying the visual representation of the objects in your game so it doesn’t make much sense to have one on the server.

To me (a poor, hapless newb!) these statements feel/seem contradictory, although I’m sure you’re referring to 2 different things in each statement.

So I guess I’m tied up with not understanding the difference between the “application of transformation updates” and “scenegraph management”. It seems that the former typically occurs on both client and server, but that the latter is almost always (your ray tracing example excluded) conducted client-side. If that’s true, then I guess the root of my question here is: why?!

How can the server apply transformation updates if its not also running its own server-side scenegraph?

Thanks again so much for all the help so far!

Generally, the server is concerned with game objects. It knows where they are and how to move them.

The scene graph is concerned with “how to display” those game objects. It may need a hierarchy to do that. It may need to load 20 different assets to represent a single game object. The server doesn’t care about any of that. It’s responsible for game logic. As far as the server is concerned, you could be displaying these objects as sprites on a 2D background. It will tell the client where they are and it’s up to the client to decide how to show them to the player.

Really depends on the game.

Eg say we programm chess, the server can be done with a 2dimensional array with ints, and an enum for the different types.
The client only gets send this array at changes and does everything itself
Only simple:
We programma 2d towerdefence, our map is determined as a linkedlist of vectors for the path, and positions for the towers in a hashmap (position to towertype) additionally a few support floats, like money, wave, ect. The enemys are moved by simple updating their position directly by interpolating it along the line/ or using a A* for maze building defences, no scenegraph is required for this.
Full Scenegraph:
We programm a 3d space game, the server has a scenegraph of some kind, to properly calculate relative positions of guns and hitpoints onto the ships. in this case the scenegraph is only serverside, each ship being only a viewvector, a damagedsubsystemlist and a enum for the shiptype.
Shared Scenegraph:
We extend the above game with custom buildable ships, we now additionally transfer the information of how the ship is build (position,rotation,model) for each suppart in relation to the ship, so we kinda transmit all information the client requires to rebuild an identical scenegraph that is used for rendering.

tl;dr it really depends on your game if you want a scenegraph srverside and if you want to transfer it. Having a flat non scenegraph server if possible reduces your work quite considerable.

I’d still argue that in all of your examples, the concern of rendering the scene efficiently and gloriously are different than the concerns of keeping track of the objects. For example, even in the last case, it’s entirely possible that the game objects are in an inverted graph where the children only know their parents and the parents never really care who their children are.

On the visualization side, you might partition things into sectors, zone hierarchies, load extra assets per model, etc… On the server, “custom ships” might even just be an array of ints.

The “I want to perform visually accurate ray tracing” is about the best argument I’ve seen for keeping a “scene graph” on the server… and it’s probably the only use-case that I’d even remotely consider it. And even in that case, the server might be dealing with a vastly simplified version of what the player sees.

@pspeed and @Empire_Phoenix have covered this quite well, but just to chip in my 2 cents… think of a game as a world that just has a bunch of data and rules governing how all that data interacts. How you choose to store/represent that data is up to you. A scenegraph data structure is one that’s very handy for 3D games, and that’s why jME (and a number of other engines) use one to store all of the information they need to display a 3D game. However, most of the time it’s not a data structure that lends itself super well to a server. Going back to the example of The Next Great MMO, you have two kinds of data: players and apples. The server can manage that data however you like… a list of players and a list of apples (probably a bad idea in practice, just using it as an example), a HashMap of players by id and some sort of a lookup of apples by location, etc. In most cases, however, a full-blown scenegraph on the server is not a great choice. Speaking specifically since you mentioned transforms, a “transform” is just a change to an objects location/rotation/scale. The server can track location/rotation/scale in any way - it doesn’t need to use a scenegraph for that.

@pspeed, accurate ray tracing is exactly why I’m considering putting a scenegraph serverside in my project… but that scenegraph will not be the primary structure used to represent world state, and it will only contain the bare minimum amount of information needed to do the ray traces (bounding boxes or very low LOD meshes - haven’t looked into the specifics of what this would need just yet) and possibly some fast distance estimates or something else I haven’t thought of yet.

Exactly my point then. It’s just a separate projection of the state… and somewhat unrelated to what goes on in the client. The fact that it might be a scene graph is an implementation detail (and not truly necessary either).

I guess if you’re coming from a desktop programmers point of view - it might be easier to understand the relationship as a website vs an open JSON api. The server just spits out JSON. It’s just pure data. That’s all the server will ever do. And the client (in this example - displayed as a website) represents that data as a beautiful website. And that’s what a game-client does. Represents this matrix of “data” into a two or three dimensional wonderland.

Facebook and other leading website pre-empt responses. When you click save. It doesnt save that fast. They “guess” it will be fine - they just code it in as a “yep thats fine” moment - but it’s still actually being sent and processed - and in 99.9% of the cases it will be fine. So when you press forward - you pre-empt it. You know it “should” be there by all means. And when the server responds that yes - you are correct - you have nothing to worry about. But when the server returns a different response - thats where the correction comes in. Oops - we have a 0.01% problem here. Represented by rubber-banding. Lag. Wtf moments. That is what is meant by “server and client” operations. They both do it, but ultimately - the server is the enforcing agent.