Greetings! My name is Tero Laukkanen and I’m a game designer / producer at Moido Games. In this post mortem of sorts I will discuss the design process behind Hopido (App Store link), our first iPhone game released in October 2009. Hopido was actually the first game released as a “Moido product”. The early years of Moido have been spent primarily on client projects. For example, we’ve developed about a dozen online lottery games for Veikkaus (The Finnish National Lottery), many of them from our own concepts.

This is Hopido

Hopido is a simple puzzle game, in which player attempts to hop on all glass tiles that make up the puzzle shape. Only two moves are allowed: over one tile diagonally and over two tiles horizontally and vertically. Re-hopping on visited tiles is not allowed, so players must think ahead to keep valid moves open as long as possible – hopefully until puzzle is completed. When faced with a dead end, player can either back up with the unlimited undo or restart from scratch. Along the way player earns gold frogs, which will unlock harder difficulty levels and elevate player’s “Hopido rank”.

Sounds confusing? Please check the embedded video. (Also visit the Hopido website.)

Background – The “Numbers Game”

I’m a bit of a gadget nerd, and when the first iPod touch came out I thought it was the bestest gadget ever. The original web apps never really interested me, but when Apple revealed the plans for the iPhone SDK and the App Store, I knew Moido had to be a part of it. Indie success stories started to emerge almost immediately, so it wasn’t hard to convince the fellow moidokas of this new branch of production. We invested on a Mac, joined the developer program and appointed our C++ programmer to iPhone duties. Now all we needed was a simple enough project for learning the ropes. Enter the “numbers game”.

The numbers game was a fun little timewaster we used to play at school on the back pages of our notebooks. I don’t know the game’s origins or if it has a real name, but I do know it is played in other countries as well. There are variations for iPhone that come from Sweden, Germany and France, all with different names. The basic concept had been stored to Moido’s idea bank way back in 2006 before the company was even founded. I had even developed this little Flash prototype. Long story short, we decided the numbers game would be a perfect learning project because of its simplicity. And who knows, if fleshed out a bit and dressed up nice, it might even have some potential at the marketplace!

Mechanical Matters

The core mechanic of the original numbers game remained the same as the concept evolved into Hopido. From the first prototypes on it felt like a really good fit for a touch screen device. There were some usability concerns with the biggest puzzles (9×9, 10×10), since the iPhone screen is only 320 pixels wide. We considered adding a zoom function, but ultimately decided it would be difficult to play the game without seeing the whole puzzle at once and tiresome to constantly zoom in and out. Instead, our programmer figured out a way to expand the touch area of the active tiles (i.e. valid moves). This worked out well, since there is always at least one inactive tile between two valid moves.

While the basic numbers game mechanic translated well to the digital format, there were still a few areas that had to be thought through more carefully and even caused some debates.

Undo or Not to Undo

One debated issue was the undo feature, or more specifically, if it should be limited somehow. The argument was that having unlimited undo could turn Hopido into mindless game of trial and error. However, I personally felt the game would be unnecessarily frustrating if undo was limited in any way. Furthermore, I always thought of Hopido as a casual puzzler that should encourage trial and error and include a substantial luck component. My vision of Hopido should be played: at first just hop around without much of a thought, and only when less than a third of the puzzle is left, start to consider the moves more carefully. If you hit a dead end, undo back to a “node” from which there are still several potential paths to take, and try another one. If that doesn’t work, try another one, and so on. If it seems like every path from that node leads to a dead end, back up further or start over.

In the end it is of course up to the player to decide how to play the game. The current functionality supports different preferences, limited undo would not.

Guiding Lights

Another issue was the highlighting of valid moves. Initially (and for a long time) the default setting was that next valid moves were highlighted. This felt like a good way to ease in new players and teach them the allowed movement. Once they’d become more adept, they could turn the highlighting off if it distracted their own thinking process. However, the highlighting seemed to confuse players rather than help. Because the first few puzzles are very simple and almost impossible to fail, players often solved them accidentally just by tapping highlighted tiles randomly. Their reaction was “What happened? What did I do?”

To avoid this, we changed the default highlight setting to “off”. Now players had to figure out the valid moves themselves, which of course may have also caused some confusion, if they failed to check the illustration displayed automatically when the very first puzzle is loaded.

(A hint to anyone playing the game right now: with the highlighting turned on, it’s possible to work out the solution to many of the puzzles with a specific trick…)

Numbers of the Beast

The final game mechanic related debate concerned the numbers on the tiles. When playing the game with pen and paper the numbers are pretty much essential. Without them it would be very easy to lose track of the last move. However, in the digital version the last move can be distinguished with a different color (as it is in Hopido), so the numbers are no longer necessary.

From early on Hopido had an option to turn the numbers off, and the debate was whether this should in fact be the default mode of the game. The concern was that the numbers might make the game look like a math challenge, i.e. difficult and off-putting.

In the end the numbered mode remained the default mode for a couple of reasons. First, the numbers were the only progress counter while solving the puzzle. Since gold frogs were awarded based on the progress, new players would’ve certainly been baffled if the numbers weren’t visible. Of course it would’ve been possible to add a separate interface element for displaying the progress (the original design actually had it).

However, the second and more important reason for sticking with the numbers was that Hopido was still “the numbers game”. There were already plenty of tile-based puzzles on the App store, and the numbers were a way to differentiate, they gave Hopido its character. Also, numbers haven’t exactly stopped sudokus from being successful… (As a compromise the App store description for Hopido includes screenshots with and without numbers and emphasizes that IT’S NOT A MATH GAME!!!!)

Fleshing Out and the Way of the Frog

There are thousands of free games available for the iPhone, so we knew we had to flesh out the basic concept if we were going to ask money for it. It was also beneficial for the learning process to have a little more substance to the game.

Initially the idea was to add depth with different game modes. There would be the “Classic” mode, in which the player would solve square grids from 5×5 to 10×10, the “Shapes” mode with different puzzle shapes, and the novice-friendly “Endgame” mode, in which the puzzles would be partially solved and the player would have to “finish the fight”. After playing with the first prototypes for a while, a fourth mode called “Dead End” emerged naturally. The goal in that mode was to find the shortest possible path to a dead end.

During the development it started to become more and more obvious that some of the modes were pretty artificial and pointless. For example, the confusingly named “Classic” mode was really just six square puzzles, which could just as well be combined with the other shapes. At the same time there was another somewhat related but even bigger concern: the game didn’t really have any obvious long-term goals, which would encourage commitment and give stronger incentive to improve one’s scores. Because of these issues we decided to radically redesign the game’s structure. The modes were scrapped entirely. They were replaced with four difficulty levels, of which only the first one (Easy) would be playable initially. The others would have to be unlocked by playing the game and getting better at it.

It took some time to figure out how exactly the unlocking would work. In many puzzle games player must complete each puzzle to unlock the next. But Hopido is not an “either-or” kind of a puzzle game. Any system that would only reward 100% completion would be ill-advised – not to mention frustratingly difficult. Inspired by Zen Bound’s flower collecting, we came up with a system of gold frogs. From each puzzle players could earn up to three gold frogs depending how far they got. (After some testing the targets were set at 70, 85 and 100%.) Higher difficulty levels would be unlocked once certain total amount of frogs was collected. The higher the level, the harder it would be to unlock. The Medium level could be unlocked by getting only two frogs from all Easy puzzles, but unlocking Hard and Evil levels required increasingly more fully completed puzzles.

The frogs were a great addition in many ways. They gave the game clearly defined long-term goals (we also added another long-term objective in the form of “Hopido ranks”), and also added much needed intermediate goals and rewards for each puzzle. We hoped this would prevent needless frustration, which might arise from seeing the 100% completion as the only goal. (However, we also wanted to encourage players to really put some effort into solving at least some of the puzzles. So as a special reward we developed a cool little mini-game, which would be unlocked if player completed all Easy puzzles. Based on my own experience this was a reasonable challenge, and quite addictive task in itself.)

Combining the modes into one also had another positive outcome: it finally gave Hopido its own unique identity. Hopido was now the numbers game with different puzzle shapes. The only one in the whole wide world!

Designer Puzzles

Designing enough puzzles for all difficulty levels was quite a task. Luckily we didn’t have to do it all in one sitting. A puzzle editor/solver was build early on in the project, and new puzzles were added sporadically throughout the project.

We had two main criteria for the puzzles: they had to be distinctive shapes that looked like they were designed instead of being randomly generated, and they had to be solvable from any starting point. Combined, these requirements made it somewhat challenging to come up with enough variety, especially for the smaller puzzles. Almost all shapes that represented some actual object or thing failed the second criteria. The “Evil” difficulty level was created partly because of this. Evil puzzles can only be solved from certain starting points. (Which makes them evil.)

Big puzzles represented another problem. Up until quite late in the project our puzzle solver was painfully slow with most puzzles above 7×7 tiles. Testing the solution from each starting point could take hours. If the tile layout was changed even a little, the whole puzzle had to be tested again. We were just about to give up the biggest puzzles entirely when our programmer suddenly came up with a magical algorithm that cut the testing process down to only minutes. Hooray!

The final task was to arrange the puzzles into difficulty levels. We had played the game enough by now to know that difficulty wasn’t always directly related to puzzle size. Some small puzzles could be fiendishly hard while some larger ones had an obvious pattern that lead to an easy solution. Nevertheless, since these were rather exceptions than the norm, and we were unable to come with any other objective measurement system, we set size limits and split the puzzles accordingly. Hopefully no one was too appalled that some easy puzzles were considerably harder than some medium puzzles.

Graphics, Audio and the Name of The Game

Obviously a puzzle game like Hopido doesn’t require the flashiest graphics. That was one of the reasons it was chosen as our first iPhone project. Nevertheless, screenshots greatly influence the purchase decisions on the App Store, so we wanted the game to look nice and professional.

The graphic style went through couple of iterations. The original idea was actually to have three different skins built into the game. The default skin would’ve been “notepaper” in honor of the game’s origins. We soon came to our senses and decided one set of graphics would be enough. But it wouldn’t be notepaper. Because our graphics artists were busy with client projects, I designed the initial graphics myself. Although not very original, their clean and modern style looked pretty good and “touchable” on the iPhone screen. For a while it was even considered as the final style, but then the name of the game changed.

For a long time the working title of the game was “Hopsan”. It seemed hilariously fitting, but in the end was perhaps too much of a Finnish in-joke. The next iteration was “Hopit”. While working on the temporary graphics for the title screen, I came to the conclusion that “HOPIT” was not a very photogenic set of letters. It looked much more balanced if I added one more letter after the “T”. Like “HOPITI” or “HOPITE”. But whatever I added, it sounded weird, like a Native American tribe. Then I experienced perhaps the single most creative moment in the whole design process: what if the “T” was also changed..?From that spark of genius came “Hopido” and suddenly everything fell into place. The game would have an oriental theme and it would be a worldwide phenomenon just like Sudoku!

It is of course completely ridiculous that such a trivial thing should have so much (or any) effect on the design. But maybe this example also gives some humbling perspective to the randomness of the creative process.

Once the oriental theme was chosen, the basic graphic design that can be seen in the final product was laid out pretty quickly. Tweaking and polishing took some time, of course. Special care was given to the icon, which equates to a box cover on the App store. If the icon doesn’t stand out and appeal, the customer is unlikely to even look at the description and screenshots to learn what the game is all about. The frog was a natural choice for the icon. Initially it was just the gold frog amulet from the game, but we decided a cartoonish frog would be more appealing. The icon turned out so well that I would’ve wanted to use the same frog mascot more prominently in the game itself. However, the humorous style didn’t really fit with the more somber look of the game.

There was also some discussion about whether the icon was a bit misleading. Would people be disappointed when they learned there weren’t actually any cute frogs in the game? Some probably were. In fact, even before Hopido’s release I already had a vision of a “live action” sequel where an animated frog would jump from leaf to leaf on a pond. Imagine my disappointment when I recently bumped into a new iPhone game called Kaeru Jump. It’s almost exactly what I had in mind, albeit with different movement rules and uglier graphics. Apparently it has also been out as a web game for years. Note to self: play more games.

Finally a few words about the sound design. All sounds in Hopido were made in-house. The music in particular turned out really well and adds much to the atmosphere. The sound effects took some time to get right, although there’s only handful of them. It is not easy to design sound effects for an abstract puzzle game; a “gunshot” sound is a no-brainer, but what does “undo” sound like? The effects also had to fit the Oriental theme, feel right in context of the interface materials, sound natural together, and of course hold up for hundreds of repetitions without becoming irritating. The “hop” sound in particular went through at least dozen iterations. The final effect is actually a mix of two failed attempts: the other was too bright and the other too dull, but together they worked like charm. (An additional nuisance regarding sound design was the poor speaker on the iPod touch. Sound effects that sounded great through the headphones could be annoying or inaudible through the speaker.)

Famous Last Words

Considering that Hopido was first and foremost a learning project, the development went surprisingly smoothly. Even the redesign of the game’s structure only took us back a week or two. In the end, I’m also quite happy with the way Hopido turned out from a design perspective. It has unique game mechanic, which fits the touch screen perfectly, a solid set of features, a very usable interface, nice graphic style and great music. There might not be anything spectacular about it, but anyone who plays the game (or reads this) should be able to see a lot of thought went into every aspect of it.

Hopido was released to the App Store in October 2009. The game was briefly featured on the Apple’s “Staff favorites” section, but never got the all-important in-device promotion (most people browse the App store mainly from their iPhone) and never climbed high enough on the sales lists for sustained business. It didn’t help that the first user reviews in both US and UK stores gave the game one star and warned everybody about a bug, which caused the game not to load. The bug was real, but only affected certain older operating systems. Otherwise the critical response – both from users and review sites – has been mainly positive, although very limited. (Go to www.hopido.com for few links.) Hopfully our next iPhone release – currently in the final stages of production – will also boost Hopido’s sales and give it a new lease of life. Looking back at all the hard work that went into it, I think it deserves it.

Advertisements