- Home /
Tilebased worldmap - are there any boundaries?
Setup/idea:
I am currently designing a game engine where the maps will be dynamically generated from basetiles and combined into larger segments. Much like if you have some room and corridor templates and then throw these into a large map.
I have this 3rd person view on my character (our view is floating up behind the main figure) and the map scrolls into view by moving forward. Outside camera range, I dynamically add the next "tileset/room" based on whats next in this direction.
My problem/question:
What I can't decide is, wheater is best approach to keep player and camera at "fixed positions" eg. around 0,0,0 worldcoords, and then scroll the tiles under the hero, or I should move the hero around on the tiles that will stay on fixed positions.
Every room is parented to an empty/axis/null gameobject, so its no problem to move a room smoothly. But when looking a particle animations, they can act kinda weird if they dont stay on the same position when animating (flames/rain/snow&smoke) - on the other hand, I dont know if there is any maximum/limiting boundary on how large my heros world coordinates may get before its too big.
My guess would be "unlimited" as its a floating value, but I need someone with largescale tilebased games to come up with some usefull arguements for A or B solution.
Currently I think moving the tiles, makes the camera etc. most logical, but if that makes particle animation troubled, it might be worth moving the hero as a hero actually does and then parent the camera to a moving setup including the hero.
While it's theoretically unlimited in size, the problem is floating point imprecision. This is practically nothing when you are near the origin, but when you're several orders of magnitudes away it cam become very significant. How big (in unitys base units) would your map be?
Answer by Joshua · Jun 07, 2011 at 05:30 PM
If you're talking about a reasonably sized project, don't worry about it and go with option b. If it's a large, detailed world that you move through at high speed (for instance a race car through a detailed city) I would combine both options.
To tackle both the floating point imprecision and avoid the huge processing overhead I would have the character freely walk around within certain range of the origin, say 1000 units. When the character get's too far away (use, for instance, a trigger spherecollider to detect this) parent the entire world to your character, transform your character back to the origin and unparent everything again. No floating point imprecision and only a possible slight loading-like lag every few thousand units.
I have a square world, so detecting when I reach max would not be the problem if I set a max. Currently a tile is 1x1x1 unity unit.
So will like 30-50.000 be a problem for floating I wonder??? I dont know how the map will look as it can branch in any direction, so worst case scenario could get out there.
50000 will be a problem if you want to move around in small steps, or have small geometry. Floating point precision is less than 7 digits, so if your camera is at 50000/0/0, the engine can no longer distinguish between 50000 and 50000.01.
Simple example: create a cube, place it at 1000000/0/0, press 'f', move around: the object will be extremely jerky, mesh and collider no longer at right angles.
Right, so if you move the entire world back to the origin every 1000 or 2500 or even 5000 you won't have the jitter ;)
What is relevant for the floatingpoint presicion problem are the world coordinates of your object. If your tile of 1x1x1 is at 1000000, your tile will get distored. If you put it at 100000, it will jerk around already, and you can't place small objects (ca. 0.1x0.1x0.1) on your tile.
Ok, good luck with it. But, like I said, only moving once every few thousand units will cost you a lot less overhead.
Answer by ericksson · Jun 07, 2011 at 04:56 PM
If you're tiles have Colliders attached to them or you have objects with RigidBody components on them, moving the whole world around will take a lot of processing power. There might be other reasons why this is not a good idea (e.g. possible floating point imprecision problems), but I think option B is the way to go. Attach a camera to your hero and third person controller and you're good to go.
its a quite basic gameplay and physics will only be applied upon destruction/crash. so that ought to be possible too. but great answer too.
Answer by flaviusxvii · Jun 07, 2011 at 09:32 PM
If you treat game units as meters you're going to have hundreds of thousands of kilometers worth of space in floating point numbers to work with. Don't sweat it.
Your answer
Follow this Question
Related Questions
How to move an object in boundaries of a cuboid or a cube? 0 Answers
How can I determine what tile I'm clicking on 0 Answers
TileMap GetCellCenter not working 0 Answers
CellToWorld not working on Tilemap? 1 Answer
Changing Size of Tilemap 1 Answer