Dedicated server examples
by Chris · in Torque Game Engine Advanced · 01/18/2009 (2:37 am) · 7 replies
In the past with 3d engines I've been happy to write my own dedicated servers, but with this game engine I would like to try out the built in networking and dedicated server but I'm having a little trouble finding good documentation or examples.
It looks like the default server stuff fires up as a thread in the client, and uses cs scripts to run. I would like to add another project to my solution and make it compile as a dedicated server.
It would also be nice if someone could point me to examples of how servers send movement packets to the client.
It looks like the default server stuff fires up as a thread in the client, and uses cs scripts to run. I would like to add another project to my solution and make it compile as a dedicated server.
It would also be nice if someone could point me to examples of how servers send movement packets to the client.
About the author
#2
1. Adding a npc entity on the server side that clients can see
2. Writing ai for that entity on the server side with no client scripts
3. Does Torque networking handle ranges? If your in a massive landscape does it xmit packets to players too far away to see things.
01/20/2009 (8:12 am)
Yes I figured out quite a bit, I need more information though - here are my main hang ups.1. Adding a npc entity on the server side that clients can see
2. Writing ai for that entity on the server side with no client scripts
3. Does Torque networking handle ranges? If your in a massive landscape does it xmit packets to players too far away to see things.
#4
Torque uses culling by default. You set the distance a person can see in the sky object in the mission editor.
01/22/2009 (2:20 pm)
1 and 2 are yes. Look up aiGuard or Advanced Ai Guard resources. I believe the advanced uses A* pathfinding but I'm not sure.Torque uses culling by default. You set the distance a person can see in the sky object in the mission editor.
#5
Objects can also be set to be scoped always so regardless they get updated, also large objects get scoped more as they don't fit into one or more zones.
01/22/2009 (4:20 pm)
Yes Torque networking handles ranges as you class them it splits the world up into zones and then server side objects are split up according to which zone they fit into.Objects can also be set to be scoped always so regardless they get updated, also large objects get scoped more as they don't fit into one or more zones.
#6
You're already using both a client and a server even when you load up a simple, single-player game example like the FPS starter kit (or whatever this is called in TGEA). Sure, they're running in the same instance of the game, but they both still exist.
Torque is derived from an engine that was designed with internet multiplayer via dedicated servers as its focus, so you actually don't need to do anything out of the ordinary to make it happen.
"1. Adding a npc entity on the server side that clients can see."
Realistically, if you've added an AI entity to your scene, this is how it was done, even in single player. Every ShapeBase-derived object type is designed to handle basic network "ghosting," which is what we call the process by which the server informs clients about the status and position of various objects in the world.
Health, position, velocity, animation state, all of these are transmitted to clients as needed to keep them up to date. There are 2 specific functions which handle the sending of this data (and 2 more for receiving it), and any new data you wish to send must be added to them. If you open up the Player class, you should look for these functions:
1) Player::writePacketData -- sends an update packet to the controlling client.
2) Player::readPacketData -- reads that packet.
3) Player::packUpdate -- sends an update to ghosts on all clients; more general information that every client needs.
4) Player::unpackUpdate -- reads that packet
You'll see that the first line in each of those is a call to the parent class for the same function. If you don't find what you're looking for here, head back to ShapeBase and see what gets sent there. And follow the chain if needed.
Anyway, that's how data gets sent from the server to clients to keep them in sync. As you can see, the controlling client gets more info about an object than the other clients do, since it needs more detailed information about position, velocity, energy state, etc. in order to predict in a way that's not jarring to the player. The other clients get just enough to predict motion and keep the animations in check.
"2. Writing ai for that entity on the server side with no client scripts"
In a client-server architecture, the server is always in charge. Basically, you could write AI scripts on the client, however when the entity began moving around on the client and not on the server, the server would simply constantly override the client. The result would an an NPC that continually started to walk away to perform some function and was immediately snapped back to its starting position by the server.
In other words, not only can you do it the way you've asked, there's realistically no other reasonable way to do it. As others have stated, there are lots of great examples available; I just thought it might be helpful to explain how things work internally in the engine.
3. [regarding scope]
Scoping is built into the engine, and you can modify how this is determined to suit your specific needs. Basically, objects far enough away to no longer be seen are no longer "in scope," and clients stop getting updates on them.
If you wanted to, for example, remove objects from scope which are cloaked (making it impossible for clients to cheat by looking up their ghosts via client scripts and reading their position values), this can be done.
If you want to completely disable scoping for an object, making sure it is always updated to clients regardless of position, that can also be done.
01/24/2009 (4:25 pm)
In Torque, the client-server architecture is not optional.You're already using both a client and a server even when you load up a simple, single-player game example like the FPS starter kit (or whatever this is called in TGEA). Sure, they're running in the same instance of the game, but they both still exist.
Torque is derived from an engine that was designed with internet multiplayer via dedicated servers as its focus, so you actually don't need to do anything out of the ordinary to make it happen.
"1. Adding a npc entity on the server side that clients can see."
Realistically, if you've added an AI entity to your scene, this is how it was done, even in single player. Every ShapeBase-derived object type is designed to handle basic network "ghosting," which is what we call the process by which the server informs clients about the status and position of various objects in the world.
Health, position, velocity, animation state, all of these are transmitted to clients as needed to keep them up to date. There are 2 specific functions which handle the sending of this data (and 2 more for receiving it), and any new data you wish to send must be added to them. If you open up the Player class, you should look for these functions:
1) Player::writePacketData -- sends an update packet to the controlling client.
2) Player::readPacketData -- reads that packet.
3) Player::packUpdate -- sends an update to ghosts on all clients; more general information that every client needs.
4) Player::unpackUpdate -- reads that packet
You'll see that the first line in each of those is a call to the parent class for the same function. If you don't find what you're looking for here, head back to ShapeBase and see what gets sent there. And follow the chain if needed.
Anyway, that's how data gets sent from the server to clients to keep them in sync. As you can see, the controlling client gets more info about an object than the other clients do, since it needs more detailed information about position, velocity, energy state, etc. in order to predict in a way that's not jarring to the player. The other clients get just enough to predict motion and keep the animations in check.
"2. Writing ai for that entity on the server side with no client scripts"
In a client-server architecture, the server is always in charge. Basically, you could write AI scripts on the client, however when the entity began moving around on the client and not on the server, the server would simply constantly override the client. The result would an an NPC that continually started to walk away to perform some function and was immediately snapped back to its starting position by the server.
In other words, not only can you do it the way you've asked, there's realistically no other reasonable way to do it. As others have stated, there are lots of great examples available; I just thought it might be helpful to explain how things work internally in the engine.
3. [regarding scope]
Scoping is built into the engine, and you can modify how this is determined to suit your specific needs. Basically, objects far enough away to no longer be seen are no longer "in scope," and clients stop getting updates on them.
If you wanted to, for example, remove objects from scope which are cloaked (making it impossible for clients to cheat by looking up their ghosts via client scripts and reading their position values), this can be done.
If you want to completely disable scoping for an object, making sure it is always updated to clients regardless of position, that can also be done.
Torque 3D Owner Cai Yundong
game.exe -dedicated -mission scriptsAndAssets/data/missions/MissionName.mis