Also, if you want to read the short version of my gibberish, scroll down until you see “Concluson” written in big letters . As the title suggests, it concludes the previously written text in a handy set of bullet points.

So, sit down, have a tea and let me answer following questions:

• What went wrong?
• What went well?

What went wrong

Just to make it clear: Big Time Monkey was a success. It even surpassed our expectations. However, there are always things which could have been made better for the sake of optimization. Those things are mentioned here.

Workload

For three people Big Time Monkey was a hell lot of work. In our first meeting in October 2010 we recognized that four months were far too short to realize all our concepts. Also, most concepts were not written, yet. It was clear that we had to cut away a lot of stuff if we wanted to finish the game. And still, it was not enough. We did not finish the final game in time. But we managed to deliver a demo version of the game and present it at the MediaNight.

Product Language

Big Time Monkey is a German game. That’s good for Germans but not so good for the rest of the world. We would have increased the number of people playing our game by making it international. If we’d had developed the game in English it would have increased the audience drastically.

Then again, we had not enough experience to write all the jokes and wordplays in English. And finding professional native speakers who fit the characters in the game and did not charge a cent for a day in the recording studio would have been impossible. So actually we had no other choice. The game would not have the same quality if it had been developed in English.

Technology

We have chosen Visionaire Studio to develop Big Time Monkey. It helped a lot and it took away much work from us. But as every technology it needs to be evaluated and understood properly before it can be useful in its whole extend. We didn’t use features of Visionaire which would have made our lifes much easier simply because we didn’t know they existed. For instance: We didn’t know about the debug console inside of Visionaire’s testplayer until I discovered it by accident… after the release.

Visionaire also had it’s own bugs and problems (like every software) we did not encounter until we used an affected feature. Some of those problems were not documented by the developers of Visionaire. Some I believe weren’t even known at all.

To mention an example: We used certain types of actions (provided by Visionaire) to trigger voice-over playbacks throughout the entire game. In the Testplayer of Visionaire  those voice-overs were played correctly. But in the release build of the game those voice-overs did not play. It was a bug in the deploy function of Visinaire Studio. This bug has been discovered by another user of Visionaire about one week before we encountered it. He reproted it in the Visionaire forum. The developers fixed it but the fix would have been applied in the next release of Visionaire which was one month in the future. But we had our release date in two weeks. So we had to sit down and apply workaround solutions in the entire game. We had to move all affected actions into another area. But the Visionaire GUI did not support copy and paste for list of actions, only for individual actions. This has worsened the entire situation. We had to copy one action at a time, navigate though the whole GUI, paste it, go back and proceed with the next action. It was quite an ordeal.

Another point was platform dependency. I’m a PC guy, it was ok for me that Visionaire was a Windows-only solution at that time. But we have a lot of Mac users walking around at our university who were quite interested in the Big Time Monkey. I ended up putting all of them off saying it would be possible to play the game on a Mac in a distant future. And I didn’t like that. I wanted to see as many people as possible playing our game.

I’m still struggling with the thought of developing an own engine for Big Time Monkey. But then, I’m sure it would have meant much more work which would have resulted in an unfinished product.

Legal Stuff

One month after we released we were contacted by a games magazine. They wanted to release our game on a DVD with their next issue. That was a big deal for us. But it included signing a license agreement with them. The problem was, I was not the only one who owned rights on Big Time Monkey. There was one musician and six voice actors who owned the rights on their individual parts because we didn’t sign any contracts with them. It was a student project and nobody had seen the necessity to do this. We had to cantact each of them in retrospect to obtain their permissions. Next time I would handle such things in advance.

What went well

Quite a lot! To begin with: the constelation of the team.

Team

I would have never expected that the three of us would complement one another so well. Frankly, I expected tensions inside of the team at some point in the project progress. Not because I thought the team members were tension prone but there are always some sorts of conflicts and misunderstandings among people. Maybe two people want to take the lead at the same time or somebody is unsatisfied with the work of another team member. But not in our team. Everybody was in charge in the same way. Every decision has been talked over with the team and in the end everybody was satisfied with the result.

Why? The first advantage we had: we were a small sized team. So this is about the upsides of a small team. You don’t have to introduce complex structures. The probability that two individuals conflict is much lower in a group of three people. It is easier to stick the heads together and sort things out. It’s easier to define milestones and come to an end with a discussion.

Last but not least we were lucky. Somehow we were a good match. Each of us is open to criticism. Nobody tried to force through his own ideas and contributed constructively to the product. This is not always the case and it is almost never controllable what type of persons come together to accomplish something. During the development of Big Time Monkey I’ve heard of other student projects which suffered of problematic team constelations.

Conception

Our conception phases were fun. And that’s the point! If you have fun doing your work you most certainly to it right. It was like sitting at a round table and throwing hilarious ideas and catchphrases at each other trying to make the other laugh. And if they laughed you knew it could work. If not, you tried at least and maybe you inspired a similar but working idea. Of course, we always had to take our time management into account. But the best ideas emerged from such discussions.

Also, during work it occured that one of us stuck his head out and came up with something the others had to evaluate. If it was good, it has been included into the concept.

Beside brainstorming, we had to record and structure our output somehow. So we used a graph to visualize the scenes of the game and how they were connected. Marius who was mainly responsible for story and concepts maintained all concept documents and wrote dialogs. He used simple screenplay writing for static dialogs and flow charts for interactive ones.

Voice Acting and Music

It really paid off to take some time searching for voice talents. Our first thought was to do the voice overs by ourselves but now we are glad we didn’t do that. It would have destroyed the whole experience. The voice actors gave a fair amount of depth to the characters in Big Time Monkey. They also incorporated own ideas into the characters and made them more alive.

The first people we were casting for character voices were professionals who did moderation, ads, documentaries etc. We quickly realized that we need real actors… like in theatres! And after some searching we actually found people who were able to understand and impersonate a character. Especially Torsten who did our main character Gordo was a perfect match.

Marius knew everything about every character in the game. Even stuff which is never being mentioned in the game. He developed elaborate background stories and played with stereotypes to add depth to them. Most characters in the game have less then two pages of dialogue. But they were so well developed that those lines sufficed to transport their depth to the player. Marius’ knowledge about every single fictive individual inside of But Time Monkey made him an essential source of information and inspiration for each voice actor.

As for the music, well, that was another case of luck. I don’t know how Marius found our musician and sound designer Ingmar. But what I can tell is that the process we established between Ingmar and the rest of the project was a good one. At first, we described the moods of the different scenes in the game as good as possible and provided mood pictures to Ingmar. He then came up with some demo bits of music and athmospheric sound and we told him what to change. It was quite straightforward.

Conclusion

Here come the promised conclusive bullet points:

Workload

• Always define milestones. Having the roughest plan helps.
• Get sure to have enough people to get the work done in time or cut the concept down to the essential parts
• Try to get stuff done on a regular basis; one small finished piece a day. It’s not easy to have a constant productivity level but once established it’s one of the most precious things you can have in a project.
• Getting things done and presenting progress to the team increases overall motivation and thus productivity.
• Grant yourself breaks! You won’t come far when you’re overworked.

Product Language

• If you want an international product do it in English first.
• If your English isn’t good find somebody whose English is good and who would understand your project (and your humor if necessary).
• A bad translation of your game can destroy the whole game experience.

Technology

• Know the technology you’re using.
• Build prototypes to try out features and workflows.
• Familiarize yourself with the technologies documentation.
• Never use undocumented technology.

Legal Stuff

• When working with external contributors, always work out some sort of contract to define who owns which rights over the product (even when the product will be free of charge)
• Even if you intend to do a non-commercial product, think about the sitiuation when your product gets commercial; just to be prepared. There are many legal cases where a free product becomes commercial without the creator having thought of it (e.g. release on a print magazine’s DVD)

Team

• Try to keep your team small as long as it is able to get the work done.
• Don’t make your team too small. Recognize when you need another pair of helping hands.
• Meet your team on a daily basis.
• Try to be on a par with everyone. Show respect.
• When working, try to sit close to each other (e.g. not in seperate rooms).
• Always know and understand what the others are working on and inform them about your own work. That’s good for both motivation and organization.

Conception

• “Kill your babies”: throw away ideas which you can’t convince your team members of, even if you think “this is the best idea i’ve ever had”. Maybe your team members have a different point of view on things and see weak points you don’t see. Also, if your team is not convinced of an idea it most probably won’t be satisfied with the implementation.
• Cut parts of the concept away if you realize you won’t make it in time. Even if the parts of the concept were promising.
• Try to understand how ideas of your team members work. Listen to them! Give them a chance to convince you! You’re not the only creative mind in the universe.
• Express your doubts, but do it politely.
• Discuss details. It’s good for the product and for the motivation. But always return to the big picture.

Voice Acting and Music

• Never underestimate voice acting. Trained people are always better than laymen.
• Prefer actors. Professional speakers are ok as long as they can act (e.g. change their voice, impersonate characters)
• Choose your main character’s voice very well. An inapropriate voice can annoy players and make them quit the game after the first few bits.
• Know your characters well! You need to understand them and how they actually think.
• Know the mood in your game. You need this knowledge to choose the music. Without the music the mood will remain in your head and never reach through to the player. Music is a very important and often underestimated component.

It’s finally done. We’ve put a lot work into this and the last fixes and polishing were really painfull. But what hurt the most was the delayed release date. Sorry for that! The game was praktically finished by the end of February but we still had to clean up a lot of stuff.

I also talked about the creation process of Big Time Monkey on the 9th GamesDay at the HdM Stuttgart (“talk” like in “presentation” ). You can see the talk as a video stream here (unfortunately only in German): Games Day – Big Time Monkey

But the most important thing is: You can download the game right now, here.

Go and have fun

Last Thursday the MediaNight took place at the HdM Stuttgart. There we presented a first playable demo version of Big Time Monkey and we got quite good feedback. The project has also been approved and it got very good marks. We want to finish the game by the end of February.

Additionally the mini page of Big Time Monkey is online. This is where you will be able to dowload the game end of February: www.bigtimemonkey.de

We want to thank all those directly involved in the development of Big Time Monkey:

Ingmar Jännsch (music)

Torsten Helber (voice actor: Gordo)

Dolores Winkler (voice actress: Dr. Dröge, barkeeper Ulla)

Alexa von Busse (voice actress: till girl Yvonne, girl Vanessa, wife Beate, computer LISE)

Benjamin Janssen (voice actor: crook Nagel, barber Blumstingel, hippie Berger, intern Chris)

Ronny Krause (voice actor: Market Manager)

Kathrin Meier (voice actress)

We are totally pressed for time. That’s why I’m just posting a short list of key points describing the progress of our apish student project:

• intro sequence done
• first three rooms completely playable
• half of all dialogues finished
• half of all backgrounds drawn
• all characters designed and animated
• voice actors chosen and appointment made with recording studio

We are all looking forward to see the finished piece.

No time for talking, must go on working…

Yep, I commited myself to another game project. Doesn’t this guy have enough stuff to work on, you might think. Indeed I do. And yes, I shoud finish some of my work-in-progress-projects first. But unlike all other of my projects this one has a fixed deadline in January 2011. So either it’s done till then or it’s a failure. And I’ll get marks for it at university, so there’s actually something at stake.

What’s it about? It’s a point-&-click-adventure again. It’s a little game about a monkey saving the world from the evil plans of his former mistress. The working title is “Big Time Monkey”.

It wasn’t me who initiated it. There where two other students at my university who wound up with a lot of creative ideas and I chose to join them. So there are three of us (maybe a fourth coming making some music): Marius, creating the story, the concepts and puzzles; Melina, doing character design and animations; and me responsible for project management, background art and the technical part.

It’s fun working together and I hope we will get all this work done in this short time.

Another source of inspiration I’ve spottet a while ago is a comic by Scott McCloud: Understanding Comics — The Invisible Art. It’s a fairly famous piece of work and it’s not an ordinary comic at all. It is a comic about comics.

Scott McCloud explains inner workings and phenomena of the comic art form and proves his explanations by applying them at the same time. During his explanations he delves into the topics of psychology, art history and effects used by comics, for example immersion, iconography and closure.

A very interesting and inspiring read which I already recommended some of my friends. Most of the concepts presented in this book are also applicable outside of the domain of comics.

There is a game which caught my attention on the topic “art games”. The size of the game is only 1.8MB (extracted, SDL.dll and Readme.txt inclusive) and it’s called “Passage” by Jason Rohrer. You could think that I’m talking about one of those 64k demos from the demo scene showing mind blowing polygon- and light acrobaticts.

I’m talking about something totally different.

Passage has a resolution of 16×100 so the graphics are humble but fitting. And a nice midi score is playing in the background.

But firstly: what is an “art game”? Art Games are not a specific games genre. The term is as controversial and subjective as the term “art” itself. That’s why I’m not going to disambiguate this any further. I’d rather want to introduce this topic with the above mentioned example “Passage”. But before you read on, you should play the game yourself first. I promise you, it won’t take long. You’ll have “made it” in five minutes.

Played through?

Fine, so I can’t spoil the first impression by writing down my thoughts on this game (at least, I warned everybody who reads this now).

Most people will ask questionts like: “What’s so special about it? It’s just moving around in a pixelated world! Where is the fun part?”

Most people think, games are supposed to be fun. Sure, games have to be fun, otherwise they would not be games, would they? Fun is the major purpose of games. Games are defined by Fun.

Now let’s look at humor. Jokes for example. They are supposed to make people laugh. But each joke is funny for a different reason. There are dirty jokes, intelligent jokes, dry jokes, nonsense jokes etc. and some jokes are very difficult to understand. In some cases jokes require a special knowledge to be funny. The sudden understanding of such a special joke amplifies the humor.

The same principle is used in games. The learning and understanding effect of things that are happening in a game world causes fun. For example: why do so many people like to solve puzzles. These achievements seem to satisfy a lot of people.

In Passage this achievment is not done by simply playing through the game. In some ways it’s more outside the game, in the head of the player. The satifaying achievment part happens (as soon as it happens) on a much higher level: by understanding the “punchline” of the game. And this doesn’t need to happen during game time.

The game tries to express something, something like an idea or a particular emotion, a message.

Simply speaking, it’s a metaphor about the progress of life.

You start your life and you see so much future in front of you. At first, maybe you think you can move only in one direction, but you’re wrong. Maybe you meet a special person, maybe you choose not to. Maybe you go with her the rest of your life or maybe you want to be alone and free to go anywhere you want. You encounter big chances (treasures chests) during your way of life. And sometimes you have to go back to be able to move on. You’re getting older and life changes. You see so much past back there in your fading memories.

In the end you lose your loved one.

And when you die, you ask yourself: “What’s the point of all this? Where was the fun part?”

All these impressions, transported in a 16×100 pixel screen, not only through graphics, sound or animation, but mainly through game mechanics!

Never before a game has triggered so many thoughts and emotions in my head.

Understanding this game was a sense of achievement.

There is a little progress regarding Adventures of Jester Chip. Currently I’m working at some adjustments of the existing background images. In the flash version of the game I’ve used an odd 600×300 canvas resolution. Since I decided to make the game in AGS (further details on this coming soon) which only supports standard screen resolutions, I have to improve the background graphics. Leaving black bars is no option for me. The game has to be an eye filling experience

I will use this opportunity to enhance the background images with the possibilities of a 32-bit color palette.