So PICO-8 is in alpha at the moment, but it feels very much like a finished product. What are the major things that will distinguish the current alpha 0.1.1 from the 1.0 release? Nothing fundamental jumps out at me as 'missing', and superfluous features seem very much against the core design philosophy; so what's left, aside from bugfixing and polish?
Every time someone asks, I press the play button on a tiny animatronic figure I have sitting on my desk of a man playing a tiny violin.
The main things I want to finish for 1.0 are:
- state saving
- finalise the api and implementation so it's unlikely I need to break any carts post 1.0 (although it's unlikely I'll break much anyway, I hope)
- raspberry pi 2 port
- distributable html5 player
- improved bbs: tagging, cart o' the week, licensing
- controls (joystick / touch on web, multiple joysticks)
- better sharing / remixing tools
- better integration with the bbs (it's currently a paint downloading and opening carts)
- fix annoying api bugs
- demo carts (mostly make Jelpi)
and possibly also splore: an internal tool for browsing online and offline carts, although this could be pushed to post-1.0
Any word on the possibility of another button per player? (e.g. "start" button)
(Also: maybe don't count comments for char count? Counting them has no effect on the size of the code written, but a big effect on the ability of people to understand code others share)
yeah a small simulated battery-powered RAM like the old NES cartridges had would be neat. It would open up a lot of possibilities for RPGs.
As a relative coding newbie, excluding comments from character count sounds good too - anything to incentivize commenting! I struggle quite a bit trying to understand what people are doing in their code.
i agree, more code space would be nice, while it can be a fun challenge for a while, it quickly becomes frustrating and gets in the way of making a fun game, i'd suggest either removing the limit or bumping it up significantly, pico8 can offer so much more without the code limit, it's such a nice platform in every other way.
would like to see a redistributable binary (sans devkit (assuming you don't want to make that free) that i can use to distribute my games, the html version's performance isn't great)
having so much fun though! <3
FWIW, the most significant difference between Petit Computer and it's predecessor is quadrupling the code lines available. But that's not my beef. Personally, I'd like to see double the TILEMAP and/or SPRITE space (but keep it simple, like it is!). Keep the mechanics fun and tight, but let the developers explore their potential more.
The sprite space is mainly because I plan to do some fighting game demakes at some point, and that's REALLY HARD to crunch in that little space there is. Detail is not as important in other genres, but with fighters it controls hitboxes and hurtboxes, and most importantly, allows players/characters to be distinctive from one another while relying on more than color swaps. Not that there'll be any shortage of THAT, but you can't really expect a SF game to feature 2 color-variants of 8 different Ryus, and 8 different Guiles or Chun-Lis, and be a "complete game." /shrug
I don't mean to be greedy by that, but enough to flesh out about 5 4x4-tile, simple characters (and then do permutations/headswaps of those) should be plenty. I'm probably gonna try a Light/Rapid attack and a Heavy attack button - crouching Light will sweep and crouching Heavy will uppercut or the like.
That said, the simplicity and elegance is making me real excited at the potential here. :D
Is that being unrealistic?
PS: This really has me jazzed, too. I know it's not THAT diverse, but just imagine:
PPS: FWIW, I'm planning on scripting my obstacles, then creatively reusing the same screenmaps for adventurey games, mixing up what's featured within them. The question is, could a good Zeldalike or Metroidlike be made like that? Those are two of my other 'to-dos.'
Tokens is more like "words" than "characters". Changing THEN and ELSE to colons won't reduce the token counts, long function names don't cost tokens, etc.
PICO-8 coding is all about the limitations. The token limit is tight, and I think it's hard for people to predict how it will constrain them, especially on the first game they try to make on PICO-8. It's a good idea to take the simplest idea you can and grow it, I think.
I'd love to see at least twice as much tokenspace. Also, reconfigurable palette. Still constant in the way you can't change it at runtime, but you could save custom palette along with the cart.
BTW. Dunno if it's intentional, but picocart design as seen in .p8.png files reminds me of hucards.
I haven't hit the token limit yet, but I'm enjoying the discipline of having to consider it (currently at ~2500/8192). It's much more like a mid 80s home computer than a mid 80s PC, which had effectively infinite ram and storage compared to the baseline C64s, Amstrads, BBCs of the time.
[Please log in to post a comment]