PunyInform v3.2 released

PunyInfom v1.6 is now out! Grab it at https://github.com/johanberntsson/PunyInform/releases

This release contains lots of important bug fixes, as well as some changes in functionality. Please read the release notes for details.

We started using a regression test suite, which makes us much less likely to break something when fixing something else.

1 Like

PunyInform v1.7 just came out. Check it out at https://github.com/johanberntsson/PunyInform/releases

It has some important bug fixes as well as some new features. One of the news is that the parser has support for ship directions like fore and aft.


Very nice. One of in progress stories use shipboard directions.

1 Like

The Navalist here thanks. But OTOH I feel that for a minimal library, things like shipboard directions ought to be extensions than options (I’m not sure if I have put clearly my opinion…)

Best regards from Italy,
dott. Piergiorgio.

Looking at the Infocom games, I can name several titles which use ship directions. So, it’s not a case of a feature needed by very few games. Boats, ships and spaceships are rather common in text adventures.

Also, this was a lot easier to implement in a performant way if we made it part of the library. And if you don’t define OPTIONAL_SHIP_DIRECTIONS, it changes absolutely nothing - the code compiled by the library is identical to what it was before ship directions were included. An extension would have introduced more overhead when included too, or made the library more complex because you’d have to be able to replace the Directions object entirely.

We’re also aiming at adding the option of completely custom directions. I’ve seen a few games that use left, right etc, and we could accomodate that.


“Several Infocom games” is still very few games! If you did a survey of IFDB, you’d find that only a tiny percentage supported PORT/STARBOARD etc.

Still, it’s your design.

1 Like

I think PunyInform is mainly used for old-school games, more like Infocom games than many of the newer pieces. If you’re writing for a retro-computing audience this may be easier to sell in, and they fit well with the restrictions in size and processing power of 8-bit computers.

As for the works I know are currently in progress, at least two of them use ship directions.

Some people want it, it wasn’t hard to add, and it doesn’t make a difference to the code unless you enable it.


(Emo is not supported in this version of PunyInform.)

I have recently started playing around with PunyInform, though I have never touched Inform 6 before. So far I am optimistic.

Is there any chance that UNDO could be made an option, at least for z5 and z8?
(sorry for running around asking for improvements all over the place, but it would be really neat :wink:

Inspired by Tristam Island I plan to release my game on several platforms (though much fewer than Tristam Island, non-profit and probably for IFComp) but for those who decide to play on a modern machine anyway, I might as well include UNDO. I could also imagine that Amiga and Atari ST could handle UNDO but I haven’t looked into it.

1 Like

That’s an interesting fact. Is that because very few titles are actually located on ships or in space where nautical directions are relevant? I think this added immensely to the immersion when playing said games, with Stationfall actually being the one I’m remembering very vividly for it.

Generally I appreciate this addition, but then Hibernated Director’s Cut (the rewrite of my first adventure) is one of the games Fredrik mentioned that will make use of the feature.

Let me know if you want to learn more about how all those platforms were achieved. Hugo is using my build tools / setup for porting Tristam Island to all those platforms. I have the whole process automated in under 20 seconds.

1 Like

We will at least have a look at adding undo support. Thanks for the suggestion.

1 Like

@8bit_era: 20 seconds - wow! Thanks for the info - I might increase the number of platforms for my game then. ::smiley:

While I make the game, I am primarily testing with Windows Frotz and Vice c64 emulator after sending the Z3 through Ozmoo. So far I expect the game to run with at least 40 columns. I take this into account when using quote boxes. If I plan to publish on a lot of platforms, is there anything I should keep in mind while I make the game?

@fredrik: Thanks for looking into this!

You should have some basic knowledge about the systems you’re targeting, so that you’re able to load up your game and test it either on real hardware or in an emulated environment. As long as you stay within the constraints of Z3, there is not much to keep in mind actually. PunyInform’s debug mode might be incompatible with some of the classic interpreters, as it uses a print to memory that might cause funny things to happen if the terp does not support it. With “classic” I am referring to both Infocom and 3rd party. So if something’s not working or even crashing, make sure debug mode is turned off. As long as you are staying close to Windows Frotz and Ozmoo on the Commodore 64 for testing in debug mode, you should never face any issues. I often test(ed) on Atari 8-bit, where it was a problem. @fredrik wanted to add some information about that to the documentation, which likely happened already.


Yes, it’s in the manual that debug mode doesn’t work on all old interpreters.


Good to know - thanks!

1 Like

IMVHO, the ideal standard of .z3 IF should be that of late Infocom parser, and we have more than enough reference with serials dated 87 and 88… and punyInform 1.7’s minimal.z3 has ~5k grow margin re. generic-r5 :wink:

Best regards from Italy,
dott. Piergiorgio.

Do you think it is reasonable to try to translate the library (especially for the v3 version) into French?
I have to write BeforeParsing(), rewrite _PrintObjName(); everything about articles and pronouns, and messages of course.
Maybe I can try.

I think the library can be translated, and I think it will be. However, translatability has not been a design goal, so it may be harder to do it in a way that will also work with updated versions of the library.

In v3, it’s not possible to change the input and then scan for recognized words again, the way many translations of the Inform 6 library do. That requires the opcode tokenise, which was introduced in v5. You would have to find other ways to make the game understand French.

You could of course choose to make the translation target v5 only.

I think Hugo Labrande has started thinking of a French translation too. Maybe talk to him?

1 Like

After toggling the buffer, I can’t write my own function in BeforeParsing() that replaces @tokenise? I thought I would read the contents of ‘buffer’, and rewrite the entire contents of ‘parse’ with the new values. That’s what I’m trying to do right now.

We are in conflict with Hugo Labrande, and if it is to reproduce what he did with version 6.11 of the French library, it is not worth it.