When I sat down to start Project 2011, I planned it out in much the same way I run a table-top RPG – a lot of up-front thinking about where I want to accomplish, a few pages of quickly-ignored scribblings, and then diving head-first in to running the game.
I don’t know why I chose that system, in retrospect it was quite foolish. The outcome is highly variable when you’re running a table-top game in a system and setting that you’re familiar with. The times that I’ve run it in a system I don’t know (especially a rules-intensive one like D&D or Dark Heresy, as opposed to something like the World of Darkness) or in a setting I’m not intimately familiar with (especially a half-cocked homebrew)… well, those times the results have been incredibly consistent in their abject suckitude.
I knew enough Java to comfortably pass a first year Java-as-a-Second-Language course at uni (let’s ignore the fact that I did it as a second language without having a first under my belt. Yes, I know that means there were (are?) some key gaps in parts of my knowledge) and I’d poked around with a few bits and pieces here and there. It was a fantastic learning experience and solidified a lot of my understanding of some fairly fundamental programming concepts, but ultimately I coded myself in to a position where it was going to be far easier to start afresh than to make enough changes to have the game work.
So, I sat back and thought about the design process somewhat more. I considered the obvious idea of sitting down and designing the entirety of the game from the ground up on paper before starting. A few things turned me off this idea – firstly, it sounded like a lot of not-fun which would increase the likelihood that I lose interest. Secondly, even a cursory amount of time spent thinking about it made me realise that I just didn’t know enough about how to structure programs to actually completely plan it out in advance. At best, the plan would get re-written ten thousand times as I discovered that you can’t do things a way I thought you could or that there are vastly superior ways to do it. Thirdly, I didn’t have a strong idea of how the final game should look. I had a small set of traits that the game had to possess, but wanted to keep it open beyond that. My experience with homebrewed table-top RPG systems and settings is that you need to playtest early and often and that you need to be constantly prepared to throw out even in the most fundamental of mechanics if they don’t work near-perfectly with how you want the players to experience the game.
I also started thinking about how the best table-top RPG campaigns that I’ve run were planned and organised. The two greatest campaigns that I’ve run were very different in how they played out but surprisingly similar in how I prepared for them. Notably, there was no real plot. There certainly wasn’t a road-map of where we were going. There wasn’t even really a end-game goal in mind. Instead, I had an initial idea for a mood or theme for the game, found out what sort of characters my core players wanted to play, and then designed the stage that they’d play on. The NPCs were heavily fleshed out with goals and a personality, though there back-stories and resources were left largely unstated. The city itself was fleshed out in loose detail at first. A very high level overview of the city as a whole and then a moderately detailed view of the area that the characters would start.
Most of the design though wasn’t done until the game was already substantially under way. As the players took their actions and considered their plans, I would flesh out those characters and areas of the city that they were likely to encounter a bit more. I’d add back-story as needed, invent new rules where required. Sometimes there were contradictions and inconsistencies. Quite regularly actually. They were rarely noticed – I think this is because every time I designed another piece of the tapestry I had the overall theme and mood of the campaign foremost in my mind, so it always felt like it fit together even if it didn’t.
Now obviously a PC game is quite different to a table-top RPG. For one, inconsistencies will be far more noticeable in a replayable PC game than in a table-top game that can never again be played in quite the same way. However, I do think that the fundamental approach is still valid – work out what the over-arching player experience that you’re looking for is, work out the theme and the mood, and design your game to that. No massive design document at the start of the process, just a list of unchangeable objectives. So, that’s what I did. I guess we’ll see how it turns out…
I’ve also started doing a lot of reading around games design and development and one of the blogs I’ve been paying attention to – Games by Design, written by Christopher Park, the founder of Arcen Games (AI War, A Valley Without Wind) – had a post today that discusses a design process that sounds like a much better variant on what I’d come up with myself. Today’s post is actually a follow up to one from late 2009 in which he describes Iterative Design as he sees it. Well worth checking out.
His work has led me to thinking that I need a little more formality in my design process, so in the next week or two I’ll be posting an article or two about Project2011’s immutable design goals and my secondary design goals.
In other news, v0.2.0 now has a functioning UI – you can end turns and everything! I just need to add an End-of-Turn Summary screen and write the code for one more activity and then there’ll be a little bit of playtesting whilst I decide what gets included in v0.3.0 – at this stage I’m leaning towards adding at least 10 or 12 new activities that a character can undertake, implementing some very basic traits that actually do something (currently, they’re all place-holders), and maybe adding some basic support for buildings. Milestone 2 (multi-character support) will be waiting until the character class is a little bit more stable and until I’ve worked out a few design issues around how characters will be able to work together and share inventories and the like.
