next »

[Perrin]

I'm currently working on a new game called Journal. Here's the blurb:

Journal is a sketchily drawn adventure game currently in development. It is a 2D platform/adventure hybrid video game that will be released initially for Windows and XBOX Indie Games.

It tells the story of a girl searching for the missing pages from her journal, and in doing so she must relive memories of childhood sadness and regret.

I've started a developer blog to chronicle production on my portfolio page but I thought I'd republish it here too as it might be of interest to forum goers here.

Here's some VERY early screen shots of the game:


Fullsize: http://www.lockeddoorpuzzle.com/site/sites/default/files/JournalEarlySS2.png


Fullsize: http://www.lockeddoorpuzzle.com/site/sites/default/files/JournalEarlySS3.png

[Perrin]

13th October 2009 - Words in sentences and paragraphs as means of introduction

Believe it or not I'm going to use my first post in this DevBlog to introduce myself. Originality has always been overrated anyway. My name is Richard Perrin, I live in a overpriced flat in central London with two other geeks and I am somewhat a jack of all trades and a master of none.

Most importantly to me (and probably you) I am an indie game designer/programmer. In early 2005 I released a free sci-fi horror point and click adventure game called "the white chamber". You can download it over at the Studio Trophis site, will throw in some links at the end of the post.

I am also the co-host of a weekly video gaming podcast called Stage Clear. A freelance video game journalist friend of mine Rob Fahey presents the show with me. Largely the show is themed around the love of video games and the hatred of gamers (sorry).

As none of that pays the bills, especially in central London, I'm also a web developer. I built complex Drupal CMS driven websites for THE MAN. It's not really a fulfilling job, but it's lucrative and gives me the money to take time off and work on creative projects.

Studio Trophis never managed to produce a second game, and I'm sure I'll get into some of the behind the scenes shenanigans that led to years of failed attempts in this blog. I am however now back at work on a new game project called Journal, that is probably about one third way through development at this point.

I am going to try and update this blog at least once every 2 weeks with a mixture of articles about my experiences with Studio Trophis, my work on my new games and general opinions and thoughts on indie game development.

I'll do my best to keep it all fairly interesting and entertaining. If you have any questions, comments, or things you'd like me to cover just let me know and I'll do my best to discuss them in the blog.

Linkage

• http://www.lockeddoorpuzzle.com - My personal site
• www.studiotrophis.com - My former indie games studio
• www.stage-clear.co.uk - My weekly gaming podcast

[Perrin]

29th October 2009 - A brief-ish history of the white chamber



the white chamber was first released to the public back in 2005 it's development took a long time and I thought you guys might be interested in a bit of history behind how it all came together.

Grand Beginnings

The real seed for white chamber came from my folder full of game story ideas. One was called The Dark Chamber it was about a bunch of people who wake up aboard a space station with no idea who they are or how they got there. The idea would be two-fold, firstly it turns out they prisoners who've agreed to be part of a deadly reality gameshow. However also the station has been subject to a great tragedy 10 years earlier which would also come into play. It was just a 1 page concept document I forgot all about.

The University Year



Actual development on the white chamber started in 2003 as a university project to build a simple adventure game, and I got Paul (my housemate at the time) involved to supply artwork. We wanted to make something simple, only 10 rooms and no NPCs to keep things manageable. So I went through my idea file, found The Dark Chamber and simplified it down to what I thought was a more manageable game. The university assignment itself was meant to be a programming task more than anything else so I coded my own adventure game engine, with all sorts of great features, and I was quite pleased at achievement at the time.

However as the deadline for the project approached two things were clear, firstly we'd underestimated exactly how big we'd made the game. It was only 10 rooms but each room had multiple versions and many animations and sprites to be done. Secondly although my engine was passable in terms of functionality it had no toolset, so everything had to be built by hand in scripts. Object placement was hard enough but writing the actual puzzle scripts was a nightmare. Still we handed in our incomplete game featuring about 4 rooms and a massive memory leak and I got a very nice mark.

The Japan Year

From there we wanted to carry on with production, and it was around then we brought Zak on-board to provide music. However Paul and Zak were due to spend a year in Japan as part of their university degree. Optimistically we thought we could co-ordinate online and keep going but things didn't really work out that way and the unfinished game lay dormant for an entire year.

By the time the guys got back from Japan the indie adventure gaming scene had matured and I came across wintermute for the first time. It's a powerful engine that can handle the high-res graphics we'd created for the white chamber, and more importantly it had a toolset I could work with. So we ditched my code and ported the game across to wintermute and production began again.

The Slow Crawl To Beta



It wasn't really clean sailing from there as we were all going through our final year at university at the same time as finishing the game. To be honest getting the white chamber finished is the reason I initially failed my dissertation and had to retake it. Still after a lot of long development days, including one full crunch week where we lived on 3-4 hours sleep per night we got the game finished. The first beta went out to 300 people at a UK anime convention, to be honest few of them bothered to play it. In retrospect it wasn't really worth staying up all night before the con burning hundreds of CD-Rs manually.

Around a month later we cleaned up all the bugs friends found in that early beta and put it up for download from our website. The game was finally finished. Well sort of, we'd given ourselves a deadline but had to cull a long list of stuff we wanted to fit in. Non the less it was released on the internet to an initially lukewarm response from the indie adventure game community but through word of mouth the game spread and spread to what seemed at the time like reasonable acclaim.

Reaching The World

At this point we were not completely satisfied with the game, and we also had people coming to us wanting to translate the game into their native language. So we started work on the "international edition" of the game, where we would add in a bunch of translations, voice acting, more endings, bug fixes and other tweaks that had been bothering us. This is hopefully the version of white chamber most of you will have played.

Over time we've released new versions adding in more languages until we stopped at Version 1.7 our so-called (and long delayed) "definitive edition" including not only German text but full German speech as well. I also put the source code of the game up on the website for anyone who wanted to learn from it or play around with it. To be honest this was the point when as far as I was concerned the whole white chamber project was done and dusted.

Post Script



However sometime around April 2009 a new and rather large group of gamers found the white chamber. It seems some rather enterprising Chinese gamers decided to translate the game themselves including not only the game's text but also text embedded into artwork. They posted their patch online and a link to our servers. First I heard about this was when my hosting company started complaining about the insane amount of CPU power our hosting was using.

Over a few month period there were over half a million downloads of the game from Chinese users, adding that to the downloads we've had over the years I would estimate well over a million gamers have downloaded the white chamber at this point. Humbling figures.

The big question I've left hanging for now is "whatever happened to Studio Trophis?", as that's a topic for another day. Hope you've played and enjoyed the white chamber, it's not perfect but it's got some nice elements to it and certainly a decent homage to my love of point and clicks when I was a kid.

Linkage
* the white chamber

[Perrin]

18th November 2009 - Let's Talk

Journal is an adventure game, one that forgoes typical gaming puzzles to focus on character interaction. That is to say there will be a lot of talking in the game. I would say the most common two methods of dealing with conversation in any story based game is either to have the entire conversation pre-defined or to give the player dialogue trees. As the conversation is the main gameplay mechanic I can't just have the player travel around triggering story cutscenes or I might as well be writing a book. So that leaves me with dialogue trees, ropey old dialogue trees.

Grinding Conversation

The first thing that bothers me about the typical approach to dialogue trees is that you're not really presenting the player with must choice. In most games it's more about letting player work their way through a bunch of pointless branches until they hit the correct route through the conversation. It's discussion by trial and error and to some degree breaks the reality of the game. How often do you have a conversation with someone and when it goes badly you just break out and start the whole thing over again.

The best implementation I've seen is probably Mass Effect, here conversations are a mostly a flowing thing. You go through them once and are forced to make choices along the way that will affect the outcome of the discussion. They even allow you to pick your next choice slightly in advance to keep the dialogue flowing. They do actually have some elements of old style dialogue trees in there if you want to pump someone for deeper information but most story conversations happen once and there's no second chance without reloading.

So for these reasons in Journal conversations about a specific topic will largely be a one shot deal, you go through that dialogue with a character and unless you find something new from another person to advance the conversation any more you can't go back for a redo. This is something BioWare are leading the way on and I'm happy to follow.



Illusion of Choice

The next big problem I have with traditional dialogue trees is you get loads of choices but essentially you have no choice as to how the game will play out. There's only really one or two correct ways through the conversation you can't really change things and inject much of how you want it to play out. The basic reasoning being that if you let the players say what they want you've got to create lots of additional branches to the storyline.

A lot of games deal with this by giving you fake choices, where if you go back and revisit the various options you were given they all in fact result in the same response. Bethesda's Fallout 3 deals with this tremendously simply by doing all the ground work it takes to accommodate quests being completed in lots of different ways.

Not wanting to trick players with hollow decisions and not having Bethesda's budget I've decided to try something slightly different. In Journal you can make choices in each conversation that will affect how you interact with the other character, and so the conversation will play out differently depending on what you choose. However rather than branching the game's storyline based on each player choice, it will instead just affect how that other character sees the player. More like a reputation system I guess, that will then affect other elements of the game down the line.



Ideas Not Words

Finally not so much a problem with normal dialogue trees but I guess more a personal preference again inspired by Mass Effect. When a character talks to you most games bring you up a list of responses you can reply with, with is fairly logical however in Mass Effect you've usually just given a couple of words, hinting at the mood or an action that you character will say without being so explicit. I liked this a lot because the way the conversation plays out is still a surprise to the player and instead of trying to analyse what each choice of phrase will lead to you're instead picking a mood or a tone of how your character is behaving.

Taking this approach really allowed me to simple down the conversation interface in Journal. Rather than having lots of text on screen I instead just use a simple row of icons at the bottom of the screen. These icons can represent either topics of conversation, or a moods for replying with. So for example when you first open up a conversation with a character you'll get icons for various topics that you've learnt about so far, but when the other character expects a response from you your choices could be nasty or nice, lie or truth.



I'm Going To Have To Stop You There

I'm hoping the system I'm describing is something players will get into. In my ideal world players will quickly learn what they think of the other characters in the world of Journal and make conversation choices based on the emotions of how they feel towards them.

Having said all this I don't think my way is a "superior" or "correct" approach. I just think these are the type of conversation I enjoy most in games and think suit what I'm trying to achieve with Journal the best. Greatly looking forward to see what choices people will be making in the eventual play testing sessions.

[george]

Hey, good to see you back around, I enjoyed reading your old blog posts on IF. 

[Perrin]

Hey, good to see you back around, I enjoyed reading your old blog posts on IF. 

Wow, I never knew anyone read that stuff but yeah glad to be back into the swing of game development. It's been too long and I'm bloody fed up of spending my weeks building websites. ^_^

[deathtotheweird]

I too liked the way that Mass Effect handles dialogue, I was actually talking to a friend about it recently.

Journal looks pretty cool so far. Keep up the devlog, I enjoy reading it.

[Perrin]

November 29th 2009 - Dangerous Expectations

A few months back I released an early prototype of Journal to a handful of friends to get some feedback about the gameplay so far. The prototype was rough, and didn't even feature a title screen. My early testers were just thrown straight into the action and expected to fend for themselves.

So a few weeks back I did the obvious thing of adding in an opening title menu to the game with all the usual options: start, continue, options, extras and quit. All find and dandy because that's how games work, you load them up and the title screen is the hub for your time with the game.



What is it good for?

However a discussion on the TIGSource forums about title screen in games made me rethink why I needed the title screen at all. Of course I could just take it out to be contrary, to be different, a lot of people seem to value being different quite highly. However as my day job is a web developer I ended up thinking about the human interface implications of having or not having a title screen.

If you think through your typical interactions with a game, the first time you start it up you'll pick new game, and then almost every time after that you'll pick continue/load. Then maybe after playing the game for 10 minutes or so you might bring up the options to adjust something. Which leads me to wonder why not just automatically start the game the first time and then automatically load on subsequent occasions.

Now you could counter by saying what about multiple users on the same machine, they might need to load each time they start or you might even want to start a new game yourself. However as these are the fringe cases that don't apply in the vast majority of cases they shouldn't be a reason to delay most of your player base over and over again.

A Little Bit of History Repeating

So yes as you might have guessed I've removed my lovely title screen menu from the game. It now starts automatically, and on top of which I always thought there was something more slick and stylish about having the game's title appear over the action in-game than on it's own separate screen.

The almost depressing thing is once, I'd thought all this through and made my decision I realised that I am far from forward thinking in this regard. Look at Braid, it does all of this already and does it well. Dumps you straight into the game and teaches you how to play without ever having to rely on typical game interface expectations.



My conquest over my menu screen might not be that interesting, in fact I'm boring myself reading this back, however I think it does hilight an interesting point about expectations. I put a menu screen in because that's what everyone does, and I think that's a dangerous precedent. I think it's fool hardy just to buck all existing trends for the sake of being "unique" because a lot of tropes exist because they're popular for very good reasons. However it's always worth thinking through the things you take for granted and establishing for yourself if they make sense.

[Perrin]

December 28th 2009 - What I Did With My Holidays

Christmas is now over and New Years will be hitting any day now, and so the temptation has been to slack off from Journal work and over indulge in sweets and TV specials. So yes, as you might suspect I've not really been working on Journal over Christmas, however I have no been slacking either. Instead I've been focusing on TIGSource's Assemblee competition.



Let's come together

Assemblee is competition where artists  and musicians are given a month to produce art and music assets with no idea what game they'll be used in. Then for the second part designer/programmers can take any of that material and try and make a game with them. I really loved the basis for this competition as the art assets I find are usually the hardest thing to arrange for a game, and having them already done when you begin not only saves a lot of work but also means you have to focus on a limited scope design because you can't use anything not already available.



My only complaint about the competition is that loads of artists have produced awesome looking high resolution assets, but the general mood on TIGSource seems to be that of infatuation with the 8bit era so more than half the entries seem to be making using of one specific set of lo-fi retro characters and tiles. In fact the selection of awesome art being completely overlooked helped inform my game design.

Beauty in boundaries

With no specific restrictions on what type of game you could make my natural reaction was to do some kind of interactive story. There was also 4 different sets of art assets I really liked but they were for the most part incompatible with each other. So my decision was to make a set of short interlinked stories each using a different art style.

The game I'm working is called Seasons of Change. It starts with and over-world used as framing mechanism for the game's multiple stories and then within that world you can enter three different doors, each leading to its own world with a short interactive adventure within. The different tales are not directly linked but they each themed around people learning to deal with change in their lives in different ways.



At the time of writing my entry is nearing completion, with a bit of luck I'll get it all done and dusted over the next week. It's been a really valuable experience taking part in this already for me. Working under right restrictions really helps you focus your creativity, and the competition has encouraged me to make a game I'd never thought have making otherwise. In terms of technology it's allowed me to try out a new engine, that I'm fairly sure I won't be touching again but that's a subject for another post. Most importantly in terms of experience it's allowed me try out some methods of game storytelling and see if they work.

Learning from history

To be honest at this point I think the game might fail to be as effective as I would have hoped, I'm already seeing problems with the design that didn't seem as apparent before it was actually playable. I'm going to use the remaining time in the competition to see what I can do about that. Ultimately though win or fail the competition has not sapped away a huge amount of time and has allowed me to make mistakes that I will remember in future.



Over January I am also hoping to find time to enter Gamma's one button gaming competition, JayIsGames one room interactive fiction competition and two different Game Jams where people gather together and spend 48 hours making games in teams. My hope is that when the end of January comes I will resume work on Journal having made a whole batch of interesting short games and having much more experience in seeing how my game ideas actually pan out.

[Carrie Nation]

Perrin this is great stuff you're writing here, you should start a weekly/daily/hourly blog on just game design, talking about elements of games and shit.

I mean the game this topic is based on looks interesting but your awesome commentary is just drowning that out. It'd be great if you could split them up because I'm sure I'm not the only one enjoying these step by step breakdowns of all the parts of a game.

[Perrin]

21st January 2009 - The best worst engine none of you are using

While browsing the XBOX 360 Indie Gaming section looking for anything playable in the sea of shit, I noticed one of the game's box art had a little bit of Japanese at the bottom saying "Action Game Tsukuru", which ignoring a japanese play on words essentially means "Action Game Maker". This intrigued me because I wasn't aware there were any commercial engines, apart from stuff like Torque, that could output to XNA. I was also interested because it was clearly from the same series as Enterbrain's RPG Maker, which is known for being incredibly easy to use if a little restrictive in scope.



A quick google search later and I found Enterbrain had indeed released Action Game Maker in Japan, but on top of that they had also put out an English version called Indie Game Maker. This is probably the kind of thing that would have no appeal to many of you, but I'm a a terrible programmer, I do PHP for a living but hate coding yet somehow find myself always stuck doing it. So I'm always looking for nice tools that will suit the scope of the projects I'm working on and automate a lot of wheel reinvention. For the record my main project right now "Journal" is being written in C# from the ground up but that doesn't mean I don't love an easy engine for the right project.

A whole new world

So at first glance at the feature set Indie Game Maker looks fantastic. With toolsets specifically tailored for making shooters, RPGs and platformers I figured this was going to have enough flexibility for the kind of simple games I'd want to make with it. It's export formats included a Windows EXE, XNA source code and Flash SWF. The flash output interested me as it meant with a projector I'd get a free no-hassle Mac port of the finished game. I tried it with one of their test games and it worked a treat.

Over Christmas I've been working on a game for TIGSource's Assemblee competition (see previous entry for more details) and I figured combination of prebuilt art assets and a really simple engine would be perfect for getting a rough game done really quickly. So I have now spent the last few weeks working quite intensively with Indie Game Maker and I think it's time to share my thoughts on this engine. Put simply: it's both brilliant and completely useless.

A poor workman...



To break this down, I really loved the toolset and workflow up to a point. You create a series of animations from art assets, with lots of control over every aspect of it along with multiple collision boxes. You then create gadgets, which are objects containing a series of states and you assign animations to each state and define what condition takes the gadget from one state to the next. The level editor works with tilesets and allows you to easily define collision boundaries for them. You can also manually place gadgets wherever you like and assign them movement paths. In game text is store separate from the logic, with some great localisation support. With all that I'm only scratching the surface of what the engine can do.  During my initial learning phase I was just amazed how logical everything was, most things I wanted to do were already in there in a simple well thought manner and didn't require any coding to pull off.

One minor gripe that I could live with is that the English translation of the engine is clearly a rush job with no real quality control, many of the translated terms are just clearly the wrong interpretations of the Japanese word. The most obvious being that variables are referred to throughout the engine as "memories", however that's not a deal breaker for me as I just learned their esoteric naming conventions.

What really breaks the engine for me is that without any kind of scripting support at all, as soon as you try to do anything outside of the expected usage you're running into brick walls. The biggest problem for me is that making a platformer with dialog seemed to be something they hadn't expected. Doing something simple as having two characters talk required a new state for each line of dialog which is messy and convoluted, and I had to give up on any notion of having branching dialog. You could argue they're uncommon requirement for a platformer but the engine doesn't even support ladders or diagonal surfaces. Finally the logic system is incredibly basic, switching between states has to be "all of these conditions are true" or "one of these conditions is true" offering no more subtle fidelity.

Proof in pudding



So despite running into the walls of the engine's capability I've managed to make it work with my competition entry. As my entry was nearing completion I began looking into the Flash export facility to get it running on my Mac. Now getting the pre-requisities for the Flash exporter up and running is no simple feat but I could live with the hassle were it not for the fact that the Flash export is completely unworkable. A huge chunk of the engine features are not supported in the Flash version including many I've used such as text boxes, stretched backgrounds, and most shockingly the logic model seems to be broken. I've not tried the XNA support yet, but even if that works great the loss of the possibility of a Mac port kills one of the major benefits I figured I was getting.

So where does this leave me? I am never going to use this engine again and neither should you. It's two remaining killer features are XNA export and a really lovely toolset but neither of these seem benefits enough for all the problems I encountered unless you were only making a fairly simple platformer or shooter. For simple game construction I fear my only choice is now to return to the Windows only Game Maker, which is a lovely tool in many ways but I do feel the toolset in IGM is where Game Maker's toolset should be at this point. I can't be the only one who feels like genuine advancement on Game Maker's tools halted many years ago.

So to repeat myself Action Game Maker / Indie Game Maker is both brilliant and completely useless. Knowing Enterbrain's history they might release a new version next year so for all I know they could address these problems but who knows? Right now this is not something I plan to use on any more projects.

[Perrin]

Perrin this is great stuff you're writing here, you should start a weekly/daily/hourly blog on just game design, talking about elements of games and shit.

I mean the game this topic is based on looks interesting but your awesome commentary is just drowning that out. It'd be great if you could split them up because I'm sure I'm not the only one enjoying these step by step breakdowns of all the parts of a game.

Really glad you're enjoying the blog. Not sure I could do what you're asking though, for me I need to be talking about a game to give my discussion some context. Just talking entirely theoretically leads to me waffling about nothing. Also don't think I could do it that much more regularly. Though I do have another entry for this blog nearly written so next update should be very soon.

[Perrin]

Seasons of Change: A postmortem - 11th March 2010

Patient was released to the public at 59 seconds past midnight on the borderline between Sunday 10th and Monday 11th of January 2009. The patient was finally buried the following Thursday when a final version was uploaded to the information superhighway. What follows is the result of a self critical analysis of the corpse, structured in the time honoured manner of video gaming postmortems.

The Game



Seasons of Change is a piece composed of four short interactive stories all thematically linked around the indie of people coming to terms with change in their lives. I built it for TIGSource's Assemblee competition in which musicians and artists created a huge amount of assets which no idea what game they would be for, then us designer/programmers could use any assets we liked to make any game we wanted from them.

With no specific theme/direction to what type of game to make I defaulted back to my usual approach of making an interactive story, I feel in love with a few difference sets of assets that would never work together so I had to make a set of short experience instead of one bigger game.

Structurally the finished game had a black and white world where a knight who does not yet know why he's there must go into three doors, experiencing visions that will help him. Those doors included a 50's style pulp detective world, a cave exploration platforming world and a black and white sketchy rabbit world. Each was a different type of experience with its own story to tell.

What I Did Right



Good choice of assets
I was slightly disappointed that most people in the competition were so focused on using Oryx's low-fi rouge-like sprites. They were very nice but there was a huge amount of amazing assets submitted and especially the high resolution stuff was being completely overlooked in favour of retro stylings.

I went through the assets and found the stuff that I thought looked really nice and the create had provided enough content for me to build something playable out of it. While the scope of what they'd created was my main limiting factor I have to give huge credit to all the artists whose work I used, since typically when I make a game content is the bottle neck so it was amazing to have it all up front.

Realistic scope and scalability
Although I'd made my project reasonably elaborate by wanting to do multiple worlds I kept in mind that I would clearly not have much time on this. So I always knew I could have included less worlds if I was running out of time, and for each world the story could be scaled back to just a couple of screens if necessary.

I also used a game making tool, Indie Game Maker, rather than coding from scratch so my time wasn't spent fiddling with source code. I am not a great programmer, so using tools for competitions and small projects is vital for me getting things finished. As I wasn't planning on doing anything complicated gameplay wise I figured there would be few engine hurdles. (More on that later)

Finish on time
This game was my first short game making competition title so I was determined to finish it by the deadline. Progress was mostly completed like an inverse bell curve, with lots of work done at the start, very little in the middle and a big push at the end. Not the most efficient way but I did get the game done. The final night though was one of no-sleep and a self imposed crunch to get it done.

I also worked on it a bit more over the next few days cleaning up some additional issues, and making some subtle changes to the artwork which was forbidden by the competition rules so I could upload a proper final post-competition version of the game. Meaning the whole project was wrapped up and I could move on.

Lots of polish
I didn't want the game to feel like a rough prototype, with over a month to work on the game I wanted to make sure it felt like a really slick polished experience. So during the final phase of development I already had all the content in place but was instead trying to clean anything that seems a bit cheap or unfinished, and adding small but cool additions to make the experience seem more developed. I find it hard to express exactly what the polish entails since it's essentially 101 little tiny things, but focusing on those towards the end can give the player a better experience than adding more major content.

What I Did Wrong



Bad choice of engine
I'd not really used Enterbrain's Indie Game Maker before and I sure as hell won't be using it again. On the surface it's a really slick engine for making platformer, shooter or RPG style games quickly with a lot better toolset and game logic in places than other rapid game dev tools like Game Maker. However as with most specialised tools you can very quickly stray out of their expected workflow and suddenly you're fighting tooth and nail against the engine to get it to do simple tasks. The worst for Seasons of Change was dialogue, which I never found a nice way to deal with. By the end of development most of my time was fighting the engine instead of being productive.

Weak "gameplay" elements
I originally wanted each of the four worlds to feature different gameplay types, the cave world would be a mario style platformer, the detective world would feature gun fights and branching dialogue trees and the rabbit world would be full of dizzy style object puzzles. Most of these were simplified out because of development time and finding the engine itself just wasn't customisable enough to do these without an immense amount of work arounds. This meant the final game was much more passive than I'd hoped, it still told the story I wanted but wasn't as interactive as I'd dreamed it would be. I think this is primarily why some people thought I was making an "art game".

No time for testing / feedback
Because I was developing until the last moment of the deadline I just didn't have any time to throw it out to people for proper QA. This meant the competition version was very buggy. Though I had chance to fix up some of these bugs for the post-comp version, by that point I wanted to move on so I didn't spend any time soliciting feedback to improve the design in general. Frankly, the game could clearly have been better if I'd got other people to look at it and point out obvious weaknesses I'd lost sight of.

Didn't stretch my design skills
As the theme for Assemblee allowed people to make any kind of game I took the easy option of picking an interactive story, a genre where I feel most comfortable. While the competition was a great chance to focus on a project and actually get something finished, I didn't really stretch my abilities and try anything particularly new. Though I did learn some things from the process, I think I would have learned more if the design itself had been more challenging.

Conclusion



Seasons of Change is a strange project for me, as despite how well aware I am of how it falls short of my intentions for what I wanted to be, I'm actually fairly happy with it as a title. I have a tendency to only focus on the shortcomings of my projects but I think as a brief piece of storytelling Seasons of Change gets it point across, even if it is not as subtle or as well developed as it could potentially be.

Technical Details

Platform: Windows
Engine: Enterbrain's Indie Game Maker / Action Game Maker
Size: 74.5MB
Resolution: 1280x720
Website / Download: http://lockeddoorpuzzle.com/site/works/seasonsofchange
Development Period: 1 month (less than a week of actual dev time)

[Perrin]

A Tale of Two Jams - 19th March 2010

In my continued attempts to not really work on Journal properly and get involved in more short form game development I decided to attend both TIGJamUK2 and Global Games Jam 2010. Both were weekend long rapid game making events held two weeks apart. They both turned out to be very different so I thought I'd jot down my experience of how they panned out.

TIGJamUK2



Located on the upstairs floor of a bistro in Cambridge we crammed in a little over 40 people all with laptops around small tables. With no introductory fanfare or structure, you just found some space and set up alongside the other jammers. This immediately made the whole thing a very social experience as you quickly got to know the people you were sitting with: who they were, what they'd made, what was their chosen dev platform.

The selection of people there was fantastic, they were all indie game makers but all of their backgrounds were different. With people of many ages, nationalities, and experience it led to a huge variety of interesting games being put together. The main thing was though that these were all people who knew how to finish making games and were here to get some games written and make some new like-minded friends.

Once things got properly underway the weekend mostly consisted of 3 hour game jams. Everyone would write down themes on scraps of paper, 3 were chosen at random and you had to make a game that used one of more of the selected themes. There was even a 1 hour jam in there at one point but the 3 hour format seemed to really work. It was just enough time to implement a couple of mechanics and get a rough prototype of a game up and running.



This was my first experience of making games in such a short period of time and I was very unsure I could pull it off, but the focus and pressure of being around so many other talented developers really made a difference. As long as you've got a tool you can work with quickly you can really put some interesting stuff together at high speed. Being a very slow and crappy coder I decided to use the weekend to get to know Game Maker and that proved quite a success.

I was involved in making 7 games over the course of the weekend of vastly varying quality but each one was a new learning experience for me. Ideas that sound interesting or funny in my head could turn into really boring or confusing games. I also got managed to work on a few concepts that intrigue me enough that I'd like to come back to them later and perhaps turn them into full projects.

Global Games Jam 2010 - Qantm College London



Two weeks after TIGJamUK2 I was very excited to be back at another event I imagined would be quite similar. Global Games Jam is the much more professional cousin of TIGJam, running simultaneously in a huge number of locations across the world, I attended the London event which was being held in a college that runs game development and production courses.

The difference in tone in the jam was quite immediately apparent, opening with us all in a lecture theatre where we watched a pre-recorded presentation played at all sites worldwide, including an interesting video keynote by Ste Curran of OneLifeLeft and Chime. We were then left in the room to break the ice and do a bit of socialising, though after chatting to a few people I quickly realised people were gathering into teams so had to strike quickly to make sure we had all the members we needed to make something.




The format of GGJ was to spend 48 hours making a single game in a small team. We had four primary members: lead coder, coder, artist and designer (myself) along with the help of a musician who was doing stuff for various teams. The overall theme for the jam was "deception" so we decided to make a punishing platformer that tricked the player at every turn. We pitched our concept to the whole room, watched everyone else's pitches and then got to work.

The weekend felt like a real microcosm of working in the AAA game industry:
- Friday was early in the project when we're full of great ideas and convinced we can do anything.
- Saturday was when the quantity of work involved really dawned on us and we worked incredibly hard all day feeling like we weren't really making much progress.
- Sunday was crunch time, corners were cut, ideas were scaled back, coding became hacking.

The rest of my team looked completely shattered by the end of the weekend, having survived on little sleep and working themselves beyond their limits. Being the designer I wasn't quite as busy as them, I spent friday coming up with the overall design, saturday building the levels in Mappy and then on Sunday I switched to doing production work getting the art and music into the game. So unlike them I got a good night's sleep back at my flat each day.

The one other key difference of GGJ was that the demographic here were not indie games makers, they were primarily students or graduates with hopes of getting into the real games industry. These were not people who had made short games before under such pressure. There was a real sense of inexperience and desperation about the attendees. Who were largely attempting to bolster their portfolio for their next attempt at sending out their CVs.

There Can Be Only One

Having experienced both, I'm unsure if I'd do Global Game Jam again. While I met some great people and I always enjoy making games, the format seems to skew towards the most draining and demotivating aspects of the games industry. Also it somehow primarily attracts an audience of people who aren't really in it for making small fun indie games but are just seeing this as a stepping stone to becoming a cubicle based drone. They were good people and very friendly but not people who inspire me to make better games.

I left TIGJam with a bunch of people on a high, a sense of camaraderie after a fun weekend. We'd all made a lot of games and new friends. While I left GGJ with a team low on morale having barely finished a project that wasn't as good as they'd hoped it would be. Seemingly great metaphors for the difference between the indie and AAA gaming industries.