Not just for hippies anymore.

In the spirit of people getting together for the holidays, I figured I’d write about the notion of collective software sharing between indie game developers. Indies forming a co-op of sorts – something I’ve thought would be of great value to indies, so I’m kind of surprised we haven’t seen yet.

In the past couple years, the industry again has become a survivable place for small developers thanks to a variety of factors: digital distribution, broader markets, market niches unaddressed by major publishers, as well as a growing set of existing software tools/middleware.

For indies, those tools range from free to pretty damn cheap game engines, like Garage Game’s Torque engines. But those are never one size fits all solutions (even GG has broken their original engine into several versions). You may need to make a lot of the game yourself for any number of reasons – the more you’re doing that’s different, the more likely this will be. Now, some engines are flexible enough that you can tear up a round hole so a square peg fits, but there may be some bleeding involved.

There’s also a number of solid mod-able games with tools, which are often the best choice for students (since they tend to have the most polished toolsets and least steep learning curves). But as a small developer, you’re going to have slightly different concerns. One, you probably want your games to diverge more from just being a mod (getting bought/hired by the company that made the game you’re modding is a strategy, but not one to sustain a business). The scope of most indie games tends to be smaller than what these engines allow - while using a sledgehammer to sculpt stone might afford certain… existential pleasures, it may not achieve the desired results.

The basic idea is that everyone joining the co-op has to put in a source module, anything separatable/re-usable. To remain a member, you have to do this periodically. Everybody in the co-op gets access to the modules everybody else has contributed. Examples could include stuff like a particle system & editor, third person camera control code, or an automated pathfinding graph generation tool. The sort of shit that, once you have enough experience, you realize there’s a very small number of ways to make the best version of such a system. And once you write it, debug, build a game with it, you often don’t have to futz with it much, and you can plug it into another game that needs that type of module without issue.

Focusing on reusing smaller modules gives indie developers the flexibility & speed they need to thrive. If you’ve got a substantial portion of your game done, but think adding some kickass particle effects would just take it to the next level of polish, do you want to jump headfirst into the learning curve for an existing engine? Your time is too valuable to port your game over, if that’s even a possibility. But why, whywhywhywhy* would you, in the year 2007 (almost 2008!) need to write one yourself (since it wasn’t a crucial feature to your game)?

Now if you could rely on a small, trusted, group of people who were tackling related, but different problems in game development? Plug in a particle system. Ask a few questions from the person who built it, who’s a trusted source of information. And add the polish you want. Learning how to integrate a particle system is faster than learning an entire engine framework. And you’ve kept the flexibility to extend the rest of your game however you like.

To some extent this no doubt already happens on the smallest scale – sharing between friends and connected small developers who are each trying to work on their own games. But having a recognizable resource for this kind of thing would help network developers spread out geographically.

On a large scale, a place like Garage Games might attempt to encourage such sharing between users of it’s tools. But the community seems too large to really have a high signal to noise (caveat, it’s been a while since I checked up on it – I’d be curious if anybody reading has insight otherwise). I imagine the sweet spot for a collective like this would be 10-20 developers, depending on how much one developer would contribute.

So why not just go full-on open source? Well, for starters, you don’t actually want or need random schmoes improving your software. The whole reason you wrote it was because you thought you could write it better than anybody else! If that’s not the case… what the hell are you doing? Unless you’re writing it because it simply does not exist as a tool or piece of middleware you can get access too (in which case, you still probably have to make it better than anybody else could).

Having people occasionally, unreliably with respect to time, improve upon your code has little value to you. What’s the most value, is trading this module you’ve developed for another one. It’s also of limited value to you, if you’re trying to feed yourself this way, to give away your source – if you plan on making money directly selling the game. 

Would people sign up to give away their code? You’re giving it to a small group of people, who are only admitted if the group deems them trustworthy and they have something to give back. You immediately get something tangible back. With enough of a range of developers, you’d be guaranteed to at least find a module that was worth looking at for comparision, if not just directly using one in your game. And if another game by someone else uses a module of yours, it’s pretty unlikely that the games would compete in some fashion just because of that.

Yeah, in certain cases you might want to give the source out to the community at large, but the community at large is also not going to reap as much value from these targeted software modules as a group of indie developers. The fact of the matter is that it’s still pretty hard to survive as an indie – sharing with trusted developers gives all of you a clear advantage, sharing via open source much less so. Sticking together is just one way of doing what larger companies can’t in order to survive & succeed. Helping the community at large is good, but it starts with helping yourselves.  

There are some open source solutions in the contained, reusable module vibe, like the Open Dynamics Engine or the minimalist C-like scripting language Pawn. Those are relatively easy to grok and plug into something bigger should you need a solution for those problems. But those types of solutions, whether open source or cash money versions, are still few and far between. Outside of indie game developer’s hard drives, that is.

What are the costs of such an endeavor? A mailing list, a website, and a protected source control server. The maintainer of those probably gets some allowances on the requirements for continued membership (since those would take a small amount of work to maintain). There’s some work to define standards for the modules. You’d want them to be separated from the game they were built in via a simple test app, for instance, and some measurement for the complexity of the problem the module solves (if it was hard to make, there should be some allowance for how long it sustains your membership). All in all, not a whole lot of work.

I know, hard to believe, but there actually may be a slider between the Web 2.0 world where everybody creates and shares everything constantly, and it’s great, and the world where every single developer has to slave away to create every single feature of each game from scratch every time. The slider doesn’t always work best when set at extreme ends of the spectrum. 

– 

* As an aside, why is good software architecture seemingly so much harder/rarer than good programming? It may just be that it’s not a skillset taught in a regular C.S. undergrad curriculum, and so if you learn it on the job it’s perhaps only by random chance. There’s also not a whole lot of good books on the topic – I’d recommend Large Scale C++ Software Design. It’s not just for large bureacratic programming projects, I swear. Although those do make up most of the examples.