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 ?
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?
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.
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.
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.
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.
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.
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.
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.
So some people like code, and some like me enjoy the process of writing my code in prose form almost like it’s a Myst book that Inform 7 offers. It’s a vibe.
That’s actually cool too. I can understand that, it’s setting parameters of things in database form. How would you create a cycling text in strand?
In I7:
The stoplight is a thing in Street. It is fixed in place. The description is "The stoplight flickers and changes to [one of]yellow[or]red[or]green again[cycling]."
Scope is a wily beast, and that’s the type of thing someone can only learn by finishing a game, and that’s why it helps to give yourself the freedom to write something shorter and manageable before tacking the the epic. Good point.
Scope Creep can easily flummox any project, and that’s why it’s important to write small first to see how your idea flow naturally fills in. Ideally you want to know how your game ends and most every element you want to implement before you start. It’s fun and tempting to start a game with no idea where it’s going - that’s good for practice and brainstorming and prototyping, not producing a complete project.
I call that the “brushing the teeth” paradox. You can implement a brush with bristles that are a supporter and a tube of toothpaste with a liquid volume inside a container which has a detachable cap you can UNSCREW and possibly lose if you flush it down the toilet and the player’s mouth as a container with teeth inside but is it fun for the player to INSERT BRISTLES IN MOUTH. BRUSH FRONT TEETH UP. BRUSH FRONT TEETH DOWN. BRUSH LEFT BACK TEETH. SWISH MOUTHWASH…
Or just narrate that the player brushes their teeth when they enter their bathroom in the morning and concentrate on the story. Unless it’s a picaresque meditation on dental hygiene.
// Anything in capitals is a macro, otherwise just text.
STOPLIGHT@ THING
> put it in street
* name
stoplight
* name
stop light
* x it
XSTOPLIGHT. // invoke macro below
// mark "<" for sequence, "<<" for sequence then repeat
// also "&" for shuffle, default random. Can mix, eg "<&" is sequence, then shuffle.
XSTOPLIGHT<<
The stoplight flickers and changes to
* yellow
* red
* green
Mentioning another resource, which I don’t see linked around much but I really enjoyed: IF Gems.
It’s all just quotes from IFComp reviews… but I feel like it gives a pretty well-rounded sketch of what folks love and hate in parser games, and it’s easy to take in bits and pieces.
I’m currently working on my first game. My first go at it was totally open-ended so that the scope just kept growing and growing. I started a new game and quite by accident found I could manage scope by creating a closed environment, in this case a small spaceship. I could lay out an entire map which had very little room to grow since it’s constrained by the geometry of the ship, and then fill that up with puzzles and plot.
I’d like to weigh in with a few thoughts:
[1] As a former programmer, using IF7 is not like programming in Python. It is a new paradigm, but programming background does help.
[2] There seems to be a spectrum of styles of IF stories/games. One one side of the spectrum is the short, terse descriptions that often come with games like Zork. On the other side is the long literary pages of narrative that reads like a story. These seem to turn into choose-your-own-adventure style stories. As an author both of IF and hard copy books, there is a transformation process from one to the other that I didn’t expect. They don’t work, read, or write, the same. It seems that people prefer one style or another: game players vs. story readers. Choose the style you want and that will dictate a lot about how you write it.
[3] You might want to look at Twines too. It is not a fully-functioned as IF7, but it allows you to put together a multiple-branching story quickly. Think of it as writing an outline (Twines) before writing the story (IF7).
Inform 7 is definitely real programming; it’s just disguised. I personally prefer TADS 3 – and I highly recommend the adv3Lite library, which is a separate download. It’s easier to get a grip on than the default adv3 library. And don’t be misled by the “Lite.” It will do whatever you want it to do. It’s just a smoother approach to library design, that’s all.
There’s a lot to learn, no matter what language you choose. Eric Eve has written some tutorial games for TADS – and Eric and I collaborated, some years ago, on a game called “Mrs. Pepper’s Nasty Secret,” for which I believe the source code is available online. (If you can’t find it, let me know and I’ll upload it.) This was using adv3, not adv3Lite. Studying the source code for a working game and then playing the game is probably a good way to learn.
BTW, a lot of us started on Zork or Adventure. I certainly did – on a Kaypro. Wanted to write a game, and eventually (in 1999) I did. I’m not a real programmer, just a ham-handed amateur. Good luck!
