Hi,

I'd like to create a top-down adventure game with a map that will exceed the dimensions of the map editor, so I'd need to create and store the map by other methods. The problem is that I'm a bit clueless about how to best go about this and wondered if anyone could send me down the right path.

I'm guessing that I'd basically have to store the map in an array (well a table). Does anyone have any experience with doing this kind of thing?

Thanks!

You might want to experiment with the PX8 compression algorithm zep posted last week, so you can fit more map into your map.

Hmmm....at first glance that compression stuff looks way over my head. I'll have to have a closer look to see if I can understand it.

I was just hoping to create a set of tiles, and then store a list of the tile numbers that could be read, placing the necessary tiles as the player reaches them.

You can use a map region design, where the map stops scrolling when the player reaches an edge, and there's a transition when they cross the edge into a new region. At the transition, you copy new map data into the map memory from somewhere else. You can design bottlenecks or underground caves into your map so it seems seamless and less like walking from one map to the other.

An easy place to keep more maps is in separate cart files. You can use the reload() function to load maps from other carts into memory. If the other carts store their maps in their own map memory, you can use the Pico-8 map editor to edit them. (Just have each map cart also have a copy of the sprite sheet.)

Lua memory (tables) may not be the easiest or fastest place to store additional map data. Easier and faster would be to use memcpy() and other regions of the cart ROM memory. Another option is to encode map data as Lua strings and store them in code, but that requires some tooling to convert the maps you design to strings. I did this for an (unfinished) puzzle game so I could store more puzzles than there was space in the map.

Compression may allow you to squeeze more map regions into a single cart (or multiple carts), but it does get more complex to manage. If you try this, you might make the map "region" smaller than the actual map so that you can store compressed data outside the boundary in map memory. At the border transition, compress/decompress out of/into the active region.

And if you want to get fancy, you can try to make the region border transition actually seamless to the player. Pico-8 may be able to copy and even decompress stuff quickly enough that you can teleport the player from one screen to an identical screen in a new map configuration.

Cool, that's a good few options for me to consider, thanks! I guess the "fancy" idea at the end is effectively what happens in The Legend of Zelda on the NES. You mention copying quickly enough....I guess that would be where my idea of putting extra map tiles into place as the player approaches them could fall down. If the player walked to the right, a new row of 16 tiles would have to be generated off the screen to the right for the camera view to move to. I assumed this would be straightforward as I've used repeating maps to make an infinitely scrolling background in one test. I'll have to see if I can test the method.

The idea of using separate carts each with their own maps interests me as it would certainly make level design easier. I saw another post about using multiple carts. Perhaps this is a question for another thread, but is multiple carts supported by this website or through the splore function of Pico-8 or can this method only be used when the player has the carts located on their hard drive?