So how dd you write a game?

A thread here, and my own problems made me ponder a question.
Many people complain about how they have ideas, started implementing, and then lost steam or got distracted (by Steam?).
So I would like to use this thread to collect people’s advice or stories on how they actually finished a game, so others can be inspired by it or take some advice away from it.

Deadlines are probably my best motivator, along with some kind of guideline or restriction.

Game jams and comps are my bread and butter because they give me parameters and set dates by which my work has to be done. I’m much slower to finish games with open-ended end dates.

  1. Same as inu - is there a deadline? Time to get cracking! Even artificial deadlines are valuable.

  2. There is no deadline. There is no pressure. I have complete freedom to screw around with a game idea, even if I know the idea is infeasibly large - or ideally if the idea is infeasibly large. If I know that I can’t complete the game I’m working on, then I can evaluate the concept without any pressure whatsoever. This is weirdly effective for me.

If I fall in love with that idea, then it’s time to haul the concept around into something that is potentially game-sized, drop a deadline on it, and see what’s actually feasible. But at that point, I’ve done enough work that I’m personally invested and I have momentum.

Yes! A deadline is crucial for me! :smiley:

On the other hand, if the deadline is to soon that’s demotivating.
For me (depending on the project) a deadline 6-12 months away is ideal to start the development of a game and be able to finish it! :slight_smile:

I don’t think self-imposed deadlines work that well for procrastinators, though.

I’ve been using a “don’t get stuck” technique: as soon as you stop writing or doing anything else because you don’t know what to type or do, leave it be and do something else. Especially with games there’s almost always so much to do that you can easily pick up some other part to work with. This way you keep moving on all the time and you don’t stop because of frustration.

That’s why I like the “no pressure” model - it means I’m only working when working brings me joy.

But another way of handling this is to add weight to those deadlines, and make them a routine occurrence rather than One Big Deadline.

Here’s a non-IF personal example:

I wrote a novel by promising my mother that I was going to write her a novel in weekly installments. It meant that every time I failed to hit a weekly deadline, I was letting someone down that I didn’t want to disappoint.

As time went on, though, it got harder for me to hit those deadlines. Time to up the ante! So I moved to a sit-or-work model where I spent an hour each day in front of the computer. I could work on the novel, or I could sit there if I didn’t have the energy to work, but I couldn’t do anything else. This turned out to work surprisingly well. (I don’t handle boredom well.)

Further on, I got less reliable about my sit-and-write sessions, so I reinforced them with HabitRPG ( Ante upped again! Now, I was not only letting down my mom when I didn’t write, but losing experience when I didn’t sit-and-write, which annoyed my friends playing HabitRPG with me.

I don’t know what I would have done next, because I finished the novel. But you might try a similar approach to avoid procrastination. Make yourself accountable, and then give yourself rewards or remove rewards based on your progress.

I was thinking of tweeting a daily or weekly wordcount, but maybe that might seem a bit attention-seeking?

I like the sit or work model. I like it a lot.

I rarely think in word count when I’m writing IF (if I’m doing that kind of tracking, I check off mechanics or rooms or bugs on a list), but if it works for you, why not?

And one tweet a day or one tweet a week is is hardly a disruption. I wouldn’t worry about it.

You might alternately try a visual accountability tool, such as the options listed at … er-widget/.

Yes! This is one of my most-used methods: if I really want to make myself do a thing, I blab about it to a select handful of people I trust to hold me to it.

Oh that’s clever; I like it.

I attended Hacker School, and among other things it taught me a lot of neat productivity tricks that seem to work on me. The whole routine and structure of HS is designed for happy productivity: casual checkins every morning with a group of 4-5 other people, with the group changed every two weeks so you don’t get too complacent; weekly presentations if you want to show off your work, which is just long enough to make you push for presenting this week instead of having to wait; easy access to help, which means less ragequitting; lightweight required hours of attendance, which in retrospect is a lot like cveneseltine’s “sit or work” strategy above; general atmosphere of genuine interest in everyone’s work but without one-upsmanship, meaning you want to show your friends your progress on cool things. (I additionally had another productivity booster about halfway through HS, which was my significant other’s birthday. You can probably guess when that was by looking at my github commits.)

The challenge is to integrate that sort of thing into my everyday life.

Edit: oh and I also wrote a daily progress blog, and knew a lot of people who had personal rules about git commits per day. I’m a big fan of “you have to get something done, even if it’s really trivial.”

Good call re: blogging! I find blogging invaluable for helping me understand the value of what I’ve done, especially when it’s added together in weekly chunks.

I might feel like I did nothing in a given week - but if I actually write a weekly summary, then looking back at “built 5 rooms, designed puzzles X and Y and implemented puzzle X, started work on shouting mechanic” shows me that I’ve actually done a lot of work, even if it “feels” like all I did was play on the Internet.

Progress blogging is… not helpful to me, largely because I’ve used it before and still failed to complete a project, so it mostly brings up the spectre of vaporware.

(Admittedly, the times I’ve tried it have been on impractically ambitious projects - the sort of thing that, in retrospect, were never going to work without a professional-calibre team over a couple of years. But having used a method once and having it fail makes it much less motivating the next time around, even if the failure wasn’t due to the method.)

I usually find deadlines leave me rushing to finish a game in time and often releasing a game I haven’t had time to properly test or even play through more than once or twice. They’re great for actually getting a game out, but the quality of said game leaves a lot to be desired.

Like everyone else said: deadlines.

With It, I started keeping a changelog, and pushed myself to have at least one entry in it every day. There’s one day where literally the only changelog entry is “moved code for X from file Y to file Z”, but I’d opened the code and looked at it, which kept it fresh in my mind and stopped me from completely losing momentum on it.

With Robin & Orchid, having a collaborator helped keep me focused. Losing my job and being unemployed and bored for several months helped too.

My own experience may not be typical. First, I have to have an idea that I actually care about. Second, having the added incentive of learning an IF authoring system is very useful – I wrote “Flustered Duck” so I could learn I7, and right now I’m working on a new game partly in order to learn adv3Lite.

With a large game, I find it’s useful to work on whatever interests me on a given day, without getting distracted by the mass of things that I haven’t even started yet. (Today I only had an hour, so I set out to write a simple scene using the new adv3Lite Scene mechanism. There’s still a whole lot to be done to bring the scene to life, but I got the basics laid down.) Some days I may spend an hour just reading and adding to my notes on the design, without doing a lick of coding. That’s useful too.

Draw a map. Or make one in OpenOffice Draw. That may make the world of the game feel more real to you. Right now I have a fairly complete map, even though some of the rooms are not yet coded (and none of them have all of the scenery they’ll eventually need).

As Emily said, having a suitable collaborator can keep things moving forward. I collaborated with Eric Eve on “Mrs. Pepper’s Nasty Secret,” and one advantage was that Eric lives in England while I live in California. So I was generally working while he was asleep, and vice-versa. Each day when the work session started, there was a new incoming email with some fresh code.

Scattered notes. Some may be repeats, but hopefully they add a different view, or reassure you it’s not just 1 person who feels this way:

  • Yup. Deadlines are a big help for me, too. External ones work best.
  • I also like tracking how much I’ve written per day, or how big my game’s code is. Quantity != Quality but it’s also useful for cutting through a backlog of ideas.
  • I also like to have a file of notes, and when it gets big enough, I realize there’s an actual game there.
  • Bitbucket works great for issues and stuff I want to do. If you don’t use it, have a document of loose ends you need to tie up. Look at it every few days. You never know when a penny will drop.
  • Echoing Jim’s point, Trizbort is great for creating a world map–my latest new project got a boost just from labeling and organizing rooms. A walkthrough is also useful–once a week, go through the game to see 1) how to expand the story and 2) how the player can mess up. Even if you haven’t changed any code or slacked off, the time off will help you see the game differently.
  • Echoing Emily and Jim’s point, collaborators can work well–but “buddies” for lack of a better word work well too. Trade your projects. Seeing how a friend is moving ahead on their project can be uplifting–or it can give the right sort of jealousy to move ahead on your own–or it can even make you say, hey, this game may not be perfect but it’s fun, so I don’t have to be perfect! Reciprocal trading of testing is also quite nice if the chemistry works. Collaborators have helped me very much with the past 2 IFComps & even with post-comp revisions. One of them didn’t have time to enter in IFComp 2013, but their help two weeks from the deadline was a morale booster and fixed a few bugs and added a few features.
  • Similarly, testing a game can give you a new perspective. Mistakes aren’t the end of the world, but you may find that testing someone else’s 1) gives you things to try and questions to ask of your own work and 2) helps you be forgiving towards their mistakes, so you know players may be forgiving towards yours. That doesn’t excuse bad mistakes, but it takes pressure off. I also found that finding certain mistakes in others’ work gave me confidence that testers would find my own mistakes, so I wasn’t worried about little stuff when trying new things.
  • As Emily mentioned, changelogs are great if you can keep track of them. They can tell you what to test or what to ask people to test. If you can save daily copies of your files, you can find even more things that might’ve regressed, or new features to add. It requires experience to do this, though.
  • I put ??'s in my code where I’m confused. This is useful as I can search for them and, after a week or month, I found lots of stoppers aren’t really so bad, but others, I needed technical help. So I asked here.
  • (Re-)read Aaron Reed’s Inform 7 book or other documentation out there. I’ve gotten so much out of it. Even reading TADS docs (as an Inform programmer) opened me up to possibilities as well as ideas of how things should be structured for a programmer, or ways I limited myself saying “Gee! I better be happy what I have with inform!”
  • Proofreading game text with respelt can turn up stuff. Sometimes I don’t feel like anything big, so I do proofreading, then I notice something I can work on behind a typo, and it can snowball from there. I didn’t try to start too big, but I worked into it. Conversely, I don’t worry too much about typos when writing a first draft. I can let computers–or, if they miss stuff, my testers–fix the detailed stuff.

Also, listing the sort of games I’d like, or even what’s blocking me from writing the sort of game I wanted to, is a big help. Singling out games I like and what they didn’t do is helpful too–not to criticise them, but maybe to explore parts they didn’t have time to. That’s how Nord and Bert inspired Shuffling Around.

I think it’s also useful to alternate between day-plus stretches of technical stuff, creative stuff and programming testing. It’s hard to change gears! I have to admit I don’t even compile the source for some of my games if I am just adding background text or “creative stuff” that doesn’t affect compiling. I can always play through the changed areas later. YMMV.

I must check out HabitRPG. That sounds fun!

Edited to add one more point:

  • if you’re at a roadblock, ask yourself “what would a more creative person than me think up?” or “how would a more organized person plan things?” or “what would someone who procrastinates less than me do right now?” or “what would a more advanced coder than me do?” This sort of fooling yourself for your own good may not give you an answer, but it will often lead to it, or lead you to the right people to ask.

I figured this topic was still new enough to be revived and relevant to the question(s) I want to pose of some of the more experienced authors out there, but if I’m incorrect I’m sure the mods will split a new thread. Most of the posts in this thread seem to be related to motivations for finishing a game, how to avoid just letting a project languish indefinitely, or tips for overcoming writers’ blocks. It is all helpful advice but what I am currently curious about is:

How do you organise your game during the writing process?

To be more specific, here’s my background. I have sporadic coding/programming experience outside of gaming contexts, but I am by no means fluent in any given programming language. A while back, I discovered Quest and decided that I wanted to make a game out of one of the stories that I have been writing. So I used the online GUI at first, but decided that to learn how to figure out the programming so that the game wouldn’t be buggy and so I could figure out how to implement puzzles and get feedback on those things, that I would put my pet project on hiatus and create a basic game with a barely-there contrived plot to simply learn those things. I put the resultant game through testing phases and while I haven’t finished implementing 100% of the feedback, I learned tonnes and once I actually sit down and implement the last few things into the programming, I will have my first game ready for release (yay!).

Now that I have figured some stuff out about how to author a game, and after joining this forum, I’ve decided to make my new game in Inform 7. So again, as I am putting together the source for my game, I will be learning the language of the program and figuring out bugs along the way. My problem here now is that my game is a fairly ambitious project, and I am finding it troublesome to organise my thoughts in a way that will give me a coherent pattern to follow as I am working on it. I found a post somewhere just recently on Emily Short’s blog about how she organises her source in Inform 7, so I think I will do my best to follow her advice and I should be good on that front. I also have downloaded and started a file for mapping in Trizbort. And I have a word document that storyboards the actual plot, rooms, and characters of my story set up like a transcript for the different categories of interactions with room/object descriptions, NPC interactions, etc. It’s how it would look if I was playing the game instead of writing it. I also have thought-webs and flow charts for putting together the puzzles and the over-all plot(s) of the story I’m telling. So it seems like so far I have a little bit of everything, but nothing complete.

My question then is the process in which experienced authors go about putting these things together into a whole project.

Do you just sit down and start coding something? Do you map first? Do you finish the story and puzzles first?

I have some of the rooms mapped out in my head, I just need to get them down. And although my game will advance the plot based on things discovered as the PC explores and interacts with the setting, the exact placement of items and rooms has a certain level of flexibility to accomodate the puzzles as I work them out and a certain amount of rigidity based on what/where my setting actually is. I know my story, but I am trying to leave some flexibility for my puzzles in it in case I need to change stuff based on:
A) the limitations of Inform 7 (less likely);
B) the limitations of my abilities to properly get what I want to do working in Inform 7.

I am pretty attached to the story I want to tell, and I think if I do this well I can make a game that people other than just me would enjoy playing. I guess I am just looking for some guidance and suggestions. Any help would be greatly appreciated, and sorry for the slightly ridiculous length of this post.

I commented earlier in this thread about my general game creation process, but since I’m currently working on my Shufflecomp game, here’s what I’ve done so far:

  1. Listened through my Shufflecomp song options.
  2. Came up with a core game concept based on one of those songs.
  3. Concepted the play experience - which is to say, “What should the player’s experience of this game have been, after playing?” It’s about what I want the player to remember afterward - what’s distinctive about this specific game.
    2.5. Based on the play experience, designed the core plot and outlined characters on paper.
  4. Built a map of the game rooms.
  5. Started a game file and set up the code infrastructure.
  6. Started coding the game proper.
  7. Sorted out some basic mechanics/puzzle structure in my head.
  8. To be continued…

@xavea, did you read the Emily Short post about the three or four ways of writing a game? One way is to write a transcript from start to finish (some of which you say you have) and code that. The transcript doesn’t include everything but it has a start, middle, and end. So perhaps try writing a complete transcript, and then code everything you need to play that transcript.

Thanks for the tips, guys! Last time I wrote the puzzles and plot while I was coding, this time I seemed like I was jumping in too much too fast and just got overwhelmed. I will keep on with my transcript, then carry on with my map. :smiley: