Quick question for the authors out there - how much effort do you put into designing your projects before you begin coding? (If any?) I’m from a business software background so i’m used to reams of documentation, analysis, technical design and such things. Do you typically do any formal up-front design work? A concept document summarising the basic plot? Or do you just start coding the first room and see where you go?
Usually I write up a (non-formal) outline of what the game will contain: puzzles, important objects, major plot events. Also I draw a map. (On paper. With a pen.)
Then I start implementing the first room. Text (descriptions, action responses) get written as I go.
Hadean Lands, being a stupidly large and complicated game, required more planning.
I think whatever your planning style, give yourself lots of time. With Coloratura, I planned for one or two more months of development than I thought I’d need, and I gave myself an empty month where I could take a break from playing and then re-approach the game from a fresh perspective.
I did a month of research before starting any real planning, created the map, then did a basic one-page outline. I did character bio’s on each NPC to have a resource to refer to if I wanted to flesh out their characters or motivations. I carried a notebook to scribble down puzzle ideas if they just came to me (and gave myself time so that I could just let puzzles percolate in my brain). Then I just start-to-finish programmed/wrote the Prologue and Act 1. I took a break and played the game to see how well it worked. I scrubbed some stuff and re-arranged other stuff before taking on Act 2, then Act 3 and then the Epilogue. After each section, I took a break and re-examined how the game played. I also left plenty of dead space towards the end of the deadline to accommodate playtester schedules.
Of course, despite all my careful planning, I was still slamming away at things in the midnight hour. So maybe careful planning won’t get you comfortably there by your deadline, but at least you’ll have a solid result.
I’d also like to point out that this was a method that worked for me on one game. I’ve had different approaches on different games, and different things work for different people. Try some stuff out, and eventually you’ll get to something that works well for you.
IFwiki seems to be down at the moment, but if it resurfaces, you might also find it useful searching that for the making-of articles that talk about how people tackled particular projects.
I generally plan out a lot of things in my head–mechanics, story, puzzle, and so on. Then I make a paper map of an area listing the puzzles and the steps in solving them and/or work on implementing one of the mechanics for a while before starting to code the game itself.
Theme/plot. What’s the core concept of this game? Usually includes an idea of who the PC is.
Characters. Who else is in the game?
Map the area on paper.
Derive puzzles from the characters and map.
Start coding. I usually code in the same direction that the player will play - the first room first, the second room second, the first puzzle first, etc. Major systems get coded at the point where I can’t progress through the game without them any more.
Update everything. Many of my favorite ideas (like the ferry puzzle in Beet the Devil or the blackboard in Ollie Ollie Oxen Free) emerge during the coding process. I’m working from those initial design documents, but nothing’s set in stone until I’ve actually come through and coded it, and even then it’s subject to update later.
Thanks for the responses everyone! It’s been very helpful to get a look at how other people do things.
Em - Thanks a lot for pointing me to that blog post, it’s very insightful. I’m just starting on a very simple competition entry as an inform learning exercise and I think i’ll give your through-line design a try. Makes a lot of sense.
I’ve been playing around with IF and inform on and off since before inform 7 was released, hoping I might actually finish one this time around
The two released games and one unreleased game developed by Textfyre had general plot and chapter summaries written first. Then full design documents with every location and interaction defined withing a Word document. These documents are around 200 pages each as I recall. We embedded full and chapter maps to help the writer and programmer. At some point I’ll release these documents, but at the moment I’m still trying to sell them commercially and we’re working on completing the third game (coding restarted in October).
I know some people like developing “fake” transcripts of games to start and then go back and code them up. Others will map out a game first. And some people will start with a “system” they build and then layer a story on top of that system.
For your first several IF games, I (my opinion) would just start making a game, any game. Don’t worry about releasing it or if it’s any good. Just get comfortable with the medium, creating locations, descriptions, scenery, movable items, and getting used to whichever tool you use. Then maybe develop a short game for a comp and try to do it well, but don’t get too hung up on that. The more important part is to finish it and try to test it well enough so it can be played all the way through.
Now you’re ready to really think about a game, plan it out, and create something special.
Of course there are those that understand all of the IF conceits instantly, are patient and thorough, and can create something special on their first try. You may be one of those too.
When I’m coding by myself, I really like to get a ‘coder art’ version up. All of the rooms, objects, puzzles, etc working as early as possible. I particularly having a path to the endgame working as soon as possible.
Then I can fill in descriptions and text as I see fit.
I’m a huge fan of placeholder text while building a proof-of-concept. It feels awful to be writing descriptions, then be unable to see them in-game because you broke something.
The approach I have, is to start messing about with the engine, entangling myself up in who knows how many extensions and fixes, and end up not releasing anything. You’re not actually asking how people do it - you’re asking what approach is actually the best one.
When it comes to IF, I believe in making things up as you go along. This is specific to IF, because there’s hundreds of IFs out there, so the player is looking to see if things look interesting in the first three rooms, and if it doesn’t look interesting, he’ll simply quit the game. Walls of text explaining an epic story, doesn’t interest the player, at least if that player happens to be me. As a player, I’m looking for cool things as I play, and you can’t plan “Make a cool thing in every third room to keep the player’s interest.”. You have to go with the flow of things as you make things up, and how the player will play things.
I imagine that if you plan an IF, you can end up with 50 rooms forming a landscape that makes perfect sense, but consists of empty, boring locations like “Approach to Hillside”.
The most work will no doubt be done after the game is done, when you try to make the game actually playable with all the godforsaken verbs and unexpected flashes of genius that the player may try and have. An IF is next to impossible to get player-proof, so good luck with that.
Thanks for the thoughts Andreas, although I do have to disagree… i’m not asking for any value judgements on what is the “best” way to design IF, I really am asking simply what approaches other authors use. I have a lot of experience in design from the business software side of the fence, and I am just looking for ideas rather than prescriptions, that I will cherry-pick from and experiment with.
For instance, I quite like Emily’s “through-line” approach, it makes a lot of sense to me and I think I could probably use something similar successfully. Then again, TextFyre’s up-front design process is very familiar to me, having used similar approaches on lots of software in the past - however I know that if I try to do it that way i’ll get bored and never finish. There are different considerations to be taken in to account when something is made for fun, rather than commercial purposes, and entertaining yourself while creating is just as (or more) important than a rigorous quality control process.
In fact, it’s impossible to have a (productive) discussion of “best” without taking this context into account. What suits a hobbyist playing around is not going to be suitable for a commercial concern such as textfyre, who has a far greater stake in the finished product and more to lose if it is low quality (potential revenue).
I think there’s a difference between ‘planning an IF game’ and ‘flooding the player with exposition at the beginning of the game then following it with a bunch of devoid-of-content filler.’
I was pretty sure of that, but I wanted to respond as if it was serious for the humor value.
Explaining this will either make it less funny, or funnier. I don’t know which, but I’m hoping for some kind of metajoke to emerge and save me from looking doofy on the forums.
…all right, it wouldn’t be the first time.
More seriously, though: Andreas, designing to “hold the player’s attention in every third room” is absolutely a viable approach. If you read about how theme parks are designed, it’s the same concept - if you have X amount of space and people are expected to traverse it over Y amount of time, you need something new to attract a visitor every Z yards. Doing the same thing in IF isn’t hard, though I’ve never been quite so regimental about it myself.
Also, saying that is not really any different to writers advice saying “write conflict on every page.”
That said, this topic was more about design processes, rather than “how to design an if game.” A failure of design, ie. a badly designed game, can (and does) occur completely separately from the process used to design it. It influences, definitely, but doesn’t determine.
Nothing about a particular design process is necessarily going to lead to any of the problems mentioned (walls of text, empty boring locations) - in fact, i’m not really sure why you think they would…