Re: Whizzard's adv.t file in progress. Ideas being accepted.


11 May 1995 05:10:32 GMT

In article <baf.800149158@max.tiac.net>,
Carl Muckenhoupt <baf@max.tiac.net> wrote:
>
>One thing I've thought about is greater modularity. In other words,
>seperating adv.t into a set of files that the programmer can choose to
>include or not. Does it really make sense for all TADS games to include
>the code for starvation, for example?

No, it certainly doesn't, and that particular bit of code is high on myy
hit list for seperating out. But yes, modularity is part of what I'm
after. I wonder, could someone write a C program that would search
through .t files pointing out all the objects that aren't used in a
particular game? It would be handy when optimizing for size.

>At one point, I tried dissecting adv.t into components that I considered
>to be intuitively distinct, writing new code where necessary to fill in
>the holes that were left when something else was torn out (taking
>advantage of "modify", of course.) The only reason I abandoned the
>project is that I'd have to keep maintaining it as new versions of adv.t
>came out, and I'm far too lazy for that. You're welcome to do it for me,
>of course.

See, my plan is to pawn this new adv.t off on M. Roberts and get him to
use it as a standard. That way, any changes he makes to it will be
something I don't have to deal with. I think he'll like what I'm doing
with it.

>At the core, I had something like three files, one providing elementary
>input processing like specialwords, one handling containment, and one
>handling elementary output routines like listcontents. Concepts like
>"rooms" and "travel" got their own files. The hard part was deciding
>what I could rely on in each file; you wind up essentially making a
>dependence tree for include files, just as you do for classes.

I'm not going that far. I have function.t, objects.t, verbs.t, header.t,
and include.t. Include is the primary file. It includes the others, and
doesn't really do anything else except describe the evocable packages and
contain the #define lines that will turn them on. object and function
are both fairly obvious, and so is verbs.t. I shunted all the weird
stuff you never play with into header.t so I could ignore it. ie
specialWords, compoundWords, and of course, format strings. Finally,
each package has a .t file that is #include'd only if the package is
being used.

I really do hate to use all these include files, as it cuts down the
number for the prospective game author to use him/herself, but it's the
best way I can do it, organizationally speaking.

-- 
<~~~VERTIGO~~~~~~~~~~~~THE~BRASS~LANTERN~~~~~~ISSUE~1~INCL~W/AVALON~~|~~~~~~~>
< In the irreverent tradition of _The New Zork Times_ comes The      |  ~~\  > 
< Brass Lantern, an informative newsletter from Vertigo Software.    | /~\ | >
<___SOFTWARE___________________________whizzard@uclink.berkeley.edu__|_\__/__>