In the testing version of a parser game, I have some code to help detect if a certain process goes wrong. If it goes wrong, some details about the problem get printed.
Does it make sense to leave that in the published version? If you can detect that something probably went wrong (which might not be immediately obvious to the player, but which could possibly maybe impede their progress), do you announce that to the player? Does it also make sense to include diagnostic details in case the player decides to pass that on to the author?
(To be clear, I’ve tried to fix the bugs that led to problems in the first place, so ideally this error text will never show up.)
Ideally I’d say have some text that says something like:
[Uh oh. You appear to have run into
a rare bug. If you receive this,
please email me this code at
<emailadress@webs.ite> with either
a transcript of this play through,
orsome context of where you are:
<Problematic code>]
Or something along those lines. But that may not be possible.
Yes, I do that for any complex game. I generally use the format
say "(BUG) Machine is on but the battery is out of play.";
If possible I include enough information to make the situation clear to me if the player pastes that line into an email. (Or forum post.)
This is good for debugging, of course. It’s also good for playtesting; you can search through a large transcript for the string (BUG).
It also makes the player aware that future problems are not their fault! This can be important. A player can get into a situation where they try a correct solution to a puzzle, see it fail (because of bugs), and mentally cross it off their list forever. Or they might try an incorrect solution and fail to get the desired clue-guiding response! The player might not try those actions again even if they play a later release of the game.
I think there’s a way to write text to an external file in Inform 7, though I don’t remember how. I wasn’t sure if dealing with an extra file would make it more complicated or less complicated for the user.
Are you saying the user will likely not send a bug report at all, or that the user will likely send a bug report without details? I’m not sure what you’re suggesting I do.
Right, you’re better off getting your technical dump right there in the transcript, with some player-oriented text before (and maybe after).
[Oh no! You encountered a bug in the game. Things might not work right from here on. Some technical details to help the game’s author debug this problem follow, you don’t need to understand this:]
The details aren’t super technical, but they include numbered lists of things that end up being like 70+ items long in total. If I just print this outright, it’ll definitely be longer than one screen. I guess I could make it so each thing is not on its own line, but then it might be hard to read.
Unfortunately, not all interpreters allow copy-paste. I’ve copied quotes from descriptions or responses by hand on a piece of paper while playing because I wanted to use them in a review and I couldn’t copy them straight out of the game-text.
Which interpreters? That’s a pretty serious usability problem.
Yes, a player using that system is going to have trouble giving you useful feedback. My response as an author is “Uh, can you turn on transcript mode?” There’s not much else I can do about the problem.
Of the major systems, the ADRIFT Runner has this problem, at least for me (on Windows), though I think the other ones are usually fine. It’s a relatively frequent issue with custom parser engines too.
Running Frotz or Glulxe in the Linux Console or in a Terminal emulator, I have no idea how to copy text from the game’s output… and the only means of creating a transcript that comes to mind would be piping the command to invoke frotz or glulxe through tee, which I would have to do when first starting… granted, this might be ignorance on my part, not a hard limit, copying game output as part of filing a bug never occurred to me prior to reading this thread.
Windows frotz / glulxe can launch a separate scrollback window for copy paste. It holds a lot of text! Enough to copy an entire Infocom game, I think.
(I usually just put a rule name in a bug catching “otherwise,” but I’d add current action, location, and maybe check for specific scenes if it mattered. My stuff isn’t very complicated, and I’d want to keep it short anyway)
I mean, I guess I could dump the details into the game text, and also write it to an external file, if that would help…though if a system doesn’t support transcripts, I guess it would be unlikely to support writing to an external file, anyway. I guess the player could try sending a screenshot?
Basically all Z-machine and Glulx games have a SCRIPT or TRANSCRIPT command that’ll save the output to a file. Which can be slightly nicer than using tee because it means the program sees that the output is going to a terminal rather than a pipe, and will buffer appropriately.