Log In  

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?

P#12285 2015-08-04 16:40 ( Edited 2015-09-08 11:38)

Maybe just bug fixes?
I also saw something about adding socket support.

P#12304 2015-08-05 10:45 ( Edited 2015-08-05 14:45)

moar code space

P#12309 2015-08-05 13:32 ( Edited 2015-08-05 17:32)

The code limitations are, if anything, an INCENTIVE to make amazing things, hard-coded by Zep to
simulate the era of DOS-esque gaming at its prime.

Though I do agree, there needs to be moar code space.


P#12313 2015-08-05 14:21 ( Edited 2015-08-05 18:21)

I heard that every time someone asks for more code space zep knocks another 64 bytes off.

P#12314 2015-08-05 14:30 ( Edited 2015-08-05 18:30)

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

P#12517 2015-08-09 19:54 ( Edited 2015-08-09 23:57)

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)

P#12518 2015-08-09 20:31 ( Edited 2015-08-10 00:32)

zep: If you had a Patreon campaign, I'd back it. Just sayin'.

P#12519 2015-08-09 21:04 ( Edited 2015-08-10 01:04)

A small amount memory for saving stuff in games would be pretty neat. Mainly Hi-Scores but could be used for all kinds of stuff.

P#12522 2015-08-09 21:17 ( Edited 2015-08-10 01:17)

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.

P#12523 2015-08-09 21:32 ( Edited 2015-08-10 01:33)

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

P#12524 2015-08-09 21:55 ( Edited 2015-08-10 01:55)

Doesn't the RasPi 2 "port" just require compiling the program on the Pi? What code actually needs to be ported? Also, is there any chance that this might eventually become opensource?

P#12553 2015-08-10 10:11 ( Edited 2015-08-10 14:11)

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.'

P#13448 2015-08-31 22:25 ( Edited 2015-09-01 02:29)

I'd like to point out that, memory-wise, the Pico-8 is far more low-spec than mid-80s PCs.

But also that's not necessarily a bad thing.

P#13449 2015-08-31 22:32 ( Edited 2015-09-01 02:32)

Another suggestion: Single, in-line loops and conditionals. We won't need more code space if we can better utilize the space we have, like:


^ just using colons to seperate the THEN/ELSE functions

P#13452 2015-08-31 22:41 ( Edited 2015-09-01 02:41)

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.

P#13455 2015-08-31 23:25 ( Edited 2015-09-01 03:25)

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.

P#13457 2015-08-31 23:49 ( Edited 2015-09-01 03:49)

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.

P#13466 2015-09-01 05:38 ( Edited 2015-09-01 09:38)

Plans to eventually feature sprite rotation?

I only ask now because if not, I should probably compensate my project for that sooner, rather than later.

P#13537 2015-09-01 23:01 ( Edited 2015-09-02 03:01)

TonyTheTGR, I don't think it's planned from what i've seen. But you can do it yourself (although it might be slow).

P#13543 2015-09-02 00:57 ( Edited 2015-09-02 04:57)

I'd also back on Patreon.

Any plans for sound in Safari?

P#13552 2015-09-02 06:06 ( Edited 2015-09-02 10:06)

dupe, sorry

P#13553 2015-09-02 06:06 ( Edited 2015-09-02 10:10)

Reason I ask, is that it can already left-right flip sprites; why would it stop there? I suppose for now, I'll just make the sideways-turned stuff seperate... it's just gonna suck to recode later.

P#13827 2015-09-08 07:38 ( Edited 2015-09-08 11:38)

[Please log in to post a comment]