[Gamasutra's first-ever WiiWare postmortem reveals the story behind overlooked block puzzler MadStone, with technical, design, marketing and productivity lessons galore.]

Introduction

Eighteen years ago, my brother and I decided to make a Nintendo game. I was eight years old and he was four. I didn't know what we were going to make, much less how to make it. Nevertheless, nearly two decades later, we actually managed to achieve our childhood goal. This is the story of our first game for a Nintendo console, a WiiWare game called MadStone.

Background

MadStone is a 2D falling block puzzler that costs $8 on WiiWare. It was designed to mimic the simple-but-deep mechanics of games like Tetris Attack, Meteos, and Puyo Pop. It features a linear 1-player arcade mode and several competitive modes.

Before releasing MadStone, my company, RiverMan Media published two moderately well-received PC casual games, Cash Cow and Primate Panic.

A screenshot from the final version of MadStone

What Went Right

1. Stalking Nintendo

I work part time at IBM as a user interface designer. One morning, one of my coworkers stopped by my office. He had just read an article about WiiWare, Nintendo's downloadable software service targeted at smaller projects and indie developers. My friend suggested that my company should pursue making Wii games through the program.

My initial reaction was, "No way!" I'm a huge Nintendo fan and I love the Wii, but I thought that we were way too small, too inexperienced, and too underfunded to actually pull it off. Also, the prospect of directly pursuing my childhood dream scared me a little. What if I screwed things up?

My friend left my office and curiosity got the better of me. Sitting at my desk, I Googled Nintendo's corporate phone number. Not really expecting anything to happen, I pulled out my cell phone and dialed them up.

Apparently Nintendo's receptionists don't get a lot of calls from random people asking to develop Wii games, because after an awkward moment they actually put me through to someone.

The WiiWare representative I talked to told me that he'd be at the Austin Game Developer's Conference the next week. He told me that he'd be happy to tell me about WiiWare in person. Woohoo! I bought some expensive last-minute tickets and headed to Texas.

Unfortunately, there was a flaw in my strategy: I had no firm plans for when or where to meet up with the guy! Nintendo didn't have a booth, and when I arrived at the conference, I found myself frantically scanning name badges, hoping against hope that one of them would say "Nintendo." No luck.

Finally, in desperation, I Googled Nintendo's phone number yet again. I pleaded with them to give me the representative's phone number so I could get in touch with him. Of course, giving out employee cell numbers is understandably against company policy. I explained to them that my entire reason for being in Austin was to meet up with him, that the conference was almost over, and I really needed help. Finally they broke down and gave me his number.

Just a few hours before his flight home, the Nintendo representative and I met up for coffee. I told him about my company and explained how much we wanted to develop for Nintendo consoles. He agreed that RiverMan Media sounded like a good fit for WiiWare. I left the meeting feeling absolutely ecstatic.

All told, it took us about three months, dozens of phone calls and emails, and lots of pestering before we finally crossed the threshold of becoming Wii developers. We are a small team and Nintendo clearly wasn't overwhelmed with our credentials. It was a frustrating process and I often wondered if I'd made the right decision.

However, a lot of good things came out of the ordeal. We became closer with several key people at Nintendo, and we got a chance to develop our core technology without the temptation of diving right into a game. Nintendo even helped us get development kits at a reduced price from a company that didn't need them anymore!

The Lesson: Getting your foot in the door is not easy. Crossing the threshold will almost certainly require you to move beyond your comfort zone.

2. Sticking with 2D

I'm a firm believer in the following principle: low budget 2D looks better than low budget 3D. Way better.

For me, consistently choosing 2D projects is a no-brainer. I have my personal biases (such as preferring the look of Miyazaki movies to Pixar films) but 2D makes sense for several very practical reasons:

One other important point is that 2D games are much rarer these days than 3D games. Lots of gamers crave old-school 2D, but aside from DS, these games get relatively little attention from large developers. Interesting 2D games automatically get noticed by gamers and the press.

Working on MadStone in-game art in Photoshop

All told, I don't think a 3D title would have been a good choice for us. There are too many complications that would have distracted our attention away from the game itself. Most gamers will probably tell you they prefer 3D games, but I believe there will always be a place for sprites and tiles!

The Lesson: Rather than being distracted by the bleeding edge of technology, it's better to use techniques your team is comfortable with so you can focus on the game itself.

3. Adopting Slag: Elegance and Dependability

I'm going to tell you a secret that I learned while at IBM:

Almost all enterprise-level business and medical software is now written in Java or another high-level managed language.

Complain all you want about performance and missing pointers, but there's a good reason big business prefers Java: programmers write fewer bugs, and bugs are expensive.

There's no reason for games to be an exception to this rule. Worrying about low-level memory management distracts programmers from focusing directly on the solution and writing clean code.

That's why, when my brother Paul Stevens and I started RiverMan Media, the first thing we did was ensure that we had a development platform that abstracted our game code away from low-level bits and bytes.

Luckily for us, we have a very good friend who's not the least bit afraid of asterisks and ampersands. Abe Pralle, owner of Plasmaworks and a professor at Northern Arizona University, developed exactly the solution we needed.

Over three years, our ideal game creation environment was crafted in two phases:

For our first two games, Cash Cow and Primate Panic, Abe created a library called Plasmacore. Using the Java Native Interface (JNI) Abe created an API that allowed Java game code to call fast DirectX rendering code written in C++. All the logic for the game itself was written in a safe, memory-managed environment. This setup facilitated rapid development and elegant code.

The Java / DirectX solution worked great for our PC games. It worked so well, in fact, that I was reluctant to leave it behind. However, there were a few obstacles that prevented us from using this framework on the Wii:

This is where the second part of Abe Pralle's plan was set in motion: we adopted his ergonomic programming language, Slag. In the words of Abe's web site:

Slag is an elegant, powerful, and efficient statically-typed, object-oriented language designed to be the high-level language of choice for game engines and frameworks. Light and portable, its virtual machine can be easily integrated with any C++ program. Slag's semantics (nature and purpose of operations) are similar to those of Java and C# while its clear and concise syntax resembles a blend of Java and BASIC.

A Slag code snippet from MadStone

As I mentioned, I was reluctant to switch to Slag at first. Java has an extremely robust library of utilities, a huge network of users, several great IDE's, and is very stable. Slag, before we adopted it, didn't have any of these things. However, as we explored using it, the benefits became overwhelming:

Because of these clear advantages, we committed to developing in Slag. We wrote foundation libraries, an Eclipse plug-in, and several prototypes to make sure all the features we needed were covered.

Spending the extra effort to get an elegant and rock-solid programming framework was worth the effort. To this day, our games still have no known bugs, despite us having no dedicated test team! That's partly because Paul and Abe are awesome programmers, and partly because we set up a system that facilitated clean, stable, code.

The Lesson: The programming language is your coders' medium of expression. Choose a language and framework that allows your programming team to focus on the game, not the computer.

4. Getting a computer science degree while making a commercial console game

My brother Paul started programming commercial games for our company during his first semester of college. He didn't have any significant programming experience, he just knew that he loved games and computers. In fact, he coded our first game, Cash Cow, at the same time he was learning that functions could return values. Before that it was all global variables and static arrays!

Handling a full course load while programming a commercial console game was certainly a tall order. He would have had plenty of work with just school or just MadStone. Effectively scheduling his time to manage both undertakings was a test of his focus and willpower.

The secret to Paul's impressive dedication is very simple: he loves spending his time making games more than anything else.

A lot of people think they want to make games, but very few understand the dedication and endurance that game development requires. After the initial excitement of a project wears off, you are in for months or years of hard work with no light at the end of the tunnel. You've got to love making games enough that you are enthusiastic about developing them even when there's no end, or money, in sight.

I'm really proud of my brother. He took his passion for playing games and transformed it into both a 4.0 GPA and a record of well-designed and elegantly coded commercial titles. He sets a fine example for the kind of mindset that independent developers need to succeed.

The Lesson: Game development is a career that many aspire to, but few understand. You should absolutely love creating games or choose something easier!

5. Being nice, even when we didn't feel like it

News that MadStone was in development leaked out unexpectedly one day. We had a small announcement on our site, two screenshots and a short video. But since we had virtually no traffic, I didn't expect it to be noticed.

The response to the first bit of media coverage was somewhat hostile. Mostly, blog commentators seemed to ignore the specifics of the game and focused on the fact that WiiWare was getting "yet another puzzle game." However, nothing was off limits, and the music, gameplay, and graphics were also met with criticism.

A selection of MadStone blog comments on wiiware-world.com

My first instinct was to defend ourselves against the criticism. Then, after I'd cooled down, I thought maybe it would be better to shake it off and ignore it.

Ultimately though, we decided that we'd participate. We'd introduced ourselves to readers and responded to their comments. Rather than outwardly defend ourselves, we explained our goals and let them judge for themselves whether they were interested. We thanked them for their feedback and left lots of smiley faces!

Forcing ourselves to befriend a tough audience paid off immediately. Comments on blogs instantly went from dismissive negativity to genuine interest and support. We started receiving fan letters. Editors of sites emailed us to thank us for our participation. They requested exclusive interviews and previews. In general, I think players were happy to have the chance to interact with a real game developer.

There's no way of knowing for sure, but I think a significant number of MadStone's early sales come from the sites where we were able to actively engage with readers.

The Lesson: The online community can make or break your game. Participate, answer their questions, accept their criticism, and most importantly, be honest and real.

What Went Wrong

1. Assuming we could make a block-based puzzler stand out from the crowd

Our casual games for PC were both modestly innovative puzzle games. They took familiar themes, mostly centered around matching, and gave them just enough of a twist to make them interesting and somewhat successful.

Cash Cow, our first casual game

Because we were very familiar with puzzle games, we felt that making another puzzler for WiiWare was the right choice for our team. We thought that we could add enough of a twist to make the game unique and exciting.

Choosing to make a falling block puzzle game was a serious mistake.

When we announced MadStone, gamers' reactions were dismissive. As I mentioned earlier, many of the blog comments and forum posts that we read focused on the fact that we were releasing "yet another puzzler." There was very little interest in the specifics of our game.

Obviously I was disheartened by a lot of the feedback we got. We'd worked hard at giving MadStone an interesting mechanic and unique aesthetics. Don't people love games like Tetris Attack, Meteos, and Lumines?

Of course they do. The problem is, in the last few years we've been absolutely inundated by matching and falling block puzzle games. There are hundreds of these games available for download on casual gaming portals. Many are offered free as Flash games.

It's no wonder that players uttered a collective "meh" when they read about MadStone. No matter how interesting it was within its genre, it was still a falling block puzzle game. We did our absolute best to make it stand out, but the sad fact is that the world has already seen our game many, many, times in other forms. Players like to be surprised and excited. Standard puzzle games can't do that anymore. Looking back, I understand that MadStone's fate was sealed the moment it was conceived.

The Lesson: Choose a theme and genre that will get people's attention. If you saw your game announced on a blog, would you be excited?

2. Thinking too retro

Coinciding with our unfortunate choice of choosing a genre past its prime, we also chose to model many of our design decisions on older games that were popular in the day, but that might seem too thin by today's standards.

My brother and I put hundreds of hours into Tetris Attack and Kirby's Avalanche (aka Puyo Puyo) growing up. I count these games among my favorites of all time. Since we hold these games in such high regard, it was natural for us to design MadStone using these games as a benchmark.

Specifically, we opted to include a small selection of carefully balanced game modes, mimicking the handful of options offered in Tetris Attack and the original iterations of Puyo Puyo.

Tetris Attack, one of the games the inspired MadStone

This was another big mistake. The limited number of modes available in Tetris Attack and Kirby's Avalanche might have passed back in the day, but modern puzzle games are expected to have a large variety of different modes and options to mix things up.

MadStone basically only offers competitive play with a few bonus levels and varying win conditions. Compared to other modern games like Tetris Party, which even lets players control the game with the Wii Balance Board, MadStone gave the impression of lacking features.

We should have spent more time studying modern puzzle games. It would have been clear that our limited number of game modes wouldn't suffice. Instead, we patterned our decisions after old games without realizing that the industry had steadily been marching onward.

The Lesson: Love the old games you grew up with, but don't forget that your games will be compared against the latest and greatest.

3. Laziness (and hoping the press would forgive us)

I don't envy the task of game reviewers. Let's admit it: the most influential part of their job is to give a numerical score their subjective experience of playing a game. The written portion of a review, no matter how nuanced, is overshadowed by this single number.

But what does a score really mean? Is it the game's value for the money? Is it the game's quality compared to other games in the same genre or the same platform? Is it a game's quality compared to every other game in existence?

When we started working on MadStone, we knew that WiiWare games would be priced between $5 and $20. Considering companies like Square Enix were making high-budget Final Fantasy games for the service, we decided to price MadStone at $8.

Given this amount is five to seven times less than the price of a retail Wii game, we operated under the assumption that reviewers would overlook missing features like extra game modes, widescreen, multiple control schemes, online multiplayer, and progressive scan.

This was wrong. Every single review makes exhaustive mention of the features the game is missing, and it cost us dearly. IGN's review, had it been more positive, may have helped boost sales considerably. Instead, with a 4 / 10, sales were disappointing.

My initial reaction was to be angry that reviewers would place so much emphasis on mentioning the missing features of an $8 game. Of course it's missing features! It was made by three people!

Then I realized that this was at least partially avoidable. With a few extra weeks of work, we could have implemented extra game modes, widescreen and progressive scan, and maybe a few alternative controller positions. We didn't do that, though, because we thought we didn't have to.

I'd argue that most of these features wouldn't actually make the game more fun. We tried several controller schemes and we chose the one we did because it's the most responsive and intuitive. The visuals, being composed of mostly abstract shapes, weren't really affected by widescreen stretching. The modes we included represented our best effort at balancing the game's mechanics.

The fact is though, the list of missing features made MadStone very easy to rate poorly. If one game is missing five common features, and another game is missing only two, a reviewer can justifiably rate the former game much lower.

I wish we'd taken the time to put in the features we knew the game was missing. We made the conscious choice to draw the line at a certain point, so we could release the game in a timely manner. We should have drawn the line just a bit further.

The lesson: Don't give reviewers the chance to make easy marks against your game. If you can implement a common feature for relatively little cost, do it, even if it doesn't really enhance the game.

4. Productivity Killer: The Internet

An indie developer has a lot of options when he or she sits down to work in the morning. On a typical day of MadStone's development, my choices included background painting, animating sprites, special effects coding, writing marketing material, arranging playtests, refining game balance, recording sound effects, and handling logistics with Nintendo.

Faced with all these possibilities, I often resorted to the most obvious solution: check my e-mail and read Slashdot.

I can tell you without an inkling of doubt that if I had unplugged from the Internet, MadStone would have been a better game. Blog reading is easier than game making, and my brain seems hard-wired to take the easy way out. I'd often kill hours a day idly browsing, getting almost nothing important done.

A about two-thirds of the way into the project, I finally started to accept the fact that my habits were slowing me down. I took what I considered to be some radical steps: I uninstalled Gmail Notifier, I deleted the Firefox shortcuts from my quicklaunch bar, and I unplugged my Ethernet cable when I was making art or composing music.

A clean, unplugged, workspace

The transition wasn't easy. For awhile my eyes would instinctively look to the corner of the screen to see if I had e-mail. Seemingly on its own volition, my mouse cursor moved toward where the Firefox icon used to be. Most surprisingly, I experienced pangs of loneliness and isolation.

I got over it and I'm glad I did. Not only do I work more hours now, they're cleaner and more focused. I feel a connection to my work that was impossible when I took Internet breaks every few minutes. I've even started to experience that fabled state of "flow" where I enter a zone of productivity and my work seems to finish itself.

The Lesson: When you're working, work. Focus wholly and completely on the task at hand. Unplug if you have to. Take sustained breaks a few times a day instead of tiny breaks every few minutes.

5. Underestimating ourselves

MadStone was a truly gargantuan achievement for my team. The last year was without a doubt the most challenging time of my life. We consumed an enormous amount of mental energy making MadStone a reality.

Unfortunately though, MadStone caused little more than a blip in the industry as a whole. It was sometimes commended, sometimes disfavored, and mostly ignored. Part of this is because we are a small team in a big industry, and part of it is because we held ourselves back from making something more remarkable.

Is independent game development the sandbox of blooming creativity we imagined when we were kids? Absolutely. I'm doing everything I thought I'd be doing when my brother and I held those rectangular NES controllers and decided that Mario's world would be our world too.

What I didn't anticipate was how difficult it would be to pry ideas out of my own head. It's one thing to believe in your own potential, and quite another to sit in front of an empty monitor and make that potential into a solid game with real art and tuned mechanics.

I wish we would have pushed the creative envelope a bit farther for our console debut. We prototyped plenty of more innovative, exciting, ideas, but we were too worried that we wouldn't be able to pull them off.

We stuck with what we knew. This was good from a project management perspective (hey, we finished!) but I'll always wonder what would have happened if we'd gone just a little bit closer to the edge...

The Lesson: You're an artist and your job is to push creative limits. Do a little bit more than your best. Make the game that only your team can produce.

Conclusion

On October 6, 2008, my brother and I achieved our childhood dream of publishing a game on a Nintendo system. Our feelings of relief and elation were tempered by the mixed reception the game received. Not everyone appreciated our effort as much as we hoped!

Despite the response of our critics, I stand by MadStone as a solid, entertaining, puzzle game. It has balanced, fast-paced mechanics, and unique, high-energy aesthetics. We worked hard to make it a game that we would have liked when we were kids. I think that shows.

Player 1 pwns Player 2

Do I wish that our game was a bestselling instant classic that made my company an overnight sensation? Yeah, sure. But ultimately it's important to remember that for all the hard work we put into it, MadStone was just one game. We've got plenty more struggles, victories, and challenges ahead of us as we continue trying to make better and better titles.

Achieving one dream just clears the way for imagining new ones. I thought that once we finally published a game we'd have smooth sailing for the rest of our careers. Instead, I'm learning just how much more we have to learn. The further you make it, the further you have to go!

Fact Box

Number of Developers: 3

Budget: Approximately $10,000 (all developers paid through royalties)

Development Time: 8 months

Release Date: October 6, 2008 (North America)

Platform: WiiWare

Hardware:  Off-the-shelf Dell PCs with 4GB RAM and 256 MB video cards. Nintendo Wii development kits. Wacom tablet.

Software:  Eclipse, Tortoise SVN, FL Studio 8, Adobe Photoshop CS2, DarkTree Textures, Nintendo Wii IDE

Notable technologies: Slag object-oriented language (www.plasmaworks.com)

Size of Project:

Art and sound files: 250

Lines of code (MadStone Slag Code): 15,000

Lines of code (Slag compiler and runtime): 46,000