Zen :: Introduction

Greetings and welcome to the Zen Open Source Software documentation. My name is Tony Richards and I am the founder of IndieZen.org and one of the principal developers of ZOSS.

It all started back in March of 2007. I had just finished wrestling for several months with  Fractured Universe as part of a "Create an MMO Game in 90 Days" contest hosted by Dream Games, Inc.

The game came in first place, but it obviously wasn't finished. Who could ever finish any MMO in 90 days?

We had created a decent amount of content, but we only populated three fairly small zones. When I said "wrestling," I meant it. During whole contest I was wrestling with code, forcing it to do what I wanted. I ripped code out, threw in more code, completely replaced all of the scripts that came with Torque (then engine I had chosen for the game) and wrote all of my own middleware for the "MMO" portions.

I used the DGI MMO Kit as a reference, but for the most part I didn't use much of their code. It was nice to have some references for the "bags" and "inventory" GUI's, and the character creation GUI, etc, but mostly I just looked to see how they did it, then did it my own way. Sometimes I copied stuff a bit, but mostly I just wrote my own code.

After the contest I went to IMGDC. One of the round tables at that conference was titled "Slaughtering Sacred Cows" which was quite an eye opener. I had never heard of such a term. Now, I knew what it was all about immediately, and it was an interesting approach. Basically, the gist of it was that we can copy other games while making our own, but each element that we put in our game should be put there because we want it there, not simply because the element exists in every other game.

That evening, being less of a game designer and more of a software developer, I was mulling over the concept, wondering what other Sacred Cows needed to be slaughtered.

My answer... Indie Game Development Middleware and Tools

I had always taken for granted that Torque and a set of inexpensive tools such as Blender, Quark, Torque Constructor, etc. were my only options when it came to game development.

I had always assumed (pretty much correctly) that Torque, Blender, Gimp and 3D World Studio were my best options for making a game, since I owned a license, had the source code for the first three, and knew enough about the products that I could do pretty much anything I wanted to do with them.

But, I had always wanted something better. For years (7 years!) I had assumed that the authors of these tools would eventually improve them and make them more powerful, flexible and easier to use.

Well, these tools did get better over time, but the improvements were minuscule compared to what I wanted.

For starters, Garage Games, the authors of Torque, always heard the complaints about how it was very difficult to make a game using their engine.

"Making games is difficult," was always the answer... or rather it was their excuse for not making Torque easier to use.

Sure, when you purchase Torque you get the source code, and anyone that can write a game from scratch can take that source code and make a game. If you're making a game that fits the mold in which Torque was created then quite likely you'll save some time, but if you're making a game that's well outside of that mold then you will end up fighting with Torque more than you end up being creative with it.

Blender has the same types of problems. The software itself is fairly extensible (if you are fluent in C, which I'm not), but the models you create with it aren't extensible. There's a new term... "extensible models". My ideal content pipeline is a pipeline in which I can make a bunch of "components" and put them together. Components don't necessarily mean pieces of a building (although that's a good start), and they definitely don't mean "arms" and "legs" of a character model. What I mean is a model that you can take and add animations, morph targets, multiple UV maps, etc, then take the model, choose a subset of the components and export something. An example is something like MakeHuman? or Daz where you can take a humanoid model, apply some modifiers, add some more components like hair, clothing, etc, then export it into a game.

The final assumption, which was yet another cow that needed to be slaughtered, was my assumption that I didn't have time to write these tools and it would take me significantly less time to use the existing tools rather than write my own. By default, that sounds like a fairly sound conclusion, it included two other assumptions... I had been assuming that I would be the only person writing the tools and I had been assuming that I would be the only person using the tools.

What if this wasn't the case? What if I could come up with some way to allow hundreds of people to collaborate on making a game engine and some game development tools? What if those hundreds of people could then turn around and make their own games with these tools and each of them save a significant amount of time?

By making a framework of frameworks made specifically for use in game engines and game development tools, I could solve the problem of extensibility. By making it open source and free, anyone can use it. The more people that use it, the more people will extend it, add more features and improve it. The better it gets and the more features it has, the more people will want to use it. And thus the snowball begins rolling down the hill, gathering momentum and more snow.

And that is how IndieZen was born, and the Indie 2.0 Revolution began.