Rss Feed

Developer Blog


A Tale of Two Jams

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.


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.

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.


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:
Development Period: 1 month (less than a week of actual dev time)

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.

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.

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.

Syndicate content

Welcome to the home of Locked Door Puzzle, the independent game development studio of Richard Perrin located in Bristol.

My primary focus is on creating expressive games that explore different forms of interactive storytelling.

For contact details check the about page.