A behind-the-scenes look at the creation of a WiiWare title with Medaverse Studios.
EDITOR'S NOTE: This chapter is going to be a tad different from the others. Instead of continuing with how Medaverse Studios became an official development house for Nintendo, this section focuses on the mistakes made during the development of Gravitronix in the candid opinion of the game's lead designer. As any game developer can tell you, the only way to grow as a creator is to make your mistakes and learn from them.
By: Jesse Lowther, Medaverse Studios CEO and Lead Designer
I'm going to take a break from my current story to address some of the current issues we're assessing right now at Medaverse, mainly the list of mistakes we made during development and how we can avoid them for our next one...
If I could go back in time, I'd slap the stupid out of the former me for a number of different reasons. For starters, I'd reverse what I feel is the biggest mistake we made during the development of Gravitronix: trying to keep the game as small as possible. To this end, we ignored the premade toolset we had available and made our own. This literally took another year of development time, just building our own engine and burning out our lead programmer. Had we not done that, not only would Grav have been out a year ago but the game would've looked much nicer to boot.
At the time we made the decision, you literally could not find a thread on the internet about WiiWare that wasn't full of complaints about the lack of space on the Wii. Thus, we had good intentions for keeping the game small, but once the SD card update hit, all of our hard work was literally invalidated. Storage space became a complete non-issue. Have you heard anyone praise Gravitronix for being only 122 blocks? Yeah, me neither.
The Wii's SD Card storage solution rendered a lot of hard work meaningless
But the biggest kicker is that, to stay as small as possible, we actually gimped our graphics. Let me repeat: we intentionally used lower resolution graphics to avoid bloating the file size. We didn't use shaded versions of the characters (which look much nicer), we used lower resolution textures and we spent a great deal of time on programming tricks to save graphical space.
"What the hell were we thinking?" I've asked myself that question daily ever since Grav's launch. Someone must've swapped my vitamins for stupid pills back then because any idiot could tell you that graphics are far more important to a game's financial success than gameplay. Yeah, that's right: If any would-be game developers would like to know, graphics most DEFINITELY mean more to a game's overall success than gameplay, something I knew at the back of my mind and yet didn't act upon in the interest of saving disk space. We spent most of our programming time honing Gravitronix's gameplay, but the proof is in the pudding and no one is going to buy pudding that they don't find visually appealing.
The most-criticized element of Gravitronix has been its visual presentation
The other huge mistake we made was developing a game that cannot be understood by a single screenshot, and really, it can't. Our playtesters all had fun with the game, but we probably should've shown them a trailer first and asked them if anyone understood what they had just seen. My guess is that it would've been a resounding "no". Ironically, it was our desire to create something other than the mountain of puzzle games that WiiWare has seen that was the most damning for us. That, and our love for multiplayer games like SSB.
My advice for any game-designer hopefuls is to start with a single player puzzle game and work your way up from there. Yes, it's boring and unoriginal. Yes, it might not be the game you want to make, but in the grand scheme of things, you'll probably turn a profit from it which means you can go on to make the games you want to make. Patience is a virtue and this is never more true than in game development. Hell, we thought Gravitronix was going to be a good starting game and relatively easy to develop and it took two years. You can never start too small. If you want to start with a text-based adventure game, so be it.
Groovin' Blocks is a good example of what Jesse suggest game developers start with
One other mistake we made was taking full advantage of the Wii's hardware. Again, at the time, it seemed like a good idea, one that might even endear us to WIi fans because we made good use of the hardware where many companies make a mockery of it. The end result is a game that cannot be ported to any other platform. Developing as platform-independent as possible is a much safer bet.
Lastly, the best advice I can give is to not delude yourself as a game developer. Even though our playtester's reactions were all fantastic, it was meaningless. I know that from experience now. We're still left scratching our heads over how a game that playtesters literally leapt our of their chairs in excitement while playing could go on to not even create a ripple. It would've actually been better for us had the playtesters hated the game and we shipped it believing it was terrible. Either way, having zero expectations is the only way to proceed.
World of Goo took advantage of being multiplatform, releasing on Wii and PC
Some might say that all of these mistakes were necessary, but I don't think I'm ever going to be able to look back without hating myself for the mistake of believing that we should keep the game as small as possible, even at the cost of graphical quality. I don't know if this advice will be helpful to those interested in development, but if you can avoid making the same mistakes we did, you'll be that much better for it.
Today's Lesson: Mistakes WILL happen. No matter what you decide to pursue in life, mistakes are going to be made. The best solution is to try to avoid them when you can, and learn from them so you can make smarter choices - or in this case, a better game - in the future.