For sure. Modular studios is an especially interesting future business model, not too unlike Hollywood. It's going to require cash to work though. Brain module will have to direct the project and all sub modules, and funnel the cash down.

The idea is far too risky for "no money" indie studios though. Two modules deciding to work together *MUST* have the utmost confidence in each other before forming a collaborative relationship. Normally a single person can be a choke point for 1 company, but with 2 studios working together it would amplify the problem making it possible for 1 person to ruin 2 companies. Not bad if you're actually trying to kill 2 birds with 1 stone.

I completely agree. To take it even further it seems that having an organization which would facilitate and aid in the pairing of these strike teams. In fact I believe a couple of start ups have started this in Winnipeg but have yet to venture into the console world.

I think the way forward is - at the very least - going to lean towards more sharing, more outsourcing and contracting, more open-source, simply because it lowers risks for the small developer. Traditional studio approaches tend to cut off inter-studio sharing and build "silos of knowledge" out of a combination of legal risks, cost of communication and support, and desire for the competitive advantages of scale, but from the small developer standpoint there is no scale advantage forthcoming, and the downsides are pitted against the problem of "I need to do more faster and at lower costs to break even," which is going to trump anything else.

So it's preferable to break up into specialists that share - whether directly, as "strike teams" or collaborations, or indirectly through contributions to the commons. Regardless of whether your approach is to hand out code and assets, to sell and support a commercial product, or to contract your services, you'll get a "rising tide lifts all boats" effect, one which benefits all developers in the end.

I will admit that I don't think the "strike team" approach will scale well because of the extremely heavy communication of most game projects. Communication is already a major problem of the existing large studios, but they at least have the benefit of letting their staff cluster in one location. A error in communication that gets resolved by walking two desks over in the studio may become a lengthy phone or email back-and-forth - multiplied by however many people are involved in the project. It's more cost-efficient in the end to have one tiny, close-knit team with a lengthy schedule and a bare minimum of outsourcing to cover the biggest weaknesses, than to set in motion a complex paralleled process with dozens of independent teams working towards the "same" goal.

But if you're each making projects that are based on a common pool of knowledge, communication is no longer an issue. That pool will just gradually grow bigger and bigger, until one day, you alone are empowered with productivity that no large developer in the past could have dreamed of. We're already seeing that at the low end of the field today - there are lots of off-the-shelf engines, techniques for the common problems, etc.

I've personally been working on a tool for various 2D game tasks, specced with my current project in mind, but with lots of general-purpose features that would interest others. It will be released open-source, GPL, when I've got it ready for use. It's taken about a month of work. A sizable chunk of time, but my tiny cost of living lets me actually profit from unemployment benefits, so the usual incentives to ship a game fast are quite low... :) And I sincerely hope that it will help not just me but others, as well.

While we do have working ways of sharing code, we're doing very bad in the department of sharing content. While it's true that some of the content is game-specific, this is also true for code; and conversely, just as there are generic parts of the game code that can be shared between projects, there are generic art or audio assets that could be shared as well. It's totally pointless to work on modeling and texturing simple chairs in each and every game project separately, they'll end up being almost the same anyway. It would make sense to release all the generic content to the scene, and in return, get most of what you need for your next game from that common pool.

What we really need is something like sourceforge.com, but for content. There are some sites with a similar goal, sharing content packs, but none of them seem to have the same weight as sf in the code world.

I think one of the reasons behind this is the lack of at least quasi-standard ways of doing all this. We more or less know how to write reusable code libraries, but we don't really have established ways of sharing anything else.

Sure... Check my blog for the game concept, then give me my share when it's all said and done. If you need consultation you know where to reach me.