Locked Door Puzzle
The works of Richard Perrin
Developer Blog
This is my blog charting development of Journal, looking back at the development of the white chamber and any other random thoughts I have about indie game development along the way. [RSS]
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.
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.
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.
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.
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.