No duh, right?

I've been making PICO8 games for 7 years now (doesn't feel that long) and the tokens and limits have just been part of the fun. Those restrictions can push our creativity into something better. That's the whole point and I love it.

My focus has always been on making the games for people playing on the P8 console in some fashion, whether on a PC or a handheld or whatever. And that audience is basically other P8 devs and gamers that know and appreciate the limitations.

Until now, Itch.io has mostly been an afterthought for my games. Basically just a nice way for people to play them all via the web...and you get some nice exposure bumps from the platform and so on.

Don't Dig Up the Dead it was the first time I put more conscious effort into the Itch.io versions of the game, whether that be the downloadable binaries or even just playing the web version for free. I've also put more effort into spreading the word about the game because I'm just proud of it and very happy with how it turned out. No shame. But with that push comes more feedback, which is always wonderful to receive...

...but this time that feedback hit me a little differently. As people called out frustrations or things they feel the game is missing, I realized I can't just say, "I ran out of tokens, sorry." That obviously doesn't fly if the person on the other end isn't aware of the PICO8 platform and culture, and in the case of Itch.io, they're probably not(?).

I don't know why this never hit me before. It's obvious but I was just so focused on the P8 crowd that I never considered the non-P8 gamer that plays the game through Itch.io by chance. It's made me realize that P8's limitations can quickly be a convenient excuse for excluding things that really should have been in my game. "Sorry, I wanted to add that feature but ran out of space," is all too common in my post-release world but in context of P8 I was fine with it. I don't know if I am anymore.

But I also don't think I want to use PICO8 as "just another" game engine because why deal with the limitations if you're always trying to find elaborate ways to get around them anyway?

Reading that back I think the real dilemma here might be multicarts. I never really considered making multicart games because it just felt like a way to avoid the limitations. I stuck with the tried-n-true 32k single cart and that guided my game design (and provided all the excuses I needed).

I guess if you plan for multicart from the start you can add all the features you want.

Don't Dig Up the Dead was started and designed as a single cart. The multicart consideration didn't happen until I decided I really wanted a title screen. Boom. Multicart. And boom, my whole concept of how to use PICO8 to make games has changed (even though it was staring me in the face this whole time).

Hi @morningtoast:

I would not feel bad about multicarts. I remember playing CHESS back on the TRS-80.

Because memory was so limited it read the instructions off of the cassette directly into the screen, then loaded the chess game itself right after that.

I thought it was a pretty clever way of making use of memory - so you would not need code to draw the instructions later. Instead the tape data writ directly to the screen memory.

And multicarts are here to stay. What with the holidays you can always count on someone to make a menu that loads a multitude of games other Piconians have written.

Your idea of having a marvelous logo in one cart which then loads the main game cart is a great one !

I guess if you plan for multicart from the start you can add all the features you want.
No - even in multicart there is always a single cart running, same token limits.
Multicart is mostly useful to load more data (mostly in lua RAM), not code.
The other multicart technique, say a title and a game cart can be done on BBS (chaining carts - recent example: Freezing Knights)

@freds72 - Yeah, I get that there's always one cart running. I guess I was saying that if I plan to do multicart then I can split the game across those carts as necessary to allow for more features (and code). Like splitting up exploring, battles, shopping, etc into separate carts, each with its own code.

I honestly don't think the multicart thing would have worked well for Don't Dig Up the Dead b/c having the battles be instant and quick is critical so I wouldn't want the load delay. But for for some games, like Freezing Knights, that delay doesn't impact the experience all that much.

Either way, multicart is now an option in my eyes where before it wasn't.

If you don't want to deal with delay from loading screens, one solution is to jam as much as you can in strings and upper memory using creative formats. The obvious example, which I noticed your cart does, is use strings to store tables. However, depending on how similar the behavior of in-game entities and such are, strings can also be used to store things like mini-scripts. I doubt it's worth it for an already finished game, but I suspect your bullet hell patterns probably could have been done in far less tokens by finding all the similarities in what things each one needed (such as all those function calls) and storing those in a creatively parsed string.