How do you, personally, usually begin writing a game?

Authoring General Design Discussions
1

These questions are in part to satisfy my own idle curiosity, and in part to assume myself that I’m just as strange as everyone else. So, how do you start writing a game (or other interactive prose [or poetry… hmm, now there’s an idea])?
Personally, I start with a simple outline of the plot and a map, then start writing code, filling in the plot and making up details as I go along. How about you? Do you jump straight into code, or do you write the ‘Lost Tales’ and the ‘Silmarillion’ before you ever write a line of code?

Also,what is your junk/testing/working game ratio? For every game I know I’m going to finish, I have at least three test games (trying out some new idea, or working on a some difficult code), and two games that I abandon when I realize my idea is too hard to implement, too long, or too boring - a 1:3:2 ratio.

2

Usually when I write a game I start out by doing the scenario and scene dressing for iconic sections of it, then draw up the story line second. I generally keep a list of motives front and center while I’m putting stuff together so the characters act believably, but generally I’m limited by my actual programming skill so things get simpler as they go on.

I’d say finished to unfinished is probably 1 out of 10 or 15, mostly because of design elements that are necessary for the story but which I can’t figure out how to implement.

Mostly I finish the entire game design (characters, general places) before I start writing the code for it, but leave some details (the particular linkages of rooms) for the actual implementing time. I’ve been kicking around the idea of doing the whole game specification in a spreadsheet or something else electronic, but I mostly do the designs in my head during dreamland, or write them in notebooks while I’m away from my computer.

Thanks for sharing your approach. Implementing is really hard o___o

LH

3

Varies by project, but my general process is:

(A) Conception
(B) Game Design Thumbnail (lots of scribbled notes or spreadsheeting)
(C) Test Implementation (seeing if I can actually implement critical things that the game will need … many projects die in this phase when I realize that I cannot, in fact, implement the critical things the game will need).
(D) Game Design Actual (even more scribbled notes and lots and lots of spreadsheeting, plus some actual writing at this point)
(E) Crude Implementation (the wireframe version, if you will, without much writing but which functionally implements the design)
(F) Self-Testing and Writing (layering words over the wireframe, replacing placeholders)
(G) Revisions (projects can get mired here; “don’t get stuck in Molasses Swamp!”) Can theoretically move game back on the track to any prior stage.
(H) Alpha Testing
(I) Post-Alpha Revisions (see G for dangers, but less so), preparation of release candidate
(J) Beta Testing
(K) Post-Beta Revisions (see G, but now much much less danger)
(L) Release, ahhhh.

I’m not sure how to separate “junk” from “testing,” really. But my ratio of “stuff that isn’t a working game” to “stuff that is a working game” is probably around 8:1 … which might sound high, but to me I7 is kind of a game all its own. Just playing around in it is something I find rewarding, and it helps me learn it.

And the usual disclaimer: my professional background is game design and game writing, with zero programming. I have no training, experience, or aptitude as a programmer, so any method I may describe should be approached with appropriate caution.

4

I know! That’s the death of most of my attempts… for instance, I started a game in which the main character was a hat; whatever NPC the hat was on would become the main character. Cool, right? Well, obviously you’ll need lots of NPCs… and things should react differently to each NPC. What eventually killed it was the realization that every NPC would have to be on a track for movement, and would need to know how to get back to said track.
Four rooms and twenty (!!!) NPCs later, I called it quits :stuck_out_tongue:
I’ll come back to it eventually, but… whew. Good idea, bad implementation.

5

Since pretty much all of my IF is 1) short and 2) based on a central trick/gimmick, I start by coding that gimmick to see if I can. Then I talk to friends and myself about the implications of that gimmick, then write some more code and some descriptions, then alpha-test, then make feelies and/or cover art, then beta-test, then release.

My Inform documents folder has four subfolders: Current, for works-in-progress; Final, for things that I consider polished and done with, such as the Post-Comp version of Byzantine Perspective; Past, for everything that I’m done working on but is not the Final version of that project, such as previous releases of BP, one-off games, and stuff I’m just sick of; and Swatches, for everything else. Current and Final also have a subfolder called “Experiments,” which is for games that I never really intend[ed] to release very widely (such as Sugar).

6

A while back Emily went through five ways of going from a starting premise or idea to writing a game: emshort.wordpress.com/2009/08/23 … mentation/

I did a post-mortem on Fragile Shells that went through my design process beginning with “no way am I writing an escape-the-room game”: granades.com/2010/03/31/making-fragile-shells/

7

The way I tend to work is contrary to the conventional wisdom, which probably means I’m either unconventional or unwise (most likely both).

First, I think about the structure, in very general terms, and decide generally on what is going to happen in each major “division” (for lack of a better term) of the game. Depending on the particular design, the “divisions” might be geographic, temporal, or based on something else. For example, if the game is about a man and a bird, the basic divisions might be (1) boy meets gull, (2) boy loses gull, and (3) boy either gets gull back or dies when he tries to fly and learns that, unlike a gull, he has no wings. At this stage, I make no attempt to work out the plot details for each division beyond that kind of general idea.

Next, focussing on the first division only, I map out, both in geographic and plot terms, the lay of the land on a somewhat more detailed level, identifying each location and what the important plot elements are (i.e., what happens so that boy meets gull).

At this stage, I start coding the first division. Once I start coding, my goal is not just to get a barely workable game; rather, as I code each room, thing, NPC, etc., I attempt to implement not only the essentials, but also the “color” details (for these latter details, design tends to happen simultaneously with coding). The idea is get the first division in reasonably complete shape.

Once that is done, I go back to the design table for the second division. Often, I find that ideas for that have been coming to me all along as I’ve been working on the first division. Once I have the second division mapped out, I’ll code that (in detail), and so on.

A lot of people would probably say this approach is crazy, but it seems to work pretty well for me.

Robert Rothman

8

As with actual prose fiction, I start with very little planning; I feel that planning almost always kills whatever creative spark I had going in the first place. So, essentially, I try and start with some sort of hook, or gimmick (say, the protagonist has no legs or the antagonist has a severe caffeine dependency or whatever), and then slowly build a story around that premise in layers. You know, what does the main character want, etc. etc.

When it comes to setting, I inevitably end up “writing what I know”, as they say. I find that West Virginia can make a backdrop for just about anything as long as you’re willing to use its weirdness to your advantage.

Using this process, I end up writing like six crappy stories, and then condensing the good ideas of each into something hopefully less crappy. I’m in the process of applying this technique to my current game, and slowly but surely, it’s working.

9

Well, I haven’t started that many projects - one, a decade ago, that never went anywhere, and two, my current WIP.

When writing prose, I find that I have to really commit. What’s finished is more a matter of what I stay interested in than what is good. So with my current project, I have promised myself to continue working on it until it is done, and not start any other projects that would suck energy away from it.

Of course I give myself free reign to jot down ideas.

When writing music (with the kind of music I make, ‘writing’ is sometimes the wrong word, but whatever), I go through tons of ideas, and throw most of them away. The ones I finish are the ones that won’t let go of me - that happens with music in a way it doesn’t with prose.

As for the process, I had a devil of a time getting started. I came up with a premise and an opening text pretty easily - it popped into my head as a result of a discussion. But then I had this situation - the protagonist has a seemingly intractable problem. To finish the story, I have to come up with a solution. So I brainstormed for a couple weeks (maybe more) using a tip from Jim Aikin about switching off the inner critic. While I was doing that, I coded up random things for the game’s opening that might turn out to be interesting.

Eventually I came up with an ending I thought would be satisfying and then started thinking about what should come in the middle. I developed a couple puzzles based on the protagonists needs, and a couple based on what I thought would be fun given the environment he was in. Then I spent several months trying to implement all that. As a programmer, I took it as a point of pride that NOTHING should be impossible to implement, as long as I could completely visualize the way it should behave. I still stuck with what I thought were reasonably modest goals but…

…along the way I got sidetracked by writing extensions. I still feel like writing extensions is progress, but I think I’ve thrown away about 3 out of 4 extension ideas that I’ve started. So in that sense I guess I do have “trash” that I write and discard.

I also ended up throwing out a lot of the game’s opening, which was coded before I was really sure what direction I was going. I think it was very valuable for helping me get started, though. Right now I’m in alpha testing and I’m starting to think throwing away more. We’ll see how it goes…

As for details, I’ve tried to at least write room descriptions as I go. But there’s been a lot where I’ve said “I need to just write SOMETHING to get past this block. I’ll deal with the details later.” And then I’ll have detail-sweep days where I just pick up stuff that got skipped over earlier. Alpha testing has been a great motivator for this.

10

Some of the best IF advice I ever was to combine ideas from different games (Emily short, “Developing a Setting for Fantastical IF”). I’ve wanted to write IF for almost as long as I’ve been playing it, I’m not even sure why. My best abandoned ideas, the ones with the potential to actually go somewhere, have always been built on the bones of less inspired ideas, both ideas that I originally conceived for IF or for something else. Even my one published game, the Comp entry “Dreary Lands” from 2005, was based on an idea I had originally thought up for a junior-high short story assignment.

I think I do have an idea I can run with now, and I think I’m approximately in an alpha stage with the project (I had hoped to enter this years Comp a while back). The first thing I did when the idea came to me was to make a map of the core part of the game with Trizbort. Then I used Storybook to write a very crude mock transcript broken down my important scenes, with lots of glossing over unformed parts, notes, and database entries to represent the rooms and NPCs. Then I implemented my map in Hugo code, including only scenery objects and the few puzzles necessary to allow the hole map to be traversed. I tried to implement more, but I got stuck with details I hadn’t fully worked out before. I had to take a step back and write a totally new mock transcript, with more detailed notes on objects and my changed ideas for characters and plot. In this second pre-script, I concentrated on nailing down all the important interactions into sequences that could definitely go into the final game without modifying much more than perhaps the wording of the prose.

I began implementing again before I had completely finished this second script. Once I nailed down the entire midgame and decided that I wouldn’t change anything, I figured I might as well go back to coding. I’m almost done with this second round of implementation, and I’m beginning to be overwhelmed by the amount of debugging that has to happen as I see the game start to come together. :wink:

11

Some more advice that may seem awfully bizarre: Write while tired. I’m talking, like, just-worked-a-12-hour-shift, had-a-crappy-day kind of tired, too. Your mind seems to shut off whatever center of the brain produces writer’s block, and you just write. Try to go as long as possible without resorting to coffee/energy drinks; the more caffeine in you, the more likely you are to get impatient, which leads to you eventally saying “guh, fuck this, time to go to sleep”.

Naturally, your mileage may vary, but I think everyone should give it a shot at least once. At the minimum, you might end up with some pretty entertaining room descriptions. Additionally, try not to code while tired, or at least do any heavy amount of coding aside from new rooms or other easy things; that’s just a recipe for disaster.

12

Looks like you are a huge fan of Stephen King. :slight_smile:

That’s what I do myself. I just start, then it all comes down to something. Never stop. Even when all you are doing looks like “shoveling shit from a sitting position.”

13

You’re right. There’s a state where being tired can make it easier to concentrate, at least for me. That’s why I’ve occasionally had success in pulling all-nighters to get homework done, but I’ve learned that I can’t count on being able to do that all the time, or at any particular time. Mostly, though, I’m too lazy and undisciplined.

As another piece of generic advice, I’d add that it’s worth spending just a little bit of time working on your game if you don’t have a lot of time. If you only have ten free minutes in the morning before you have to go to work or school, I’ve found that it really is worthwhile and even satisfying to spend those ten minutes working on a hobbyist project. You can always run or speed to be on time afterwards. :wink:

14

This, I’ve done. Well, in writing prose, anyway; one of my best stories is due to writing late at night.

this, I’ve also done. Trouble is, I look at the clock and see I have 10 minutes free; ten minutes later, I look at the clock and realize I’m half an hour late. Heh. I try not to do that very much these days; late for class is one thing, late for work is something entirely different.

15

The flip side to this is - allow yourself to rest. One of my breakthrough moments on a recent project came when I said to myself, “No, I’m too tired to work on this, but as soon as I get up in the morning, I will go back to writing.” It gave me time to think about it as I fell asleep, and let my subconscious turn the matter over, and then I woke up inspired. (And I was all proud of myself for being good to my body.)

16

Yeah, I’m a best-while-rested writer, myself. When I’m exhausted but still working, I do graphic design or typography instead of writing.

As near as I can tell, the reason is that I have only one “gear” when writing. I write at exactly one brain-speed. Trying to write while tired has me fighting that, and it’s just unpleasant and inefficient and dreary.

With graphics, I can be meticulous at a variety of speeds. I still don’t get a lot done if I’m tired, but it doesn’t feel like I’m fighting my own gears.

The lesson being: we’re all such very different creatures, really.

17

I think that being tired can really help with imagination, the flow of ideas - that is, the plot, and those things that directly hinge on it. However, being tired is terrible for actually fixing things; once the plot is there, you don’t want to try to troubleshoot (or tie the story together) when you’re nodding off. There’s a time for imagination, and there’s a time for focus; a good story needs both.

So, the moral of this is: if you start tired and wake up gradually as the story goes on, and it’ll be perfect!

18

This discussion reminds me of this question in QI.