I heard of Pico-8 on the Indie retro news blog, and loved the idea. I quickly purchased the "soft hardware" implementation, and I love it. What a great community, and what a great idea.
I love the restrictions ... except for one!
I feel that the cartridge limit is restrictive. I mean, I know it's "meant" to be restrictive, and I appreciate that it forces a certain kind of game - or at least a certain way of thinking about games - HOWEVER I also feel that the resolution and interface restrictions control the type of software developed beautifully.
With more "RAM" (or is it ROM if we're talking about a cartridge? Soft ROM :)?) we could see some amazing games with great depth catering to the display hardware restrictions.
If simply allowing any size cartridge is out of the question, what about considering several "categories", so we could have 64, 128, and 256k cartridge categories, for instance?

ps
None of this is any kind of negative or "I know better than thou". I love what you have created!

Cheers,

Rob

Very good idea! Prepare to be disapointed though. Pico community doesn't take well such requests for improvements.

I believe it's possible to use multiple cartridges, getting round the "ROM" size limitation, I'm just not sure how one would go about that... It has been discussed though so a forum search should get some info on that.

I'm glad someone new came via my article...
mission accomplished :D

i personaly like the ram limitation, part for clever thinking, optimization and in realism,
playing with the gamebuino (a arduino based console)
and working on my own real version of the 'pico 8 like' on hardware (curently working on an arm cortex m4, no lua yet) the limitation is very real.

i do agree with the idea of a multi carts or atleast carts loading in other cards to expand there limitations (like final fantasy swapping disks on the playstation)

has anybody ever brought the concept of ROM banks to the table?

it's a feature i'm familiar with from programming older PCs & game consoles, where cart ROM has extra banks which do not fit system RAM, and you swap them around during runtime, almost a kind of precursor to loading in CD & HDD based games.

this sounds like something which might fit the pico ideology, making you think about your code & structure in a different way and still introducing its own form of limitations.

it has always seemed to me like the code space limitation was a bit overzealous, as even the NES (i cite this only because that's where my experience lies) had a standard cart size of 128-256k. im not really taking a stance here, but i thought i'd offer the idea.

I made a slight suggestion a while back for something I called a "chip".
They're essentially small, minimalist libraries that you can load in a cart. The current spec for the idea is something like roughly 1/8th the size of a cart, with the ability to load 4 chips into a cart.
A chip could potentially hold anything that a cart can, just less of it.
I've been wanting to do a prototype of this idea in PicoLove, but I haven't had the opportunity to do so yet.

Personally, I'm largely fine with the limitations. It's like a programmer game. "How small can I crush this code".
Just follow the normal advice for gamedev, i.e. keep your scope in check, and you'll be just fine.

All excellent responses.

lululululu ... after I wrote the first comment here, I was pondering bank switching too. With bank switching, you can switch in and out as many banks as you have, but can only have one at a time, and all previous bank content is "lost" when you switch in a new one.

I was also pondering that larger carts, or a similar idea, could fit into the idea of an expanded "fixed" machine.

The Commodore 64 received some third party bank switching tools, a RAM expansion add on (I can't recall the capacity), and even the might Super CPU that gave it a 20mhz processor instead of the 1mhz built in one.

Again, I'm certainly not complaining, or even saying what I propose should happen ... I just like the idea :)

The chip idea is cool, too, fruckert.

And I LOVE your real hardware implementation adekto :)

The NES had that cool thing that were separate CHR (graphics) and PRG (code) roms on the carts. The idea would be to introduce few additional rom types (map, sfx, music) and allow people add up to 4 roms, the size of regular space for that specific data, as seen in the current format) of each and switch each one independently.

Kinda like something between bankswitching and chip idea. Obviously zep wouldn't ever do that, but here's my 3 cents. 😠

wel idk but the limitation that have fallen into atleast in hardware is not so much the storege size but the ram size, we are dealing with an interpreted language meaning your limited by ram the carts are designed around that so called limitation
as an example one of my chips has 64k of ram if it had a lua interpreted, graphics buffer and some sprites i would have less then 32k of ram left for programs, sure i could swap those out but as a biginer programmer thats like a bit complicated.

has anyone looked at Cartride Data? im not entirly sure what that is, but could be used as a game save for a multicart games

i'm actually using cart data for a multicart game project right now. it solves cart limitations issues but introduces multisource logistics to manage, which can be a biit of a headache. the code tabs feature zep mentioned elsewhere would help with that though

I agree that raising the data limit would enable some fairly epic cartridges, and I periodically come back to reconsider it, especially after seeing stuff posted on twitter recently like this Link's Awakening map in PICO-8 resolution by Johan Vinet and a Golden Axe demake mockup by Christina Antoinette. I think these two are good test cases for what we'd generally consider to be large games. They definitely aren't manageable with the current limits.

The reasons for keeping a small capacity are more subtle and perhaps personal taste -- somehow trying to make a big game in 32k feels exciting, but I feel overwhelmed at the prospect of what I'd do with 48k or 64k. Separating sizes by category would definitely be the way to resolve this -- there is already this kind of separaton with an emerging distinction between 'development' vs. 'consumer' functionality. e.g. it's possible to pull data out of other carts while developing and making tools, but there's no supported / official way to do that reliably for published cartridges. So I am keeping the chip / ROM expansion idea in the back of mind while I get a grip on how this is going to play out. The arguments I normally end up with for keeping the lower capacity:

1. A lot of people enjoy PICO-8 as an escape from feeling pressure to make large things. Seeing other epic cartridges or knowing you have a bunch of unused space eats away at that -- but that could be partly alleviated by having commonly understood categories of cartridges.

2. It is possible to make pretty big carts though, and a much more more inviting challenge at 16k of data (to me personally). I was able to compress the graphics in the Golden Axe mockups to around 11k and something similar to around half of the Zelda map would be plausible in theory. So not massive but I think a substantial size, and so much more glory in pulling something like that off!

3. The code size and data size are intended to be complementary. Putting aside the task of trying to make impossibly epic cartridges, if you follow your nose and write code and make graphics / maps without planing ahead too much, you'll probably run out of code first. This was an argument for increasing the code size earlier on that I agreed with and bumped up capacity around 20%, and I still think it's a little short (there may still be some token-counting tweaks). Adding extra data capacity would disturb this balance again somewhat.

4. Having more data steers developers towards content-driven carts, as opposed to novel rule-driven games or more abstract designs. Making an RPG or long platformer aren't off the table, but they're not first thing that spring to mind given that you're probably going to run out of mapspace pretty fast without doing weird data management. Either way, you have to do something interesting and probably go down a path you're not used to, which is appealing to me. There are a bunch of unusual games I want to make in the future that I sketched as a result of working around the data limit, and I feel they would lose their meaning to some degree without that limit.

Personally, I find the current token-based system for code limits to be more limiting than the overall cartridge size or graphics limits.

It also feels like the least realistic / arbitrary limitation of all the other choices made so far for Pico-8.

I feel like a system based on the size of the lua opcodes or the amount of memory the code takes would be a much fairer mechanism than the current system. It would also be more reflective of older systems where if your program could fit into memory in its assembled form, you were "good to go".

As an example, at the moment I'm working on a game where the map generation and simplistic title screen / map selection code alone has already taken over ~2400 tokens (even with a fair amount of minimization effort by me). Since I haven't even written the actual gameplay logic yet, I'm concerned that I'm going to only be able to implement "half" of the game I want before I hit the token limit.

With that said, I too would be happy to see options for other cartridge sizes, but I would encourage the idea of there being some sort of tradeoff. And I would encourage keeping the number of options limited (e.g. perhaps just 32K and 128K cartridges).

"real" console systems (I know, I know, Pico-8 isn't intended to be one) generally had tradeoffs. For example, they may have had greatly expanded space for graphics memory, but not program memory.

I definitely come under point 1 here. Regardless of its implementation, I have always loved the limit of PICO-8, precisely because it takes the pressure to make something 'big' away, and encourages making something that's small and fun.

Rarely do I get anywhere near the limit, with my mostly simple games, but it helps me to know that there is only so far I could take a given idea. It makes moving on to the next idea easier, and, crucially, pushes me to finish/polish games a lot more than I have previously,* since it's harder to 'just add more stuff'.

I would not be opposed to a way to add more code or sprite space, in the interest of more games and more complex games. The stuff people have managed to do with <=0.1.1 is really incredible. I think a chip/library system would be really neat, as I definitely find myself throwing together half-baked frameworks of code in each cart. Or maybe there could be something within the fantasy console product line, like PICO-8 CLASSIC and PICO-8 DX, where CLASSIC maintains the original memory limit and DX extends it in the way a RAM add-on might.

Anyway this is a great discussion and I'm excited to keep making more PICO-8 stuff, thanks zep and community! :)

*This is not to say that my games are finished or polished, heh.

I got it!
Let's say here's a sort of variable system going on, just for explanation.
Well, it could walk you through a setup mode, with five settings:

1. How big do you want your cartridge? (16k, 32k, 64k, 128k [?])
2. How big do you want your map? (None, Small, Regular, Large)
3. How many sprite banks do you want? (1, 2, 4, 8)
4. What's the amount of sounds that you'd like? (None, 16, 32, 64, 128)
5. How many patterns would you like? (None, 32, 64, 128)
   "Enjoy creating your cart!"

If the option of "None" is selected, then don't show the tab for the editor!

what gets me baffled is, in response to your #4 zep, it feels to me like the pico-8 represents much more of a content-based dynamic, and i believe the best argument for that is the things people tend to post on here. there is a large gap between small programming experiments and the games which push the system to the maximum, which seem to very often be more content-oriented.

there is so much map and sprite space proportional to the actual amount of interesting things you can code them to do with the current token limit. in my experience, making use of the code space efficiently has always meant heavily templatizing the rules so that the interesting parts of the game can exist in the sprites, maps, and sounds.

this has been true for any project of mine which has exceeded the ambition of, say, an atari-2600 scope game? which i feel is an overzealous limitation.

i have noticed two sorts of general outlooks on pico8? one which likes it as a small hobby curiosity and the other which wants to be able to embrace it as a platform. it seems to me like the goals of these two are generally opposed, but it remains true that the pico8 doesn't give much space for ambition and growth within its limitations after a point which, in my experience, is very easy to arrive at.

what has always felt most valuable to me about pico8 as a platform isn't that it forces heavy limitations but that it offers a different way to interact with games & etc. that is removed from prioritizations over graphics & fidelity & such. it normalizes a space for people to make things that would elsewhere, say, look ugly or sound weird or don't have all the typically expected gameplay features, but are perfectly worthwhile here.

okay i've got it all out i think :)

When discussions of limits come up, I ask myself: if there were a Pico-16 with double everything, would I use it?

Limits are essential, even definitional, to Pico-8. So what do we like about Pico-8, and to what extent do the current limits contribute to those aspects? It's exciting how people seem to be attracted to Pico-8 for a variety of different reasons: the pixel aesthetic, the graphics and sound editors, the simple APIs, the resemblance to small computers from an earlier time, the overall mission of capturing the spirit of gamedev on those small machines, the charm of editing in situ, the BBS, the community. The design of Pico-8 includes all of these things, and if I'm interested in some of these things more than others, then aspects of the design not related to my interests might seem arbitrarily limited.

What effect would increasing those limits have on the dev experience, and on the community? Having been alienated from gamedev by the increasing capabilities of hardware once before (I pretty much halted childhood gamedev when I went from a C64 to an Amiga 500), I'm pretty sensitive to the subject. For me at least, Pico-8 gets less interesting the higher the limits are. Having just one kilobyte more will always seem like a good idea, so where do you stop? And at what point are we better off just using HaxeFlixel or Love2D?

Interestingly, so far nobody has suggested that Pico-8 should increase its screen resolution. Discussions about increasing limits have focused on code space, and to a lesser extent map space. This suggests that different limits have different effects on the dev experience. I suspect many P8 devs are excited about fitting a large game into a small space, but the smallness of the code or map areas aren't what's important to their enjoyable dev experience, whereas the smallness of the display is more essential. Cart "categories" feel a bit like Pico-16 to me, but maybe it isn't because of the dimensions involved.

I like lulublululu's point about a bifurcation of interests between small games and large games. I value Pico-8 as a gamedev sketching platform, and as a community for sharing sketches. Large Pico-8 games are super-fun and very inspiring, but even within the current limits building a large game is ambitious. I would bet that with larger limits, the small and the large are still the most compelling categories, and all increasing the limit does is increase the skill/resource gap between the two categories. The narrowness of this gap is an important part of the fun.

Firstly, thank you so much for taking the time to respond, Zep.

I feel both you and lulublululu have put forward far more realised thoughts than my initial humble ramblings were able to express.

I feel enormously in support of the way lulublululu expressed the two views on the pico8. To me, I love the idea of it being a real platform with games that tend to reflect the graphical limitations. You know, that's really the core of it for me.

I see that a large group also see it as an incredibly beautiful way of working within tight limits and being creative. That's not me. I'm not the worlds best coder, although I've published games in my distant past. I find the token limit frustrating because I'm not good enough to find better solutions.

Me up vote 1 for token limit well ahead of graphics / tile / sound space.
I agree with binarycrusader and lulublululu, at the moment I actually feel constrained by the rules I can implement, not the graphics. That is by design, of course, but MY choice would be to allow vastly larger token counts, and I'm not too fussed in regards to the limits on "everything else".

binarycrusader, I'm not sure addon hardware for old machines actually had tradeoffs as such. I mean, obviously they were attempting to do things beyond the original scope of the machine, but the biggest tradeoff was usually the cost of the upgrade, which could be fiercely expensive. Also, I guess the biggest restriction was why people would bother developing for the addons that would mean their game could only be played on 1% of the system's user base.
From memory, and please correct me if I'm wrong, something such as the SCPU on the Commodore 64 had absolutely no downside ... other than costing 5 times as much as the actual computer, and therefore being owned by about 7 people :).

> has anybody ever brought the concept of ROM banks to the table?

@lulublululu I mentioned it, but didn't put much more thought into it - too hard ;)

I really like the current limitations of pico-8 (though a slightly higher token count for code would be good).
But I think that there should be some way to make longer games. I like that the restrictions of pico-8 make it interesting and refreshing to develop for, but for me it also means that I'm less likely to even try something if I think I'll want it to have more content than there is room for.
I'm in favor of having a larger cartridge size (probably with a distinction that this is a bonus size and not the normal)
My goal for the size would be so I could make something along the scope of Super Mario Land 2, which is a 512 kB cartridge, though I'm not sure it needs to be that big.

I also like the current limitations. While remaking a large game like zelda seem attractive, you dont realy need the whole game to evoque that nostalgia. I personaly prefer releasing small games regularly than working on a single project for months.
I think a multi-cartridge can be a good system to make longer games but avoiding feature creap. It would be more like an episodic system. If your game is well received, make a sequel (with new levels, reworked enemies ...) instead of directly working on a long game.
On the code side, changing the token system or slightly rising the limits may be good.

My 2 cents about the token system:

Although having some kind of limitations on code size is necessary, the token system as it is currently designed leads to strange stuff that does not reflect anything in reality.

For instance someone pointed in another post that you can save one token by making function calls without parameters with myfunction"" instead of myfunction()... This is typically the kind of optimization that makes no sense and only leads to less readable code. It is not even a smart optimization: once you know it you do it! The token system leads to all that kind of awkward optimizations... I know that every system has its own oddities but still...

Why not simply trying to map assembly/opcode instructions to count tokens instead ?

Something like every instruction costs 1 token: function call, parameter, assignment, addition, abs... regardless of how many parenthesis there is! Maybe some calls like trigo or sqrt could cost more tokens also.

A design like that would be far more consistent with actual hardware I think and still easy to understand for users.

i'm super for the idea J-Fry put forward. it sounds a lot more intuitive than the current token system. i have produced a lot of very weird (and bad in any other context) code accommodating the token system. it feels specifically limiting that things like a single function call or an array access cost 4 tokens at minimum, maybe the bandaid solution to that is making parens/braces/brackets not cost tokens though.

i think the current limits on sprites/maps/sound are at a sweet spot but maybe the code portion isn't there yet? that is how i've come to feel from my time with the pico-8. i can fully express my ideas through everything but code, coding sometimes feels like constant austerity instead of a kind of liberation via limitations.

To fix tokens:

Make commas, parenthesis, and periods/colons equivalent to whitespace. They're abstractions denoting a specific correlation of two points of data, not a symbol in and of itself. If you're calling a function with two arguments, "funcname(arg1, arg2)" is actually 3 useful points of data, "funcname", "arg1", and "arg2", not 6 just because there are arguments at all.

Look to assembly code for inspiration. At the assembly level, which translates quite directly to bytecode, do you write "function, begin_arguments, argument1, argument_seperator, argument2, end_arguments" as that many different individual tokens? I don't think so. :P It's more like "push argument1, push argument 2, jump to function" isn't it? Three commands.

@JTE: +1, that would help a lot.

I'm personally of the opinion of doing some sort of opcode counting, but I don't know how Lua internally works, or if it even uses opcodes.

Of course you'd still need to count the .. operator as a token, since that's actually an operation like addition, subtraction, etc.

Unless you want to go all the way and make it so that "x = y + 7" is only three tokens as well, neglecting the operations and again only counting the "data points"? I'd be happy either way on that one, really.

Hmm, I'm sort of derailing the topic here, though. Perhaps I should've made a new thread. @_@; Yeah, this one is supposed to be about RAM banks, not how to fix script token counting, whoops.

Here's a new thread to discuss tokenizing changes in, then.

I'd say it'd be best to do away with token limit and keep old character limit instead. I think this would make everyone happy.

There is a (non-standard) notion of Lua bytecode in the reference implementation that looks a lot like Lua without punctuation. I think everyone is on board with the idea that the limit should be intuitive to the developer and that actually counting bytecode ops would be unnecessarily obscure, but I'll say it anyway. :) IMO the compressed char limit qualifies as obscure, but in practice it's not an issue when the token and uncompressed char limits are in place.

If you're just looking for a few more tokens (and not, say, twice as many), it's notable that picotool's lexer counts fewer tokens than Pico-8's lexer, and I think picotool makes some pretty sensible choices (but I'm biased). For example, in Pico-8, ".." is two tokens; "..." is three tokens; 10e5 is two tokens. picotool accounts for these and still consistently undercounts, so there are more I haven't pinned down. It's not by much, but if 100 tokens would make the difference in a cart hitting the 8192 limit, tightening up Pico-8's token count might offer it.

Going back to just character counting undoes an important rationale for token counting in the first place: we want variable names and comments to not be constrained by the dominant limit. Empirically, the current token limit offers somewhat comfortable headroom in the char limit.

And obviously, increasing the token limit significantly (such as by not counting punctuation) would also require increasing the character limit. There's also a user experience factor in play with the character limit: the built-in code editor gets more difficult to use the more characters are allowed. I don't know if we've seen this limit yet, and existing editor features like method jumping are already helping with this. But it's worth noting.

I can only speak as an expert pixelartist and amateur chiptuner, since I haven't coded enough to reach a limitation in code.

Color count and screen size is not a problem. I can say anything in Pico 8 that I could say on a gameboy screen. Maybe more. (Well, I could use a proper dark blue that can be ramped with the light blue, but that's it. To be frank, I'd make the dark blue a bit darker and use it as black, and I'd then assign black to a proper dark blue) And the challenge is very real, I feel the right amount of motivation to make art for Pico 8.

Space for art is a problem. (and demotivational, at least for me) Although pico8 can handle a screen-filling boss with ease, performance-wise, having one screen-filling boss leaves you no space for a level and animations. Much less a second screen-filling boss.

Also, 8x8 sprites are kind of forced on you. Yes, a 16x16 sprite is possible and looks exponentially better, or even 16x24. But it isn't plausible, because of cart space. Think of all the animation states, multiply them by at least 4 frames (that's what it takes for decent animation to read) and you're quickly out of space, no matter how much optimization you do.

If all my Golden Axe mockup graphics can fit inside one cart, with compression (and of course additional painstaking tilemapping and creative pixeling on my part, I don't shun hard work) I'm super happy, it will make for a cool slideshow/demo cart.

But gamedev wise of course, that doesn't account for the dozens of animation frames needed for the sprites in a game like Golden Axe or Xenon 2 (mockup/demo coming up soon). So, more realistically, each stage would have to be its own cart. For the music too, if you don't want procedurally generated music, or tiny repetitive loops.

And then we'd have to have the option to load carts on the fly and package games as a collection of carts. And then a Pico8 cart isn't like an NES cart any more, because even though the code/performance specs are comparable, the cart space for graphics isn't. A NES game spanning one cart per level would be ridiculous, and wasteful of all that code that has to be repeated on each cart.

Same for any kind of representational art. Yes, you can make a platformer using the same tiles all over, but for game art to properly shine you need "flavor" art here and there. This is true no matter how far back you go in 8-bit gaming: world-class games have flavor art to break the repetitiveness.

Limiting the graphics to one cart and asking of users to be very very code-savvy and peek/poke into memory in order to fit 25-50% more art, is clearly, in my opinion, pushing in the direction of games that either have mediocre art or require really genius coders (like space trader Elite did in its day).

It becomes another case of highly knowledgeable programmers getting most of the freedom, and more visual/artistically oriented users like myself being left in the dust. Because if code can help pack more art in a cart, why bother having an easy to use sprite editor at all? Why not load 50% more art directly into code somehow?

What do y'all think?

I very much want Pico-8 to be a satisfying to use without a fancy toolchain (compression etc.). I also hope techies exploring toolchains doesn't alienate devs that don't want to use them, since that's its own kind of fun. I'm inclined to think this is unlikely to be a problem in practice, but I'm sensitive to the idea. My personal interest in toolchain building comes from my disappointment as a kid discovering that all the best pro games for my favorite 8-bit were cross-compiled from bigger hardware, and not written directly on the device. (But I also didn't have access to a community showing me what was actually possible to do without leaving the device. I needed an older sibling or something. :) )

I'm not sure how save data works in the web player, but if all the carts on a page (for instance, all the carts in the first post of a thread) can share the same save data by inputting the same cart name like they can offline, I'd say it's a safe bet you could get away with just a "Please insert side B" screen at the end of one cart's level. That would be "good enough", if it works. I don't know, though, because I haven't seen any carts actually use save data at all yet, weirdly enough.

EDIT: The web player doesn't support save data at all! D:< This must be rectified!

... But my completely-missing-the-point aside, there's a delicate balance between programming and art. I would agree that you, as an artist, need to be given better tools to work with to make your games come true. But at the same time, when technology progresses to the point where machine limitations aren't so strict anymore, artists with very little game development experience come in and make games entirely by themselves and clever programming is no longer a relevant statistic anymore.

Forgive me for this rant, I just don't want to be made to feel useless when I already have only one talent. :(

I read you, JTE.

I have a lot of game development experience. I used to code on the C64, have participated in 10+ game jams, etc.

And yet art is still what I do best. I myself don't feel useless in PICO-8, I just don't feel motivated to try fitting the bare minimum of art through micromanaging and unreadable code.

I don't think you should feel threatened. When artists are given tools, you are not being robbed of tools. And vice versa. It's not zero sum.

Everyone is right :) (in my very very very humble opinion).

It seems we all love the colour and resolution limitations (effectively what I personally define as PICO-8, along with the brilliant built in tools).

We are split over the limitations to graphics / audio / code.

Personally I want no limit on any of those three areas. Nonetheless, I see why really amazing coders DO. I am not an amazing coder. I am a terrible artist. I don't want to compress and I don't want to write unreadable code.
In my day job I'm a solution architect. I love really readable code ... at the expense of performance.

I want bigger carts, much bigger carts, but with the option of course to use the "hardcore" 32k carts for competitions and the super-men coding.

I'm probably being annoying and going around in circles, but it feels like a reasonable summation of what has been expressed.

Cheers all,

Rob

I just want to be able to use more CPU :x
Having a full texture-mapped 128x128 3d game written in pico would be absolutely fantastic.

I feel the same way about the limits, they're a lot of fun for the challenge and great for getting started. But once you get started and are up and running they can become more of a hinderance to development, I especially notice this with the code/token limit, I'll spend a lot more time working on trying to fit more code in than actualling making my game more fun/interesting/etc.

I like the idea of having a hardcore limit mode for competitions and a less strictly limited mode for casual funtimes.

That's why I developed picolove which is a lot more lenient with the limits (there's no code limit or cpu limit and you can choose what limits you want, increase the spritesheet size or tilemap size if you want) and lets you keep working on your game once you get stuck on them while still keeping the pico8 look and feel and being able to load your pico8 carts (hopefully ;).

I think that it would be a great thing if we can develop a small game, an experiment or a big complete game. Limits in graphics, colors, screen are good but not in code, I think. I'm not an expert programmer, actually, I only know the basics so it's really complicated to optimize my code.

I've been avoiding this topic becaues I didn't have much to add. I've bitten my tongue many times about ideas for changing the limits (even a conservative suggestion for what to do with th extra palette space.) But comments in this thread have been on my mind a lot.

What draws me to pico8 is partly the integration of the tools, but more than that it's in line with what zep said about the content balance. The limits encourage working on the behaviour more than the media, and going beyond the surface limits to the media involves introducing behaviour under the hood. It's elegant in an artistic sort of way. Let me put that in a stronger way: pico8 is itself an artwork.

I sympathize with wanting to break free of the limits at times. I would love to see a full Golden Axe game for example. But I do value the artistic basis of the application itself more than any of that. Some of you probably disagree, and there's nothing wrong with that—there's something about art that begs different interpretations, even when it comes to contradicting the artist's intent.

With that in mind, my own take is pico8 is roughly where it should be. I resist the idea of moving the lines because there's no place to put them that will scratch all itches, and it can degrade (or alter) that charm if done too much, even though I have a few ideas that I think would do wonders without compromising on charm. I try not to argue one way or the other much because it's not my baby. On the other hand, it's not a painting and it loses nearly all of its merit without the community that uses it.

@smosher, that's totally fine. I can still make mockups and music with Pico 8. It will be my last choice for making a game with good pixelart graphics though, due to the gfx space limitation.

It's as if when the NES first came out, it was limited to making either full games that looked like the Atari, or impressive tech demos that looked amazing. It would be needlessly punishing.

I think the design idea "the harsh limitations of PICO-8 are carefully chosen to be fun to work with" means different things for different people (I find not being able to fit nearly enough graphics in it spoils the fun a lot) and is differently applicable to each component of Pico 8. The graphics editor, map editor, music editor and code editor are incredible. The graphics storage is underpowered in comparison. In my opinion.

ETA: oh and may I add, the color limit is fine with me, but it seems it was designed with 50% dithering expressly in mind. However some current pixel artists, including myself, think 50% dithering is abysmal-looking, and is in fact a form of banding. Banding is the enemy of pixelart, so some of us don't use 50% dithering. It means we're stuck with other forms of dithering where pixels don't touch, or the 16 built-in colors, andthat's totally fine. So long as someone doesn't claim "omg you can dither black and green to make a darker green, the pico8 palette is so versatile", because that isn't true strictly speaking. What I mean to say is, because pixelart is my area of expertise, I can safely say the gfx limitations are harsher than assumed. Therefore, some leniency with the graphics storage space would help a lot (for example using black outlines around sprites helps separate colors, but outlining sprites wastes precious graphics space right now and is prohibitive).

I'd say PICO 8's graphics limits re: pixelart were reached quite a bit before 3D graphics limits or code or music limits, and there's no optimization possible, no hidden space we can exploit for more gfx. Therefore there's no hope of expanding and improving in that area. The territory is known, no exploration left, except how many sprites you can recycle here and there.

@castpixel I think the sweet spot for seemingly larger games is in ones with generative content. Without that you will often need more room not just for art but also code to get everything you want to fit in the cart. Not exactly your wheelhouse, I know. Honestly I think that's new to most of us, even the ones who write code for money.

What attracts you to Pico8? That's not meant to be challenging in any way, I'm genuinely curious. For me it's probably something different than for you (I've been wanting to explore generative content more), but I know we both see limits that we will need to address by other means for some works. Pico8 has inspired me to design my own graphics tools and audio/video framework for building games. I've gone with graphics and audio libraries before and always felt like something was missing, Pico8 turns that all inside out and I'd like to hang on to that experience when doing larger projects. That's how I plan to scratch my various itches, but Pico8 will remain a great playground for experimentation for me.

Btw to all,

I don't know if this reflects any part of the community, but what attracts me to Pico-8 (not that I've put up anything I've been working on) is the graphical limitations ... that's actually it.

My mad dreams that don't even completely make sense are of a Commodore 64 with the display limitations but without the 64k or 8 sprite limit. I just imagine the amazing things people could do ... but never will :).

@smosher if you see Pico 8 as an exercise in Procgen, that's fair, even though that's not the intention of Pico 8. While I do care about procgen myself, I'd rather dress it up in handcrafted pixels.

Since you ask I'm attracted to the small resolution, as I'm an expert in those. Counter-intuitively, since nobody really needs to make tiny pixelart any more, let alone do it to perfection. I'm also reminded of my youth spent poking at the ZX spectrum and C64: machines, especially c128's sprdef.

I'm just saying that the best-looking games that the c64 could produce (Mayhem in Monsterland, Critters 2, Bod Squad) are impossible in pico 8 due to the graphics size limitation. Altough performance-wise Pico 8 is a lot stronger in many ways. There's an imbalance. If you don't care about the imbalance and decide to design around it, that's smart too. I care about the imbalance and decided to ask if something can be done about it. NES games and C64 games could always expand their cartridge space (NES up to megabytes I believe).

Unless you're saying Pico8 should not be a tool for making games with pretty pixelart. Then I disagree, and all I see is wasted potential. My understanding is that Pico8 was designed to do 8x8 sprite games best, like the excellent Celeste, and I'm liking the idea but can't help but be underwhelmed since it can do so much more

If I ever find myself hitting the token limit (which I haven't yet, I'm not that ambitious with PICO-8) I will probably consider re-creating my game in Love2D and coming up with my own method for generating low-res graphics.

I do like the idea of size categories, though, since if you wanted to fit your game in the small size for 'bragging rights', or maybe even have a game contest using the original size limit, you could still do it.

Ha ha, oh that's right. Pico-8 is actually an open-ended sandbox game itself where you have an absurdly powerful CPU and absurdly limited space and you can basically only make GameBoy Color games with it. Yes, the platform itself is an artwork.

That's why my magnum opus is to make Kid Radd -- an NES-era game. Because packing in the necessary sprites involves a lot of hacking together piece mashups (mostly because the head poses don't change a lot anyway) and palette remaps (mostly because the faces are expressive, so I colorize them to show some pixels and hide others on the same reusable sprite) and I'm still running dreadfully low on space and having to cut corners everywhere.

I couldn't even imagine making an SNES-sized game like Golden Axe on it unless a cart was made specifically to compress page after page of sprite data into a super dense string which would then be taking up half of the precious code space... But that could still be workable. Swapping sprite banks is definitely the direction Pico-8 should go in, because it's already not impossible, it just doesn't have a good GUI for it, the tools to use it aren't easy as they should be, and there's no space allocated specifically for more sprites that aren't in "active use" (you'd have to stuff it into the script or map space or load it in from another cart -- somewhere.)

I love the idea of using Pico-8's limited 127 (or 255) sprites as merely what you can actually show on screen at once, while you can just swap out the data as needed when you transition to different scenes. A concept of video RAM, rather than a fixed and unchangeable data store you plug in ahead of time. There just needs to be space and utilities for it. Which don't really fit into 32 kilobytes, I guess.

But then what's to stop you from just swapping out sprite banks constantly mid-render? Hmm.

You know what else would go a long way? A start button. Right now the only thing you can do is steal player 2's controls. Which isn't something you'd ever have to do on a real console unless you're inputting wacky developer cheats.

@castpixel No, I don't really see it that way, I just think that's the sweet-spot for larger things.

Honestly I'm just glad it's not up to me what to do about resource limits.

@zep another option could be a PRO version of pico-8, that has more ROM/RAM + x2 tokens or something. I really want one :X

@egordorichev PICO-16

I was just looking at the specs of the Atari Lynx and read this:
"16 simultaneous colors (4 bits) from palette per scanline (more than 16 colors can be displayed by changing palettes after each scanline)"

Can something akin to this be done in Pico-8?

[semi-simulated image]

@Slybo

There's a few experiment carts out there on the bbs that do something similar by alternating what pixels' colors are on a sprite so that between frames of refresh it appears the two or three alternating colors make a 'new' color. It's really just tricking your eye into seeing red then blue then red so fast betwen frames your brain sees "Purple".

Easy enough to do in theory.. Just set up something like a table or two of colors and then use the palette commands between alternating frames to 'draw' the sprite in the colors in your table.

Me, I'd like to see (Even if limited to a tiny amount of k) read/writing of 'text' files for storing/reading datas.

You can always use a separate cart with cstore/reload if you want to have more data. Not more code, but more data. I'm doing something right now that gets a background image from a second cart.

PS: The annoying thing is that damned spinning cart icon that comes up while loading from it. Is that really needed, @zep?