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.