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 of 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 implment 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 (...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.
Next: End of Line...