Game map is automatically generated as a Voronoi diagram. In some games, Voronoi diagrams are used to generate natural looking texture and terrain. The diagram visually resembles a reptile skin, but it also forms a complex cellular structure that can be used as a movement constraint. In chess or hex, where square or hexagonal tiling is used, every cell looks alike. But, in a Voronoi diagram, every cell has a different shape and varying number of neighbors. I used the Voronoi cells as the valid positions for the bug.

On the map, the bug is allowed to walk from one cell to one of its neighbors at a time. From top-down view, player left-clicks on the map to make the bug walk to a neighboring cell. Some cells contain food the bug should eat and finish. The bug creates itchyness on the cells it walks on.

Presence of the monster is felt by hearing its groanings of irritation from itching. After every moaning comes the monster’s hand to scratch. The main tension is either to continue eating or to flee the expected scratch. The bug is either eating food or running around.

Itchy does not include a level progression, but has a freeform mode where the player can adjust the difficulty by changing (1) the frequency and speed of monster’s scratching (2) the itchyness of the skin, and (3) the total amount of food available on the map.

Itchy is developed in GGJ at Ankara. Strong points of Itchy are the generated game map, its rich sound effects that count in gameplay and fun factor.

Voronoi as game map

In Itchy, generated Voronoi diagrams are used as a hard constraint for player movement. I emphasize this, because previous applications of these structures such as texture synthesis and terrain generation are (to my knowledge) less directly related to gameplay. But in Itchy, the player directly faces this geometrical structure as a constraint and determinant of her actions. The obvious alternative would be allowing her to walk the bug to anywhere she clicks on the screen. By applying this constraint, we reduce the selection of clicking from 100.000s of pixels, to a choice from merely 5-6 neighboring cell directions. As the bug arrives in each new cell, a different multiple choice appears, necessiating the player to plan her moves in small discrete steps. This also simplifies the actions, removing the need to aim the mouse accurately. This discretization of gameplay is typical in turn-based games, but it can as well be used in fast, real-time interactions. This is like when people (especially children) walk funnily by stepping on one rock, or one paving stone at a time, using the existing segmentation under their feet like a game board. What Voronoi diagrams offer is the procedural, automatic generation of naturally segmented game maps that directly affect the gameplay by shaping and discretizing the player’s movement.

Chess uses square cells and Hex uses hexagonal cells, but as far as I know, there is no game that uses cells of a generated Voronoi diagram as valid player positions before Itchy. I think this is mostly because of the additional algorithmic complexity introduced by leaving behind the regular grid structures that are so convenient to code in the memory blocks of today’s computers. By the way, these regular tiling systems are special cases of Voronoi diagrams, and the algorithm can be used to generate altered or distorted versions of square, hex and triangle tilings. Most of the previous game designs can be adapted to this new structures to get more interesting games. For example, the cells can be painted to different colors to denote opponents’ territories, making it a strategy game with multiple units distributed to several cells on the map. The actual geometric distances can be used as an external cost, as an intrinsic cost of time like in Itchy, or they may not be used at all.

Eternal conflict

In Itchy, the game space is defined by the strange arrangement of skewed green cells, expressing the unwelcoming, alien skin of the giant beast, stressing the smallness of the feeble bug. This effect is strengthened by the startling roars by the monster, and the fact that the player can only see parts of the monster: Either the part of skin the bug is walking on, or the monster’s hand and fingers as an immediate fatal threat.

However, the monster is also disturbed, maybe even more so, as the bug can constantly irritate it by moving around, and it is always possible for it to flee the monster’s scratching (though it can be made harder by difficulty settings).

This is a game about mutual and endless relationship of irritation and threat between two beings that are completely different from each other.

Today, most of the games are about purposedly destroying the (offered-perceived) enemy agents to preserve one’s own homeostasis, usually in a series of missions. Every mission ends with a momentary success, only to be upset by another challenge, another threat to oneself. The conflict is further segmented into individual enemy units that are distributed by level designers to gradually increase the difficulty of the game. This approach creates an economy of challenges and benefits that have precalculated effects on the “gameplay”, making the life easier for the game designer and harder for the level designer. These games are like a TV series where each episode repeats the same scenes and stunts in different looks, but makes it interesting by playing with their quantities, making the chase scene shorter or longer etc. Each episode/mission presents an absolute enemy, which is always defeated in the end, before reappearing/respawning in different costumes to further keep the watcher/player’s attention.

Thief is a counter-example where the guards are only bystanders, thus no agent claims to embody the “enemy”, raising the antagonism to a larger context, thereby stringing the missions together in a long approach to the unreachable. We never know everything, there are several times in Thief that we reach somewhere and the mission objectives change, similar to our bug in Itchy facing a different set of choices at every cell it reaches. This is one of the reasons I did not implement levels and progression. It would create an illusion of success where none is possible.

Another counter-example is Dungeon Keeper where we are the commanding evil hand over our feeble creatures (Itchy probably owes its atmosphere to DK, by the way). We are the evil side killing good guys, our creatures are full of hate and fear, some of our creatures fight with each other… There is no inner balance to begin with, and there are no external enemies other than the monstrosity in our own agency. In DK, you can use the Possess spell to see through the eyes of our monsters, and their visions are either awry or distorted. You Possess the chicken and the creatures eat you. The imps run around, being weak and short sighted, similar to our bug in Itchy. DK presents a game space where no clear cut template applies. This is like expressing the concept of ideology through a game.

Black & White is another counter-example where our primary enemy is your own power and contemption over our people, as we will lose power if we give in to our urge to throw them around. These are games that contain structural conflicts that cannot ever be resolved. You can instantly make an algorithm respawn less enemies, send more medikits or whatever to balance a fake conflict, or series of small conflicts. But in these games, the conflict is implicitly coded into the primary relation between the player and the agents in the game. The intrinsic parameters of this relation must be fine tuned to a certain level that adds to the fun-complexity, and preferably not modified during the game, as the player will adapt and learn these parameters throughout the game. This is like raising the player control parameters (like friction or deceleration speed) to a more global level, to the shape of game-space itself. If the intrinsic skewness of the game space is adjusted well, level design should not be a problem, as the primary gameplay properties of the game will respond fruitfully to different types of simple modifications. This is similar to having fun improvising with a beautiful musical instrument, despite the lack of talent. That’s why we spent several hours in the Game Jam to play and adjust the primary parameters of Itchy, making the bug faster and making it longer to eat.

Itchy is a game where there is only one primary conflict, between the itching by the bug and the scratching by the monster. This conflict is fun to play with, but it is obvious that it will never completely resolve (unless the bug dies). Moreover, the roles of both sides are defined by this conflict, and the existence of both sides feed and depend on the sustanence of this never-ending struggle. Mathematical tools like Voronoi diagrams are only used to reach this goal of creating something meaningful that is original and consists only of core gameplay.

Itchy 1.01 (for Windows)

Itchy 1.01 (Source code)

(Abbreviated translation from the original Turkish text)

Itchy’s hero is a little bug. It wanders around and feeds itself on a green surface. Nobody knows about the blue things it eats, except that they are healthy. Also, red markings appear where the bug walks. Soon, we understand the meaning of these markings, as the giant green hand of a monster reaches to scratch its skin, on which our bug is wandering. The bug makes the beast itchy, and he reaches to scratch. Purpose is simple: We try to eat blue food, but our bug can die in a scratch if we are not careful.

(I chose “missing” because the bug was always “avoiding and escaping” the beast and also the beast was always “missing the target”. Moreover this escaping from each other “missed” the point, because practically the two were always together.)

When the theme was first told, Ugur, Basar and I started walking around the corridor, thinking. Togetherness and problems made us think of different things: molecules and chemical reactions, things destroying each other, nations that are hostile to each other, lovers that cannot come together… But all these relations showed a mutual and symmetrical structure. Thus, I wanted to use a most asymmetrical relationship, I thought of the relation between parasite-host, and Itchy came out of this idea. Basar slipped to the social themes and from the individual’s relation to the people around her, he decided to cover accumulation and cheering of a crowd. This idea transformed to make the game Hooligan. Ugur, on the other hand, went up to the level of relations between groups of living beings, planning to build an ecosystem. With certain changes, this idea formed the main theme of the game Lucid.

From now on, I leave these games to their makers and focus on my game, Itchy. For detailed information, you can look at the pages of games developed in GGJ 2009 Ankara.

At first, I thought what could happen between a parasite and its host. The parasite could harm the host, gain from it, disturb it… The creature could attack the parasite, shake its body to drop it…  But, firstly, it was neccesary to determine what would the skin be like. I considered a side-view wavy skin surface, but it would limit the player’s movement only to left and right directions. Then I decided on a top-down view, but I wanted to distort the uniformity of this surface, and find an automatic method not requiring level design to do so, as the time was limited.

I saw this image while looking for skin textures in Google:

In fact, this is a synthetic image, but it looks real. This view reminded me of Voronoi diagrams. Read Wikipedia article for details.

Maybe Voronoi was used to generate this skin texture, but my intention was to make it more than an image, make it the map of the game. Thus our game area would consist of irregular polygons, contrary to squares and isometric quads in Civilization, or hexagons in RPG games like Fallout. The player would be at one cell center at a time, and every move would be only towards a neighboring cell center. I thought this kind of a topological limitation would make the game more interesting, instead of a uniform 2D plane, where every direction looks alike. However, it could still be turn-based, real-time or user-directed like Snake or PacMan.

Production

My first night was spent on Voronoi algorithm. I believed this idea was original and novel, independent of the resulting game. I used Sjaak Priester’s Delaunay triangulation code for generating the Voronoi diagram.

At last I managed to generate the map. I played on it by drawing a snake-like thing through its cells.  Then we went to our aunt’s to sleep, handing over the job to create to our subconscious. Most of the participants stayed at ATOM in the first night, but we didn’t want to be sleepy at times of important game decisions.

I started the second day making the bug. Our hero was not going to be a weird stretchy shape, but a hopping or running little bug. My cousin Sera and friend Ugur convinced me on this. But the moves would still depend on the cells. In brief, every mouse click would make our bug rush from a cell to a neighboring cell. And some cells would contain food for it to collect. But still I did not know how I would make a live monster out of a green surface.

I worked on making the bug walk for some time. The camera had to show part of the map, and follow the bug. Also, the food had to be decrementally consumed. Most of the day was spend on things like these, adding to the action of the game. Thus, our bug was able to happily wander around and feed itself. Now it was time to make the life difficult.

At first, I considered putting eyes that watch the bug on some cells, to indicate the monster. But it would not suffice for the monster to look around, it had to do something. It could shake the surface, but the action had to be meaningful in gameplay. With Ugur, we walked the bug, trying to think of something. We thought about the sounds the monster would make. It would groan, roar, and… scratch the places made itchy by the bug! Making this clear, we decided on the sound effects. Irritation, scratching and relief for the monster; rushing, eating and dying of the bug, and the music. We chose Hulla appropriate for the game, with the low sounds for the monster and the high notes for the bug. Then we looked for a silent place to record the sound effects on the upper floors, and found the stairways of ATOM. By making weird sounds to the microphone of our recording device, we formed all the sound effects in the game. By pitch-shifting Uğur’s voice a few octaves, we obtained a perfect monster. The structure of the ATOM building also contributed to the ambience of the sound effects, giving a cave effect. We strengthened this effect with an ambient sound we found, which also happened to hide the noise in our recordings.

We needed a scary hand image to go with the monstrous sounds. As we did not have a visual designer, I sketched something out in Paint .NET. After Ugur added some shadows, it became nicer. With sound and action together, our beast came to live and the game really started to be fun. Now, the gameplay circuit was close. We had to define the rules, and balance the game by adjusting the parameters.

Last hours and “polishing”

I worked through Saturday night as the time was short. The gameplay was ready, and it had to be turned to a finished game. There was no time to make a sense of levels and progression, but at least we could leave the game parameters to the player, by translating them to natural language. At this point, I decided main parameters like the bug’s walking and eating speed had to be constant. The three adjustable things would be (1) the frequency and speed of monster’s scratching (2) the itchyness, or skin properties, (3) amount of food available on the map. Here is the selection screen:

Until finishing the gameplay, I made everything global and patched up every function in a single main.cpp file. But to insert different screens like intro and menu, I had to completely go through and organize the code. On Sunday morning, Ugur prepared images for screens like intro, game menu, options and game controls, and we built the general skeleton. The player could “Learn” about the controls, “Play” the bug, or start a “Freeform game” to adjust difficulty level, look at “Credits” or “Quit” the game.

In the last few hours, we tested the game to make it more fun and more challenging. We made the bug faster, made it longer to eat, made the scratches a little more frequent… We tried to heighten the chasing in the game. Of course the default difficulty level would not be satisfactory for all of the players, but at least they could change things with the Freeform option. Lastly, we inserted hints to the “Game Over” screen to reduce the frustration of a losing player, and handed the game in.

Itchy’s shortcomings

I told you the game’s development process like a story, wihout distinguishing good from bad. Now, we are going to investigate what Itchy lacks from the critical comments from people who played the finished version of Itchy.

1) “The game’s too easy, finishes very quickly.” In fact the game is not that short, if you increment the difficulty from Freeform mode. Of course it would be better for the game to include a level system and progression. I considered a progress from one beast to another, or through different parts of the same beast, but it would have been necessary to create the material to support this set up.

2) “Instead of the cheery intro music, you could make it more gloomy, similar to the game’s atmosphere.” It seems like a matter of choice, but the thematic consistency and what the player is made to expect is important.

3) “The controls are difficult to get.” Though the game is real-time, we divided the map into several cells. Every click makes the bug walk to the nearest neighboring cell. This requires a different kind of thinking while escaping the monster. This was a feature that made the game different, but we lacked to convey it to the player, getting ourselves so used to it.

4) “There could be different food that made bug faster, slower, etc..” Few different food types could be fine, but we would have to draw, code, explain, test and balance each of these objects.

5) “There are small artifacts in the graphics.” Rendering the game map in a visually satisfying way was one of biggest challenges. We needed to generate a texture that reflected a Voronoi diagram while looking natural. I first tried to make floodfill after drawing straight lines, leading to a mechanical looking texture. Finally, to use for every edge on the diagram, I prepared a static alpha image and pasted it at different rotations and scales to form the map. This image consists of two bands (light and dark) getting thinner to the corners and less opaque to the wings.  It is not perfect, but I couldn’t find a better way.

6) “Resolution is low.” This is partly due to neglection. We could have made the image quality better in a short time, but it first had to come to our attention. However, as the hours passed and we added new things to the game, the game seemed more and more beautiful to our eyes. Sleeplessness also could have prevented us to be critical to our own creation.

Itchy is a little game, produced in 46 hours. When GGJ was beginning, it was told for the gameplay not to exceed five minutes. So, we emphasized the quality of the experience over the amount of gameplay.

Even if a player feels for a moment like a bug wandering on the skin of a green monster in a dark cave, we count it as success.

Happy gaming…

Işık Barış Fidaner
February 2009

To download:
Itchy 1.01 (for Windows)

The game’s site on GGJ:
Itchy @ GGJ

Credits:

Işık Barış Fidaner
Game design, programming, graphics

Uğur Güney
Sound design and recording, visuals

Special thanks to Başar Uğur; Nuray, Hıdır and Sera Göktaş

Music: Hullu (Purple Motion, 1994)

It is about a bug running and eating things while trying to avoid the scratching by the hand of the giant creature it is walking on.

We really worked on the gameplay, I think we managed to make it fun and interesting. However, it is short, it has no levels (only a random map). Nevertheless, the difficulty is adjustable and the sound effects are great. Reminds me a bit of Dungeon Keeper.

Avoid the scratch!

Download Itchy 1.01

About Itchy

Visit Itchy’s page on GGJ.org

The competition in Turkey took place at ATOM, METU. 13 games were developed by 47 people. You can see other games from Turkey. Or all 300+ games that were made in GGJ 2009.

I am currently writing a postmortem for the game. As soon as it’s complete, I will publish the relevant parts here.

Barış