Kultima, A.  “The Organic Nature of Game Ideation:Game Ideas Arise from Solitude and Mature by Bouncing”

Kultima, A. & Stenros, J. “Designing Games for Everyone:The Expanded Game Experience Model”

First paper presents the results of interview study of idea generation habits of Finnish game developers. The main finding is that the process of coming up with ideas is mainly solo activity, but the maturing process of the ideas is more social. Game developers were talking about “bouncing the ideas”. The ways and tools vary among individuals, but even though it may seem that there is no method, individuals have developed intuitive ways to enhance their processes. The sources for new ideas lie also outside the digital entertainment realm, as many interviewees reported that they seek inspiration constantly from everyday activities. Paper also implies the need for educating game developers even more about ideation methods.

Second paper discusses the expanding nature of game experiences, not only because of the “casual turn” but also because of the rise of social games (Facebook and similar) and games turning into services. The paper presents theoretical model “Expanded Game Experience, EGE”, that we have been working on in several projects, including Gamespace and GaS research projects.

Here are the slides for both of the presentations. Papers will be available at ACM digital library later this year.

http://gamesandinnovation.com/survey/

Read more about the benefits of participating here.

More information and the link to the survey can be found at our Survey page (http://gamesandinnovation.com/survey/)

The survey will be closed on 14th of May 2010.

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.

In order to grasp a better view on real-life game design our researchers will be spending a few weeks with some of our partners, actively participating in their daily work. The researchers will be reflecting and observing the game design processes of the companies and keeping a detailed diary during their stay.

In addition to understanding the daily life of a game designer, we are particularly looking at how the companies nurture and support creativity.

First round was a blue-sky ideation workshop with 2 to 3 ideation methods per workshop. The methods included GameSpace methods such as VNA, GameSeekers, GameBoard and some other methods such as ThinkCube.

The other round included restriction-based ideation, where the companies could propose a restriction for their session. We developed new prototypes that try to facilitate more focused ideation sessions. The results have not yet been overly promising as this “idea game” design challenge is more demanding. The restrictions used in workshops varied from platform, theme and social aspects to old concepts.

In both rounds the ideas were documented, and the best ones were introduced and talked about. We also gathered the experiences by conducting a group interview about previous experiences, thoughts about the workshop, methods and ideas as well as what restrictions means in general level to the developers.

GameSpace project methods are available here:  http://gamelab.uta.fi/gamespacetool/

Make sure to register early! The registration will be open until Monday, January 25th, 16:00. However, the participant number is limited and in case it is exceeded, the registering order is one criterion to select the participants. In addition, participants registering before 15th January get a free Finnish Game Jam t-shirt!

More information of the FGJ on www.finnishgamejam.fi and on the global event it is part of, Global Game Jam, from www.globalgamejam.org.

A Game Jam brings together both game development students and professionals to innovate new games in a single weekend. Global Game Jam is a worldwide event, in which several jams are organized all over the world at the same time. The event lasts 48 hours, starting on January 29 at 17:00 local time in each time zone.

The first GGJ was held in 2009 with over 1600 participants in 23 countries, producing 370 games. More information about the GGJ and examples of previous game jams and games can be found on the GGJ website, Finnish Game Jam details are found at new domain www.finnishgamejam.fi.

During the Game Jam, GaIn will be conducting research on the development process, ideation and time-constrained creativity. We are interested how this approach could be developed into a method that can be tied into game companies innovation processes.