A while ago, Darkhog spoke of a large list containing codes for PICO-8.
Since I don't have a source of income right now, I decided to look for it.
I found it, and used elimination to snag me a copy of PICO-8.
For treasure hunt reasons, I can't say where this is.
All you gotta do is look ;)
But I hope to crank out some games quite soon!
The first being a remake of my Gamebuino game, Smash and Crash!
Thanks for being a great community!
A friend pointed me in the direction of PICO-8 last night to see if I'd be interested in having a play with the tracker so I grabbed a copy (Ubuntu 64-bit, works a treat) and had a go. It's a piece of cake, loved it so much that I decided to have a try at making a classic Amiga/ST demoscene/cracktro screen to go with it. It was a doddle!
If you're wondering what the demented-looking face that's sinusoidally twerking its way over the screen is, it's the protagonist of an Atari 2600 game I wrote a few years back: https://www.facebook.com/thewickedfather
Issue #1 of the community-made PICO-8 zine is out! You can order the 48-page printed version via pico8fanzine.bigcartel.com for a nominal fee, or download the pdf (mirror).
Much respect to @arnaud_debock and contributors for putting this together -- it's humbling to see the world of PICO-8 extended in such a creative and kick-ass way. Issue #1 includes artwork and articles by @dotsukiHARA, @bitmoo, @TheRealMolen, @pizzamakesgames, @PROGRAM_IX, @aliceffekt, @modernmodron and @terrycavanagh. I also took the opportunity to write something on the history of PICO-8 and it's relationship with other Lexaloffle projects.



I thought I'd make a short log of what I'm working on at the moment and my thoughts on the lovely PICO-8. First, let me say that since I work with Love2D I like being able to use Lua. I'm working on code for pixel-perfect collisions because I can make shaped sprites and perhaps get better use of real-estate. That is, I can make more complex levels in a smaller screen space. The dream is a simple metroid-style game with items to find.
Unfortunately Pico-8's implementation currently still has a few small bugs. Actually, scratch that, there's no such thing as a small bug in a code editor when that bug could prevent a perfectly good game from compiling and running. That said, I've had fun making my little game but I think I'm going to take a break from PICO-8 and go back to my other project(s). I've been having a ball with Love2D's physics engine and I've got to get back to that. I'm not leaving PICO-8, I'm just waiting for an update.
Also, the code limit makes me sad. I really like this one PICO-8 game, Tempest, and I hope the author will figure out how to fit in everything they want, but it sounds like they're still cutting it close to the eight-thousand-something tokens. We'll see what happens soon enough.
A quick Speed-Modeling I did for an artist on deviantart who's comics and artwork I enjoy immensely... :)
https://www.youtube.com/watch?v=N-Ye1EDo944
Also, go check out her stuff: http://tamarinfrog.deviantart.com/
Hey, if you want music for your PICO-8 game, just hit me up. I'll make you some. Free of charge, free of obligation. I'd do it for the bleeps and bloops.
To elaborate: I've been shocked to see lots of games for PICO-8 that are otherwise freakin amazing, especially the idea/coding/gameplay and art part, just flat-out not having any music, which is just so sad. So please, if you have a great game and you don't have anyone to make some music for it yet, and don't plan on making music for it yourself, drop me a message. I'll gladly track some tunes together. I'm no Tim Follin yet, but I've been at it for a while now, and it started to come kinda easy.
Here's an example: https://www.lexaloffle.com/bbs/?tid=2102
If I'd make music for a game it'd probably be less prominent though, just in case that'd be a concern of you. This track is just so powerful cause it was meant to stand on it's own as a cartridge. Well, except for some violently flashing text and pizza.








The last inventories thing I needed for 0.3.3: adaptive formatting (an extreme example). Each inventory item is assigned a group (left, middle, right), and it does its best to figure out how to format everything in a sensible way that doesn't jump around too much and doesn't overlap. I had to be careful not to end up with a 1996 html table renderer!
It's possible with the new inventory system to display the capacity of an item (e.g. empty slots for up to 5 potions), to draw different icons for wielded or carried, and to draw different icons depending on how much ammo each one has.
To handle 1p vs multiplayer inventories, you can tag animations with context information -- how many players should exist for them to be displayed and with which attributes. For example, a single player inventory might show a row of potions, but when playing multiplayer it might be displayed as a single icon with a number to save space.
There's not long to go before 0.3.3 -- just a few microscripting details and converting legacy cartridges over to the new system on load. 0.3.4 will be a smaller follow-up, so let me know if there's something you're hanging out for, and I'll see if I can bump it up, or make sure it will be possible with Lua scripting later on. Things that were recently mentioned and are already confirmed:
- pico-8 music tracker and music triggering (and some new music!)
- custom inventories with selection and/or button bindings
- inventory microscripting (check for number of arrows in a quiver etc.)
- items that share the same ammo (e.g. all spells cost MP)
- id duplication and aliasing bugs after copy/paste
- fixed density allowing actors to sink in liquid
- scroll-wheel zoom, mb3 camera movement , alt-click mb2 emulation
- fixed total playtime bug for speedruns, made restarts faster
There are a few things that are wishlisted, but might be better suited to Lua scripting later on:
- player selection menu
- separate inventory menu
- assigning chase targets to monsters (for waypoints or making snakey monsters)
- arcade style lives




The general strategy for developing Voxatron's toolset is to provide specialized features (modifiers, microscripting, physics properties etc) that capture 90% of a typical designer's requirements, and then leave the rest to Lua scripting. Lua will be kind of like a glue that that holds the engine together and fills in the gaps of functionality.
Working on custom player inventories and menus that have a plethora of possible requirements, I feel I've hit that 90% boundary. The engine is now complete enough that it is possible to create a Lua API that is grounded in something stable and maintainable. For this purpose, I've created a text editor that can be used within Designer, and a custom version of Lua designed to work efficiently with Voxatron (both of which you can see in action in PICO-8). It's time to (carefully) plug everything in and see what happens!
It will also be possible to write cartridges from scratch in Lua, of course. This would be handy for making games that need their own style of physics, or things like RTS, sim or puzzle games that deviate a lot from typical Voxatron shooty-runny things. The purest cartridge can contain simply one Lua script, and no rooms or object definitions.
If all goes well, I'll start to roll out a minimal API later next month for anyone to experiment with. It is a typical object-wise callback scheme, where things happening in the world/engine call Lua functions that the cart designer provides.
Here's a simple example:
[vine]eiTpKIL2eLZ





PICO-8 0.1.1 is now available! Grab it from the Updates page.
Note that PICO-8 is available to all Voxatron alpha users (including bundle customers). You may need to activate your account, or log in via email if you don't have a username/password already set up.
I'm doing things a little out of order here.. a full introductory post to PICO-8 will follow in a bit for those who haven't been around lately, but for now here's a rundown of new stuff in 0.1.1..
1. Gif saving! Press F9 to save the last 8 seconds (or F8 to set a starting point if you wish)

2. Token counting.
Instead of limiting cartridges to ~15k of ascii text, the primary limit is now 8192 tokens. I say primary limit, because the character count still stands, but is now 32k -- in practice the token limit is almost always reached first. There is actually also a third limit when saving cartridges -- the code must compress to the original 15k allocation. Exceeding this is extremely rare and you can probably ignore it! To get the status of your program, use the new INFO() command.
There aren't currently any cartridges that I know of that go over 8k tokens, and in general this change will give you around 20~30% more space.
[b]3. Freeform sprite and map editing







Hey All
So you may be wondering what I've been up to for the last 4 months or so, and I'll post all about that very soon! v0.3.3 has required a lot of general housekeeping work including improving the player inventory system to function nicely with world state saving, scripting and controls. As a result, it became a good opportunity to also squeeze in weapon switching and custom HUDs.
Here's the design I have -- please feel free to comment and criticize -- especially if it looks like it won't carry ideas for carts you'd like to make soonish.
Here's an example HUD that shows a single player carrying more than one weapon (switchable with Q/E or shoulder buttons):
The basic idea is to add an animation to INV_ITEM similar to the ones that exist now for arcade weapons, but to allow adding any inventory item to the hud, including things like potions that are activated with an alternative button, or temporary pickups like the score multiplier.
The items only have limited information about how they are to be displayed up top -- the layout happens mostly automatically. But certain common item meanings (score, life, player head) are tagged as such to help make a sensible layout.
The layout is performed in single player by separating elements into up to 3 groups and aligning then left, then right then center. Multiplayer layout is similar, but elements are squashed together and layed out per-player.
The goal here is to provide a simple way to make inventories for common genres, without requiring lua scripting or a lot of work doing layouts that work both in 1P & 2P. Later on, fancy HUD requirements can be taken care of in Lua scripts (more on that shortly!).
So, the steps to make a custom HUD will be:
- Add (or alias) any inventory items (INV ITEM) that the player should start with. // e.g. start with a bow and 8 arrows
- Add animations to inventory items that should be shown in the HUD
- Tag some inventory items as having a special meaning: score, lives
It will still be possible to use the old arcade HUD that you're all familiar with, but not to mix-and-match the two systems.
So, here's the question -- are there any simple HUDS you'd like to use that don't seem to work with a scheme like this?
Here are some examples that I think will be ok:
Doom: Score, life, current weapon & ammo
Bomberman, Bloot: Player heads with points won in a single row
RPG: armour & weapon, MP, HP, Gold
Adventure: List of collected objects
Scrolly Shooter: lives, score, panic bombs // lives logic not yet implemented






