3
\$\begingroup\$

I'm making a game like this: https://www.youtube.com/watch?v=hO7573lphqI

wherein a 3D ship is flying around on a 2D plane. From the player's perspective, the ship will stay stationary in the center of the screen.

The question I have is whether it's better to have to ship stay stationary and the world move around the ship? Or should I have the camera follow the ship as it moves around?

Notes:

  • assume the ship can go infinitely in any direction
  • this is in Unity, though I'm curious if that differs from other tools like Unreal
  • I will be culling items that are offscreen either way

Obviously, having the camera follow the ship is easier from the programming side of things, but I'm wondering if there's a good reason not to do that (if the player moves far enough in one direction does it hit an internal limit that would break the game)?

Thanks!

|improve this question
\$\endgroup\$
2
\$\begingroup\$

Both the points brought up by projectskillz and by twyla are important considerations. However they push in opposite directions (floating point precision means you don't want to move the player too far from the origin, but NPC ships will be extremely hard to handle if the world is moving) so you'll need to find a third-way compromise. For an infinite universe I would try a zones approach, where the world stays still within a zone, but when the player reaches the edges of the zone the world snaps over by the width of the zone, thus always keeping the player near the origin.

|improve this answer
\$\endgroup\$
  • \$\begingroup\$ This is a solution to an implementation but not really the question he asked. But yeah thats how I would do it. \$\endgroup\$ – Ray_Garner Mar 27 '14 at 0:51
2
\$\begingroup\$

There aren't any technical drawbacks in both implementations.

That said, simplicity is very important when designing software. For many reasons. A game - most of the time -, simulates a subset of the reality. So trying to achieve a simulation that is more natural, that works like it would work in real life, is a noble objective to pursue. Even when there are some technical disadvantages.

But in your case, attaching the camera to the ship in the Hierarchy and moving the ship is the most natural way of doing. The other way doesn't have advantages and has the disadvantage that is just... weird.

You will have the challenge of making it be able to "go infinitely" to any direction, but this is a problem you'd have on both implementations.

|improve this answer
\$\endgroup\$
1
\$\begingroup\$

In unity you can move as far as you want off the origin point.
There is no internal limit. However you will encounter a different type of limit. The floating point precision limit.

In short floating point types have a precision limit of around 7 digits no matter the placement of the dot.

So for example you moved a character past say 1000 unity units.

You wanted to move an object from 1000.0000 to 1000.0001 you may or may not see jittering and your Gameobject may or may not be exactly in the place you expect it to.

So in general you would want to keep your gameplay as close to the origin as possible.

So if you wanted to be able to infinitely move in one direction you would absolutely need to implement a system that moves the world and loads it dynamically as you move.

This is not really just a limit of unity but of just how floating point numbers work. You could get double the precision if you were to use the double type however, Unity represents everything internally as a floating point number as they are just faster and have a lower memory footprint on almost every modern system today.

For a detailed explanation of this check here. http://www.davenewson.com/dev/unity-notes-on-rendering-the-big-and-the-small

|improve this answer
\$\endgroup\$
  • \$\begingroup\$ While your answer is true, it's also not relevant to the original question. Just because the world moves around the ship, doesn't really mean the edges of the scene get closer to the practical floating point limits. Because if the origin-based player is at the edge of the scene, what that means is the rest of the scene is at scene-width distance from the origin. At best you get 50% of the scene size back, because you can ensure that the mid-point of the scene is at the origin. \$\endgroup\$ – MrCranky Mar 22 '14 at 9:43
  • 1
    \$\begingroup\$ @MrCranky How is it not relevant. He asked wether he should move the world or the ship assuming the ship can move infinite distance in any direction. The floating point problem almost ensures that he has no choice but to move the world. How is that not relevant if not directly answering his question? \$\endgroup\$ – Ray_Garner Mar 22 '14 at 16:21
  • \$\begingroup\$ @projectskillz, thank you. That's exactly what I was looking for. I assumed that, at some point, an infinite plane would run into issues. I just had no idea what those would be. \$\endgroup\$ – Summitch Mar 23 '14 at 3:29
  • \$\begingroup\$ Apologies, I missed that nuance in the question. \$\endgroup\$ – MrCranky Mar 24 '14 at 8:58
  • \$\begingroup\$ No problem. I thought maybe that was the case. \$\endgroup\$ – Ray_Garner Mar 24 '14 at 10:09
1
\$\begingroup\$

Asking yourself one question should make the answer glaringly apparent:

"How many game objects need to move for either implementation?"

Under most circumstances, the ship moving through the game world requires only the player's ship itself to move. All other objects in the game remain relatively stationary in game-world-space.

If the ship is stationary and the game world moves, now you're introducing a whole world of mathematical nightmares in trying to calculate the movements of anything else which moves within game-world-space. NPC ships (and other PC ships, if ever making a multiplayer game), planets, space stations, etc.

Think back to the days when people thought the Earth was the center of the universe and all the wonky, lopsided mathematical formulas they had to work out to explain how other known planets varied their orbit speed throughout the year (sometimes appearing to reverse directions). Even though you've touched on this, you don't seem to quite realize just how deep this rabbit hole can go!

As others have pointed out, there are some issues concerning floating-point precision if you make your levels excessively large. Just be smart with your level designs and you'll save yourself a world of headaches.

|improve this answer
\$\endgroup\$
  • \$\begingroup\$ How would setting the world coordinates of those objects affect their speeds, rotations, etc? If they are moving 1000 units away at a certain speed and a certain direction, moving their world coordinates relative to your movement input is all you need. Everything else stays the same for that object, and this is true for both single and multiplayer games. A good read about this exact same issue in the form of a PhD paper: citeseerx.ist.psu.edu/viewdoc/… \$\endgroup\$ – António Sérgio Simões Apr 10 '19 at 16:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.