Recommended order for building a game

Is there a recommended general order/method when first building a game? For example, when I’m trying to write one, here are the general steps I follow (after an idea has been developed and the overall story with goal in mind has been written):

  1. Hand-draw a map
  2. Use hand-drawn map to build/connect the rooms in I7 labeling each room as a Volume
  3. Consider what out of world stuff may be necessary – extensions, before play, etc, which I also label as a Volume
  4. Then I start with the room the player starts in, adding the room description, things in the room, and other details
    4a) If there are extra things in the room, I create Books under that Volume for each thing, Parts under the Books if those things have specific rules, etc.
  5. I continue to do this with each room, either building by whatever the next Volume (room) I happen to have listed in the source, or by going to the next Volume (room) that I intend for the player to go to.

This is the most organized way I have been able to find on my own, but I figured you all must have a better protocol to follow, and yet I never even thought to ask until now.

Your method seems good, and reminds me of this post by Ryan Veeder saying how he outlines/completes his (very successful) games:

rcveeder.net/blog/2016/08/10 … an-veeder/

It can vary depending on the focus of your game. If there is a tricky system the plot depends on, it might be worth prototyping before you start to build. If map focused, I love using Trizbort ( trizbort.com/ ) to tweak the map since you can drag and drop and it will write the code for you. Your game might be very conversation-dependent, in which case you might want to spend time first building your primary NPCs and experimenting.

Just finished reading Ryan Veeder’s post, Craig. Truly was engrossing, and lets me know I’m at least sort of on the right track. I hadn’t thought of using my notebook to mark details/items about each room the way he describes. Usually I would just fill them in on the map using a legend of some sort (stars for where objects are located, question marks for where those objects are needed, stick figures for people, etc), but his way seems much more organized since I wouldn’t be trying to cram everything into a single page.

Hanon, for the game I’m trying to write now, it’s a quest game, I guess. The two main things the player does is go around fighting creatures to earn weapons/armor, and talking to people to figure out where to go to get such weapons and armor, littered with some (hopefully) elementary puzzles. What would you recommend for that? The NPCs, maybe? I have started writing two of them and noticed that both characters follow a lot of the same rules, so now I’m trying to figure out how I can create one blanket set of rules to apply to certain types of people (sort of like a function, I guess).

Whatever makes the game easiest for you to write. I guess what I’m trying to get across is exactly what you discovered - you might want to hold off writing your game from “once upon a time” until you experiment around and figure out things such as having npc’s use the same set of rules. When I wrote Baker of Shireton, I spent roughly two months on the baking mechanism. (It was still broken when it initially came out, but…that’s routine for me!)

Ideally, you want to avoid getting your game half done and going " Oh THAT’S how I should have done it in the first place…" and end up having to go back and tear up all the hedges you planted to re-do the plumbing underneath.

So yeah…in your case I’d suggest prototyping your fighting system and knowing all the ins and outs and stumbling points so when you get down to writing plot and using the systems you aren’t also having to troubleshoot “why isn’t damage working?” types of issues while implementing the story.

Thanks, Hanon. That really does help. I also have to admit, I’m a little comforted in knowing you spent two months on a single aspect of one of your games. After my first two games got a bunch of critiques from the beta-testers, I was rather discouraged, thinking I’d never make a successful game the way all of you do. Knowing now that part of my issue is that I’m simply not spending enough time on the game – I only spent a couple months each on both of those games before releasing – motivates me to be more critical and detail-oriented with my work.

A few brief points (and that from someone who has never released anything of substance):

  1. Most authors have a learning curve: many people have had several OK games before producing something really good (not everyone, to be sure, because there are some outstandingly talented people who just get it right first time: but it’s a common pattern). And why not: if you do a lot of something you probably get better at it.

  2. Everyone should expect criticism from beta testers. Don’t take it to heart. That’s /why/ you need beta testers. You are by definition too close to your own game to see what it needs.

  3. Yes, you should obsess about detail. But you also need to stay creative. That’s a hard balance. Above all, ask yourself “What is cool about this game I’m making?” Is it the setting? The writing? Some mechanic? Some puzzle? The narrative drive? It’s easy to get hung-up on the coding details, and lose sight of whether you are actually writing a game that people will /enjoy/ playing. And if there isn’t something that /you/ find cool in what you are writing, you won’t get anywhere. That needs to come from you, not your beta testers.

  4. Make your writing process /match/ your “cool thing”. Ryan Veeder happens to write games where a big part of the “coolness” is the setting and characterisation. He’s clear about that in his interesting article: /for him/ the foundational experience of IF is seeing places and doing things there. So he builds the bones of the world first. But maybe that is /not/ your cool thing. Maybe your cool thing is “the conversations we will have” or “a particular puzzle mechanic” or “the story” or “a particular character”. And if so, it may well make sense to build /that thing/ first, at least as a prototype.

  5. If in doubt, keep it simple. Strip out verbs you don’t need. Cut out objects you don’t need. Write one fantastic NPC, not three so-so ones. Reduce your locations, making sure there’s nowhere that the player can’t do or see something interesting. The easiest things to take care of are the things you don’t have.

Stick at it!

Emily Short has written some useful thoughts about various approaches to this:

emshort.blog/2009/08/23/idea-to-implementation/

In that she favours having a playable through game at any stage, then filling in the details after.

I’m following this approach in the games I’m finishing off at the moment. I’ve found it seems to get me making far more progress than a more traditional step by step approach, where I tend to get bogged down in details, and not move forward.

In response to number 2: I guess I’m just too overly sensitive lol. I do know that the testers are there to help me find my mistakes, but when I see their critiques I just can’t help but think “Damn, I suck at this, and I’ll never get better. I should just give up now.” Not that I do give up, that’s just the feeling I get as I read through their play and find all the stuff wrong with my game.

In response to 5: Making sure there’s nowhere that the player can’t do or see something interesting is an aspect I really need to keep in mind. At the moment, my current game is based on a map I drew long ago (before I ever even discovered IF and just wanted to make a cool story with it), but there’s not really anything of interest in some of the rooms, and all they do is connect one room to another. Thanks for that tip.

I’ve read this article before, too. I really liked it. It was what changed my game design to creating all the rooms first (no descriptions or anything like that, just how they’re related to each other) before adding in any mechanics.

One thing that I am beginning to appreciate is how different playtesters perspectives can be, between them. They are not all going to like or expect the same things from your game. The old adage ‘One person’s trash is another one’s treasure’ (or something like that) is very true. You should take from them what you can use, leave the rest, but learn from them all. Don’t let them define your experience of IF as an author. One playtester can critique you up the wazoo, another may totally connect. Ultimately, your game must be YOU alone. It must communicate YOU. The obligation of the playtester is to help you to make the game easier to be played and experienced by others, not to judge whether you should be doing this game at all.

This, from someone who is still touching up his first game(from 2016), and has not yet released it. I have another long game still ‘baking’(‘complete’ but not yet edited), and am already working on a third. Don’t let time pressure you.