This is a demo for a system I developed that can store console-size game worlds on a Pico-8 cart. It contains every level and sublevel map from the original Super Mario Bros., and you can run and jump through all of them. There's no level progression, sound, or things to interact with besides platforms, but the map data includes placeholders for enemy spawn points and interactive objects, just uncomment a line in the init() function to make these visible. I'm not planning to release the finished game, as I don't want it to be taken down for copyright reasons, but I wanted to show some definitive proof that large-scale games are possible on Pico-8.
Cart Technical Info:
- Uses standard map() and sprite flag functions (w/special camera offsets)
- 60fps w/ CPU usage between 11-25%
- 1352 tokens, including streamlined platformer engine and graphics/map decompression systems
- 35% of compressed storage limit
- All maps contained in 3.9KB of binary data in map area
- No data stored in the 8KB spritesheet
The big thing is the last point on the list. Instead of storing the nearly-incompressible level data in strings, I instead store the spritesheet in a string because it compresses over 2:1, leaving a full 12KB of potential level storage space. This means that while leaving the majority of compressed data capacity and token count unused, 3 copies of every Super Mario Bros. level could fit on the cart! By my estimates, the worlds of mid-tier NES games like Megaman, Ninja Gaiden, Castlevania, Zelda, and even SMB2 (or original ones with similar scope and detail) could fit within that 12KB limit with some optimization. For instance, I estimate that Zelda 1's whole world could fit in around 6KB.
This demo was built entirely in Pico-8, using a graphical level editor that I plan to release in the near future. It's currently a bit limited due to being tailored to the quirks and limitations of SMB, but I intend to add some more features and make it easy for anyone to build their own large game worlds using a simple point-and-click interface. Here's a little preview =).
With Pico-8's small spritesheet, I've noticed that many game makers who want a nice title screen are forced to either give up valuable sprite space for a custom-drawn logo, or use a tiny one that takes up less space, which they may then zoom in so it fills up more screen area but looks very pixelated.
Occasionally, someone who wants a fancy title screen will use a more advanced method to either expand the usable sprite memory --as with Zep's PX9 compression, or encode it in string form --as with dw817's compression programs. These work well, but the minimum cost of 1000+ characters and 280+ tokens for decompression + sprite sheet rewriting, and/or screen-filling strings in the thousands of characters can be overkill for many projects.
I present a new alternative. Instead of compressing full-color bitmaps, my system encodes logos as 1bpp images into 7 bit-per-character strings, then renders graphical features such as shadows, color gradients, and outlines in real time. It uses no spritesheet space, the resulting functions take perhaps 400 characters and 160 tokens (considerably less when optimized), and when combined with the data string take a fraction of the space on cartridge compared to the spritesheet equivalent. There is a tradeoff with CPU usage, as large logos with outlines can use ~50% of cpu cycles at 30fps. On the other hand, the real-time nature of the rendering presents opportunities for animation or lighting effects not possible with other approaches.
I've encoded several example logos in the cart, some from mainstream game franchises and some from recent Pico-8 games, to show the system's capabilities, and I've tried to add enough comments and instructions to make things understandable.
I welcome any feedback, and I hope this is useful to someone out there, I definitely plan to use it for my own projects.
Lately I've heard bits here and there about a new function called unpack that seems to have some significant benefits, but after searching the BBS, the Pico 8 Wiki, and Google, I've barely been able to come up with any solid infomation on it or how to use it.
If someone could point me in the right direction, I'd much appreciate it.
Yes, this is yet another version of Space Invaders, but with this one I'm going for a direct port of the original arcade game. It's mostly complete, with functional gameplay and a working high score save system, but it needs some gameplay tweaks and a few graphical elements, and the sound effects are very much unfinished (I'm working on a version of the 4-tone march using subtones, but haven't ironed out the glitches yet). Anyway, in addition to going for authenticity, I also tried to code this very efficiently, and the whole game (including all graphics and sound), takes under 3KB and only about 1100 tokens.
Any constructive criticism and general feedback is welcome, thanks.
Join Squirt as he jumps and bounces in the sky through varying times of day, on his way to Cloud Land.
A little while ago I uploaded my first game Cloud Bounce, an animated platformer designed to fit in 280 characters. I was happy with the basic gameplay, but in order to fit it in such a crazy small space, it was pretty bare-bones. The EX version is fundamentally the same game, and still tiny at just over 700 characters, but with a lot of important game features added, including:
- Title screen
- Lives system
- Game over screen with restart
- Gameplay timer
- An improved ending (the original was by necessity super abrupt)
It's still missing sound because I haven't figured out how to make music yet, and when I tried adding a basic jump sound without music, it got monotonous quick. The game's a simple and straightforward platformer with no enemies or in-depth mechanics besides reaching the end in good time, and I don't plan to really change that outside of making a sequel. I'd appreciate any feedback on ways I could make it better and more engaging within those limitations, though. Thanks.
This is a fully playable version of Tetris in fewer characters than a moderate-length email, including:
- Line removal
- Level progression (speed increases after every 10 lines cleared)
- 'Lines cleared' display
- Soft drop button (with slight delay when next piece appears)
- Reset button
Fitting everything in this small a space was really tough, but I made it. I had to cut a few corners, for instance there's no next piece preview, only one rotation direction, and there wasn't space for logic to allow movement of blocks once they land, so overhangs are a nuisance. With all that said, though, I worked hard trying to make this an actually decent version of tetris and not just a technical curiousity, so hopefully somebody actually enjoys playing it instead of just staring at the indecipherable souce code. Shoutout to 2dArray, whose Tweetjam Tetris and its genius piece indexing system I built on for this project.
Version 0.2 - Now has definite fail state with timer stop, and recolored graphics
You are a ground-based defense drone at a top-secret research base inexplicably located by a mountain prone to avalanches. When a tidal wave of snow and ice rushes toward you, you must use your cannon to vaporize it, keeping it at bay for as long as possible so the base staff can get to safety. How long can you hold out?
This is the unintended result of trying to cram a minimalistic space invaders clone into 280 characters. I couldn't figure out how to fit code for individual enemies, but an advancing amorphous mass was just doable. Hopefully it turned out alright on its own terms, and I welcome any feedback or criticism. Warning, though, this can get a bit nerve-wracking. o_O
After discussing base64 encoding in a recent thread, I decided to try my own version of it for storing level strings, but after some experimentation I started wondering how much of a storage benefit it really offers vs. hexidecimal. I also came across an old post from user Overkill from 2016, in which he concludes that unfavorable interaction with Pico-8's built-in compression basically negates base64's byte-per-character advantage.
I decided to perform a test of my own to measure the difference precisely. To do this, I used some web-based tools to generate random strings, using both hexidecimal and my own base64 character set, which uses as many 1-byte characters as possible (59, to be specific -- certain characters like small caps and glyphs use 2 bytes). I generated very large strings and pared them down just enough to fill the compressed data limit to 100.00% using each character set. I performed 3 trials each, recording how many characters would fit for each encoding type, then averaged these amounts for a general comparison. Results are as follows:
Base64: 15846 characters max.
Hex: 23230 characters max.
Base64: 15776 characters max.
Hex: 23261 characters max.
Base64: 15757 characters max.
Hex: 23275 characters max.
Base64: 15793 characters max. -- 11,845 bytes
Hex: 23255 characters max.-- 11,628 bytes
From these trials, the difference in byte capacity vs. compressed size appears to be about 2%, which suprised me. While there could be cases in which custom encoding offers various benefits, in general I think I'll stick with hexidecimal. For me, a negligible increase in storage efficiency is more than offset by much easier conversion to and from byte values and some degree of readability.
Join Squirt as he jumps and bounces in the sky through varying times of day, on his way to Cloud Land.
Features character and level animation, 60fps gameplay, and 150 unique screens of platforming-- all in 280 characters!
This is my first game for Pico-8 (or for any platform, for that matter...). I wasn't originally planning to try and fit a game in this small a size, I was just working on a platformer game test, but then I came across the concept of tweetcarts and things went in an unexpected direction.The game won't change a lot because I can't find any way of packing more in, but I figured it would be good to have some feedback before releasing. Thanks.
Hello, first post here.
I just got started with Pico-8 recently, and have learned about the usefulness of storing data in strings to get around token limits. I was wondering, can I build a data string using a p8 program, then output that string as text that can be fed into another p8 program without it being reformatted? I'm working on a graphical level-editor program that will output level data strings usable by another cart.
I tried using printh(), but when I opened the text file it mangled up the extended character glyphs and didn't preserve the 4x3 font lower-case letters I had in the string. My goal is to have all 121 characters available so I can store about 7 bits per character, instead of the 4 possible with hexadecimal, if this is possible.