As production of "Pavel Piezo - Trip to the Kite Festival" was recently finished I reviewed the material I collected for the Postmortem and found it too much and too diverse to put in one huge article. So, I identified the topics that can stand very well on their own, which were not limited to this specific game or production, and decided to write three short(er) posts in advance to this Postmortem.

[This post is cross posted from gamedev.net]

Our game “Pavel Piezo - Trip to the Kite Festival” has just been released for the first target platform (find it on iTunes). I decided to write up this postmortem without knowing sales numbers and without being able to share details about marketing on different platforms as “the story so far”. When there are interesting numbers to convey after some time, I may write a follow up or update this article for those who are interested in how an “educational game” that employs “peripheral learning” does in the wild these days.

The Pavel Piezo series puts a twist to the well known mechanics of Hidden Object Games, namely imparting foreign languages.

There are already many good articles (for instance here on Gamasutra Learning to Play to Learn and Educational Games Don't Have to Stink!) about educational games; I won’t dive into these waters in this postmortem.

Initial Idea

With one sentence of Ernest Adams in mind, “Admit that games don't teach ...”, and a recent study about the effects of peripheral learning the idea came together. The game uses the player's concentration on common objects that are to be found in the game and play a short phrase or sentence in the chosen foreign language containing the word as part of the game's reaction to a player's actions. Simple as that. According to the study it works and a few playtests with prototypes were promising.

About the Game

(abstracted from Pavels website)

"Pavel Piezo: Trip to the Kite Festival" is a hidden object game with six exciting levels. All of the objects that Pavel seeks, finds and uses come with short phrases in the chosen language. A new selection of objects, different hiding places for the hidden objects and a further assortment of spoken phrases for all the actions ensure that the game still remains fun, even if you’ve visited the kite festival already.

The language teaching corresponds to the latest scientific techniques and allows the player to enjoy playing Pavel undisturbed!

What Went Right

Starting small

The core team for the production of our first game for tablets within this studio consists of only two people, “starting small“ was vital. This has been written about many times before by people who experienced starting a small studio and I had experienced this situation myself before on comparable occasions. As tempting as it is, starting development on a game without restriction about what the game should be, we knew we had to think very carefully about what two people could handle within a realistic timeframe.

Starting common

It is important not getting carried away by the possibilities for scope or gameplay complexity. A game where we would have had to research and prototype gameplay mechanics for months upfront wouldn’t have been feasible. So, we opted for a genre that is well known, is always in demand and sets a clear objective for programming and production.

Choice of Core Audience

With the theme of Pavel Piezo we strayed from the usual core audience for the current breed of Hidden Object Games. A very limited budget for production told us that we couldn’t compete with other productions for this core audience. So we opted to be more kid friendly with the theme and graphic, keep the scope of production in reasonable limits and choose a PoD that is of interest to players from other demographics, too.

Choice of “Point of Difference”

We were loving the idea of an “educational game” right from the start. It all came together when I discovered a recent study about peripheral learning. The described method integrates nicely with a HOG, we had something that would set our HOG apart from others and would make the game interesting to people beyond a specific demographic. HOGs are liked as casual games by a wide variety of age groups and the added bonus of getting to learn about foreign languages hopefully makes players of older demographics forgiving about the limited scope.

Choice of Game Engine

I have written about our choice of HTML5/JS as the Game Engine for Pavel Piezo in a previous article. I list it here under “What went right” because we had done a different project in HTML5/JS right before starting development of “Pavel Piezo” and that allowed us to immediately jump in on the programming. Plus, in the end it worked out fine.

Coding

This went like a charm. Being only two people, my colleague Sven was coding the whole thing from start to finish while I took care of game design, production, auxiliary art direction, organizational issues and everything else. Beside that I was able to help with programming as occasional sparring partner, tester, researcher and with coding additional small systems for the website, etc.

Audio Production

We outsourced audio to a local studio with experience in producing audio for games and audio books for children. The music, sound fx and the German audio that we produced with two professional German speakers, friends of mine, were actually the first parts that were finished. For the other languages we found very friendly professional native speakers online, through various websites and searches. We found them all very competent, organized and helpful to the extent that they even pointed out translations that did not feel 100% natural to a native speaker. We did let everyone work with their preferred local studio or with their own equipment. The quality was flawless and the speed of delivery and even extra lines that were recorded as changes came up could not have been done flying people across the country.

Estimated time for production

We did not have a fixed budget for the production but instead aimed for reaching a certain degree of production value with minimum costs. It was clear that this would result in us doing tasks ourselves which could otherwise be outsourced. Once the game design and concept art were in place we evaluated the tasks and estimated the necessary time for production. In spite of troubles on the way (see below) and using up the buffer time I factored in we did hit that mark pretty accurately without heavy crunch.

What Went Wrong

Organizing the translations

While we had a very capable professional translator working with us right from the start, I underestimated the amount of effort it took to translate the short sentences and phrases into the additional languages. It’s one thing to translate the two words “scary ghost” to another language, but it may turn out to be better to use a different phrase or word once you can actually show a picture of that particular “scary ghost” to a native speaker. Of course, not every description, short as it may be, can be translated 1:1 and that caused extra effort with organisation as some phrases had to be honed later on.

Artwork and Artists

With this aspect of production, we were simply unlucky. We started out with a skilled artist for the concept drawings and other early steps. Unfortunately, he quickly realized that he did not have the technical skills required to produce the final artwork for the game in a timely manner. After that we had to look for a new artist who could jump in - not easy to find. The artist who then joined us as a freelancer had experience creating art for games and could produce art in a very fitting style for “Pavel Piezos” theme and audience.

Unfortunately, he underestimated the total effort involved and soon it became clear that we would be approximately three levels short by the beginning of the time we set aside for fine tuning and bug hunting. After I did put a lot of time and effort into searching (again), we found a studio which had experience with HOGs and available capacity at that time. Although they did their best in the limited time available to capture the overall style of the artwork, composition and scheme, one can clearly see the breach between different levels in the game.

HTML5 / HTML5-Audio / iOS Safari WebKit

We ran into serious problems on our way which, at first, we thought to be the usual trouble with memory optimization. As we dug deeper and deeper into code and libraries it dawned on us that we did hit bugs and glitches within the underlying system, specifically Safari Webkit on iOS on different iPads (unless noted otherwise, all notes here refer to up-to-date versions between Nov. 2013 to Jan. 2014). We traced each of these glitches down to the point that we coded specific test cases with minimal code, some just five or six lines. As we observed the effects with these small routines and did not find a way to avoid them we concluded that they are in the underlying browser engine. If you recognize any of these and know that they are not in fact browser glitches and know how to avoid them, we would love to hear from you!

The game has a lot of Graphics-Assets, so we’re “unloading” assets after a level to keep the footprint in working memory within reasonable limits. Tests with XCodes profiler showed that “deleting” assets (in our case loaded by XML-HTTP-Request) left around 100kB allocated, no matter which technique we used to delete the object, null the object etc. Seems like iOS Safari WebKit always keeps some metadata in memory.

We started out using HTML5-Audio. With the systems we used for development we observed that loading audio files with XML-HTTP-Request into the HTML5-Audio-Object used up about four times the memory of the size of the loaded file. Plus, the quality got muffled, audibly. To us it seemed that the browser engine somehow loaded the sound, unpacked it in memory and re-packed it in some lower quality. We were a bit baffled, to be honest. Well, that effect might be avoided by choosing some special encoding parameters (we did stick to Apple's documentation, though) but we simply opted to go with Phonegaps bridge to the native audio functions, which worked off the bat and has better performance.

To keep the file- and memory-clutter minimal we switched to audio sprites for the short sentences and vocabulary. Turns out that audio files can’t be bigger than 20MB when loading into the browser engine (again, for the devices and underlying systems we developed on). We had to cut some of them apart to meet this.

The graphics in our game are the exact size that is needed for displaying them. We don’t scale images or sprites. There are different sets for retina displays, etc. Nevertheless, somehow the canvas always did some kind of smoothing to the images when displaying them. There are a lot of posts out in the internet that suggest one or the other method of avoiding that effect and we tried a lot of them. From some testing we concluded that the iOS Safari Webkit simply ignores “...webkitImageSmoothingEnabled = false;” while honoring other directives for displaying images and sprites in canvas. We managed to work out a decent solution from all the helpful comments about this topic out there on the net.

Lessons learned

Besides the experience one gains during the production of a multi-language game there are two topics that I feel worth mentioning.

Production Pipeline

For the next production of a Pavel Piezo game, I will opt for finishing pre-production in its entirety in our native language first. Of course we'll keep internationalization for the target languages in mind and work with preliminary translations for development and testing. Only after that will the final translations be done and the native speakers of the other languages be involved. This will allow for easier tweaks and changes during the first part and will present translators and speakers with a much clearer picture of the contents.

As for the artwork, for upcoming productions we will employ an artist to do much more elaborate concept art at the beginning. While a “chair” might be drawn in this way or that way, the composition of elements in a scene, findable items within the scene, sizes and positions were not easy to communicate, even with providing rough concepts or finished previous levels. Our approach would have been fine and fitting if we didn’t had to get additional artists mid-production. But to be prepared for eventual growth of the team and possible changes of members the visual composition has got to have solid prototyping.

Choice of Game Engine

We are happy with our choice of HTML5/JS for the production of "Pavel Piezo - Trip to the Kite Festival" and we will continue using HTML5 for projects where it fits. But, as I described, we feel we reached some limits of what is feasible with this combination at the moment. We want to go further, we want to have more animations, more sounds and simply a bigger scope in upcoming games and we decided that using a different, full-fledged game engine will fit productions like that better and will save effort in the end.

Conclusion

Despite all road bumps the production of “Pavel Piezo - Trip to the Kite Festival” was a great experience. The game was finished in time and I think that everyone who helped this to come to fruition can be proud of having been part of creating a game which is fun for all ages and helps with learning foreign languages; the latter being a topic that gets more and more important in our time. For any flaws one might find with the methods used or with the game itself: I am entirely to blame, personally.

The team is very excited to see how the game is received by its audience. We welcome any feedback, we look forward to releasing "Pavel Piezo - Trip to the Kite Festival" on additional platforms and to producing additional games in the Pavel Piezo series.

Infos and Numbers

Developer: intolabs GmbH
Publisher: "Phase 3: Profit"
Release: February 2014 (iOS/iPad)
Platforms: iOS/iPad (other platforms are planned for later 2014)
Development: Sven Toepke and Carsten Germer
Outside help: Translator, audio studio, eight native speakers, two graphic artists, art studio
Length of development: Ten months
Development tools: HTML5, Javascript, jQuery, createJS suite, Cordova, ...
Lines of code: 57976 in 112 files (Javascript, HTML, CSS)

Article Update Log

13 Mar 2014: Initial release