Breaking is violence?

Even after all the code below, when the player attempts to ‘break the clay jar’, the game responds ‘Violence isn’t the answer to this one’.

Any ideas as to what I’ve done wrong?

The clay jar is here. It is a thing. It is undescribed. 
The description of the clay jar is "It seems to be quite old and is sealed tight."

Instead of taking the clay jar:
	say "It is far too heavy to lift and far too big to fit into your backpack."

Breaking the clay jar is an action applying to one thing.

Understand "break the clay jar" as breaking the clay jar.

After breaking the clay jar:
	say "A scroll that was inside the jar rolls out onto the floor.";
	 Now the scroll is in the location;
	 now the clay jar is off-stage.	

Instead of breaking the clay jar when player does not hold the crowbar:
	say "You try to perform a martial arts-type jab against the jar but end up only bruising the fat of your hand."

Try defining breaking as something new.

Understand the command “break” as something new. Understand “break [something]” as breaking. Breaking is an action applying to one thing.

Take out this stuff:

and it works.

3 Likes

For this example, you’re way overcomplicating the problem by creating a new action. This works fine:

The clay jar is here. It is a thing. It is undescribed. 
The scroll is a thing.
The description of the clay jar is "It seems to be quite old and is sealed tight."

Instead of attacking the clay jar:
	say "A scroll that was inside the jar rolls out onto the floor.";
	now the scroll is in the location;
	now the clay jar is off-stage.	

The attacking action covers HIT, SMASH, BREAK, DESTROY, and several other verbs already.

5 Likes

This will definitely work, but just to elaborate on what was going wrong, the issue is that Inform already understands “break” as a synonym for the built-in “attack” command (you can tell this by using the ACTIONS test command, which will tell you how your input is being interpreted). So rather than build your own action, you can just create rules for the pre-existing attack action, which is probably better practice (for one thing, it will catch circumstances where the player types “hit” or stuff like that). By default, attacking isn’t allowed (that’s what gives the “violence isn’t the answer” response) by the block attacking rule, but it’s easy enough to turn that off in this circumstance, by saying “the block attacking rule does nothing when the noun is the clay jar.”

(The other thing to point out is that Amanda’s “understand ‘break [something]’ as breaking” is 100% how you should be defining actions – your way of doing it means the player needs to type the exact command you wrote, down to using the “the”, which means you’re passing up a lot of the power Inform has to understand player input!)

3 Likes

Oh, also. If you don’t want anything else broken by the player, you should include a new message for breaking any other objects, otherwise if the player tries to break other things, they’ll get a blank response.

So like this:

The place is a room. 

Understand the command "break" as something new. Understand "break [something]" as breaking. Breaking is an action applying to one thing.


A thing can be either breakable or unbreakable. Something is usually unbreakable.

The whatsit is here. The description is "a standard whatsit.".

The clay jar is here. It is a thing. It is breakable. It is undescribed. 
The description of the clay jar is "It seems to be quite old and is sealed tight."

Instead of taking the clay jar:
	say "It is far too heavy to lift and far too big to fit into your backpack."

Carry out breaking an unbreakable object:
	say "Shame on you!".

Carry out breaking the clay jar:
	say "You try to perform a martial arts-type jab against the jar but end up only bruising the fat of your hand.".

Now you can break the jar, but not the whatsit. Hope this helps!

** Edited to replace “instead of” with “carry out”- except for “taking the clay jar.” I think that has to stay.

2 Likes

And if you redefine, you can say “carry out” instead of “instead of breaking”, which can cause grief down the road. Major grief. Serious grief.

2 Likes

Yeah, exactly – if you use an instead rule, conditions like “if the clay jar has been broken” won’t behave the way you intuitively think they should. So better to avoid them if possible (I say this having written like 90% of the rules in my first game as instead rules, and only realizing why that was a bad idea after it was way too late to change things!)

2 Likes

More concisely:
A thing can be breakable.
“Can be” means it won’t be by default. You can assume everything is unbreakable unless you give it the “breakable” property.

May seem picky, but there’s no need to assign every other object in the game an “unbreakable” property. Adjective clutter I am also guilty of! :nerd_face:

3 Likes

Thanks! Good to know. I better attend to that in my game.

1 Like

Ya. I’ll edit my sample code above to say “carry out.” Oy, the pain I had from “instead of.”

3 Likes

I’m now seeing @zarf 's post, and want to clarify:

If breaking the the jar is a one-time breaking event, and won’t affect anything down the road, his answer is clearly the simplest and best. Yes?

If breaking is going to be a thing in the game, with several things getting broken, and future events depending on state of wholeness or brokenness, it’s better to redefine?

Am I seeing this correctly?

1 Like

If you want BREAK FOO and ATTACK FOO to be distinct commands, wtih different results (in some situations), then it’s worth creating a new “breaking” action.

Otherwise, just use “attacking”. It’s already there.

1 Like

Breakin’ ain’t violence! It’s this movie –

Summary

Breakin' Offical Trailer (1984) - YouTube

– and was followed by Breakin’ 2: Electric Boogaloo

-Wade

2 Likes

Except that in this instance, neither carry out rule ends up with the jar being broken. So Inform thinks the action of breaking the jar has succeeded, but the jar remains unbroken.* So these rules would perhaps be better in an Instead rule (for the particular case of (not) breaking the jar) or a Check rule (for the general case of (not) breaking an unbreakable object)…

Furthermore, it’s generally good style not to report the outcome of successful actions in the Carry out stage, unless the report is the essence of the action (as for example in ‘Look’ and ‘Examine’). Change the game state in Carry out (‘Now the noun is nowhere’) and report it in After (for specific cases - say “The jar shatters into a million pieces.”) or Report (say “[The noun] is now broken.”)

  • The key point here is that internally, Inform considers any action reaching the ‘Carry out’ stage to have succeeded (regardless of whether it changes the game state or of anything printed) and any action not reaching the ‘Carry out’ stage (i.e. one stopped or diverted at the ‘Before’, ‘Instead’ or ‘Check’ stage) to have failed, and this becomes what is reflected in subsequent conditions such as ‘if we have broken the jar…’
1 Like

Though you can override the failures with a ‘rule succeeds.’

e.g. If a check rule ends with ‘rule succeeds’, that tells Inform that the action succeeded, even though you didn’t reach the Carry Out stage. The default outcome of the check stage is failure, but the ‘rule succeeds’ overrules it.

This is good for me as I resolve tons of things at the check stage. I can’t advise anyone to do this, but it works for me.

-Wade

1 Like

There are two ways to go about asking questions about the state of brokenness. One is to ask if the action of breaking an object has succeeded in the past: ‘If we have broken the jar…’ * (see Documentation 9.12 Example 147, Night Sky)

The other (more flexible) is to have an either-or property attached to a thing (‘A thing can be broken or unbroken’) and to change this when the thing is broken or mended (‘Now the jar is unbroken’) and ask questions about the state of that property either currently or in the past: 'If the jar is broken… If the jar was broken… If the jar has been broken…

  • NB despite the wording, this condition will be true if ANY actor has ever broken the jar (i.e. the breaking action has ever succeeded for any actor with the jar). It’s not possible to be more specific by saying "If the player has broken the jar…’ or ‘If Mrs Jones has broken the jar…’ although the syntax ‘If an actor has broken the jar…’ compiles and seems to be equivalent to ‘If we have broken the jar…’

Good point. Although it subverts the intended sequence of action-processing and probably shouldn’t be recommended for routine use unless there’s no other simple way of allowing the action to succeed naturally. Why not resolve these cases in Carry out /After/Report rules?

My experience it saves me restating the often complex conditions that led to the outcome. Otherwise I often end up having to add clauses to After or Report rules that recapture the condition leading to that particular message. And I sometimes don’t like the logic being in two different places, either.

So I guess After and Report rules can make me feel like I’m double-handling. Sometimes I just check and grade some whole situation at the check stage, print whatever the message is that I need and say ‘rule succeeds’. Obviously this lends itself to more specific actions and outcomes, not general ones, but it’s mostly with quite specific actions that I use it.

-Wade

In general, yes. Depends on what you’re doing in the game.

If you have one unique object that is breakable in the game, you might want to deal with it singly using an INSTEAD rule like Zarf explains. Just be aware that if the player has to figure out that the jar is breakable, it’s a good idea to either modify the default “Violence isn’t the answer…” denial or hint that the object “looks fragile” somehow because experienced players will see default refusal messages and often assume that attacking isn’t implemented in the game anywhere.

If your game involves multiple things breaking and a damage system throughout, then you’d want to design and apply properties that might apply to all or just breakable objects.

I gotta tell you, my solution is to never use past-tense conditions. If I need to remember game state, I add a property or variable somewhere. So I can use before/instead/check/report rules however I like, and it never matters whether an actions succeeds or not.

From my point of view, this is the easy way out.

1 Like