Alexander Birke was programmer and game designer on The Adventurers of Bertram Fiddle, an episodic point and click adventure series starring the titular Victorian explorer and his manservant Gavin The Cyclops. The first episode was released for iOS in December 2014 and PC in March 2015. This post mortem was first printed in the March issue of Making Games.

“Has his nose been eaten by a beetle?!?” was my immediate reaction the first time I saw a drawing of Bertram Fiddle.  In November 2013 I learned that Rumpus, a Bristol based animation studio, were looking for a developer to help realise their idea of a traditional point and click game about a dark humoured murder mystery played out by weird characters with even weirder noses. Being a long time fan of everything steampunk, and loving the art style I got in contact with them. I ended up spending the next year doing the programming and game design on what would become the first episode of the game. Since this was the first title that Rumpus set out to make, and the scope was really big, there was a lot of challenges we had to overcome. In this post mortem I will dig into what things that went right and wrong which will hopefully be of help to other small teams that want to produce point and click games or other titles that rely on a lot of content. So put on your favourite adventuring monocle and moustache and let’s get to work!

Things that went jolly good

Unique Artstyle and Universe

Classic adventure games rely on two things to create an immersive experience: An intriguing world you want to explore, and compelling characters that you want to talk to. Seb Burnett, the creator of Bertram, first came up with the idea for the character 7 years ago and has since spent a lot of time developing the universe, the characters, and its look. *Seb comes from a background in animation and illustration so his influences come from that industry*. He also took a lot of inspiration from B movies and Victorian Literature. Having this reference from outside the gaming industry has given Bertram a unique look you have not really seen in games before which I believe makes the game stand out from other point and click games. 

Who knew Dodos’ favourite food is apples!

The fact that the universe also had been in development for so long meant that there was less of a need for pre production of the game since many of the characters and locations had already been thought of beforehand. 

Good workflow

Before I worked on Bertram I had already worked on two other adventure games. I learned that creating a content driven game with a small team is a daunting task. Whereas big productions can assign more manpower to crank out assets you need to be smart when you have a limited amount of man hours available. What makes matters worse is that where most games can be balanced by tweaking numbers in a spreadsheet, adventure games require a substantial amount of work to change a puzzle or interaction because new assets needs to be produced for it. So how do you go about solving this problem? One part of the answer is to test early, test often, and find faults in the design as soon as possible which I’ll come back to later. The second part of the answer is tools driven development. On Shadow of Kharon, the last adventure game I worked on, it was the programmers who had to implement the content from the rest of the team into the game. As you might imagine this was very inefficient. If everyone on the team can put in their own content the whole process is much more parallelised and as a bonus you will also have more eyeballs directly on the game which helps with communication on the team as well. Instead of having to explain how they want something to be inside the game, content creators can simply put it in themselves and get immediate feedback if it works as they want it to. 

The core of Bertram’s gameplay was created with what we called the StoryEvent sequencer and Conversation Timeline. The sequencer allowed both me and Dan Emmerson, the lead animator on Bertram, to add puzzles and interactions in the game. To start with, the events that could be played back in the sequencer were fairly basic. Such as instructing a character to walk to a point or say a piece of dialogue but it proved very extendable so by the end of the project Dan even started to put in his own small easter eggs here and there. A skip button also allowed for easy testing of a puzzle by letting a condition such as using the right item or completing another puzzle in a different scene to be skipped. The sequencer would also highlight in red if an event had not been connected properly which meant it was easy to fix bugs caused by not configuring them properly.

The StoryEvent sequencer and Conversation Timeline tools

While the sequencer allowed Dan to put in puzzles, the timeline tool allowed me to create cutscenes without having to animate anything. I could simply reuse animations Dan had already created and use them in the game. Since we used Unity as our game engine it was relatively straightforward to implement these tools since the Unity editor is very open to adding extra workflow and UI to.

Like digital clockwork

Automation also played a huge part in allowing us to finish the project on time and get a higher quality product than we initially aimed for. For starters, we had not planned to have lipsyncing in the game but just use looping animations of the characters mouths opening and closing no matter what line they were saying. As we started to get dialogue and other animations into the game, it stood out more and more that this looked inferior to the rest of the game. By resurrecting an old open source project called Papagayo which was originally intended to be used with Anime Studio, we managed to come up with a workflow that let Dan and me lipsync the whole game, which is about 1200 lines of dialogue, in a couple of weeks. The new system also allowed us to change a character’s expression mid sentence which made them really spring to life

Timing is very important for storytelling and animation. Often when you start to put audio into a game it is necessary to revisit the work done earlier because the timing needs to be redone. One solution is to wait until you have the audio but that is often not feasible since you need to test the game before you have the audio available. With some smart programming we we’re able  to bypass this issue. When dialogue was imported into the game, the cutscenes would automatically scale to fit the length of the now spoken dialogue. Some manual tweaking was still necessary, but it saved us a lot of time and was made possible by having our own timeline system we could modify as needed. 

Around the world in 80 conferences

Okay it might not have been that many conferences we attended but we pretty much covered the whole globe in our effort to spread the word about the game. The first event we went to was the Play Blackpool convention where we showcased the game for the first time. It was a small event which was a great way for us to get some experience before we took the game to bigger events. Over the rest of the year we had the game showcased at Pocket Gamer Connect in Helsinki, Tokyo Game Show, EGX in London and also more locally at Bristol Comic Con. 

Adventure noses, a must have for any self respecting explorer

In general we got three things out of attending events. One was to get a lot of playtesting done with a broad range of players and get their immediate reaction to the game. The other was to help build our network. We also think that showing Bertram to representatives from Apple at these events so they could see the progress on the game resulted in the game being featured on the front page of the App Store when we released. Lastly it also allowed us to learn how to talk about the game to get people and press excited about it. Important knowledge when it came to do the written promotions on our own website, for the app store and when creating the trailer. It also helped us to get in contact with journalists and reviewers who can be hard reach through email since they are bombarded with press releases on a daily basis. 

Good writing and voice acting

In order for an adventure game to click (pun definitely intended) the writing needs to catch the player’s interest. Where other genres offer mechanics that let the player have more control over the experience, adventure games  rely much more on story. Luckily Seb had a knack for cheeky British humor and bad puns which an adventure game is the perfect vehicle for. Of course you still need good voice actors to make the dialogue come to life. We were lucky that Seb and Joe Wood, the other owner of Rumpus, had a bunch of friends who had provided the voice for Bertram and the other characters for years. Something I also think made the way we did voice acting different from how it is done for most games is how much Seb allowed the voice actors to ad lib a lot of their own lines during recordings. This gave us some of the best jokes in the game and a more natural delivery. In general the game received a lot of praise for the voice acting and we recently picked up a nomination in the Best Narrative nomination at the Casual Connect Indie Prize.

Right amount of playtesting

Inventory based puzzles are tricky to design since each puzzle and the items you use to solve them with can be understood in so many ways. This is especially true for comedic adventure games that rely on the puzzles to provide a sense of the humor. As such a shoe can for example be something you use to plant the seed of the man eating plant you’ve been carrying around or the peculiar odour it produces could be used to lure a love sick skunk away from its hiding place. 

A good adventure game puzzle is often characterized by a bit of lateral thinking but it is therefore also important to playtest them a lot. When we started development we relied heavily on paper prototyping since it allowed us to test out the puzzles without a single line of programming. As good as paper prototyping is though, it has the weakness that it introduces a major variable  into the equation: the one conducting the test. When you act as the computer it will inherently introduce variations in what you say or how you move the paper around for each person you test with. 

As more of the tools became ready to use we therefore started to skip paper prototyping and implement a rough version of the puzzles and story with placeholder art in engine instead. In general we were good at testing ideas out in this way before we spent too much time producing assets for them. At the end of production we also became better at using our design document to find faults in the puzzle design before we even got to test them which was a big plus. You should not be afraid to optimize how you work as the game progresses.

Placeholder art or a concept drawing for Bertram Vice?

Things that went down the chimney

Jumping back and forth on lead platform

At the start of the project iOS was selected as the lead platform for the game. This was pretty much because the iPad 2 was the device with the lowest specs we wanted to support and barrier to entry is easy since everyone can submit to the App Store as long as they are a registered developer. 
However midway through production we decided that it would be better to release on PC first. Firstly we expected our core audience there, PC still has the biggest community of adventure gamers and premium games are still the norm on the platform as well. We also wanted to avoid the stigma games that first come out on mobile carry with them for some of the PC audience.
We first tried through a contract to get onto Steam but were told we needed to go through greenlight instead. Reading about other developers experience interacting with Steam representatives we might have been lucky if we had talked to someone else from Valve. We then decided to try our luck with a Greenlight campaign. We launched this at the same time we showcased the game at EGX and initially had a lot of traction but it slowed down drastically after the game was pushed out of the Greenlight frontpage. In hindsight we should have launched the Greenlight campaign sooner. In the end because of a deadline imposed by our funders we were forced to jump back to iOS as the lead platform instead.

Looking back at it I think our decisions were made on a sound basis but what we should not have done was put time into the PC version before we were sure the game was going to release on it. At least a couple of weeks was spent working on the UI for PC which could have been used on something else. Thankfully the game was greenlit in February this year and the desktop version is now available on the AdventureGamers.com’s online store, so it is not like the effort was wasted. 

Awful audio workflow

The only core team member who did not work in our office was our composer and SFX guy Cameron Reynolds. Because we could not afford to give him his own Unity license it was up to Dan and me to implement all the audio he would send to us over Dropbox. Unity is great in many ways but audio has always been one of the weaker sides of the engine. I had created a bunch of components to make it easier for us to trigger audio on animations, randomize the audio and crossfade between the music but it was still a lot of work to get all the audio in. During the whole process Cam had to act through us as intermediaries which greatly slowed the process down. If our audio workflow had been better Cam would have been able to implement and play around more with the audio. In the end we had a marathon audio session over a weekend where he came down to our office and we mastered the game in one go with me acting as a human interface to Unity for Cam.

Me acting as human mouse for Cameron Reynolds, our composer

Another great limitation that arose during this session, was how Unity 4 represents volume. Actual volume and perceived volume are not linear but exponential which is why the logarithmic dB scale is audio professionals favorite way of representing volume. Unfortunately Unity 4 does not use a dB scale which meant it took us a long time to find the correct levels. Thankfully that seems to have been solved in Unity 5 now with the new audio mixer.  

A final pain in the audio department was the lengthy task of adding all the individual audio files for the dialogue into the game. When we got the raw audio from the recording studio Seb had to manually cut out the best takes in Adobe Premiere and export them with the right names. When you have more than 1200 lines of dialogue that quickly becomes a chore and we often had audio files not being named correctly. We did create a system that would import the audio from dropbox automatically and tell us what lines were missing in the game, which helped a great deal but this was still a surprisingly large task to get right.

No localisation at launch

Separating subtitles from the rest of the game was one of the first things we implemented so it would be easy to have more than one language. It also had the added benefit of making it easy for Seb to change the dialogue without having to edit the game in engine. Unfortunately the most use we had of the localisation system was that we had a friend translate the first part of the game to Japanese when we showcased the game at Tokyo Game Show. If the game had launched with more than one language it could have helped to make a bigger splash. We are currently getting Russian, Spanish and German translations made, but should have done this so they had been ready for the launch.

Beta testing is Alpha & Omega

While we had enough playtesting done we should have put more effort into having the game beta tested. For beta testing we used TestFlight which worked out pretty well for us although we were quite late to recruit testers which meant we did not have a big pool of devices to test on. Right up to submitting the game we were also busy putting in content which meant there was less time for bug fixing. As a result the game was released with at least one bug that could stop progression in the game, something that pains me as the programmer on the project.

The quality of responses we got from beta testers also varied a lot which meant it could be hard to track bugs down. In the future I would besides beta testers also hire a QA tester to tear the game apart. To use such a tester effectively I would make sure the game is essentially done a couple of months before release so all development time can be put towards making it robust. That also ties neatly together with the next point.

Not enough of the right kind of PR

Evaluating PR is kinda tricky since you are trying to predict how something might have turned out that is heavily affected by external factors. However, in retrospect a couple of things we should have  spent more time on was building a bigger online presence and in general get the word out to more people. Bertram has always had a strong presence on Twitter and Facebook but those are best at keeping your audience engaged while you make the game. 

The last conference we showcased at was AdventureX. By far the smallest event we attend it was also the one that catered most to our target audience since it is only for adventure games. A lot of the attendees really liked the game and were really surprised that they had not heard about it before. They were even more surprised to hear we were releasing the game on the App Store in less than a week of the conference! To me this indicates we had not done a good enough job of connecting with the most loyal fans in the adventure game community who could have helped us to spread the word of the game as we were developing it.

Something else we first learned at the end of development is that when you release on the App Store it is first after the app has been approved that you can send out review codes. Because we were busy putting in content we only just completed the game before we had to submit it to hit our target release date. As a result we could only send out review codes about a week before the game would launch, not ideal if you want as many sites as possible to cover your game and which probably lead to the game not getting as much coverage as we had hoped.

End of the Journey

In the end we managed to produce and release the first episode in a little over a year. The game was featured on the front page of the App Store in America, UK and several different countries and has since been released on Steam as well. Bertram recently won the award for best narrative at Tokyo Indie Fest 2015 and was nominated for best narrative at Casual Connect Amsterdam 2015. 

The team behind Bertram

If I should point to the biggest mistake we made it was to not focus enough on PR. It is an experience we will carry with us to the games we make in the future. 

Data Box

Developer: Rumpus
Publisher: Self-Published
Release Date: 11th December 2014 on iOS. 
Platforms: iOS, PC & Mac
Number of developers: 3-6 at different stages of production 
Length of development: 14 months
Budget: 60k GBP
Lines of dialogue: around 1200
Unique animations: 603
Lines of Code: 8410
Development tools: Unity3d, MonoDevelop, Git, Flash, Photoshop, Adobe Premiere, UniGayo, our own open source version of Papagayo
Amount of Tea and Biscuits consumed: Enough to feed a lesser spotted glump for a year