Indie-Resource.com

I'm putting together a quick proof of a concept game. This proof will have 3 playable areas. A "Home Base", "World 1" and "World 2". My original version used an Canvas and a very basic Isometric viewer that I wrote. The "server" was a set of php files that accessed a MySQL database to pass world information to the client. This data was requested with a javascript timer that called for the data via AJAX every 300 ms. The world data was passed based on the session created in php to know what map the player was requesting data for, and the xy cords of the top left corner of the view port in world coordinates.

So, now that I'm moving to Isogenic server and using the Node.js server I am presented with a few questions about the "correct" way to do this. Since the server broadcasts to all clients connected to it, I would assume that, like other MMO style games, it would be best to limit the amount of packets by breaking up the connections to logical areas or zones. I don't see a way this can be done "out of the box", so I'm going to assume that I would need to run multiple servers to handle the different play worlds. (SubQuestion1, Is that assumption correct?) If I was going to set the game up to connect to different servers (SubQuestion2, Better to use different servers, or just run multiple instances of Node on different ports?) should I limit the resources of the client by loading individual pages for each of the worlds? (example: homebase.html, world1.html, world2.html) Or would it be better to load everything in a single page (index.html) and then let the server manage what needs to be displayed, and resetting the connection to a new server via a javascript call? I know that sounds confusing and I'm sorry, it's the best I can explain it.

Also, The "Home Base" map is really a single player map that will interface with a server trigger the display of menus and update UI elements. I'm thinking that the best way to do this is to make it a page that uses the Isogenic engine to display the map and UI, but use AJAX and php to pass information to the server. Since this does not need to be real-time I don't see a reason to waste the server on it, and since this map will be single player interaction, there is no reason for a server to update any other clients. Once the user enters a world I would just load a new page that would handle the world. That world page would then connect to a real-time server. Would this be the correct way to handle the "Home Base"?

A little background on the game type, in case it makes a difference in the way to handle this game. The game will be real-time strategy / resource management. The "Home Base" will be where the player can check stats, build new units/buildings, do upgrades, etc. The worlds will be playable to users based on level. So, leaving the "Home Base" will only take you to your current World. Once a player reaches a certain point in the game they will transition to a new world. Once they leave the old one behind they will never return. So for example, all new players will start on "World 1", once they reach 25km of area and x number of resource generators captured the game will progress them to "World 2". The server needs to know what player owns certain map tiles and how many units are stationed at those tiles, but once a player has moved to another world they will never interact with that world again.

Thank you for any input you might have.

Demotis wrote:I'm putting together a quick proof of a concept game. This proof will have 3 playable areas. A "Home Base", "World 1" and "World 2". My original version used an Canvas and a very basic Isometric viewer that I wrote. The "server" was a set of php files that accessed a MySQL database to pass world information to the client. This data was requested with a javascript timer that called for the data via AJAX every 300 ms. The world data was passed based on the session created in php to know what map the player was requesting data for, and the xy cords of the top left corner of the view port in world coordinates.

So, now that I'm moving to Isogenic server and using the Node.js server I am presented with a few questions about the "correct" way to do this. Since the server broadcasts to all clients connected to it, I would assume that, like other MMO style games, it would be best to limit the amount of packets by breaking up the connections to logical areas or zones. I don't see a way this can be done "out of the box", so I'm going to assume that I would need to run multiple servers to handle the different play worlds. (SubQuestion1, Is that assumption correct?) If I was going to set the game up to connect to different servers (SubQuestion2, Better to use different servers, or just run multiple instances of Node on different ports?) should I limit the resources of the client by loading individual pages for each of the worlds? (example: homebase.html, world1.html, world2.html) Or would it be better to load everything in a single page (index.html) and then let the server manage what needs to be displayed, and resetting the connection to a new server via a javascript call? I know that sounds confusing and I'm sorry, it's the best I can explain it.

Also, The "Home Base" map is really a single player map that will interface with a server trigger the display of menus and update UI elements. I'm thinking that the best way to do this is to make it a page that uses the Isogenic engine to display the map and UI, but use AJAX and php to pass information to the server. Since this does not need to be real-time I don't see a reason to waste the server on it, and since this map will be single player interaction, there is no reason for a server to update any other clients. Once the user enters a world I would just load a new page that would handle the world. That world page would then connect to a real-time server. Would this be the correct way to handle the "Home Base"?

A little background on the game type, in case it makes a difference in the way to handle this game. The game will be real-time strategy / resource management. The "Home Base" will be where the player can check stats, build new units/buildings, do upgrades, etc. The worlds will be playable to users based on level. So, leaving the "Home Base" will only take you to your current World. Once a player reaches a certain point in the game they will transition to a new world. Once they leave the old one behind they will never return. So for example, all new players will start on "World 1", once they reach 25km of area and x number of resource generators captured the game will progress them to "World 2". The server needs to know what player owns certain map tiles and how many units are stationed at those tiles, but once a player has moved to another world they will never interact with that world again.

Thank you for any input you might have.

Hey ya,

Technically there is no "best practise" way of doing it. The engine does support the ability to run multiple "zones" on a single server but you have to modify the stream logic so that only the relevant data gets sent to the relevant players of particular zones. That is handled either with a streamControl method or in advanced streaming mode (see the site documentation on streams).

Alternatively you can do it as you described by loading particular zones into individual server processes. You could easily have multiple processes running on different ports and then maybe have a PHP script to return to the client what IP/port they should connect to when loading a new zone. This is probably the easiest way to do it.

You might even consider a PHP script that each server instance can call to get the map info to load, that way you could employ a round-robin sort-of setup where you can fire up 3 server instances and they will all be given a different zone to manage by your PHP return. This has the benefit of being more automated since you wouldn't need to instruct each server with what map data to load, it would be told automatically.

Let me know if you want any more insight.