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.