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

Super Mario Bros design documents

Super Mario Bros design documents
by on (#70953)
Not sure if this is the correct forum, but anyway.. The "Super Mario 25th anniversary" for Wii has recently been released if you haven't noticed.
There's an included booklet which contains photos of the development-sketches (for example level-data) of "Super Mario Bros" for NES, which are really inspiring and cool to look at.
Just wanted to let you know.. :)

by on (#70954)
Nice. I love these pictures that show game development at nintendo. It's all more spaced out then I thought, but stuff does come together.

by on (#70959)
What the heck, it's soon christmas, here's one high resolution scan from the booklet. This kind of stuff makes my heart beats faster. :)
Can anyone read the japanese stuff?

http://dl.dropbox.com/u/2590713/SMB1.jpg

by on (#70960)
oRBIT2002 wrote:
Can anyone read the japanese stuff?

I can't read much (too many Kanji I can't be bothered to look up), but I find it pretty interesting that UP was supposed to jump...

Hum... There is some katakana under the "ATTCK" (lol typo) text that is easy to read: kick, rifle and beam. So, was Mario supposed to carry firearms or something?

by on (#70961)
Yeah I think I've read somewhere that Mario had a gun in an early prototype or something.

by on (#70964)
oRBIT2002 wrote:
Can anyone read the japanese stuff?


Yes.

Controls: Up=jump, jump height determined by how long you press the button. Can move left or right mid-jump.

left, right = move left or right. Holding B makes you run faster. If Mario has acquired the "rocket", mid-air horizontal movement will be accelerated with a press of the B button.

Down=crouch

A=Attack. If Mario is carrying a weapon/tool, A will make him attack with/use it. (possible weapons = kick (when crouching?), rifle and beam gun)

I can't make out the bottom page with the jump diagrams. There is a fragment that says that say "in the case of <something I can't make out>, horizontal movement is random". Maybe talking about enemy movement?

If you can link me to some other pages I will be happy to translate.

by on (#70966)
Here's another page:
http://dl.dropbox.com/u/2590713/SMB1-1.jpg

EDIT: I wonder what a SMB prototype with weapons included would be worth on e-bay. :)

by on (#70968)
oRBIT2002 wrote:
I wonder what a SMB prototype with weapons included would be worth on e-bay. :)

I imagine that a change this big was made during the design phase, so there probably isn't a prototype like that... You could of course make a hack like that and I'm sure you'd fool a lot of people!

by on (#70969)
oRBIT2002 wrote:
I wonder what a SMB prototype with weapons included would be worth on e-bay. :)

Someone on Bregalad's site in one recent debate would probably think it's Yet Another Fake Proto. I've seen a ROM hack with fireballs modified to be "grenades": they explode instead of bouncing.

by on (#70971)
Wow, thanks for the translation! Wow, cool docs! :D


I like how everything is in hex, too....and the background pages have the memory locations on them too, too cool. I need some of those!!! -goes to make some haha-


Wow. Very cool. Thanks for the link!

by on (#70972)
3gengames wrote:
I need some of those!!!

Like this one that tepples made because of this thread?

by on (#70973)
MetalSlime wrote:
Controls: Up=jump, jump height determined by how long you press the button. Can move left or right mid-jump.
[...]
A=Attack. If Mario is carrying a weapon/tool, A will make him attack with/use it. (possible weapons = kick (when crouching?), rifle and beam gun)

The descriptions of Up and A match how Mario behaves in Super Smash Bros. series released a decade and a half later. Except because N64 through Wii have analog Control Sticks, SSB uses stick-tap to run, freeing B for a fireball.

by on (#70974)
From the keyboard of Breglad:

Bregalad wrote:
YOU ROCK TEPPLES



This is very useful, especially for a reference for remembering where the attributes are at and the screen resolution. Two things I am bad at remembering. :roll:

by on (#71024)
Now I understand how game developers know everything about the game they're making before they program it.

I always thought they just guessed at what they need and programmed under the limitations of their own predictions.

by on (#71027)
psycopathicteen wrote:
I always thought they just guessed at what they need and programmed under the limitations of their own predictions.

That not advised even when you're working alone, but when you are part of a team this kind of documentation is an absolute requirement!

Professional game makers can't just get together at a bar one night, toss a few ideas about a plumber that eats mushrooms and go home to work on whatever part of the game they think is relevant. They must sketch the whole idea, and create the basic rules before they can develop it any further.

by on (#71045)
tokumaru wrote:
psycopathicteen wrote:
I always thought they just guessed at what they need and programmed under the limitations of their own predictions.

That not advised even when you're working alone, but when you are part of a team this kind of documentation is an absolute requirement!

Professional game makers can't just get together at a bar one night, toss a few ideas about a plumber that eats mushrooms and go home to work on whatever part of the game they think is relevant. They must sketch the whole idea, and create the basic rules before they can develop it any further.


I always wondered how developers knew exactly how much memory/PPU bandwidth they needed to reserve.

by on (#71048)
psycopathicteen wrote:
I always wondered how developers knew exactly how much memory/PPU bandwidth they needed to reserve.

I don't think they always did... I think that the first time you work with a platform it's hard to know where the limits are, but after several projects on the same platform you start to guess much better! =)

I know that when I am designing my programs I have several backup plans, in case my primary plan turns out to be impossible to implement. So for each different part of my programs I think of 2 or 3 ways they could be implemented, and when placing all the parts together I decide how to distribute my resources, possibly using the simpler/faster/smaller solutions in some cases.

by on (#71050)
I remember an interview where Miyamoto mentioned that he had thrown in the bike sound effects from Excitebike to test out how much CPU time the sound engine would take.

by on (#71074)
oRBIT2002 wrote:
Here's another page:
http://dl.dropbox.com/u/2590713/SMB1-1.jpg

EDIT: I wonder what a SMB prototype with weapons included would be worth on e-bay. :)


It's a design page about scrolling. They say they want to keep the "athletic" Mario from DK Jr. and Mario Brothers, but they want him to be bigger. Due to his bigger size they need to have the background scroll.

The description of the scrolling is familiar. Mario advances through levels left to right. When moving right, he will eventually reach a space called "Scroll Start". When Mario reaches "Scroll Start", his sprite stops moving and the background scrolls instead. Scroll speed is determined by Mario's running speed. If Mario slows down, the scroll slows down. If movement stops, Mario can walk left. Here, the screen doesn't scroll. Mario can move to the leftmost edge of the screen but not any further.

by on (#71086)
MetalSlime wrote:
oRBIT2002 wrote:
Here's another page:
http://dl.dropbox.com/u/2590713/SMB1-1.jpg

EDIT: I wonder what a SMB prototype with weapons included would be worth on e-bay. :)


It's a design page about scrolling. They say they want to keep the "athletic" Mario from DK Jr. and Mario Brothers, but they want him to be bigger. Due to his bigger size they need to have the background scroll.

The description of the scrolling is familiar. Mario advances through levels left to right. When moving right, he will eventually reach a space called "Scroll Start". When Mario reaches "Scroll Start", his sprite stops moving and the background scrolls instead. Scroll speed is determined by Mario's running speed. If Mario slows down, the scroll slows down. If movement stops, Mario can walk left. Here, the screen doesn't scroll. Mario can move to the leftmost edge of the screen but not any further.


Thanks so much, MetalSlime! :D Very interesting, I wonder where are the documents that were later in development and figured out that scrolling can only be X pixels and stuff. I know scrolling on here got a lot of talk and stuff brought up about it, where is it here? :D :P

by on (#71090)
Similar paper design documents exist for the Legend of Zelda. I know I saw some awhile ago showing graphics tile sketches.

by on (#71091)
tokumaru wrote:
That not advised even when you're working alone, but when you are part of a team this kind of documentation is an absolute requirement!

Professional game makers can't just get together at a bar one night, toss a few ideas about a plumber that eats mushrooms and go home to work on whatever part of the game they think is relevant. They must sketch the whole idea, and create the basic rules before they can develop it any further.

In fact we might even be surprised how they planify everything and do code last.
As you said, we wants to say results immediately, this is our nature and this is perfectly normal.

I've recently found an article about a FDS RPG that was going to be released on 5 disks, and that was given up early in the development, despite some japanese people already having pre-ordered it. Too bad I don't remember where I read that... I found that "by accident" when I was investigating prototypes though. They said there was no chances of finding leaked prototypes of games that never made it even close to being finished.

So yeah, how comes that they knew the game would fit 5 sides, but have given up very early in the development ? Also how comes people could pre-order a game that was just starting to get developped ?
The only answer is that they planned everything, estimating how many bytes it would takes. Also, they could develop a game in only a couple of months (not that this would make a good game though).

Or this could also as well be fake / distorted / mistranslated info. Especially since I don't remember the site, it was a site about prototypes.

by on (#71093)
MottZilla wrote:
Similar paper design documents exist for the Legend of Zelda.

I posted the link in the previous page.

MetalSlime wrote:
It's a design page about scrolling.

I find it curious how they have to explain in so much detail something that is so simple. OTOH, back in 84/85 scrolling wasn't so common, and not that many games used it.

by on (#71099)
Bregalad wrote:

I've recently found an article about a FDS RPG that was going to be released on 5 disks, and that was given up early in the development, despite some japanese people already having pre-ordered it. Too bad I don't remember where I read that... I found that "by accident" when I was investigating prototypes though. They said there was no chances of finding leaked prototypes of games that never made it even close to being finished.

So yeah, how comes that they knew the game would fit 5 sides, but have given up very early in the development ? Also how comes people could pre-order a game that was just starting to get developped ?
The only answer is that they planned everything, estimating how many bytes it would takes. Also, they could develop a game in only a couple of months (not that this would make a good game though).


I don't think the pre-ordering was all that uncommon, I remember years ago some gaming magazines had ads/pricelists where you could order games, and those lists did include games that weren't even out yet. I didn't notice if there were selling ones that didn't get released, but I wouldn't be surprised.

Was the game you are thinking of Seiken Densetsu? I'd read that it was an FDS game originally.

by on (#71102)
Bregalad wrote:
So yeah, how comes that they knew the game would fit 5 sides, but have given up very early in the development ? Also how comes people could pre-order a game that was just starting to get developped ?
The only answer is that they planned everything, estimating how many bytes it would takes.

That or they were planning to port a nearly finished prototype that they had going on some computer platform.

by on (#71116)
Quote:
I don't think the pre-ordering was all that uncommon, I remember years ago some gaming magazines had ads/pricelists where you could order games, and those lists did include games that weren't even out yet. I didn't notice if there were selling ones that didn't get released, but I wouldn't be surprised.

Was the game you are thinking of Seiken Densetsu? I'd read that it was an FDS game originally.

Yes, it was Seiken Densetsu I was mentioning. (for people who don't know it eventually was made a Gameboy game, and it's fun because that is the one that inspired me to do my current NES projet, Dragon Skill).
Few FDS games were more than one disk, let alone 5 ! That's 640 KB of data, more than FF3 !
So yeah I wonder how they could know the # of disks in advance... although I guess it's something you had to decide pretty early in development, as you have to decide when the user will have to switch disks, so what data goes on what disk.

It's possible to determine how much space you use for various data such as text, maps etc... but it's hard to determine size of the code without coding anything !
If you compress data it becomes even harder to predict how much space it will take.

by on (#71120)
tokumaru wrote:
MetalSlime wrote:
It's a design page about scrolling.

I find it curious how they have to explain in so much detail something that is so simple. OTOH, back in 84/85 scrolling wasn't so common, and not that many games used it.


It's been my experience living and working in Japan that the Japanese love to produce documents. The office culture here pressures you to "always appear busy even if you have nothing to do". The result is a surplus of documents. I'm being half-silly, but it's a little true. :)

by on (#71121)
Bregalad wrote:
It's possible to determine how much space you use for various data such as text, maps etc... but it's hard to determine size of the code without coding anything !

Try telling that to someone who has worked on Atari 2600 games. I imagine that in the NROM era, 6502 coders still had their instinctive sense of how many function points a gameplay feature took and how many source lines of code that was likely worth.

Quote:
If you compress data it becomes even harder to predict how much space it will take.

A lot of "compression" on small-RAM platforms such as the NES consisted of static dictionary compression (such as metatiling) and various methods to avoid internal fragmentation, which provide a roughly constant ratio. It's also possible to estimate a rough compression ratio based on a completed 1-chapter tech demo and (roughly) extrapolate that to the full game.

by on (#71220)
Quote:
Try telling that to someone who has worked on Atari 2600 games. I imagine that in the NROM era, 6502 coders still had their instinctive sense of how many function points a gameplay feature took and how many source lines of code that was likely worth.

Well no idea how you could guess the size of the code. I also had no clue about that function points. I bet it depends a lot of your coding style and efficiency too.

by on (#71277)
In the complete disassembly of "Super Mario Bros". floating around, I think there's actually 4 or 5 bytes that's unused. That's pretty good. :)

by on (#71279)
But then SMB1 is flexible in size because it has variable-length level maps. I'm pretty sure a few levels were cut or shortened to make the game fit. Half of Donkey Kong Country 2, for example, consisted of levels that were cut from the first Donkey Kong Country.

by on (#71281)
tepples wrote:
But then SMB1 is flexible in size because it has variable-length level maps.

What do you mean by that? Do you have examples of games with fixed-length level maps?

by on (#71285)
tokumaru wrote:
tepples wrote:
But then SMB1 is flexible in size because it has variable-length level maps.

What do you mean by that? Do you have examples of games with fixed-length level maps?

The overworld in The Legend of Zelda is a grid of 16 by 8 screens, and each screen is made of sixteen "vertical column" metatiles, each 16 by 176 pixels in size. Likewise, the dungeons of the first and second quests form a jigsaw puzzle in a circumscribed space, and each room is 12 columns wide (source).

by on (#71286)
I guess I don't understand what you mean by "variable-length level maps" then. To me it seems that the game you used as example uses fixed-size entities to build the levels, but the levels themselves vary in size.

These days I was reading about how level maps are stored in Sonic games and I found out that 1 and 2 had a fixed number of chunks (256x256 pixels in Sonic 1, 128x128 pixels in Sonic 2) per row, and a fixed number of rows. So basically they had a 2D area with fixed dimensions in RAM where levels maps were decompressed to, meaning that the engine always worked with the same level size. Sonic 3 changed that, and introduced a system with contiguous RAM use (rows start immediately after the previous one) and pointers to the start of each row of the level map, in order to have control of the dimensions, which allowed it to have larger levels than Sonic 2. Maybe that's a good example of fixed-length vs. variable-length level maps?

by on (#71288)
LOZ has exactly two maps, each of which is fixed in screen size and data size. One map contains all the overworld; the other contains all the dungeons for both quests. The size of these maps was set when the game was conceived, and in fact, the second quest was added specifically to eat up unused space in the dungeon map. If you "remove" a screen, you don't save any bytes; you just have several-bytes-sized hole in the map. The encoding is, as one more familiar with modern audio and video codecs might say, "fixed rate".

SMB1, on the other hand, has levels that are 1 screen tall and of unbounded width. Each map has a pointer to where it starts, and there's no limit to how many screens or bytes before it ends. The levels are variable length, and their encoding is variable rate, so removing objects will save bytes.

by on (#71292)
Well nothing prevents them from not using some "squres" in the world map and therefore save space.

Also, I also wanted to pull the limits of a 32kb PRG ROM to the maximum, just for the heck of it :)
Probably the extreme limit would be to fit a complex RPG with mapper 3, 32 kb PRG ROM + a whole lot of CHR ROM + SRAM.
Unless it's absolutely necessarly to place it in PRG ROM, data would be read from CHR ROM before being used. That's pointless I know I'd just like to try that for the challenge.