Game Development Community

Move Class and Networking

by TheMartian · in Torque 3D Professional · 07/10/2013 (6:16 pm) · 4 replies

I tried looking around for this both this site and tdn and didn't really see anything.

When creating a new project (latest T3D with Project Manager 2.0) you have the option
for Move Class and Networking:

The options are Standard Move Class, HIFI Networking, and Extended Move.

Can someone provide an explanation of what is the difference between them and why would you
choose one over the other? Are there reasons to not choose one of them most of the time and why?


#1
07/10/2013 (6:28 pm)
Standard Move Class
- in general for Singleplayer Games/ it is the standard

HiFi Networking
- mainly for Multiplayer Games
-------------------------------
these 2 where in T3D even before it went MIT

only
Extended Move Class (was added)
- is used for the new input support
such as
Occulus Rift/ leap Motion/ Hydra

so if you decide your project to have Occulus Support
you have to go with the newly added Extended Move Class
#2
07/11/2013 (6:45 am)
J0linar was almost right except that Standard Move Class is used for majority of Single (offline) and Multiplayer (online) gaming modes. HiFi Networking is meant for racing games where the latency of the Standard Move Class isn't good enough.
#3
07/11/2013 (4:13 pm)
So if I have a 64 multi player map with fast moving projectiles from some of the weapons the standard move class is still fine?

But if I as a player and moving really fast (like in a car, boat, plane) I might want to choose HIFI networking.

Does it hurt to have the HIFI networking in the first example? is there some overhead that would lower the number of players I could support?

Thank you for the answers by the way, I figure this will help others too as there isn't much info on this particular area.
#4
07/11/2013 (6:09 pm)
Just from skimming the code, it looks like HIFI networking is designed to keep the client sim as sync'd to the server as possible. It seems to process moves at a faster rate and also implements some clientside "catch-up" techniques. There's probably some additional overhead associated with all of this.

I'd be a bit wary of using it in any kind of serious project because the code looks unfinished and it's definitely untested. The standard move class is sufficient for most things.