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.
There are different things that are easily reuseable. Something like a particle system has huge dependencies: does it render to D3D? OpenGL? What about 2D games? Or does it not render and let you do the rendering? How does it evolve over time: is it a game simulation object?
Those sorts of questions are easy to answer if you’re all working with a common framework, but without that framework I think you’re a lot more limited in what modules you can release, and it requires a lot more skill to realize how to design it to be reusable.
Generally the easiest middleware to farm out is what we call “leaf” technologies, that have no feedback into the game (a particle system _is_ a good example of this). I think these are largely succesful because that constraint makes the modularity much stronger, so makes sharing and integration much easier. For example, all of RAD software’s middleware projects are output-only: bink and smacker video, miles audio, even the granny animation system.
But there are only so many leaf technologies; physics is clearly _not_ one, for example.
Anyway, I’ve been posting my leaf technologies to the Molly Rocket forum: http://mollyrocket.com/forums/index.php which has become something of an informal collective (although of course the code posted can be used by anyone). On one level my code is entirely redundant (many things I write already have existing LGPL libraries), but at least for some people it’s just what’s needed (a better interface, a license that doesn’t force DLLs, and no dependencies on other software). I’m not sure this generalizes, though, since the population there tends to be pretty hardcore programmers. (Then again, anyone can use this code, if they find out about it.)
After I put out a tiny experimental platform a couple weeks ago, I downloaded PopCap’s open source framework for doing games to see if maybe I could switch to that for future tiny platform games, since it’s obviously so well-tested, but it’s a mass of software engineering that doesn’t mesh with how I like to do things. Modular, non-dependent, non-frameworky code is just so much better when you can find it, but most of the shared code I know about tend to be framework-y, and when you dig into it (like the popcap stuff) it’s not internally architected well enough to break things out of that, unfortunately.
er, a tiny experimental _platformer_, not platform.
That’s really cool about posting your stuff on MollyRocket, that definitely gets to the sort of thing I was talking about.
Point taken about lower level rendering API limitations for stuff like a particle system – but that output is only one portion of such a system, too. You should be able to rip out the renderer, replace it with whatever API you happen to be using, and still use the same editor (or just not implement the rendering & expose the resulting billboard data). I’d also imagine a 2D system would be a different module than a 3D one, although I could see them being combined if really well designed.
Physics tech isn’t exactly a leaf technology in that sense, but the API needs for collision & basic rigid body physics are fairly well understood at this point. Correspondingly, I’d say Havok is arguably one of the more successful middleware vendors. Obviously if you want to tightly integrate physics & gameplay in non-standard ways, you’ll need to do it yourself, but that’s true of most anything when it comes to the non-standard part.
Anything that doesn’t require feedback definitely is a better target for sharing. But as long as the feedback paths are well understood, isolating the communication has a similar effect. For instance, I’ve seen pathfinding API’s that require that the module runs all agents, putting restrictions on the behavior framework, just to make agents follow a path. If the module just feeds back the sequence data for the resulting path, none of those constraints are forced upon you. The module ends up doing less, too, though (not always a bad thing).
But, yeah, finding that sort of thinking is rare, although it still boggles my mind as to why – since these sort of architectural decisions don’t often actually take more *time* to implement, if you set out with this sort of goal to begin with.
“Correspondingly, I’d say Havok is arguably one of the more successful middleware vendors.”
I’m not sure of anyone who’s integrated Havok who didn’t have to do a _ton_ of work to get it going (and often involved a deep understanding of how to _implement_ physics, which seems contrary to the premise of “modular”).
Obviously it works great if it gets integrated into the Unreal engine or such, since that’s essentially the framework sort of case.
Here’s Havok’s list of titles: http://www.havok.com/content/blogcategory/29/73/
I’m not sure between this and the horror stories I am convinced it’s a huge success. Maybe things have improved since the horror stories, some of which were early on and were clearly because the Havok people hadn’t actually ever written any games and hadn’t considered some of the important issues from that perspective (like an object hitting another object and the game wanting deciding to destroy the latter object and let the former object continue on its original trajectory; this isn’t non-standard, this is ‘throw a brick through a window’). It’s possible that they’ve had enough licensees and taken the feedback seriously that things have improved now, compared to back when I was really paying attention to it (when I think you _couldn’t_ say the API needs were well-understood). But the whole point is that physics + gameplay _do_ need to be tightly integrated most of the time; otherwise, it’s just a rag-doll/explosions special effect, which is fine, but that’s basically the output-only case.
Yeah, heaven help those who have to integrate middleware made by non game makers into a game. :)
Havok itself has gotten better (well, I worked with it about a year ago). Out of the box all the pieces you’d expect to be there, are there, anyway. Even if the interfaces are sometimes obtuse, it’s not “OMG WTF am I supposed to do with this?”, which has been my reaction to working with other physics packages (much like the brick/window example). Most of our problems were standard rigid body physics/ragdoll problems (ie. make sure the character isn’t embedded in the world before starting ragdoll, etc.). But yeah, we were basically using it as a leaf technology, for visual effect/realism.