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:

• 2D projects generally have an extremely simple art tool chain. In most cases, Photoshop is the tool chain.
• Very little graphics support code is required. There's no bones or skinning or NURBS. Just pixels.
• Since modern consoles are able to render millions of textured triangles per second, we never had to worry about performance, even with lots of objects and particles.
• Collision and physics are simplified. Bounding boxes are often good enough.
• Game mechanics tend to be easier to refine.
• Although we didn't use any extra artists for MadStone, it's much easier to train artistic talent for 2D production than for 3D. There's much less technical overhead and new team members can get started very quickly.

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:

• The Java runtime ranges from about 7 to 30 MB, a number that increases with each version of Java. WiiWare games are limited to 16 or 40 MB, depending on the business model the developer chooses. We'd have to spend too much of our download budget squeezing in the Java Virtual Machine.
• As far as I know, the Java runtime isn't available for Wii. We'd have to port it or write one from scratch.
• Java is very fast these days, but JNI doesn't keep up. We wanted to avoid the overhead of function calls crossing the Java / C++ barrier.

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:

• Slag's runtime is just a few hundred kilobytes and is easy to port.
• The language was designed and implemented by a game developer for game developers
• Slag code can be cross-compiled to C++, significantly improving performance.

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.