Post Mortem
of MetaBall
Introduction
It was the June of 2003 when I first heard about the Make Something Unreal Contest. I immediately asked Indy (Attila Malárik, the coder guy) whether he wants to participate. He liked the idea, so we started thinking about possible game ideas. On the next weekend, both of us wrote down our own ideas, and we discussed them on monday. On the list there was a railshooter, a real time strategy, bird simulator, action RPG, and we both described a kind of a puzzle/platformer game, with different balls in it, and extensive usage of physics...
What went good
- Base idea -
At first MetaBall was meant to be a warm up project, just to learn the way of Unreal engine. After that we would have made a more complex, more serious game. However, we got more and more ideas since the early days of the development, and the feature list started to grow.
The first conception looked like this: we have a ball, and the goal is to reach the end of the level in a given time, and also to collect all sun icons along the way. Naturally there are moving platforms, spiky enemies and bottomless pits as well.
Okay, but what if we create a few, simple puzzles? Hmm... that would be a nice touch, but they shouldn't appear on every levels, because some players prefer platformer style maps to puzzles.
Well, then one map will focus on the player's dexterity, the other on puzzles, and the player could choose which way to go. So the game won't be linear, and you can beat the game without finishing all the maps, although then many secrets stay hidden... and the evolution of the basic idea has begun.
During this evolution, we encountered a few dead ends, but eventually they had a positive effect on the project. One example is the case of the rubber ball, as a ball type: the wild bouncing around the room was fun for awhile, but we had to face the fact, that it is uncontrollable. (The effect was much more like the ball scene in the Men In Black movie.) So we dumped it, and we created the SonicBall and the Speed challenge game mode instead, which fit right in the existing design.
A guy suggested, that we should change the empty, impersonal ball to something with a soul. So the Diva character got into the ball - who was a substitute until Lena arrived - and on the HUB we started to walk around in a human form. Then we thought that it would be more fun, if we could change balls while playing on a levels.
I designed a fatty fairy, who would have changed the ball after collecting a given number of sun icons. The fairy didn't make it to the final release, but based on her, the Tinies appeared, along with the background story and the Evacuation game mode.
The bottom line is that the base idea was flexible and extendible enough, so we were able to create a varied, more or less round game.
- Team size -
The MetaBall Team consists of two "full time developers" : Indy and me, and two "contractors": Masa (Richard Masa, our animator, who also designed our heroine, Lena) and the Fish Music Studio, who made the soundtrack.
In a team of this size managing and distributing the work is quite simple, and to top it all, that time Indy, Masa and I worked together, so we were able to discuss problems and tasks on a daily basis.
Indy and I have quite different taste and attitude, and that sometimes resulted as fierce arguments. Fortunately we always found the golden middle path between the different points of views. When someone had an idea, the other started to find its weak points, tried to discover possible downsides, while the owner defended and revised the original thought, until the concept has been crystallized. Or gone to the recycle bin, because it can't be done or there is no time for it or it doesn't fit to the game.
Since I made most of the contents, I didn't have to explain my visions to others (fortunately Indy trusted me on this), I created assets in my own pace, the file structures, naming conventions were set up as I saw fit. It was also easy to gather the stuff for backup.
We got much help from the alpha and beta testers. When we couldn't decide certain stuff, we asked them, and they voted in a free, democratic way.
I think these factors helped the project on the long run, and the final game became enjoyable for a broader audience.
- Documentation and planning -
When we started MetaBall, we already knew that planning and a scrupulously managed documentation is crucial to every project. (We learned it in the hard way at our day job.)
The basic rule was that if something is not in the documentation, then it doesn't exist. Maybe we was talking about some cool feature (like implementing the daily cycle), but Indy ignored it until I wrote a specification into the documentation. When I did that, I went over it, and eventually I made things much clearer and tidier then the memories of a conversation.
There was a section called "What's new?" which functioned as a changelog, so by reading this everyone knew what are the new features and new tasks.
We also had an article describing each map. When making a new level, I start with a sketch, outlining the basic structure and the theme of the map. I made a kind of a walkthrough: where should the player go and what happens at certain places. 
I also noted any foreseen technical issues. I gave this blueprint to Indy, who gave me his opinion, some constructive critics and a few ideas.
Many things has changed in this early phase, and we saved so much time and effort this way: its easier to rearrange the map on paper than do it later in UnrealEd.
Of course sticking to the plans beyond reason is also not advised, since many unforeseen problem or idea could show up on the field. If you don't have the time to finish the whole map, you have to cut it. A smaller but finished level (...game) is better than a bigger but half-way made (so unplayable) one.
Its also a good idea to revise older maps, and refresh them with newer assets: add new textures, objects or recently implemented features if necessary.
- Gathering assets -
In the very early days of the development I used UT textures and staticmeshes, but I had to realize soon - as the main concept started to evolve - that I can't avoid producing original content. So I picked up my digital camera, and started to hunt for textures. One of the first pictures show a grassy clearing, which made its way through to the game. In the tall grass a flat, bright white stone lay, as big as my fist. It had a nice surface, so I took a picture of it. A few days later I realized that this texture looks great as ice on the ice ball (which was removed due the lack of time). Of course it needed some retouching, but I learned that it's worthy to take a picture of every kind of surfaces, from ham, through a wreck to sawdust, because you can make interesting new textures by combining them.
The creation of sound effects was more challenging. Although UnrealTournament has an extensive collection of sound effects, we needed many MetaBall specific sounds. In this case I also looked... hmm... listened around the house for the neccessary noises. I mostly used household devices, the ones that I was able to bring to the vicinity of the my crappy $5 PC microphone. I recorded the sound of my swallowing, the noise of a halfway filled pan hit by a spoon, and as I crumpled different kind of papers. The jump of the EvacBall has the sound of an inflated condom knuckled gently.
My biggest challenge was making the rolling sounds for different surfaces. Initially I experimented with pushing an iron ball around the table. This method had a big problem: since the speed of the ball wasn't constant (it was always accelerating or decelerating) so the pitch of the rolling sound was also changing which made the looping quite audible. Later I realized that concentric movement is what I need. I aquired a rubber ring from the kitchen (it normally serves as a packing ring in a pressure cooker) and taped it to different surfaces: I used a 10kg heavy marble plate, a steel panel and a drawing board. I placed them in my lap, I put the iron ball inside the rubber ring, and I started to slowly swing it around. The ball started to roll around, and the noise it produced was clear, loud and steady.
So don't be afraid of experimenting with visuals and audio, it's fun, and you'll realize how many interesting objects are around us in the everyday life.
- Music -
Until the half of the development, we had no idea how we could get a proper soundtrack. We didn't know any musicians, and we didn't even have a clear idea what would we expect from the backgorund music.
Then one day I saw a TV ad. It had a track which made me think that THIS is the music I'd like to hear in the game. Indy agreed, so I started to search for the composer. After a few calls I got the e-mail address of the music studio, so I wrote a letter to them, explaining our project and asking whether they would like to make the soundtrack. It turned out that they are a very kind composer couple, and after I presented them the concept and the finished levels, they undertake the task for a symbolic ammount of money.
It was a pleasure working with them. We kept sending them screen shots and animations from the game, we told them the main features, the background story, etc, so they were able to feel more the mood of game. Later they sent us 15 second "sketches" of the emerging tracks, so we got the idea of the instrumentation, the main themes and the mood. Indy and I discussed that, and in the studio we expressed our opinion, and they made changes according to this. It was fun to mess around the studio, we tried a variety of different instrumentation (for example when the percussion in the title music's was changed to a church organ, now that was cool). It was fascinating to see a sound studio up close, in work.
And I think the result speaks for itself.
What went wrong
- Team size -
Since developing MetaBall was practically a "two men show", we had to leave out many things due the lack of time or resource. There are no bosses, the inside of the castle on HUB is unavailable for now, and many features exist only in the documentation.
We spent all of our spare time making the game during the 17 months of the developent, and we were worn out at the end. 
We also encountered difficult periods until then, but they lasted only for a couple of weeks. When the morale was low and we were tired like hell, we tried to diverge from MetaBall for a few days. The zoo, excursions and reading worked for me best.
Unfortunately we had to work in our workplace, and the crunchtime there and the deadline for Phase 4 overlapped, so august and september in 2004 was especially exhausting. So much so that I burned the last backup with a feeling that I don't want to hear about MetaBall for long time. However in these lethargic times we gathered confidence from the encouraging letters of fans. For example when we read that a guy plays with our mod with his son in his lap, and the 3 years old kid also have fun, then we think that it was a good idea to start this project. :)
- Karma integration -
This a bit more technical topic, but it fits to this section, because the physics module gave us the cold sweat several times.
The first ugly surprise happened when I was setting up a scale, which is not the most complex machine I can imagine. However, when I was rolling onto the scale, the ball or the scale itself was suddenly destroyed. We couldn't find a workaround, so we had to leave out certain game elements. (This issue sometimes arises on the Out Of The Blue secret level, when you jump into the cart. I made an alternate route, so you can finish the map even if the cart has destroyed.)
The other thing was the mirrored collision geometry: it turned inside out, and a ball fell into the object. Although it was fixed in a later patch, there still are left and right versions of certain objects, like the half pipes of the Speed challenge.
We had the idea of sliding on the top of a big ice cube. Unfortunately it was impossible to implement this feature, since KActors lodged at the edges of BSP faces and at the borders of collision primitives. These otherwise minor glitches rendered a few of our ideas useless, because in the case of the ice cube, the cube tipped out, and our ball fell off it.
And then we got the problem of penetration. Of course not as itself ;), but between the map and the karma controlled ball. It's especially embarrassing on the Speed challenge levels, but it could render the whole game unplayable under 25 fps.
When we moved to 2k4, we experienced that the balls are slower than before, so the already set up ramps and landscapes were useless, since we couldn't gather enough momentum to roll up certain places. Indy looked through the whole code three times, but he was unable to tell what caused the different behavior. It took some time to figure that a new editable karma param, the KMaxAngularSpeed appeared, with a default value of 10 (not 999999 or 1000 but 10) which limited the rolling speed of the balls quite much.
These kind of problems caused some major setbacks. Three or four times I thought that we are done, we can not finish this game (...at all, on time or as we planned). Fortunately most of these bugs were fixed in patches, regarding the remaining ones, we always found a hac... I mean a workaround. We regularly visited the Unreal Wiki and the UDN site, although on UDN it could take some time to assort usable and obsolete information.
- I tended to bite off more than I could chew. -
It happened a few times, that I worked on things which eventually became unnecessary. Like I built the HUB too big, so then half of the outside was cut out, along with the inside of the castle. (The latter can be seen in the outro.)
My biggest waste of time was on the Factory level. This map took me the longest time to build, it became quite big, it was slow, and it took far too much time to finish (around 20 minutes... for me). There were a room when I was not able to build the planned puzzle for weeks, so it went down the drain eventually. I ended up splitting the map, and making two smaller ones. Rearranging and polishing the stuff took quite a while.
And there is the boss. Well, there isn't one, although I designed, modelled and textured it, but it never made it to the game. Not just for the lack of time, but it simply didn't fit into the game, what I failed to realize during the creation.
The initial concept of pavement was that they should indicate the state of the map where you can travel from them. That meant 6 states, depending the number of saved tinies (0-5), so I made six skins: gray stone, yellow stone, bronze, silver, gold and ruby red. It turned out that its too much, their order is not obvious. Indy told me a wise thing: "Keep it simple." All right, I changed the concept, so now a pavement has 3 states: no Tinies saved, some and all of them. This requires less resource, the message is clear without the unnecessary precision.
The bottom line is: pondering the work/gain ratio of an idea is essential. It needs some degree of discipline to cut otherwise cool features, if they don't worth the effort.
- Programming difficulties -
Here I'd like to give the word to Indy:
"I started the coding part as an experiment to really get to know how UnrealScript worked. For me, coming from C++ the language felt much more game friendly of course although there are some weird parts in it. Because of the time limit and the fact that we are two people doing a project of this size we had to think even more about the reusability of the code created (you should code with expandability in mind anyway).
UT2004 comes with a large amount of code that can built on when you want to code anything for it from the comfort of your home. I really advise everybody to use an IDE, like WOTGreal because it makes coding much easier to manage and also easier to have an overview of the mod.
The code that comes with UT2004 helped a lot although there were times when I had to create my own base classes and go with that instead. There were quite a few occasions where I coded some functionality for the game, just to find out that it already exists in some form in the original classes a week later.
Basing a game on physics entirely is always risky so this was the main challenge: get the feel of the controls right, make the levels work with everything that could affect the balls and create AI that roams the world in an interesting fashion.
One good example of reusability is the KarmaEffector. We used this Actor class to create forces that affect objects in their vicinity. We could use this one class to create wind, magnetism, and even aiding in the pathfinding of computer controlled balls.
Another interesting bit on the code side is the camera code. It is very powerfull although not fully used in the game right now. Basically using control 
volumes the location, orientation, zoom, follow and even more parameters can be set for the camera. This helped a lot in creating some of the levels where there is a special camera required (like the 2D sidescroller camera) but also to create dramatic cameraviews when the player enters certain areas in the level.
There was one problematic side of the project that is often neglected by other mods also: the GUI. The UI code for UT2004 is fairly complex and is very different from that of UT2003 which was also very complex so I spent a lot of time just trying to figure out what all the tiny bits of code do when building a screenfull of GUI elements.
This takes me to another point: the migration from UT2003 to UT2004. The new mod system was not too easy to work with in the beginning and it was all guesswork to figure out why things are or aren't working the way they supposed to work. This was a setback for us which also prevented us from entering the mod into phase 3.
What else is there... oh, yeah: bugs. As with any other project this one also had/has bugs in it and I am quite unhappy that I didn't have time to fix all of them. I have to apologise from all the people who wrote bug reports and never got a reply or fix for the problem they mentioned.
There are some bugs that came up because of platform differences in UT; for example you cannot create motion blur or rendered textures on some systems."
End of line
Developing MetaBall, aside that we learned many things along the way, was quite fun. We consider this project as our child. We remember in a nostalgic way to the stages of the development: the birth of the idea, the first steps...ekhm..rollings, when we was pushing a big ice ball around on a white landscape by shooting it with assault rifles. Or when we first heard the background music in game, and how it added suprisingly much to the whole feeling. Now we just wag our heads with an indulgent smile when we recall how twits we were sometimes... (WHYYY DOESN'T CHANGE THE FRICTION OF THE BALL?! See, I'm modifying it right in the .ini file, it has the value of 5000 but still has no effect... damn unreal... oh...khmm..it seems that I'm editing the .ini in the backup directory... hmmm...)
We have a lot to thank to the fans, who helped our work with their constructive critics, bug reports and encouraging e-mails. So if you have a game or a mod in mind then just start doing it, it worth the effort.
A few advices:
- Always backup, to more then one place if possible. I burned the stuff on a daily basis, and copied it to three different PCs (my home PC, my work PC and Indy's home computer) scattered around the city, so only an extensive meteor shower could have destroyed it. Therefore it was not a big deal when my HDD died: I had to remake only a few hours of work.
- Experiment. Think out of the box and try to create something original. Experiment with visuals, sounds, music, gameplay and so on. We saw a hundred games where you played a soldier and you had to shoot terrorist in a warehouse with your MP5. It's a kinda boring. The commercial game industry is conservative enough, you dont have to be. Use your freedom and independence to find new ways.
- Pet your project regularly. Many project died in an early stage when the starting enthusiasm was gone (for a while), the routine began and the team faced with boring tasks. You'll need strong determination, and daily, regular work to get through these periods. If each member of the team works only half an hour on the project every day, then you're probably going to finish what you've started.
- When working in a team, the mutual agreement and understanding is very important. Of course you have to make compromises, but if you discuss the problems in an open minded fashion, you'll find the golden middle path. It also help to keep the morale high on the long run, since no one will feel his or herself supressed.
And finally, Indy's advices:
- Always discuss every new feature you want to implement in code with your designer. This is one way to create reusable code and also makes sure that you don't waste time on coding funtionality that is not even needed.
- Try to come up with a style guide for your code; this is even more important if there are more people working on the code at the same time.
- Plan out your code before you start hacking at it. I know this is something that is said all the time, but it is completely true. It is very important to think about the base classes that everything else will be
built on.
In conclusion, we'd like to express our hope, that even without any contest, there will be even more original, fun mods and free games available in the future.
Attila Malárik, Zoltan Erdôkövy