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.
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.
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.
> 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.
> 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.
Errr... yes? Obviously, nobody is claiming that the SNES was capable of "detailed physics and AI."
My first thought was that perhaps you were replying to the wrong post, but there aren't many replies. You certainly don't seem to be replying to what I wrote, so I'm baffled.
Let's go back to what I said. I said it took a while for 3D games to catch up to latter-day 2D titles in terms of "range of interactions."
In SMW, Mario can...
- Walk
- Run
- Jump
- Spin
- Swim
- Hold an item
- Throw an item
- Throw a fireball (as Fire Mario)
- Drop a reserve item
- Run jump
- Super jump (with Yoshi)
- Fly (as Cape Mario)
- Crouch
- Climb
- Smash into the ground
- Swallow an item (with Yoshi)
- Spit out an item (with Yoshi, will have different effects depending on what was eaten)
- Transition between different states (small, big, Fire, Caped, each with or w/o Yoshi)
Mario has dozens of abilities in SMW depending on which powerup is active and which (if any) of the Yoshis he's riding, as well as depending upon what Yoshi has eaten. There are dozens of objects with which they can interact, and many of those objects can also interact with each other. There is a physics engine, albeit a simplified 2D one, with gravity and momentum.
Contrast this with, say, Quake. You are of course inhabiting a fully 3D world, but there are a smaller range of interactions possible.
As I said, "a lot of" 3D games from the following decade (SMW came out in 1990) didn't have as rich of a range of interactions available. They were 3D, but there was generally less to do.
I can think of some exceptions, mainly from the latter half of the 1990s, but as I said, it generally took a while for 3D games to catch up.
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:
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..
> 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.
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)
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.
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.
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!
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.
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.