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?
Maybe just bug fixes?
I also saw something about adding socket support.
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
I heard that every time someone asks for more code space zep knocks another 64 bytes off.
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)
zep: If you had a Patreon campaign, I'd back it. Just sayin'.
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.
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
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?
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:
http://pixeljoint.com/pixelart/82857.htm
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.'
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.
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:
IF LIVES <= 0: GAME OVER: LIVES -= 1;
^ just using colons to seperate the THEN/ELSE functions
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.
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.
TonyTheTGR, I don't think it's planned from what i've seen. But you can do it yourself (although it might be slow).
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.
[Please log in to post a comment]
