This is a demo for a way to store console-size game worlds on a Pico-8 cart, which later became my PicoMap system. 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.
Controls:
L/R-------Move
Z---------Run
X---------Jump
Up/down---Select Level
Up+down---Restart Level
Cart Technical Info:
- Uses standard sprite flags for map interaction
- 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, This should be more than enough to store the worlds of many NES-era games, with space left over for the extra graphics and sound assets. For example, all the level maps from the original Mega Man fit in less than 6KB.
This demo was built entirely in Pico-8, using an early version of my PicoMap system, the latest version of which you can find here: https://www.lexaloffle.com/bbs/?tid=42848
Oh hey, neat! I had this same exact idea a while back and I messed around for a bit trying to make something similar myself, yours seems a great deal more efficient, though, using the whole map I would've likely only just barely managed to cram everything in. It's messy and really only an experiment that I was messing around with, and I did everything by hand and etc etc etc, anyway, good job! I have a considerably more complex metatile system I use based off the Genesis/Megadrive Sonic games, I should definitely try and see if I can use your tricks to make that more efficient.
Feel free to use my tiles, not just you, but anyone who wants to. I feel I did a good job replicating the look of the originals. You've definitely got a nicer Mario sprite, though. It'd honestly be really cool to see someone port a full-length NES game, shame that doing so at least with SMB1 will likely incur the wrath of the big N. I may attempt to port one of the 8-bit Sonic games someday myself, though.
Thanks, (oh, and btw, I do really like your small Mario sprite =)
I know others have worked on metatile-type systems before, I just wanted to push things further with a really efficient system that lots of people can use. Hopefully people will like and use my editor once it's released, as I'd like to see more games that don't require devs to invent a new custom compression system or cut resolution or active screen area in half to fit much content on a cart.
I think my approach is simpler than others largely because I haven't learned to code using elaborate scripting and OOP, but very basic stuff (including tinkering a bit with actual BASIC). I actually got the core idea from watching a tutorial from Doc Robs on YouTube in which he used the map() function multiple times at once to make a scrolling background. I wondered if this could be used for individual objects in a level like trees and blocks. With some trial and error I figured out how to make levels this way, with the map data area serving as a sort of scratchpad, or palette of objects that can be mapped wherever I want.
Here's a super-compact version of the core idea that takes just 135 tokens and (besides the data strings) uses fewer characters than a single tweet. It only has a chunk of Level 1-1 which I repeated a few times because I had to code each object in by hand in hex, but it's capable of full levels. My current build has more storage-efficient level formatting, is way easier to make levels for, and makes game interactivity much easier, but the basic idea is very straightforward.
Metatiles and mirroring (simetric metatile so you store only half of it) has been a solid proven approach to increase map size reducing variation in map desing for ages, particularly in NES. There's even extremes like zelda that had full screen height 16px wide metatile columns and conformed the screens with very few bytes each. Nice to see some good implementations on that.
Good work.
I've been thinking about trying something like this since I watched the video about the making of MicroMages.
It's cool to see how far it could be pushed on Pico-8.
What do you mean, exactly?
Thanks, this took quite a while to get working how I wanted, but I just got annoyed that I was able to make a little tweetcart platformer in 280 characters that was 160 screens in size, but would be limited to a world 1/5 that size using the standard map system.
I'm working on ideas for the next version of the editor, hopefully making it versatile enough to handle a wide variety of games. At the moment I'm trying to see if the game world from Mega Man 2 could be made to fit into a cart, and how that might work ;).
Not gonna lie - to a total noob like me, this is basically sorcery. I am constantly amazed at how far people can stretch this wonderful little console while I still stumble across esoteric nil conditions in my basic little card game :).
Hm...
Ok so compared to the og smb, the speed isn't as fast, it's a little bit slippery, the momentum isn't kept with jumping (or in general), and I can't backwards jump, but otherwise pretty good.
Thanks. Don't put yourself down too much, though, I have absolutely no idea how to make a card game. =)
Oh, I know it's definitely not perfect (the little bugs in the collision detection bother me more than the imperfect physics), I just wanted to get a functional little platformer engine in there with relatively low token use, and for only 400 tokens I'd say it's pretty good. There is momentum, I guess it just doesn't work the same way as in the original game and I didn't figure out how to animate acceleration smoothly. If I were releasing the finished game I'd try and make the controls feel spot-on.
@JadeLombax I'm super proud of my card game! I play it every day, which is why I still find the occasional bug, haha. PICO-8 has been a fun creative outlet with lots to learn in a very satisfying way when it all comes together. Seeing what can be accomplished with some of the more advanced techniques like this one blows my mind, but it's great knowing I can study the code and work out what's going on . . . eventually :).
Any progress on this? Would love to use it for a larger scale project and I feel like the editor would help a lot.
I've made some progress, it's just been slow developing the new systems required to make it more versatile, such as a realtime-rendered metatile thumbnail system and selectable icon menu, translation of 1D coordinates into 2D level maps for better compression, a compact autotiling system to allow for more complex level graphics than would otherwise be possible, and a palette-based system for tile animation. I'm basically trying to build an integrated graphical development environment for NES-scale game worlds from scratch, and learning as I go because I don't have that much programming experience. Other things are also demanding my attention more these days. I guess I could release it as a work in progress if there's enough interest, but it has some distinct limitations & rough edges and documenting and providing instructions for everything will still take a fair amount of work.
Well, it's not going to be really 'finished' for a little while, but I'm thinking about releasing it as a work-in-progress to get some feedback and make it better. I've had some difficulties, not so much from a technical perspective, but more from a design one, such as figuring out the format and feature set to make it both user-friendly and versatile enough for a wide variety of games. Things like how I'm categorizing the types of metatile objects, working on making properties of them user-configurable via in-editor switches and figuring out how configurable to make them, stuff like that.
I guess if I release it in-progress, though, I'll have to warn people that figuring things out could be a little tricky, and updated versions could make levels created with previous ones incompatible.
If you posted your editor as is with no support promise, I’m sure interested people could investigate it together and adapt it for their needs!
I guess that's true.
I'm pretty picky about my work, though, and wouldn't want to release something in a shoddy state that other people would have to remake into something useful. A big reason I started working on this in the first place was to provide a tool to people that would allow them to make larger-scale games without reinventing the wheel each and every time.
I think I'll try and pare back my ambitions a bit and not aim to make this a comprehensive package at first, but take what I have and fix it up enough to provide a functional system with baseline features and enough explanation that people can use it as-is, then see about expanding it in the future.
Little update,
I've pretty much finalized the feature set of the initial version of the editor, and simplified things with a more straightforward and open-ended system than I was trying for. As merwok said, the people here should be capable of optimizing and adapting it for their needs, so I guess I don't have to plan for every possible use.
Some basic specs should include:
- Support for levels up to 256 screens in size(!), with user-definable width and height
- User definable object properties including size variability and repeating tile patterns
- Variable-length encoding of objects for minimized level size
(2-3 bytes per object, with room for optimization via lookup tables) - Realtime-rendered object thumbnails
- Export function for converting strings directly into binary data to store in spritesheet or map area
- No editor graphics stored in the spritesheet, so entire area will be available to users
It should still take a little while to get things fully implemented, but at least I have a pretty solid plan now.
ok cool
Edit: maybe (with crediting) I could use the editor to help with my game (here: https://www.lexaloffle.com/bbs/?tid=39432). (just saying I'm not picky and I'm pretty sure that not many people are so maybe you can release a demo version).
Great job all we need to do now is to add the enemy's coin counts, bowser, the top graphics the other collectibles like the fire flower and mushrooms and we got a great remake
I've thought of that, but if word of it got around, Nintendo would swoop in and threaten legal action, and I'd have to take it down. =(
In better news, I've just about completed the initial version of the metatile level editor, just doing some tweaks and bug fixes. =)
[Please log in to post a comment]
