Talking iOS Apps

Summary

The most long-term client relationship I've had was with Yann le Coroller from Tayasui. When the number of titles is concerned, most of my published work also comes from this collaboration. The apps in question aren't exactly games but more like toys. Each app has a character (usually a cute one), that responds to touching in various ways, and most importantly, repeats back whatever the user says. Each also has some kind of extra functionality.

List of Titles

• The Mouth
• Talking Carla (small contributions)
• Talking Carl iPad
• Pat the Talking Cat
• Talking Air Penguin
• Mr Poo

Technologies Used

• Unity Pro, iOS addon
• iPhone, iPad
• prime31 plugins: inApp Purchases, Social Networking, Game Center
• 2D Toolkit plugin (GUI)
• Megafiers plugin
• Playmaker FMS plugin (finite state machines)
• Unity Asset Server

iTunes Connect

I've already discussed the quirks of mobile devices in an earlier entry, but this was the first time I got familiar with Apple's publishing and sandbox testing system: iTunes Connect.

Strangely enough, publishing an app turned out to be fairly streamlined, as long as you make sure your application information and info.plist contents are correct. However, they seem to have gone the extra mile to make testing network-based features, such as inApp Purchases, as awkward as possible. I'm still not sure why I needed to create a fake app, publish it and reject it just to test whether you can indeed go through the puchasing sequence in your app.

Playmaker FSM

We used many plugins to speed things up, and one of them was Playmaker FSM, that allows building finite state machines. Basically, it lets you create program logic by connecting boxes with lines. You then attach scripts to the boxes to determine what the program does while it's in that state.

I found this system kind of interesting. It brings a nice, intuitive high-level structure to the program flow: each FSM is always in one state and one state only. You'd usually stay in one state for multiple frames, as opposed to the usual Unity program flow where the Update method and the like are called every frame for every object and the logic branches there, only to return to the Update method next frame. Also, if you wrote scripts for Playmaker, you'd have to think in terms of activities, not actors. You'd consider how the activity would start, what would be done every frame, and on what conditions would it end and what would be done next. These activities often ended up quite modular and reusable, though not always: sometimes I had to write a script for a simple equation used only once.

I'm not convinced it's going to replace conventional scripting, though: my eventual impression was that it suits situations where there isn't a lot happening simultaneously, and where the sequence of tasks doesn't branch too much. Otherwise the FSMs tended to become bloated. It's also hard to avoid copypasting similar states just because you need them in two different parts of the tree. However, the approach lets non-programmers participate more directly in creating program logic, so it definately has its place in projects like this.

Rediscovering Vrouw Maria

Summary

Even though I run my own freelancing company, I don't object to the old-fashioned salary work either. I've been working at the New Media department of my old school Aalto University, at a semi-regular basis. The jobs there use Unity as well. This one, in particular, a project between the Aalto University and the Finnish Maritime Museum. It's a digital museum installation through which the visitors can explore the wreck of a ship that sank in the Gulf of Finland in the 18th century. The installation is viewed in stereoscopic 3D and controlled with Kinect.

The Team (Medialab side)

• Lily Diaz-Kommonen acted as project lead and designer.
• Markku Reunanen participated in project management and design.
• Ferhat Sen acted as designer and contributed with his expertise with the Kinect controller.
• Mikko Hovi built the ship models.
• Svetlana Maras created our immersive soundscape.
• Heikki Sillanpää provided us with GUI design and related graphics.
• Minna Piirainen participated in design and user testing.
• I brought everything together in Unity, participated in design (especially the gesture interaction part), and implemented the gesture interaction.
• Lots of other people from both Medialab and the Maritime Museum participated as well. I've only mentioned the most central Medialab people to keep the list short.

Technologies I Used

• Unity 3D engine and development tool
• C# for scripting
• Kinect with OpenNI and NITE libraries

Working with Kinect

The most interesting part of this project was, without question, the creation of the gesture based interface with Kinect. It was surprisingly straightforward to get data out of Kinect and use it (when it wasn't outright malfunctioning for some obscure reason) but designing the right gestures was a challenge. Not only did we need a system that allowed the user to do all the necessary things, such as swimming in all three dimensions, but it also had to be natural and obvious for people who had never used Kinect - or even a computer - before.

The first control metaphor we tried was swimming. I came up with the (very common, I heard) idea that moving your hands far away from your body would push you to the appropriate direction in the water, while moving them close to your body would not. It worked quite well when I used it or when my teammates used it after a bit of an explanation but when we tried it with test users... it went less well.

There are, we discovered, a lot of different ways to swim. Some people would do something like we intended while some would just kind of flap their arms with very small motions. Some would scoop the water like a dog, and those are only the variations I remember right now. And this was with new media students who had instructions on how to use the system. So after discovering that you can't assume people to share your specific idea of an abstract concept such as swimming, especially when brought into a not so natural context, we decided to do something simpler.

We went through a few variations but eventually ended up with a pretty plain pointing metaphor. Pointing forward moves you forward, pointing to the sides turns you, and pointing up and down moves you up and down respectively. The trickiest part was moving down, as resting your hand by your side is also a very natural gesture for just stopping and resting for a while. We ended up requiring that you point forward and down to go downward.

Time will tell if gesture based interaction and interactive exploration are the thing of the future for museum installations or just a curiosity and failed experiment. Whichever it is, however, it has taught me a lot about usability.

By the way, I mentioned below that there are few moments as nice as getting your game to run smoothly on a mobile device. Well, one of them is the moment when your installation is first made available to the public - and they love it.

Kasvi the Game

Summary

One day the Aalto University branch of the Finnish Green Party went to visit Jyrki Kasvi, one of our parlamentarists (at the time) and the most vocal proponent of information technology in the parliament. I had no idea he even knew I was in the game business so it was kind of a shock when he asked, in a sort of an embarrassed way, if I could make a game to promote him in the 2011 election.

It didn't take much to convince me so we went on and made it with a group of people we recruited at the university. We made it in time (barely) and published it, but for some reason Kasvi still dropped out of parliament, a mystery that remains unsolved...

At the time of this posting, the game can still be played here.

The Team

• Jyrki Kasvi acted as the main character of the game.
• Patrick Jensen created most of the graphics.
• Joona Karjalainen composed the music and made the sound effects.
• Olli-Pekka and Tomi-Mikael Kahilakoski tested the game and programmed some features.
• Timo Tuomaala and Antti Mustakangas helped with testing and marketing.
• Maija Koivula helped a bit with concept design.
• I programmed the game and created most of the menu graphics. I was also project manager and coordinated the design process.
• We all participated in designing the game.

Technologies I Used

• Java, Swing

Designing a Political Game

The game wasn't very difficult to code (though optimizing Swing for various platforms turned out to be surprisingly problematic). The inspiring challenge was the design. It had to be fun, easily accessible, and - about politics.

A parody was the obvious choice and we took it. In the game, Kasvi stands on the steps of the parliament building, using a megaphone to shoot down bad laws that fall from the sky, while letting the good ones fall through. The good ones are, of course, the ones supported by Kasvi and the bad ones the ones he opposes.

I believe that especially in a project like this, where you don't have a horde of earlier similar games to base your design on, it's important to do the design as a team. For one, you have to come up with a lot of novel ideas. ("What elements of politics are funny? What should we include?" "I know, how about the 'group whipper', the one who looks after party discipline? She could hit Kasvi with a whip!") On the other hand, you have to weed the bad ones out. ("What do you mean a 'Black Hole of Ignorance' is too obscure?" - I'm glad that early favourite of mine didn't make it into the game.) I think we did a great job and ended up with a good set of game elements that both enhance the basic gameplay and are thematically appropriate.

Even though it didn't save our country from the disaster that was the 2011 election, this was one of the most fun game projects I've been involved in.

Commission Work

Summary

Apart from Unfinished Business, which I still occasionally work on, my first years as freelancer consisted of smaller scale jobs, mainly for the iOS platform. I would get my jobs from the Unity forums, do the job, and get paid either hourly or on a commission basis. Most of these jobs were prototypes and/or are still unfinished due to various reasons, hence the limited number of samples.

Technologies I Used

• Unity Pro, iOS addon
• iPhone, iPad
• various plugins

Mobile Platforms

When I began freelancing, I had never worked on any mobile platform. I didn't even own a device that could run anything more complex than Snake. So I was pretty unprepared for working in such a limited environment. Suddenly, you couldn't just create and trash new objects all the time because that eats up CPU. You had to carefully consider the necessity of every little piece of graphics because of memory limitations. You jump through a number of hoops just to get your draw call count as low as humanly possible. Add to that Apple's convoluted provisioning system, Xcode's mystery errors and seemingly random crashes and performance fluctuations...

So it's a pain, but then again, there are few moments as nice as finally playing your game on your device, and it's running absolutely smoothly. And strangely enough, that usually does happen eventually. And even the optimization itself can be rewarding, as I've always enjoyed a good puzzle - the ruling out of each potential cause until only the answer remains.

It does have its plus sides too. I find the touching / accelerometer interface interesting and inspiring. I'd like to see more games that take full advantage of the accelerometer, where things always fall according to real gravity, for instance. A Lemmings style game where the puzzles are based on turning the device as much as assigning skills. Maybe one day I'll do something like that myself.

Example Games

• Apple iBasket (first version)

Unfinished Business

Summary

On August 2009, I took my first steps towards being a freelance game developer. On the Unity forums, I responded to a request to create a script for a puzzle where the player needs to press a bunch of buttons in the correct sequence. That was only the first of many scripts for Don Gray, and the start of my freelancing career.

Even after working on and off for almost three years, Don has remained secretive as to the exact nature of his game. It's definately an adventure game, played in 3D, and the screenshots suggest a somewhat surreal style. Judged by the puzzles he has ordered, the puzzles rely heavily on pushing buttons, rotating things in correct order, etc, although traditional item based puzzles are also present.

There's a video with Don describing his work with the scripts here.

Technologies I Used

• Unity Pro (PC/Mac)

Freelancing Challenges

I had of course used Unity for a couple of years at that point due to Lies and Seductions. However, there were still many things left to learn about Unity and working on an actual professional basis. Special challenges were caused by the fact that I was providing the scripts but it was Don who applied them. Firstly, I had to make the scripts easy to use and the inputs understandable, but I had already grown decent at clarity. More importantly, even though we often discussed the requests at length, I could never know (and I still don't) how exactly Don was going to use the script. So when testing my script, I couldn't just test them in the context it was used, but also try to think of all the possible contexts in the first place. Plus, Don always seemed to have new ideas on how to use the scripts, different puzzles that needed just one extra feature...

In Don's case, I was lucky to get an agreement of hourly payment, because as I discovered in other projects, my ability to estimate the time required for a task was as lacking as I imagine it's for most programmers. Sometimes I could implement several features in an hour, while at other times I might spend days on a particularly tricky problem. This is amplified by the fact that the clients don't always quite know themselves what they need.

Lies and Seductions

Summary

This is my Master's Thesis project, done as part of Petri Lankoski's PhD project for the Medialab in University of Art and Design Helsinki. It's an adventure game about romance, focusing on social interaction with computer-controlled characters. The player is Abby, who's made a bet that she can seduce a Christian rock singer. To succeed, she needs to work her way into his social network, manipulating his friends to help her. The game is based largely on dialogue, with some minigames thrown in. At the core is the Impression System, a memory and personality model that determines what the NPCs think of Abby.

The game is freely downloadable here. There's also a video (by Petri Lankoski).

The Team

• Petri Lankoski acted as creative lead, participating in many tasks such as concept design, game design, writing and programming.
• Raisa Omaheimo developed the basic story and characters and wrote some of the cutscenes.
• Mike Pohjola wrote most of the dialogue and story content, and helped develop the dialogue editor.
• Niklas Gustafsson designed the 3D characters and modeled and animated Abby.
• The other characters were modeled and animated by Reettakaisa Neittaanmäki, Linda Kronman, and Anne Parkkali.
  
• Kimmo Karvinen designed and modeled the scenes, and made the UI graphics.
• Jari Suominen made the music and sound effects, and did programming related to that.
• Josie vd Stel proof edited the dialogue.
  
• I focused on game design and implementation, developing the personality model and the AI system, and did most of the programming and building work. I also created a dialogue editor, and participated in the writing.

Technologies I Used

• Unity 3D engine and development tool
• C# for scripting
  
• Java for a dialogue editor (Swing, XML, DOM)
• Pathfinding algorithms (Navmesh, A*)
  

The Impression System

I'll go into a little more detail about the Impression System now, since it's my most important contribution and the topic of my Thesis. It was a bit of an excersize in wheel reinvention - I realized later that Chris Crawford's Storytron (www.storytron.com) uses a similar though more complex version of it.

The system models two things: the memory and personality of the NPCs. Both are centered around Abby: what they've witnessed her doing and what they think of it. From this, an overall attitude score is calculated. This is how it works:

The NPCs estimate Abby according to a specific set of characteristics, called impressions. There are twenty impressions altogether, such as: Religious, Slutty, Lesbian, Rich, Intelligent, Exquisite... Whenever Abby says or does something, all NPCs in the vicinity adjust their view of her: for example, flirting with someone will increment the Slutty impression in those who witness it. The impressions can then be directly referred to in conversations (the NPCs might, for example, discuss how slutty they think Abby is, or directly critisize her). They are also used to calculate the general attitude the NPCs have towards Abby.

This is where personality modeling comes in. Each NPC has an opinion about each impression, reflecting if they like or dislike that quality and how strongly. For example, Chris loathes slutty girls while Lord James loves them. The overall attitude, determining general reactions, is calculated as follows:

Attitude = impression_1 x opinion_1 + impression_2 x opinion_2 + ... + impression_N x opinion_N

Improving the attitudes of the NPCs by giving the right impressions to the right people is at the core of the game's challenge. To seduce Chris you need to improve his attitude to the level of love, and attitude is also important in getting his friends to help you.

I think the impression system works pretty well, though there are some oddities, and a lot of tweaking was needed to balance the game of course. It's certainly an improvement to the single-value system used in Meren Vangit.

Working with Unity 3D

My second major contribution involved learning the Unity 3D engine and game development environment (unity3d.com). Its features are most directly applicable to developing 3D action games with physics modeling, so we had to do a lot of scripting of our own to implement the feel and style of an adventure game. Nevertheless, it was definately useful, significantly speeding up the development.

Besides that, there was also lots of tweaking and bizarre problems to solve. We used Softimage XSI to create the models and animations, and importing via the .fbx format proved tricky: sometimes our characters looked less like people and more like aliens from outer space, reflected in one of those funhouse mirrors. Genuine bugs on our part also caused amusing effects: the characters had the tendency to float around in their chairs for instance, or wave full glasses of bear around when walking or talking. Suicide by bad pathfinding was also a common occurrence. Fortunately, we got most of that stuff out by the release. (Not all, though: Probably due to some compatibility issue, there's some annoying graphical bugs on some video cards...)

In addition to using Unity itself, I learned countless little things of course, in both game design and programming. One of the most interesting, and rewarding, field was pathfinding. Using the A* and navmesh techniques, the paths the characters take just look so wonderfully smooth and natural. Performance optimization was an interesting topic as well: minimizing the number of draw calls without sacrificing too much of the artistic quality. (Seems there are a lot of important tricks, especially when it comes to lighting and textures.)

I'm hoping the use of development environments like this will become more commonplace. It seems like a good way to counter the increasing workloads in game development. Personally, of course, I hope Unity becomes big so my skills will be in greater demand.

Cells - Nantes 1944

Summary

Cells - Nantes 1944 was another Medialab project. It's a networked multiplayer game about cooperation, intrigue, and betrayal, in which the players take the roles of Resistance fighters and Gestapo infiltrators in the WWII era France. It's one of my favourite designs so far.

The Team

We had a four person team working on Cells:

• Jukka Liukkonen designed the user interface and created a set of very athmospheric graphics.
• Raisa Omaheimo and Jarno Koponen looked into the era and wrote textual content that made you feel you're there.
  
• I came up with the original idea and implemented the game in Java.
• Together, we brainstormed and designed the game mechanics to make it a thrilling and balanced experience for everyone.

Technologies I Used

• Java GUI programming (Swing, Synth look-and-feel)
• Java network programming (sockets, serialization)
• XML for permanent data (read in as DOM)
  

The Gameplay

The players are divided into two teams, the French Resistance and Gestapo, with different victory conditions. There are a set of targets, such as German military structures, in the game (at the top in the interface). The Resistance tries to destroy those targets while the Gestapo tries to protect them.

To achieve their goals, the Resistance has to work together. For each target, there's a number indicating the strenght of its defences. Only if that many players or more attack the target on the same date, will the target be destroyed. To coordinate, the players have to build a network of contacts, to organize as cells.

The Gestapo players, on the other hand, try to infiltrate these cells, to uncover the dates and targets of the planned attacks. This is possible, because nobody knows on which side the other players are. If Gestapo manages to find out about an attack, they can send troops to protect that target for a day, which will foil the attack.

All of this information is spread in in-game chat sessions between groups of two or more people. The chat is the very core of the game, where a variety of trust games take place as the players try to figure out who to tell what information. In addition to attack plans, they may share their suspicions about others, try to trick spies into revealing themselves... All of this under the constant threat of being listened in by a third party.

To support these core mechanics, there are mechanics for spying on other people's actions, counterspying, and arresting and interrogating other players in Gestapo's name.

The game is all about team play: No individual score is kept. Instead, each player collects points for their team, be it Resistance or Gestapo.

Future Improvements

Despite a lot of people really liking the game concept, it's been difficult to get to play it. To play a meaningful game, you need 10-20 players to play simultaneously, seriously hampering the game's success. In order to fix this, I'm planning to recreate the game as a slower-paced web game, developed on the Java EE architecture. Games will last for days or weeks instead of hours, and real-time chats will be replaced by exchanging messages. Some of the mechanics, especially on the Gestapo side, will probably also be tweaked. The core gameplay, however, will remain the same.

Keiju ja Kummitus (A Phantom and a Fairy)

Summary

The Phantom and the Fairy were two projects done for a HUT course, in which we made digital effects for the stage. They're both virtual characters whose visuals reflect the changes in the voice of the voice actor.

The Team

• Teemu Mäntylä invented and programmed the Phantom character, and played the cello during the show.
• Lauri Puska sang some opera as the Phantom.
  
• Toni Laitinen invented and programmed the Fairy character, and directed it during the show.
• Elina Teppo did staging and propping and voice acted the Fairy during the show.
• Ville Häkkinen did programming on the audio analysis side.
• I wrote the Fairy's story, did propping and other practical arrangements, programmed the Fairy's background, and played the painter during the Fairy show.

Technologies I Used

• GIMP to create the Fairy's background elements
• Pure Data to program the Fairy's background
• Audio and video playback systems in the Odeion Hall (at HUT)
  

The Phantom

The Phantom is the ghost of an opera singer who only exists when he sings. We filmed Lauri, our singer, in real time off stage and projected his image on a canvas next to Teemu playing his cello. The louder the ghost sings, the less transparent he appears.

The Fairy

The Fairy is a sparkling sphere of light that lives inside a painting, flies around and talks to the painter. The show consisted of the painter (played by me) and the painting projected onto a blank canvas. The painting changes as the painter and the Fairy take turns to paint items into it. The Fairy, controlled in real time by Toni and voice acted by Elina, is projected into the painting, flying around the items. The louder Elina speaks, the brighter the Fairy is and the more she sparkles. She also has three emotional states (changed by the push of a button): yellow for happy, blue for sad, and red for angry. The short dramatic arc ends with the Fairy painting a gun and shooting the painter.

Inside a Live Reptile Tent

On fall 2006, I took a minor subject in University of Art and Design Helsinki, Medialab department. I took a variety of courses, from drama theory to game analysis and design, learning a lot of new things and getting some much needed perspective. But the big production course, Inside a Live Reptile tent, from January to March 2007, was by far the most intense.

The Course

The course was directed by Teijo Pellinen, Chris Hales, Pipsa Asiala, and Jouko-Thomas Kleine. I could say a lot about the course arrangements (and I did) but that's not the topic of this blog. Let's just say it was a learning experience for us all, in lots of different ways.

The objective was to create a stage show that uses interactive audiovisual elements. The actual contents of the show were in a flux for most of the course's duration, but we ended up playing with the themes of death and motifs of fire and water. It was a two-month intensive course, during which we had little time for other studies and activities.

We began by doing some excersizes and brainstorming, then split into groups based on individual interests. I ended up in the groups dedicated to story and the dramatic arc of the show, but ended up doing lots of different things in the end. In the following sections, I'll describe a few of the more important sub-projects I was involved in:

The Fireman's Miniroom

In the story, there was a fireman who suffocated in a burning building. In the show, there was a small, dark room the audience would enter with flashlights. They'd point them at various items from toy firetrucks and burnt-down chairs to the body of the fireman (me!). This triggered images, depicting the events leading to his death, to be projected on the wall (images created by the very talented Diana de Sousa).

So, I got to play with light sensors, two Arduino boards, lots of wire and duct tape, and Macromedia Director. I had only used wire and duct tape before, but after five hectic days on site, it all worked together smoothly. Of course, when the D-Day came, way too many people entered the room and once, practically flooding it with light and rendering the whole interaction moot. Oh well.

The Black River Arcade Game

In line with the ever-mutating story, I programmed a small Java game, in retro style, depicting the fireman and a swimmer on the Black River. I used the same arcade game base code as in Lemmings Remake and A Dog's Job.

It's a two-player collaborative arcade game: The swimmer tries to swim upstream to a raft, avoiding dangers brought down by the currents (logs, zombie crocodiles and black swans). The fireman, standing on the raft, tries to destroy these dangers with his axe. Extra complexity is added by the varying speeds of the currents, forcing the swimmer to swim sideways to slower currents or be swept away.

The graphics are by me, except for the swimmer, who was created by Katarzyna Miron. The sounds were provided by Antti Mäki.

Staging and Propping

In addition to my main projects, I ended up doing some staging and propping work, mostly for the fireman's room. For this purpose, I frequently visited the prop room, a wondrous collection of... things (I don't think there's a narrower category to encompass that all). We also went a bit pyromaniac with some old furniture to create an atmosphere of a burning building, and borrowed a real fireman's suit from the fire department. In addition, I helped with some sewing as well as hanging cheap flashlights from the ceiling.

Random Ideas

During the production process, there was a lot of brainstorming and cool ideas, but unfortunately most of them never saw the light of day (or, well, the darkness of the stage but anyway...). Here are a couple of mine:

• Divine Discourse: An installation entered by one audience member at a time. There's an altar with a pillow in front of it. Under the pillow, there's a pressure sensor connected to a computer, connected in turn to a hidden speaker. When the audience member enters, a voice of a goddess starts to speak, demanding they kneel down before her. If they refuse, the demands become more forceful, if they comply, the story takes another direction.
• Interactive Instruments: There's a live stage performance and some instruments the audience can play (no skill needed to make strange sounds). Some of the instruments make sounds of harmony, while the others represent discord. The actors adjust their performance based on which instruments are played more.

Meren Vangit (Trapped by the Sea)

Summary

An HUT project, Meren vangit was my first serious attempt at interactive storytelling. It's a branching-structure adventure story set in the age of sailing. Its outcome is based on the player's interactions with various non-player characters. Graphically, it looks like a book that writes itself based on the player's choices.

The Team

There were five people working on this product:

• Jarno Väkeväinen acted as the project lead and created the UI graphics.
• Olli Katila drew the various pictures on the pages on the book.
• Osku Kannisto composed several atmospheric pieces of background music.
• Jukka Larja did the huge job of both programming the game and implementing a scripting language I used to write the game.
• In addition to coming up with the concept, I designed and wrote the story.

Technologies I Used

• Special, XML-based scripting language developed for this project.
  

Story Overview

The player takes the role of the captain of a small vessel that's trapped, through powerful magic, in a small sea area consisting of three small islands. He must travel between those three islands, interacting with their inhabitants, and find a way to reverse the spell. During all this, he must make sure his crew stays loyal to him.

The Crew

In order to keep his crew loyal, the player needs to understand their personalities. This creates the true challenge of the game. The members of the crew are as follows:

• Phileas, captain and the player character
• William, a brave, stern, and snobbish first mate
• Humphrey, an old and experienced boatswain who doens't like being bossed around
  
• Elmer, an old and superstitious carpenter
• Benjamin, a self-learned Native American doctor who prefers the scientific world view
  
• 
• John, a charming and flirtatious sailor
• Horace, a cynical sailor fed up with sea life
• Edmund, Horace's romantic son
• Hutch, a mean spirited sailor who listens only to force
• Alice, a strong-headed stowaway
• Emil, a young and incompetent cook looking for appreciation
  
• Jim and Jesse, two fearful, thieving ten-year-olds
• d'Argenlieu, a contemptuous noblewoman booking passage on the ship

Progression

The player spends most of the game traveling between the islands, having adventures on them, and interacting with the crew. The islands are as follows:

• Lost Colony, a townful of people with European origin
• The Native Island, a jungle island with a Native American tribe
• The Desert Island
  

The player can freely travel between the islands. On each island, there are adventures to be had and choices to be made. Eventually, these adventures lead to uncovering the mysterious spell and the means to its reversal. The choices the player makes during the adventures affect the loyalty of the different crewmembers. For example, on the Native Island, Hutch semiaccidentally insults the natives: letting them punish him pleases Benjamin but displeases Hutch and also William (who considers the natives less worthy).

In addition, there are shorter pieces of story, picked semi-randomly from a pool, that take place during the voyages between the islands. Each of them describes some kind of a problem (such as a storm) or a conflict between the crewmembers (such as William and Humphrey disagreeing on maneuvers). The player's choices during these, once again, affect the loyalty of different members. (Chris Crawford calls these "interstitial stories" in his book Chris Crawford on Interactive Storytelling.)

Finally, as the player attempts to lift the spell, the group is drawn into a magical dream reality that draws on their personalities, tempting them to disobey the captain for different reasons each. Good relations with the NPC, as well as good understanding on their personality, are the key to winning these confrontations. If large enough number of the crew come through these trials still loyal, the spell is lifted and the journey can continue.

Lessons

Based on the theory that you learn best from your mistakes, this was a giant step towards my enlightenment. Here are some of the lessons I learned:

• Don't bite more than you can chew. 13 interactive characters and a wide-arcing storyline with magic, adventure, racial issues, social conflict, and romance is a little too much for 5 credit points. All the characters ended up with skeleton stories, with far too little for the player to base character understanding on. The plot moves ahead similarly quickly, with little attention paid to detail or refinement.

• If you don't have time to do your research, stay clear of historical settings.

• Sometimes simple is just simple. The personality model of the crewmembers is very simplistic: they have only one number to describe their attitude. This number is adjusted manually for each crewmember whenever the player does something meaningful. It'd have often made sense to distinguish between, say, frienship, respect, and fear (punishing someone, for example, causes fear but loses frienship). In addition, I had to manually adjust all 13 NPCs in lots and lots of places, which soon became tedious.

All in all, it was a good learning experience, with lessons I've already used in the development of Lies and Seductions. Interactive storytelling is a very interesting line of study, and creating this game only made me more enthusiastic about it.

Airhockey

Summary

This game is a project on a computer graphics course. It doesn't look too impressive, because it's just an excersize in using various OpenGL features. Nevertheless, it's worth a mention here, since it gave us insight into the workings of computer graphics on a low level of abstraction.

The Team

• Toni Laitinen came up with the concept and did programming.
• I also did programming.

Technologies We Used

• OpenGL
• C
• Pair programming (which I found worked well because there were a lot of things neither of us had never done before)
  

Triple Trouble

Summary

This is a little course project we did in Flash. It's a very simple adventure game about a set of triplets who get abducted by aliens and have to use their identical looks to escape. I'd have liked to create a full adventure using the concept, but due to the project's scope we ended up with a simple, slightly interactive cartoon movie.

The Team

• Rogemond Nicolas did actionscript programming and documentation.
• I did actionscript programming, wrote the script, drew the graphical elements, and animated the characters.

Technologies I Used

• Flash
• Actionscript

A Dog's Job

Summary

This game was created as part of a course on multimedia programming. It's about the life of a sheep dog, dutifully herding his flock and protecting them from predators. The player's task is to drive a group of idly wandering sheep into a den, while keeping wolves away from them, his presense and voice his only tools.

The Team

A team of three was involved in making A Dog's Job:

• Riku Björklund programmed the game logic, using my basecode for arcade games (first used in Lemmings Remake).
• Jukka Larja programmed the AI of the animals, using e.g. flock AI algorithms to make the sheep move nicely as a group when not disturbed.
• I created the graphics and animations.

Technologies I Used

• GIMP (open source drawing software) to draw the terrain and animations
• Java-based animation viewer to run the animations
  

Gameplay

The gameplay is simple: The player moves the dog around and barks as necessary. When not disturbed, the sheep wonder around as a flock (using flock AI), looking for grass to eat, while the wolves try to make a meal of them. If the dog approaches, both the sheep and the volves move away from them - by barking he can chase them faster and from longer distance. If he can drive the sheep into a den without getting them eaten, the dog wins. Terrain considerations add some complexity - the sheep can't go into water or forest, while the dog and the wolves can.

The Animation

I used the same, simple animation method that I'd used in Lemmings Remake, to create the different animals: frame by frame, arranged in a grid in an image file. I find I enjoy doing pixel animation in the old-fashioned way quite a lot. Fiddling with the minute details is relaxing, but since the characters are small and the animations short, it doesn't take too long to make. (As a side note, I modeled the running animations of the dog and the wolf on the closing theme of the anime series Wolf's Rain.)

Teach a Dog

Summary

This is a little Java excersize I did on a simple learning AI. You train your dog by giving them commands and then rewarding or punishing him for his behavior. The commands can be anything you like, though the dog can only perform a limited set of actions. In the beginning, he responds to the commands randomly but with time he learns from your feedback. A later version also adds different visitors that enter your house. You can teach your loyal watchdog to greet your wife with a warm lick but drive burglars away with teeth and growl. Train him well enough, and you won't even need to give any commands!

Technologies I Used

• Java

The AI Mechanic

The game is rather repetitive - you just give commands and give feedback. The interesting was to create the learning mechanic. The dog always responds to the commands in three phases, with three options each: bark/growl/be quiet, run/walk/stay put, and lick/bite/do nothing. For each phase, there's a matrix: one dimension for the three options, one for the commands the player has issued so far, and one for the different visitors. The values in this matrix represent the desirability of each action with each command/visitor combination. When a visitor arrives and a command (optional) is issued, the dog finds the action with the highest value for that combination (with some random variation added) and performs it.

If the dog is rewarded, all the desirability values related to the selected action are increased, making him more likely in general to perform that action in the future. This way you can develop you dog's general nature into a specific direction. The desirability values related to the action combined with the command or the visitor are increased more, however, making the dog more likely to respond to that command and that visitor with that action in the future. The opposite is true for punishment.

I played with the idea of making this into a more interesting game, in the spirit of the Lassie stories, but haven't got around to it yet at least.

Lemmings Remake

Summary

I've always been a great fan of the Lemmings games. As a kid I used to draw up my own level designs on paper and have my friends solve them. As I grew more confident with Java, I finally decided to take it a step further.

Basically, it's Lemmings 1, with the original eight skills, but with my own graphics, animations and level designs. I also included fast forward and highlighting from the sequels for better playability.

Technologies I Used

• Java (Swing for graphics)
• GIMP to create the levels and animations
  

Charting New Territory

This was the first real-time graphical game I've created, so I had a lot to learn about drawing in Swing and working with the frame rate. And, of course it was my first attempt at pixel animation, which I think worked out great! I used a primitive but functional method of laying the frames out on a grid, then separating them in the program.

For future use, I created a generic package that handles the real-time updates and animations in games like this. I've used it in a couple of later games. It could use some performance optimization, though...

Guardian Angel aka MMOCGRPG

The acronym stands for Massively Multiplayer Online Character Graphics Role Playing Game. It's an engine for, well, character-graphics-based MMORPGs by Mikko Rasa. I worked on designing a ruleset and a world to be built on that engine (called Guardian Angel). Unfortunately, both the ruleset and the world were far too ambitious for our skills and resources for that time, and even the engine never got finished. I had some fun, however, creating the world as well as some cool ASCII art.

The Team

• Mikko Rasa came up with the idea and built the engine.
• Viljami Lappalainen helped us design story, gameplay, and the ruleset.
• I designed the game world, and created ASCII art.

Neverwinter Nights

Summary

When Neverwinter Nights came out, I too took my chances with the Aurora editor that allowed players to create their own worlds and adventures. I never finished any of my projects, but I tried out a lot of concepts, tried to accomplish a lot of effects with the scripting system, and learned a lot about designing game stories and scenarios. In my designs, I focused less on combat encounters and more on creating an interactive story with meaningful choices.

Technologies I Used

• 

  NWN Aurora Toolset (including scripting)

Three Virtues

Three Virtues was the project I got the most results in. I wanted to create a story about the conflict between three virtues, represented by three guiding spirits, called Aeors. The player chooses one at the beginning, and then gains supernatural powers related to its virtue. Whether the player manages to live by the virtue he selected, determines a great deal of the final outcome of the story. The virtues I chose were Courage, Wisdom, and Love (similar to the three principles, Truth, Love, and Courage, in Ultima IV, as I later discovered).

I really liked developing the story and characters and writing dialogue trees, as well as scripts that made the story progress at a nice pace. I was surprised to find, though, that I also enjoyed building the physical aspects of the world: adjusting the color of the sunrise, adding frog croaking into the stream, creating different people, their looks and clothing... It was just enthralling to see my vision of the little agrarian village come to life, bit by bit, detail by detail. I also became quite obsessive about getting the music right, finding themes for the different characters, fading one piece into another in the middle of dialogue to support the advancement of the story.

I only completed one small chapter of the story that was to become a truly epic arc. Nonetheless, good practice and an even better experience.