Recently I finished the initial implementation of the World Wrapping system. It was a little tricky and had to vary from the initial design, but in the end turned out pretty good.

I first started implementing the World Wrapping system using the original design of tiles with collider "walls" to track player movement. The walls are not right on the edge of the tile to create some dead space that makes transitioning a little smoother. 

The theory was that by determining the order of walls hit by the player, the system would be able to shift accordingly. For example, if a player goes through the left wall of a tile, then passes through the right wall of the another tile, then the player must have moved left.  However, the system became very convoluted and tracking down all the edge cases became cumbersome. So I created a simpler version that didn't require the tracking of which tile a wall belonged to.

Keeping the same walled tile design, I assigned values to each of the walls.

When the player triggered a wall a value was incremented or decremented depending on the wall (horizontal and vertical values were tracked separately). This limited the possibilities and simplified the cases to just 3: the same value, the opposite value, or zero. If the value was the same as the wall, the value was reset to 0. If the value was opposite, then the player shifted, so adjust the world and reset the value to 0. If the value was 0, then increment/decrement the value. This meant that if the player was in the middle of a tile, the value would be 0 and if they were in the transitional area between tile, the horizontal and vertical values would track how they got there. At least, that was how it was supposed to work in theory and the math checks out. But, there was one problem with the system and it had to do with the way the colliders work, can you guess what it was?

The problem I ran into was that any system based on the colliders was assuming that the player was always passing through the collider. I was using Unity's OnTriggerEnter to determine when the player hit a collider. This gets triggered when the player first hits a collider, but it does not determine if the player then passes through the collider or is just dipping in.

In the above graphic, the player collides with the collider, causing OnTriggerEnter to fire, but they exit back in the direction they came from. This tricks the system into thinking the player has now "left" the tile, while the player is still on the same tile. There are solutions to this, but the ones I could think of weren't elegant and I didn't want such an important system to complex and prone to edge cases, so I had to completely rethink how the system was going to work.

I decided that the best solution was to just track the player's position and using some simple math, determine which tile the player was on. Since the tiles are all a fixed size, it is easy to determine this just by using the player's X and Z coordinates. Then as the player moves around, the system can adjust accordingly. The result was this:

The player is now always (except for a little dead space) in the center tile and the world moves around him. This will hopefully give the player the sense that they are on a tiny world and when they run around, they wrap around the world.

In the next devlog I will go over some of the editor tools I created to accompany this system.

Thanks for reading!

- Matt