1pMARS is a team project, and we're always glad to see it ported to new
2machines, operating systems and graphical environments. If you want your
3code contributions to be incorporated into future pMARS release, please
4follow these simple guidelines:
5
6    * before you start changing the main files, request a copy of the most
7        recent code. pMARS is constantly changing, and we likely have
8        "unreleased working code" that outdates the archive you downloaded
9        from the corewar ftp site. We can merge updates to old pMARS code
10        with our current working code, but this is error-prone. Another
11        reason for letting us know about your changes ahead of time is
12        that someone else may already be working on it.
13
14    * don't send patches or diffs to the main files, but rather the entire
15        file. This is related to the previous point: you are unlikely to
16        have an up-to-date copy of the source.
17
18    * new display code should go in seperate *disp.[ch] files to keep the
19        source modular. For consistency, try to maintain the "look-and-feel"
20        of preexisting displays and user-interfaces and use similar variable
21        naming and formatting conventions.
22
23    * use a descriptive preprocessor symbol to bracket your code additions
24        to the main files. Try not to use a compiler-predefined symbol
25        (__SYMBOL__), but rather come up with a name yourself and add a
26        section to config.h that automatically #defines your symbol if a
27        compiler-predefined symbol is defined. This makes it easier to adapt
28        your code to a different compiler that happens not to predefine the
29        same symbol.
30
31    * in general, follow the examples of previous contributors, and if you
32        have any questions, let us know.
33
34Contact Stefan.Strack@Vanderbilt.edu if you plan on contributing code
35or if you would simply like to know who is doing what.
36