If you look at older platformers, and even many later ones for other platforms and even the NES, there is typically no "momentum" and "realistic" physics for the main character that you control. Even "Mario Bros." (the arcade game, ported to NES) uses very strange/primitive physics.

I've long wondered: does Super Mario Bros. for NES have the "realistic" momentum effect just because they were the first to think of it and/or have the skills and/or desire to put it in a game? Or does it actually require some kind of "expensive" mathematical calculation which earlier (arcade) hardware simply didn't live up to? And the NES was simply powerful enough to be able to accomplish this?

It's pretty strange if you think about it. It's almost unique to the Super Mario Bros. series of video games, really. I always assumed that other developers simply weren't as good with math/physics or that they were just sloppy developers and didn't take the care to give their game a realistic/"genuine" feeling to how you control the guy.

  • 1
    Can you specify what consists realistic or unrealistic physics/momentum and ho that differed between the games (and which games) you want to use as example? Without clear definitions what this is about it might attract opinions only.
    – Raffzahn
    Mar 23, 2021 at 18:42
  • 2
    @Raffzahn I'm referring to how Mario slowly gains momentum when running, heavily affecting the physics of jumping and controlling Mario. In contrast, most other platformers seem to have zero concept of momentum, with the character having full speed immediately after starting to move after standing still.
    – Z. Laris
    Mar 23, 2021 at 18:50
  • 1
    Erm, my remark isn't about discussing this using vague terms in comments, btu a reminder to add this information to the question to make clear what you want an answer to be based on. (Beside: Acceleration has been seen in games before - as early as the 1979 Asteroids arcade, eventually even before with STT pong versions in 1976, so it's about programmers deeming that important or not, not hardware.)
    – Raffzahn
    Mar 23, 2021 at 19:24
  • 2
    I think you need to be a little more specific about the systems you are comparing against. But even without that, if there’s one thing I know about the NES, it’s that it’s based on the 6502 CPU, which was extremely popular back in the day, so it would have been pretty trivial to have the very same sprite movement calculation code ported to other systems based on the 6502. So I’d lean towards ‘it’s really just a matter of programming’. Mar 23, 2021 at 19:36
  • 8
    Joust is not only an obvious predecessor with realistic physics but also the game that [non-Super] Mario Bros directly rips off.
    – Tommy
    Mar 24, 2021 at 0:39

3 Answers 3


There is nothing about the NES that enables Mario's more physics-based behaviour; credit is due to Miyamoto et al for that innovation. Algorithmically, all there really is to it is maintaining a fractional part of location and applying user input as an acceleration rather than directly as a velocity.

So: 16-bit arithmetic rather than 8, two adds rather than one.

The NES has a reasonably fast processor for an 8-bit console but it's within ordinary bounds, and none of the other chips help in the physics calculations.

Sticking with the cost of computation stuff, exact mechanics aside:

Realistic momentum was a key part of the very first arcade game, Computer Space, to the point that few could control it — it's set in space so there's no sense of wind resistance or anything else to decelerate you other than turning your ship around and accelerating in the other direction. You can see that strain of physics get much closer to the mainstream in some of Atari's vector arcade games, Lunar Lander and Asteroids being obvious examples.

A great home example of that line of gameplay is Thrust.

Trying to come up with things that look closer to platformers, and just off the top of my head, Chuckie Egg in its Acorn and Amstrad variations as a title that absolutely nails gravity, and Exile for the Acorns and the Commodore 64 develops a pretty complicated system of physics that also ropes in buoyancy and objects interacting with one another.

I'm sure there are innumerable other examples, many better and/or earlier, those are just some that I'm acquainted with.

  • 4
    Thrust+ on the Atari 2600 manages to not only perform physics calculations of a simple ship, but also of the combination of a ship and a tethered object which can rotate around it, on a CPU that runs at 2/3 the speed of the one in the NES.
    – supercat
    Mar 25, 2021 at 20:34
  • 4
    @supercat not only that, but the 2600 also has less that can be offloaded onto the TIA (graphics chip), so more CPU cycles were likely being used for drawing the game objects as well.
    – Wyatt Ward
    Mar 26, 2021 at 15:18

I cannot answer the question from a game design standpoint, and I suspect the real answer lies there. Hopefully someone will be able to preempt my answer here with that perspective.

Or does it actually require some kind of "expensive" mathematical calculation which earlier (arcade) hardware simply didn't live up to?

Such calculations are not particularly difficult. They would not use up very many processor cycles. Various ways to apply a curve to the acceleration rate would have been obvious to programmers at the time, if they wanted to implement such a feature.

The main limitation would be ROM space used for the routines. ROM was at an extreme premium on the earliest arcade platforms and consoles. Some of the earliest microprocessor-based arcade games had as little as 1 KB of ROM. The total number of instructions you can fit in that much space is measured in the hundreds.

Even by 1982, most games for the Atari 2600 are 4 or 8 KB and big arcade games were weighing in around 32 KB. Released in 1985, the Super Mario Bros. cartridge had 40 KB total of ROM. The designers would have been far less constrained, compared to even just a couple years before, when it comes to things like a couple dozen instructions to implement the feature you mention. This was not specific for the NES, and came from the general cost of ROM coming down; it would have benefited most platforms.


Shigeru Miyamoto and Takashi Tezuka talk about it in this interesting video about designing the game:


At 4:07 they start talking about the game physics. The idea was to simulate Mario having weight, not just dots moving in whichever direction you push the controller.

"Because it's an image drawn on a flat, 2d surface. When he moves around, goes backwards, and jumps, and then you try to reflect those actions using a flat surfaced image in a program you just don't feel that weight .... that's why there's a bit of slippage... adding weight helps the player believe it's a real character. This helps form an emotional attachment."

There are other videos on YouTube where Miyamoto talks about the same topic a bit as well.

To answer the question, this was mainly a Nintendo design decision that lends itself to great gameplay.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .