I’m working on a rather large TADS game and I’d like to know if there’s a way I can preserve my tester’s save functionality when I make a few changes; I’d like to, for example, let them save at the furthest point of development, then continue on when a new section of the game map has been implemented without having to manually play through the whole thing again.
Is there anything I can do to avoid having their saves read as “incompatible” with new nightly/weekly releases?
The short answer is “no”.
Thaumistry does it a little bit. I understand it works by having a “base game” which never changes. Bug fixes are applied as patches to the compiled code, loaded in every time the game is started up.
But you really don’t want to do that during development. It would just make your game code unnecessarily messy before it’s even done. And I don’t think it would make sense for adding large amounts of content. Thaumistry only uses this method to fix typos and small game logic bugs.
Maybe a dumb suggestion, but couldn’t you use a temporary magic word? Like “BETAPLUGH” or “XYZZYTEST?”
This word would transport the tester to the beginning of the new content with the proper items in inventory, and the necessary tasks checked off thus far, allowing them to continue from that point.
Then, just disable the magic word when you release (or not, that’d be an amusing Easter Egg).
That’s not a bad solution; the game isn’t terribly linear so there aren’t really “milestone” points that new releases will be able to point towards. I might be able to do something along those lines, though.
If you’re using Adv3Lite, there should be a way to add tests, which automatically perform a chain of commands for you. These also do not appear in “production” builds, just “debug” builds.
If your testers send you the transcripts from gameplay, you could write a test command for each tester that just plugs in the commands they used in the transcript. Alternatively, you could just set up the test to return them to where they were using a more optimal route.
This is really handy because it not only proves that previous parts of the game still work, but also interacts with the game world in more “natural” ways, so the game state after the test has all the variables and properties set to what they should be during actual gameplay. It also doesn’t require you to know ahead of time what these should be set to; it’s all done naturally by the test command.
So if you have a tester whose username is something like “SlyRox97”, then the test command would be > TEST RETURNSLYROX97, and you just let your tester know to enter that in before resuming testing.
EDIT: By “It also doesn’t require you to know ahead of time what these should be set to”, I didn’t want to imply that you don’t know how your own game works. It’s simply good testing wisdom to pretend like you don’t know what will happen during the bughunting and bugfixing process, because assumptions will only hide other bugs.
I for debugging into farther points of the game, use strings like, e.g.
n.u.w.w.n.take this.s.e.e.s.take that.put this in that
n.w.turn on that.s.s.s.d
n.n.put that on gizmo.turn on that.u
as one can easily figure, line 1 solve a puzzle about this and that, and lines 2 and 3 solve two different puzzle needing the solve of puzzle 1
Astute people will note that as walkthru, is in a format ready to be pasted into the parser’s command line… 
if your ßtester must check a specific puzzle, s/he need to cut/paste the required command line, e.g line 1 and 2, or line 2 and 3
I’m actually working into two distinct part of one of my major work, and indeed I kept a “main” branch (akin to line 1) and “trunks” toward the work aerea (akin to line 2 and 3)
oh, I’m sure that really old timers will smile, because, well, is how mines (the industrial type) are actually digged, because, well, dungeons and underground are basically mines…
Best regards from Italy,
dott. Piergiorgio.
These are all better than the solution I used for testing an adv3 implementation: use RECORD/REPLAY to save ‘golden’ sequences. It has the downside of needing to spam space bar (even after perling it into a single command line), which could be excessive in a large game.
Time to practice drum rolling on my spacebar!