Monday Jun 13 10:15

Mattias Gustavsson — 2005-06-13T10:15:37+00:00

Life and game development

I guess you know how it is. You're doing fine, the game progress at a steady pace, you start thinking "Yeah, at this rate, it'll soon be done!". Then something happens. Usually, it is referred to as "life gets in the way". Things happen, unforeseen things, things beyond your control. This changes things, you might find that you no longer have as much free time on your hands, you can't maintain the necessary focus, or any number of things that mess up your flow.

About two months ago, me and Tanja moved from Scotland to Vienna. The new job was a good one, much simpler tasks than the previous one, more days off, a limit to the overtime, and we had a flat 5 minutes from work. This was great for productivity, and we've gotten loads done while living here. No more getting up at 5 to make sure I got an hour or two done on our own stuff before being off to the day job. Things were great.

But a few weeks ago, the company got into some trouble. Basically, they had a bit of financial problems, due to circumstances mostly beyond their control. This meant that our own financial situation became too unstable for us to stay, and now we're moving back to the UK. I agreed with the company to stay for two weeks, to finish my current milestone, and then I'm off. Those two weeks are almost at an end now.

This have upset things a lot, and the whole uncertainty of it all (Where will we end up living? What new job will I get? Will the money we have left be enough to cover all expenses, like travelling for interviews, up-front rent and deposit for a new flat etc) have made things difficult, to say the least.

The short of it all, is that progress on the game have been really slow for the last few weeks. It's not like nothing have been done, but it's been so unfocused, just a little bit here, a little bit there... Hard to judge how much actual progress been made. Maybe a little, maybe none... The only real tangible thing is an algorithm for generating fractal ground-tiles from a tile-based height map, but that's just two days work at most.

I keep telling myself that once the move is done with, it will all fall into place again, progress will once again be good and there'll be no problems. But that's only until next time isn't it? Next time life hits you with something unexpected. Next time things get out of hand... I'm thinking that the trick is to keep your focus even through the rough patches, but I'll be damned if I know how? I'd be really interested in hearing other peoples thoughts on this topic, so feel free to comment on this plan or e-mail me privately.

And for those who are interested: I have a new job already, actually for a company I've worked for in the past. They're happy to get me back, and I'm happy to go back there. We'll be back in UK on friday, and from then on, work on Shepherds Inn will hopefully get right back on track.

Friday May 27 9:18

Mattias Gustavsson — 2005-05-27T09:18:38+00:00

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.

Tuesday May 3 11:33

Mattias Gustavsson — 2005-05-03T11:33:24+00:00

Me and my wife, Tanja, are working on a game together. Actually, it is more than a game, it is also a website and a whole Fantasy world of our own.

The name of the game is Shepherds Inn, and if I may say so myself, it's going to rock :-) This will be the RPG that we always wanted to play, set in the type of fantasy world that we like the most. The name of this world is Rivtind.

It will be different from the RPGs and worlds that are popular nowadays. We won't go for the dark & moody or

Blog for Mattias Gustavsson at GarageGames.com

Monday Jun 13 10:15

Friday May 27 9:18

Tuesday May 3 11:33