@dircategory Games @direntry * Dominion-design: (dom3-design). Dominion Version 3 Design Document
@paragraphindent 2
@parskip 4pt plus 1pt
Copyright (C) 1997 The Dominion Project
Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice are preserved on all copies.
Permission is granted to copy and distribute modified versions of this manual under the conditions for verbatim copying, provided that the entire resulting derived work is distributed under the terms of a permission notice identical to this one.
Permission is granted to copy and distribute translations of this manual into another language, under the above conditions for modified versions, except that this permission notice may be stated in a translation approved by the author.
Dominion is an empire-style game, originally developed by Mark Galassi and a group of his students at Stony Brook in the late 1980s.
Dominion was inspired at first by the very imaginative but poorly coded game of Conquer, written by Ed Barlow and maintained by Adam Bryant.
Dominion quickly became very popular and is still surprising popular, even in the mid to late 1990s, when client-server games with graphical user interfaces are the norm. In fact, it seems that some popular commercial games like civilization have taken much inspiration from Dominion.
Since there still seems to be a need for a game like Dominion, but with a client/server based core and the possibility of writing GUIs for it, I thought it would be good to begin a re-design effort for Dominion.
This document collects my ideas, along with those of the Dominion team, on how Dominion-3 should look.
Dominion should run nicely on any UNIX platform.
You can obtain Dominion from the anonymous ftp site @url{ftp://max.physics.sunysb.edu/pub/dominion-snap.tar.gz}
You can then follow instructions in the INSTALL file, which will basically tell you that to install the game and data files you run:
./configure make install
To start a game:
make new-world [answer questions] dom_server dom_add
and to play a turn for your nation:
dominion
NOTE: the current snapshots do not yet work like this. Right now you can follow the configure and make install steps, then start the server with dserver, and then do telnet server-hostname 4430, since 4430 is the dominion port.
See the node section Getting and installing the Dominion prototype for instructions on how to get a current snapshot, look through the code and documentation, and make suggestions or write code.
Here are some of the requirements we have for Dominion-3.
Here is a description of the global variables in the Dominion server. Keep in mind that the data structures are very closely tied to the file formats described below (see section Dominion world files).
#define NAME_LEN 1000 /* max lengths for name-like strings */
We could store some of this info in a history file, which would be fun and might be a good diagnostic tool.
struct s_user {
char nation_name[NAME_LEN];
int is_auth;
char client_info[NAME_LEN];
char login_time[NAME_LEN];
char logout_time[NAME_LEN];
};
typedef struct s_user Suser;
extern Suser this_user;
struct s_nation {
char nation_name[NAME_LEN];
Srace race;
Sarmy *alist;
Spt *ptlist;
};
typedef struct s_nation Snation;
This chapter contains a description of the file formats for the dominion world.
These files typicallly store the standard Dominion structures structures Scargo, Sarmy, Srace, Soptions, Sconstruction, Snation, Sspell, Sh_spell, Sspirit, Sdiplo, Ssector, Sgeo, Sworld.
Each time a data structure contains a pointer, the pointer is written
out as NULL. This can be useful because we know if a pointer has
been assigned. It can also help to verify file integrity: when the file
is read, if a pointer is not NULL, and an error should be
reported.
There are two ways we could store data, and it might be interesting to present the option of both, as determined by a magic number in the first two byes.
In the binary format, integer-type data is stored in network order on the server machine. In the ASCII format there is no such issue.
The server always sends these integers to the client in network order or in ASCII (I have not yet decided which).
Frequently the nation and sector data structures reference each other. For example, each nation has a list of all the sectors it owns, and each sector has a pointer to the nation that owns it.
The issue comes up: "which of these gets saved to file?" The specification for each data structure and file format has to address that issue: only one copy of the information will be saved, and when the information is read in, the other copy must be generated properly.
This contains physical information about the world. This is a description of its format.
The major organization is that it contains a list of all the sectors in the world, arranged by matrix order @math{(0, 0)}, @math{(0, 1)}, and so forth.
Here is a list of what goes in the file.
magic number
#define FORMAT_ASCII_0 'f' #define FORMAT_ASCII_1 'a' #define FORMAT_BINARY_0 'f' #define FORMAT_BINARY_1 'b'
world.topology
world.xsize
world.ysize
world.sectors[0][0]
world.sectors[0][1]
...
world.sectors[0][world.ysize-1]
world.sectors[1][0]
...
world.sectors[world.xsize-1][world.ysize-1]
Here is a description of the routines available for extracting the terrain information from the terrain file. These routines are usually called by the server to get the bits of information that the client is requesting.
#define TERR_FNAME "terrain"
terr_get_file_format().
terr_get_topology().
TERR_TOPOLOGY_TORUS.
The next few routines are for manipulating the world structure as a whole.
This contains a list of all nations in the world. It is closely modeled
after the Snation data structure. As with the terrain file, the
data can be stored in ASCII or binary formats, and the same magic number
is used.
magic number
nations.n_nations
nations.list[0]
nations.list[1]
...
nations.list[nations.n_nations-1]
Here is a description of the routines available for extracting the nation information from the nation file. These routines are usually called by the server to get the bits of information that the client is requesting.
#define NATION_FNAME "nations"
nation_get_next() mechanism can
work.
NULL, then opened the first time a nation is read
from that file. Reset to NULL after the last nation is read and
the file is closed. Hmm: must figure out a way to associate these with
the nation file name.
nation_get_file_format().
bla
bla
If an error condition is met by the Dominion server, the server should handle it in an intelligent way
The Internet Dominion Playing Protocol (IDPP) is the elementary language accepted by the Dominion server. I based it somewhat on the SMTP interface, since I am acustomed to typing at an SMTP port.
The server reads a line of input from the client and parses it. The first word (separated by the space character) is the command, the rest of the line contains arguments.
The client does not yet do much with the protocol, but the server understands the following commands, so you can practice telneting to the Dominion server port (by default 4430), and typing these commands at it.
It is very important that we plan a series of prototyping manouvers that can be carried out by a core of prototypers who have not committed time to the project yet.
If the prototypes are successful, then I expect that someone on the team will be willing to start real development of Dominion.
Here is a tentative list of prototyping actions that should be performed to gain some momentum on Dominion.
If you are interested in joining the development of Dominion, please contact Mark Galassi (rosalia@nis-mail.lanl.gov). To get up to speed on the issues and technologies involved, you could peruse these network resources.
I am collecting here the list of authors who are to have access to the CVS repository.
None of these people have written code yet, but they are participating in or making comments on the strawman design.
scm extensions (beyond Scheme standards).
Documentation on the internal representation and how to extend or
include scm in other programs.
This is an alphabetical list of all the procedures and macros in Dominion.
This is an alphabetical list of the major global variables in Dominion.
This is an alphabetical list of the major data structures in Dominion.
This document was generated on 5 March 1998 using the texi2html translator version 1.51.