Older games often implemented wrap-around worlds "accidentally" by exploiting integer overflow behavior. If you have a 256x256 tile world, your coordinates are an 8 bit unsigned integer, you are at x = 255, and you add 1, you get back to 0.

If you are willing to stick to a map size of 256 x 256 (or alternatively 65,536 if you use 16 bit integers), and you are using a programming language that doesn't throw exceptions on integer overflows, you can still do that today.

But a more modern game engine should offer the flexibility of arbitrary map sizes that are dictated by game design considerations and not technical limitations. If you are developing such a modern game engine, then you can solve this by doing all access to map tiles and object coordinates through abstraction layers that implement wrap-around by themself:

x = x % MAP_WIDTH; if (x < 0) x = MAP_WIDTH + x; y = y % MAP_HEIGHT; if (y < 0) y = MAP_HEIGHT + y; 

Wraparound chunks and player jumps

Let's consider the problem in 1D (1 axis): Say I want to make an infinite runner game that consists of 3 chunks, looped over and over again. Boring game, but it serves to explain how we make a game look like we are moving in a straight line forever. Consider chunks A, B and C:

ABC ^ 

I start in chunk B. As I move forward, I leave B and enter C:

ABC ^ 

Oops, there is nothing in front of me. So at the moment that I cross the boundary between B and C, I grab chunk A, and move it ahead of chunk C:

BCA ^ 

As I move out of C into A, I do the same thing again, this time moving B in front:

CAB ^ 

And moving back into B, we move C ahead (aaand we've completed a full cycle):

ABC ^ 

What matters is that there is always something in front of me, and behind me. If each chunk were represented by a class instance, the code would look roughly like:

//1. declarations and initialisations class Chunk { ...chunk data... } Chunk[] chunks = new Chunk[3]; Chunk tmp = null; //player position and speed float x = 0; float vx = 1.4; //2. each frame / game loop iteration x += vx; //update position by speed int pxi = (floor(px) - 1) % 3; //chunk behind player (previous) int cxi = (floor(px) ) % 3; //chunk where player is (current) int nxi = (floor(px) + 1) % 3; //chunk ahead of player (next) Chunk chunkCurrent = chunks[cxi]; //...do jump collision detection based on current chunk... etc. 

Rendering

It's important to understand that you can either do this using modulo wrapping as above, OR by literally cycling the Chunks inside the array, every time you move forward one chunk; this also means you can assume the player is always at chunks[1], so there is always something behind and ahead of you. You don't need to move the player's index, just the chunks it refers to.

The reason I mention this is that you will need to do exactly this for the rendering side of things. If you have each of the 3 chunks displayed by an individual canvas or texture, you are going to need to swap these _in front of the player each time as they move forward.

About the math

In terms of the math, Philipp's answer is roughly correct. Performance-wise however you may prefer bitwise logic than the (relatively expensive) modulo operator and branching conditionals (if), provided you can use powers of 2 and unsigned integers (8, 16, 32 or 64 bit).

Unoptimised:

//each frame x = x % MAP_WIDTH; //costly modulo operator if (x < 0) x = MAP_WIDTH + x; //possibly costly conditional (depends on compiler) y = y % MAP_HEIGHT; //costly modulo operator if (y < 0) y = MAP_HEIGHT + y; //possibly costly conditional (depends on compiler) 

Optimised:

//initialisation int x = ...; int y = ...; const int MAP_WIDTH = pow(2, 8); //256 const int MAP_WIDTH_MOD = MAP_WIDTH - 1; //will set all 8 bits to 1 //each frame x = x & MAP_WIDTH_MOD; //same as 'x % MAP_WIDTH' y = y & MAP_WIDTH_MOD; //same as 'y % MAP_WIDTH' 

When running these for thousands of entities per frame, it can make a considerable difference.

The exact same math as the infinite runner example applies in 2D, we've just added a y axis.

This is a basic "get it working now" solution, which I recommend changing before shipping if your development cycle is longer than a month or two.

Use nine cameras

Instead of having one camera, have nine. One which follows the player, and eight more which are offset from the first camera by the size of the world in each dimension.

When you draw, first clear the screen to a fill color, then draw what each of the nine cameras sees (in any order). Cameras which do not see the world should not draw anything.

For example, if we consider only the x dimension, you have a camera that follows the player, a camera that is one world-size to the left of the player, and a camera that is one world-size to the right of the player. Most of the time, these supplemental cameras will be pointing at empty space, and so will not draw anything. However, when the player gets close to the edge of the world, one of these cameras will get equally close to the opposite edge.

With nine cameras, if the player moves to the bottom left corner of the map, the three cameras in the top right will get close to the top right corner of the map, and draw it connected to the bottom and left corners.