It’s not a problem for me. I already have a working project, but it’s very old, on jme1.
I completely rewrote the network stack, made it on netty 4.1+. Works great.
I completely rewrote the database to hibernate.
and now I want to rewrite the game engine from jme1 to jme3, and use all the available capabilities of this miracle engine.
at the moment jme1 works, but it is very bad used, use only as a calculation for collisions, where after the collision the height coordinate sent to the client.
I have experience. I want understand the best practice from what to extend the zoneid class? and how to link it to appstate and to simpleapplication. I’ll figure it out further.
You have stuff… that is your game stuff. The world data, NPCs, milk cartons, whatever. Each zone has its own “stuff”. AllTheGameStuff is your stuff. Whatever that is.
I’m not writing your game so I don’t know what that is. I could explain it in terms of my own examples (already linked) but they are already very different than your approach.
…and most MMOs will be using an entity system anyway.
In my case (note it’s not an MMO), each map is completely separated from the other maps and is backed by its own entity Database and physics space. Players can teleport inside the map and I am using Zay-ES and SimEthereal and it’s ZoneManager that divides space in to zones to provide view limits for each client in the same map.
On the server-side, a map is managed by a single server instance and the URL to that map’s entity database.
When I want to switch players from one map to another map I just kill the current server instance and spawn a new server instance with the DB URL for the new map.
If I ever want to let each player be on a different map (I do not need this feature atm for my game) I can spawn multiple server instances, each managing a single map.
Edit:
I also have a master server with REST API to manage game server registration, player-specific save data, profile,…
Why do you still feel the need to have a root node that holds your zones? They will literally never be displayed at the same time.
Why do your zones extend root node? A zone maybe “has a root node”… there is no reason for it to “be a” root node. Especially since having a root node on the server at all may be questionable. (Not a single server I’ve ever written even uses a scene graph on the server… just a bunch of rigid bodies in a physics space at the closest.)
Also note: there is little reason to have the server extend SimpleApplication… you drag along all of the “render to a GPU stuff” without actually using any of it. Even if you want to use app states for your game logic (instead of a simpler game system of some kind) then you could just use a state manager directly and leave off calling the render-based stuff.
If you use JME Control objects heavily on the server then I guess you are a little stuck… then you suck in this, then that, then that… and before long you are back to writing a whole GUI application for the server again.
rootNode → Its a Node that is used for a main render purpose (elements within it and camera scope/etc will be rendered and update() will be called)
So you should think of it as about some “renderNode” while all other Nodes that are not inside it are “nonRenderNodes”.
(You know you can have Node inside Node inside Node? etc?)
This way you could just have own Nodes that are “nowhere” and put only “current one” into rootNode and switch them based on where player is.
also if you need update physics in not-current areas, you would need call update manually for their nodes if they are not in “render/update process”.
Also anyway you should learn about ECS to determine if you need it for your purpose.
But generally a lot of misunderstand come from that you didnt read wiki/scenegraph tutorial, am i wrong?
I would like to learn something here, unfortunately I don’t understand the question.
Should a game run on a rendering server and all users are streaming? (Then the architecture would still provide data servers, controlling servers and lots of individual rendering servers and not a single mosnter graphics card).
Should a game run on a controlling server and should the events be calculated using graphic card programming? Then only the physical hulls and not the whole scene have to be created. Nevertheless, here too, the architecture of the server landscape would not provide for a single monster card.
It’s a hot seat for two players with two controllers and a split screen. At most two cities and two RootNodes and two cameras?
In short: I don’t understand why both cities should be rendered on the same graphics card.
I think the best answer that really defines this topic , is that the game server is nothing but a command sender that commands clients to render their game as an Entity , may be that would be only if all players are ready then isReady is settled to true which in turn commands the server to command a feedback for the clients isRender=true → Render the game & the scene for each player accordingly , but as Paul said , it’s a large topic to open now , @TidalPoo wants something simpler now , which is like GTA VICE CITY or GTA III but 2 small cities instead of one big .
EDIT : I am working on a networked small game that’s something like Rocket Leauge for android using RealTime Firebase Servers , I have started like that already.
for my java application i am planning to use rigid body physics. After many searches for the framework, I settled on jme3.
In my application there are different zones, with different terrain, solid objects - houses, trees, on which I plan to place NPCs and gamers. No drawing and no animation, no sounds. Only math and events. I expect to use only physics, collision, character movement, navMesh functions, events, and triggers.
all the rest of the logic I have done, as network
for example: a package recived from a client, “move the character 10 meters.” I transfer this to the jme3 engine, after the character moves on terrain with walkDerection, I will take physical coordinates, especially the height coordinate by terrain, and pass it back to the client, and in the client this character will also move to the desired height.
this is the main thing that I need from the engine.
Edit:
each zone is a separate object, with a own ID with its own events, with its own coordinates, with its own terrain, separated from other zones, and not intersecting with other zones.
No)) try start from begin. Maybe start new topic?)
The client work on CryEngine. Managed by network packets from my java desktop server. The package logic is done. In fact, the game is generally done and work.
Then java server is running, clients
connect to the server, sends and receives net packets, based on which it renders the game in client. I just want to refactoring server, and try use jme3. Because now there is no logic of physics objects. NPCs walk through walls, fall into the ground, walk on air. Because the current physics implementation is not correct. Jme1 is currently being used. I wrote about this earlier.
For me need zones, these are cities. Between which the character is teleported. Cities are independent from each other, they are identified in the client and server by id. Cities are 3d objects, I make them in blender, 3dmax.
I need to somehow implement cities as objects or nodes, or AppState (i realy don’t no) in jme3. Create physics, own statemanager (or else), where I will use control, collisions, navMesh. Desirable independent statemanager (or appstates, or zoneIdState)