We store cookies, you can get more info from our privacy policy.

Medaverse Developer Diary: A Simple Challenge

The Development

by Jesse Lowther - November 13, 2009, 9:46 am EST


The Development

By Jesse Lowther, Medaverse Studios CEO and Lead Designer

I spent the night of the Wii launch inside a Wal-Mart, lined up with the other customers waiting for midnight. I spent the time chatting with other Nintendo fans and a few cougars who were there to buy the system for their families. It was a good night, the same night my programmer friend came home so drunk that he passed out in the bathroom and I had to carry him to his bed. I stayed up until 6 AM playing Red Steel with a friend. The next morning, we all tried Wii Sports for the first time and we were immediately made to understand just what motion control could do for a game. At the time, we were already talking to Nintendo about acquiring licensed developer status and had been since August of 2006. Like Ubisoft, we got in early, back when most developers doubted the Wii and its selling power. We got in early and we couldn't wait to develop for the system.

We moved forward with our plans for development having absolutely no clue what we were doing, but that wasn't about to slow us down. We whittled down the list of game ideas until we had one that not only would be within the scope of something we could build but also a game that made use of the Wii's unique control scheme to enhance the gameplay (a decision that proved unwise in the long run).

We began development with one piece of development hardware, a burnt-out lead programmer, an artist who knew nothing of being a video game artist and me, a starry-eyed dreamer who always wanted to develop games. Right off the bat, we decided we needed more help and went looking for another programmer. We found a bright-eyed college kid in his senior year who shared our passion for wanting to develop games. Though he was only supposed to be an assistant programmer, he wound up becoming the lead over the year of development time it took us to create the engine that we believed would be ideal for keeping the game as small as possible, a process that burned him out as well.

Our development process was tragically organic: although we had a design document to adhere to, it was being changed on a regular basis as I kept coming up with new ideas or changing existing ideas (much to the frustration of our lead programmer). We had never prototyped the game, which meant that we were always working toward what we thought the game would be like without ever actually knowing if we'd arrive there. During this time, I learned that it's completely possible to overdevelop a game concept. You can literally give yourself a headache thinking about how to change the game to make it better, as I often did late at night. Without a prototype to test the game for fun factor, we didn't know what it would actually be like in the end, and that meant I could spend hours of imagining things differently, churning over many ideas and wondering if previous changes were valid or not.

I don't recommend doing it this way. As a game develops, there should naturally be extra ideas and concepts that go into it, but the basic gameplay should be tested long before even the art assets start being created. Starting without that is gambling on the outcome to the point where it's irresponsible.

No matter how simple the concept is, it's best to test it first

We also lacked an art pipeline. We're just now figuring out (thanks to Jeff) just what it is a game artist should be doing: acting like a fountain overflowing with concept art. When you come right down to it, it's the job of the artists to drive the whole creative process forward, even early in the process. Without an idea of what the final product might look like (even if no concept has been nailed down), you need to have SOMETHING you can look at and imagine what the world around it will look like. 99.9% of all concept art will probably never be used, but it still has to exist because that 0.1% results in characters and concepts that very well could make or break your company.

The development process was as challenging as Gravitronix itself

The biggest challenge we faced came from disputes among the staff There were a few points where bitterness arose about some of the team not doing their fair share of the workload and others having to pick up the slack. There was talk by some of leaving over the frustration, but in the end we managed to resolve these issues and keep moving forward.

Despite my many roles on the project (lead designer, sound effects, text, etc.), I managed to never burn out, though I didn't spend hours a day with my brain wrapped in code so I can't say I was in the same boat as the programmers. Many times, we felt as though the finish line was in sight, only to find out that we had a great deal further to go. The interface in particular was the most painful for our lead programmer, and had we not found a second artist to help out, it would've been all that much worse.

As we neared the end of our development cycle and testing began, things seemed more encouraging: playtesters were enjoying the game and we realized for the first time that we actually had a game on our hands. I'll never forget the first time I ever twisted a Wii remote and watched paddles moving on screen, or the first 8 player game of Gravitronix that was ever played. Moments like that in the development process were what made it worth it. Oddly enough, I miss working on Gravitronix. There was an inherently good feeling that came from developing a game, maybe tied to the feeling of being enriched through what was for all of us a learning experience. Either way, work on the next game can't start soon enough.

Next week, I'll touch upon the final advice I have to offer on game development.

Today's Lesson: Game development is one filled with many learning experiences. Don't be afraid to ask for help when you need it. Work first on your game's concept and see if it has merit before moving on with graphics, gameplay modes and other assets of development. Finally, as with any group effort, disputes and disagreements will happen. But it's important to put them aside for the sake of the product.

Got a news tip? Send it in!
Advertisement
Advertisement