Instancing/Multi-Mission in TGE
by Dave Young · in Torque Game Engine · 10/07/2006 (4:21 pm) · 7 replies
Thought I'd post a hook out here for the topic of instancing a mission in TGE. I've searched to see if anyone has done any pioneering in this area, seems sparse.
Some other game engines support instancing, and it is not immediately clear how to string it up in TGE without 'empty' mission servers waiting to server a mission instance. We would like to put something like it in the MMOKIT someday and are beginning the research on it. I know Dreamer has begun researching this as well.
This might be part and parcel, but it would also be neat if we could get TGE to serve multiple missions at the same time from the same server .exe. Understandable that it is easy enough to launch other dedicated servers listening on different ports, but it is the possibility that is intriguing.
Any thoughts?
Some other game engines support instancing, and it is not immediately clear how to string it up in TGE without 'empty' mission servers waiting to server a mission instance. We would like to put something like it in the MMOKIT someday and are beginning the research on it. I know Dreamer has begun researching this as well.
This might be part and parcel, but it would also be neat if we could get TGE to serve multiple missions at the same time from the same server .exe. Understandable that it is easy enough to launch other dedicated servers listening on different ports, but it is the possibility that is intriguing.
Any thoughts?
#2
Is the global world your talking about just script global and/or C++ global? The reason I ask is because if the scripting language could be modified to support scoped execution where it only knows about what is scoped (defined in it) to it then it would be possible. I know Python can do that, but I have no idea how hard it would be to do that with Torque Script.
10/07/2006 (11:15 pm)
JW,Is the global world your talking about just script global and/or C++ global? The reason I ask is because if the scripting language could be modified to support scoped execution where it only knows about what is scoped (defined in it) to it then it would be possible. I know Python can do that, but I have no idea how hard it would be to do that with Torque Script.
#3
However, I'm sure it can be done. I'm just saying it'd be a lot of work, and I'd rather just spend the extra dollars on additional hardware -- or even just additional processes on the same hardware.
10/08/2006 (4:07 pm)
Torque uses globals both in script, and in C++.However, I'm sure it can be done. I'm just saying it'd be a lot of work, and I'd rather just spend the extra dollars on additional hardware -- or even just additional processes on the same hardware.
#4
(http://www.garagegames.com/mg/forums/result.thread.php?qt=23589).
Clicked on your name, saw this post.
I have just finished adding in support in Linux for a forking version of a dedicated server.
It starts, loads the mission, and runs, and listens for a signal (or, alternatively a request to it's embedded internal HTTP server). When is receives a signal, it forks, re-initializes a few mutexes, re-initializes a few internal subsystems to restart their threads (asynchronous network thread, internal IRC client, internal embedded HTTP server, etc.), and then rebinds it's UDP to a new port.
The parent process and child process share everything "mission based", but you don't have to worry about any other process state -- fork() and Linux CoW mechanism handle all of that for you.
I don't know how you would do this on Windows.
07/13/2007 (10:36 am)
Heh. I had just answered your other thread Dave(http://www.garagegames.com/mg/forums/result.thread.php?qt=23589).
Clicked on your name, saw this post.
I have just finished adding in support in Linux for a forking version of a dedicated server.
It starts, loads the mission, and runs, and listens for a signal (or, alternatively a request to it's embedded internal HTTP server). When is receives a signal, it forks, re-initializes a few mutexes, re-initializes a few internal subsystems to restart their threads (asynchronous network thread, internal IRC client, internal embedded HTTP server, etc.), and then rebinds it's UDP to a new port.
The parent process and child process share everything "mission based", but you don't have to worry about any other process state -- fork() and Linux CoW mechanism handle all of that for you.
I don't know how you would do this on Windows.
#5
Personally, I always envisioned having a "server manager" application (TGB would actually work pretty nicely for this!) that handled all of the server instance management work, and also acted as a centralized index of current server status, workloads, and available resource packages (what server platforms are under/over utilized, etc) to dynamically load balance your performance.
With a backside database connection for persistence, your players would basically login to the authentication server, query the database for current "world location", and then do a lookup through the server instance manager to determine which instance to connect to.
The server instance manager would receive periodic load reports from existing server instances, as well as direct standup requests due to "game play" (very loose term there) for when a new instance that isn't currently in the game world environment are needed.
07/13/2007 (10:42 am)
"on demand" is an interesting way of approaching this, but I'd suggest taking a look at having instance servers stood up and ready to go, and if you can data mine your general demand over time, you might even be able to stand servers up ahead of time based on general user flows to various missions vs time.Personally, I always envisioned having a "server manager" application (TGB would actually work pretty nicely for this!) that handled all of the server instance management work, and also acted as a centralized index of current server status, workloads, and available resource packages (what server platforms are under/over utilized, etc) to dynamically load balance your performance.
With a backside database connection for persistence, your players would basically login to the authentication server, query the database for current "world location", and then do a lookup through the server instance manager to determine which instance to connect to.
The server instance manager would receive periodic load reports from existing server instances, as well as direct standup requests due to "game play" (very loose term there) for when a new instance that isn't currently in the game world environment are needed.
#6
I thought about per-forking a pool, but even that seems unnecessary. The child server is ready to go within milliseconds (in fact, for a small mission representing a small space, it takes < 10ms).
In my implementation, the parent is never actually used as a server (i.e., no clients connect), so, it's always in this pristine steady-state. Also, it keeps track of the processes it fork()'s and does some management/monitor'ing of them.
I have yet to add in the facility to do so, but this parent process will also report relative load to the management app (which already exists). The management app. will ultimately decide which parent it will next use to create new child instances.
07/13/2007 (11:25 am)
"On demand" on Linux, at least with this approach, is as fast as having pre-spun-up servers. fork() is awfully darn cheap under modern kernels.I thought about per-forking a pool, but even that seems unnecessary. The child server is ready to go within milliseconds (in fact, for a small mission representing a small space, it takes < 10ms).
In my implementation, the parent is never actually used as a server (i.e., no clients connect), so, it's always in this pristine steady-state. Also, it keeps track of the processes it fork()'s and does some management/monitor'ing of them.
I have yet to add in the facility to do so, but this parent process will also report relative load to the management app (which already exists). The management app. will ultimately decide which parent it will next use to create new child instances.
#7
07/13/2007 (11:27 am)
Does sound like a good strategy :) 
Torque Owner J "hplus" W
Everything is global scope in Torque -- think for example of all the arrays! You'd have to find a way to separate out the entire global context into a separable and instancable concept. Sounds easier to just spawn another process.
For games that support instancing, typically you just add another server process per instance. Having them hang around un-used when not used just isn't that bad, because you have to plan for peak capacity anyway. If you want a server to switch which level it servers based on need, that's not very hard (look into the level cycling code, for example). The idea would then be that you have a central server which decides how many instances are needed of what levels. When a new instance is needed, it contacts the next server on its list of empty, available servers, and tells that server what mission to load. Then the central server talks back to the clients, telling them about the instanced server.