IMPERIUM REX v1.01 - OVERVIEW/FAQ v1.0 (January 17, 1994)
---------------------------------------------------------
Imperium Rex is Copyright (c) 1989-1993 Brainstorm Software
This document file is Copyright (c) 1994 Brainstorm Software
0. PRELIMINARIES
Concept development, programming, and testing by Glenn Robins.
Concept development, testing, and story writing by Jens Winslow.
This OVERVIEW/FAQ document written by Glenn Robins.
Imperium Rex v1.01 is FREEWARE: You may freely distribute this program so
long as it is distributed in its entirety and is unaltered.
This document may be freely distributed as-is (with no ommissions or
changes).
This OVERVIEW/FAQ document is intended to encourage new people to try this
game by providing some details that an index description (if any) will not
give you, and to provide current users with some playing hints and answers
to common questions.
This file, or an updated version of it, will be sent to all people who
request preliminary information about the game, and to those who are on my
e-mailing list. To add yourself to this list, just mail a short message to
me indicating your registration request. You will then be notified of
anything that may interest you with regard to Imperium Rex. I expect that
only a small group of people will take interest and register. For this
reason, I encourage you to register - every response I get will contribute
significantly. The quantity of registered users, as well as qualitative
responses will dictate this program's future (and the time I invest in it).
I would especially appreciate any negative comments that people may have,
even if they are only based on first impressions.
This game will cost you NOTHING to play, except time. Be warned that
depending on the setup, it could take months until the state of the game
reaches a point where someone, or everyone resigns. It is NOT a game that
can be completed during a lunch hour (well, unless you don't know what
you're doing).
Part of this file will contain pertinent information from the actual game
manual.
Official Release Dates:
rex10.zip (Version 1.0): Oct.31/93
rex101.zip (Version 1.01): Nov.09/93 (Bug fix)
TABLE OF CONTENTS
1A. HARDWARE REQUIREMENTS (Abbrev.)
3. GAME DESCRIPTION AND OBJECTIVES
4. TYPICAL START TO A GAME
4A. ADDITIONAL PLAYING TIPS
4A.1 EARLY IN THE GAME
10A. LIST OF PLAYER OBJECT TYPES
20A. COMMENTS BASED ON USER FEEDBACK
20B. OTHER COMMENTS
20C. FUTURE POSSIBILITIES
99. CONTACT AND DISTRIBUTION INFORMATION
1A. HARDWARE REQUIREMENTS (Abbrev.)
- Any 80x86 processor
- At least 500K of conventional RAM
- VGA and colour monitor
- A MOUSE is STRONGLY recommended
- Roughly 1MB of hard drive space
(Video mode is most often text with an alternate character set;
Tactical maps are 320x200x256 VGA)
3. GAME DESCRIPTION AND OBJECTIVES
This is basically a world domination game: Your goal is to take over
and rule all of civilization (for the good of the people). Strategy,
tactics, and logistics all play a role in the success of your empire.
You will start by ruling one city and having ownership of just a few
objects. Then, you will seek out the establishments of your opponents
and forcefully persuade them to follow your cause (since there is no
time to reason with them). However, the largest and most powerful of
your prey are an alliance that stands for freedom and independent
rule, and resists change with all their might: the Neutral Player
(NP). The actual introductory story is presented to you as you begin
a new game - the one presented here is an extremely abbreviated
version.
There is a minimum of 1 and a maximum of 3 human players, and always
one Neutral Player that is played by the computer. Playing with only
one human is considered to be a practice game, as there is no threat
by a human opponent, and more importantly, the introductory story will
be inconsistent! It is a good idea to play a practice game for a
while individually, to get a good feel for the game before engaging in
a real contest.
A player is officially out of the game when all objects are destroyed
and all cities lost. It may be more often that a game is declared
over when all but one player verbally resigns.
A key to your growth and development is the exploitation of resources.
There are three types: Grain, Mineral, and Oil (see MAP FEATURE
OBJECTS). Cities and Settlements may collect these resources each
turn if they are scanned and in collection range. Cities can produce
objects that constitute your offensive and defensive forces. However,
to produce any object costs resources and MegaCredits (1 MC is a
million credits, where a credit is the standard global currency).
MegaCredits are obtained mostly from tax revenue (proportional to your
total tech-level) and profit from transactions on the global market.
There are three categories for the application of technology: Terra-
Tech (non-aquatic terrain-based objects), Aero-Tech (objects in
flight), and Hydro-Tech (aquatic-based objects). Moreover, there are
five levels of technology for each category (1 is the most primitive,
and 5 is the most advanced). Cities, over time, may advance tech-
levels in each tech-type if sufficient funds are invested in the
city's intellectual growth.
There are different surface types which affect the performance of
objects in different ways. These surfaces are: LAND, WATER,
MOUNTAINS, SWAMP, and JUNGLE. There are also infrastructure types
that may be built on some of these surfaces, which are: RAIL, ROAD,
and CANAL.
The global market is a virtual economy in which the exchange of
resource units takes place. If transactions are made carefully, you
may make a lot of money. It is also a secondary source for resources
if your own pool is low in a particular resource type (if you have the
money to spend).
4. TYPICAL START TO A GAME
If you play a normal non-region game (you'll know what that is when
you build a game), you will automatically be given a Fuel Depot, and a
Hover-Scout. These are the two most important and useful objects that
you can have as you start, since you are now able to locate resource
deposits. It is possible that more resources might surround your HQ
(other than the four that are deliberately placed there) since the
immediate area has not been scanned by a Hover-Scout. Scouting your
immediate surroundings is also a good idea, to make sure there isn't a
city just outside your city scan range (or some other nasty surprise).
Knowing the surrounding terrain early in the game will enable you to
quickly determine your strengths and vulnerabilities with respect to
your own location, and such knowledge may dictate what type of objects
you should focus your production on. Make sure that your scout moves
along the map diagonally, forming a triangular or diamond-shaped
search pattern - this is the most fuel-efficient scheme for patrolling
the maximum area.
If you happen to find a Neutral city near you, concentrate on a quick
but dedicated effort to take it. The longer you wait taking a city,
the more difficult it will be to take it, and the more potential
production time will be lost. Do not send an object on a lost cause -
they are very valuable in the beginning. If you intend on taking a
city, make sure it is taken in one combined assault - attacking in
bits and pieces will cost you more time and resources than it will
cost the city to repair itself. You will discover the proper balance
with experience, as with all causes. Make sure that before you
attack, you click on the city in TACTICAL when its age stat is 0 to
know what the tech-levels are for that city (immediately after
scanning it). This way, you will know what kind of objects it can
produce, and the maximum number of guards it can sustain which
determines its damage potential, and maximum hit points.
It is also a good idea to produce guards early on - it is something
that can be easily forgotten until it's too late.
4A. ADDITIONAL PLAYING TIPS
4A.1 EARLY IN THE GAME
Try to take coastal cities so that you can build destroyers or
submarines. This will give you an edge for defense and offense.
Keep in mind that the computer will build these too, so you need
to be ready for them anyway. Concentrate on a strong defense
once you take a city - make one or two photon cannons and build
up the guards (very important). When you take a city, you may
expect things thrown at you continually so you need the defense.
The spreading and quantity of the cities affects the game
considerably. If there are many cities close by, you can expect
a continual (or even continuous) onslaught. To alleviate this,
you may want to ensure the cities are sufficiently spread apart
(base this on fuel range of objects the NP can produce); you can
also change the max. age of an NP city to something a bit lower,
so that they start out less developed (lower tech-levels). Try
making a lot of gun boats and armies - they are hard to hit and
having the quantity will distract the NP and give it more things
to shoot at, prolonging the battle so you may move in or produce
reinforcements; it's surprising how effective a large force of
not-so-powerful objects can be. You may even choose to sacrifice
some hover-scouts, which can make all the difference.
It may sound like you need to produce a lot of objects which will
cost more resources than you have; it really depends on how lucky
your setup is in terms of resource allocation. It is advisable
that you play a couple of games with POOLED RESOURCES first,
which will solve many of your infrastructure problems. Pooled
resources will allow any of your cities to have instantaneous and
unlimited access to all resources in your HQ, so there is no need
to transport resources. This is also VERY convenient for when
you take a new city that isn't self-sufficient (being able to
collect one or more of each and every resource type). It will
otherwise take a long time to establish a proper defense by way
of production, if you first have to ship resources to the city.
If you are not playing pooled resources, you should plan on
shipping the required resources to the city you are about to
take, possibly having them already loaded onto a transport and
waiting outside the battle zone around the city. This brings up
another important point: you really ought to resource-scout the
collection area of a city you are hoping to take. Knowing the
resources it will collect when and if you take it, is vital
information - it may even lead to a decision of not wanting the
city. If you discover it is self-sufficient, you will want to
invest all you can to take it. You may question the tactics of
flying a hover-scout all around an enemy city - the point is to
do it carefully without being spotted or shot at, which may
require fuel and patience, both of which you may find lacking!
Aero-porters loaded with photon cannons are handy - fly near a
city and unload one or two of them just outside the city's attack
range (the guard's AR) and cover them with a couple of aero-
fighters (or even a destroyer if possible). I know it takes time
to produce these, but there's no real hurry to go out and pound
the NP - as long as you can keep up your defenses, you should be
OK. You'll never be able to charge and take all the cities
before the NP can make a Battle Cruiser, so stop trying (if you
are, that is). By the way, make sure you produce at least one
submarine and keep it handy in case of an encounter with a battle
cruiser. The NP isn't smart enough to escort a battle cruiser
with a destroyer or submarine, unless it happens by coincidence,
so you're submarine can pound on it without being spotted until
it decides to go home for repairs. A human player, however, may
not be so careless as to let its battle cruiser sail away without
such protection.
10A. LIST OF PLAYER OBJECT TYPES
(In no particular order)
Army City Settlement
Photon Cannon Gunship Anti-Sat Builder
Mine Layer Settler Unit Battle Cruiser
Aero-Porter Aero-Fighter Hover-Scout
Anti-Sat Defense Detector Placer Laser Tank
Terra-Porter Hydro-Porter Road Constructor
Fuel Depot Stealth Bomber Resource Container
Destroyer Submarine Repair Unit
Rail Constructor Rail Transport Bomb
Gun Boat Hydro-Settler Unit City Devastator
Canal Constructor
20A. COMMENTS BASED ON USER FEEDBACK
1. Global Market
A comment was made that the global market is far too sensitive, in
that one player shouldn't have such a profound impact on the market;
this ultimately allows the player to make a lot of money by just
continually buying and selling the same set of resources. In multi-
human-player mode, there is always an opportunity for another player
to intervene in your exploitation of the market. For example, you may
sell all your grain to drop the price, so you can buy it all and sell
it again; but if your opponent sees that you are saturating the grain
market, he/she might decide to buy some or all of it him/herself and
make money from it as you were going to do (at which point you will
have no more grain to sell to the market to prevent your opponent from
making a lot of money selling it). I admit that in one-player mode,
there is no intervention, and the reality of it falls apart - that is
one reason why it's called a practice game. The NP has some power to
intervene, but the current default settings are such that it only
responds in small quantities, and in a random fashion - the impact of
its response can of course be changed at your discretion (see the game
parameter table). You may want to consider including a selling
commission (which is zero as the default), so that it will cost more
to sell what you have than to buy it (so to speak).
2. Damage Report
It was suggested that the damage report also state where the attack on
your object came from (in terms of a direction), especially in the
event that you haven't scanned the attacker. My argument was that if
you haven't scanned it, you won't expect anything; so if an object
hits you and you haven't been paying attention, you won't know where
it came from. You can observe the type of damage done to you, and
deduce what kind of object fired on you, but I am also assuming that
you can't tell by the damage where it came from. This may not be a
realistic assumption in general, but I also felt that it would give
away too much information otherwise. It is something I will think
about.
3. Acquiring Cities
I was asked to confirm that cities cannot be built - that the only way
to obtain a city is to take one from an enemy. This is certainly
true. During development however, I originally had settler units
(formerly called city constructors) build cities. Moreover, I had
each city pre-specialized (to one tech-type only) and thus could only
build one object at a time. It was decided that cities were not
valuable enough if they could be rebuilt usually faster than the
attacker can recover the forces and time lost destroying the city
(they were destroyed, not taken). It is an interesting concept
however to have one build a city but then is taken over by the enemy,
not destroyed. In any case, I believe the current setup provides a
better power balance. Settlements are built now to collect resources
only, which was perhaps the most motivating reason to build a city
(where resources were found of course).
4. Game with One Player Only
It was suggested that most people will probably never play the game
except in one-player mode, and so the game should be made to provide a
more balanced and interesting game for just one player. I agree in
some respects - I found that it was more interesting playing another
human, as was the primary intent. Although, I admit that after a
while when turns get longer, each player has to wait a fair bit before
it's his/her turn (on average, 15 minutes per round). That is why
when I play my friend, we either read a book or watch TV while we wait
for each other to play. Creating a better balance to play only the
computer will be difficult as the AI will have to be a lot more
sophisticated to provide an interesting game. The current AI is
geared towards a defensive posture, which fits in line with the intro
story (which we wrote last of course!).
5. "Shouldn't hover-scouts be air units?"
By a certain logic, they could be considered aero-tech. However, no
other aero-tech object can detonate a mine, which a hover-scout can
do. Hover-scouts are only lifted a small distance off the ground (a
few metres maybe) and are also considered terra-tech as they are
primarily designed to scan the ground for resources. They can even
conceivably be called hydro-tech, since they can float on water (with
no fuel). One supporting argument for categorizing them as aero-tech
was to fill in a "gap" in the production capability for a tech-level
one aero-tech city, which can only produce bombs. I still stand by my
decision to keep it terra-tech, but everything will work fine if you
change it yourself to aero-tech in the game editor (they will still
detonate mines though!).
6. Scenarios
Some useful comments were made with regard to scenario building and
playing. The idea is to provide some pre-built scenarios that people
can play, where the NP cities are pre-placed and pre-developed; the
production capability is limited to certain lower-tech objects; and
there could be objectives layed out in the beginning. Other scenarios
are provided that get progressively more difficult and more complex.
This will guide a new player through the game concepts at a gradual
pace instead of just diving in and having too much to cope with. In
particular, the game parameter and object specification tables should
be linked to the specific game (or scenario). This is a pretty good
idea, and will be considered if a new version will be developed. In
any case, it is definately a good idea to at least provide the ability
for each individual game to have its own associated game parameter and
object specification tables, so that changing one parameter in one
table will not affect other games in progress (if any). This will
also allow for one to set up different sets of tables and select which
one to use when building a game, allowing levels of difficulty to be
implemented as well.
7. Terrain Types and Modifications to Specs
It was suggested that the current "terrain combat modifications aren't
very dramatic", and the various percentages for spotting and hitting
should be adjusted more significantly for the various surface types.
We haven't put too many testing hours in since surface types were
introduced, and especially haven't had many combat hours given
surfaces such as mountains, swamp, and jungle. The adjustments made
were relative to land, and were purely based on what seemed like a
good idea at the time. This will be considered further. Of course, I
am open to suggestion in terms of specific adjustments.
I am open to any comments or suggestions with respect to the above, or
anything else.
20B. OTHER COMMENTS
Make sure you remind yourself to use the on-line help facility. This
context-sensitive help will describe many details that are not covered
in the manual. Feel free to browse through the .HLP files with a text
reader to get a general idea of their content, but be sure not to
overwrite them! The integrity check may fail otherwise.
If you design your own world map and are proud of it, feel free to
mail it to me along with your name (to give you credit) and I may
include it with the next release (if any). We could use some good
maps considering how few we currently have.
As well, if you have any problems with a current game, just ZIP,
UUENCODE, and mail it to me. These problems may include the need of
advice, something spooky happening that may be a bug, or whatever else
that can't be solved using the game editor. If there is something you
need to change in the game file, I may consider revealing the
appropriate offsets to this data so you can fix it yourself.
If you find, as you are playing, that you are continually short of
resources, you should consider increasing the number of each resource
type for when you build your next game (in the game parameter table);
sorry, there is no way to add resources to the world in your current
game (that is, the program won't do it for you).
You may want to play around with the object specification table, but
be sure to keep a backup of the original. However, you can always
delete the spec file and run the editor to re-create it with default
values if you get into a mess. The probabilities may be changed to
anything you like; other specs may also be changed so long as these
changes satisfy any restrictions that may be indicated in the manual
for the object type in question. I do not recommend that you change
surface compatibility for objects - some certain aspects of objects
that are related to this are hard-coded, so you may want to check with
me first.
20C. FUTURE POSSIBILITIES
If there is enough interest, I may consider adding some more features
to this game (provided I have the time). Some of which may be the
following:
- Make the world wrapping in the east-west sense.
- Add spying/intelligence: able to obtain random information about
the enemy, or promote insurgence; costs MegaCredits to support spies
and counter-intelligence.
- Make the NP more intelligent (or change certain aspects of its
behaviour) - depends on specific reactions from people.
- Add natural disasters.
- Add more object types.
- Add modem/network support
- Link data tables to individual games
- Add difficulty levels
- Add scenarios
- ... or any other suggestions.
99. CONTACT AND DISTRIBUTION INFORMATION
If there are any questions or comments, please address them via e-mail to:
ROBINS@QUCDNTRI.EE.QUEENSU.CA
This account is valid until May or June 1994 (roughly) when it is expected
to expire (and I am expected to graduate!). Please feel free to send me
mail if you wish to be notified of any new releases, or other pertinent
information. If you are registered, you will be notified of my new contact
address when available.
You may acquire this program by anonymous FTP from:
archive.umich.edu (141.211.120.11):/msdos/games/strategy/rex101.zip.
ftp.funet.fi (128.214.248.6):/pub/msdos/games/strategy/rex101.zip.
I will also e-mail it (uuencoded) to anyone who requests it.
Note that the size of REX101.ZIP should be 202429 bytes. If another
version is released, its version number will be included in the filename as
it is now (where 101 -> version 1.01). The next release will most likely
either be version 1.10 or 2.00. Also note that the program will not run if
it fails its own integrity check of all distribution files. It is not fail-
safe, but it provides some security against tampering.
