Meanwhile, in Inform, this is completely possible! try NPC smelling the flower will involve the SMELL action, just for the NPC instead of the player.
3 Likes
Which turns out to be critical in a lot of cases. For instance, try NPC going east will account for whether there are doors in the way, try NPC taking rutabaga will account for whether the rutabaga is in scope, whether the NPC has carrying capacity, etc.
3 Likes
To be clear, it’s possible in TADS3 as well, the problem is that by default the library messages make no sense. In this specific case, for example, if the NPC is Alice, then the message “Alice smells nothing in particular.” will just be appended onto the reports for that turn.
2 Likes
I feel like, “Is it possible?” is the wrong question to ask when trying to implement any particular feature in any given development system, at least as long as the development system is Turing complete, which I understand most programming languages are aside from the constraint that real computers have finite memory.
The better question is whether something can be implemented within a reasonable amount of developer time, which is probably especially important for IF considering how many assumptions major systems make and how often implementing a given feature involves overriding default system behavior and how often it would appear reletively simple things require making exceptions to dozens of defaults.
Disclaimer, I have no direct experience with IF systems, the above is based on impressions I’ve gotten from skimming threads discussing the coding side of inform and to a lesser extent, other systems.
2 Likes
Time wise I’ve only made one complete IF game in inform 7. I barely knew inform 7 so it took about a month to make. Had I properly tested it etc. and knew of synonyms and inform 7 more thoroughly it probably would have taken a few months.
My current project includes different enemy types, shooting, reloading, explosives, boss puzzles, environment puzzles, different weapons, etc. I’ve been working on it for a little over 3 months. It feels like it’ll take over a year because I am constantly thinking of synonyms and replaying earlier parts and restructuring them.
1 Like
Couldn’t you just do something like this?
dobjFor(Smell)
{
action()
{
// Check if the actor is NOT the player character
if (gActor != gPlayerChar)
{
"<<gActor.theNameIs>> smells the flower. ";
}
Or you could use capture output, I think, something like this:
gOutStream.captureOutput({:
nestedActorAction(alice, Smell, trailScent);
});
or you could probably use that all together to run inherited without triggering the default message, I think, I’m still not exactly great at this.
But this is for lite, I don’t know if the default adv3 handles it differently.
That’s one way of doing it, yeah. I think it’s a little cleaner to tweak the global action messages, but there are other ways to approach the problem.
And although the fix for that one specific instance is probably straightforward (in that there aren’t likely to be hidden gotchas due to implicit actions or internal action rewriting and things like that that can complicate some other actions), the larger problem is that if you want to do this in general you have to go hunting through the library to even find all the places this sort of thing is happening.
But, to echo what @Mewtamer says, I’m not really talking about what’s possible, I’m talking about what’s default. My point is that when you see something like the default behavior of the >SMELL action, it indicates that having NPCs take that action wasn’t a design consideration. The same is not true of, for example, travel actions, which have logic that accommodates both player and NPC travel.
3 Likes