Rss Feed

Seasons of Change: A postmortem

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)

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.