• Register
Post news Report RSS Warping Millions of Meters Accurately

If you want to be able to warp around a star system, you've got to implement a system for maintaining floating-point precision. That feat is arguably difficult enough on its own, but adding to that the constant stream of transform updates for other players tacks on a whole new level of difficulty. Here's how it was done.

Posted by on

Floating-Point Precision:

One of the greatest challenges in building a world as large as ours is maintaining floating-point precision. Suffice it to say that the further from the scene origin - otherwise known as (0,0,0) - an object moves, the less precise the values that store its position become.

In Vague, we circumvent this issue by constantly shifting the scene around the player. We have a threshold of ~9,000 meters set and anytime the player moves outside this threshold by moving further than 9km from the origin, we shift the player back to (0,0,0) and move everything else in the scene the same distance and in the same direction. This happens so quickly that the player doesn't notice (at least when we've done things correctly), and what you end up is fluid, uninterrupted travel between objects that can be millions of meters away.

Things become even more complicated when you incorporate remote players whose data is coming in via a constant stream of transform updates. The game needs to take their updated transform position and work out where that player is in relation to our player, keeping in mind that our player is constantly shifting around the scene as they move beyond our 9km threshold.


This past Saturday I had the goal of ensuring that we maintain floating-point accuracy throughout our game, regardless of how far the player - and anyone they may be playing with - travels from the center of our world. There's a lot of potential for issues, including - but not limited to - the fact that the camera is following our ship at a very high rate of speed as our entire scene is being shifted around the player. If anything is out of place for even a single frame, we break the player's suspension of disbelief and the player will need to put in the effort to reattain that suspended disbelief.

Problems like this are why I enjoy game development; the math not only needs to be accurate but it needs to be artistic as well. You can't simply dust off your hands and boast that your math is spot-on because it also needs to keep from disengaging the player. Nobody wants to see a planet skip 9,000 world units in a single frame, and so figuring out the math to pull off this trick is only the first half of the battle. It is a lot of work that not only needs to function properly but also needs to be completely invisible to the player. If I've done my job correctly then the work won't be noticed by anyone.

That being said, I finally put in the time Saturday to finish the second half of this battle, which is to say that I put the representation of our shifting origin through its paces. It took me the better part of the night to test and re-test every situation I could conceive of, and I am happy to report that my ship can now travel millions of miles away from the center of our game world without objects rendering incorrectly for a single frame.

Warp Drive

The reason I wanted to ensure we maintain position accuracy was that my next goal was implementing a warp drive system. I had made the commitment to be able to warp 2 million world units (m) from any player's spawn point and then have those players meet up at a single object, which in this case was a glowing orb representing the location of a neighboring star system.

I started with a warp speed that was just below our 9km threshold to start, but since recording this video have had successful tests with warp speeds up to 25km/s. I've tested this with multiple clients as well, it's just a bit difficult for me to solo multiple clients while also recording video that is more than a ship floating in empty space doing nothing while I fly another user's ship. This extrapolates without issue regardless of how many players are in the scene or how far from the scene origin they are, and also applies to the server-controlled clients that I programmed last month.

There's nothing really special in the above video; I'm only multiplying the ships warp speed by a float and playing some particle effects for the sake of player-immersion, but the end result proves that my math is on-point. Whether I'm 200 meters from where I spawned or 2,000,000 myself and any remote clients are updated accurately and consistently.

This is a huge milestone for me personally as the lead (and currently only) developer of this game. In my own slightly ego-boosted mind, this framework is a symphony of a brain-boggling amount of numbers, all of which are well into the millions, working in tandem to draw a star system on the player's screen that matches what is represented on another player's scene with pin-point accuracy.

With my warp drive in place since Saturday night, I have been spending my evenings playing around with my galaxy generator and warping between star systems without issue, which has provided me with a new dose of confidence to keep pressing forward in my quest to reassemble this game, taking it from what was a proof-of-concept to a full-fledged, working MMO.

Post comment Comments
callumhutchie
callumhutchie - - 2 comments

I have always been interested in creating a game similar to this but don't have anywhere near the talent to pull it off, how do you plan on handling space to planet surface transitions?

Reply Good karma Bad karma+2 votes
idlepeon Author
idlepeon - - 17 comments

Our very first video shared on IndieDB shows our space/planet transition. Indiedb.com

Reply Good karma+1 vote
Post a comment

Your comment will be anonymous unless you join the community. Or sign in with your social account: