This was funded through a Kickstarter, and a lot of backers are pretty bitter over the progress and direction of the project - just check out the forums.
I love the idea, but I'm very sad that this isn't open source.
I bought Voxatron in the humble voxatron debut bundle and i loved it just for what it was at that stage, all the updates past then were just bonuses to me.
I got excited about Pico-8 when I was reading, then I noticed its by the voxatron dev, THEN I notice it says if you already bought voxatron Pico-8 is free?!
I was hyped, now I'm hyped and happy. I was thinking about buying Pico-8, I wonder if this is a good business decision or not... I'll probably be raving on about it for a while now so the word of mouth might be worth $15.
Kinda makes me think 0x10c, developing games within a game. Someone should build hardware for this to run on :p
There are a few partial re-implementations of Pico-8. One is PicoLove (https://github.com/ftsf/picolove) and I've seen reference to another one that generates standalone binaries (I think Terry Cavanagh made it?).
Zeb has said on Twitter that he's fine with people building new runtimes.
Excellent! Really nice demo .. me and the kids are sitting down to watch it together later today and see what we come up with after watching your tutorial. Thanks for that!
PICO-8 is totally awesome. I've built a few simple games, and have been encouraging my daughter to make games. She can't program (yet!) but she can play with the sprite editor and sound editor :)
The limitations really make it easy to not worry and just make a dang game! For those of you worrying about cart size limits: if your game is too big for one cart, make it a two-parter :P
Also, apparently you can load data from another cart while your game is running so you could just chain a whole bunch of them together.
Two things I am really excited for are support on Pi-style hardware, and mobile support for the web player.
My understanding is that with PICO-8 you can export to HTML5. If this is the case, (I haven't used this myself.. Yet.) why would you need direct support for mobile and Pi's? Couldn't you just change the dimensions of the app to fit mobile devices, and take advantage of the HTML5 support while on a Pi?
I want to point out that the console uses a (quite appealing [1]) fixed palette of 16 colors for all of its graphics. I think having a fixed palette is a great idea. I can see it helping would-be game developers overcome their initial art style analysis paralysis and helping ensure that the games have a recognizable "PICO-8" look.
You're right, it looks like much thought went into it. I se 4 distinct human skin tones, or 3 if you include a darker tone for shading, pleasant colors with darker tones for shading and good availability of high contrast (not everything is pastel).
This system is quite amazing. Peek and poke! Extremely limited pallet! An integrated development environment. The restrictions make for some very interesting design choices and force you to limit the scope of your designs -- super important if you ever actually want to finish a game.
I highly recommend this system to anyone. It's great and I've been having a tonne of fun with it. It's no Amiga 500, but boy it has that feel.
Built on Silicon-on-Sapphire process, it was radiation and EMSEC tolerant plus low-power. Used in Galileo space-craft. Highly reliable. It's still sold with a spec that you can fully understand and that documents every state:
So, not just a toy, Octo or CHIP-8 could be used to prototype applications that just run and run and run in the field. Heck, even a retro-gamer might appreciate a system that never freezes past game logic errors.
Eventually I would like to equip Octo with an optional 1802 emulation mode and the necessary mixed-mode assembler for producing 1802 machine code. Probably won't be available any time soon without strong demand, though.
That's understandable. I doubt the demand will show up but it was cool to see them connected in the write-up. Few even know 1802 exist much less why it's worth copying.
Not sure how far you like to push yourself on low-level coding, reading on or doing it. I'll end with these links for your entertainment:
Note: Really wonder what best retro games would look like on 4-bits, esp after hardware acceleration tradeoffs. I always challenge the demoscene to show us. ;)
Note: Manual and source code are attached to comments on that page. Would be amazed at seeing people do anything useful in modern applications with these. They'd win by default on memory/power/area efficiency haha.
anyone in Tokyo interested in this should check out the Lexaloffle HQ in Kichijoji - http://picopicocafe.com
They have a very developer friendly environment (I spent many days programming there, they often hold Ludum Dare marathons) and Joseph is a first class indy developer.
This totally reminds me of Family BASIC. It had a music editor and level editor, and I had a fond memory of playing (i.e. programming) it at a friends house. The biggest problem: its memory storage was only 2Kbytes. A program had to fit in basically one screen. Also when you use the music editor, you had to give up the memory for programs. I kept saying "Phah! Mai-con (abbrev. of "Microcomputer") is so much better!" just like I do today.
Looks like fun! We're building something quite similar to this, but compatible with / inspired by existing 8-bit computers / consoles (Apple II, C64, etc...) Good to see some validation for the space though =)
It means that games download fast and don't need a separate thumbnail. It's the most strenuous limitation but it makes sense in terms of being able to host content cheaply.
I totally agree. The vendors that made stuff like that later made memory expansions for that exact reason. Even great embedded demos like QNX came on a floppy (1+MB). My 28.8kbps connection handled that download fine. Plus, SymbOS already showed us how much more interesting things get with more memory/storage:
The unexpanded ZX81 had 1kB of RAM, of which 672 bytes were usable (and you had to fit your video framebuffer and program storage in there; no ROM cartridges here!).
It doesn't need to do that, though. It's an interesting set of visual limitations, but the size limit is an arbitrary pain in the ass if your program gets too big. Nobody's hosting is going to break at 256kb.
I agree. Those limits including the 32k code limit really focus what to aim for. Google online game editors and there's plenty with few limits and ... No one is using them. To
me it's kind of one of the reasons minecraft has done so well. The limit style frees people from feeling like they need mad skillz
Also note pico-8 limits the number of instructions executed per frame. So a faster CPU will not increase what you can do. The goal is to make sure all games run even on the least powered hardware.
You certainly make a good point. There aren't really any real constraints that make the size so small.
At the same time, I feel the size limit is intended to have the same spirit as the audiovisual ones. Or, if one really wanted the PICO-8's features, but with more space, she could easily recreate the same functionality with another game framework pretty quickly. Perhaps it's almost like a tribute to stuff seen in the C64 demoscene.
Oh for sure it's about "staying on theme" but it's arbitrary. Based on some of the amazing stuff people are doing with Pico-8 it seems reasonable that more space could make it even more interesting. The fact that processing speed isn't a limitation reveals that even such a truncated screen can communicate beautiful things.
As a programmer who's not good at compressing stuff, it would be annoying to have to spend time bashing code to fit an arbitrary limit.
Very cute and cool little environment .. was pleasantly surprised to see that it came with my Vexatron purchase (amazing in its own right) .. a truly delightful little environment, which I'm going to enjoy, very much, teaching my 8-year old to play with .. just like the good ol' days of computing, before IDE's came along .. ;)
EDIT: reminds me a little bit of antirez' LOAD81 environment which is also, a bit of a retro programming experience:
