Debugging and testing TADS games
Terrence Koch
please bear with me if the answer to my question seems obvious.
Being new at this, I am in the habit of writing some code, compiling,
then testing to see if what I did works. The frequency with which I
do this might be more often than someone who has more experience, but
right now this is what serves me best. So far, this has worked fine,
since it only takes a few commands to reach any changes I have made.
But I can see that as the adventure grows, I'm not going to want to
step through one or two hundred commands just to test something.
What are some of the best methods of isolating portions of your game,
or jumping to portions of your game for testing without having to work
through the parts that already work fine? (especially when trying to
fine tune problem areas)
tk
Phil Lewis
> What are some of the best methods of isolating portions of your game,
> or jumping to portions of your game for testing without having to work
> through the parts that already work fine? (especially when trying to
> fine tune problem areas)
First, "magic" debugging verbs are handy in this situation. A couple that I
use a lot are "teleport" (move any game object somewhere) and "find" (tell
where a specific object is). You'll want to put these in conditional
compilation blocks or at least remove them before releasing the game, of
course. More specialized verbs can be created for specific situations as
well.
Another helpful approach is to create a small "test world" for just those
pieces that you're hacking on. Just copy the objects and classes that need
testing to that test project and play with them there so you don't have to
go through the whole game to get to them.
Some special situations call for more work than this but I've found these
two techniques well suited to most cases.
Phil Lewis
Stephen L Breslin
Two things come to mind.
Firstly, I'd recommend breaking the code into modules. You may find it
works well to have a seperate module for the main NPC in the game, or a
seperate module for the forest -- good boundaries for modules are case
specific. I have all my modifications to the adv library in a seperate
module, for example.
Second, I'd recommend, in some cases, testing something out before adding
it to the game. I very frequently use the "dummy startup house game" as a
scratch platform for trying out new code, before I add it to my main game.
As you note, checking the way some code behaves under Spartan conditions
is considerably simpler.
One other thing, in case you're unaware. If you're using the TADS
Workbench, you can use break points to break into the debugger stepthrough
at a particular point during execution. I think you can put a stop point
at any evaluation of an expression. When I am debugging, I put a stop
point at the beginning of what I think is the problem area, and start
stepping through the code from that point forward in the execution. The
workbench manual tells you about them in great detail.
Hope that helps,
Steve Breslin
T Raymond
> What are some of the best methods of isolating portions of your
> game, or jumping to portions of your game for testing without
> having to work through the parts that already work fine?
> (especially when trying to fine tune problem areas)
Check out debug.t in the TADS2 contribution area. It'll give you some
magic words that will help with this sort of thing.
HTH
Tom
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Tom Raymond af956 AT osfnDOTorg
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
Jim Aikin
> First, "magic" debugging verbs are handy in this situation. A couple that I
> use a lot are "teleport" (move any game object somewhere) and "find" (tell
> where a specific object is). You'll want to put these in conditional
> compilation blocks or at least remove them before releasing the game, of
> course.
I use this technique a lot, as I'm working on a large project. Below is
the code I use for the magic verbs. (This stuff is not original with me;
I borrowed it from somewhere.) Note that I'm deriving all of my
locations from a special class called loomRoom (because the word 'loom'
is significant in the story). If you use the default 'room' class,
change the code accordingly.
After creating this verb, you need to give each room a noun property
(which is otherwise unnecessary), so you can type 'gothere myroom'. I'd
also suggest making sure that none of your rooms has the same name as
any other object in the game (such as, for instance, a scenery object
that refers to the exterior of the building), as ambiguities could trip
you up.
Note also that if you define an object in a non-default way, the code
below won't necessarily produce intuitively transparent results. For
instance, I have a couple of objects for which, initially, isListed =
nil, so they won't show up in room descriptions. The first time doTake
is executed for these objects, I set isListed := true, so if they're
later dropped, they'll remain visible. Because of this, when I use my
"goget" verb to grab the object, if I then take inventory, the object
doesn't show up in the inventory list, even though in fact it's in
inventory. This is trivial, but if an object actually changes state when
it's first picked up, you may have to drop it after using goget and then
pick it up again. On the other hand, if picking it up is a puzzle, you
may not be able to drop it, because goget doesn't actually solve the
puzzle (unless you code it so that it does).
Have fun!
--Jim Aikin
// define the magic verbs:
goget: deepverb
verb = 'goget'
sdesc = "goget"
doAction = 'Goget'
validDo (actor, obj, seqno) =
{ return (seqno = 1); }
validDoList (a, p, i) = (nil)
;
gothereVerb: deepverb
verb = 'gothere'
sdesc = "gothere"
doAction = 'Gothere'
validDo (actor, obj, seqno) =
{
if (isclass(obj, loomRoom)) return (seqno = 1);
}
validDoList (actor, prep, io) = (nil)
;
// add this code to your customized 'room' class:
verDoGothere (actor) = {}
doGothere (actor) = {
"Moving via debugging verb...\n\b";
actor.travelTo(self);
}
// ...and this code to any other modifications you use
// for the thing class:
modify class thing
verDoGoget (actor) = {}
doGoget (actor) = {
self.moveInto(actor);
"Grabbed!";
}
;
The Despoiler
>Firstly, I'd recommend breaking the code into modules. You may find it
>works well to have a seperate module for the main NPC in the game, or a
>seperate module for the forest -- good boundaries for modules are case
>specific. I have all my modifications to the adv library in a seperate
>module, for example.
I definately see great value in doing this but when I try it in Tads 2
I get a bad performance hit! The same source code, once split into
modules, produces a larger final file size when compiled into the .gam
file!
Am I doing something wrong?
//Game.t
// Object definitions
...
//Main NPC definitions
...
// More object definitions
...
//end of Game.t
Compiles into Game.gam
Binary size = 157k
Then once I split it as follows:
//Game.t
#include "npc.t"
// Object definitions
...
// More object definitions
...
//end of Game.t
//npc.t
//Main NPC definitions
...
//end of npc.t
Compiles into Game.gam
Binary size = 161k
All I did was cut out a block of code and put it in a different file.
I get the exact same behaviour but a bigger binary file. (Overhead for
extern variables?)
I guess you should split up your code for development but bring
everything together once its ready for release...
______
The Despoiler
atholbrose
news:3ccf4eef...@news1.sympatico.ca:
> Compiles into Game.gam
> Binary size = 157k
>
> Then once I split it as follows:
>
> Compiles into Game.gam
> Binary size = 161k
I really wouldn't worry about a 4K difference; that's minimal and the
modularity of the code will be a benefit to you. TADS files zip really
well, anyhow.
--
r. n. dominick / cinn...@one.net
mini-if site: http://w3.one.net/~cinnamon/if/
Stephen L Breslin
wrote:
>I really wouldn't worry about a 4K difference; that's minimal and the
>modularity of the code will be a benefit to you. TADS files zip really
>well, anyhow.
I would add that the modularity will be a benefit to your readers, if
you decide to publish the source. I recall that Uncle Zebulon's Will
is a very nicely modularized TADS2 game, and quite a bit easier to
read because of how neatly the source is organized.
Cheers,
Steve Breslni