Effecting analogous objects across networks

As I was toying with JMonkey’s networking API, I realised that Spatials and other Jmonkey objects were not serialized. After reading other posts on this forum detailing why that was so, I began to try formulating ways to make sure that analogous objects were effected across connections, e.g. a translation of Node n on the client would have the same effect on the same Node on the server. I came up with several ideas, each varying slightly in form, but all based around the idea of id-ing Nodes (or other objects) and searching for them on the other side of the connection to make changes to. My solutions did not seem to be very optimal, so I was wondering if there were other solutions.

First of all, it will be super important to disconnect the idea of Nodes and Spatials as game objects. They are visualizations of game objects but they are not game objects. From there, I guess there are approximately 3,145,160 ways to network a game. :slight_smile: A lot depends on your requirements, though.

Anything close to real time, then you should carefully read (and probably reread a few times) these articles:

If you’ve never written a game before then write a single player game first. Networking makes it 100x to 1000x harder. That’s no joke or exaggeration.

Hi there pspeed, thanks for responding. I took another look at the MonkeyZone code and, correct me if I am wrong, but think I saw that rather than having “picking logic” done on the client, instead, MonkeyZone clients only messaged input and allowed the server to do deduce picking of Spatials from that. Is that what you meant by “disconnect the idea of Nodes and Spatials as game objects”?

I think I’ve seen those Valve pages before, but I’ll definitely go through them with more detail the last time I saw read them, my head hurt. :). Oh, and you are right about multiplayer being 1000 times harder. I’ve been playing with Jmonkey on and off for a year or so now, and have made a simple game or two, but none of the problems I faced with those has compared with the headaches I have gone through to even understand networking. :slight_smile:

MonkeyZone doesn’t really separate game objects from spatials, as I recall. It tries to be simpler and so lumps everything together.

Usually in a game, an object is a game entity. It has only what’s necessary to be in the game. It exists independent of any sort of visualization. (If you aren’t familiar with the Model-View-Controller pattern then now is the time to learn it.)

The server shouldn’t care if you are rendering your game objects as a bunch of spheres or as little stick men. It only knows what it needs to implement the game logic and that’s all that’s ‘networked’. The visualization then decides what to do with it.

For a (poorly documented) different take on a network architecture you can look at the other end of the spectrum where Monkey Trap uses an ‘entity system’ as its networking layer. It’s somewhat ‘turn based’ nature eliminated any need to do any sort of Valve-style prediction and compression, etc… in fact, most of the game doesn’t even know it’s networked. The single player and multiplayer games are essentially the same code… they just need to be good ‘entity system citizens’ and keep in mind that the network might be there.

That approach is more complicated because it’s using an ES which is already a pretty huge learning curve. But the networking is all handled by the ES.

The spatials and nodes are just representations of data. It makes absolutely no difference whether you are working with spatials, floats, enums or any other kind of data. The point is that you have data and your goal is to synchronize it across multiple network connections in as primitive-a-form as possible using the least amount of lookups or responses, preferably keeping all important data (such as a players position) server-side enforced (as to avoid cheating). Its complicated. It’s really complicated. But the point is that it’s game-specific. My implementation will not work with your game, and so on, hence the reason the jmonkey implementation provides the core implementation. Just make sure that you try to reduce everything down in to as-tiny-as-you-can-get little packets of data, and send those tiny packets of data in bulk - that is to say fill the packet as much as you can.

Hmm, I kinda suspected that there would be no one-size-fits-all solution. I’ll experiment with that MVC-pattern, its far more elegant than my current set up.