Template Philosophy
Design
The primary design goal is KISS -- Keep It Simple, Stupid. All the
following goals arise from that.
- Only latex and perl shall be used. No makefiles, autoconf, etc.
Postscript figures may be included in latex, but no raw postscript hacking
should be required. Furthermore, whatever versions of latex and perl
are the Athena defaults are what the Template shall use, though it may
use packages not in the default set.
- A team should need only a little latex knowledge and no perl knowledge
to use the package in default configuration. A game without mechanics
that require latex hacking should be able to get away with using
everything out of the box at the "fill in the blanks" level,
no tex/latex hacking required.
- A team should need only latex knowledge to customize the package in
most obvious ways. Perl scripts and tex style files are there to handle
black magic so you don't have to.
- A piece of information should reside in one and only one place.
For instance, the game name goes in one file, which is included by
all other files that need it. Similarly, all sheets share a common
style file, making it easy to customize the game look.
- All (or as much as possible) character information goes in one file.
We believe this is a simpler approach than the obvious alternative of
giving each character their own directory.
- Lack of a possible feature is not a bug! As long as GMs are no
worse off with the Template, it's ok. For instance, we do
provide \rot to 'encrypt' text, but not providing it would have been fine.
Policies
Here are the guidelines on proposing changes:
- Any change which removes functionality will require you to demonstrate
that this functionality is not used in more than one recent game in the
archives. (Recent is approximately equal to "within the last 5 years.")
- Any change which only affects implementation, but not functionality,
must be a substantially cleaner implementation than the existing
implementation. If you want to change the way in which an end
user interacts with the Template, you'd better be way superior,
or it's not worth fiddling with.
- Any change which adds functionality will probably require you to
demonstrate that this functionality is used in more than two games in
the archives. We're not much interested in hypotheticals or one-shots.
A poll on the template-gms list showing strong
desire for the feature is a great way to get it on the to-do list.
- As per the design philosophy above, we won't use anything that's
neither (la)tex nor perl (or a bit of postscript). No autoconf, no
make, etc.
We reserve the right to flagrantly violate these guidelines.
Send suggestions to
template-dev@mit.edu,
but first look at the to-do list and see
if we're already planning on it.
BTW, if you've told us your game is using the Template, then after
it runs we'll send you a feedback questionairre. Most of the Template's
to-do list derives from such GM feedback, especially from Czars.