The french translations serve as evidence that a translation is quite doable. Also, they offer two different ways of approaching the problem, which may be helpful for anyone wanting to create a translation to a language which has some similatities with French.
But yeah, the simple, binary answer is “No”, which I think was clear from my first reply.
Compiled, installed and successfully tested the new punyinform… a question:
what is, and what means, that R in the banner and VERSION, just after “v4.5”, in the spot where usually S D, and SD are printed ??
A production build typically shouldn’t have runtime errors enabled, so it’s a reminder to the developer that the game you’re looking at is not a release version. Also, it may be useful during testing, as you then know if you can expect the library to try to highlight problems or conceal them.
I’m unsure about this reminding; post-release bug reporting will always happens, notwhistanding the best efforts of the author(s) and his/her ßtesters, so I guess that a runtime error cited in a bug report from a player with with little or no knowledge of programming is a sound telemetering (artillery sense, of course) in aiming against bug.
Yes, but it will also be ugly and make the player enjoy the game less, when possibly they could have completed the game and enjoyed it without ever noticing a problem.
E.g. one of the PunyJam #3 games didn’t have the scope limit set correctly, and had runtime errors enabled. A player got error messages, and this was a big enough turnoff to make it into his/her review of the game, making it look like a pretty broken game. It seems the reviewer never had any problems because of the bug, but the error messages became a problem, and now they’re stuck in the review for ever. As an author, you don’t want that. You can fix the game, but not the review.
This tilts the other way if the bug makes the game silently unwinnable. (Which is common, for runtime errors. The usual outcome is that the action fails but the game loop keeps running, so there’s no indication that you’ve tripped over a bug.)
Better if the player knows something is wrong and can wait for an updated version.
Independent of any discussion about right or wrong, if you prefer the v4.4 user experience in your game(s) there’s nothing to stop you just commenting out this feature in lib/grammar.h (lines 1245-1248).
Actually this discussion serves as a good reminder that we should document exactly which runtime checks the RUNTIME_ERRORS setting controls. I realize it may sound like it lets you enable or disable all runtime checks, and this is not the case. I consider it quite similar to Strict Mode - a bunch of checks which are useful, but they also make the game larger and slower, so you may want to consider disabling them in a production release, especially for 8-bit targets.
It’s now fixed. The problem came from a flaw in the git-archive-all script. The gzip program saves the timestamp of the compressed file unless this behavior is specifically suppressed. I use this add-on because simply using git-archive won’t work if a repository includes other repositories – here it’s the Inform6 compiler source code, PunyInform, and the Inform6 Standard Library.
PunyInform isn’t only for retro adventuring. Although the aim is to allow the creation of games that are really compact and can run on old 8-bit and 16-bit platforms, you can still write super sophisticated games that are every bit as feature rich as all the other modern authoring systems.