Unix Programming - Studying Cases - Case Study: Freeciv Data Files
Freeciv is an open-source strategy game inspired by Sid Meier's
classic CivilizationII. In it, each player
begins with a wandering band of neolithic nomads and builds a
civilization. Player civilizations may explore and colonize the world,
fight wars, engage in trade, and research technological advances.
Some players may actually be artificial intelligences; solitaire play
against these can be challenging. One wins either by conquering the
world or by being the first player to reach a technology level sufficient
to get a starship to Alpha Centauri. Sources and documentation are
available at the project
we'll exhibit the Freeciv strategy game as an example of client-server
partitioning, with the server maintaining shared state and the client
concentrating on GUI presentation. But this game has another notable
architectural feature; much of the game's fixed data, rather than
being wired into the server code, is expressed in a property registry
read in by the game server at startup time.
The game's registry files are written in a textual data-file
format that assembles text strings (with associated text and numeric
properties) into various internal lists of important data (such as
nations and unit types) in the game server. The minilanguage has an
include directive, so game data can be broken up into semantic units
(different files) that are each separately editable. This design
choice has been carried through to such an extent that it's possible
to define new nations and new unit types simply by creating new
declarations in the data files, without touching the server code at
The Freeciv server's startup parsing has an interesting feature
that creates something of a conflict between two of Unix's design
rules, and is therefore worth closer examination. The server ignores
property names it doesn't know how to use. This makes it possible to
declare properties that the server doesn't yet use without breaking
the startup parsing. It means that development of the game data
(policy) and the server engine (mechanism) can be cleanly separated.
On the other hand, it also means startup parsing won't catch simple
misspellings of attribute names. This quiet failure seems to violate
the Rule of Repair.
To resolve this conflict, notice that it's the server's job to
the registry data, but the task of carefully
error-checking that data could be handed off to another program to be run
by human editors each time the registry is modified. One Unix
solution would be a separate auditing program that analyzes either
a machine-readable specification of the ruleset format or the source
of the server code to determine the set of properties it uses, parses
the Freeciv registry to determine the set of properties it provides,
and prepares a difference report.
The aggregate of all Freeciv data files is functionally similar
to a Windows registry, and even uses a syntax resembling the textual
portions of registries. But the creep and corruption problems we
noted with the Windows registry don't crop up here because no program
(either within or outside the Freeciv suite)
to these files. It's a read-only
registry edited only by the game's maintainers.
The performance impact of data-file parsing is minimized because
for each file the operation is performed only once, at either
client or server startup time.
[an error occurred while processing this directive]