Torque2D networking, how is it?

#1 From what I understand is that the only thing missing in T2D compared to TGE as for networking goes is the lack of a move manager. Everything else is still there its just all the typical object types that are usually networked don't exist on T2D such as Item, Static shapes, Interiors, Water, Terrain, Vehicles, Player, and etc.. The only thing that is actually exposed to the network subsystem right now is the SceneObject class and it's blank just like the fallback NetObject packUpdate/unpackUpdate() functions.

Practicing01 had no problem getting a network connection going the same way you do in TGE and T3D and a networked game going, but he's just using the TorqueScript RPC functions which seem to work just fine as well.

Now keep in mind that the network support script code that goes on TorqueScript side of things of course is also missing in stock T2D, so you'll need to grab that from TGE that's responsible for starting the server, accepting incoming network connection requests from clients, and such.

#2 Every now and then, someone asks about real-time networking in T2D. Here is a reply from Mich on the subject:

Quote:
Simple answer here. Torque 2D does not have real-time networking. If your goal is to have multiplayer like Terraria, this would require a decent amount of time and C++ coding. It's not as simple as just updating position over the network. First, you'll have to do all the basic client/server connection stuff. Next, delivery of data to both ends. Then, you have to deal with providing information based on the location of each player. If they are both at separate ends of a map, you do not want to render, handle logic, and calculate physics for all the "empty space" in the middle. Empty space being stuff neither place can see. T2D's rendering already handles that automatically.

Finally, the hardest part, is handling physics. Box2D is not setup for networking. It's a single world simulation. It takes input in the way of bodies, forces, and joints. It outputs the the updated position, velocity, and collision responses. For the sake of networking, you will have to hotwire the physics or use a custom solution. The server would be the Box2D authority. It runs the simulation. Clients would not run their own Box2D. They would just update based on what the server is telling them.

Getting functional, real-time networking is no trivial matter.

The event based networking T2D does support is detailed in this tutorial (along with providing the scripts you need):

github.com/GarageGames/Torque2D/wiki/Network-Tutorial

#3 Looks like i got some work to do. It's going to be a multiplayer based project, and I really wanted to use Torque2D as I'm familiar with the torque engines ever since I started programming.

Thanks for pointing me in the right direction. The hardest part imo will be the physics handling hehe.

@Mich (since its his quote) or Mike, how do you feel about the subject of having the client simulate the physics as well as the server to keep it interpolating and stuff?

#4 Got the connections established. Off to adding UDP BitStreams and the like soon D:

#5 How difficult is it looking to you? If you really think you can pull it off, what approach are you taking? Is this something you would like money for? Would be cool to have you on irc :).

#6 I'll pop in on the IRC when I can.

I don't want money for this, it shouldn't be *that* much work for at least what I will need from it. I'll most likely throw the code up on GitHub as well. The hardest part will be ensuring that the legacy ghosting system works again and properly.

I plan on exposing this to script so I can script udp packets to be sent across the network as well.

#7 Just a point of insider voice:

The datablock system in Torque 3D and legacy TGB was the back bone for networking. When Torque 2D MIT was being developed, the datablock system was removed completely. This was the best option at the time, which kind of makes your job easier and more difficult at the same time. My suggestion is to come up with a custom solution that factors in the box2d simulation. Just trying to merge T3D into T2D is a losing battle.

#8 I wasn't planning on merging, but I am leaning towards adding a custom ghosting mechanism. I always disliked the datablock system anyways, I don't know why but I just never liked it :P

I don't have a ton of experience in this stuff (most of my networking knowledge rests on the multiplayer project that I was involved with in MB, but regardless I am going to give this a shot)

Thanks Mich though for the tips :)

#9 Also, a disclaimer, the way I design it might not be the best implementation or something that an individual does not like/prefer, but this is how I will be using it in future projects as well.

I will be working in a public github repo, and will make a new thread for a status thread once progress will start coming along. For now:


https://github.com/JeffProgrammer/Torque2D/tree/Networking

#10 Okay, every sceneObject and its children are now children of NetObject instead of SimObject, and ghosting works!