Monday 28 December 2009

Future of Adventure Game Interaction

Introduction
Interactions in adventure games has gone from written input (aka "text adventures") to todays mouse controlled (and often single-button-driven) games. There still exist text adventures though, although now called "Interactive Fiction", and here the complexity of interaction has increased instead of becoming simpler. It seems like the way of interacting has on one end gotten more and more complex over the years, while on the other end it has gotten more and more simplified. What I want to explore in this post is if this great polarization has made us miss out on other ways to interact in adventure games and in what other ways interaction might be possible.


History
Before moving on to the core of this post I need to very briefly discuss the history of interaction. It is always important to know the past in order to figure a way to progress in the future.

The first adventure game created was Colossal Cave Adventure, aka "Adventure", which was built on top of a cave simulator and featured interaction through text commands. After Adventure more text adventures followed and as time went on the parser became more and more advanced. The parser is what handles the text input and translates it into game commands and the better the parser the more synonyms and complex grammar is supported. A few years after the release of Adventure, text adventures started to get a graphics, but still had a the text input (like Mystery House).

The first evolution in terms of interaction was to add third person character and allow movement using the arrow keys. Text was still needed to do actions, but the player could explore the environments more freely (moving around in text adventures can easily become quite confusing). Examples of this type are the original King's Quest and Leisure Suit Larry.

It is important to note that the divide between text and graphical adventures started here. Texture adventures continued to evolve along their own path, getting more complex interactions, while graphic adventures instead started to become more and more simplified. Both types co-existed commercially until the early 90s when commerical text adventure games where pretty much extinct. Text adventures still continued to be developed by hobbyist though and has continued to evolved the entire time (now days called Interactive Fiction).

The next evolution was made in Maniac Mansion by skipping the text input and instead exclusively using the mouse (except for some shortcut keys) and a predefined verb list with words such as "Push", "Open", "Walk to", etc (all in all there where 15 verbs) . To simplify things further objects that could be interacted with had their name displayed when the mouse was over and right clicking carried out a default command (such as "walk to" an empty spot or "look at" a sign). This trend of interaction continued and was further evolved by cutting down on the number of verbs.

The next and most recent big step has been to take away the verb list altogether and restrict the possible actions in such a way that all the user has to do is to click on things that requires interaction. An early example of this is Myst and now days pretty much every adventure game use this system.

An important thing to note is that as adventure games have evolved with the interaction, the unforgivingness (mostly meaning how easy it is to die and get stuck in an unwinnable state) have decreased as well. This is of course due to improved design, but I also believe it has to do with the interaction systems. With more actions, there are also more ways to mess up. Text adventures actually tend to be more unforgiving than adventure games released in the same time period. Although it is certainly possible to make text adventures free of cheap deaths and places where player can get stuck (there are many modern examples of this), but the large space of possible actions makes it more easy to do so. More on this later.


Why simplicity?
The main (and probably obvious) reason for making the interactions simpler, is to make the game easier to play. For example, games like Samorost are extremely simple to get hang of. In text based interaction (especially with older parsers) one quite often ended up in a guess-the-verb- situation and having to pick from a list of verbs can easily become a boring activity. Also, text input requires a bit of knowledge of what kind of actions usually works and which doesn't. This makes text based games harder to get into for beginners.

When using verb lists much of the freedom from text input was lost and interaction could become the boring task of testing every word in the list against every object in a scene. This is similar to the situation of branching dialogs but mostly without without a fun response for a specific combination ("cannot push door", "cannot pick up lawn", etc are quite common). Because of this, just using a single command context-sensitive interaction for each object can even increase the immersion.

Another major reason for simplifying is that it makes the games more laid back to play. Modern graphical adventure games are often quite relaxing and one can easily lie down (or some other comfy position) while playing. Actually, requiring the player to use the keyboard seems to be a hideous crime in some gamer circles. We have even gotten quite a few angry emails regarding the "dated input method" in Penumbra.


Why complexity?
So if having simplified interactions makes adventure games easier to play and more relaxing, why add more complexity? Does the years of evolution from complex to simple not show the right way to go? I confess that this might be the truth, perhaps the current system is the best way to go and further enhancement should be concentrated around making things simpler still (like the evolution has been so far). However, I suspect that there is bias towards simplicity lurking and that the success of some titles have set the path for other designers as well. Before moving on to the reason for me suspicions, I would like to quickly discuss why I think increased complexity is a good thing.

My main motivation for increasing complexity comes from playing Interactive Fiction (ie "text adventures"). As stated before, this genre diverged from graphical adventures almost 30 years ago and has, contrary to graphical adventures, increased in complexity since. By using the rich space of actions provided by words, there is a lot of actions possible that are not possible in graphical adventures. A major feature is ability to use all senses: the player character (abbreviated PC) can "touch" an object hidden from view in order to get more information, smell the air for tell-tale signs of some gas, listen next to a door to overhear a conversation and more. It also allows for more intricate interaction, for example when holding a piece of paper it can be crumbled to a ball, folded to become a container or rolled up to act as a funnel. To include these actions in a modern graphical adventure game they would either have to be special cases (like a folding-paper mini game) or implemented as a default action in some situation (using the door when in cell makes the PC listen next to it). Both of these solutions are forced though and do not give the sense freedom that a text parser would.

Am I suggesting that we should go back to some older type of interaction? No, I am not. What I am suggesting is that instead of improving the interaction by simplification, some other route should be taken. Making a user interface better does not always mean making it simpler. Consider first person movements as an example. The first FPS games like Wolfenstein 3D had really simple controls, with arrows for moving and strafe modifier key for sidestepping. Later on games like System Shock made the controls more complex, adding the ability to look up and down and more. These where then made easier to use in Quake by using mouse control for head movements. Since then controls have become even more complex with leaning, crouching, etc. The controls for first person games have over time become more simple to use, yet more advanced and allowing greater interaction in environment. I think that the same could be true for the future adventure game interaction.


The problem with freedom
So, what should be the goal with interaction in adventure games? The first reaction might be to use some kind of virtual reality suite (or matrix-like brain connection) that can entirely immerse the player in the game, allowing any kind of interaction. I do not think this would be wanted though as a big part of designing a game is actually to restrict the player from doing certain actions. If the player picks up a very important key and then throws it into a bottomless pit, it will probably be very hard for the player to continue. Although a designer can add alternative solutions for situations like this, due to time and resources it will not be possible to add for every possible bad choice the player makes. It is also impossible to find all of these situations during testing, given the huge amount of choice a realistically simulated world would give. Some actions might seem so stupid that player deserves ending up in an unwinnable state, but this can be a really fine line at times (especially for a designer that knows how the game is "supposed to be played").

The problem with freedom is actually a lot easier to control in a modern point-and-click system. When the designer can exactly determine all possible actions, it is a lot easier to make sure that the player does not end up in an unwinnable state or manages to skip large sections of the story. This is a really important bit to have in mind when designing a new system and simply going for whatever gives the most freedom will simply not be enough.

Because of the problems with too much freedom, it might actually be harder to design puzzles for adventure games with high interaction complexity. When designing a puzzle in Amnesia the idea was that the player should open a door connected to rope throwing the rope through a pulley, tie the rope around a rock and then push the rock into a hole, pulling the door up. When doing this with physics as implemented in penumbra it simply was not possible without adding lots of restrictions. The stone should not be possible to push down the hole before rope was in the pulley and tied around it. Also, the rope should not be possible to tie around rock until it was pulled through the pulley. Restrictions could be added to make it work, but would make the game too inconsistent (it would the depend on the situation if a rock could be pushed or not, etc). Making alternative solutions is possibility, but cannot be done indefinitely (especially if the difficultly level of the solutions should be similar).


Future
The problem here is that more complexity is wanted, but at the same time the player must be restricted. How can these ideas be united? I do not have an answer to this, but have at least some ideas in what directions to start looking.

First of all I do not think it would be worth thinking about things that might be possible in the future. This would include things hooking up some device to the players brain or to have some kind of AI in the parser that could understand a wide variety of phrases and respond accordingly. I think it is more interesting to discuss what can be done now or even that which could have been in the past. When it comes to the evolution of first person control, much of it does not depend on technology and could have been implemented much earlier than it did.

A path that might lead fruitful results is the use of predefined verbs. The major problem with this was that they where always visible to the player and easily became an exercise in trying combinations. Text adventures are not far from this kind of interaction, since they too have a set list of verbs, but these are never visible to the player and because of this, they feel more free. So, the idea is simply to add some kind of way to use a certain amount of actions without listing them in view for the player. This can be done using mouse gestures which, if similar to the action performed (for instance: move mouse in a circle to spin something), could be quite intuitive. Even if intuitive, it would take some time to get into and would be far from as easy to pick up as the modern point and click mechanic. A sort of remedy could be to allow combinations of gestures to make more actions, requiring only a few base movement to be learned. An example would be that there was a gesture for each body part and then some other gesture for the type of movement performed. Of course this does not require mouse movements and key combinations is another alternative. Games that kind of use a similar approach are Loom and The Void.

Farenheit (and the upcoming Heavy Rain) has another way to tackle this problem: By having context-sensitive inputs depending on where the PC is. This system works pretty well to add a great deal of possible actions and the additions of "gestures" (this might stretch the definition, as I do not think calling button mashing a "gesture" is entirely correct) can add some simply gameplay and challenge to this. These gestures are quite nice at the start of the game, and gives the feeling of actually performing the action, but later on they get quite arbitrary and feel more like a chore. This system would work without gesture though and could just be a single button push or icon click (if using a mouse-only system). The main problem with the system is that it just like visible verb list boils down to a try-all-combinations-exercise (even more so than the verb list!). I think that for a system like this to work, the actions available need to be meaningful choices and not just different ways of interacting (which is also the direction Heavy Rain seem to be going).

Finally, I do not want to rule out physics even though we have had some problems with it. Physics work extremely well for objects that are in limited in their movements, like doors and drawers. It is much more complicated when it comes to stones and furniture that can be moved in any which way. I think that using some kind of hybrid system would be investigating more, but the focus must be on providing consistency. What works so good with physics is that it uses the simple and intuitive point and click input, but allow for a lot more possibilities. And that is something must be retained as much as possible.


Conclusions
Getting interaction in adventure game has taken quite a bit to come where it is today, both for text-based and graphical adventures. This means that finding another way of doing it will not happen over night, but will take a lot of time, testing and iteration. I do however think that it is something well worth exploring and although we will not have anything revolutionary for Amnesia we plan to give this some more thought and research for what ever game comes after.

If you know any adventure game that have an interesting way of doing interactions, please let us know! We are also very interesting in seeing what other people have written and of course hearing your thoughts about this!


Tuesday 22 December 2009

On Versioning (or how the simplest thing can save you from the hardest pain)

Been there, know the feeling...

Long titles aside, this is no flashy post. Some will even find it a bit boring, but if at least one can learn anything from it, I will be happy. The motivation for it comes from an often overlooked issue. I now must tell how a work day can eventually turn out:

A freelance artist we are working with found this really strange and annoying crash bug in the LevelEditor. One point listed in the Luis's standard procedure manual when working with bugs says "first, check the logs, see if anything looks strange there", next one states: "try to reproduce, and work your way on from there". Happened that the logs looked alright, and no one in the team could reproduce the bug in their machines, me included. So neither of these points threw any light into the issue.

It started to look like I was staring at one of those errors that no one wants to deal with, caused by hardware incompatibilities or similar übernice stuff (oh boy).

A new log seemed to make Luis happy, showing some strange error when loading a temporary file. It warned that the file the editor tried to read hadn't been even created. This might sound like hint... but the way the editor works (it checks if the file exists before trying to read) certainly told me that it could not be possible. Frustration++ now (or for the non C speakers there, Luis starts to lose his temper a bit).

After a while of step-by-step execution debugging, unsuccessful thinking about the cause and some other shooting in the dark, a new log came in to my hands and, while it looked alright, it stank of "I fixed this warning thing like three months ago". Turns out that the freelancer was using a dusty old version. He updated and bug gone. Gñe... now I want my sanity back.

This longish story confirms a couple things:
- You must never assume your users have the latest version when they complain about some bug.
- You definitely need a way to identify what version they are running without needing to ask them.

One might think I'm playing Captain Obvious here, but the same kind of situation described above happens a lot of times. It is actually strange to see no new messages for a while in our tech support forum. And even stranger if they are about stuff we have never seen before. Most of the time they are already solved issues, and the solution for them is as easy as updating to the latest patch.

So, after learning this nice lesson, I made a little program that is called by the IDE on the pre build event, and updates a build-ID string (in the form of yyyymmddhhmmss, with y - year, first m's - month, d - day and so on... basically a timestamp of the moment the thing was built) that will then be hardcoded in the engine and apps, and appear at the first line in logs. I am pretty sure there already are better solutions out there for this kind of stuff, but I felt like doing it before any googling, and it didn't take long, so no big deal. At least it might save me from having to buy a little suit:
Our Random Crash Simulator 1.0, feels just like crashing for real!

That's enough for today. Remember to take care, and always version your stuff!
Also, merry Christmas and happy holidays everyone!


Saturday 12 December 2009

Level Editor Video - The Inside Scoop

Continuing the topic of my last post, here comes a post about the creation of our latest video...

What we wanted to do in this video was to show how quickly you can create something playable using our Level Editor. So we decided to take 30 minutes to build something, use another 10 minutes at most to do some gameplay scripting and then finally show it all in game.

To make it all viewable without spending more than 40 minutes watching a video we time lapsed it all down to about 8 minutes. While working on the video we also wanted to add a voice, describing what was going on, but it did not work very well. To make this properly, you should write down what you want to say first, then record and edit the material after the spoken text. So it got difficult to make a voice that would have enough time to properly say what was going on during the very fast level editing (due to the time lapse). As I was battling with this problem I had a chat with Thomas, who joked that I could "write it all in verse", which I thought was actually a pretty good idea. Then I could have some voice talking, making the video more interesting but not need to be overly specific in what is said, so it could be more freely added to the visual editing going on in the video.

It took me about 4-6 hours to write the whole thing for the full video and then another 2 hours to record and edit the voice. Then I showed Thomas the video...

He got a bit worried, with good cause, that the video could give the wrong impression about the game. Is the game a parody on the horror genre? Or what is really going on? So after some discussion we decided that we should probably skip the voice altogether and only add some nice music or else the video would go on consuming time we need to spend on the game!

To cut things short, here you have the final demonstration of our Level Editor! We have shortened it a bit, then removed the actual scripting part as we felt it looked more difficult than it actually is. But to give you all the goodies, at the bottom of the post you can find the script with comments, to give you a view of the amount of script needed (and to show that a lot of gameplay is done automatically by the objects in the game). I have also, for everybody's pleasures, added the original verse. It's not structured correctly but hey let us call it free-form verse.

Have you got any questions about the editing or scripting of levels for Amnesia? Shout them out in the comments!

The Video (our first HD release!):


Gameplay Script:
As you can see, if we remove the comments (in green) it is a total of 19 lines of script code!

// This is the initial setup that is done when starting the level
void OnStart()
{
// Check if Player enters the area called AreaExit, if so then do the CollideExit function
AddEntityCollideCallback("Player", "AreaExit", "CollideExit", true, 1);


// Check if Player uses any of the two keys on the desk or door if so do the UseKey function
AddUseItemCallback("usedesk", "key_desk", "desk", "UseKey", true);
AddUseItemCallback("useexit", "key_exit", "mansion_1", "UseKey",true);


// A timer that will activate a function after 120 seconds
AddTimer("enemy", 120, "TimerActivateEnemy");


// This says to play the music file 04_amb.ogg, that it should loop, play at volume 1, start with a 3 second fade, have a priority of 0 and that it will resume where it ended if the music is stopped and played again.
PlayMusic("04_amb.ogg", true, 1, 3, 0, true);


// Adds a quest for the player, escape is the name to use in scripts and XXVideo is an entry in the file that contains all the text for Amnesia.
AddQuest("escape", "XXVideo");


// As this level is for testing, we give the player a lantern at the start of the level
GiveItemFromFile("lantern", "lantern.ent");
}


// The timer function that is called after 120 seconds from start of level
void TimerActivateEnemy(string &in asTimer)
{
// Slide the door open leading to the room with the enemy
SetMoveObjectState("door_1", 1);

// Activate the enemy
SetEntityActive("grunt_normal_1", true);

// Play an extra sound to warn the player
PlaySoundAtEntity("enemyBoo", "notice", "door_1", 0);

// Give the enemy a patrol node so that he will start to move into the large room
AddEnemyPatrolNode("grunt_normal_1", "PathNodeArea_5", 0, "");
}


// Function for when using keys on the desk and door
void UseKey(string &in asItem, string &in asEntity)
{
// Set the entity(desk or door) to unlocked
SetSwingDoorLocked(asEntity, false, true);

// Remove the item used from the inventory
RemoveItem(asItem);
}


// Function triggered as player enters the exit area
void CollideExit(string &in asParent, string &in asChild, int alState)
{
// Show quest complete message, using XXVideo entry in the text file.
CompleteQuest("escape", "XXVideo");

// Change the map to 02_entrance_hall, player start in area PlayerStartArea_1
ChangeMap("02_entrance_hall", "PlayerStartArea_1", "", "");
}


Without further ado, a Christmas carol just for you:

Jens I am, Frictional Games I curse you damn -
"Bastard from hell, don't force me to tell!"

"You better sing it like a snake or else you won't get that cake!"

"OK, OK I'll spill it all!"

You see, I got a call during the fall... a dude handed it to me "Man, what can you do in 30 minutes short, using that editor of yours, I've heard its like snort?"

Lo and behold, I told. See you do it like this. Half an hour building the base, 666 seconds to script, not even taking a piss. To not bore you stiff, check my time-lapse I'm fast as a mastiff, pay attention or get lost in another HPL dimension.

With sets of 3D tiles, even kids will get smiles. Easy as copy that floppy a room is crafted, damn it might even get you drafted. Walls, windows, ceiling and floor comes in different flavours we all can adore, combine as it unfold, see how I build a top so gold. Press B to compound create, it will save you from being late.

Feisty as they are, Entities of many kind makes the world go round, what ever you can find, make sure to use them sound. At times like these, a light or two will surely brighten the mood, where art thou tease of a candle? Shine upon my wood so I can tweak it further, it can't look as if created by a vandal.

A bed or cradle to take a nap, drawers and a table, you know, we even have a horse stable. Crap! Thomas - damn you and your ideas, "write it in verse" your words gave me this curse! I hope the christmas sock has nothing but peas (this should rime with ideas).

It is all pre-configured, place it and you won't have to go figure. What the player can do, we have already turned to our attention, it works as I mention: Doors swing, drawers pull, boxes carry, if a berry found it can be eaten, it will even crunch as you munch.

Entities of light is best placed in the dark, it will show their proper mark. Some gameplay they have, with the player around it can astound - as the Tinderbox comes to use, sort of like a fuse. Paintings, paper and books you could have them all on hooks, but let's put them all at their proper places: Walls so fine with a painting of mine, a desk is best if placed below papers and pen, the book from the den fits perfect by the pillow, perhaps something about Willow? Where did I put my glasses? Argh, it did not rhyme with places, it must be time for tea, why those long faces?

Adding a chest for treasures to keep, it is as safe as it is true that a mouse says "meep". A key for a puzzle and tinderboxes, just for the dazzle, put them all in. Remember though, it will cost you a dime if you want to get them back, not gooey in slime.

In a closet so small, Santa will fall. We poked him with a stick, to really make him tick. Locked behind a door he can't get out, but as I'll later shout - we can script some dangerous code, letting him get out finding a node. Like bread crumbs Santa can follow, the player better hide in hollow or better yet! Escape the room avoiding Santa's evil bloom.

Speaking of which, let's brighten it all up in a hitch. Spotlights in windows, shadows will cast, a gobo can be added just as fast. Size and colour adjusted with ease, we promise you do not need to lease a professional. This has all been very visional, just one more thing. We need glory fitting for a king, rays from the windows to shine upon the gory inner part of our highly technical art. Tweak it back and forth, you can really make it worth by adding particles as pretty in the light as pickles are delight.

Let's continue on and write that script or else Frictional will throw me down the crypt!

Music, oh music, my kingdom for some music. With one line of code, some music will load.

Add a timer that when 60 seconds pass, a Santa will get on your ass. Add a noise, to make sure the player has a choice. I forgot it at this point, but later I will make the door open as though pushed by a spring joint.

With a few lines of code two keys of use will be. On a desk and a door both will see, that there is no stopping me. Writing code should be made with care, not like here - I wrote a lot but "SetSwingDoorLocked" would have made a perfect knot. Erase it all and do it proper while standing tall.

An area we placed, to check if the player is correctly paced. If they collide, we should take it with pride, load a new level and end the player's ride. Took it for a test. But quickly noticed what a mess! Some last minute fixes, should make it all work without any trixes. A patrol route here, a remove item there, it starts to feel polished, if only the player knows it all clear. As a cooking show on TV, I prepared some text in a file that will make it all worthwhile, with a big bong a quest is heard making the player follow the herd. One minute the timer was short, Santa came out furious and picky, I had to increase the timer in a quickie.

And so the carol reaches the final destination, the player's faith I won't even mention. Take a look, hope we got you on the hook!


Friday 11 December 2009

Horror Tip: Beacon

Name: Beacon
Type: Game (Windows exe)
Link: Download and short info
The core of the game is simple: You are trapped in a cave and need to escape. To do so one must go through gloomy caves avoiding darkness at all cost. Helping the player accomplish this are crystals that spread light and a mysterious beacon that moves around, illuminating the surroundings where it goes. The game starts out slow and then progressively get more challenging.

This is not really a horror game, but the way darkness is handled makes it quite interesting. First of all since darkness is deadly it serves as a sort of unseen foe and it is up to the player's imagination to decide what hides in the shadows. The brief and sometimes obscure text messages at death also add to this and leaves what happens to the player open for interpretation.

Even though the game is really simple in its graphics, the darkness makes one feel like there are more details than what there really is. Many times one gets a quick look at some creature passing by, hinting that there is a vast world hidden in the darkness. These brief creature appearances also makes one wonder what might be lurking up ahead ready to attack. Finally, the minimalistic ambient track adds greatly to the atmosphere and although very simple the game becomes quite immersive.

Closer to the end, the game gets quite unforgiving in the platform jumping, taking away some of the atmosphere. This is only true for the last few maps though and works nicely as finale. Added to this is a nice little twist ending. The games should take less than 30 minutes to complete, so make sure to play until the end!

Also worth noting is that the game was made in 48 hours, which is quite a feat!

As always, we are interested in hearing your comments!


Tuesday 8 December 2009

Video Editing Hell - Linux to the Rescue!

I'm the proud owner of the oldest and crappiest computers here at Frictional Games. This is very unfortunate, to say the least, considering I'm the one usually recording videos of our work, editing and then publishing it. For the Penumbra games it worked pretty OK, for Amnesia it works surprisingly well to record videos, probably thanks to a much more polished and optimized game engine. But as online videos increase in quality it puts more strain on my poor computers and I bet that "Security Update" is a synonym for "Force User To Upgrade Computer", which really does not help at all.

I record videos on my PC using Fraps and CamStudio, the former for doing full screen capture of in-game scenes and the latter for partial screen recordings of the editors. These programs save in specific formats that I have to convert into other formats in order to import the videos into the editing software. I have not been really happy with the software that I have used for these conversions, VirtualDub, while it works it has problems using many of the codecs that I have installed, often resulting in error screens. My first step on this "Improve The Video Editing Workflow With Out Spending Any Cash On Software Or Hardware"-journey ("It vew wosaco soh"-reescha as the Swedish Chef would say) was therefore to find a new converting tool, should be the easiest thing to find in the world I thought. Hell no!

Video converters seems to be a typical piece of software that encourages it creators to add a lot of advertisements in them or to limit them a lot for the "free" part. Those that are truly free tend to be a bit too basic, while I'm happy to not have to tweak a lot of settings there is some essentials configurations you want to be able to control. It think I tried 4-5 different "free" converters until I finally found MediaCoder. MediaCoder is quite nice once you get past two obstacles. The first is that the homepage and download site is filled with advertisements, placed so that it is difficult to know if you are clicking on an advertisement or the actual link. This continues on with a lot of advertisement in the software itself, it gives a bit of a bad impression because you get worried that the software might be filled with spyware and the alike! But as far as I know it is not :) The other obstacle is that it is very detailed with settings and configurations for all the codecs. However, it has a nice setup wizard which smooths it all out a bit and once you have configured a codec the way you want you do not have to do it again.

I continued my "It vew wosaco soh"-reescha by looking into video editor options.

For editing I have been using good old iMove running on my super fast 1.4 Ghz PowerPC Mac. iMovie is simple and quite enough for doing our type of demonstration videos (infact all trailers for the Penumbra games made by us were created using iMovie). But as YouTube allows for larger and larger resolutions these days, the videos have been more and more time consuming to make, not to mention painfully slow on the interface when everything lags around, the computer struggling to render the previews in real time. The export of the final videos also take quite some time on that old Mac, when it was created there were no such fancy things has h.264 codecs.

This really led me to start looking into some options for video editing on my PC, a real monster machine powered by an AMD Athlon 2.2 Ghz (*sniff* Yes, I know, it's not really a monster at all). I searched long and hard to find some suitable free software, something that was not very complicated, yet feature rich enough to do the type of editing we have in our videos. I finally found VideoSpin by Pinnacle, which at first seemed to be pretty nice, but while trying to use it to edit our next video, it was clear it was way to simplistic. Of course there is Movie Maker, but that really didn't cut it either, so I searched long and hard but could not really find anything usable for Windows. But, for Linux there were 5 options that seemed very promising. I figured why not try some Linux editing, I do have Ubuntu installed too, so it would be easy to test some software.

I downloaded Kino, PiTiVi, kdenlive, Open Movie Editor and Cinelerra-cv (maybe LiVES too). Kino and PiTiVi was very rudimentary, Kino the better. Open Movie Editor was almost right but, I'm almost ashamed for it, it wasn't a very visually appealing interface. Cinelerra was promising, but the interface a tad to cluttered, not very pretty and for our editing needs too complicated. I was starting to get a bit worried, kdenlive was low on my list because it looked to be as simple as Kino and PiTiVi, but kdenlive really shined! It's about the same level as iMovie, a bit more functions and a killer with the amount of supported codecs (not a unique feature, but well implemented). I'm not sure if it was due to running kdenlive on the latest Ubuntu release or if it is a common problem, but it took a bit of tinkering to get all the codecs to work properly. I'm guessing the latest Ubuntu release as it has caused quite a bit of problems for our own Penumbra games.

I've been working with the software (converter & editor) during the day and after a lot of baby steps of testing I'm starting to get quite comfortable with them both. To summarise, the "It vew wosaco soh"-reescha was quite successful, it takes a while to get used to a new program but this setup is definitely an improvement over the old. At least it buys this dying computer of mine a bit more time until the day of doom. Our next YouTube video will also be in HD, making it our first contribution to the bandwidth monster.

What are your suggestions for good video editing tools for Linux / Windows?