What's your advice for an aspiring IF author? What experiences should I definitely have?

Authoring General Design Discussions
1

So I’m not really new to IF. I played Zork and other IF games on the Commodore 64 back in the day, but even to this day I kind of suck at playing IF. Over the past few years, I’ve tried playing a few comp games, but I’m really bad at puzzles and more often than not I resort to walkthrus. I greatly prefer parser based games that are story driven, but there aren’t many out there that have clicked with me. Perhaps the best one was Worlds Apart by Suzanne Britton. It’s an oldie but a goodie.

So with that inauspicious beginning, let me continue…

I would really like to write IF. In fact, it’s been a dream of mine to write long-form, parser-based, story driven games. The most I’ve ever really accomplished is a small, complete game in Python that apart from my own testing, hasn’t had much exposure to the world. I’ve dabbled in programming for years but I’m getting up there in age, and my latent dream of becoming a software developer doesn’t seem like it’ll ever happen. But I can still program for fun, at my own pace, and if I can just give myself permission to do something as “impractical” as IF I might have a lot of fun.

I’ve been considering TADS. Years ago, I spent several weeks trying to learn TADS 2, printing out all the manuals and creating a few test games that were really nothing more than programming exercises. Then TADS 3 came out, and for some reason all of the prior effort seemed like a waste and stole the wind out of my sails. Lately, I’ve looked at Inform 7, and maybe it’s my nerd bias showing, but I don’t see the natural language as real programming. In fact, I swear I have some mental block that prohibits me from grasping the notion of creating a complete game in Inform. But TADS 3 seems like something I could get a handle on, though it would take time. (I don’t mean to start any language flame wars, but
that’s where I stand.)

Having said all that, what experiences do you think it is important to have to create the type of IF I’m interested in? Are there any games that I should definitely play? Are there any code bases I should definitely look into? Do you have any general advice about how to see a project through, and the hurdles I might inevitably face? Are there any articles or blog posts you recommend on what it takes to make a good parser based IF game?

I’ve pretty much ruled out entering games into competitions for now, but if you recommend doing that I would be interested in hearing the arguments in favor.

Thanks for reading this far, and I appreciate any responses.

8 Likes
2

I started to type up something more verbose here, but instead I’ll just suggest a few points:

  • Start out with the smallest project that interests you, and focus on just getting it done.
  • Just shipping a game is hugely valuable experience because a surprisingly large amount of doing it involves all the “other stuff” apart from just writing the game itself.
  • Actually shipping a game, if you’re like me or literally everyone else I’ve personally talked to about this, is a huge psychological boost. After you’ve shipped a game you know that you can actually do it, because you have done it.
  • This is invaluable because it can’t be over-stated just how much easier it is to not release a game than it is to release it. At roughly a billion points during development it will seem like you’re just wasting your time, this thing will never be done, &c, &c, &c. Knowing what you actually need to do to get to the finish line and knowing you can, because you’ve done it before, is invaluable.
  • When in doubt, just muddle through and get it working. There are exceptions, but in general it’s easier to overcome inertia in fixing one last bug in [some feature] before release than it is to overcome the inertia about “how am I even going to implement [some feature]”.
  • Do not be afraid to ask for help. There are a lot of problems in programming and game design that are difficult to even articulate if you’re not familiar with the subject matter, but for which there are elegant, ready-made solutions out there. A clumsy description of a problem in a game dev forum is usually waaaaay more effective than trying to google around for a solution to a problem you don’t even have a name for.

Beyond all that, I tend to prefer TADS3 over Inform7 because I always feel like I’m wrestling with the grammar in Inform7. That said, all IF authoring systems seem to be very good at helping you if you’re more or less keeping to coloring between the lines, and they rapidly become less friendly as you try more unusual stuff (in terms of IF design).

Inform7 does seem to be much better at hand-holding novice writers who aren’t already familiar with programming. In fact it’s difficult to imagine a system better suited to getting a novice writer to the point where they actually have a working game faster. Inform7 also continues to be in active development (which TADS does not appear to be), and there appear to be far more active users of it in places like this forum.

10 Likes
3

I agree totally with jbg. I prefer TADS 3 and Inform 6. However, I have yet to publish a game myself. I have one finished. It was written in Punyinform. I’m waiting for either another Punyjam or Introcomp to release it.

The IFWIKI is a very good resource.

Welcome. I’m looking forward to your future work.

1 Like
4

If you’re inclined to programming, go for TADS3!

2 Likes
5

I’ll also endorse @jbg’s post as excellent advice: the single most important experience to have prior to releasing a game is that of just having finished working on a similar game, of slightly smaller scope and ambition. Make the small, simple, silly games that your pride says are beneath you: the more you do this, and the more recently you do this, the more you can accomplish.

4 Likes
6

Something I found useful and interesting was to simulate some familiar location. I created, in Inform6, simulations of my house and the CS department at my university. There wasn’t any sort of a plot or any way to win or lose; the player just walks through manipulating things.

3 Likes
7

You know, if you want the programming-feeling experience but want to use an established engine, Dialog is actually very complex, based on the Prolog language, and is fun to learn to use as well as making excellent games.

I’d strongly recommend making a small game first, letting people see it and comment on it, then learning from it before making a big game. (This seems to be the common thread here)

It’s hard to get feedback without entering some competitions. Fortunately there are a lot of low-stakes smaller ones like Ectocomp for Halloween or the text adventure literacy jams.

If you search if wiki for Craft articles, a lot of them do a great job of describing how parser games can be made. They’re about 20 years out of date, but I still find their advice useful. Also searching this forum for Postmortem will get you great advice.

Great games to play would include things that really use the medium in compelling ways, like Slouching Towards Bedlam, Metamorphoses, Deadline Enchanter, Into the Facility, Delightful Wallpaper, etc.

7 Likes
8

There is a lot of good advice in this thread, so I’m going to try not to echo stuff that others have already raised. A couple additional thoughts:

  • The language you write your game in mostly doesn’t matter, so just picking whichever seems to best fit your work process is totally fine. There’s definitely more folks doing Inform than doing TADS than doing Dialog, but you’ll be able to get support on any of them. The one exception to this general rule is if you wind up picking a language that doesn’t allow for easy play via the standard interpreters and/or the web (like Python, which you mention) – this may be worth doing, but I’d be very careful about it since this will likely really reduce your audience.

  • Similarly, I’d be careful about forgoing the attention entering a comp or festival can bring you. Even if you’re not competitive, it’s a great way to get your game in front of folks and almost guarantee some reviews and engagement. Games do get released outside of the big events, of course, but it’s much harder to get people to notice, especially for a first time author. If IF Comp seems too big or intimidating, Spring Thing and Parser Comp as well as the shorter, themed competitions are definitely options (Spring Thing and Parser Comp might be your best bet, from what you’ve said).

  • I think the most important thing you can do to create the type of IF you’re interested in is to create the type of IF you’re interested in. That is, there’s no substitute for just jumping in and trying to implement your ideas; from that you’ll very quickly learn what you need to learn, which will be maybe 50% stuff you probably had on your radar screen at the outset, and 50% stuff you would have had no clue you needed to learn.

  • With that said, there’s no substitute for playing a lot of games and thinking critically about them – I like writing reviews because it helps me clarify my thoughts about what works and what doesn’t work. Trying to play stuff that’s very similar to what you want to make is of course a good idea, but I wouldn’t limit myself to that; in particular, if you’re trying to make a parser game that relies on story, rather than puzzles, for its engagement, I think you’d be very much missing out if you didn’t check out some choice-based games to see how they involve the player without using traditional parser gameplay crutches.

Having said that, here’s a list of stuff you might want to check out, in addition to what others have flagged:

  • Constraints – a puzzleless meditation on the limits of the parser (and of agency more broadly); 19th place in the 2002 IFComp is maybe not the best advertisement, but I think this game is just great at getting your creative juices flowing.

  • The Best Man – a choice-based piece that does a great job presenting an unreliable, unlikable narrator.

  • The Weight of a Soul – this has some puzzles but they’re few and relatively simple, with the long, YA-style story the major focus.

  • A Rope of Chalk – interesting storytelling techniques in this Rashomon-style take on a college art show gone badly wrong.

9 Likes
9

Just to add, there’s also IntroComp. I understand it will be back for next year. It’s for games that aren’t complete, but still interesting enough to let others play.

You can enter a wacky idea and get feedback or, say you’ve written half a game and not sure where to take it. You’ll get to know people’s reaction to it.

However, you may or may not then be able to enter the completed game in other comps (check rules).

Open question: can an IntroComp game, after completion, be entered into IFComp, SpringThing or ParserComp ?

3 Likes
10

  • IFComp specifically does not allow entries that have been fully or partially released publicly and specifies they must be “new” works that are debuting in the Comp. They can only have been privately beta tested and not had a public demo - therefore IntroComp entries are not subsequently eligible for IFComp.

  • Spring Thing states: “Your game should be unreleased at the time the festival opens.” I believe this applies to Back Garden, but Back Garden games can be incomplete, or a demo or more experimental.

  • Parsercomp currently specifies “entries must be previously unreleased.” I’m inferring that means in their full form, because the FAQ states:

Can I enter the full version of a game I entered into IntroComp?

Yes.

4 Likes
11

Hey thanks for the clarification. So,

  • IFComp = no
  • SpringThing = maybe?
  • ParserComp = yes

So SpringThing needs to be a bit clearer with its definition of “unreleased”. Clearly the completed game is unreleased, but not the partial game.

A better question for SpringThing might be:

Can you enter a game that already has a public demo?

2 Likes
12

Do what you want to do. Some of your success will depend on how stubborn you are. I wrote my first game last year, which was the first time I had ever coded anything, and it was way bigger and more complicated than a newcomer’s project had any right to be. But I am STUBBORN, and so with a lot of help here on the forum, I finished it.

There is much advice here to take on smaller projects first. I’m absolutely certain that this is wise advice. I’m also absolutely certain that some people just aren’t built that way. If you’re a surly old mule like I am who wants to do this thing and not that thing, go for it. What’s the worst thing that could happen?

I have always suspected that if I could do it, it isn’t real programming. I could never have done it without I7, though.

8 Likes
13

A lot of good advice was already given; I’ll just add some more links:

Emily Short: Idea to Implementation – Emily Short's Interactive Storytelling

Mike Roberts: IF Design: In Practice (has some TADS-specific parts, but most of the article is generally applicable) and IF Design: In Theory

Graham Nelson: The Craft of Adventure : Graham Nelson : Free Download, Borrow, and Streaming : Internet Archive
(contains the famous “Bill of Player’s Rights”)

Several authors: IF Theory Reader (here, especially the articles in the Craft section)

7 Likes
14

The Theory and Practice section of the IF Resource links sticky post links to lots of good stuff. An overwhelming amount of stuff, actually, so try a little at a time and go back to coding something… don’t get bogged down in thinking you need to have read everything.

3 Likes
15

Spring thing lets in introcomp games. I entered my introcomp game into it, they made an agreement I think.

2 Likes
16

I will add, not to change your mind but because I find this very interesting from a language design standpoint—Inform’s natural syntax isn’t actually that much more forgiving than TADS or Dialog. You still have to be very precise about how you word things and a pronoun in the wrong place can throw everything off.

The big difference (and the reason I really like I7) is that the end result is significantly more readable, which helps a lot when you come back to an old project a couple years later. I’ve found it a lot easier to pick up an old I7 project than an old Dialog project, and it’s faster for me to figure out where things are and what they do.

That said, if you don’t like the natural-language aesthetic, I also recommend Dialog. It feels very clean and elegant to use, without the historical cruft other systems have accumulated over the decades.

7 Likes
17

This is true. There is a weird curve of natural language vs “what I7 understands” and I’ve had stumbling moments where what I wrote made perfect sense to a human but wasn’t quite right. Luckily that usually only occurs with the more advanced principles. If you don’t like natural language, you’re probably never going to like I7.

One thing it can do is get non-coders used to the brain-space of coding concepts in readable language. A person with no coding experience will likely immediately comprehend

The ancient server is scenery in the server room. Understand 
"machine" and "computer" and "old" as the ancient server. 
The description of the ancient server is "an ancient server".

whereas Inform 6

Object server "server" server_room
    with
        description "an ancient server",
        name 'server' 'machine' 'computer' 'ancient' 'old',
    has scenery;

or ZIL


<OBJECT SERVER
        (LOC SERVER-ROOM)
        (DESC "an ancient server")
        (FLAGS NODESC)
        (SYNONYM SERVER COMPUTER MACHINE ANCIENT OLD)>

might as well be hieroglyphics. But seeing them all together can help people understand more advanced code structures.

[Example via A Tale of Two Languages | Linux Journal]

4 Likes
18

Yeah, everyone writes their own way and (in general) it’s important to keep that in mind when you’re scoping out a project.

That said, nearly everybody seems to have a built-in rule in their heads that goes something like, “When in doubt, write more.” And so games (and novels, films, and my forum posts, for example) have a tendency to grow beyond their originally-conceived scope.

I think there’s also very IF-specific a tendency to commit what we might call errors of verbosity-through-mimesis: that thing where if you implement two rooms then you want to implement a corridor between them and if it’s a long corridor then maybe it need to be two locations, and if it’s in a multi-story building then every other floor gets a two-location corridor by default just to keep things symmetrical, and then for one puzzle you need for there to be a bathroom off the corridor and so all the corridors are suddenly three locations long…and pretty soon you’ve got a building that you really needed two rooms in and now you’ve got two dozen. You can see this happen in a lot of classic IF, like all those nearly-identical color-coded corridors in Starcross.

Which I take the time to talk about not to argue that all games should be small or that you should fret over adding every new location—I actually tend to prefer games that swing for the fences in terms of scope—just that for most people the natural tendency is to err on the side of adding too much and so if you’re a new writer it’s something to watch out for.

6 Likes
19

I kinda think it’s exactly the opposite. A person with no coding experience absolutely will not comprehend that example, but their mistaken impression that they do can get them over the initial “oh no this is complicated I can’t do this” stage of learning a new skill. And by the time they realize that oh no I don’t really understand any of this and the rules are way more complicated than I thought they were…well, by then they’re already at least somewhat comitted.

Inform7 is the “the first one is free” IF authoring language.

2 Likes
20

I don’t like any of those syntax. Here’s how i do the same thing in strand. I made this language for authoring expediency and very light on magic syntax.

SERVER@ THING
> put it in server room
* name
the ancient old server
* name
machine
* name
computer
* x it
It's an ancient server.