    ** Dec. 31 1996 **

I'm leaving the old tasks as ideas, but since we are moving into the
dominion-3 design, here are the few things that should probably be
done for dominion-2.

* Add all the fixes from the 1996 Ohio State University game players.
They spotted some bugs and I will be giving them access to the
repository.

* Completely remove the old clever-guessing configuration stuff and
move completely over to autoconf/automake.

* Port to all important architectures.

* Find out enough about how tables work in the latest texinfo, and see
about re-writing the documentation with those.  Documentation will be
largely reusable, and latexinfo is not at all supported, so it is a
good effort. [DONE, Mark Galassi]


-----------


[OLD] List of things that need to be done SOON for dominion 2.  -- Mark.

-- You can put troops on intercept in cargo units, and they will intercept
        into non-owned territories or owned territories, and over any
        terrain, land or water without drowning. The troops will also stay
        transported in the cargo, but they will be in the sector they
        intercepted into.

-- You can occupy water (land) sectors by unloading sailors/marines from
	a ship, setting them on occupy, then loading them back up.  They
	won't drown.

-- When you trade army units that have spells cast upon them, they become
        permenent and you are able to split the troops. Vampiric troops
        are nasty in this way. Just keep on splitting them.

-- You can initiate mages in owned sectors that are hostile, or with no
	population.

-- You can transfer between ships/caravans on different sectors.

-- Troops can intercept into enemy territories?

-- Bug with vampire_army spell lets you get vampiric ships.  Disbanding
	them gives lots of metal!  (MDF FIXED 1/4/93)

-- Spells are not deleted when an army drowns.  The next army with that
	ID gets the spell.

-- Using the spell CASTLE, you can redesignate a sector that you own that
        is hostile in your enemies territory as your capitol, and then
        castle a bunch of troops over and whomp them, and then redesignate
        your capitol back to a safe place.

-- You can use CASTLE to drop any army unit in enemy territory. Just castle
        the cargo unit to your capitol, and then since your cargo unit
        is in your territory, you can unload the army unit which is still
        in the enemy territory.  Also, CASTLE should reset an army's
	status to DEFEND.

-- Spells like 'fly' and 'haste' should be proportional to army weight, not
	size.  This takes care of flying ships. (PARTIAL FIX)

-- Disguised armies are not handled at all in battle reports.

----------------------------

Perhaps for future version 2 releases.

-- Spell list hides army numbers; makes it hard to remember army ID desired.

-- Hanging spell list needs to be more informative

-- When you get cargo mail for a sector trade, are the coordinates correct?

-- Some strangeness with water_walk'ed canoes, etc, drowning.

-- When highlighting your armies, your hidden armies aren't highlighted.

-- Get the bonds data structures incorporated somehow so that the file
	format does not change when we implement them.

-----------------------------

List of tasks to be done for dominion, with concise reflections on
how they might be done.

					Mark.

[ My main concerns are: ]

-- No features should be added for which it takes longer to play.

-- A system of going into debt, possibly the system of issuing bonds
   outlined in the manual but not implemented.

-- Trimming the manual.  The manual is big and has lots of repeated
   stuff.  In particular, the Getting Started section should be
   replaced with a "Don't Panic" section which really takes the user
   by the hand for the first couple of turns.  People who are not
   experienced with war games are quite overwhelmed at first.  We
   should also rearrange the chapters and sections.

-- Thoroughly test the new battle code.

-- More spells, and make spells useful (currently people use their
   spell points only for spirits).

-- Make hospitals have some effect.  One idea thought of independently
   by Chris Adami, Titus Brown and Mark Galassi is to make them
   have an effect on deaths in battle if they are near enough
   to a battlefield.

-- Construct-types should be defined in an abstract way and determined
   by technology, just the way army types are.  If you want to think
   of a scheme for that, let me know what you come up with.

	The next two items are for the far future:

-- A built-in programming language interpreter to allow for more
   extensions in the game.  As it is, we have a mini-interpreter
   for the exec commands, and if someone is studying compilers and
   wants to implement something more general, then whole new horizons
   will open up.

-- Split the game into a client and a server.  This would allow 2
   things: (secure) remote access through a network, and the
   possibility of high-quality graphics interfaces in the future.
   [Titus is currently working on a simpler idea to make the game
    playable over the network.]

-- A bold idea for "distributed dominion" proposed by Paolo Montrasio
   [montra@ghost.unimi.it] which is best summarized by including part
   of his message and my reply to it which includes my reflections on
   how it might be done.

[--Paolo--]

- Now the BIG idea. I read in the TASK file that the dev. team is planning
  to rewrite dominion using a client-server architecture. This is intended
  to allow remote-playing and the development of some graphical interface
  (X11 ?). This is a good idea, but not so innovative. This is my own idea:

  We have a > 200,000-hosts network, the Internet. A lot of universities
  are linked to the Inet, and you know that the students are good players.
  So we have a lot of potential dominion players. Why must we force them
  I think you know what IRC is, however I cannot be sure, so here is a
  SHORT explanation:

  IRC is chat system (you can login and talk with everyone has access to
  the Inet) with a clever architecture. There a lot of servers, linked
  together, and distributed across the world. The clients links to
  the nearer server and are still able to talk with someone at the
  other end of the net. If IRC was built around central-server machine,
  this machine would suffer of overloading.

  I think that this distributed architecture can be applied to dominion
  to reach the following goals:

  - use the storing capacity of any single (interested!) Inet host
    to store a part of the world.

  - allow thousands of players to play in the same world.

The topology of this world must allow an indefinite expansion of the
playing ground: I think that an unbounded flat surface must be used.
When too many new players join the game a new portion of the world is
generated and stored on a server near them.

I think that an "expert" in distributed databases can help a lot
in designing such a system. Conversely, if someone does implement this
system, he'll became a distributed DB expert!

I don't think it is an easy job, but it is very fashinating, isn't it?

[--Mark--]
    As for the distributed database aspect, you are quite right.  It is
extremely ambitious to decentralize it that way.  If all the servers were
to keep complete data, then it would be quite easy, since the game
is not real time.  There are right now a couple of real-time elements:
mail and diplomacy.  The diplomacy can be made to change over the update,
(some people already want that) and the mail could too, or alternatively
ordinary email could be used for mail.

    We are due for a meeting in which we make improvements on the battle
algorithms.  Then we will implement those.  After that, I think we should
dedicate our attention to your idea.  Here is my simple-minded first-try
approach:
        1. each server has a planet.
        2. each nation starts on a given planet
        3. if a nation discovers and can colonize another
           planet through magic or technology, then their nation
           participates in the updates on those planets.  when they
           select the army or sector that is on the other planet, then
           the software would not have to do any special networking
           stuff, since the data would be duplicated on all the servers.
        4. over the update the networking aspects come up.  the update
           program would have to collect exec files from all the servers,
           then run the update on one of the servers, then ship out the
           new  data files to all the servers.
        5. for integrity, there would have to be a system to either force
           a nation to play always on the same server, or at least to make
           sure that he does not have an exec file on another server when
           he starts up a session.

    This is simpler than what you had said, and is less distributed, but
might be doable with minimal changes to the software.
[----]
