Sponsored By

Postmortem: Game Oven's Bam fu

In this postmortem, Game Oven's Bojan Endrovski and Adriaan de Jongh talk about the effort they put in making Bam fu multi-platform and all the obstacles along the way releasing the game on both platforms.

Adriaan de Jongh, Blogger

June 7, 2013

12 Min Read

Originally written by Bojan Endrovski and Adriaan de Jongh on gameovenstudios.com.

In this post-mortem, we explain a bit of the effort we put into making our second game Bam fu multi-platform with one code base. As Bam fu is about to be released on Android (June 20th), we’ve quite succeeded at making that happening.

The idea for Bam fu started with a prototype for another game that required ten people to play on one device. While that prototype failed miserably, a fellow designer noted that the players thought each of them had their own color. This resulted in a string of thoughts and eventually in a prototype for Bam fu that convinced us of its physical appeal.

Making Bam fu was mainly a technical experience and we knew this from the start. The core of the game is dead-simple, but we pushed to make sure its code, art and music remained sophisticated enough. In that sense, Bam fu has been an extremely successful project for us.

Before we get all serious, check our trailer: https://vimeo.com/65065275

Tap it like a baws.

What Went Right

1. Scalable interface

Bojan: Our first game Fingle was an iPad only game because the design required it. We knew this from the start and took a very inflexible approach to built that game for that screen resolutions and aspect ratio. While iOS has gotten a few more resolutions to care about and Android is already swimming in a sea of different resolutions and aspect ratios, we wanted our next game to look as if it was crafted for your device specifically. And simply cropping would not have given us that result.

For Bam fu, our solution was quite simple in the end. We used a 3:2 format as a safe frame and extended vertically or horizontally on devices that have different aspect ratios. The whole pipeline was made to be as artist-centric as possible, so all the art was drawn in Photoshop in a fixed image size and layer structure. A combination of scripts takes over from there. The result is a bunch of images and an XML description of the exported game screen or level. The images then get scaled to three resolutions for devices with varying screen sizes to make them look crisp and to fit them nicely in every device’s graphics memory. This step also includes compressing selected images with a specific hardware compressed format for each platform and device.

The XML description is used to recreate the content in the game. Many elements use anchoring to the sides or corners and some animations, but their size is still taken from the description. Using an art tool to design the GUI and the levels made it a lot easier for artists and designers to create content. They never left an application with which they were not familiar or comfortable with.

2. Multi-Platform Engine

Bojan: All our games so far have been made with our in-house technology, which I will call ‘engine’ from here on because it just sounds better. The engine is mostly written in C++ and is simple yet flexible and efficient. It is structured much like a bunch of loosely coupled components that can be used independently. The engine was always built to be as platform independent as possible, but the design of each platform did slightly influence the design of the engine without us noticing. Overall, the engine code required only some minor changes to accommodate Android: most of the work on the engine came from making a proper asset pipeline.

We were lucky to have Gerard Meier join the team to help us out with getting the engine to work on Android. We use the Native Development Kit and Eclipse to build for Android. Both are very far from mature or reliable. A lot of work went into bridging C++ and Java and playing audio over OpenSL, instead OpenAL that we use on iOS. Making different libraries compile for Android, compensating for the different life cycle and bundling the resources into the game also took a fair share of the Android development time.

Bam fu's main menu.

Bam fu's main menu.

Adriaan: After Fingle, we were took a different (and better) approach and signed contracts with everyone involved as soon as they came on the project. This made for a frictionless collaboration and a calmer atmosphere in the office, as all sides always knew what to expect.

We had earned some cash with Fingle and were able to pay every collaborator up front. Many would argue this could turn out negative for each collaborator’s motivation, but everyone remained very motivated throughout the project.

4. Fonts and Languages

Bojan: As with most small games, we only released Fingle in English. A few months later, we find out that much of our sales actually come from non-English speaking countries. With Bam fu we really wanted to make the game available and accessible to everyone. We knew that Bam fu is lots of fun to play with kids, so to make the game accessible for them too, we made the decision to support about 15 languages in the game.

We completely threw away our old font rendering system and made a new one. We had been using sprite sheets with all the characters previously, which is fast and simple but very inflexible;  it’s not really feasible for Asian scripts. Our new system uses FreeType to generate images with text at run-time, so we can use any opentype or truetype fonts. With a bit of help from utf8-cpp, a small UTF-8 library, and some small tweaks in our resource and GUI systems, we were able to technically support localisation to most languages.

The translations were handled by U-trax, a translation company here in Utrecht, and went very smooth. We simply used a shared Google Drive Spread sheet from which a small script would generate an XML file that goes straight into the game.

Designing the pebbles.

Designing the pebbles.

5. Art, Music and Sound

Bojan: Pre-production on the game started somewhere in September 2012, as first prototypes proved lots of fun to play. The pre-production of the game was very long as we were making a major update for Fingle and our only developer at that time was putting only for two days in the week into Game Oven. During this period the artist on the project was Frederik Jansen and he documented his progress on his blog in detail (mostly in Dutch, but with plenty of images). The shape of the buttons that you touch took few hundred concepts, over the whole pre-production time, to get done right. The overall setting of the games was decided to lean towards martial arts movies to fit with the game’s fast pace.

On the second week of real production on Bam fu, our artist Frederik unfortunately had to leave the project. But with a some luck we managed to find a new artist within day: Rumena Najchevska joined the team and picked up the game where Frederik left off. She did most of the production art, icon and website art for Bam fu. The final result is a slick looking game and it’s almost impossible to find the seams between the work of the different artist.

The sound and music were both handled by Rick Nieuwdorp from Claynote and we were lucky to have the guys just across the hall in the Dutch Game Garden. They also did the sound and music on Planetenreis, a smaller project that we did last summer. We recorded a ridiculous amount of sounds and managed to reach a truly reach sound scape. In short, if you are playing Bam fu with the sound off, you are missing half the game.

What Went Wrong

1. Testing the Levels

Adriaan: The game’s levels suffered as the only designer at Game Oven was out of the country during most of Bam fu’s production. I remember a piece of advice Vlambeer’s JW gave to a bunch of aspiring game designers, to make sure that you play your own game as much as you possibly can. Upon releasing the game, we still thought that we didn’t play all the levels as thoroughly as we ideally would have.

Besides, getting a fresh look on four player levels was rather difficult. Playing an unbalanced game is obviously not an ideal experience and we noticed this from play testers after asking them to play the same levels over and over again with the same people. We we’re required to circulate four players because players grew tired of the unpleasant experience of crappy levels. (We’re very sorry! We threw ‘m all out!) Soon, we had asked most people in the proximity of our office who had time and were willing to try.

Building Bam fu's levels in Photoshop.

Building Bam fu's levels in Photoshop.

2. Fonts and Languages

Bojan: While we had fonts and languages in What Went Right, they also found their way into When Went Wrong. As happy as we were that we managed to get different languages to show up on the screen in a relatively short time, there were many things that went a lot slower.

In the first place was getting the library to compile and work nicely on all devices a bit tricky. Knowing how to interpret the data from fonts into useful information took time. We needed to learn some details about typography along the way. We underestimated the variety in languages, scripts and fonts. Finding a font that has all the needed characters was though challenge and some characters were still missing or had incorrect kerning information, messing up the flow of development.

Not knowing much about the languages the we are supporting backfired when we got to Arabic. Obviously, Arabic writing goes from right to left, but little did we know about how ligatures are being used and that it’s up to the rendering bit to do the glyph substitution and layout. We unfortunately ended up dropping support for Arabic, maybe until we get a library like HarfBuzz working.

3. Hardware compression

Bojan: On our quest to perfection we wanted to give our artist full creative freedom in making the interface and look of the game. At the same time we wanted the make the game lively so literally all interface elements have animation. We ended up always having lots of textures on the screen, and often in many layers.

The only way to cope with this was to use hardware texture compression on all devices. There are many different Android devices using different graphics hardware and of course each one has its own compression format. We ended up compiling and setting up three image compression tools in our toolchain and writing code to import the formats in the game. We used a blend of very poor documentation and days of trial and error. It all took an tremendous amount of time, but our technology now support about 90% of smartphones in the world and the game runs smooth even on an antique ones.

Bam fu's main developers making it work for Android.

Bam fu's main developers making it work for Android.

4. Forget to Include Someone In The Credits

Adriaan: The nightmare of anyone who makes beautiful things together with other people is to forget to include someone in public who has been essential to the project. It hurts, and it can destroy your relationship with that person.

So here you go, Rik Nieuwdorp from Claynote – we never intended to accidentally leave you out on the game’s announcement post. You’ve made amazing music and hilarious sounds, better and cooler than we ever expected.

Everyone should check out Rik’s work on Soundcloud and listen to the stuffs! We’ll be extra cautious not to let this happen again… we do feel terrible about it.

5. Production Art for Marketing

Adriaan: Although we did ask our artist to make at least some art to promote Bam fu with, it was by far not enough to be fitting everywhere. We found ourselves struggling with the material we had as it wasn’t versatile enough to fit in every context. One example is the screenshots we completely revamped with Bam fu v1.0.2.

Like Fingle, Bam fu is a physical game in which most action happens outside of the screen. When we released Fingle, we released the game with screenshots that didn’t communicate what the game was about. We had to quickly ask for more material from our artist when we realised this. We made the exact same mistake with Bam fu, which makes it official that we are not allowed to pull this off again.

As we found out with Fingle when we changed the icon to something more communicative, sales immediately rose. Taking a very shallow perspective on your own store page is immensely important. Next time, we’ll be asking a lot more people what they think about our icon and screenshots before releasing the game. Never solely trust on your own taste and guts.

Playing Bam fu at AMAZE Festival in Berlin. Oh hi C418.

Playing Bam fu at AMAZE Festival in Berlin. Oh hi C418.

Conclusion: Cut Your Nails And Stay Playful

Adriaan: The process of creating Bam fu felt amazingly flexible as a whole, but I feel that the game lacks in terms of design. The art and music are both super good, but we could have put more work into coming up with and testing levels. Bam fu’s gameplay is rather flat – it was always designed that way – but may be a bit too flat. The multi-platform aspect of Bam fu was a scary mountain of work, but I think Bojan managed to pull it off thanks to our intern Gerard. Not only is he a really cool dude, but he took a lot of weight from our shoulders and had it under control.

Data box

Record of iPads broken: none
Fingernails cut during / after game: 82%

Developer & Publisher: Game Oven
Release Date: January 12th 2012
Platforms: iOS, Android
Length of Development: 5 months
Number of Developers: Two full time programmers, one designer and business person, three contractors for art & music and one additional contractor for the trailer
Lines of code: 19K engine code and 11K game code, out of which 24K written in C/C++, 1K in ObjectiveC, 3K in Java, 1K in bash and 1K in JavaScript
Libraries: TinyXml2, libpng, FreeType2, UTF8-CPP
Development Tools: Xcode, Photoshop for level design, Photoshop for visuals, TextWrangler for editing the XML’s, sporks for all the food we ate.

Game Oven on Twitter: @GameOvenStudios

Read more about:

Featured Blogs
Daily news, dev blogs, and stories from Game Developer straight to your inbox

You May Also Like