Sorry; this is very, very basic stuff...

I've been planning out my first game, which amounts to one character walking around a tile based map, with a few buttons to press, and some scrolling text along the bottom of the screen at certain prompts.

I have my story plotted, and I'd like to start work on the level design, but I've no real understanding of how the memory limitation affects the number of tiles I can place. As I understand it, I can work with 128 8x8 tiles, but is there an upper limit to the number of tiles I can place? On the Pico-8 homepage, it mentions "128x32 cels"; does this mean that my game must exist within 32 screens, minus however many screens I need for character sprite animations?

Here's how it works:

There are 128 sprites in the sprite bank that are available.

The map holds 128x32 tiles.

However, there is an extra bank that can be used by either.

You could have double the sprites, double the map, or balance it between both.

A good way to see how this affects the shared bank is by making a tile, then throwing a lot of said tile into the bottom of the map.

does this mean that my game must exist within 32 screens, minus however many screens I need for character sprite animations?

Sort of, the screen is 128x128 so a 16x16 tilemap will fill it. If you use the shared memory for tiles, then you have 32 screens worth of tiles to work with. If you use all of the shared memory for sprites, then you only have 16.

It's possible to get more tile storage, but not easily. Old NES games didn't store raw tilemaps in memory. They were usually compressed or encoded somehow. For instance, the original Mario game only scrolls forward because the tilemap can only be decompressed in a left to right manner. Writing games like that usually isn't a lot of fun unless you are really into optimization. ;)

Okay, I think I get it. Thank you, both! That Mario scrolling thing is pretty fascinating. I remember reading this thing by Ian Bogost on how limitations on the Atari 2600 were circumvented. People can be pretty ingenious...

I've do have one further question; I'm wondering if it's possible to work with larger sprites, by linking smaller ones together? I think this was an old NES thing. I'm hoping to have a 8 x 16, or maybe 16 x 16 character. Does this sound doable?

The spr command allows this by default.

spr n x y [w h] [flip_x] [flip_y]

The w and h allow you to combine several tiles in one draw.

a 8x16 sprite would be something like: spr(1,0,0,1,2)
a 16x16 would be: spr(1,0,0,2,2)

I had to take notes for myself on some of those sprite commands so I could be sure I entered them right, lotta variables, but they are extremely useful.

I've do have one further question; I'm wondering if it's possible to work with larger sprites, by linking smaller ones together? I think this was an old NES thing. I'm hoping to have a 8 x 16, or maybe 16 x 16 character. Does this sound doable?
I'm doing that with my TMNT game. It starts like it's wasting tokens, but it pays itself when you add more animation frames that would be possible otherwise. But my approach is more like a flash animation than what the old NES did. I'm sticking little pieces together with no respect for the size of the sprites.

Ah, that's great, thank you all so much!