
Super Mario World Memory Map - Alupis
https://www.smwcentral.net/?p=memorymap&game=smw
======
JohnBooty
This is impressive. We think of Super Mario-style platform games as "simple"
but in reality, _wow..._ the engine for Super Mario World really is a state
machine with thousands of values.

In many ways, a game like SMW is more complex than a lot of the fully 3D games
that came out in the following decade.

Sure, a game like Quake or Tomb Raider had to crunch a lot more math for each
frame of their fully 3D worlds. However, 2D games like SMW offered a much
richer range of interactions between player/enemy/environment compared to
those early 3D titles. It was quite a while before 3D games caught up.

~~~
beetwenty
This is probably only true if you're thinking of the complexity in terms of
board-game style complexity, with characters and items and abilities that you
can enumerate in a list. That's the type of thing that digital computers are
pretty good at doing and analog systems aren't, so in our digitally-soaked
culture we tend to appreciate it more and associate it with being "more
complex". But it also hit a saturation point in the 90's, right around the
time SMW came out in fact - there are plenty of early 90's PC wargames and
RPGs that are just baffling to play because they model the playspace in a way
that makes for spreadsheet UI.

Detailed physics and AI, on the other hand, is a thing that is largely beyond
the ability of the SNES platform, and that's something that started to pick up
along with 3D gaming. We don't greatly appreciate these things in video games
because we can pretty easily play with blocks and balls or find live opponents
in the real world, but it's a realm that still has a lot of untapped
potential.

~~~
CoolGuySteve
Mario World does have a 2D physics engine with tile-based collision detection
that works on 255 objects iirc.

The physics it implements is cartoony in that max velocity is capped such that
acceleration is limited, but it's an implementation of verlet integration,
more or less.

You can see the devs playing with it in a few levels. For example there's that
long vertical fall with multiple objects falling along with you that leads
into the 8th world.

Or a few levels where an enemy causes chaos with a turtle shell.

------
matheusmoreira
Always found it interesting how the entire state of the game is statically
allocated. This places hard limits on the game's engine. For example, there
can only be so many active objects at the same time. I wonder how they
determined these limits.

Static memory allocation also makes things easier for hackers. No need to find
and follow pointers. Many emulators have Lua support and it's possible to
interface with the game this way. Amazing tools can be built. For example:

[https://github.com/brock-
heinz/NESDev/blob/master/Emulators/...](https://github.com/brock-
heinz/NESDev/blob/master/Emulators/FCEUX/luaScripts/MegamanII-LaserEyes.lua)

More data:

[https://datacrystal.romhacking.net/wiki/Category:RAM_maps](https://datacrystal.romhacking.net/wiki/Category:RAM_maps)

[https://datacrystal.romhacking.net/wiki/Category:ROM_maps](https://datacrystal.romhacking.net/wiki/Category:ROM_maps)

[http://tasvideos.org/GameResources.html](http://tasvideos.org/GameResources.html)

~~~
dcow
Games are engineered products in heavily constrained environments. General
software is more like: clever ways to automate annoying tasks. General
software can be maximally lazy or elegant or both. Games are clever yet
practical and efficient. What baffles me is how often I find a game design to
be far more elegant than that of common software..

~~~
matheusmoreira
> General software can be maximally lazy or elegant or both. Games are clever
> yet practical and efficient.

Video games are soft real time applications: performance visibly degrades if
the targeted frame rate is not met. Given the hardware of the time, they _had_
to be practical and efficient.

This might not be the case anymore. Today we have hardware with incredible
performance but some of that speed powers abstractions that make it easier to
develop the game. Older games had complete control of the machine but now they
are merely one program scheduled to run by the operating system.

> What baffles me is how often I find a game design to be far more elegant
> than that of common software.

I think it's because of how little abstraction there is. The data structures
we find in the code of older games are directly related to the game itself.
It's rare to find a retro game with a separate game engine.

------
TapamN
One thing that's interesting about this memory map is how much is crammed into
the first 8KB of the SNES's 128 KB main RAM, while the rest is mainly used to
store large blocks of uncompressed data. This is probably a remnant of how the
SNES was originally designed have just 8KB of RAM.
([http://www.chrismcovell.com/secret/SFC_1988Q4.html](http://www.chrismcovell.com/secret/SFC_1988Q4.html))

~~~
CountHackulus
It's likely due to being easier to deal with across various memory mapping
modes. There's a Retro Game Mechanics Explained video about it that I can't
seem to find right now.

~~~
RetroSpark
This. The Super NES memory map is divided into 256 banks of 64KB each. The
bottom 8KB of RAM is visible in 128 of these banks, but the remaining 120KB
only appears once. The bottom 8KB of RAM is therefore faster to access (at any
time, it's more likely to be visible in the "current" bank).

Of course, game developers tried to put as much data as possible into the part
of RAM that is faster to access.

------
pathartl
This is really cool. I know people have been messing around with Gameshark
codes for decades, but I'm finally getting to the point where this type of
stuff doesn't seem out of reach anymore.

I just don't know what to do with the information!

~~~
danharaj
There is a very vibrant SMW hacking community with very functional GUI editor
that can act as a springboard for getting into assembly patches ranging from
simple changes to sprite behavior to whole new game modes. If you love the
game, it's a joy.

