I’d like to add an ending that has the explanation of the plot of my game; this is shown to the player after they’ve won/lost/died, similar to how AMUSING is shown (if enabled).
However, while I can easily customize the message about the ending options, it looks like adding a new end-game-command would require either replacing the entire “main” loop in my code, or by editing puny.h. Both of these feel like they’d be a maintenance hassle.
Does anyone know of a better way, or is there a hook mechanism I’m not thinking of?
I can add the BeforeParsing entry point, and put in a check like if (CHECK_FOR_SOLUTION_IN_PARSE && deadflag && f_enough_evidence) {, since once they’re dead, the only reason for parsing should be (I think?) the UNDO/FULL/QUIT prompt, so I can check if they entered ‘solution’ and show them the solution here.
It feels a little dirty to put this in a parsing routine; if anyone has a better idea, please lmk!
Yes, @improvmonster , thanks — but it’s that I wanted to add a command (like AMUSING does) for that end-of-game prompt. Some people may end the game and not want to read the entire solution.
(for context: this is a game where you can end-the-game without having gathered 100% of the possible evidence or points; you just need enough — it’s possible they don’t want to read this because the solution would spoil some things they haven’t yet found)
ah, so you want an “amusing” option at the end but one that doesn’t say “amusing” and instead sums up the game or their partial solution.
i’ll bow out and defer to someone smarter than i re: how to hack the game-over menu. inform itself has built-in menu extensions but i don’t think these are available in puny inform.
touching the library itself is generally not wise but in this case it may be easiest to provide an Amusing() routine and then simply go into the library and change the display name from “amusing” to “recap” or whatever?
That would be the easiest way; I just was hoping for a way that doesn’t require my to edit puny.h (so if there’s a new release of puny, I can use it without figuring out the diff).
I did find a reasonable solution (read up) that’s a bit hacky, but works (by using BeforeParsing).
I have a different philosophy. For my projects I copy Puny into the project (in a git repository) and modify anything I need to. For All that shimmers… I made the following modifications (some things I’d probably do differently now, having more experience)
CHANGES MADE TO PunyInform 5.14.1
=================================
- removed spaces before `***`
- modified the banner (serial info etc) to use two lines
- fixed issue with darkness in the crypt (approaching grues)
- prevent picking things up when holding the ladder
- allow showing newspaper articles to people
- remove `SPEAK` as a synonym for `SAY`
- remove `SWEEP` as a synonym of clean/rub
- add newline when a dark room becomes non-dark (and a <Look> is done)
- implemented joke of not understanding player directly after losing
- change message from `GET ALL` when no matches
- implicitly open gate (if not locked) when going through it
- show "type ABOUT ..." message after banner
- show message when implicitly opening cemetery gates
- made `x ceiling` produce same message as `x floor`
- require a held-object with `SQUEEZE`
- make `them` and `it` synonymous (dud the `themobj` var)
- tweaked BRIEF message after making VERBOSE be the default
- made sure `INV` and `LOOK` do not advance time
- have `ATTACK` and `BREAK` as distinct verbs/actions
- use `CUT` instead of `ATTACK` for weapon case
- changed grammar of `KISS` to allow any noun, do animate check in KissSub
@andrewj : I’ve chosen to not edit the puny source files, but I can see the advantage of doing so if there are lots of changes.
One thing that really tempted me is that thedark in puny has so few properties on it, and since you can’t edit properties not originally set, it was very limiting. Unfortuately, the "NO_DARKESS " constant doesn’t just remove thedark, but removes the very concept of darkness (which is great; if your game never needs it, you save space)
I do wish Puny had a separate constant to keep the idea of darkness, but not emit the thedark object, so you could define your own.
(in my case for this, I used the InScope hook to add things to scope when location == thedark, but I didn’t love that approach: it hides this away in InScope. I was hoping that I’d have been able to simple add an add_to_scope to thedark in my code)
Letting the game author define the darkness object is certainly possible, and possibly useful. Let’s talk about what you’d actually need this feature for, and figure out what the use case is.
You can’t use add_to_scope for a location. The library doesn’t check the location’s add_to_scope property, and actually it couldn’t even if it wanted to, as it’s an alias of in_to, which serves a quite different purpose for locations.
Of course you’re free to choose this path. The upside is you can change anything, and for a few of these changes I’m sure it’s quite a bit easier to change them this way, compared to using mechanisms like Extend and Replace.
The downside is that you will probably be really reluctant to upgrade the library, as it’s so much work.
When I upgrade the library for one of my projects, it typically takes me a few minutes. I check the “Important to note when upgrading” for every release after the one I was using, decide if there’s anything there that affects my project, apply changes if needed, and move on.
