For years, I’ve been an advocate of the following Plan for New Indies:

I’ve learned, though, that people don’t want to do it that way. So, bowing to the realities of aspiring indie game developers, I now present the following New Plan for New Indies:

What could be easier?

-David

The latest article by Jeff Vogel, Throwing Myself On the Innovation Grenade, discusses the dangers inherent in “innovation”. Based on his experience creating what he considered an innovative game, and watching it fail (in comparison to his other games), he argues for sticking with what you know works.

What he is saying, I think, boils down to this: If you have a game (or whatever) that sells to a particular audience, and you create a new game (or whatever) that doesn’t appeal to that audience, they won’t buy it.

This is a valid point, and a dilemma that all businesses face as they consider allocating resources to upgrading/improving what they have now (that sells) or to what they might create (that might not sell).

The problem, though, isn’t innovation. It’s not the new game, or the new product. Nor is the problem in the seemingly missing market that failed to show up on cue.

The problem is that we want easily repeatable success. We want certainty. We want to know that the effort we’re expending will be repaid, with a nice profit margin.

Clayton M. Christensen wrote an entire book on this topic back in 1997: The Innovator’s Dilemma: When New Technologies Cause Great Firms to Fail.

To sum up the book: When you’re doing something that makes money, it never looks like a good idea to do anything else. You have a lot invested in what you’re doing now, and it makes sense to invest in expanding that.

The heart of this dilemma is that no one likes starting over. And any time you create a new game (or whatever) you are starting over. You are leaving behind your existing market, and trying to create a new market.

In the game industry, publishers and developers strive to reduce this “starting over” by creating games that (they hope) will appeal to the same audience/market as their last successful game. And that’s why you get sequels into the double digits and year after year of the same sports titles.

I’m hardly immune. That’s a large part of why I keep working on The Journal (it also helps that I like working on The Journal ). It’s exactly why we’re building a new Paintball Net instead of another title (I have had a few other ideas in the past decade).

So, yah, I know what Vogel’s talking about.

But if you never move past what you know works, you’re in what’s called a “rut”. And I’ve never heard that described as a good thing.

Sometimes you just have to face the uncertainty.

You might as well try to enjoy it.

-David

Some people use the Torque Game Engine to create games. Others seem more inclined to extend it a bit and sell it to other indies. How many add-ons and tack-ons do they have now? I can think of:

I could swear there were more. Hang on. Gonna go look. Oh, right:

Plus there is a long list of content packs with 3D models, sound effects, buildings, etc (including one or two by Spencer Boomhower, the artist I’m working with on Paintball Net) and even a growing collection of books.

I haven’t heard that anyone is getting rich from this re-tooling-indie-tools-and-selling-them-to-other-indies approach, but it does seem like a workable business model. I even like the business model. It is, after all, indies helping indies, and maybe even profiting a little. I wrote a book for much the same reason.

Still…it probably indicates something that there are nearly as many variations of Torque as there are games being sold on GG (and that’s counting games that weren’t built with Torque). And when you add in the content packs and books, the total dwarfs the number of games.

Indies, it seems, need those hard-nosed, deadline pushing producers that get such a bad rap in the retail arena. Otherwise, they’re more likely to tinker and twiddle and amuse themselves and their friends.

Producers and money, actually, for a full stick-and-carrot set. Someone to smack the indies around so that the indies get the work done, with a bit of a carrot to dangle in front of the indies to keep their attention.

Of course, then we’d not be indies so much any more.

In any case, my recent work at “tooning” Torque made me start thinking that maybe I could create my own variation: the Torque Toon Engine. It would have cel shading and outlining built in, of course, with lots of options for applying them. And because I think machinema is cool, I would also want to include improved camera control and other goodies to support creating 3D cartoons. Et cetera.

But I doubt I’ll do that. At least, not anytime soon.

For a very simple reason: To get the Torque Toon Engine ready would almost certainly mean that the game I’m supposed to be working would be left unfinished. Can’t have that.

For Paintball Net, I don’t need all the features I would have to build to make the Toon Engine a viable product. I need many of the same features, yes, but not all of them. And for Paintball Net, I don’t have to document them for use by third parties.

In the same vein, since I only have to support what the game needs, I can be specialized and specific. Conversely, as a product to be sold to other people, I would have to support the more general cases, which are always more work.

Getting a product ready for market is always such a lot of work.

And if I’m going to be working like a dog, anyway–and I have no doubt I will, either way–when I get finished, I want a game. Besides being able to sell that to (potentially) more people, it just seems more fun.

-David

I hear all these wonderful stories about how source control has changed peoples lives. I see the bullet point list of benefits touted by the developers and lauded by the populace of programmers.

I want the benefits, and I would really love to sing the praises of source control.

But, to date, I’ve never once received a single benefit from a source control system. Be it SourceSafe, SVN, or–Annie, get your gun we’ve got a hideous beast to kill–CVS.

In fact, to date, going back over ten years, I’ve lost more time to setting up, wrestling with, cursing, redesigning, trying to fix, trying to figure out the “boggle” on supposedly simple merges, ad nauseam infinitum, than I’ve ever saved. In some cases, it would’ve been faster to type the source code in from an out of date printout than it was to “recover” it from these bastard children of databases and text editors that claim they’re only here to help me.

Today, facing the prospect of losing yet another productive day to the cesspool of source control, I realized that maybe the problem isn’t the software. Maybe it’s me. Maybe I’m just not “geek enough”.

After all, the problem couldn’t possibly be lousy installation software, ridiculous assumptions, or back room coders with little-to-no ability to effectively communicate shirking the task of explaining how to use their creation.

I must be the only one who has lost week after week to this crap, because if it was happening to everyone else, there would be real progress on this front.

It must be me.

So…do I have to turn in my Geek badge?

-David

Back in college I took Psychology 101. It proved an entertaining, low impact elective course, and a couple of facts I picked up that semester have stayed with me, even after 15+ years.

One of those facts is: Some laboratory rats only figure out which lever to press to get the food pellet after performing some unrelated activity. For example, in their initial exploration of the cage and playing with the levers (one goes bzzt! the other gives food), they might spin in a circle then hit the food lever. Woot! Food! Which was the point of the exercise, of course. However, the rats wouldn’t always separate those two actions: the spin, and the lever press. So from that time forward, whenever the rats wanted food, they would spin in a circle and hit the lever. Every time: spin first, lever second. And this is the definition of “superstitious behavior”.

In the programming arena, I call it “voodoo programming”.

I’ve been thinking about it a lot lately, as I’ve been engaging in it.

3D graphics programming is a region of much voodoo. 3D graphics are based on math that is both arcane and often counterintuitive. Though most Computer Science majors accumulate heaps and piles of mathematics textbooks, ranging from discrete math to various levels of calculus and maybe even some mathematical modeling and numerical theory, that doesn’t mean we wanted to buy those books or take those courses.

John Carmack and Doom made it “cool” (in a geeky sort of way) to be able to use mathematical terms like “cross product”, “Euler angles”, and “quaternions” in casual conversation. But that didn’t mean more people understood those concepts. It just meant that more people could correctly pronounce the words and call the appropriate vector class member functions while sneering at the “great unwashed”.

People want to make 3D games. More people, in fact, than will ever be able to build a 3D game engine. But, as I’ve said before:

Being a “3D mechanic”, though, is not easy. Sure, you can pop the hood and poke and prod at things and maybe change the output a bit, but to really make any meaningful extensions or additions, you have to know. You may not need to know everything, but you have to know the details of why what you’re poking and prodding goes “whir” sometimes and “chug” others.

If you don’t know, then you’re engaging in superstitious behavior and, hence, voodoo programming.

Voodoo programming isn’t a bad thing, necessarily. It’s often the best place to begin. It’s the epitome of “learning by example”:

Hopefully, by the time you get to the desired result you’ve eliminated most or all of the “voodoo”. You know why each line of code is necessary and understand how it contributes to the end result.

Hopefully, I said. Because the temptation is to cheer, “Woot! It’s working!” and then move on. This kind of voodoo patchwork accumulates and begins to take its toll. Plus it just looks ugly. Like a car made out of junkyard pieces assembled from the carcass of many different makes and models. It’s functional, sure, but damn…

The most important part of voodoo programming, I think, is realizing when you’re doing it. Knowing when you’re just grabbing something that works in one context and using it in another context without taking the new context nor the original code into full account.

Maybe you need to do that double backflip with a half-gainer before the snack machine will give you your Cheetos. Or maybe not. If it’s all voodoo, you can never be sure.

-David

PS My particular bit of “voodoo programming” this week involved hacking Torque’s shape shadow code so that I could make decals “wrap” across in-game geometry, like buildings and trees. Most of the voodoo has been eliminated, I think, though there a few more additions I want to make.