Infinitely scrollable, 360 degree, tiled background.
The end goal is for a player to drive a jetski in any direction and the background never runs out.
Here's an example animation just to set the stage, with other pieces of the game disabled so we can focus just on the background tiles:
Constraints
In theory, I don't need infinite scrolling for my game. I could find a way to keep a player within the confines of a course, and prevent travelling in all directions. I might even still do this.
However, I did not want to be limitted to a specific course size, I wanted to be able to flex the course size up and not worry about scaling the background.
Using a single, large background image with a confined course might work. However, this runs into a major issue in regards to image & memory size: since I am always rotating the view, I would need to have a 360 degree spritesheet for a large background image, which would almost certainly not fit into memory.
Another constraint is the number of tiles. I know upfront I can't just add 100's of background tile sprites/images, since the overhead in moving and rotating all of them would eat up my perf budget.
tl;dr try to use a reasonable number of tiles, to balance memory and performance.
Approach
Overview of the algorithm:
- Move & rotate all background tiles in response to the user input (covered in my post above).
- Detect any tiles that have moved out of view. Add these tiles to a list, let's call it
freeTiles. - For every visible tile:
- Check if each neighboring, visible, tile slot has a tile.
- For any missing tile: move a tile from the
free_tileslist to that slot. - If the
free_tileslist is empty, create a new tile, and place it in that slot.
The algorithm works as long as there is 1 tile placed anywhere that is visible to start.
Showing an animation, starting from a single tile placement:
- For that tile, check each of it's neighbors (north, east, south, west) to see if we need a tile placed.
- In this case we need 3 tiles, so we create a tile and place in each slot.
- On the next tick, we check the neighbors of all 4 tiles (including the 3 that were just placed), and perform the same operation, filling in any gaps.
Now, let's look at the case where we are rotating and moving, and tiles are going out of view.
Let's assume we've reached this state where a tile has gone out of view.
nb This is for illustration only, this much of a gap would not be possible, as the missing tiles would have been detected immediately.
- This tile has gone entirely out of view, so we add it to our
freeTiles. - We run our algorithm for each tile, and find the missing slot.
- Remove the tile from the
freeTileslist, and move to the missing slot.
And that's it!
No matter what happens, the background always fills itself in.
The re-use via the freeTiles list means that we only create enough tiles to cover the worst-case scenario - which is rotated such that just a tiny bit of corners of tiles are visible on the screen.
Perf tuning
Notice in the screenshots above that there is a + sign shaped check for the neighbors. The 4 offsets can be computed for the current rotation a single time per tick, then applied to each tile, making the neighbor computation quite cheap.
Currently, I landed on a tile size such that the algorithm maxes out at 13 tiles in the worst-case. This means there are 13 * 4 neighbor checks, and only 13 tiles are part of the rotating & moving logic (outlined in my previous big post). This number is just a place I landed considering tradeoffs, and can tune a bit. A larger tile size - I might only need, say, 9 tiles in the worst case, but I would need more memory for the image (or a smaller image, using more tiles, and more CPU for moving).
As mentioned previously, I am using a sprite sheet/image table of 360 degrees. For other game objects I can get away with 180 degrees, however, with the tiles being relatively large, the steps at 180 degrees are noticable, and you can see the shear at the edges of the tiles (tbh you can still see some if you look for it). This does mean that the actual images are large when loaded into memory - this is an area I hope to try a few things in soon and there are already some comments above!
Bonus
I wanted the water to feel more "real", so there's two more things I layered in here.
First, I can have the water move in a direction, for example, always move a little "East". This can be useful for giving a bit of a moving wave effect.
Second, I want the water to "shimmer" and not feel so static. To accomplish this, I actually have several image tables, each of which represent a frame in an animation. For example, right now I am using a 3 frame animation. I set a timer to increment the frame so it's not locked to the FPS. I can even start each tile at a different frame to give even more shimmer effect.
Showing the result of those two effects with zero movement on the player - to show both effects without the distraction of movement/rotation, but work when moving/rotating as well.
And the final result:
Future
I plan on making a distinct background for each level, but at this point that should "just" be on the graphics side and can plug them into this same algo.
I have some thoughts on how to keep positional information for tiles as well. For example, I want to have a rainy pond level, with rain pattering on the water and maybe some simple lilly pads or reeds. I'd want those lilly pads to not teleport as you race around. If I can reduce the memory footprint, I can run more frames for smoother animations as well.