Really cool demake, but still needs work...
the physics and controls feel really off, as Mario falls at a steady pace immediately after releasing the jump button, and his jump is much higher (for example, getting to the top of 1-2 is much harder because I keep on hitting the bricks.)... I'm curious as to what's taking up all the tokens, as it's clearly not levels, and the code could probably be shortened even more...
In principle the controls in the original are probably delayed. But I think the controls in the original are a lot more diffucult , especially without gamepad... At least my girlfriend found this easier.
Nice work! I love how you used the pallete. Also I am not feeling the jump is a big issue.
There is a concern about Nintendo bringing this down. They are known to take out assets using their IP so be careful on publising it in the open.
What is the map data being used for? I see that you define maps in code, but the top half of map editor is still filled with data. Are those just maps you were building prior to taking the code approach?
Title screen is using map data. (the first 16x16 blocks).
More ist not used anymore... I created a custom level editor, which exports strings. But if I had known, that there is only enough memory for a few levels, I had not taken the trouble...
But this 8k token limit makes no sense at all. You can make a limit, but at least 16k+16kb user memory whould make sense.
Currently it is simple impossible to create games like mario, turrican or other 8bit titles. Which is sad..
Really great remake. The backward scrolling is a welcome addition to the original game as well. Other additions such as starting the game as Super Mario and the lenient fire-flower-counts-as-a-hurt-buffer are also fun tweaks, for starters.
It would be pretty easy to use that 4k of MAP that isn't used to store levels, but unless you could squeeze all the levels down to 4k may not be worth it since then you'd need different routines to load from string vs map.
I read the code. It sure looks like the first segment of letters are stored in hexadecimal... I do see where after that you switch to a different encoding. But there is quite a bit of data stored in ASCII HEX from where I sit.
As a note, it sounds like you're using a very inefficient representation of the levels in your strings. Are you storing literal tile layouts, or using a much more efficient 'sparse' layout like the original Super Mario Bros game did?
SMB1 defined the global sky/ground/background for the entire level in two bytes, then describes individual 'screens' (16-tile sections of the map, key look that matches PICO8) in two bytes per overlay, with a single overlay able to place multiple objects.
So really I think the main issue is your level format is overly huge because it's storing raw tile layouts instead of using such a 'sparse' structure. So yes you'd need to do more work to update your editor to do such a format, but that kind of 'indirect' map layout is really the key to fitting stuff into tiny systems like the PICO8 limitations.
Old games almost never stored the entire map in 'ready to render' format back in the day; they would commonly store a 'palette' of objects, and the map would define where those objects went and in what order, sorted so that the game only had to examine a few dozen bytes to update the screen.
This is why so many early games didn't let you scroll back: They didn't have structures that could be 'scrubbed' both directions cheaply, only in one direction, and the CPUs at the time couldn't brute-force-scan the entire level data to scroll backwards.
And storing raw data into the map/tile regions and then copying that out using peek() in your _init can be a LOT more efficient than packing data into strings. It avoids the cost of the byte->whatever encoding (which at a minimum will expand the data by 20% for ASCII85, or as much as 50% for hexadecimal) and then the cost of that in the 'compressed string' size limit.
Edit:
I am still hesitating because I have no idea how to deal with the token limit. using the map memory istead of strings, will propably bring some free tokens. But there are still some missing enemies/gameplay elements, that are necessary in the later levels
...format, which saves tokes. There's a lot of token optimizations that can be done, not one silver bullet, but this first step gets you well back under the compressed-string limit which was what you'd ran into first by far. :)
Sadly a lot of game design for the PICO8 can be "design a basic idea... then redesign it to actually fit the constraints of the system" at times as you learn more and more about structures and the like to use.
Hey, I played a bit, and even if it doesn't feel exactly a 1:1 reproduction, it feels pretty solid. But I have one nitpick with the game : the camera feels a bit off. When running to the right, the camera leaves Mario around 75% on the right side of the screen, leaving not enough screen space to see what's coming on you.
Since it's been a long time since this was originally posted, can you send the level editor you used to create the levels for this game? It would be good since this game has really good physics and could be a great base for some PICO-8 Mario games!
Mario Bros. is an arcade game developed by Nintendo and released on June 21, 1983.[3] It was also released on the NES under the Arcade Classics Series series of games (a version itself later ported to other systems), Atari 2600, Atari 5200, and Atari 7800 as well as a large multitude of home computer systems. This was the first game to introduce a simultaneous two-player mode, coins, pipes, and POW Blocks. The game is often stated to be the first appearance of Luigi, such as by Nintendo during the Year of Luigi that commemorated his debut, despite the fact that Luigi had actually previously appeared in the Game & Watch game of the same name, though the arcade game was in development first.[citation needed] Beyond featuring Mario and Luigi, the Game & Watch game bears no similarity to the arcade game.
The premise of the game revolves around twin plumbers Mario and Luigi, who are in the sewer system of New York[4][5] (or their house according to Atari).[6] The sewers are overrun by waves of enemies, which must be defeated for coins.
The game features a simple stage in which the player plays in an endless game. Much of the gameplay appears to have been inspired by an arcade game named Joust. Enemies come from the pipes on the top and head downwards, where they may enter the pipes again to return to the top. The game features 22 unique phases (although Phase 2 was removed from non-Japanese versions of the game), and after the last phase has been completed, it merely loops the phase order from then on; the screen will still read "Phase 23" onward up to "Phase 98" (99 in Japan). After reaching Phase 98/99, screen text will stop incrementing, though the order of unique phases still loops. The phase counter at the bottom of the screen reads "KO" from Phase 25 onward.
The goal in each phase is to defeat all enemies, which is done by jumping up and hitting the floor below enemies. This flips them, giving the player the chance to kick them away, which is rewarded with 800 points. Enemies that are kicked over in succession quickly enough after the first will award 800 more points, up to 3200 points. The highest score that the game can display is 999,990 points, and scoring any more will overflow the display and make it start counting from 0 again. The POW Block can also be used to flip enemies; however, it can be used only three times. After an enemy is knocked away, a coin (a "wafer" in the Atari 2600 version of the game) appears from one of the pipes, and gives 800 points when collected. When all enemies are defeated, the player continues to the next phase. In later levels, different types of enemies and harming fireballs appear. In Phases 4, 9, and every seventh phase after that (Phase 3 and every fifth phase after that in the NES version), a bonus level appears where all the coins have to be collected in order to get an extra 5,000 points (during the first bonus level) or 8,000 points (during the second bonus level onwards). The time limit of the bonus level at first is 20 seconds, but starting from the second bonus level (third in the NES version), it is reduced to 15 seconds. Excluding the first bonus level, all bonus levels have floors of ice. The POW Block regenerates after the second bonus level and every subsequent bonus level. Unlike the arcade original, upon reaching Phase 100 in the NES version, the screen reads "Phase 0", and completing it will start incrementing the phase counter again as normal.
Target enemies must be defeated to clear the phase while other enemies should be defeated by the player's discretion. Each phase consists of one or two types of targets with a maximum of six targets. Shellcreepers and Sidesteppers appear together only in Phase 5 (6 in Japan). The last target enemy will always move at its fastest pace unless said enemy is a Fighter Fly.
The arcade game was given a preview at the Amusement Operators Expo held at the O'Hare Exposition Center in Chicago from March 25-27, 1983. The reviews were mixed. Steve Arrants of Creative Computing Video & Arcade Games considered it his favorite among the ten games showcased[7] while William Michael Brown of Electronic Fun with Computer Games thought it was a dud with difficulty being the main issue.[8] John Holmstrom of Video Games criticized the slippery controls.[9] However, the version they reviewed was a prototype.[3] Michael Brown noted that the released game was much easier than the version he played at the expo.[10] The promo photo that Nintendo handed out showed a standing red Shellcreeper as the stand-in for the "P" in the phase counter. It also shows Shellcreepers and Sidesteppers together in Phase 4 which is not the case in either the Japanese or international arcade releases.
c80f0f1006