How Would One Implement Two Actions Per Turn in Inform 7?

Authoring Inform 7
1

Hello all! I was wondering, is there a way to make it so that an actor could only take, at most, two actions per turn in Inform 7? Something similar to how a lot of roguelikes process turns in loops?

I’ve been playing around with Inform 7 for about a month now and have read through the documentation as well as a good portion of Aaron Reed’s excellent Creating Interactive Fiction with Inform 7, but I can’t seem to find anything that would suggest where to start implementing a feature like this (I suppose that might be because I’m not using the correct search terms or it may even be a little out of my pay grade as a newcomer to Inform 7 :sweat_smile:).

If I’m not mistaken, in Inform 7, a user can input multiple actions into one command (e.g. > open door, take camera, go west), but my goal is to have something resembling how turns work in most TTRPGs, with each character getting two actions per turn, which would allow for things like [> open door > go west] in a single turn or [>open door, go west], but not [>open door, take camera, go west] as it exceeds the two action per turn limit.

I gave up using Inform 7 to implement this for awhile, choosing to make a console application in C# with a similar effect (I’m more familiar with C#), but after reading a bit of Reed’s book, I think it might be a missed opportunity to abandon such a powerful tool just because I can’t figure out how to do one kinda bizarre thing.

The way I have this working in C# is, roughly, (and apologies for using another language, I’ll show it Inform 7 shortly):

foreach (var actor in actors)
{
        actor.GainActions();

        if (actor.HasActions)
        {
            actor.TakeTurn();
        }
}

In Inform 7, I thought it might look something like this:

repeat with A running through actors:
    now A has 2 AP;
    if A has AP greater than  0:
        [???]

…but, as indicated by the coding comment, I don’t know how to give Inform permission to proceed, allowing the actor in question to keep making actions. I could give the Person kind an “active/inactive” property but how would that apply to the player? Even if I did find a way to activate/deactivate all actors, including the player, I think I would still have to probably fiddle with the Turn Sequence rules in order to keep the game from continuing before all the actors have taken their actions.

I think a lot of this is coming from the fact that I’m trying to implement a kind of roguelike turn functionality within the Turn Sequence rules instead of making my own turn sequence rules. A big reason for that is I don’t really understand how the Turn Sequence rules work and everything I’ve read on the Standard Rules tends to say just not to mess with them.

I don’t know if there’s a magic bullet I’m missing because I’m pretty new to Inform 7 or if I’m just working outside of my skill level (maybe both!), but if someone could offer suggestions or even just point me in the right direction of some more advanced documentation, I would be incredibly thankful! I’m new to Inform 7 but not new to coding, and I’m always willing to learn new things and find out how stuff ticks (which is the main reason I’m pushing myself into more advanced topics, I like to see what my limitations are :wink:).

Thanks a billion!

2 Likes
2

I think a basic approach here is to add a rule at the beginning of the turn sequence rules to check the relevant variable (does AP = zero?), and prevent the rest of those rules from running. Here’s a simple version of what that would look like:

The two actions per turn rule is listed before the every turn stage rule in the turn sequence rules.

This is the two actions per turn rule: if AP is not zero, rule succeeds.

(The above is just typed on my phone, not double checked in the IDE, FWIW)

And then you’d just need to decrement AP after every action (or every time-consuming action), and reset it once time does advance, probably as an every turn rule.

I will say that I’d personally be wary of implementing this as a global approach - it can potentially wreak havoc on things like scenes and timers, and lead to unintuitive behavior, especially if you allow movement between locations to happen without time advancing. My sense is DnD uses this rule because it tracks movement in a significantly more granular way than most IF, and it wants players to be able to use the available space to engage enemies while still being able to take an action. But in Inform out of the box, if you can see someone you can interact with them. So I think you’d be much better off implementing special-case free actions (like drinking a potion or drawing a sword) where you want to let players do a combo than painting with such a broad brush!

6 Likes
3

Thank you so much for your reply!

I agree, your wariness is well warranted :sweat_smile:. I was thinking of implementing these double actions within combat scenes or chase scenes and then exposing an abstracted range-band system like the one in Marc Miller’s RPG Traveller in those special cases. I don’t know how elegant such a system would be but we shall see.

I will give your solution a try tomorrow and let you know how it goes, thanks again for your response! :smiley:

3 Likes
4

I tried the code with a few additions:

Section - Free Actions

Taking inventory is free action.

Dropping something is free action.

Looking is free action.

Examining something is free action.

Section - Turns

A person has a number called AP. The AP of a person is usually 0.

The two actions per turn rule is listed before the every turn stage rule in the turn sequence rules.

This is the two actions per turn rule: if the AP of the actor is not zero, rule succeeds.

The take action rule is listed after the two actions per turn rule in the turn sequence rules.

This is the take action rule: if not free action, decrement the AP of the actor; rule succeeds.

---- DOCUMENTATION ----

This implements an unorthodox turn sequence.

Example: * Fist Full of Dice

	*: "Fist Full of Dice"

	Basement is a room. "You are hunched over a folding table, waiting for the other players to arrive."
	
	Upstairs is a room. "You're not supposed to be up here..."
	
	Basement is down from upstairs.
	
	Upstairs is up from basement.
	
	The DM is a man in basement.
	
	Every turn:
		Try the DM going up;
		Try the DM going down.

Testing this source with >wait, has the DM pacing up and down for one turn and then, every subsequent >wait, freezing in place. I did notice that I could >examine the DM and every turn he would move but then another >wait would lock him in place again. It seems like the new rules take a moment to come into effect and then the default zero AP kicks in once the player takes a not free action.

So, I edited the source to have actors gain AP every turn:

Section - Turns

A person has a number called AP. The AP of a person is usually 0.

The gain actions rule is listed before the every turn stage rule in the turn sequence rules.

This is the gain actions rule: if the AP of the actor is zero, now the AP of the actor is 2; rule succeeds.

The two actions per turn rule is listed before the every turn stage rule in the turn sequence rules.

This is the two actions per turn rule: if the AP of the actor is not zero, rule succeeds.

The take action rule is listed after the two actions per turn rule in the turn sequence rules.

This is the take action rule: if not free action, decrement the AP of the actor; rule succeeds.

Now the DM is frozen from the get go, but doesn’t ever move despite my intention of giving him AP every turn. I suspect all this freezing might be due to “rule succeeds” being in the wrong place or it could be the order of the rules I’ve written.

Or maybe, the DM is just too nervous for the big game night. :sweat_smile:

2 Likes
5

I just realized an error. I didn’t edit the “before” from the two actions per turn rule… whoops! :face_without_mouth:

2 Likes
6

So what’s going on here is that you’ve listed the two actions per turn rule before the take action rule, and when the two actions per turn rule executes “rule succeeds”, that’s aborting the rest of the turn sequence rules. So AP are never actually getting decremented, I don’t think (you can confirm this by using the SHOWME testing to command to check the DM’s AP).

2 Likes
7

Oh! I see. I think I had the rule succeeds behavior flipped in my head, but you’re absolutely right. I’ll edit the source accordingly.

2 Likes
8

Yeah, “rule succeeds” means “end this rulebook” (and return that it succeeds – “rule fails” also ends the rulebook but returns failure, intuitively enough). You can use the index in the IDE (or check out the standard rules) to see what’s in the rulebooks by default, which as you say can be a bit of a rabbit hole, but in theory at least the descriptive labels should give you a reasonable sense of what’s going on!

2 Likes
9

Yep! I’ve got turn sequence rules running properly now that I’ve removed most of the rule succeeds breaks. There’s still some stuff I’ll need to play around with to get the actions processed in the peculiar way I’m going for but I’m beginning to get the gist of how it’ll work.

Thank you so much for taking the time to help me with this! I really appreciate it! :smiley:

2 Likes
10

I found another thread about someone who addressed a similar problem recently. I think their approach is pretty similar, but maybe there’s something there that could be helpful to you.

3 Likes