T2D Networking: Will all T2D clients perform the *exact* same?

#21 1000MS / 32MS tick time -> 31.25 updates per second over the network.

There is no reason stock T2D physics should NOT be usable over the network in this manner. If I want to have 1000 clients with stock physics I should be able to do that. I wouldn't, but I should have that option.

Basically what you're saying is the majority of T2D will not have realtime networking, and that kinda sucks :(

#22

Quote:
A different update rate should not change the physics output, if the result is a different one, then the physic system would definitely be bugged.

Exactly my point.

Check out this screenshot:

I had a projectile spawned over and over again from the exact same place and had the exact same force applied to it yet it landed in much different places on the same computer. The first collision was WAY out of place because I switched from window-mode to full-screen (which is a huge T2D bug) and the rest of the numbers are just plain off... (some by as much as 10 units which us HUGE)

In it's current state, the physics engine is mostly useless. Unless I'm confused about something, a projectile shot with the same force should land in the *exact* same spot every single time...

I realize a solution to my game is to rewrite the physics engine but that seems like extra work I shouldn't need to do.....

#23 Uuuhh ... thats indeed bad.
Somehow I'm happy that I had to program coulomb forces myself ... otherwise I'm sure I would have smashed my notebook or pulled my hairs out ...

This definitely need a deeper look. As soon as I understand the torque source good enough I'll try my luck ... :-)

#24 You could always implement table lookup like old-schools games that couldn't afford the processing time of floating point calculations on older hardware.

#25 Hopefully somebody does something because I can't (eg. don't have the knowledge) fix it by myself.... (and I can't make the game I'm trying to make without reliable, basic, physics)

#26 Where do you need physics other than projectiles?

#27 Well, in my specific game I want to have anti-air turrets and several different kinds of projectiles.

The anti-air, for example, would activate when a projectile got close enough and then it would fire a anti-air projectile trying to destroy the other projectile. It would *very* important that it function that same way on all machines... (so if the anti-air projectiles missies the other projectile it is that way on all machines).

Also a lot of projectiles won't be standard "shoot at 45 degrees with 400 force". The projectiles might explode after 2 seconds or spawn new-projectiles mid-flight (remember the Scorched Earth MIRV bomb?). Stuff like that....

For other games the physics might be important for bouncing a ball (eg. multiplayer pong) or perhaps an Arkanoid clone.

#28 Well, if it's only some projectile physics it should not be a problem doing it without the standard physics system. Do the calculations yourself in some function. Just do it in a way that is the same on every computer. Precalculate a path before the projectile is actually fired and then let the projectile follow this path. Something like this. There are lots of ways to get this right.

Quote:
The projectiles might explode after 2 seconds or spawn new-projectiles mid-flight (remember the Scorched Earth MIRV bomb?). Stuff like that....

That is not related to the physics system. Should not be any trouble.

#29 I think that asking for realtime networked physics is the wrong thing to ask for. step back and think of the "real" problem you are trying to solve, and if there is a nice way of getting there.

For instance, assuming that you REALLY want is for the game on different computers to do the same stuff (bullet bounce, etc) the thing to do, would be to have one client be the master, where all the physics calculations are made, and the other clients be slave, with *no* physics calcs being done, only updating the items positions every 1/X seconds.

#30 Ok, let's say I do the calculations on the server... what functions in TGB would I use to draw the path of the sprite? Also, see my question about which method is better above. I'm assuming I would need to do a time based method to insure that everything is drawn at the same place... I also assume I need a TGB function that insures execution at a set interval (onTimer?)...

Finally, does anybody have any links to basic ballistic trajectory equations? (for non math majors :))

#31 I don't think you have to do the calculations on the server.
I have hacked something together for you. That's how I would about imagine it:

/* this functions creates a path where %iterations is the number of path points. */

function createProjectilePath(%pathObject, %startPosition, %velocity, %gravity, %wind, %projectileMass, %iterations)
{
	%pathObject.length = %iterations;
	
	%currentPosition = %startPosition;
	
	%gravityVector = 0.0 SPC %gravity;
	
	if(%projectileMass == 0)
	{
		warn( "Projectile mass must not be equal to zero!");
		return;		
	}
	
	%windVector = (%wind / %projectileMass) SPC 0.0;
	
	for(%i=0; %i < %iterations; %i++)
	{
		%pathObject.point[%i] = %currentPosition;
		
		%currentPosition = t2dVectorAdd( %currentPosition, %velocity  );
		
		%velocity = t2dVectorAdd( %velocity, %gravityVector );
		%velocity = t2dVectorAdd( %velocity, %windVector );
	}
}

// prints the path
function ProjectilePath::print(%this)
{
	echo("Length of path = " @ %this.length);
	for(%i=0; %i < %this.length; %i++)
	{
		echo(%this.point[%i]);		
	}	
}

/* this function create 1 reference path and 100 test paths and compares
    each of the test paths to the reference path. In my test there never was
    a difference (which is quite obvious). It should be the same on every
    machine as they all get the same numbers for the calculations (in contrast
    to the numbers the physics system works with).
*/

function testPath()
{
	echo("test path");

	%path = new ScriptObject()
	{
		class = "ProjectilePath";
	};
	
	createProjectilePath(%path, "0 0", "10 -20", 1, 0.4, 1.0, 100);
	
	for(%i = 0; %i < 100; %i++)
	{
		%path2 = new ScriptObject()
	   {
	   	class = "ProjectilePath";
	   };
		
		createProjectilePath(%path2, "0 0", "10 -20", 1, 0.4, 1.0, 100);
		
		for( %a = 0; %a < 100; %a++)
		{
			if( !(%path.point[%a] $= %path2.point[%a]) )
				echo( %path.point[%a] SPC "not equal to" SPC %path2.point[%a] );			
		}
		
		%path2.delete();
	}
	
	%path.delete();
}

You can let the projectile object follow the path with setPositionTarget() for example. Whenever the projectile reaches a path point you can use the callback to set its target to the next path point.

This would be one option of doing. There may very well be more elegant ways.

-Michael

#32 Thanks for the example!!

How would I move the projectiles? I understand setPositionTarget will allow me to do a callback but it won't actually move the projectile... I'm guessing I could use moveTo but I'm not sure thats the best way to do it...

#33 Oh, sorry, yes I ment move to.

#34 I'm going to give an anecdotal mini-story regarding networked physics to help describe this issue, and (hopefully!) explain why the "it should work the same on all computers, all the time!" concept isn't (unfortunately) a realistic one:

[anecdote on]
During development of "Tube Twist", 21-6 Productions integrated ODE (an external physics library) into TGE, and it worked extremely well for them. While their game uses TGE, and therefore has both 3-Space and full TGE networking, it's mostly a 2-D type world, so it's an applicable discussion to this topic.

They originally planned both cross-platform (Windows, Mac), as well as the ability to have a level editor that allowed users to make their own levels and distribute them, but they ran into a problem: Even with their relatively simplistic use of a proven and stable physics library, they were not guaranteed that a puzzle made on a windows platform using the level editor would solve in exactly the same way on a Mac platform--and they even found out that different versions of cpu's on the same OS solved differently--all using the stock physics library!

The root reason for this in their case had to do with how CPU's implement floating point rounding--basically, it turned out to be a signifigant digit problem in that the underlying OS's were handling very low signifigance digits differently, and the error was cumulative across time, causing divergent situations.

Unfortunately, the solution (after several months of research and dev attempts to resolve the situation) was to remove the level editor capability--because they couldn't fix this issue in code without basically emulating the entire set of math operations in software instead of letting the hardware do it by default.

[anecdote off]

The reason for that little story is to point out a couple of things:

1) The challenge of real time networked physics in any platform/engine has not been solved by anyone in the industry, including the simulation (non-gaming) space. Tech is advancing, but any game/product that appears to have solved it is actually doing a whole lot of smoke and mirrors behind the scenes--similar to what Michael describes above--and/or run endless tweak test runs to carefully limit their conditions for the simulation to stay synchronized and/or not matter.

2) Gameplay affecting physics is still quite a challenge--again, tech is advancing and you are seeing better and better implementations (see "Black" for example, although that much R&D and budget to produce 8 hours of gameplay demonstrates the problems IMO), but many projects are best guided by limiting their gameplay affecting physics to the lowest feasible denominator whenever possible.

3) TGB has a great physics engine, but there are weaknesses that can be exposed rather easily--and that's going to be the case regardless of what physics engine you work with. When you add networking and require guaranteed accurate synchronization and response across multiple clients, at this stage of industry technology you are probably best served by re-designing your gameplay.

#35 Ok, so what you're saying is that games like Worms, Gunbound, and Scorched Earth are all using some kind of method to hide the inaccuracies of networked physics? Are they all doing something like Michael mentioned above?

#36 Or they designed their gameplay and implemented their physics to extremely specific situations (including very detailed threshold synchronization issues) that a more general "engine" such as TGB isn't going to do for you out of the box--exactly becuase they would be specific to gameplay and therefore not appropriate for a tool aimed at many game types.

#37 Well, Stephen; You still have to admit that there's "something wrong" when the exact same setup results in wildely different end results (see John Klimeks post with the console screenshot).

In my own tests the t2d physics still seem to be slightly too dependant on framerate and I _would_ consider this a "bug". There will always be some difference due to rounding errors, I agree with that. I'm not at all worried with networking, I just want stable physics that isn't so dependant on the current framerate.

As an example; In my tests I had one sprite (basically a ball) with rigid collision response bouncing around in a tilemap, this worked just fine until I started Fraps to record some video, the framerate of course dropped and as a result the ball started to jump around frantically (even if I first let it settle down on the ground before starting the recording).

Basically; The physics work okay, but there are issues with it being too dependant on framerate. Unless of course I just missed some setting somewhere... =)

#38 In terms of the games mentioned from Worms to the Ballistic turret game for the 2600 to Scorched Earth have a limited level size which would allow a software implementation of table lookup to be implemented without a lot of work (especially not as much as a 3D solution as Stephen mentioned with ODE). If creating random terrain, you would need to make sure that it (and the destruction zones) would also conform to this same software scheme. I"m reminded specifically about the Doom projectile code which used the finite levels and positioning of walls (and z-ordered height levels). It was a finite world which they could use a table-lookup to calculate consistent look-up for variant processors (386, 486, those shiny new Pentiums, etc).

I wouldn't even know where to start working on this in TGB, though.

#39 I dont need extremely accurate physics. TGE has realtime networking, including the networking of it's physics. While it's not acurate enough to do mathematically precise simulations, it serves its purpose in emulating a physics environment being replicated over multiple clients, which is all that's neccessary for a game.

You're not going to do the same for TGB?

#40 Hopefully they will.
The above console outputs with a +- 10 for x and y on hit is definitely quite a problem ... On the same PC I would have had assumed that it performs always the same not mather if it calculates at 60 fps or 30 as the state on the simulation points should always be the same due to time_difference based implementation (which I assumed any single threaded app uses?!).
ut from the results one should assume that it only performs physical calculations for the discrete moment it updates and ignores the time passed in between (or it uses a fixed time value based on your set physic update rate which would be as worse in a single threaded environment where the update can be pushed to a later execution if something else is going on)