My Thought

I was thinking of making a "quite-long" and "story-based" game (like Papers, Please) and for that, I have only two options which I believe can make it, first, Godot - It's perfect but the only problem is its bundling with "both 2D & 3D" when we don't need both. Next there's PICO-8 - I believe it can make it just so it is better suited since my game shall have "arrows" and "1-2 interactive btn".

My Fear

I fear only one thing. That is, are the limitations workable for the game?

• I know the Cart size limit, But then I can simply #include a main.lua file and a network of codes to work.

• The next big thing is SpriteSheet. Can I possibly have more than the "128x128"? I believe I can (by the unlimited #include space) make "text-sprites" (a 2D array with sprite data) and "workaround" and display it.

• Can I rely on dget() and dset() to completely save user data?

• Do the dset() and all save data even on HTML builds? Since I'll be using Cordova to export easily into Android (As I've already done it on one of my other game: vech10

Your Views

I'll be extremely glad if anyone would guide me (possibly) since this is "the" first time I'm at this "BBS"

When you use #include, the code in the #include files at some point gets inserted into the code and counts against the token limit, so you don't actually have unlimited tokens in that way.

dset() does work in HTML builds as long as the user allows the use of local storage in their browser settings (I imagine most people do).

There is a limit on how much data dset()/dget() can be used with, and they can only store numbers. http://pico8wiki.com/index.php?title=Dset has a bit more info on that. You could also potentially use cstore() for storing data, but that doesn't work in the web player.

Hello.

It is possible to have sprite sheets larger than 128*128 by several methods.

• Write additional sprite data in the code.
• Use multiple carts (multi-cart).
• Use compressed pixel data in the sprite sheet (you can add up to 4 sprite sheets by expanding to 0x8000 or later).
• Graphics generation using reproducible random function srnd(),rnd().

However, dealing with expanded data in the Pico8 environment can be bloated in terms of time spent on management.

If you need to make a longer game in pico-8, you'd need to use multiple carts and pass info between them either with the save data mentioned by 2bitchuck, or with a string parameter passed when switching carts. If you're going to do a game in the same vein as papers, please, then you'll definitely need to put different scenes or chapters in different carts. I can tell you from experience that dialogue and text will take up cart space very quickly.

If you decide you want to use pico-8, then I would recommend figuring out a small number of numbers to save for player data with the rest as flags, as you only get 256 bytes of save data. For example, if your game is similar to papers, please, then the first 4 bytes could be used for the player's amount of money, then the next 4 bytes could be used as a bitmask storing which chapters were unlocked already (4 bytes would be up to 32 chapters), then the next 1-2 bytes could be which endings have already been seen, then the rest could be which choices were made in the current run.

That said, if you want to distribute the game anywhere other than the BBS, you'd have another limit of 16 carts per executable.

Lastly, it sounds odd that you would have those specific options for making the game. Are you sure things like Love2d (which also uses lua), Ren'py (which is good for anything in a visual novel style), or Raylib (which uses C++, but has its own tiny environment in notepad++) wouldn't be better?