Indie-Resource.com

I'm trying to figure out how best and how to create multiple instances for players using ImpactJS and Node.js. I'm not looking for codes, but rather the best way to tackle this. This is the example of the problem:
Taking Sid Meyer's Pirates as a reference. Players start in seaports which act as a sort of lobby or hub. From there, players can then go into the big pond (large strategic map) and begin there travel, seeing themselves as tiny ships. The big map is likely to be broken down into smaller maps, just to provide ease of segregation of players. But when say two players (or more) encounter one another, then combat may occur, which would go into an Instanced Tactical Map. Of which more detail and larger images are used.

What I am guessing off-hand would be to that server side PHP would be used to manage when combat instances occur. And when they do occur, the server (via PHP) temporary create a new game ID (or gamename), and then would direct ImpactJS to load up a given map and place the given players into that map. This would then prevent other players from entering that game (as well as have some routine checks with the database to verify the correct players are in the given instance).

Would that be the best way to tackle this or is there a better or already an existing method for this?

Just for added information, I am thinking of using ImpactJS for the front end, with the server using PHP scripts to verify the actions (and hopefully reduce cheating). The Lobby session is not needed for real-time use and thus likely to use AJAX calls to the server. But once going into travel mode or a combat instance, then that is when the real-timing is needed to be used. I'm not looking for precise timing, as like a FPS, but something to near real-time.

I hope that made sense...

For my rooms on my webchat game uses the socket array of Node. like socket.clientid, or socket.room.

if you did want to use the node server to track then you could add socket.party then have it check all people in that party. Node will keep that property attached to that socket. This way you can send that data as well to the clients. socket.emit("getparty", socket.party);

Unfortunately I am new to sockets and node, so I am somewhat trying to grasp this.

So basically following the following information in regards to rooms:
https://github.com/LearnBoost/socket.io/wiki/Rooms
What is the proper way to manage multiple chat rooms with socket.io?
http://stackoverflow.com/questions/6721 ... -socket-io
Dynamic rooms with Socket.io and Node
http://stackoverflow.com/questions/6846 ... -node?rq=1

That is to create rooms (instances) with the players put in, manage them, and then transfer the players out when done, and disconnect the room.

Would there be a limitation of the number connections as a whole (even if split up into multiple rooms) or is all of this handled by the hardware or cloud service (if used, such as Pubnub)?

As far as connections Nodejs can do a ton

Felix Geisendörfer recently tweeted that Node.js can allocate 1.6 million concurrent HTTP server requests through a single socket before running out of memory. Resulting in a 1.53kb memory allocation per request. This was done by flushing a huge buffer of GET /\n\n in one HTTP connection. 1.6 million is quite impressive, but than again Node.js is known for it’s first class and high quality HTTP parser (Thanks Ry!).

http://blog.caustik.com/2012/04/10/node ... nnections/

Well that is good to hear... more than enough to work with. And if for some reason needed to go beyond that, then just create another server/service it seems.

Keep in mind that most Node implementations are completely single-threaded and run on one processor. However, that doesn't have to be the case. Node has pretty much solved this issue, which was considered one of the major hits against Node outside of the complication of asynchronous programming patterns in complex applications. You can find out more about Node's native support for clustering here (I know their documentation sucks, but at least its official lol). The old solution was to simply start up another completely separate server and code in ways for them to communicate and share the load, but clustering makes it much, much easier.

Very nice!

Jackolantern wrote:Keep in mind that most Node implementations are completely single-threaded and run on one processor. However, that doesn't have to be the case. Node has pretty much solved this issue, which was considered one of the major hits against Node outside of the complication of asynchronous programming patterns in complex applications. You can find out more about Node's native support for clustering here (I know their documentation sucks, but at least its official lol). The old solution was to simply start up another completely separate server and code in ways for them to communicate and share the load, but clustering makes it much, much easier.

Nice!

whoa Chris is back!

He seems to duck in and out every once in a while