This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

Rebuilding Super Mario Bros. piece by piece

Rebuilding Super Mario Bros. piece by piece
by on (#147136)
My efforts to create the "President" engine got sidetracked so many times that I've lost count. But last night, I had a conversation with ShaneM, famous around here for his massive SMB1/SMB2J bug fix patch, about creating a homebrew platformer engine by rewriting Super Mario Bros. in a Ship of Theseus manner.

One would have to do at least these:
  • Rewrite SMB1 a subroutine at a time, replacing each subroutine with equivalent original code. This is how LAME was bootstrapped from the ISO MP3 encoder over the course of two years (mid-1998 to May 2000). It also gives a chance to optimize the engine's RAM use.
  • Leave NROM behind, allowing data to be split across banks and enemies to be replaced in CHR RAM between scenes.
  • Replace the level designs.
  • Replace the graphics. For the hero you could find all sorts of pixel artists, and the animation could be made more intricate by streaming tiles to UNROM. For the enemies, NovaSquirrel and I would probably be willing to let you use the enemies we designed for DABG.
  • Replace the music and sound effects. At this point, the decision to leave NROM behind would allow use of FamiTone or another homebrew music engine, so long as the replacement subroutines leave enough RAM free for other things.

The result would look and feel like a total conversion of SMB1 but be an original program with original characters that can be used as the basis for a means of making creating a homebrew platformer as easy as ROM hacking. Take the example of Erockbrox, who suggested to ROM-hack Super Mario World into a fan sequel to Kid Icarus.

Practical or no?
Re: Rebuilding Super Mario Bros. piece by piece
by on (#147144)
This could be a very interesting project. I would be interested in contributing tiles and famitone music.

Let's agree not to name it OpenPlatformer or some other similarly open-source name, though :P
Re: Rebuilding Super Mario Bros. piece by piece
by on (#147156)
Issues:
1. It'd be better to call it OpenPit anyway. (Especially if you can duplicate Kid Icarus!)
2. Even if you replace all the boards and nails and materials of a Ship of Theseus, you never replace the design. You'll have merely replaced every box in the flowchart with another box; the skeleton of the flowchart remains the same, just with different meat on them. This seems suspect from the perspective of a project aiming to be not-infringing-from-foundation.
Re: Rebuilding Super Mario Bros. piece by piece
by on (#147161)
And to an extent, LAME retained the structure of the ISO MPEG example code. But after stripping out all ISO or Nintendo code, the remaining "skeleton of the flowchart" is a set of processes inherent in psychoacoustic coding or the side-scrolling genre. The idea is that these processes do not rise to the level of eligibility for copyright per 17 USC 102(b):
US Congress wrote:
In no case does copyright protection for an original work of authorship extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated, or embodied in such work.

And even this can be refactored later to meet a particular project's needs. For example, once we no longer have to remain compatible with the quirks of SMB1's level design, we can fix its collision quirks even more thoroughly.
Re: Rebuilding Super Mario Bros. piece by piece
by on (#147165)
I think the problem is that modifying an existing design would be harder than doing it from scratch, especially something like SMB1 which was made when gameplay mechanics for platformers were still way too green. It'd be better to just make a SMB1-like engine but with current knowledge (and being aware that we can use mappers, which would matter for things like the level format).

Also don't call it OpenPit, jeez:
mikejmoffitt wrote:
Let's agree not to name it OpenPlatformer or some other similarly open-source name, though :P
What this post says :|
Re: Rebuilding Super Mario Bros. piece by piece
by on (#147174)
I too don't see the point in using an old engine as the foundation of a new game.

For it to feel like SMB, all you have to clone is the physics, everything else would probably work better if designed with the new specifications in mind.
Re: Rebuilding Super Mario Bros. piece by piece
by on (#147193)
I think it's a fantastic idea to make an open platform engine with SMB physics though.
Re: Rebuilding Super Mario Bros. piece by piece
by on (#147257)
There are a few key things that make Super Mario Bros. feel like Super Mario Bros, which many mediocre clones like The Great Giana Sisters didn't copy. Fortunately for us, and unfortunately for Time Warp Productions, a copyright lawyer isn't so concerned with these aspects:

-Mario's rise follows the curve of a parabola flipped about the X axis, approaching the maxima.
-A much stronger downwards acceleration follows either at the jump's apex, or at the release of the jump key
-Mario reaches maximum vertical downwards velocity very quickly, as it is quite a low value.
-The initial jump "strength" is influenced by the player's horizontal velocity
-In-air navigation is limited compared to the on-the-ground movement; changing signs in X velocity is nearly impossible at a high speed
-Mario's ground movement is a bit slippery.

These make it really feel like Super Mario Bros 1 and 3. New SMB follows these a bit, though with some more flexibility. Super Mario World give much more in-air control, leading to different acrobatic possibilities and challenges. A 1:1 replacement of the SMB1 engine as outlined in Tepple's original post is very interesting from an implementation perspective, and my interest in the project is mostly for such an academic reason. I think if the intent is just to have an SMB1-like engine, that can be achieved by following these guidelines more or less.
Re: Rebuilding Super Mario Bros. piece by piece
by on (#147260)
The physics in SMB3 compared to 1 don't feel anything alike. I feel handicapped playing the original game.
Re: Rebuilding Super Mario Bros. piece by piece
by on (#147271)
It's time consuming, but simple enough to have someone convert each routine into pseudo code with some description of what the routine does and give that to another person to code. http://en.wikipedia.org/wiki/Clean_room_design

The person writing the code should be someone that has never looked at the disassembly/source.
Re: Rebuilding Super Mario Bros. piece by piece
by on (#147273)
There's a lot to be said about jump physics in games =P I mean, I could take Sol's and mention that:

  • Gravity is always accelerating constantly when falling by default.
  • When jumping and with negative gravity (i.e. going upwards), the acceleration is doubled if the jump button is released. This does not apply when falling, if the jump button is held down or if the ascent wasn't the result of jumping (e.g. landing on a spring wouldn't count).
  • The above applies per frame. So you could release and press it again before going downwards and it still affect gravity acceleration. This does indeed give some fine control over variable jumps.
  • Friction (i.e. horizontal acceleration) is halved while in the air. This applies to both increasing and decreasing speed.

And that's just the jump physics. And yeah, they aren't anywhere close to Mario's, but that doesn't mean worse or better either. (incidentally, the way variable jumps work was done because it was easier to implement, since it doesn't rely on a counter, just on a flag you'd already have for other reasons anyway)
Re: Rebuilding Super Mario Bros. piece by piece
by on (#147276)
Espozo wrote:
The physics in SMB3 compared to 1 don't feel anything alike. I feel handicapped playing the original game.

Then you aren't paying enough attention. SMB3 gives more control in the air especially, but Mario's strange jumps are more or less the same.

Even if the gravity modification is applied per frame, Mario reaches his maximum drop speed so fast it mostly doesn't matter once you've released the button.

Other jump physics aren't worse, they are different, but if you want it to feel like a Mario game then implementing something else isn't going to do it.
Re: Rebuilding Super Mario Bros. piece by piece
by on (#147279)
The problem with Mario physics is that putting aside the fact that they vary between games, they also do some... weird things. E.g. doesn't the running speed in Super Mario World alternate between three different values at its peak? (rather than the two you'd expect from subpixel physics) If I recall correctly which frame you jump on in a TAS matters precisely for this reason.

I think most people will just want good physics anyway, not necessarily those from a very specific game.
Re: Rebuilding Super Mario Bros. piece by piece
by on (#147286)
Creating a game by modifying every piece of another game is one way to learn. Part of what makes creating a game hard for a newcomer is understanding all of the pieces that are necessary to make a game. If you start with something that's already complete and working, it can make up for gaps in your knowledge.
Re: Rebuilding Super Mario Bros. piece by piece
by on (#147287)
Quote:
Rewrite SMB1 a subroutine at a time, replacing each subroutine with equivalent original code. This is how LAME was bootstrapped from the ISO MP3 encoder over the course of two years (mid-1998 to May 2000). It also gives a chance to optimize the engine's RAM use.

I don't know how cloning every subroutine ones after eachother would not make a copyright infigement. After all you're still copying the game engine and not just only it's functionality. You're copying the very software architecture they used. Especially if they optimised for ROM saving which means functions were very short (so they could be re-used more).
Re: Rebuilding Super Mario Bros. piece by piece
by on (#147288)
Bregalad wrote:
I don't know how cloning every subroutine ones after eachother would not make a copyright infigement.


See clean room link I posted above. As a classic example see this section on Compaq: http://en.wikipedia.org/wiki/Compaq_Portable#Software
Re: Rebuilding Super Mario Bros. piece by piece
by on (#147290)
Bregalad wrote:
I don't know how cloning every subroutine ones after eachother would not make a copyright infigement. After all you're still copying the game engine and not just only it's functionality. You're copying the very software architecture they used. Especially if they optimised for ROM saving which means functions were very short (so they could be re-used more).

Pretty much from the Clean Room page that was linked:
Quote:
Clean room design is usually employed as best practice, but not strictly required by law. In NEC Corp. v Intel Corp. (1990), NEC sought declaratory judgment against Intel's charges that NEC's engineers simply copied the microcode of the 8086 processor in their NEC V20 clone. A US judge ruled that while the early, internal revisions of NEC's microcode were indeed a copyright violation, the later one, which actually went into NEC's product, although derived from the former, were sufficiently different that they could be considered free of copyright violations. Interestingly enough, while NEC themselves did not follow a strict clean room approach in the development of their clone's microcode, during the trial, they hired an independent contractor who was only given access to specifications but ended up writing code that had certain similarities to both NEC's and Intel's code. From this evidence, the judge concluded that similarity in certain routines was a matter of functional constraints resulting from the compatibility requirements, and thus were likely free of a creative element.[9] Although the clean room approach had been used as preventative measure in view of possible litigation before (e.g. in the Phoenix BIOS case), the NEC v. Intel case was the first time that the clean room argument was accepted in a US court trial. A related aspect worth mentioning here is that NEC did have a license for Intel's patents governing the 8086 processor.[10]
The implication being that if you replace all the code it doesn't seem to be considered a derivative work. At least you can argue that this is a possibility as a legal defense.

The real problem is not whether it's infringement or not, the real problem is whether it gives Nintendo an excuse to sue or not. It doesn't matter if you infringe or not if it's cheaper to bail out than to go through the court costs.
Re: Rebuilding Super Mario Bros. piece by piece
by on (#147291)
rainwarrior wrote:
Part of what makes creating a game hard for a newcomer is understanding all of the pieces that are necessary to make a game. If you start with something that's already complete and working, it can make up for gaps in your knowledge.

I could maybe agree if we were talking about well commented open source games, but having to disassemble and reverse engineer an engine will not help at all.
Re: Rebuilding Super Mario Bros. piece by piece
by on (#147292)
We're talking about SMB, which has at least two comprehensive disassemblies already available:
http://www.romhacking.net/documents/344/ - Disassembly by doppelganger.
http://www.romhacking.net/documents/635/ - High level refactoring by Movax12, based on doppelganger's disassembly.
Re: Rebuilding Super Mario Bros. piece by piece
by on (#147295)
Bregalad wrote:
I don't know how cloning every subroutine ones after eachother would not make a copyright infigement. After all you're still copying the game engine and not just only it's functionality. You're copying the very software architecture they used.

It looks like you're heading toward a "structure, sequence, and organization" legal theory. I mentioned that the next step after replacing all parts is refactoring the messy architecture into something cleaner. This further obscures any "structure, sequence, and organization" claims.
Re: Rebuilding Super Mario Bros. piece by piece
by on (#147297)
Sega v. Accolade decided that copying code (specifically Sega's TMSS) was protected under fair use, allowing reverse engineering as a legal practice in the computer industry. The final statement made by Judge Stephen Reinhardt, who presided over the Appellate Case was, “We conclude that where disassembly is the only way to gain access to the ideas and functional elements embodied in a copyrighted computer program and where there is a legitimate reason for seeking such access, disassembly is a fair use of the copyrighted work, as a matter of law.”
There are four questions that determine fair use:
Is the purpose and character of the use commercial or non-commercial?
What is the nature of the copyrighted work?
What is the potential effect on the market?
What is the amount of original work used?

Sorry if this doesn't help, I just thought fair use and reverse engineering as well as disassembly were good to add here.
Re: Rebuilding Super Mario Bros. piece by piece
by on (#147301)
And once the "amount of original work" is less than a certain amount, the fair use defense doesn't even come into play because the works are no longer similar enough for there to even be copying. A full rewrite followed by a couple rounds of refactoring would mix it up so much that any similarities follow from common function.
Re: Rebuilding Super Mario Bros. piece by piece
by on (#147304)
Just rewrite everything like if you'd be making a Windows Mario fan game and try to mimic the physics.
Here's what I found when I was attempting to make a Mario clone. http://s276.photobucket.com/user/jdaste ... s.png.html
Re: Rebuilding Super Mario Bros. piece by piece
by on (#147308)
Do rebuild like that is interesting kind of ideas and possibly can be used when you want to be able to play the various new levels made up for Super Mario Bros. by the new free game engine (you might need to convert the data format though; doing so might also allow such level sets to be extended though even more longer).
Re: Rebuilding Super Mario Bros. piece by piece
by on (#147328)
Sik wrote:
Also don't call it OpenPit
I was joking. :?
mikejmoffitt wrote:
-Mario's rise follows the curve of a parabola flipped about the X axis, approaching the maxima.
-A much stronger downwards acceleration follows either at the jump's apex, or at the release of the jump key
-Mario reaches maximum vertical downwards velocity very quickly, as it is quite a low value.
-The initial jump "strength" is influenced by the player's horizontal velocity
-In-air navigation is limited compared to the on-the-ground movement; changing signs in X velocity is nearly impossible at a high speed
-Mario's ground movement is a bit slippery.

I think what you're trying to say might be better phrased that Mario operates on nearly-Aristotelian impetus physics (things fly until they run out of impetus, then fall), and releasing the jump button cuts his impetus off so that gravity starts affecting him. (The problem with claiming impetus is that he does have descent symmetric with ascent, but it works well to describe the rising motion, I feel.)

Also, though I may be wrong, my impression of SMB1,3 movement was that he had about five distinct angles,not a continuous acceleration (at least, when moving full-speed): 45° (while holding A/until impetus runs out), ~22.5°, 0°, ~-22.5°, -45°. (Other things seem to be simply actually accelerated, so I may be perceiving something here that I shouldn't.) ...on further thought, this approximates hyperbolic arc rather than parabolic, doesn't it?

SMB2 jumps are more obviously acceleration-physics-based, particularly if you observe Luigi.
Re: Rebuilding Super Mario Bros. piece by piece
by on (#147343)
Those angles you describe sound more like an accuracy problem put together with a gravity cap (since they'd be 2:2, 2:1, 2:0, 2:-1, 2:-2 in terms of distance).
Re: Rebuilding Super Mario Bros. piece by piece
by on (#147655)
Go for it! I would love to see it 8-)

I actually had a pretty long reply, but I failed to explain my thoughts on the possible backwards compability with level patches and stuff in a sensible way, so I will just keep it short and see what happens in this thread.