I've been reading and searching on these forums, on captiveimagination, as well as examples and jME och JGN source to try to figure out an efficient way to set up a client/server-relationship for an MMO game.
My thoughts about this have distilled into a few questions, namely these:
I've read about StandardGame in it's headless state being used on the server side. Is this a generally efficient approach for an MMO? I imagine that the server keeps a standardGame for each client with a sceneGraph to easily keep everything synced, is that usually the case? Or could it be more efficient to make your own classes to handle the information?
How have you (if you have) solved the issue of attaching one instance of an object to several sceneGraphs on the server (assuming the above set up)? Perhaps make a nodeObject with a reference to the original object for each sceneGraph and let the object send out updates to all created nodeObjects?
If I use a universe without any skyBox but where stars that are far away turn into spots, would this create too much overhead with 1000's of stars? Would using a frustum that is almost infinate be a problem?
I've also wondered about what to let the client do and what the server should handle and seen different approaches. Does it usually put alot of weight on the server if you let it do most calculations and let the client just send commands like "accelerate", "turn left" and so on, letting the client receive the new position from the server (to correct approximated position in client)?
My thanks go out to all devs and users of jME and JGN!
I only have mild experience with JGN, so I'm going to defer on those questions for now. But I can answer one of them:
Tumaini said:
* If I use a universe without any skyBox but where stars that are far away turn into spots, would this create too much overhead with 1000's of stars? Would using a frustum that is almost infinate be a problem?
Yes. The problem with increasing the far plane of the frustum is you lose precision in the depth buffer (i.e. it will render crappy). Also, a large part about graphics is making things 'look' great without actually getting into the details of 1000's of individual stars. I don't want to discourage you from trying anything, but I think you may hit some limitations with this one.
I assume you've seen the networking tutorials that were integrated into the Flag Rush series. I believe they are included with JGN, and highly recommend going through it if you have not yet. This will clear up many questions you have about how things can actually be implemented with these frameworks.
Yes. The problem with increasing the far plane of the frustum is you lose precision in the depth buffer (i.e. it will render crappy). Also, a large part about graphics is making things 'look' great without actually getting into the details of 1000's of individual stars. I don't want to discourage you from trying anything, but I think you may hit some limitations with this one.
I assume you've seen the networking tutorials that were integrated into the Flag Rush series. I believe they are included with JGN, and highly recommend going through it if you have not yet. This will clear up many questions you have about how things can actually be implemented with these frameworks.
But where do I lose precision? I only want the nearest objects, maybe a few planets, ships and one/two stars to look good, the stars that are outside of the system should just be spots. Would the near objects lose precision? I've also thought about having a huge skybox and "painting" the far stars on it, but I want the player to be able to click on a star and get info on it/travel to it.
I've read some of the Flag rush files that come with JGN, though the whole program never works on my computer (something with the terrain being too big), so I've only tried it with a tiny terrain and I didn't find much documentation about what it was supposed to do network wise. I'll look into it again.
Quote:
Now about the lots of different starz, you wouldn't want to call a map by 500thousand by 500thousand... like nymon said.
You could just use a background for stars (which is exactly what this game called spore did). If you wanted to see every object in the game that's on your screen's pane, that would mean every object would have to be rendered if you did a 360 degree spin ... now about "to correct approximated position in client" this is were reverse engineering clients completely ruin programming, Not having any simple math being solved via client just kills the bandwidth and overall latency speed. If you don't have atleast a quad core on a self hosted game, you're going to kill your cpu if you do anything other than hosting on that specific computer (i.e. get that blue screen of death). So 1 is not better than the other
Thank you for that code. I don't have a problem with handling players, inventory and such though, it's the graphical restrictions I'm unfamiliar with and how to make the network as efficient as possible, while still being easy to maintain.
As I'll be using a 3D universe, I won't be loading any terrain in this "space gameState", so what I would load would be the planets and ships that are near a player, and then all other stars (that are far away). These would be rendered as spots instead of real models. I'm just not sure if I should use one StandardGame for each client or if it would be better to use one huge StandardGame which holds the entire universe and then relay changes by sync to the part of that sceneGraph to each client that the respective client would see. Or if I should just use custom built classes on the server but also sync with JGN.
I disagree with what sonis says. Though you don’t want a new thread created per player necessarily I sometimes manage up to 1000 threads in applications without any noticeable penalty. Granted, those threads are being managed by my ThreadManager system (available in my xjava project: http://xjava.googlecode.com) so I’m not creating and removing threads on a normal basis, I’m simply letting it keep track of my threads and add more as needed and then I give it “work” to do with priorities, blocking, etc.
As for JGN, you can check out the wiki for a bit more information along with the tests in the src that show how JGN works:
Thanks darkfrog. That thread manager sounds like something I should look into, if I do use threads for users.
I've looked into the flagrush files that come with JGN as well as some more into the sync examples and source files.
What confused me the first time was that the server started a whole game, with a screen, controls and everything and that the game created exactly one player that was then used to syncronize with the player in the client.
But from what I've seen I've extrapolated that this is how the setup would work (please correct me if I get it wrong):
*The server has one headless StandardGame with a GameState for the entire world's graphics (and if players can land on planets and walk on the terrain there, there would be a GameState for each of the planets, that would be sleeping when noone was there).
*In the server's GameState, only the update function is used, the render function does nothing = override the render function with an empty one? (since nothing will render on the server).
*The client has a normal StandardGame with different GameStates for various parts of the game, one for the main world (space), which works like normal and registers objects with the sync manager to keep them synced with the server.
*When a client logs in the server creates a new player on the server, gets that players info, adds the ship to the server sceneGraph, registers it to the sync manager, then sends the (in this case 27) nodes/quadrants that are near the player along with all objects attached to them and their information. These are then registered to the sync manager here too (alternatively you don't send the sceneGraph nodes, but rather just strings with the info of what and where the client should create).
Darkfrog, are you still developing JGN ? I'm using it (and it's working very well) but my copy is more than a year old I think. Any new things or major updates that would make it worthwhile to upgrade ?
Tumaini, I responded to your cross-post on the JGN forum.
Baune, mostly just bug fixes and performance updates. Not a lot of active development has happened on the JGN 2.0 code base for a while. However, there may be something completely new coming down the pipe in the next few months, but you'll have to just wait to find out more.
