Multiplayer, multiple maps, and me.

#1 Interesting that you mention that. I was wondering the same thing. I have done tests with all of us on the same map, and when the server changes maps, all players experience it. And if you are lower than the ground in the new map in your current xyz location in space, then your player will of course plummet into the deep abyss of nothingness.

My hunch is that to have people on different maps, each one would require a separate server connection albeit on the same machine. I think this is possible and common with Torque but I'm not sure. Think Tanks, for example, looks like its hosting several separate server connections all on the same box. We'll find out in a short while, though as soon as this thread gets answered.

#2 You would need to have different game servers running different mission files (or zones). Then you would use in game triggers to send players to another server/zone. I've tested with 3 servers running on the same machine and it seems to work fine zoning from server to server..

#3 I see. So when a player reaches a certain level, s/he will be transported to the other server (software server running on that same machine) and continue on. Correct?

I understand how triggers work in general, but how do you send someone to another zone?

#4 Yah, Look in the joinServergui for the function that allows players to connect to a remote server. I basically used this resource to get the zoning part then just called *connect() - IIRC to the new ip.

#5 Erg... not what I was hoping for... Even a "modest" server of 12-14 people would require as many servers.

Hmm.

#6 NO...what are you talking about. 12 - 14 people could all play on the same map. Then each one gets promoted to the new levels one by one.

#7 Ok found my old post, when i was working on this
heres the code to make the player zone:
www.garagegames.com/mg/forums/result.thread.php?qt=19710

#8 12 to 14 people could not all be on different maps at the same time however.... which is what I was looking for if you allowed players to go where they please.

#9 I wasn't specific enough I think... I apologize.

I would like a system where X number of players could be on X different maps with persistant data between them and communication back and forth. I suppose this is something like the MMRPG threads, but not really. The "zone" sizes would be much smaller.

#10 This is exactly what we do..

You would just need X servers where X is the number of different maps you want. Then use a database implimentation to handle persistant data. Do a search on persistant character server resource for details..

#11 And "server" is defined as a server instance, of which you can have many on one physical "platform" at once...just make sure they are assigned different port numbers to listen to, and have some mechanism for communication: a server manager, common database, or the like.

#12 Actually if you take this a step further (And I apologize if I missed a post and this has already been said) you write a server manager application that can spawn any "zone" on any physical server "on demand" so that you could in theory run many many zones on a smaller number of servers as you grow your player base =).

The server manager would basically be a module you run on every server side code to check for population. If the zone is empty, take down the zone and add the server to the global "available" list. When a player zones into a zone that is dormant (IE no server is running) it picks the next available piece of hardware and spawns zone X on it.

Further to that I am planning on personally trying to get multiple zones running on a single physical server. Then load balance the playerbase based on sheer numbers rather than wether a zone is dormant or not. Basically write the code to use the average number of players in an area over different timeframes to determine which zones to combine onto a single physical server based on the average player population in said zones over various timeframes. It's not something I'm focussing on as I have alot of more serious modeules to get ingame first.

Mark

#13 Great info. thanks Flybright, Kevin, and Stephen. I have saved this page. Very relevant to the work I'm doing.