General Code for Multiple Scene Endings

Hello, all:

I’ve been using Inform 7 on and off for a couple of years now and this is something I’ve thought for a long time but have never written it – the documentation for how to code Inform is horrible.

That being said, can someone help me with the coding for a scene? The circumstances are:

when dynamite is lit, scene begins

scene ends after four turns

scene can end multiple ways: one, the character blows his hand off (ending the game); two, the character blows up the fish (which is the desired ending), third, the character blows nothing up, it just explodes harmlessly on the ground.

The code below doesn’t work, it’s a mixture of different iterations. I can’t get the compiler to like it:

bangbang is a scene.

bangbang begins when dynalit is 4.

Every turn during bangbang:
decrease dynalit by 1.

bangbang ends in failure:
if dynalit is 0:
if player is carrying litdyanamite;
end if;
end if.

when bangbang ends in failure:
say “The dynamite blows up in your hand! You are started when you see fragments of bones and flesh scatter around you until a split second you feel the pain of getting your hand blown off. I think that…yes, I was afraid of that…[paragraph break]* * * * * YOU HAVE DIED * * * * *”;
end the game finally.

bangbang ends in success when fishies is 1.

when bangbang ends in success:
now litdynamite is nowhere;
now matchflag is 0;
now fishies is 4;
say “There is a brief moment of hush followed by a huge explosion! Water sprays up into the air, reddened by fish blood and chunks of trout like buckshot. There is the sickening pitter-patter of fish flesh as it lands on the wooden bridge.”;
increase score by 1;

when bangbang ends:
now litdynamite is nowhere;
say “The dynamite explodes, shockingly loud in the silence of your subconscious. Instinctively, you shield your eyes and when you recover from the shock of the noise you discover with some measure of satisfaction that you have managed to blow a hole in some part of the world. I suppose now you can die feeling fulfilled.”

Here’s how I got it to work.

[rant=bang][code]“Bang”

Blast Zone is a room.

some dynamite is a thing in blast zone. dynamite can be lit. Understand “fuse” as dynamite.

dynalit is a number that varies. Dynalit is usually 4.

Instead of burning dynamite:
say “You quickly light the fuse[if the player does not carry dynamite] and step back[end if].”;
now dynamite is lit;

a barrel is an open, unopenable container in Blast Zone. some fish are in barrel. Instead of taking fish: say “No, that’s their home.”

bangbang is a scene. bangbang begins when dynamite is lit. bangbang ends explosively when dynalit is 0 and the player encloses dynamite. bangbang ends fortunately when dynalit is 0 and the player does not enclose dynamite. bangbang ends in fishy death when dynalit is 0 and dynamite is in the barrel.

Some dead fish chunks are a thing.

Every turn while bangbang is happening:
now dynalit is dynalit minus 1.

when bangbang ends explosively:
say “KABOOM! The dynamite blows up in your hand! You are startled when you see fragments of bones and flesh scatter around you until a split second you feel the pain of getting your hand blown off. I think that…yes, I was afraid of that…”;
end the story finally saying “You have died”.

When bangbang ends fortunately:
say “The dynamite explodes, shockingly loud in the silence of your subconscious. Instinctively, you shield your eyes and when you recover from the shock of the noise you discover with some measure of satisfaction that you have managed to blow a hole in some part of the world. I suppose now you can die feeling fulfilled.”;
remove dynamite from play.

When bangbang ends in fishy death:
say “There is a brief moment of hush followed by a huge explosion! Water sprays up into the air, reddened by fish blood and chunks of trout like buckshot. There is the sickening pitter-patter of fish flesh as it lands on the wooden bridge.”;
move dead fish chunks to the location of barrel;
remove barrel from play;
[/code][/rant]

Thank you!

One question, for my own learning – why did you decide to code the scene as beginning with the dynamite being lit instead of the dynalit variable being set to 4? What are the advantages of doing it this way?

Thank you!

Look at it again - I forgot your third condition the first time before the edit.

It makes more sense to me for the scene to begin when the dynamite is lit, which is a direct action the player takes, and also allows me to charge the dynamite at four initially. The variable changes as a reaction to an action that starts the scene instead of triggering a scene But you can certainly code it either way. It’s not a big deal here, but in a more complicated game where variables are changing and you have recurring scenes, you’d not want the scene to start over if there were some way for the variable to hit 4 again; you’d only want it to begin when the dynamite is lit. It’s always a good idea to “idiotproof” your code so if you make a change later there’s no chance of interfering with what you wrote a month ago.

Speaking of, I didn’t account for if the player tries to light the dynamite twice:

Instead of burning dynamite: if dynamite is lit: say "Already done - no going back now!"; otherwise: say "You quickly light the fuse[if the player does not carry dynamite] and step back[end if]."; now dynamite is lit;

Can you pin down what you thought was missing from the documentation? It seems to me that the essential syntax for multiple scene endings is reasonably well described in 10.8. But maybe a more straightforward example would help; the two currently linked there are both quite complicated.

Hi, jrb:

I think that, looking at the feedback that Hanon left – I think that the problem with the documentation is more with me than the documentation itself.

The type of person I am – I want to program what I want to program. And so, in my life, I have a habit of jumping in and figuring things out as I go. It’s just the way I learn. Undoubtedly this leads to ineffecient coding at times, but eventually I figure things out and on my second or third pass through I spot ways to tighten coding up. It also leads to really bizarre situations in which I can figure out how to complete or design very complex tasks but struggle with very simple ones. I think ‘hey, how would I create this puzzle?’ and not, ‘Do I know how to create this puzzle?’ or ‘Am I familiar enough with the material to create this puzzle?’

So, part of the issue is that the documentation isn’t organized for somebody like me. I’m not saying it should be, I’m just saying that it’s an issue for me. I’m much more likely to look for relevant material when I need it than to read stuff that I may not need (at least immediately). It’s one of my many many flaws.

In addition to this, I haven’t had much experience programming outside BASIC (when I was a kid). Because of this, I’m not really programming literate and so I miss some of the global concepts that lead to specific wording that I would need to search for something.

Overall, if it mattered and if it helped more people than just myself – I am the type of person that needs to know why I am doing something – why something is being coded one way and not another. How one example is different than another (not just that it is). Maybe an example of how something might have been coded in an Infocom game that I’m familiar with. There are of course trademark issues with that – but knowing how in AMFV the video footage required would have been coded in Inform would be a tether to my world. But, of course, I’m 49 years old and I’m not sure how much of a common experience I have with my contemporaries in programming Inform.

So, I guess I would say often is that the documentation is written by programmers for programmers and isn’t meant to teach, really. That, and the book by Aaron Reed is absolutely horrible. If you had anything to do with that book, sorry for the offense.

Anyway, thank you for asking but I think it’s on me, my friend!

There is an Inform 7 for Programmers document that might help you. It was written a number of years ago so some of it may be out of date, but it might give you the holistic view you need that will help you when you do need to delve into the documentation.

plover.net/~pscion/inform7.html

I note with some wryness that the opposite complaint is more common. (That the I7 documentation isn’t written for programmers, and it should be.)

Well, don’t listen to me :slight_smile:

I found it immediately very useful – beginning with the hierarchy of subclasses. Thank you!