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

• Be polite or be ignored.

• Asking about something when you need it will often inspire us to come up with a quick (albeit unpackaged) solution you can apply, so it's more productive than waiting til postgame. And even more so if we answer "Uh, that's available already, see there? Use that." Of course, in that case you obviously didn't bother to read the docs first to check for a way to do it, did you? Sheesh.

• 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 may send you a feedback questionairre. Most of the Template's to-do list derives from such GM feedback, especially from Czars.