Well, I finished my Kongregate entry recently, and I was wondering if anyone would like to see a tutorial set detailing the game’s construction from start to finish. I guess this movie will say it all: http://www.youtube.com/watch?v=7jFi6ft_Nco
Yes very much so. This has a huge problem that i just cannot seam to get my head around and thats how to deal with large space environments and floating point problems. Even if it’s not a complete tutorial from start to finish i would love to know how to deal with this problem in a proper manner.
Yes it will be a useful tutorial, i like your game.
Well, the floating point issues are usually due to distance from 0,0,0. If your objects, overall, are reasonably-sized, you can make the illusion of a space system in the inner 5,000 units or so. The main trick is to just make your objects around .01 units large, so the systems and spaceships are proportionately large.
I haven’t had many responses about the game, though, so I’m not sure I’ll be making the set. It’s only been a scattering of a few people.
That won’t work. Although space is a lot of empty stuff, when you do collide with something it’s rather important. PhysX, does not work at those scales due to floating point resolution in the opposite direction. People attempting to make real-world scale pinball games run into this all the time.
If you tried to transpose scales so that a of FP value of 1 = .01m, what you would find, is that objects that jittered at 10k, will now jitter at 10k * .01 from the origin.
In Game Programming Gems 4 there is an article entitled : “Solving Accuracy Problems in Large World Coordinates” Certainly worth reading.
There are a good number of solutions if you search about, but they boil down into two categories.
- Discrete local coordinate systems.
- A floating origin centered on your camera.
Yes that’s exactly what I’ve been wanting to learn. I’m going to check out programing gems 4 and give it a read. Are there any other good resources on these topics?
I’ve seen a good bit of information other than the GPG article yes. Last I remember reading was someone’s doctoral thesis from 2008 or so which presented I think a mix of floating origin with some interest management thrown in. There are others who use an octree or a portal based system to segment discrete local references on the fly…
It’s just a matter of using google to filter out all the ‘why is my character shaking’ and ‘dude just use doubles!’ to get to some real solutions.
Take a leaf out of Professor Farnsworth’s book, move space around the ship instead of the ship around space. Quite a few do that and it seems ok.
Another alternative is to work at regular large sizes, but not have things calculated after a certain distance and approximate them in some way instead. I suppose in most cases the end user wouldn’t notice the difference.
please do release a tutorial Gargerath, I’m jealous that you have finished your space sim so quickly.
I know that I could benefit greatly from your knowledge.
I am also interested in this tutorial.
That would be the floating origin approach.
There are problems with it, most obvious being collision if your ship is not actually moving under control of physics. There are performance considerations as well, since you’ll be subtracting your movement vector from every object in the simulation every physics frame.
If you have a handful of ships then no problem. If you have a handful of ships flying through a field of asteroids, each with an additional set of particle array positions to iterate through…well yeah.
Most people who implement a floating origin do it at a threshold, say 2-k → 3k from the origin then reset everything. You can then achieve acceptable fidelity.
Though once you’re at that point, you might as well just add an integer to your position vector as in the GPG article, and go with the discrete local reference frames as you’ll be most of the way there anyhow.
The thing I can’t get my head around, is how this all works in multiuser scenarios. Obviously, each client has a totally different opinion as to the position of objects in the simulation, as does the server.
Hmm some good points… shakes fist 
thinks ok, well… I suppose you could make in-game reasons for keeping things smaller and less prone to such problems. Space being big and mostly very boring and empty, for the sake of the players sanity, you can cut out deep space and have the tried and tested hyperspace approach, then you’re just dealing with single systems between all that deep space, which should fit within the limitations. Come up with in-game reasons for why Hyperspace is almost instant, and a history of how it was created and quickly phased out the regular method of traveling between systems. Which coming up with that in itself would be fun.
Of course, some people will still want to go explore deep space in the hopes of finding something out there that could be incredibly rare, so perhaps give them a way to drop out of hyperspace in the middle of nowhere (some randomly generated scene) by way of sabotaging their engines in some way. Yeah I got that idea from Frontier hehe.
Actually speaking of Frontier, how did that handle this floating point issue? It had pretty accurate simulation of certain physics, and distances, at least for its time, and thanks to a procedural approach, happily generated an entire Galaxy on a single floppy disk. And supposedly it was even possible to fly from one system to another without using hyperspace (though that could have just been a rumor since nobody would be bored enough to try… maybe).
The “floating origin approach” is the system that i’m using right now but i also have other problems with it that are not physics related but GUI related as in another topic of mine HERE. This is great information thanks for the tips.
Ok i have been able to implemented a real floating origin. i was able to make it so that when the player travels x far from 0,0,0 it will reset the player back to 0,0,0 and shift all the world assets relative to the player at the same time. This works great. Thanks again guys.
I’ve hardly noticed any jittering in space games, so long as all planets beyond 2K or so don’t exist until you “warp” to them and their positions are moved to a static spot relative to you. The usual setup does have a looping outer border, as discussed above, but I personally prefer making sure that the outer border of a set location does not allow movement beyond it. For a space system model, that’s usually good enough.
“Danger, leaving system radius. Turn around or leave mission.”
In any case, I’m removing it from the Kongregate hosting.
Would you mind sharing your code for that ForceX?
I got it from the Unity Community webpage. You can get it HERE. Easy to use. Just place it on your player camera and set the threshold to be when you want the world to shift back to 0,0. The default is 1000 i think, but for me i needed a setting of 10. If there are better ways i’m all for trying them out. So far this is working really well. My world size is about 10,000 unity units which in my game scale is about 19-20Km.
Thanks!
Gargarath, are you gonna post a tutorial?
As stated above, not too likely at this point. There hasn’t been much interest, so I’ve put it on the backburner in favor of other projects.