What Went Right

  1. 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 then 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.

  2. 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.

  3. 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.

  4. 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... 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.

  5. 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 background 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.

Next: What Went Wrong...