Wii Super Mario Rom

[Henrietta Naughton]

Inthis interview, we're going to talk about New Super Mario Bros. Wii, but rather than diving straight into a discussion of the new title, I'd like to begin by talking about Mario's roots. There will of course be a lot of readers who know all about this, but I think there are also people who are completely in the dark about how Mario began.

Sure. Now, this is something I've been asked about in hundreds of interviews, so I'll make it quick! (laughs) In the Pac-Man1 era, there were a number of games that were really popular in the video game arcades. Nintendo had released titles such as Sheriff2 but none of them quite achieved the level of popularity where you could call them hits.

Right. At the same time, you were also seeing the emergence of side-scrolling games where your character would run along. As I was originally an industrial designer, I would analyze those games while I played them, trying to figure out what it was about the way the games were put together that made them enjoyable and made people want to play them again.

Right. And basically, I concluded that this was born of the players being mad at themselves. So I would try to analyze how the game made players feel that way. It was when I was mulling over these issues that a more senior colleague, Gunpei Yokoi4, was good enough to explain a lot of things to me. I don't want to get bogged down in too much detail about the intricacies of game design, so I'll skip over this. Anyway, up until that point, I had been working as a graphic and packaging designer for games developed by other people...

I was involved in making games for arcades, but the kind of ideas I was suggesting weren't really getting picked up on... But then I was lucky enough to be entrusted with the entire development of a software title...

Yes, it's identical to Pac-Man! (laughs) So I sketched out a few ideas for games using Popeye. At that point, Yokoi-san was good enough to bring these ideas to the President's attention and in the end one of the ideas received official approval. Yokoi-san thought that designers would become necessary members of development teams in order to make games in the future. And that's how Donkey Kong6 came about.

Yes, we were. Let's say, for example, that there's one action in the game that the player can perform easily. Then let's add another simple action. These actions may be simple in themselves, but when the player is required to do them both at the same time, it becomes a whole lot more tricky.

So while those two actions might be easy to pull off on their own, when you try to do them simultaneously, it gets more difficult. And it's precisely because you think it should be easy to do that you get mad at yourself when you don't quite manage it, right?

So you're aiming to get safely to the goal using short cuts while constantly trying to predict the route that the barrels rolling towards you are going to take. It's easy to climb higher and higher. It's also easy to avoid the rolling barrels. But it's when you try to do those two things at the same time that it becomes challenging. What's more, you're also thinking about how to take the shortest possible route, so it gets even more difficult. We thought that we could work with that concept. It was at that point when we tried to make the screen scroll and were told: "That board doesn't scroll!" (laughs)

The "board" that you just mentioned is the circuit board inside the arcade game cabinet. At that time, there was a fair amount of individuality, shall we say, in each machine and, depending on the specific type of hardware, there were different limitations imposed. When you began work on Donkey Kong, the cabinet, which you were supposed to use, included a board, which wouldn't allow games to scroll.

Yes, that's right. The technical supervisor at the time asked us what on earth we were thinking: "One screen is plenty for a regular game! But you're making four separate screens! You might as well ask us to make four different games!"

Well, that might have been the case. Originally it was a game where you had to escape from a maze. To allow players to jump and avoid dangers would have spoiled the strategic element of the game. But then we thought: "If you had a barrel rolling towards you, what would you do?"

Of course you'd jump over it! (laughs) So we decided to use the button to allow players to jump and when we made a prototype to try it out, it worked really well. I think that if we hadn't allowed Mario to jump, it would have most likely proved to be a horrendously difficult game to play.

Also, if we'd made it so you'd been able to jump by pressing up on the joystick, the name "jump button" would never have come about! On the 2nd stage, we had vertical lifts and we were concerned as to how the player would be able to get on them. But if Mario jumped...

Really cool demake, but still needs work...

the physics and controls feel really off, as Mario falls at a steady pace immediately after releasing the jump button, and his jump is much higher (for example, getting to the top of 1-2 is much harder because I keep on hitting the bricks.)... I'm curious as to what's taking up all the tokens, as it's clearly not levels, and the code could probably be shortened even more...

In principle the controls in the original are probably delayed. But I think the controls in the original are a lot more diffucult , especially without gamepad... At least my girlfriend found this easier.

Nice work! I love how you used the pallete. Also I am not feeling the jump is a big issue.

There is a concern about Nintendo bringing this down. They are known to take out assets using their IP so be careful on publising it in the open.

What is the map data being used for? I see that you define maps in code, but the top half of map editor is still filled with data. Are those just maps you were building prior to taking the code approach?

Title screen is using map data. (the first 16x16 blocks).

More ist not used anymore... I created a custom level editor, which exports strings. But if I had known, that there is only enough memory for a few levels, I had not taken the trouble...

But this 8k token limit makes no sense at all. You can make a limit, but at least 16k+16kb user memory whould make sense.

Currently it is simple impossible to create games like mario, turrican or other 8bit titles. Which is sad..

Really great remake. The backward scrolling is a welcome addition to the original game as well. Other additions such as starting the game as Super Mario and the lenient fire-flower-counts-as-a-hurt-buffer are also fun tweaks, for starters.

It would be pretty easy to use that 4k of MAP that isn't used to store levels, but unless you could squeeze all the levels down to 4k may not be worth it since then you'd need different routines to load from string vs map.

I read the code. It sure looks like the first segment of letters are stored in hexadecimal... I do see where after that you switch to a different encoding. But there is quite a bit of data stored in ASCII HEX from where I sit.

As a note, it sounds like you're using a very inefficient representation of the levels in your strings. Are you storing literal tile layouts, or using a much more efficient 'sparse' layout like the original Super Mario Bros game did?

SMB1 defined the global sky/ground/background for the entire level in two bytes, then describes individual 'screens' (16-tile sections of the map, key look that matches PICO8) in two bytes per overlay, with a single overlay able to place multiple objects.

So really I think the main issue is your level format is overly huge because it's storing raw tile layouts instead of using such a 'sparse' structure. So yes you'd need to do more work to update your editor to do such a format, but that kind of 'indirect' map layout is really the key to fitting stuff into tiny systems like the PICO8 limitations.

Old games almost never stored the entire map in 'ready to render' format back in the day; they would commonly store a 'palette' of objects, and the map would define where those objects went and in what order, sorted so that the game only had to examine a few dozen bytes to update the screen.

This is why so many early games didn't let you scroll back: They didn't have structures that could be 'scrubbed' both directions cheaply, only in one direction, and the CPUs at the time couldn't brute-force-scan the entire level data to scroll backwards.

And storing raw data into the map/tile regions and then copying that out using peek() in your _init can be a LOT more efficient than packing data into strings. It avoids the cost of the byte->whatever encoding (which at a minimum will expand the data by 20% for ASCII85, or as much as 50% for hexadecimal) and then the cost of that in the 'compressed string' size limit.

Edit:

I am still hesitating because I have no idea how to deal with the token limit. using the map memory istead of strings, will propably bring some free tokens. But there are still some missing enemies/gameplay elements, that are necessary in the later levels

...format, which saves tokes. There's a lot of token optimizations that can be done, not one silver bullet, but this first step gets you well back under the compressed-string limit which was what you'd ran into first by far. :)

Sadly a lot of game design for the PICO8 can be "design a basic idea... then redesign it to actually fit the constraints of the system" at times as you learn more and more about structures and the like to use.

Hey, I played a bit, and even if it doesn't feel exactly a 1:1 reproduction, it feels pretty solid. But I have one nitpick with the game : the camera feels a bit off. When running to the right, the camera leaves Mario around 75% on the right side of the screen, leaving not enough screen space to see what's coming on you.

Since it's been a long time since this was originally posted, can you send the level editor you used to create the levels for this game? It would be good since this game has really good physics and could be a great base for some PICO-8 Mario games!

3a8082e126