LÖVE

I am very interested into making games with a world bigger than just what my screen can render and I can't seem to find a way to do that.
So far, I've been using tables to store my tile informations but I want my game world to be big !
Is the "table technique" the only way to store and render a game world ?
Obviously, it needs to not render what's outside of a screen so it needs a way to know/remember what tile to place at what location.
If I want to make, lets say an RPG map, do I have to create a huge table to store everything or is there a different way to do that ? Doesn't seem right, what do you think ?

When it comes to infinite terrain generation,I've heard about perlin noise and all that stuff but I never find any proper LUA tutorial about it...
Can anyone try to explain (in an "algorithm" way) how I could use this technology to place tiles and create a big world, without having to hard code a huge table, storing tile numbers ?
Thanks in advance !

You can get away with having a pretty large table as long as you don't iterate over the whole thing every frame.

I use a technique in this that only iterates over the part of the map that's visible to the camera.

The approach that I have been using recently is to use string indexes for the table, which are basically just the x and y coordinate put together.
The main advantage of this is how it means that you are never limited to a fixed size, at any point in time the world can extend in any direction by any amount, and any parts of the world that are completely empty, don't need to be stored in the table at all even if they are in the middle of areas that do need to be stored, which can reduce the memory footprint.

Also, one trick that I have used to reduce the amount of time for rendering is to pre-render the world onto a canvas, and then use a quad to only draw the region of that canvas that would be visible on screen, with these two tricks I have been able to have a game that was about 300x30 tiles, which that can obviously adjust that to any dimensions needed, with the only limitation being that canvases have a limit to how big they can be, but you can easily break the world down into multiple canvases if necessary.

As far as tiles with animated textures, it is easy to keep track of where those tiles are in a separate table so that in each frame you can still go through and be able to only redraw those specific tiles.

It is possible that there could be a better approach out there, but after about 4 years of using Love2D, this is the best one that I have found through my own experimentation.

Another thing I would recommend for when you go to build out the tile grid, is to use image files, you can use the RGB values of a pixel to specify the tile type as well as any other data you may need, and being able to use something like paint to edit it can be very handy, and it's fairly simple to load it in.
The format I have used for the RGB values in the past allowed for up to 128 different tile types, which would be specified by the red value, and if the given value for a pixel was greater than 128 that would indicate that the tile was meant to be on a background grid instead for a foreground one
The green and blue values were then available to specify data for each individual tile, which could be different depending on the tile type being used.

Re-rendering a canvas for an animated background would reduce the performance gain of the canvas.
Try using a spritebatch and change the sprite's frames with spritebatch:set. You'd get much better results.
Anim8 supports spritebatch animation.
Even if there are no animated tiles use a spritebatch.

TheJogMan wrote: ↑Thu May 17, 2018 2:32 pm The approach that I have been using recently is to use string indexes for the table, which are basically just the x and y coordinate put together.

You're creating a string each time you need to access the map? This is not only slow on its own, but also accesses to the map part of the table are slower compared to accesses using numeric indices, strings use space on the heap, and are subjected to garbage collection.

I advise against this approach, unless your map is very sparse, meaning there are a lot of missing tiles in the grid.