This is a recreation of the original Super Mario Bros, crammed into just under 24KB of a Pico-8 cartridge. (spritesheet memory is unused)
It includes all original levels, the minus world, and the second quest. Due to the token limit and limited likelihood of use, the alternating 2-player mode has been replaced with just playing as Mario or Luigi.
It's basically complete, but could use some playtesters, please let me know if you come across any serious issues or bugs.
Controls:
L/R--------------Move/Select world on title screen
X/V--------------Run/Shoot Fireball
Z/C--------------Jump/Start
Special thanks to:
- Jwinslow23 for composing the music and many of the sound effects
- Zep for his PX9 compression system
- Thisismypassword for the Shrinko-8 minifier
- Nick N. Bruns of NESmaps.com for documenting level maps
I can't tell what should be considered a bug versus what should be considered artistic license.
You kept all the level designs the same, but every game object is at least slightly different, with many of them having completely different behavior. That includes the walls and moving platforms. It also means that many of the original design choices don't actually function. Honestly this feels to me like the result of looking up how the game works on gamefaqs instead of playing the original.
I think keeping the lives system but not the continue system is a particularly odd design choice.
Hmm, I'm kind of surprised to hear that, since I primarily gathered info on how the game worked by playing the original version. Any differences are due to the fact that I built the code from scratch without knowing exactly how everything originally worked. I also had to find approaches that worked under tight token constraints the original didn't have, which probably favored different approaches.
As for the continue feature, I never knew about that until Googling it just now. Wish I had known about it as a kid, but Gamefaqs wasn't around back then. I agree it's not a perfect 1:1 port, but as previous versions had only a handful of levels and other drastic simplifications, I don't think it's a bad version.
Perhaps I should clarify. I wasn't trying to say it's bad. I would've gone with adjusting the level designs myself, but I can understand if nostalgia or respect for the original or really anything like that takes priority.
Also the parts that don't work as originally designed probably won't be noticed by players who haven't recently played the original game. For example, in world 1-2, you'd have to find the 1up in the roof and also try to get it from below before you'd have any way of seeing that the path it takes if it hits a 1-tile gap in the roof is not the same. In another case, I don't know how many players would know even one behavior for the squids much less both of them.
I understand, guess it's a combination of being a somewhat more casual player who doesn't usually go for tricks and speed runs, and working under tight technical constraints. If something behaves pretty closely to the original in most scenarios, different behavior in a special case isn't high on the list of things to fix when I'm hitting the token limit.
Guess there's also the fact I tried to make it look as much as possible like the original, so any differences stick out more. My goal was a very familiar version that played pretty close to the original, but I'm not worried about enabling accurate tricks or shortcuts.
Ay the game released! I played bits and pieces of it, and I must say, it is an amazing recreation, although there are some things that are inaccurate to the NES version:
-
Lakitu Behavior: Lakitus normally duck and hide their head after throwing 3 spineys that are still on-screen (due to NES object limitations) and immediately throw an egg after one spiney either falls into a pit or is killed.
- Mario is a tiny bit slipperier than the original (similar to Luigi's slipperines in The Lost Levels). It's not a game-ruining error, but it does make some jumps tricky.
Hope this helps!
Very quick edit: Instead of "Player 1/2 Game", use "Mario/Luigi game" (like in SMB: The Lost Levels). That way, there is more clarity and nobody is gaslit into thinking that there is multiplayer ;).
in the original smb, when you jump into say, a empty question mark block, your vertical momentum is halted, right? But when you jump into the edge, you're supposed to slip out of the block! this is to make collisions feel more natural
also when you have the fire flower, you can only shoot 2 a time, not 3
I'll look into the fireball thing. As for the soft-edge collision, I'm not sure how to make that work, can anyone point to an explanation or code implementation of it?
Oh, you're willing to add the soft-edges? I didn't bring it up cause it seemed like it might take too many tokens. That would really help with getting the mushroom in 1-4.
The first way that comes to mind is to use % to check what pixel the player is on versus the tile with a brick. If it's a pixel that's close enough to the edge of the neighboring tile, then the neighboring tile can be checked for a gap and the result of using % can also be used to know how far to move the player.
I'm pretty sure the original games all did that in every direction, which is why mario can traditionally run straight across 1 tile gaps.
Uploaded a new version:
- Movement physics are now more accurate and a bit less slippery
- Walking animation shows smooth acceleration instead of just 2 speeds
- Lakitu now hides after the max number of spinies are present
- Controls are standardized instead of being configured at start
- Starting world is selectable at title screen
- Menu now makes it clear that you can select your character, not the number of players
I was going to attempt soft-edge block collision, but I'll have to cut more tokens to make that work.
Wow... 🤯
The perfect PICO-8 SMB port is here!
Amazing work, as always, @JadeLombax 👏🤓
Thanks.😊
I wouldn't say it's perfect, but it is more or less complete.
I was planning to reskin everything, but I wasn't sure how to make it significantly different, and I didn't relish spending a lot more time on the project. Figured I'd make it available in a low-key way, try and stay under the radar. It's basically all new code and assets anyway.
when midair, your momentum should be the same regardless of holding run or not. Say i'm running at max speed, and i jump without holding any buttons. i should have my speed continue to be max speed WITHOUT having to hold the run button
Hmm, I've never had an issue with this, I guess because I've never felt the need to, or even thought of letting go of the run button while wanting to go full speed. I'll see if I can think of a straightforward fix, but I'm basically at the token limit, so adding any new logic takes time-consuming rewrites.
can't say i dont know the feeling. btw, i was wondering; what was the process for making the sprites, and would i be able to make my own personal edits by assembling a sprite sheet?
Also, the main reason why i mentioned the midair momentum is mostly because if you're running and want to throw a fire ball midair; you will lose some momentum
I guess that makes sense about the fireballs, I'll see if I get any ideas.
As for editing the spritesheet, that would be tough, because it's all tied into an elaborate compression system and every sprite on the sheet has a designated use. The spritesheet's compressed via PX9 from a separate editor cart, the data addresses are stored in a table and things are decompressed and moved around on startup, many sprites are drawn using colors 1-5 and recolored by separate logic depending on the current level and state, then everything's run through a minifier. Even if I went through and rewrote things so the spritesheet was used as-is, there would be a lot of constraints on what could be changed without messing things up, and I don't want to have to offer source code, explanations, and troubleshooting for all that.
[Please log in to post a comment]