How i built fortmcmoney.com — Part 1 — Introduction

In this first post of the series of 7, i will talk about my experience in building fortmcmoney.com. If you have not seen the project, i suggest you take some time to view it first to have a better understanding of the challenges and decisions i made during the process of developing this huge project.

Summary of the project

Fort McMoney.com is a webdocumentary game build for desktop and iPad. The project started as a prototype in the beginning of 2011 and as been launched on november 25th 2013. Globally, the project is an virtual representation of Fort McMurray, a real city in Alberta, Canada, which is the heart of the whole canadian’s oil sand industry. All locations you see in the game are real, as well as all characters and events. You navigate through these locations, interact with characters, collect objects and finally made your way into a mine. The story is divided into 4 weeks. Each week ends with a debate on a specific question, in which the players are requested to take position and give their opinions about their vision of the world.

The project, in numbers

3 languages,
2 years of investigation,
5 months of filming,
55 interviews,
28 locations,
1940 hours of development

The team at Toxa made a beautiful making of video that wrap up the whole project in 4 minutes.

The components

The project contains multiple components that all interact together in a very complex way.

The most important one is the exploration component. This component is responsible for loading the locations assets, displaying it and adding interaction, such a moving in 2D, zooming into characters, objects and TV screens.

The video player is also a key component on the project. It handle video playback from progressive and streaming source, as well as displaying video UI and optimizing playback by using GPU when available.

The interview module is where the player can collect information about his favourites characters through the game. All data, pushed to the interview module, are managed by a database and a complex algorithm to make the interview as natural as possible and avoid linear progression. I haven’t created the algorithm, but i must say that i was really impress by the work my coworker put on this to make it work the way the creative team wanted it to be. In fact, even if he explain it to me several times, i’ve never completely understood it. 🙂

The dashboard is where you see your progression in the game and interact with the community. There are plenty of screens that display lots of data. Some are in plain text but some others are full of graphics and animation all driven by the data collected by the community.

There is way more components and API used in the project but i will not cover those in details. The thing is that each components interact with each other in some part of the game. What i’m mostly proud of, is the flexibility we have in building the story. For example, when you click on a character, we could make a list of actions to be done in a particular order. These actions can be:

1. watch a video
2. when completed, start another video
3. when completed, prompt 3 choices to the user
4. when clicked on the first one, go to another location
5. when clicked on the second one, start an interview with that character
6. when clicked on the third one, go back to the first location

The possibilities where almost endless for the creative team, and i think i have made a very good job on that part of the project.

Why we choose Flash instead of HTML5

First of all, i want to say that both technologies are awesome and that you can build awesome experience with both of them. But in the end, we have to make a pick and we choose Flash.

When we first started to think how we should build this project, it was in mid 2012. HTML5 was not was it is right now. Lots of improvements has been made lately in the field of HTML5 and the platform is still improving and maturing. If we have to made the same decision right now, we probably go with HTML5 but we can’t go back in time. 🙂

Also, one of our goal was to publish an iPad app to the AppStore. This would have been possible with HTML5 using PhoneGap. Unfortunately, the WebView in iOS is much slower than mobile Safari. This would leave us with some heavy code optimizations to made in run smoothly on iPad, and lots extra work. But remember, we were in 2012. PhoneGap was not as mature and stable as it is right now.

The main point that made us choose Flash are the browsers inconsistencies and bad support of HTML5 by old browsers, like IE8. We wanted the project to run on old browsers like IE8, without cutting on features or creativity. That would had been possible in HTML5, but the extra work needed to made it run in older browsers would have been so big that the project would have suffer from this support to legacy browsers. Flash is still a mature platform that is consistent across all major operating systems and browsers. Even if you don’t like Flash Player, we must admit that it is stable and when used properly, can deliver great user experience at a wide variety of browsers, even the older one, a lower cost than HTML5.

Technologies like WebGL were also a good looking solutions. Unfortunately, WebGL was, at that moment, not available on mobile device. It was a deal breaker for us.

That’s why we choose go to with Flash. The creative and design team on the project had a lots of experience with Flash in the past and knew how to work with it. We still hit walls during the development, some bigger than others, but we were able to pass over them and deliver the project on time.

What’s next

In the next posts of the series, i will talk more of the techniques i’ve used as well as the problems i’ve run through during the development. I hope you enjoy this post and will enjoy the next one about Exploration module.