[net.games.emp] Questions

desj@brahms.BERKELEY.EDU (David desJardins) (01/11/86)

   Here at Berkeley we have a version of Empire described as "Export Version
of Feb 26 1985".  We have the object only, no source.  Can someone out there
tell me:
   1) Is this the most recent version available?
   2) Is the source for this or a similar version available?
   3) Is this game in the public domain?
   4) Where is the most current version of Empire being maintained?
      There are several fairly substantial bugs in the version we have
      which I would like to report to someone...
Please don't deluge the net with responses to these questions; if you mail
me responses I will summarize to the net.

   I would also like to know more about the history of Empire.  I know some-
thing about its development but not a lot, and I'm sure there are a lot of
other people out there who would be interested.  If you have complete infor-
mation please post it, but if you just have limited information mail to me;
I will summarize if a good comprehensive response does not appear.

   Finally, I have some (lengthy!) comments on the version of Empire we
have, not really bugs but rather design decisions I don't particularly agree
with.  I am interested in getting feedback on these points from other exper-
ienced Empire players.  I am seriously considering the possibility of devel-
oping a new version of Empire more to my liking (not that I don't think
Empire is wonderful, just that I think it can be improved...), which is part
of my reason for asking #2 & #3 above (I would certainly prefer to adapt the
existing software if possible!), and for requesting feedback on the following
points.  It is probably just as well to post comments on this to the net
(I'd like to get some traffic going on this newsgroup!) unless you want to
discuss your comments with me first.  But please trim this down if you
include the text in your reply; the last thing we need is to post 20 copies
of this entire message...

   A) There are a number of things in the game that depend strongly on how
often a sector is updated.  These include plague chance and production (due
both to rounding losses and to the way in which gold and petro resources are
depleted) as cases in which frequent updates are detrimental, the execution
of deliver as a case in which frequent updates are generally beneficial, and
the execution of contracts as a case which can be either.
   I understand the need to avoid loading the system by updating every
sector every time unit, but I would much prefer to see a game which at least
simulates such a situation; i.e. the results should be the same if a sector
is updated every time unit or only once a day, at least within a relatively
small margin of error.

   B) One particular effect that is strongly dependent on update frequency
is the depletion of nonrenewable resources (oil and gold dust).  In our game
the depletion takes place whenever the sector is updated, so that between
updates the sector is producing at a constant rate, but as soon as the
sector is updated the rate drops, often to 0 if it has been long enough
since the sector was updated.  By not updating these sectors for long enough
periods you can produce far more than the nominal total oil or dust content
of the sector, and can even "roll" the resource over to 80 or 90% (due to
the use of 8-bit integers).  Of course this last is a bug, not a feature,
but I think it is symptomatic of the way updates are handled.

   C) I also dislike the mobility system as it is currently implemented.
To my mind it reduces playability and increases complexity without any
substantial benefit.  I especially dislike the idea that a sector with 1 mil
generates the same mobility as a sector with 999 civs.
   My thoughts on this are that a system could be substituted in which the
cost of moves could be paid in a more global way, so that the individual
mobility of each sector would not be so much of a concern.
   Two possibilities are either a $$ cost for each move, or possibly a new
type of sector which would produce mobility units which could be used where
needed.  In either case the cost of a move would still be based on distance
and terrain, but would be charged on a global rather than a local basis.
   With this change deliver could also be simplified and its implementation
improved (in that you would not have to worry so much about moving items
from sector to sector to sector, but merely from source to destination).
   Note that I am not considering here the military implications of mobility,
which will be discussed below.  Nor am I discussing ship mobility, which
seems to work fairly well, although there is some room for improvement in
the way ships are moved.

   D) The contract system as implemented in our game is seriously flawed.
First, the prices are totally random and on our system are so skewed toward
food that it is not even reasonable to sell anything else.  And second, the
way that the contracts are executed (1/2 of the stockpile is sold each time
the sector is updated) is inconvenient and generally unmanageable.
   I envision a possible threshhold system in which all production above a
certain level would be sold.  Prices of different items would be brought
more into line with production costs, either simply by adjusting the ratios
or more likely by implementing a supply/demand system (if everyone were
selling food the price of food would drop and that of other commodities
would rise).

   E) I would like to see technology play more of a role in the game,
allowing a sort of continuous advance throughout the game, rather than a
one-time push for high technology and then conversion to production of huge
numbers of ships/guns/shells/nukes.  One idea is to have more different
types of military hardware, obtained with advancing tech.  With compara-
tively little difficulty you could have tech be an ongoing effort throughout
the game, rather than a sort of one-time all-out push.

   F) The artificial device of allowing a very high population growth rate
but then capping the population of each sector does succeed in allowing
rapid growth but forcing geographical expansion, and so is less objection-
able than some of the other matters I have mentioned.  However it does give
a huge advantage to those on larger land masses; only 100 time units or so
after one player has filled his 50 sectors, another player will have filled
his 100 sectors and have twice the production capacity...
   Part of the problem with this situation is that I can't think of a better
way of doing things.  This is, of course, why I am looking for feedback!

   G) While I'm not sure what to do about population growth, or even if
anything should be done, I know that something has to be done about mil
growth.  Only another 100 time units after your land mass is filled with
civs you can have 999 mil in every sector.  It's true that this reduces your
production somewhat because you have to feed and pay all of these mil, but
they do add 20% to your workforce, and further give you a tremendous
defensive capability.
   It seems acceptable to me that you will eventually have 999 civs in every
sector via one means or another, but I cannot accept a combat system in
which there is no allocation of mil to where they are needed, but rather you
simply have the maximum number of mil in every sector from the border all of
the way in to your capital.  I have thought of at least three ways in which
the number of mil could be limited.  Note that the absolute numbers of mil
are not particularly important, only the ratios between players.
   One idea is rather artificial, but would simply limit your total mil to
some proportion (say 10%, but as noted above this is arbitrary...) of your
total population.  Another idea would be to increase the pay of mil to a
point where it would only be possible to maintain a small number.  And a
third possibility which I like is to have a maximum enlistment rate (say
1%/day, but it could be affected by happiness) combined with a constant
retirement rate (say 10%/day).  The maximum enlistment rate could be imple-
mented either by allowing only one enlist order per day, for some maximum
percentage, or by having enlistment be an automatic process that takes place
at a constant rate, possibly controlled by the ruler.
   This seems so much preferable, in that it would force you to move your
soldiers to the front, allocate them where they seem to be needed, etc.

   H) To go with the above the combat system needs essentially a complete
revision (certainly if mobility is eliminated something needs to be changed).
The current system basically regulates combat by having a 999 mil vs.
999 mil combat take 1/2 hour and use 100+ BTUs and 200+ mobility (and you
can add 40% to the mobility cost by designating your defensive sectors to
wilderness...).  Needless to say, I think this can be improved!
   I actually have lots and lots of ideas about combat, most of which are
probably impractical.  However, one which I definitely consider valuable is
retreats!  This is what real combat is about: a superior force attacks an
inferior force, the superior force takes a few casualties, the inferior
force takes more casualties, the inferior force retreats and the superior
force advances.  The rate of advance is limited by the available supplies
and equipment and the strength of the resistance.
   This seems not at all hard to incorporate into Empire.  The limited rate
of advance could easily be implemented as a time period during which attacks
out of a just-captured sector would be prohibited.  The time would depend on
the relative strengths of the attacking and defending forces, the terrain,
and possibly equipment (more on this below).  The idea of a defensive line
through which it would be possible but difficult to break would be repre-
sented by the defensive troops, which would retreat to adjacent sectors and
maintain continuity of the line, and possibly by adjacent sectors adding
some of their defensive strength to an attacked sector, to prevent concen-
trations of strength against individual sectors.
   Of course the combat system would be reworked so that it would not take
1/2 hour for one battle; I don't think this would be too difficult.  Nor
would it cost 100 BTUs for each battle.

   I) I don't like the bombardment system either (I sure am hard to
please!).  An attack with 1 mil can draw fire and use up shells from all
of the forts within range.  On the other hand, in a real bombardment, for
every shell fired every enemy fort within range can fire one shell back.
But if there are no enemy forts, or if your range is greater, you can
bombard over and over until the defenders are completely obliterated,
although it consumes huge numbers of BTUs since you may well bombard a
sector 30 times or so (just yesterday I bombarded a capital 48 times and
then captured it with 30 mil...).
   I don't have a definite plan on how to deal with this, but my feeling
is that artillery (and possibly other types of military equipment, below)
should be incorporated into the combat system.  That is, part of an attack
would be your guns firing at the enemy and his guns returning fire.  I
certainly don't have strong feelings about this, and I definitely would
like to hear other people's ideas.

   J) And I don't like the tremendous bias toward nuclear weapons.  I
suspect the intent was to simulate real life by making nuclear weapons so
destructive that they could never be used.  The effort was not entirely
successful in that the first player who gets the 300 tech our game requires
for nukes can start blowing everyone else away!  Note that this is partially
due to the way resource depletion is handled in our version, mentioned
above, which makes it very easy to build lots of nukes.
   But in my opinion the nukes don't add anything to the game except to
break the deadlocks caused by the way combat is implemented, and so in my
opinion they should simply be eliminated, or their effectiveness should be
sharply reduced in some way.  I would like to hear from people who disagree
and would like to retain the nukes, but please don't tell me you want them
because they are realistic.  My interest is playability, not realism.
   
   K) Connected with the changes involving bombardment could be the intro-
duction of other types of military hardware.  In as much as this constitutes
an extension rather than a modification it is even more ambitious than the
other things I have mentioned, but I would like to bring the subject up for
discussion.
   Things I would like to see, in increasing order of technology, are
various types of ships, trucks (increase rate of advance), halftracks
(ditto), tanks (same, plus combat value), different types of planes
(fighters, bombers, cargo (paratroopers!), reconaissance, ASW, ...), anti-
tank weapons, anti-aircraft weapons, helicopters, spy satellites, and more,
most of these in varying versions so they would provide a motivation to
advance your technology.
   All of this may well be considered excessive, particularly by those who
see Empire as more an economic than a military simulation...  And I am
certainly not enough of an expert on such matters to impart more than a
relatively small degree of "realism"...  Certainly this is something to be
considered only after many other things have been done.

   L) It would certainly be much more convenient to play Empire if it were
to make use of some sort of video terminal output, along the lines of the
Visual Empire which was recently distributed, but built into the game so
that that would be the way you would gather information, give orders, etc.
The cost of this, of course, would be to rule out playing the game on non-
video terminals, but that seems to me to be barely a restriction.  I suppose
another disadvantage would be that the Empire program would be slowed down
a little, and perhaps it would play would be a little slower on slow
terminals (I don't suppose it would even be possible at 300 baud!), but it
still seems like it could be a good idea to me.  Any comments?
   
   Anyway, those are the major points which I wished to bring up.  Comments
are definitely encouraged; if you think I'm completely wrong please say so.
My primary reason for posting all of this is to get some discussion going!

      -- David desJardins (ucbvax!brahms!desj)