The Making Of... Buckets Of Blood

Very occasionally RPS runs development diaries from game development teams. Most recently we received one from Sakari Games, who released cartoon combat game Foreign Legion: Buckets Of Blood in late 2009. Written by Pepijn Rijnders, the art lead of Sakari Games, this diary tells the story of how this commercially release game went from Global Game Jam experiment to full-time project for the Sakari team. We think it might make interested reading for all your active or prospective game developers out there, or anyone interested in the indie game process. Okay, over to Mr Rijnders...

Foreign Legion: Buckets of Blood is made with Blender and Unity3D. When we started the project, the Unity3D engine was rather new to us. We tried it at the Global-Game-Jam weekend in February 2009, and had a nice experience with it. Since we are a very small team and had to invest in the game ourselves we wanted to make a small but attractive game: something you could play to kill some time, and something that would run even on a low-end machine to keep our market as broad as possible. We dug up an old game concept and made it - let's say - less politically sensitive. The bottom line was that it should be a 3rd person 3d shooter so easy to play that even your mum could enjoy it.

The style for the game was developed by me, Pepijn. It started with some rough sketches of the main character. We wanted to make it look cartoonish but not childish. Our reason to go for a cartoon style was that we could add a decent (read: huge) amount of blood and gore, like the exploding suicide bombers in the game, without us being marked for it in a bad way. Like Tom and Jerry, which is very violent too but doesn't get the blame for kids being aggressive. Another good thing about the style is that it works well with few polygons. To us shape is more important than detail. Because the entire world has the same level of detail the elements all blend-in nicely. Next to shape comes shading. We don't use any heavy stuff like normal-maps, or cell-shading. We tried messing with it a bit but the result tended to look a bit flat, like we were using it to cover-up something. In the end we noticed that with a little tweaking on the light-settings in Unity3D the atmosphere and the shadows came out really well.

Since we funded the development of this game ourselves and we only had enough budget for a couple of months, we planned the game really tight. The basic game-design Merlijn made was only a couple of pages and from that we made a rough planning of all the assets in a Google doc, including props, characters, animations, sounds and so forth. Merlijn and Pepijn made placeholders for all the objects so when Sander started coding he wouldn't have to wait for artwork. When all place holders where made the basic gameplay rules where implemented by Sander. Once we had some thing playable, which came down to a moving character that could shoot other characters, which followed a path and disappeared when hit. Merlijn started designing the level and working with the tools given. In the mean while Pepijn started polishing the assets and animating all characters.

Getting the animations in the game was kind of tricky. We planned the animation to be out sourced but there where few animators available at that moment and even fewer that could do it in Blender. So Pepijn had that added to his to-do list. In production we noticed that the animations in Unity did not really match the animation in Blender. This really surfaced when we made the animation of the air-raid bomber. It looked as if the plane hesitated in its flight. The reason for this was the way the animation was sampled when converted to fbx. Instead of being liniar or bezier for some reason it was set to stepped. And that was than interpreted as curved in Unity. Than something amazing happened, on Friday we send out an email to Campbell Barton who wrote the .fbx exporter for Blender. And on Monday he send us a new exporter fixing our problem. No not Monday a month after the the deadline, but the next monday. 3 days, weekend days... well you get what I trying to say. So once again kudos for Blender; the indie game developers weapon of choice

The animations where redone twice because we had to change the animation system a couple of times. Since we worked on such a tight schedule and lost some time we took peace with animation system for now and Sander got to the million other things to implement: the hud, the controls, the menu, the special weapons, the pick-up system, the scoring system, the the implementation of the music system, tweakable game-play functionality. Well, basically everything that is needed by the game´s logic.

We used a lot of dummy assets during development. For instance our sound assets: at the start of the project we made dozens copies of a bleep sound file to allow the programmer to play the right sound file at the right moment. Our sound engineer, Noel Wessels, would later on overwrite the sound files with the correct sound and could instantly hear his changes. For the music we wanted to something dynamic, something that pushed the action but calms down when the pace of the game slows. And on top of that we wanted a heavy metal ring to it. This to emphasize the type of game we wanted it to be: not taking cover, but gun-blazing, full-frontal attacks.

For source control we used TortoiseSVN. But that was maybe not such a wise choice. Unity has a nice asset server we noticed later on after the project but we had to spare our dimes on food and water so TortoiseSVN is was. The problem was mainly in the meta-data that Unity uses. For that reason only one person could work on the scene at the time. To make sure you would not submit your scene while some one else was working on it we used a physical wrech with the label “lock” on it. The person that had it had to have it on his desk. Once he submitted all his changes the lock was handed over in an almost ceremonial way so no data would be lost. And still the data did hit the fan at more than one occasion. Sander gladly knows his way very well with SVN but it felt un-natural to work this way. After the project we bought the asset server for Unity and boy did we regret not getting it earlier.

Personally I prefer production teams to be as small as possible. We mainly worked with an artist/animator, level-designer, coder combination. Not an overkill on documentation and a global idea for the game-play that was clear to every one. Knowing what you are supposed to do is very important in game development. And if you end up off track it's great to just turn your head and ask if anyone is planning to start on a feature that needs your input somehow. The master-plan with small games should always be: make the game fun to play. Maybe this counts for big games too... An other advantage of small teams is flexibility. You don't have a chain of command for each decision to run through. I think game-play tests are the best moment to decide rather you are on the right track or not. You cant go from fps to rts but having the parameters to tweak exposed in your game-editer and even during the play-testing allows you to balance the game early on. This was kind of a positive side effect of using Unity and having little time. Sander just exposed anything we might want to tweak so he didn't have to focus on those things while implementing other features. Simple because we did not have the time for it.

At the end of the third month everything in the game needed to work properly and the visuals needed to look final. At that moment a lot was in place, but not everything was finished yet. Merlijn pulled it off to make it quite fun to play too. The testers reaction so far were mainly: "Can we kill the chickens yet?", "Are there more maps?" and "Is there a multi-player version as well?". A week later the chickens could be killed and some game play issues where addressed.

But unfortunately, our budget was too small to accommodate the demand for more maps and a multi-player mode for the first release: we had to release soon. So we made the promise on our blog that we will update the game with more maps for free and later on extend it with a multi-player. Elise took care of the paper work and Sander dove into the integration of our game in the Steam Platform while Pepijn supplied the artwork for the achievements and needed media material. On August 5th, 2009, the game was published on Steam. Now, we can look back at the past 4 months with a big smile, and we 're looking forward to a successful independent future.

We previously wrote about Buckets Of Blood here.