Nintendo DS

The tool that the designer first used to make a microgame was, compared to the final product, rather meager.

That's right.

Even so, he could do quite a lot right away?

Yes. There wasn't much you could do. But precisely because there was little you could do, you could put a game together like a puzzle, leading to the surprising discovery of just how much could be accomplished.

So even if you couldn't do much, if you used multiple functions together, you could accomplish quite a lot. But games make use of quite a wide variety of movements, so I imagine you wanted to start throwing in all kinds of stuff.

We kept ourselves down to the functions that were absolutely necessary. Then, when we actually made games, we could apply them in a variety of patterns.

So rather than put in a bunch of functions at the start and then get rid of the ones that were unnecessary, you confirmed the many ways you could enjoy just with a few functions, and added more that you felt were absolutely necessary. Times like that, you want to throw in all kinds of stuff. I'm surprised at how well you controlled yourselves.

If lots of buttons for different functions were lined up, you would be unsure of which one to choose.

So we decided to go with six buttons for different functions. To meet that number, we gave precedence to the most important functions.

For example, suppose you want to have Mario jump up and down in the same spot. To have him jump, you use the jump function. When you do, he'll jump all around the screen like a frog. So you narrow the movement field so he jumps up and down in the same spot.

By decreasing the area for the movement, you can make him jump vertically.

All you have to do is specify the range for jumping with the stylus .

But, Hatakeyama-san, didn't you want to throw in all kinds of stuff? Didn't you actually say, "Six isn't enough!" (laughs)

Actually, I did! (laughs) For one thing, I didn't have much experience making video games.

It's normal to think it would be great if you could do this, that and every other thing.

A lot of the time I would say to Abe-san, "I wanna put in this kind of action," and he would say, "You can do that by combining this and that other function." Then he would hit me with a killer line that always struck me down...

A killer line?

He'd say, "These games will only last a few seconds." (laughs)

Ah ha ha! (laughs) Yeah, microgames do only last a few seconds.

Even if you could do something really fancy, the game will be over in just a few seconds.

That's a convenient rationalization, but I sort of understand. You have a short attention span and quit making a shooting game halfway but you thought you could do it with a game like this.

That's right. Short microgames last about four seconds, long ones, about eight.

They're over in a flash.

But we wanted it to be able to make a wide variety of microgames. So we experimented to see if we could use WarioWare: D.I.Y. to make the games so far.

You mean whether or not you could re-create with WarioWare: D.I.Y. the microgames of WarioWare: Touched!

Right. We tried to recreate the first stage of Touched!, which you can play simply by touching the screen. Sometimes we could do it, sometimes we couldn't, but when we couldn't, we made repeated adjustments toward being able to.

In the end, how many were you able to recreate?

Almost 100%.

It was a little difficult for ones with random elements, but we could recreate most of them.

Because since so much was possible with it, I suppose debugging was difficult.

It was. This time, first we got the part for making games firmly established, then proceeded relatively early on with the debugging for it. Then the debuggers were making all kinds of games...

The debuggers became workmen on the microgames? (laughs)

Well, creating microgames was part of their work as debuggers, but they went above and beyond the call of duty, mastering all sorts of advanced techniques.

They got to where they could make some incredible stuff to make our developers think they had been outdone. (laughs)

Not a single one was a programmer, though.

One time, a debugger said to me, "Isn't it a problem that you can't do this action?" I said, "Well, let's put that on hold because technologically it's difficult." Then a little while later he came back and said, "I did it by putting this and this together."

What? Who's the real programmer?! (laughs)

(laughs)

So some of the actual microgames made by the debugging team are actually in WarioWare: D.I.Y. and their names appear in the staff credits.

Game designer-slash-debugger. (laughs)

That's amazing. (laughs) Nothing like that has ever happened before.

I understood then how much could be done even by non-developers.

But the debuggers also told us, "Now we know how you game developers feel."

We evaluated their microgames, saying stuff like, "Maybe you should fix this in consideration of the players." (laughs)

Isn't that sort of backwards? (laughs)

(laughs)

The debuggers who received such advice said that was exactly the kind of thing they had been telling us all along! (laughs)

Maybe now that this game has caused the debuggers to understand how you developers feel they will be a little nicer to you. (laughs)

Speaking of debugging, Nintendo caused you a bit of trouble this time, right, Sugioka-san?

You mean the NAND Card, which we used for the first time with this product. (laughs)

A NAND Card is a new type of DS card with flash memory for large volumes, called NAND memory. Compared to the DS card used with regular DS games, you can rewrite and save large volumes of data, and erase or rewrite data much faster. If I hadn't proposed to Abe-san using NAND cards, this game would probably have come out a little sooner.

I spoke with our hardware staff right after I received your advice. I told them the schedule and that you wanted to use NAND cards, and they said, "No, it can't be done." The schedule was a little too tight.

Nonetheless, you still wanted to do it.

That's because rewriting data is so unbelievably fast with an NAND card. We were originally planning to use the same DS card as with Band Brothers DX, but with that it would have taken time to save.

With WarioWare: D.I.Y., you work on a game, save it, work on it, save it. You want to save the data you've made frequently. With the Band Brothers DX DS card, you have to wait four to five seconds, which is frustrating. So, no matter how hard development might be, saving would be supremely fast, so I thought we should use the NAND card.

It also possessed the merit of increasing the number of microgames that can be saved. You can save up to 90 games.

Right. I knew how nicely it would work with the game, so partway through development I suggested using the NAND card, which was nearly complete. But since this type of memory was being used for the first time with game software, unexplainable problems occurred.

There wasn't any problem when we were working on the development tools, but as we moved onto the mass-production model, when we used that memory, it would just suddenly stop.

Sugioka-san eventually figured out the cause.

In the end, we put Sugioka-san in charge of the hardware debugging for the NAND card. Explaining problems that don't reappear with the development tools makes for quite difficult debugging. Sugioka-san, if you hadn't gone deep into it and pinpointed the problem, we still might not have an idea of when it could go on sale. Good work.

No, when I think about future projects, I'm glad we used the NAND card.