Hey folks. Okay so I’m not so sure on the physics side of things but I’ve been working on a 2D defender-like shootemup game which wraps around horizontally. The game world is several screens wide. Obviously there are lots of objects moving through space and across the edges of the world so I had to figure out how the heck to make it work.
Just for the case of horizontal wrapping, you need 3 cameras. You assume that a world scroll position of X=0 is aligned to the left edge of the screen, positive coordinates (and the rest of the game world) are to the right. To render this, you need a regular camera. The camera’s going to be centered on the screen so you need to add half a screen’s width and height to its position. This camera moves in order to implement scrolling.
Next you add two more cameras. They’re basically set up the same. However, the 2nd camera should be positioned at a negative WorldWidth offset, ie to the left. The 3rd camera should be positioned with a positive WorldWidth offset to the right. So you’ve got three cameras, one in the middle, one an entire world’s width to the left of it, and one an entire world’s width to the right. The 2nd and 3rd cameras must be child objects of the main one so that they move together.
With this setup, you only need one instance of each game object. The main camera clears the screen and draws anything visible at the main scroll position. When the camera gets too far to the right it will cover the case of objects overlapping the right edge. You still have to use a script to detect when an object’s position becomes >=world width and then subtract world width from it to wrap around. Similarly, when the camera is at the left side, e.g. if you put camera X=0, it will show some world that overlaps the left edge, and that’s captured by the third camera. The 2nd and 3rd cameras need to not clear the screen at all otherwise they will wipe out what the first camera drew. Similarly if an object’s X coord becomes <0 then you must add world width to it to wrap around.
This works perfectly fine but does not incorporate physics. Technically you only actually need 2 cameras to do this when an object’s position (and world scroll position) are always aligned to the top-left edge of the object… but I found that when adding e.g. a second player and you want them to show up properly to the left of the first player, it needs that 3rd camera to cover all the bases.
Non-rotational physics can be done by giving a single game object multiple colliders. E.g. add a spaceship with its own collider, then add two child objects each with a collider but not a renderer/mesh. The 2nd and 3rd collider objects are positioned at a world’s width to the right and to the left, similar to the camera. That accounts for odd wraparound effects at the edges of the world where the collider kind of needs to be in two places at once.
I presume this would all work vertically as well, although in that case I think you’ll need 9 cameras to do X and Y wrapping. Same principle, cameras above and below by the height of the world. Similarly for physics you’d need to have 9 colliders per object to capture all cases.
The remaining issue as mentioned in other posts above is rotation of the game object’s collider, for which I have no comment 
The colliders really need to rotate in-place and not around the main object. Is there any physics setting regarding local rotation/object rotation versus world? Or perhaps constrain the main game object to have no Z rotation and somehow handle local Z rotations? Actually I think if you have separate game objects for the extra colliders they will be able to rotate around their own local center, and then if you attach them to each other by a physics constraint/joint (ie don’t make the game objects hierarchical, but tie their position to each other), then you will get local rotation… but this will still require copying any rotation between all of the colliders in the set.
