Go to the first, previous, next, last section, table of contents.

Game Module Organization

Each separate file is known as a game module or just module. A module has a name, displayed name, an advertising-style blurb, a version, and designer notes.

This is an example of an elaborately-declared game module with no actual content:

(game-module "foobar"
  (title "Foo of Bar")
  (blurb "An exciting game with lots of cliffhanging suspense")
  (version "1.3")
  (program-version (>= "7.0.3"))
  ;; other properties?
  (complete-game true)
)

;;; contents here

(game-module (notes (
  "This is just a sample game."
  ""
  "It's not really as interesting as the blurb makes out."
  )))

(game-module (design-notes (
  "This is commentary addressed to other designers."
  "Also a good place to mention things to work on."
  )))

The notes and design-notes could have been supplied with the first game-module declaration, but in practice, putting the player and designer notes at the end of the file keeps them out of the way. You can supply any number of game-module declarations in a file. Only the first need include a name.

The game module format is only loosely structured. In general, anything that you might want to reuse or combine in different ways should be a separate module. Good candidates include text generators and maps of real terrain. Unfortunately, they don't always mix-and-match as well as you might like!

The following are the generally preferred module names:

Terrain-only modules should be named t-xxx.

Lists of units should be named u-xxx or ob-xxx (for "order of battle").

Name generators should be name ng-xxx.

When supplying a year in the module name, use four digits, unless the rest of the name makes the century clear (WWII scenarios are pretty much guaranteed to be in the 20th century!).


Go to the first, previous, next, last section, table of contents.