Does it make sense to put error text in the release version of a parser game?

For runtime errors in my game, I notified the user that something had gone wrong, but wrote the stack trace (or technical details) to a file located in the same directory as the game file. In the error message, I suggest that the user would be doing the author and any future players a big favor if they’d be willing to email that file to [my email address]. So far I’ve already had a few people from out of the blue contact me with bug reports and the generated file attached. I’ve always been able to fix the problem based on what they sent me…

1 Like

Important note!! If you do program your game to write error information to a file, make sure you incorporate some kind of failsafe that will only write x amount of error files in one interpreter session. Before I did that, a certain kind of error kept retriggering over and over until I realized what was happening and quit the interpreter, only to find 2000+ error files clogging up the game directory! Happily, I discovered that before I ever shipped a version of the game with that feature…

3 Likes

I would think it would make more sense to append new error messages to an existing log file than to create a new file for each error, at least if the ability to do so exists within the given framework.

Also, I don’t think I’ve heard of the transcript command before… then again, since joining this forum, I feel like I’ve encountered a lot of little things anyone who plays IF should know that I didn’t know before joining.

2 Likes

Well, Q-TADS for one.

2 Likes

If anybody is using ZIL (and supposedly Inform 6), I have a way of writing to an external file, adding the new stuff instead of overwriting - using only Z-machine opcodes, although it requires Gargoyle (or Frotz) to play it properly…

I think it does. Sometimes, you may just have a lot of complex code, and you’re pretty sure you’ve got all the main messages, but you have to admit there’s a good chance you’re missing something.

I’ve done that–often it’s just a one line fix. Sometimes I’m updating code to work a lot better. Even if it never pops up, it’s useful.

And I think it’s good to sort the error messages.

  1. “This is insignificant, but I still want to fix it. You’ve found a test case I overlooked.”
  2. “This is probably not a game-breaker, but things may get weird.”
  3. “This is a potential game-breaker.”

A possible additional comment is: “you found a good try I didn’t consider during programming testing. Please contact me at (email) or drop in an issue at (source control) with repro steps.”

Oh, and don’t overstate how bad the bug is. I’ve made that mistake.

1 Like