Physics out of the box - Does Torque have it?

#21 @Andy Hawkins
One of the simple reasons for not having a support ticketing system is economic. We would either have to charge scalable levels of support (which can be very expensive for developers if we end up almost being contractors to get some bit of functionality into their product) or else raise the core price of the engine significantly. Another reason is informational flow, though. There are a lot of people using our engines and only a small number of us available to try to support them, so the forum community is one of the best ways that a large number of eyes target your problems.

There are a number of problems with this approach, of course, but it is the best one that is affordable for us and for the majority of our users. We do offer specialized support contracts on some projects when we can, but they are out of the budget range for many of our users.

#22 @David - yes I was talking to a colleague and I realised this a few days ago. I think it's a great package and the price point is awesome!

However I was thinking that while the core team at GG develops new products perhaps the growing list of associates could take a more active role in supporting the users with technical issues.

#23 I do realize that responsibility comes with recognition, but if you've ever worked in support for software (especially source-based software where people can try to make it do amazingly strange things), that kind of seems like punishment for associates! ;)

#24 I'm just talking about the source engine based support stuff really. The community can handle the rest. Stuff like getting rigidshape back in and how to do it, getting graphics to load properly when loaded via GUI's - basically all the stuff I've asked for in the past that the community can't answer. Vehicle articulation springs to mind.

#25 Personally I don't think that Unity is worth it. $1500* (or ~$2k if you want to be able to use source control as well) per seat for basically a closed source engine doesn't seem very appealing to me.

* - Though it has the indie license for $200, which isn't eligible for the source control package ("pro" license is required). Still though, $200 for an indie license of an engine with no source is pretty crazy IMO. If you need something done in the base engine you're pretty screwed, and you don't get the assurance that even if the Unity guys bite the dust and disappear, at least you own the source and can do whatever with it, forever after.

Anyone remember what happened when Google Video shut down? The whole "Hey our auth servers are gone, so you're basically out of luck, thanks for all the cash, here's a $5 gift certificate you can use at our affiliates (i.e., give us the money)." Having that happen with an engine you spent $2k (per person on your team no less!) on doesn't seem like something you want to chance with IMO.

Implementing PhysX (even networked...) isn't *that* terribly difficult to get the basics in. Ragdolls are fairly easy (basically just bodies + joints for each bone in your skeleton), especially if you get the PhysXNotify and NXUStream stuff implemented (i.e., so you can load PhysX XML and have it create everything for you, which is best used by using the PhysX Max plugin to set everything up, although there is some auto-ragdoll creation stuff in Rocket and PhysXViewer, and you can set up such a system relatively easily by having a separate DTS that has a bunch of sub objects representing primitives or convexes for each bone).

Edit: Also, I don't see the point in determining your engine by what physics library it uses (e.g. Unity with PhysX) given that with something as complex as PhysX with all its features, you really want to be able to implement them however you wish. What happens with Unity when PhysX is upgraded and gets, for instance, height field fluids? I assume you're going to just have to wait until the Unity devs decide to add it(assuming they do so). No such obstacle if you have the source, though you have to do some *work*. Seems incredibly limiting to say "I want a good physics library" then deciding to let someone determine what/where/how/why you get to use and access it, simply because you can't look at the source yourself.

#26 Exactly why I evaluated, then rejected Unity as a solution Ross. Without the Source Code to the engine, there will always be the threat of running into the "brick wall" where you want to do something that Unity just can't do. Not to mention, if you're planning on deploying to Windows you'll have the issues of developing in a different environment than your deployment environment. I will call anyone crazy that thinks that Mac-to-Windows translation process will be infallible.

#27 @Mark, exactly. Not to mention I find their whole source control situation distasteful... Having to pay $500 per seat for something that is only needed because they broke regular source control seems...meh.

#28 Thanks for the extra info guys. I'm glad you found that out about Unity because I was starting to look at it, as a viable solution. However I've found that the more I program Torque the tamer it becomes (and I become).

Like I said before, I've invested time and money in Torque so I need to see it turn some profit for me.

Thanks again guys!

#29 @Andy, what sort of game are you planning(for instance, real time/turn based, single/multiplayer, LAN/Internet)? I'd be happy to give you some tips for improving the PhysX resource more towards what you'll need(though I honestly don't remember exactly how it was set up, since I rewrote it almost entirely for our projects...).

#30 @Ross - it's a real-time arcade shooter with ground troops doing command and conquer things under AI control. When the enemy or player blow things up (especially buildings) the debris needs to hit them and roll realistically.

#31 @Andy, is it single player or local multiplayer only? Or over-the-net multi? The first case will work well with the PhysX resource as it's currently set up, but if you want a proper server/client set up it will be a bit of work. You'll also be able to get away with doing more gameplay-affecting physics if its not true networked multiplayer (fluids, cloth etc.).

#32 @Ross - single player will suffice. I have a plan for multiplayer later but I will rebuild it then.

#33 Right so, the current resource should work pretty well for you then (it basically assumes a local client).

#34 I have seen a lot of people state that it is difficult to do detailed physics in a multiplayer environment. I'd like it if someone could give an overview of why it's difficult (ie. what are the major hurdles to overcome)?

#35

Quote:I'd like it if someone could give an overview of why it's difficult (ie. what are the major hurdles to overcome)?

Because unless the client and the server predict exactly the same thing, then it ends up looking like a hideous mess instead of something reasonable.

Your client bounces a ball off the corner of a box, but because the accuracy of floats on your system are capped at 5 significant figures [or your client is missing one minor impulse on the ball because of lag, or ...], you're off by a tiny fraction of a radian, which causes the ball to bounce off the corner of a box in a *completely* different direction to the direction the server did. Whaddya do now?

It's usually impossible for the client and server to predict exactly the same thing because:
1) Your own client knows your own inputstate for the next tick to predict it, but the server doesn't know it yet
2) Once the server does know it [account for lag here], it has to take into account the fact that when you did it, it was a while ago
3) The server then has to send stuff to all the other clients [account for lag again here]. Now all the clients are trying to predict what's happening based on [2*lag] ago.

Clients not predicting stuff leads to ice skating [for anyone that ever played quake1 long ago]. Clients predicting stuff leads to clients being wrong.

It's a bit of a charlie foxtrot. Couple interesting links: www.gaffer.org/game-physics/networked-physics, developer.valvesoftware.com/wiki/Lag_Compensation

Gary (-;

#36 Edit: Gary is spot on ;)

@Mark, a lot of what is hard about networked physics comes down to the issue of determinism. If you have gameplay-affecting (this is an important distinction*) physics and those interactions will not be deterministic between the server and every client, you will run into problems. This will affect everything you decide to do in terms of your client/server set up for your physics solution, such as the type of simulation you're doing (are you doing it on client only, server only, or client and server for instance). Since you can essentially count on a small amount of determinism, usually correcting to the server's representation is enough. The problem with this is that you don't want to be sending the parameters of every physics body in your sim over the network (which would defeat the point of having a sim on the client itself, as well as not work on any but the best Internet connections), so you have to work out some sort of compromise for syncing critical interactions. If you don't, eventually the state of the physics simulation on the clients will diverge from that of the server, and your gameplay will suffer (players will *see* things looking fine on their end, but be unable to interact in various ways because the server does not have those physics objects in the same state).

Typically what a lot of games do, is make the player representation "styrofoam" (as Glenn Fiedler (Gaffer on Games) noted at the Mercenaries 2-Networked Physics talk at GDC) so that physics objects in the world are affected by it, but nothing affects it. Most games simply don't allow the physics to influence gameplay very much :) (Note that Glenn is using a different client/server setup than the one I've described, and a different solution for networking it that leverages the fact that Mercenaries 2 is non-competitive (it's co-op).)

* - By "gameplay-affecting" physics, I mean elements in which the physics interactions directly influence the player. To take an example from Be The Dinosaur, in it we must allow the player to eat from the corpses of other dinosaurs. Dinosaurs are ragdolled when they die, which means that the ragdoll position on the server must in general match that on the clients. The reason is because when the dinosaur goes to eat from a corpse, the server is what's checking to see whether or not the bite "hit" the ragdoll. If the positions of the ragdoll are disparate from client to server, the client will be seeing an incongruous state (for instance, he could be standing perfectly over the dino, but not be able to eat because on the server, the dino's ragdoll is somewhere else, which would prevent the client from eating). Physics interactions that can move the player are also of this type (i.e., if you had a player and some large debris hit him and moved him around, the debris would need to be synced, otherwise the ghosted player on other clients would be in the incorrect position).

#37 Funny that both of us picked exactly the same guy to read and reference :-)

Gary (-;

#38 Thanks guys, that does answer a lot. I guess having "really realistic physics" in a multiplayer game is a case of "be careful what you wish for." It looks like it would be a long, delicate process to balance sending more info to the clients for accurate predictions with packet size and network load then?

#39 @Mark, pretty much. It's mainly about picking a scheme that fits your game. If your game is non-competitive, it makes things somewhat easier, because you can use a scheme in which your clients sometimes take authority over corrections for physics objects (this is Glenn's setup for Mercs 2). If you need the server to be always authoritative then things become slightly harder (especially in an environment with lots of latency). If you pick a good prediction/correction setup, you can usually get results that are "good enough" but for things like cloth/fluid/soft bodies, you're mostly out of luck if you want them to be gameplay-affecting elements.

#40 For anyone else following this conversation. Here's an interesting article about network physics that the aforementioned Glenn wrote.