koobas.hobune.stream
How to create a "wrapping" world in Unity?
I am trying to create a "wrapping" ("rolling" / "repeating" etc) game world. In other words when a game object goes beyond the borders of the world I flip its location to the opposite edge.
My problem now is that I want to make this behavior more smooth. This means that for an object that is partially crossing the world border, two things must happen:
The part of the object that is beyond the border must render on the other side (the game is in top-down view).
The part of the object that is beyond the border should collide with other objects on the other side.
A good example to explain what I mean is to think of the "Star Control" games (if you are old enough like me to remember them...).
I have achieved #1 by using additional cameras that do not clear the buffer and have a limited layer mask. However I think that this is somewhat inefficient? Is there a better way to do this? I looked into using shaders but am not sure if this is the right answer? Or is there something else I've missed?
I do not have a solution for #2 yet. I was thinking of using joints and started looking into the custom joint (as the basic ones obviously weren't built for this scenario). I still haven't fully got my head around how the custom joint works. Anyway the question is if this is the right direction, or is there something better that I've missed?
Edit: Perhaps an image will help... :-)
Unitroids uses 4 duplicate objects, where 3 are offset in a rectangle the size of the screen, and parented to the "real" one.
Yes but Unitroids doesn't do physics simulation on these objects does it? These are just sphere trigger colliders moving about.
For rendering purposes I wonder which is preferable - multiple cameras or duplicate objects?
The real solution is to make it real: make a toroidal universe! Of course that would cause strange physics, a lot of work... but can you imagine the result? No tricks there, your world would really be wraped!!! You would be my hero :)
http://en.wikipedia.org/wiki/Doughnut_theory_of_the_universe
Damn you now I simply must make a game with a donut shaped world...
1)I had a simelar problem and fround 2 solutions
-)Use a secound camera translated exactly 1 map size away and let them draw over each other. They even move automatically right if you parent them to the player 
-)Divide your map into subtiles. when the player comes close to an edge take the last tile behind away and put it in front of him (better solution i think)
2)I can think of one solution:
Make collider just outside your Map (so they get triggered when something showes over the edge). Then you instanziate a Gost object of it on the other side of the map (position - map size).
I would create a extra instances of your "world" and tile them, as soon as you move from one i would delete the instance of the "world" you just left and create a new instance in the same direction you went to replace...
If that makes any sense?
I understand what you are describing but I don't quite see how it will solve the problem, perhaps I've missed something?
The problem is that an object can interact with "ghosts" of other objects, i.e copies of other objects from the other side. However when a collision occurs I need the original object's physics to be affected, not just its ghost.
In other words I need the results of collisions and other physics events on the ghost to be applied to the origin object ins$$anonymous$$d of the ghost.
Is there a known fixed number of "collision" objects that will be interacted with? or are they randomly spawned? are they multiple instances of the same object. ie asteroids or all unique objects
There is a limited number of objects. They are randomly spawned initially.
Technically, the answer to this is going to require a few things:
8 copies of the object (complete with rigidbodies, colliders etc) that can wrap, placed half a screen above, beneath, left, right, above left, above right, beneath left, beneath right.
All of those objects to be connected to the central object with joints / constraints. You basically need a rigid joint that holds the objects positions relative to each other (which will also transfer forces applied to one to all of them), and the objects themselves rotations need to be jointed together (not just synced), so that angular velocity applied to each object is applied to all other objects. (perhaps code that, on collision, each frame, syncs the angular velocity?)
Probably some code to ensure that objects outside of the view have their colliders disabled.
It's the physics aspect that makes this so difficult.
In the end (more than a year ago...) this is what we went with. With the exception that I didn't use joints, but simply updated the parent physic's properties on collision. It worked well. I even tested comparisons with normal objects and the "linked" objects (via code) behaved identically.
Hi! I'm trying to figure out in the same issue (wrapping and collisions), like you did couple of years ago. $$anonymous$$ay I ask, how did you distributed collision data across the 3x3 object grid?
