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__|_\__/__>