T3D as a client only for use in a 3rd party server backend

#1 Greetings!

Yes, even in single player T3D uses a client/server under the hood. In this case there are internal shortcuts it uses so you're not actually going over a network stack.

Everything that makes use of NetObject relies on T3D's networking methodology. You may be able to write your own NetConnection class to simulate what Torque does with your own networking back end. Or rewrite how network updates happen in general. The way T3D does networking permeates through all of the game play classes, so you may want to rewrite those.

If you want to learn how T3D behaves as a client you could trace through what it does when connecting to a dedicated server.

You could also allow T3D to remain in a single player mode and work with a non-T3D server in another way. For example, write the code to communicate with a web server to move objects around and validate what the user does. In this case you're not relying on T3D's networking for its security and game play checks. T3D operating in a single player mode is more resource intensive then when in a pure client mode, but it is doable.

- Dave

#2 I was thinking that you could use the Torque Server to broker data to the rest of your server apps. So you get the benefit of Torque networking and just talk to the server app on your server using your other tools/servers you write.

You can also pass messages back and forth between server and client and vice versa if the object data sent is insufficient.

#3 @Gnometech
my aim is to not make torque to double work, since even in single player mode torque still needs to talk to its local server.

but like you said, i can just do the singleplayer mode then from there adapt to talk to my own server, but am confused if it will break things since torque rely on its server for pretty much everything, so i am afraid
that still need to do double work? code my stuff in torque server plus do my own backend logic too?

the purpose is to lighten up the client, this deal seems confusing, lol


@Frank
not following? can you elaborate please.

#4 T3D can run on a server as a server for the clients. On the server you can communicate to PHP, Python, C code, etc directly. So the T3D server acts as a data broker to the rest of your server app. Or it could be a highly modified T3D server. That way you are not having to redesign the T3D client.

That is one of the reasons I built ScriptT3D. I can run the T3D server on a server with Python bindings. Although I have not yet tested this. I am thinking about rewriting that interface again. Also with Python bindings the client can talk to servers using Python network libraries if I choose.

#5 Isee what you mean now.

#6 @pilotcap232:
It really depends on what you would like to do with your own server. If you would like your own server to handle game logic, physics, object motion, collision detection, etc. and just use T3D for its rendering and user input, you would likely have to replace all of T3D's game classes with your own. There is nothing wrong with that, it is just a lot of work depending on the type of game you are building.

Another approach is to still use a Torque 3D server for all of your physics, object motion, collision detection, communications with the client, etc. You would then extend the T3D server to communicate with your own servers for game logic (such as checking for success on using a skill), trading between players (handling inventory), communication between "zones", etc. With this approach you can take advantage of what is already in T3D. I believe this is what Frank was talking about.

If you went with this second approach, you do need to keep in mind that the network updating is more geared towards a FPS game. You may be able to get away with fewer updates between the client and server, push more work to the client, etc. depending on the type of game you are making.

- Dave

#7 @David,
Is there a simple way to control how fast the network data is updated with the default setup?