Hey,

Probably been asked but I can’t find it.

What IF Comps are there, and when are they due?  The smaller and less
official the better.

I’m just getting into coding, and have had to put my dream game on a
back burner.  It’s too hard.  I am looking for direction.  I just missed
the ‘McDream Comp’ which would probably have been perfect, but I’m
looking for some small comps to direct my efforts.

cheers =D.

Can score notification (not scoring itself) be disabled via code in
Inform 7? I am attempting to implement a more unobtrusive scoring
system (where points are still recorded, but only shown when the user
requests them and at the end of the game). Is there a way to silently
award points, or would I be better off simply overriding the scoring
system with my own award handler?

This is a bit convoluted, so please bear with me. I’ve created a "put under"
verb, and in certain circumstances I need the second to be able to respond
with its own customized message, along the lines of "That would be a nice
hiding place, but perhaps there’s a better solution."

The problem is, the before property of the noun is being called, when I will
almost always want to call the before property of the second instead with
PutUnder.

One hacky option would be to declare PutUnder a reverse action, but that
would probably have unintended bad consequences. Another option would be to
give the thing that has an underside (a bed, perhaps) a react_before. Is
that the optimum solution? (What I’m looking for, I think, is the Inform
equivalent of a TADS 2 verIo routine.)

Just to be clear, at the moment I’m not actually planning to create an
under-hider object (though that may become desirable at some point). I just
want to have the bed respond instead of the held object during the before
stage.

Thanks for any suggestions.

–Jim Aikin

As IFComp season fast approaches (faster for those actually working on
games, I’d imagine), I’ve compiled a helpful little list of the five
things that are most likely to send games spiralling into a pit of
snarky reviews. I suppose this list is inspired by a vague and probably
vain hope that this might reduce the number of games I’ll hate in
October. It’s far from exclusive, but hell, it’s a good start.

In reverse order then:

5. Underimplementation

If >X ME returns the default response for whatever platform you’re
using, then you’ve underimplemented. If I try to examine any noun
mentioned in a room description and it tells me no such thing exists,
then you’ve underimplemented. If I can pick up an egg-whisk, and yet
have to >PUT WHISK IN EGGS. TURN WHISK then you’ve underimplemented.

Solution: Don’t be lazy. Implement everything you can think of. Then
think harder and start again.

4. Not proofreading.

I can handle the occasional typo and spelling error. I can even handle
misplaced apostrophes every now and then. Not excessive amounts of them,
I’ll be reasonably happy if you’ve made an effort. But I become deeply
annoyed if any of these things happen in the first screenful of text. If
you can’t be bothered to proofread even this much, then I probably can’t
be bothered to find anything good to say about your game.

Solution: Proofread.

3. Making excuses for your game.

The purpose of an ABOUT section, or preable should be to tell the player
about your game, not to express your own low opinion of it. If you tell
me your game isn’t very good, then I’ll be only too happy to agree and
move on to a game written by someone who actually thinks I’ll enjoy
their work.

Nor do I care if you’re a first time entrant to the competition. Hell, I
don’t even care if you only began learning Inform a couple of weeks
before the deadline. There aren’t my problems. Trying to make me feel
sorry for you and your game won’t work. I’ll freely take it as an open
invitation to eviscerate your game in reviews.

Solution: Have some confidence in your game. If you don’t have any, then
don’t enter.

2. Inflicting your overblown angst on players.

Every damn year there’s one or two games that are evidently the product
of some awful, tragic, terrible, tragic, heartbreaking, tragic tragedy
that befell the author. The tragedies involved are generally on the
level of "I love her so much, but that fucking whore broke up with me,
why can’t the bitch realise how much I care?!" Such melodramatic
effluvia, usually presented in the form of a transparent allegory, are
hugely dull. The IFComp judges are not your therapy group.

Solution: Channel your angst into something useful.

1. Overwriting

This one’s probably just me, alone and gibbering in the darkness. Past
results have shown that a fairly large segment of the voters have zero
literary appreciation. Seriously, these are people who think Jim Theis
was an unsung genius. If you write badly, but with enough confidence you
can actually fool people into thinking you’re writing well. But please
don’t.

I don’t mind servicable prose. If you’re not going for a literary game,
then that’s fine by me. But if you’re writing a game where your prose
forms a large part of the experience, don’t try to convince the reader
how great a writer you are. Specifically, don’t show off your amazing
vocabulary for no good reason. Your astounding knowledge and/or
ownership of a thesaurus does not impress me. Words have subtle shades
of meaning and your immature posturing has the same effect to the
fragile structure of prose that a monster truck has to the fragile and
brittle limbs of an elderly grandmother.

Solution: Become comfortable with your own writing style.

–
James Mitchelhill
ja…@disorderfeed.net
http://disorderfeed.net

Hi,

I was wondering if anyone could held me out. I’m trying to get text
like this:

"The rock and the camera fall out of the womb onto the ground."

I have this code:

When the Plant loses interest:
        list the contents of the womb, as a sentence, using the definite
article;
        say " fall out of [the womb] onto the ground.";
        now the everything in the womb is in the Chamber;

The problem is that the first letter of the list isn’t capitalised.:

"the rock and the camera fall out of the womb onto the ground."

I could reword it, but I’d like to know if the effect is achievable.
I’m probably just missing something. (The above code doesn’t have the
special case of having only one object in the plant…but I can add
that after I’ve sorted this)

Can anyone help with the capitalisation?

Sir Pyke

Inspired by James Mitchelhill’s recent post on bugbears for IF Comp
judges, I’d like to offer some hints that I learned from entering the
IF Comp last year. As a quick recap, I entered my first game "Mix
Tape". It got equal 18th place out of 36. This post is not about the
game itself, but what I learned from writing and entering it, so
please keep this in mind.

1. Betatest, betatest, betatest
You need to leave a lot of time to do betatesting. You need to have
several testers. You cannot test your game. Your friends who aren’t
familiar with IF cannot test your game. Your mother cannot test your
game.

My mother didn’t look at my game, but I failed on the other bits. In
the real world, I had one less week to work on the game because I was
going to a conference in the week before IF Comp was due. I knew this
and didn’t plan accordingly. I was writing and testing until a few
hours before my flight left at 6am. While I caught a few bugs, there’s
only so much you can do. You’ll be too familiar with the game to bring
it close to the rough parts of the implementation. I had a few friends
giving me feedback under extreme time constraints, which was great,
but I should have allowed for more time, more testers and a few more
experienced testers. My personal feeling is that you need at the very
least a month before submission to test. This gives you and your testers
breathing space. It also allows you to implement cool additions that
make the game experience smoother.

Another way of looking at it: do not, under any circumstances, believe
that IF Comp judges are there to betatest your game or will be as
forgiving as your testers. I didn’t personally feel this, but if
anyone gets the feeling that you didn’t, couldn’t or wouldn’t betatest
your game before submitting it, you’ll be torn to pieces.

2. Know your scope
IF Comp games can only be an hour’s worth of play. If you leave time
for judges to look around, poke at the cool bits, and take their time
thinking about their review, then you’ll do better. On the flip side,
don’t try to stuff too much into your game. You have a deadline to
write to.

For those unfamiliar with Mix Tape, the basic premise was to tell a
break-up story as a mix of songs accompanying scenes. The game I
entered had (basically) 6 tracks. Throughout development the number of
planned tracks depended on the songs I wanted in, and some philosophy
regarding the best way to order a mix tape. I didn’t think that adding
a single track added weeks worth of work. When the deadline quickly
approached a few tracks were ditched, and others had their
implementations cut drastically short. The original idea was to have
two sides (Side A and Side B) where one side was the break-up story
and the other was IF inspired by random songs. This was far too much
work and the game would have been too eclectic even if I did finish
that plan.

My approach was essentially the wrong way to go about it. Have a plan,
fulfil that plan and then maybe add more if you have loads of
time. This requires you to plan well ahead and know how much you want
or need to put into the game. Keep your scope tight and the game will
be more powerful as a result.

3. Know your audience
Judges come from all walks of life. Make sure your game appeals and
makes sense at a base level to everyone. Not everyone knows what you
know, and they may not get your in-jokes, jargon, references or
cultural assumptions. For example, if you write a sci-fi game, make
sure it’s not only for hardcore sci-fi fans. A good way to do this is
to give the game a good story or characters. Beware that both of these
things should not rely on your genre. If you confuse or ignore your
judges, they will respond. Some will not rate your game. Some will
rate you harshly. IF Comp is for a wide audience. Respect this.

Mix Tape has a lot to do with music. More appropriately, it has a lot
to do with music I listen to. All the tracks I refer to are tracks I
own. All the bands I refer to I know. Most people wouldn’t. It’s fair
to say that very few people were familiar with all the songs I used as
the basis for my game. Part of the problem is that I referenced a band
called Little Birdy, which is pretty big in Australia, and maybe
Japan, but that’s it. This meant that one of the foundation songs of
my game would make no sense to a lot of people, and so the whole
premise stumbled. I also had a few references to the reasonably
obscure Japanese band Cibo Matto. One reference can be ignored but I
made the frequency and prominence of the references too large. One
reviewer exclaimed in their review: "Who the hell are Cibo Matto?"
Pick your references well and make it accessible and not distracting.

Another problem Mix Tape had was that it was a break-up game. This
translates to a sad, emotional game. A lot of people got bummed out by
the theme and I didn’t make it uplifting enough at the end (if the
player got that far) to redeem it. Make sure your players can take
away something from your game other than a bad mood.

4. Survive the judging period
You might feel exhausted from all that IF writing to judge any of the
games but your job isn’t over. Play, rate and review the other games.
You’d want them to do the same for you. Give feedback to the other
authors. Thank anyone for feedback they give to you and take it on
board. When reviews come out, thank the authors for giving your game
a chance. This is not to suck up to anyone, but to give respect where
respect is due and to properly participate in the comp.

Luckily I did these things (for the most part). It helped me get over
the anxiety of my game being out in the wild and I didn’t know if it
was worthy to be out there. I traded a few emails with Jason Devlin
who had some interesting comments and gave me some support (and I
tried to reciprocate). Comments from the other authors were
interesting and I think it’s good to keep at least some
camaraderie. It’s a competition, not a war. I personally tried to
thank everyone who wrote a review for Mix Tape, good or bad.

And on reviews, maybe I’m a glass-half-full kind of guy, but take
every review constructively. If they say good things, then good. If
they say bad things, then learn from it and make your game better. If
the reviews are useless rants, then leave them be. Most of the reviews
for Mix Tape were very useful to me and I’ve used them to plan the
rewrite.

5. Miscellany
And I’ll finish on a bunch of points I don’t want to elaborate on too
much. Some of these are obvious. Some of these apply to outside the
comp.
  – Your game needs to satisfy two conditions: it has to be interactive
and it has to be fiction. Allow people to play around with it without
the game exploding, and provide a good story.
  – Run your game through a spellchecker. A grammar checker if you
can. But most importantly, run it by several humans.
  – Don’t throw in puzzles for the sake of it. Keep your focus.
  – Don’t spend too much time implementing things that have little
impact. Focus on the story and the implementation of that story. If
you have time, then details. (See the CD collection and the old man in
Mix Tape for violations of this)
  – Make your characters understandable, and likable if you can. This
especially goes for the PC.
  – Catch everything you and your testers can think of.
  – Implement helper verbs. Mix Tape had one good one (CHECK MAIL) and
missed an obvious one (SERVE FOOD).
  – Test your game on a variety of interpreters and platforms. If you
find any problems, let everyone know via the Readme.
  – Include a walk-through. Make sure it definitely works, exactly as
typed. Preferably make sure it works even if they use different
phrasings or do other things midway through the walkthrough.
  – Consider a "full walkthrough" which is a transcript of the game if
you went through the walkthrough. Make sure the two are exactly the
same sets of commands.
  – Add in as many hints as you possibly can. Make them adaptive if you
have time.
  – Betatest, betatest, betatest!

Best of luck!

BrettW

I can ascend or descend the ladder  and I can climb DOWN the ladder but
I can’t climb the ladder or climb up the ladder.

I get the message
"I don’t think much is to be achieved by that."
when I try to CLIMB LADDER  or CLIMB UP LADDER.

<code>

"Ladder Test"

StoreRoom is a room.

A supporter called a scaffold  is in the storeroom.
the description is "A painter’s scaffold.[line break]
[if ladder is placed] It has a ladder placed on it.[end if]".

a ladder is in the storeroom.
the ladder can be either placed or unplaced.
the ladder is unplaced.
the description of the ladder is "A plain ordinary ladder.".

OnScaffold is a room.
the printed name is "On The Scaffold".

understand the command "ascend" as something new.
ascending is an action applying to one thing.
understand "ascend [something]" as  ascending.

understand the command "descend" as something new.
descending is an action applying to one thing.
understand "descend [something]" as  descending.

carry out taking the ladder:
now the ladder is unplaced;
continue the action.

check putting the ladder on the scaffold when the ladder is placed:
say "You’ve already placed the ladder.".

carry out putting the ladder on the scaffold when the ladder is
unplaced:
now the ladder is placed;
now the ladder is in the location;
stop the action.

carry out ascending the ladder when the ladder is unplaced:
say "You need to place the ladder on the scaffold before doing that.".

carry out ascending  the ladder when the ladder is placed:
move the player to OnScaffold;
move the ladder to OnScaffold;
say "You climb to the top of the ladder and step onto
the scaffold.".

carry out descending the ladder when the player is in OnScaffold:
move the player to StoreRoom;
move the ladder to StoreRoom;
say "You climb back down the ladder and step onto
the floor.".

climbing down is an action applying to one thing.
understand "climb down [something]" as climbing down.

instead of climbing down the ladder when the player is in OnScaffold:
move the player to StoreRoom;
move the ladder to StoreRoom;
say "you climb down the ladder and  step onto the floor.".

<code>

In the thread "What IF Comps are there?", Taz wrote
in message news:44e26866@quokka.wn.com.au…

> Ideal for me would be something very simple and small and directed.  I
> suck at doing things without a solid goal.  The mini-comps with themes
> that I’ve seen around would be good.  The ‘something-comp’

> Preferably something without conversation – could we have a mime-comp?
> I don’t know.

How about a mini-comp where the idea is to do one thing well – whatever the
author chooses. Maybe the setting, or PC characterisation, or a really cool
gadget, or a conversation system (if the author was so inclined) …

The reason being, this could give authors a chance to focus on one
particular aspect they are trying to develop their skills in, or are
interested in trying out.

FocusedComp ?

I know the usual response to this kind of post is "try it and see", but I
would be really interested to know if this is something people would enter,
or if someone is struck by a better idea.

David Fisher

Hello,
I realize that this topic has been beaten soundly into the ground with
more than one large stick.  However, I feel I should mention my views
on some of it, just because I’ve noticed that lately certain
fundamental issues that are being debated.
The argument seems to center on the validity of natural language as a
programming model and means for expressing ideas.  Let’s get one thing
across here, then.
The I7 system is viable for interactive fiction.  I say this because
the worked examples are compileable, understandable and most of all
valid demonstrations of the fact that writing substantial and complex
games is very much a possibility.
Now, to address another point.  I am blind, and thus use a screen
reader to handle my everyday interaction with the computer.  I7′s IDE,
as it stands now, is an extremely friendly piece of software, certainly
more so than the command-line compiler that Inform 6 used to be.
As a related point, programming languages, especially those of the
C/C++/Java/tads/I6 variety, are filled to the brim with punctuation
characters.  Semicolons, braces, brackets, parentheses, little squiggly
things that probably don’t have a name.  These characters are not read
by the default punctuation setting of my screen reader and are thus
difficult to pick up at first listen.  I7, by contrast, is a much
friendlier alternative by virtue of the less punctuation-heavy design.
Also, to my mind, the natural language concept, and rule-based approach
to design, as described and explained in the manual, are quite powerful
ideas which shouldn’t be torn apart by a community which can’t
understand them.
Another point I would like to make is that the style of I7 and its
syntax and power are not evident from the point of view of someone who
looks only at the natural language layer and screams ‘Inefficient.’
Just because it is natural language, even with tables and other such
constructions, does not make it inherently less powerful or even less
elegant and practical than a language like Inform 6.
My rant is done now, and if the point of it is too obscure, all I am
really trying to say is that just because of something which is a
surface property of the language, one shouldn’t dismiss I7 or Graham
Nelson’s ideas categorically.
Yours,
Zachary Kline.

_Why_ can’t Inform 7 count past 32767? Why does it have room for all
this object-oriented mumbo-jumbo, but not _counting_?

I think that this is the real reason why the "time of day" in Inform
has only one-minute resolution.

(And no, I do not think it would be a good idea to try to split
seconds– or would it? Hmmm…

- — -

>GET TAMI.N.Z.N.Z.N.Z.E.E … no, too Textfire-y)