Usenet 1994 October/usenetsourcesnewsgroupsinfomagicoctober1994disk2.iso/games/volume13/dominion/part27/TASKS

Text File | 1992-02-11 | 6KB | 137 lines

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.

-- Battle code must be completely redone.  Right now it only supports
   land-land warfare properly, and other situations are pretty weird.
   it would also be nice if it handled the capturing of cargos and so
   on.
   [Titus and Charles are currently working on that and have almost
    finished.]

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

-- Make "dom_add" give new nations a contiguous land (or water) mass.
   Nations that start out split have a severe handicap.

-- 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 UNIX interface with a ".dominionrc" file, and other such stuff,
   would be quite nice.  [this has already been provided by Paolo,
   but is not yet included]  Stephen Underwood has made the [O]ptions
   be saved in a file, which might make the ".dominionrc" file
   unnecessary.

-- A bold idea proposed by Paolo Montrasio [[e-mail]]
   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.
[----]