First of all since this is my first post
… Hello to everyone
I have a question and i cannot find an answer on the Net so maybe i am just asking the wrong question !
This is an architectural qn.
So,
I am trying to develop a network board game with a lobby for players to chat and challenge each other.
Using spidermonkey i have a created an instance of a Simpleapp server side and have n-clients each running their own SimpleApp instance.
A single JME app server-side will handle the ‘lobby’ part forward messages etc, everything peachy
This looks to me like an architecture of the server running ONE game and MANY clients connecting to this one ‘game’
BUT what i need is the server being able to run n instances of the game logic, one per pair of clients playing.
It seems insane to have each of these ‘games’ attach as an AbstractAppState to the single state manager so i am assuming i need some server object that will launch the ‘lobby’ simpleApp, and have clients connect to this and when a game is started between 2 clients have a new SimpleApp instance object handling this and the lobby instance delegating messages from players to the respective game (SimpleApp) instance …Which of the two is correct if any and if none what is the way to go about doing this.
Hm why is your lobby s impleapp? It basically only needs to be a throttled while (true)donetworkstuff() ?
As for the other question, what is your intented scalability?
10 Games? 500 Games? Multiple systems hosting the games?
The first 2 cases might be possible by simply using the processbuilder and actually start a own jvm instance for only the one game. (Pass via main args the ports and tell them via lobby to the clients, wich then can connect to their game)
Pro+ Game crash would not disturb anything else,
possibility to patch game (just add a newer version jar and let all newer games start with that one, (delete old one once all game instances using it are closed)
Contra- Each asset would be loaded once per game instance, so its more memory heavy.
Alternativly
Using Threads, appstates ect you could run them all in one jvm, kinda as you explained above.
Or as a saying here is.
If it works it ain’t stupid.
I agree with empire… I would never in a million years use SimpleApplication on a server… or Application or anything related to it. Typically my servers use only 2 things from JME: networking and math.
The application class includes a bunch of stuff (most of its stuff) that is completely unnecessary for running a server. You don’t need sound, you don’t need user input, you don’t need display stuff, you don’t need viewports, etc… it’s possibly to turn these off but then what are you left with? Answer: a state manager and scheduled execution. And AppStates themselves have some methods that are only related to rendering.
Add to that that most ‘state’ is client related and therefore you will end up managing client-specific states rather than global states and the whole Application thing is a whole lot of nothing. A ScheduledThreadPoolExecutor and some nicely designed connection session attributes (and appropriate message listeners) are all you need.
Whether you use SpiderMonkey for this or not is a matter of scalability. For a turn-based game with thousands and thousands of players you are probably better writing a web application. If you can move any concept of an ‘active session’ into the data itself then you can scale up to millions of players.
First of all
‘why is your lobby s impleapp?’
‘I would never in a million years use SimpleApplication on a server’
yes! my original network module is basically a loop and an executor and a pair of threads over a socket, server side (1 to Write and 1 to Listen) … Then i run across spidermonkey and the main tutorial starts by creating a headless simpleapp server side so i followed suit … my bad
If you want an example of using HostedConnection session attributes as a sort of stateful manager of some connection-specific service on the server… you can look at how I did the networking in Zay-ES’s networking layer.
Essentially, the message listener for a certain set of messages looks up an object in the connections’ session attributes and then forwards the methods to it.
Well, i use a simpleapplication for the server cause i need physics AND i like how i can create a really plugin-friendly server with the appstate/control stuff. Also, i need the assetloader to load models (even if it would be better with a version of the assetloader which wouldn’t load textures).
For the multigame aspect, i use a class named LayeredAppStateManager in each game. The basic idea is : if the appstate exists in the game instance (is defined for this instance), the the getState method return this instance. Otherwise, it will search in default/globals appstates.
I understand that an entity system is by nature not plugin-able ( you can’t modify an existing comportement, you need to recreate it - that said with my limited comprehension of the entity system ), but with the control system, you can create derived class that will derive an existing comportement in a plugin and the rest of the application will not know it. For this, each unit in the world need to have its own “brain”, and the triplet appstate/control/userdatas fits my need perfectly.
@bubuche said:
Well, i use a simpleapplication for the server cause i need physics AND i like how i can create a really plugin-friendly server with the appstate/control stuff. Also, i need the assetloader to load models (even if it would be better with a version of the assetloader which wouldn't load textures).
For the multigame aspect, i use a class named LayeredAppStateManager in each game. The basic idea is : if the appstate exists in the game instance (is defined for this instance), the the getState method return this instance. Otherwise, it will search in default/globals appstates.
I understand that an entity system is by nature not plugin-able ( you can’t modify an existing comportement, you need to recreate it - that said with my limited comprehension of the entity system ), but with the control system, you can create derived class that will derive an existing comportement in a plugin and the rest of the application will not know it. For this, each unit in the world need to have its own “brain”, and the triplet appstate/control/userdatas fits my need perfectly.
Certainly it works… but you’ve also pulled in a lot of stuff you don’t really need just to get something that only takes 20 minutes or so to write yourself. I think many of the things you’ve pulled in were partly because you also pulled in the other stuff. For example, you likely wouldn’t need the asset manager if you didn’t want to load models… and you might not want to load models if you didn’t need controls, etc… I mean, physics may be an issue but you don’t need JME Spatials to do physics at all… and all you’d at most need for physics is the collision shape and you are better off just saving/loading that.
You have something that works and you probably shouldn’t change it now… but I wouldn’t necessarily recommend it for someone starting out. It tends to encourage mixing view with model (Spatials with game data).
Note: in an ES-based approach you don’t really need controls as the system managing the ‘brain’ would have its own game objects that it was managing and would update them appropriately rather than traversing a scene graph to do it, ie: it would simply iterate over all Brains and update them.
… my bad 