Plan for Mattias Gustavsson

How important are tools and editors when developing a game? How important is the "art pipeline" (the way graphic is brought from whereever it is made and all the way into the game in the correct, runtime format).

I think it is easy to both overestimate as well as underestimate the importance of tools and editors. It's common to go all out on tools, setting out to create the ultimate editor before even starting the game. Often also trying to make the editor good enough for future games as well as the current one, in order to "save time & effort" in the long run. The tools project becomes such a big thing that it sort of becomes the end in itself, rather than just the means. This is understandable, since we humans tend to lose focus on whatever is not right in front of us at the time, but it usually leads to never getting to the game, because no matter how long you work on them, the tools are never fully "done".

It's equally common to go the "Tools? We don't need no stinking tools!" route, and just focus on the game itself, hardcoding everything, jumping through all the hoops everytime new art or levels need to be put into the game. Now, this obviously will let you get to work on the game sooner, and get the first level together in almost no time at all. But what happens in the long run? You find yourself wasting more and more time on just getting stuff in there. It is awkward to get the art from the art package into the game, and once it is there, it's equally hard to make use of it. I made a platform game like this once, and even though it was released, it ended up only having two levels, because the process of making a level was so time consuming (it consisted of typing lots of numbers into a badly organized text file).

I'm as guilty as anyone of making these mistakes. And I think the reason that we keep making mistakes like this is that we don't understand why or how tools are important, from the lone or small developers point of view.

The first thing to realize is that tools have to be good enough. No less and no more. Their only purpose is to shorten the development time and reduce the development effort. This is the focus we need when making tools. How to make them good enough, but not MORE than good enough.

Right now, with Shepherds Inn, we're working on the art pipeline and two editors: the object editor and the world editor. The art pipeline consists of getting the mosters, animals, trees, chests etc etc from 3D models in Poser, to RLE compressed rendered animations from 8 directions inside the game. The object editor is then used to define properties for those rendered objects, like what scripts are to be associated with them, where their origins are, and which parts of them are collidable and not. Finally, the world editor lets us place instances of these objects in the world, change their angles, and paint terrain tiles on the ground.

Being an RPG, there will be a lot of content. I guess that goes without saying, really, but let's consider this for a moment. An RPG need lots of content. I couldn't imagine an RPG without a world to explore, and to have a world, you need stuff to fill it with. This means lots of assets. Every prop, plant, character and animal will have their separate assets. In our case, being a 2D isometric game, every frame of every animation needs to be rendered as a separate image. Also, for each frame of each animation, we need the object from 8 different directions (nice but not strictly necessary for static objects, but essential for moving entities). That's a lot of image files to keep track of. Imagine rendering each frame manually, saving it out with the correct name, changing the camera angle (and the lighting to compensate) for all 8 direction, then bringing all the files into the object editor(or even worse, typing their names into a textfile) , specifying that they are to be part of this animation for that object.

It works, no doubt about that. For a larger team, whith several artists that spends days modelling and animating an object, it might not be so bad for them to spend the few minutes it takes to render, save and set up the animation. Annoying, sure, but not impossibly so.

But for a team like us, where we are only two people? I'd say it would be almost unworkable. We buy most of our models, and simply set them up and tweak them to fit our world, but this takes only a few minutes for most objects, at least the less important ones. The majority of Tanjas time would then be spent waiting for renders to complete, typing filenames into dialog boxes and rotating cameras. Surely this would be way better spent adding more stuff to the world, or more quests to the game?

Thanks to the scripting interface of Poser (using Python scripts) there seemed to be a way to automate parts of this process. It took a few tries, but what we have now is a system where Tanja saves all the things we want to have in the game as Poser documents (pz3). She saves them in a folder that have the same structure (with subfolders and such) as the games asset folder. The names of these Poser files follow a special naming convention, allowing us to specify as part of the filename what sort of object it is, the name of the object and which animation of that object this file contains. Then we run our custom render script, and it will load up the files in Poser, set up camera, lights and render properties, for each direction of each frame, render it and save the resulting image in the correct place in the games asset folder. At the moment, all files that are to be rendered have to be listed in this custom script files, but I'm going to write a little tool that can look through the Poser files folder and the games asset folder to figure out which files are new and needs to be included in the render batch.

On startup, the game editor will scan through the asset folder, and if it finds new image files there, it will automatically import them and convert them to the in-game format, using the different fields of the filename, as specified by the naming convention, to make sure it ends up as part of the intended object. It is then ready to be placed in the world editor.

So, to sum it up, the only thing we have to do manually (once that last tool is completed) is to set up the object the way we want it to look, save the file in the correct place. At the end of the day, we run the tool that generates the list of things to render, execute the script, and the next morning we have a fresh bunch of objects that have been rendered over night.

This might seem like the obvious solution in hindsight, but I think it shows me how far I've come since earlier attempts to do similar types of game. Back then, I either wouldn't have recognized the importance of a solid pipeline, and ended up with a game that it was too laborious to produce content for, or I would have commited so much to the editors that the project would have changed into a game-maker project instead of what I really want to make; an actual game!

As a last note, I'd like to point out that you shouldn't start with the tools to early or too late. First, you need to have some sort of prototype running, as during the process of making it, you will learn essential things about how your game will work, things you need to consider when making the tools. But don't leave it until the game is "done", because by then it might be so hard to write a tool for it that you just won't bother. After the first simple prototype, the tools and the game need to develop side by side, so you take both into consideration at all times.