Super Mario 64 Nds Rom
Kiera Mcintyde
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!
The original Super Mario games stand amongst the most important and influential video games ever created, but after the series shifted to the third dimension, Mario's side-scrolling adventures never quite reached the same heights. Now, for the first time since 1995, at least in my opinion, the magic of 2D Mario lives again in Super Mario Bros. Wonder.
This magical adventure perfectly encapsulates everything that makes Mario great - top-tier platforming gameplay with exceptionally creative level design paired with beautiful visuals and a catchy soundtrack. It looks, sounds and plays like a dream - but you could arguably offer similar endorsements of Nintendo's successful New Super Mario Bros series, which enjoyed four entries across multiple platforms and sold millions. These are good games, but for some of us they never fully clicked.
Therefore, today I'd like to explore Super Mario Wonder, both on its own merits and in contrast to what came before, to hopefully demonstrate why I think this is the best 2D Mario adventure since Yoshi's Island. Of course, we'll cover the technical landscape as well - this is Digital Foundry after all.
I'd consider myself a connoisseur of the platforming genre and, having bested hundreds of platformers over the years, I've developed my own criteria for describing the truly great side-scrollers. It comes down to these four elements:
How does Super Mario Wonder fit into these categories and stack up against other Mario titles? Let's begin with the core gameplay mechanics. No two Mario games feel exactly alike but, for my money, I've always been partial to Super Mario World's precise controls. The speed and precision possible in this game remains captivating even today.
With Super Mario Wonder, Nintendo has created something that feels somewhere between the ultra-precision of World and the heavier Super Mario Bros. 3. It feels snappy and responsive, but there is just enough weight behind Mario's movement to enhance that feeling of momentum. Running across the game's worlds feels great. All the basic actions are fun to use and there is an inherent satisfaction in just playing the game - something critical in a platformer.
They've also freshened up the move set - aside from the fire flower, Mario Wonder boasts a slew of entirely new power-ups with their own capabilities. The elephant is well-known from the trailers, controlling more like you'd expect Wario to, but the bubble cap and drill cap provide entirely new gameplay opportunities.
When playing through the game, it was instantly clear that Wonder felt more responsive to play compared to the four New Super Mario Bros games, so I decided to examine this aspect more closely - and the results were surprising.
I initially discovered that the standing jump is virtually identical between Wonder and New Super Mario U. Press the button and they both reach the apex of their jump at the same point before dropping back down. I tested other scenarios and found that they were similar too, yet I could feel there was a difference - so what's going on? It turns out there's one big change that has a significant impact on the feel of the game - momentum.
In short, Mario maintains momentum much longer in the New Super Mario Bros games versus Mario Wonder. It is specifically this element which lends the New series that heaviness people complain about. Adjusting to the scenery and making precise maneuvers simply feels more satisfying in Wonder as a result - at least to me. That increase in responsiveness is key, but it's not the only major upgrade over the previous 2D Mario titles - so let's talk about the the game's presentation.
The visuals in Super Mario Wonder are bursting with color and personality, and we'll discuss that in a moment, but one of its key victories stems from animation and key frames. In older sprite-based games, artists would create a series of individual frames that would play at fixed intervals. When Mario jumps in Super Mario World, you can see this cycle in action. This plays a huge role in how a game feels to play, but it's a little trickier in 3D when you're no longer bound by individual frames and instead create a smooth, interpolated animation.
What do I mean? Well, the designers clearly poured a lot of time into posing and key frames. When Mario jumps, he assumes a pose reminiscent of classic box art Mario, for instance. They linger on specific poses to achieve this sprite-like feel - Mario has his upward jump pose and then the downward pose. There are subtle, secondary animations happening, but the broad strokes rely on these specific poses - poses which kind of mimic Super Mario World.
The world map demonstrates another key concept - when running around, Mario's running animation is fluid, but the game snaps between one of eight cardinal and ordinal directions rather than smoothly rotating the model. This very specifically mimics what you might see in a sprite-based game, where the artist would draw only specific angles, and we see this during normal gameplay animation as well.
d3342ee215