The Making of Match Master

The Match Master project started out with some bold ideas. We wanted to push the bar as high as we could with web-only HTML5 technology and go at least as far as we could as if we were building a game in Flash. When the project was conceived in early 2014 there were not many HTML5 games that were considered console quality. The technology had made some recent advances and a lot of developers were working hard to prove it could be done. Our goal was to manage a single code base and deliver a game to web, iOS, Android and Windows Mobile. At the onset with HTML5 and Apache Cordova this was theoretically possible. We would also take this single code base and deliver three iterations of the game: Match Master 3000 for our own distribution, Top Chef Memory Challenge as a promotional game for the Bravo TV Top Chef franchise, and Real Housewives Memory Challenge as a promotion for the Bravo TV Real Housewives television series.

We reviewed several of the available frameworks and we went with CreateJS based on its impressive demos, the spectacular Atari Arcade, and its comfortable API given our experience with Flash.

The game idea we settled on was a memory match or concentration mechanic. Match pairs of cards and score based on having a good memory and clearing the board quickly. However, we added several twists to the basic game play mechanic. At the time we were flabbergasted by the popularity of games like Candy Crush. We wanted to understand what elements made it so addictive and if we could replicate that in a game of memory match. We added a lot of features you would not find in a game of this type: moved-based instead of time based limit; 8 different game play mechanics of progressive difficulty culminating in 28 levels; story-based progression through 4 lands; boss level to beat in order to progress to the next land; achievements; and many others.

On final delivery we made a game we are proud of and it stacks up against the many successful games in our portfolio. While it hasn't been much of a commercial success, the code base and lessons learned will help give us a strong foundation moving forward in web games that work well on any platform.

What went right

• We delivered a pretty deep memory match game experience on HTML5 platform that runs fairly well on a very diverse set of web and mobile platforms.
• We delivered to Bravo their first HTML5 game giving their users a game that can be played in browsers and on mobile devices, highly tailored to their brand, integrating their ad network directly inside the game.
• We made a game that represents the brand very well with a deep integration using their content. Visually the game is as good as anything we would have done using Flash.
• We responded very quickly to changing requirements such as iterative game design, content changes, progressive technology, and integrating Ad delivery.
• We made a flexible code base that should allow us to customize the game very quickly in the future and jump-start new games.

What went wrong

• Late delivery. We promised a delivery schedule against a code base that did not exist, on a technology stack we didn't have experience with, assuming our experience on other technologies to predict our ability to deliver on time.
• Many unanticipated technology and functionality problems. We did not have enough experience on the HTML5 platform or CreateJS, this being our very first project. Therefore we did not know what roadblocks were ahead of us. Most of these issues centered around the diversity of target platforms and HTML5 nuances.
• While we built a highly customizable game, that feature alone caused many delays.
• We over-promised features post project acceptance (feature creep), causing misaligned schedule conflicts when we should have been focused on meeting what was originally promised and delivering on that.
• We did not have a complete game design at project acceptance, and then designing, iterating, and changing on-the-fly.
• Ad integration was not added to the project until we were in final delivery. This should have been an up-front feature determined at project proposal time and properly scheduled. The ad integration caused significant delay and was the source of several bugs.
• Working as a remote, non-dedicated development team. In particular, not having a full time designer caused many delays in turnaround. It also caused many non-productive iterations as we made feature changes in the app.
• Trying to hit too wide a target for platform coverage using an evolving technology. HTML5 is still evolving and it performs poorly on older devices and its feature set is inconsistent across platforms. Trying to cover too many devices engaged significant effort to meet the requirement of a consistent performing app.

Summary

We delivered a game we are proud of and the people involved find fun to play. Given our initial expectation and experience with our first HTML5 project we feel we are in a good position to deliver much more predicable schedules on future HTML5 projects. It is important that we better match requirements with our understood capabilities of HTML5. It is also important we either commit to a specific project design and platform target, or, when we design on the fly, do not commit to a specific delivery date. While we addressed the resource experience gap, it is still important as ever to assemble a capable and experienced team to predictably deliver creative projects. None of these issues are new to game development, regardless of the technology stack used.