I usually tell people that developing games is the most challenging and also the most rewarding discipline in programming out there. You get to solve really rather difficult problems with astonishing regularity and everything you can squeeze out of the technical environment has a significant impact on the player experience.
That makes it a bit strange that we haven’t talked about the technical details of the stuff we’ve made here. That is going to change with this technical review of the game Beestenbende we recently made for the University Museum Utrecht.
From the project page:
Beestenbende is a game for families visiting the cabinet of curiosities at University Museum Utrecht. Players are invited to look at the objects on display through the eyes of scientists. In the game, a number of animals in the cabinet are confused about the animal group they belong to.
From the onset it was rather clear that this should be a mobile game of some sorts that takes place in the museum, so off we go.
Phonegap
Initially, because I had hardly any experience developing for iOS I tried setting up this project in PhoneGap. The promise of being able to use my existing web development skills to create an app and then be able to deploy it to multiple platforms was very appealing.
After a couple of days this turned out to be a dead end. Even in the basic game engine I set up, where some screens transitioned into each other, performance was disastrous. Attempts at throwing optimizations at that problem did not show much progress. Additionally PhoneGap documentation was not very helpful and tooling to debug these issues nearly non-existant. So rather quickly we made the switch to native iOS development for this project.
In retrospect seeing how far we took the project, how much content eventually went in there and how much polish we wanted to apply, I think the attempt to do it without native code was misguided in the first place. But even for simple apps the threshold to go native is not that high. Programming in Objective C is not much more difficult than JavaScript with the recent addition of storyboards and ARC. In fact for those with a more formal programming background in either Java or C#, Objective C’s clean object model with its delegates and properties may be more appealing.
This was my first iOS project but I found a bunch of API knowledge along with ample use of Stack Overflow to be more than enough to start building with confidence.
Storyboards
We heavily used storyboards in making this app. How heavily you can see in this screenshot (click through for the entire thing):
Working with storyboards is really excellent and something lacking in most integrated development environments. They work equally well if you want to quickly prototype something or if you want to really go for a pixel perfect design. Interaction designers cas use a storyboard with NavigationControllers to quickly pull together the basic flows and controls of an app. But they also enable you to fine tune the final 10% of your app.
What proved especially useful is the fact that non-programmers can easily make deep changes to the user interface without breaking code. Creating new screens or tweaking existing views and assets proved to be very easy and source control conflicts that did turn up regularly (MainStoryboard.storyboard could have been a bit less monolithic) were easily resolved.
I would say that serious web development needs something equivalent to a storyboard editor very desperately. I know the paradigms are different, but that is not the point. The main point is that an environment where developers and non-developers can comfortably work together without integration problems is the future.
Camera
The default camera control in the iPhone works well but its introduction of a new mode is jarring and unnecessary. We saw the possibility to use AVFoundation based video within an existing view (as seen in for instance Grid Lens) and we went for that. It did prove to be a bit finicky to get right but overall the vastly superior user experience was more than worth it.
Rik modeling the game’s photo team photo mode
Fonts
We had quite some issues with enabling custom fonts on the iPhone. The ones that we originally wanted to use had a misset ascender. Correcting the font metrics using a tool (see this Stack Overflow answer) then caused other problems down the road which made us eventually go back to one of the fonts included on the iPhone.
The custom typeface we use for titles and buttons
If you want to set custom fonts in the storyboard editor a simple trick to do that is to create a custom class (for instance CustomLabel) which changes its own font. Then in the storyboard any label you want to have that special font you can assign that class in the identity inspector. The customization does not need to be limited to the fonts but can be anything. We used this method to create uniform master styles for the various labels, buttons and other views that we were using in the app.
Sounds
We added sounds relatively late in the game but it cannot be overstated how much of a difference they make to a game. We can say that the sound effects provided by Rik Nieuwdorp from Claynote really made the game come to life.
Besides needing sound effects for the actions one can perform in the game, we needed voices for the various characters and tunes for some of the introduction and summary screens. Rik did an excellent job on what was probably not the most straight-forward brief.
The game is hosted by the Nautilus who sounds like:
Then we start off with a squirrel who thinks it’s a bird and sounds like:
Next there’s the eel that is sad because it thinks it’s a snake:
And finally you can get a hint of the dragon who is serves as our boss:
And all in between there are transitions such as:
I used Cocos2D’s excellent CocosDenshion sound library for the audio playback which is a simple drop-in and very easy to use.
Polish
Finally to talk about polishing a mobile app: what starts out as a small project quickly balloons into something rather daunting. Being able to control the entire user experience carries with it the responsibility to ensure that it is a good experience, but that takes an enormous amount of time.
Beestenbende technical wrap-up
I usually tell people that developing games is the most challenging and also the most rewarding discipline in programming out there. You get to solve really rather difficult problems with astonishing regularity and everything you can squeeze out of the technical environment has a significant impact on the player experience.
That makes it a bit strange that we haven’t talked about the technical details of the stuff we’ve made here. That is going to change with this technical review of the game Beestenbende we recently made for the University Museum Utrecht.
From the project page:
From the onset it was rather clear that this should be a mobile game of some sorts that takes place in the museum, so off we go.
Phonegap
Initially, because I had hardly any experience developing for iOS I tried setting up this project in PhoneGap. The promise of being able to use my existing web development skills to create an app and then be able to deploy it to multiple platforms was very appealing.
After a couple of days this turned out to be a dead end. Even in the basic game engine I set up, where some screens transitioned into each other, performance was disastrous. Attempts at throwing optimizations at that problem did not show much progress. Additionally PhoneGap documentation was not very helpful and tooling to debug these issues nearly non-existant. So rather quickly we made the switch to native iOS development for this project.
In retrospect seeing how far we took the project, how much content eventually went in there and how much polish we wanted to apply, I think the attempt to do it without native code was misguided in the first place. But even for simple apps the threshold to go native is not that high. Programming in Objective C is not much more difficult than JavaScript with the recent addition of storyboards and ARC. In fact for those with a more formal programming background in either Java or C#, Objective C’s clean object model with its delegates and properties may be more appealing.
This was my first iOS project but I found a bunch of API knowledge along with ample use of Stack Overflow to be more than enough to start building with confidence.
Storyboards
We heavily used storyboards in making this app. How heavily you can see in this screenshot (click through for the entire thing):
Working with storyboards is really excellent and something lacking in most integrated development environments. They work equally well if you want to quickly prototype something or if you want to really go for a pixel perfect design. Interaction designers cas use a storyboard with NavigationControllers to quickly pull together the basic flows and controls of an app. But they also enable you to fine tune the final 10% of your app.
What proved especially useful is the fact that non-programmers can easily make deep changes to the user interface without breaking code. Creating new screens or tweaking existing views and assets proved to be very easy and source control conflicts that did turn up regularly (MainStoryboard.storyboard could have been a bit less monolithic) were easily resolved.
I would say that serious web development needs something equivalent to a storyboard editor very desperately. I know the paradigms are different, but that is not the point. The main point is that an environment where developers and non-developers can comfortably work together without integration problems is the future.
Camera
The default camera control in the iPhone works well but its introduction of a new mode is jarring and unnecessary. We saw the possibility to use AVFoundation based video within an existing view (as seen in for instance Grid Lens) and we went for that. It did prove to be a bit finicky to get right but overall the vastly superior user experience was more than worth it.
Rik modeling the game’s photo team photo mode
Fonts
We had quite some issues with enabling custom fonts on the iPhone. The ones that we originally wanted to use had a misset ascender. Correcting the font metrics using a tool (see this Stack Overflow answer) then caused other problems down the road which made us eventually go back to one of the fonts included on the iPhone.
The custom typeface we use for titles and buttons
If you want to set custom fonts in the storyboard editor a simple trick to do that is to create a custom class (for instance CustomLabel) which changes its own font. Then in the storyboard any label you want to have that special font you can assign that class in the identity inspector. The customization does not need to be limited to the fonts but can be anything. We used this method to create uniform master styles for the various labels, buttons and other views that we were using in the app.
Sounds
We added sounds relatively late in the game but it cannot be overstated how much of a difference they make to a game. We can say that the sound effects provided by Rik Nieuwdorp from Claynote really made the game come to life.
Besides needing sound effects for the actions one can perform in the game, we needed voices for the various characters and tunes for some of the introduction and summary screens. Rik did an excellent job on what was probably not the most straight-forward brief.
The game is hosted by the Nautilus who sounds like:
Then we start off with a squirrel who thinks it’s a bird and sounds like:
Next there’s the eel that is sad because it thinks it’s a snake:
And finally you can get a hint of the dragon who is serves as our boss:
And all in between there are transitions such as:
I used Cocos2D’s excellent CocosDenshion sound library for the audio playback which is a simple drop-in and very easy to use.
Polish
Finally to talk about polishing a mobile app: what starts out as a small project quickly balloons into something rather daunting. Being able to control the entire user experience carries with it the responsibility to ensure that it is a good experience, but that takes an enormous amount of time.
But all in all making a game like this is very rewarding, especially if you see the families in the museum playing it.