quote:
Original quote by Tom
So now I want to develop a simpler research system. Rather than use fields of technology (energy, propulsion, etc.), let's use elements of the game itself: chasses, engines, weapons, defenses, buildings, mass transit, resource collection and storage. . . the player is left to decide what's most important to the success of his empire.

This is how I implement "new tech" in my game. In essence, you aren't researching fields of science as you say, but rather are utilizing the functionality exposed in your modules. Having Tech Levels also helps give a sense of furthering your technical prowess by making modules more efficient.

Efficiency, however, can be tackled in several ways. Is the module lighter? Does it take up less space? Does it cost less? Is it quicker to manufacture? This will go a long way towards letting players tweak the technology to suit their play styles.

There was something I forgot to mention when I talked about Champions. The neat thing about Champions was that its powers didn't describe how it worked, just what it did. For example, you could have a power called "Ranged Attack" that in game terms determined the damage of the attack and its max range. But it didn't say how this attack actually did damage. It could have been a bullet, or a flamethrower, or a missle, or an energy blast (in Champions, there were three kinds of attacks, Physical, Energy and Mental...as well as characteristic drains). So let's say you wanted to create a flamethrower...well, it has some advantages and disadvantages for being a flamethrower. A disadvantage was its very short range, but it also had an area effect (it spread out like a cone). Also, the damage was persistent and Champions had an advantage that meant once a power "thit" its target, it continued to have its effect on that target for a certain number of rounds. So in essence, by having fundamental building blocks of powers coupled with defining advantages and limitations, you could conceivably create just about anything you could think of.

The only thing about Champions power systems was that all powers, advantages, and limitations were built on a point system which is based off the effectiveness of that power, advantage or limitation. In other words, the greater the game effect, the more costly the power. For example, a simple ranged attack cost 5pts per 1d6 damage, however, a killing attack (which bypasses non-hardened defenses) cost 15pts for 1d6 damage. Normally, this works out fine, except that it introduces a lot of ambiguity in balancing terms, since balance is determined by what the game designers sees as more or less powerful. The trouble is that effectiveness of things is very dependent on how that thing is used...its context. What maybe very weak out in the open may be incredibly powerful in confined or diffuclt terrain. The game designers even mentioned that it's very possible to "minimax" the rules system to create unbalanced characters, and that the GM had to keep a careful eye on things. In a PPRPG, this is quite normal and not a concern, but in a multiplayer game with no referee on hand to "judge" designs, it's necessary to build a closed design system that isn't as arbitrary as that.

I've explained before that the "worth" of a unit should remain seperate from the "cost" of a unit. Indeed, I think the only quantifible measure of a unit should be it's cost, but that its cost should in turn be modified by the diffuculty in producing the unit. In other words, boombers in a game might be "worth" a lot because of their range and damage they can do...but they also tend to be very expensive to make and mass-produce. They are NOT costly because they are "worth" alot. Conversely, an infantry man armed with a TOWII launcher can take out a tank that actually cost about 50 times what it took to equip and train the soldier. This makes him very effective, but his cost is still low. I think many game designs try to associate worth and cost, and just arbitrarily come up with the cost of a system based on its worth. The trouble is as I mentioned, the worthiness of a unit is highly dependent on how it is used. Sure, maybe that TOWII infantryman is cheap as hell, but he needs a ride anywhere he goes unless he wants to move slow, and he's mincemeat if there's an artillery barrage or if his position is coming under a lot of small arms fire...all things the tank can shrug off without worrying. Trying to link cost and worth is a huge mistake in many game designs.

It would be nice to have a research capability that included new functionality, but the balancing issues would be horrendous. If you can figure out a way to create permutations of research design to synthesize something new, that would be really cool, but it could also imbalance the game to a great degree.

[edited by - dauntless on April 2, 2003 2:33:32 PM]

Well, the problem is that you can't really balance the system until you see it in action, so I'm going to be making educated guesses at how much everything should cost until the game is ready for play-testing (which won't be for at least a few months). Then I can begin to analyze the strengths and weaknesses of various technologies based on how they are used.

I do have another idea regarding research. Hide the cost for each discovery. Notify the player only when breakthroughs are made. The most obvious breakthrough is when a new product is fabricated, but you can have milestones in between products that let the player know basically what's going on in his labs. For example, his scientists can notify him that they've made "tremendous breakthroughs in nuclear fission," and that a fission power source may soon be available.

What you do is you make these breakthroughs part of your research chain, and then you link a bunch of technology to them, so that when the breakthrough is made, you effectively unlock a bunch of other items that can be researched individually. Example: breakthroughs in energy could yield laser technology, which in turn unlocks several products (CD-ROM, advanced security, bar code scanners, laser cutters, laser surgery, laser-guidance systems, laser sights, laser communications, perhaps even laser weapons).

So, in essence, these conceptual breakthroughs don't provide any immediate advantages, but they give the player a good idea of what's to come. If you keep the rest of your research tree hidden (until some asshole prints it online), then the act of research becomes exactly what it should be: a trek into the unknown. As a side note, I think it would be best to conceal breakthroughs that cannot be made due to a lack of knowledge in related fields; for example, quantum computers. You can notify the player that "research in this field has reached a standstill," which is the player's cue to spread his money elsewhere for a while.

[edited by - Tom on April 3, 2003 3:26:39 AM]

One thing that would make it nice is to have the primary class, then allow the player to make standard upgrades, or refits.

This way you end up with the following:

Alpha class, the basic Alpha class ship.

Alpha-A class, an upgrade to Alpha class, replacing weapons and fire control systems.
Alpha-B class, another upgrade, inclusive of the Alpha-A upgrades, but also upgrading the defensive electronic systems and adding a cloaking device.

This way you can simply tell a group of ships to go back to base and upgrade to whichever version you want, then it has a basic blueprint to work off of when it goes to upgrade and you know what a ship is automatically, without having to go "did I upgrade this one?".

Some other things you can possibly do is have bases that can only handle upgrades of certain size ships. Maybe one size class larger than they can manufacture. You could also build upgrade bases that just upgrade ships and can''t actually build ships. You don''t have to be able to lay down a keel to be able to rip out that bank of 8-inch guns and replace them with 12-inch guns, do you? The only thing that is likely to not be upgradable on a chassis is actual armor. Usually the armor IS the chassis, so the only way to replace the armor is to replace the chassis.

BTW, very nice to hear someone actually like my ideas enough to use them.

Matt

About upgrades and refits, while technically they should be possible to do almost anything, there comes a point of diminishing return on your investment. For example, the engine on the M113 "Gavin" chassis has been upgraded several times in its lifetime, and the M1 Abrahms has also seen some substantial upgrades as well (reportedly using Depleted Uranium inserts on some of its armor as well as upgrading the original gun from a 105mm to an almost NATO standard of 120mm [the brits use a 120mm gun on their Challenger2 tanks, but it''s rifled, almost all other NATO nations use a 120mm smoothbore]). But the important part here is that there are two ways of upgrading units.

One is to simply make all further new units have the upgraded items. The second form of upgrading is to retrofit the new items onto currently existing units....and this is where you get into diminishing returns problems. Normally, you have to take these units off the frontline and into some kind of factory to do the upgrades. That alone is going to entail its own set of problems. Then you have to remove the old item as well as install the new one....taking perhaps almost as much time as just going ahead and building a new one. There''s also the factor of utilizing your mechanics and factory resources for these upgrades when you could have been building new units.

So in essence, I think all these things tend to factor themselves out, so I''m not against unlimited upgrades. But you also have to consider how exactly upgrades work. Each module in my game has member variables that include mass, volume, cost and maintenance (which it inherits from the BaseModule class). That means that if I upgrade a unit to a new module that weighs more....my chassis had better be able to support that added weight otherwise, you have to chuck something out, or lighten the load somehow. So again, depending on how you do upgrades, I see no point in artificially limiting upgrades. The only drawbacks to upgrading are what I mentioned above....which are more logistical concerns than actual structural concerns

quote: Original post by Tom
Well, the problem is that you can't really balance the system until you see it in action, so I'm going to be making educated guesses at how much everything should cost until the game is ready for play-testing (which won't be for at least a few months). Then I can begin to analyze the strengths and weaknesses of various technologies based on how they are used.

My own personal guideline to cost is based on how complex the unit is. Some technologies are simply more complex and therefore cost more (fusion power plants as opposed to ICE engines, or particle accelerators versus chemically propelled kinetic kill guns). Usually (but not always) the more costly something is, the more effective it is in game terms. I try to seperate as much I can the notion of complexity to manufacture (and therefore how much it costs) from how effective something is. Again, look at the simple infantryman carried anti-tank weapons which cost maybe a thousand dollars, and yet can take out a tank costing a few million with a well placed shot. Also, something which is complex at first may become easier and cheaper to manufacture overtime, once the infrastructure and mass-production facilities are built up. Indeed, there may come a time when a more complex product is cheaper to build than a less technologically advanced device simply due to industrial matters (think about home CD players versus phonographs, or electronic typewriters vs. manual type writers).

quote:
I do have another idea regarding research. Hide the cost for each discovery. Notify the player only when breakthroughs are made. The most obvious breakthrough is when a new product is fabricated, but you can have milestones in between products that let the player know basically what's going on in his labs. For example, his scientists can notify him that they've made "tremendous breakthroughs in nuclear fission," and that a fission power source may soon be available.

This could be a good idea as it would keep the end-result of your research hidden from the player. I'm not sure how you would hide the cost though....do you mean have the researchers cough up a bill after so much time to represent the cost of doing research?

quote:
So, in essence, these conceptual breakthroughs don't provide any immediate advantages, but they give the player a good idea of what's to come. If you keep the rest of your research tree hidden (until some asshole prints it online), then the act of research becomes exactly what it should be: a trek into the unknown. As a side note, I think it would be best to conceal breakthroughs that cannot be made due to a lack of knowledge in related fields; for example, quantum computers. You can notify the player that "research in this field has reached a standstill," which is the player's cue to spread his money elsewhere for a while.

This is a good idea too, but unfortunately someone somewhere is going to put up the tech tree on the web and players will know what areas to concentrate on. But it's good to have technology items require prerequisite breakthroughs which aren't known by the player. For example, guided missles need both rocket technology as well as electronics, but the electronics component alone is not enough, perhaps it needs a communications prerequisite as well.



[edited by - dauntless on April 3, 2003 5:51:13 PM]

quote: Original post by solinear
One thing that would make it nice is to have the primary class, then allow the player to make standard upgrades, or refits.

This way you end up with the following:

Alpha class, the basic Alpha class ship.

Alpha-A class, an upgrade to Alpha class, replacing weapons and fire control systems.
Alpha-B class, another upgrade, inclusive of the Alpha-A upgrades, but also upgrading the defensive electronic systems and adding a cloaking device.

This sounds like an inheritance (IS-A or IS-LIKE A) solution towards the problem, and I thought of doing it that way originally too, but the more I thought about it, the more I realized that having pre-designed classes are more limiting than having a composition (HAS-A) system for upgrading or designing new units. The trouble is inherently that if a player wants to design something altogether new, then either you have to downloads a new DLL with that new class in it, or recompile/patch the program.

I think it''s easier to use the composition method wherein you think of each unit as a sum of its parts rather than as classifications. For example, what''s the difference between a tank and an armored car? If you go the class route, you can have a base class like class vehicle, which has things like a virtual move() function, and has data members like an enum for an enginetype, a rating for StructuralIntegrity, and crew count. Then you think...what''s different about a tank? So you add something like an attack() method, you override the move() method to account for it''s tracked characteristics, and you give it an armor rating as well. But what if you want to design a tank that has wheels? And what about armored cars...they have armor too. You could do multiple inheritance, but then that gets ugly real quickly.

Instead, I think a combination approach is easier. I think it''s easier to think of what a vehicle can have, and then those components add to the functionality of the vehicle. For example, let''s say you want to create a towed artillery piece. Technically it doesn''t move at all, but your class vehicle has a move() function. You could make the move function call upon another attribute (say enginetype) and since it has no engine, it can''t move...but this is rather a kludge and an unelegant solution. Instead, simply create a null class so that the artillery has no engine to represent that it has no engine.

In the composition method, every module is another class which is an aggregate of the vehicle instance. It''s like building a car. You can either have a base class car, and then further subclass it into things like, race car, sedan, station wagon, economy, etc, or you can look at the individual components (engines, suspension, chassis, handling, cargo, and give your desired instances the attributes they need....i.e. race cars with good engines and handling, station wagons with longer chassis and cargo, etc). By having modules which the player can alter, you can make a script system that creates an instance of the vehicle class with pointers to the modules that you create.

quote:
This way you can simply tell a group of ships to go back to base and upgrade to whichever version you want, then it has a basic blueprint to work off of when it goes to upgrade and you know what a ship is automatically, without having to go "did I upgrade this one?".

A type identifier for each class of vehicles you create is a good idea not just for the reason you mention above, but because when the player is allowed to build vehicles he chooses, the first time the enemy encounters it, he won''t know what it is capable of. He therefore creates designation class (which will be the same class identifier type that you create) to mark off its observed capabilities.

quote:
Some other things you can possibly do is have bases that can only handle upgrades of certain size ships. Maybe one size class larger than they can manufacture. You could also build upgrade bases that just upgrade ships and can''t actually build ships. You don''t have to be able to lay down a keel to be able to rip out that bank of 8-inch guns and replace them with 12-inch guns, do you? The only thing that is likely to not be upgradable on a chassis is actual armor. Usually the armor IS the chassis, so the only way to replace the armor is to replace the chassis.

In my own game design, I''ve hardly touched the concept of what I refer to as the "War Machine" simply because I think it''s going to be one of the harder aspects in my game. But what you said is true, certain types of vessels can only be produced or repaired at certain facilities. Even today, some larger warships (aircraft carriers and battleships) can only be repaired at ports with deep enough harbors and the facilities to repair them (drydocks large enough to accomodate them). However, I also don''t want the player in my game to have to worry about the willy nilly details of running and building a country along with fighting.

That being said, the player in my game does not have direct control over the factories and output of war materials. Instead, he makes requests, to which the best effort is given to supply those needs. The first priority is always to replenish battle losses, and then to build new groups (and since my game is strategic and not tactical, you never build just one of something...instead you either replace battle losses, or you create holistic groups which are self-contained). It''s also possible that you might be given more than you requested, but your side would have to be very well off for this to happen.

However, I know a little of Tom''s design, and I think in his case, an idea like this might be a good idea. Distinguishing the kind of factory made to create items should be important.

You''ve got some good points Dauntless.

It''s really about balancing the cost, time and benefit.

With the M1, they didn''t actually replace the barrels on most of them, since the electronics and so much else was going to be upgraded also. The original M1s went to 2nd line units or reserve units while the M1a1s went to front line units. A similar situation happened with the M1a2s, where the M1a1s went to the units that had M1s and the M1s went to units that were basically further down the line.

Why? Because the old M1s were still more powerful than anything that anyone else had, with a few exceptions, they are still very useful. They can beat the snot out of anything that a non-western European nation or Canada has, hands down. The upgrade from a 105 to a 120mm gun was significant, but not enough to make the old M1s obsolete by any stretch of the imagination.

This is something that people who make games really don''t understand. Unit integrity. A unit is whatever I happen to send to an area in a strategy game, there is no benefit for keeping units together, regardless of the fact that they will work better. There is no compensation for being willing to increase the upkeep cost to reflect training costs (low costs = low training, low quality units, higher costs = highly trained, high quality units).

I think that people who make these so-called strategy games really have no real understanding on what it takes to create a high quality, professional fighting force. This is applicable in any time, whether 2000 AD, 500 BC, or 4000 AD. I think that this is much more important than wondering how you''re gonna upgrade your missile launchers. If you don''t have a high quality, professional fighting force, those missile launchers won''t matter.

It''s more than that though. As with many other things, you have to keep your societal education high or, much like the Mexican vehicle factories that were highly automated, they will shut down after a year. No matter how much money GM throws at the robots, the Mexican populace didn''t have sufficient education to understand the basic operation and upkeep of the robotic systems to keep them running and after a year a factory that cost tens or even hundreds of millions of dollars to build would be shut down and the slack taken up by a factory that was in a more highly educated area.

So what do you end up needing? Highly educated populace (which would help with the research all around), highly trained military and units that have long-term cohesion in order to build esprit de corps. Without those, it doesn''t matter if you have an old Spitfire or a Stealth Fighter, you can''t win.

Or to make a long story short, while the equipment considerations are very important, there are several pieces to any equation. Commonly you can only get a few of those pieces, whether it be high training, education, unit cohesion, technology or one of the other pieces involved (of which I can''t think of now). It''s balancing what you can get and figuring out what is most important. It''s only the true empires that can get all of the pieces together at once (the modern western world, or the Roman Empire for example) and even then it will have weaknesses.

Solinear-
You point out some interesting thoughts I had about a national resource that is seldomly looked at....its "people" resource. Not only does a country have a finite population over a short time span, it also has a certain "skill pool". Some countries may have vast human resources, but comparitively speaking, a low percentage of people who have high education or vocational/technical training (think India or China). While China and India at the very top has some very educated and intelligent people, these will be reserved for top level duties...like research, government and business. So the common military man will be stuck at the lower end of things.

In my game, there is a people resource as well as refined and raw resources. The people resource is broken down into quantity, as well as "skilled" resources, which represent your country''s ability to churn out technical or higher education people. I define technical as skilled trades (including military roles for more demanding tasks like armor crews, pilots, artillery crews, etc). While it''s very abstract and could be refined more...I think it does the topic more justice than not covering it at all. I suppose I could flesh out this resource by further defining the "educational infrastructure" (which could help Tom''s research design btw). Afterall, money alone can''t train your armed forces, you need to have the infrastructure in place to properly train and motivate your armed forces (look at some middle east nations which are actually wealthy and yet do not have the required infrastructure to capitalize on educating the people, or conversely countries like Malaysia which aren''t exactly well off, and yet have extremely high levels of higher education as well as good broad general education for all).

I think American armed forces have tried to stay close to our English forebears when it came to the quality of its armed forces. England was never known for having very large armed forces (the exception being in modern times being the Royal Navy) and yet it consistently was able to give as good as it got even against larger forces. In Napoleonic times, the English soldiers were the only soldiers who were trained to sight down the rifle when they fired....all other nations main line infantry simply raised their gun, pointed at the enemy and fired (better units of course were taught to sight down the rifle...Grenadiers, Guard units, some Fusiliers and rifle regiments were usually taught this skill). And like their English forebears, the effectiveness of American forces belies their relatively small numbers in quantity. Some may say it is our technology which makes the American War machine so powerful, while this is undoubtedly true, I large part of it is also the training and "esprit de corps" of its armed forces.

You''re right that most game designers (I think) have no concept of organized and combined arms warfare. They simply make click-fest solutions to represent war...and not just the battles. Concepts like building new units is what I''ve termed "pizza delviery" system by letting players simply call up the factory and order as many units as he has money for. irregardless of units are designed to interoperate with each other. That''s what most games simply don''t include...the ability to maximize the effectiveness of units by logically organizing them to minimize weaknesses, and capitalize on strengths.

I was just reminded of a TV show I watched a few years back comparing the educational systems of Germany, Japan and the United States. From what I remember of the show (it was on PBS IIRC) it basically stated that the US had the advantage in post-grad college level education, where we continue to have probably the best higher education in the world. However, where the US was failing, and in some cases failing critically was at the lower education levels...and not just grade school or high school, but in terms of vocational or technical schools. This it said was where Germany was in much better hands. The Germans apparently have a system in place where if you can''t or don''t want to go to college, they have an excellent infrastructure of vo-tech schools to go to.

Some may say, "well, college is better than vo-tech", but not really. Think about it, Engineers may design machinery, and they may very well be able to operate it...but you don''t want to use your engineers to operate equipment. That''s where the vo-tech trained people come in. They said America may find itself in a position where you have loads of bright people developing things, and no one to operate them. My mother talks about nursing as an example. In her time, many girls went into 2 or 4 year nursing programs, but later, girls realized there was nothing holding them back from being a doctor except society''s notions of what women could be. So as a consequence, you have a billion doctors, and very few nurses (btw, if you''re thinking of being a doctor just for money, do nursing....average salary for a starting nurse is about 60grand now, and my mom who doesn''t even have a 4yr degree is making very close to a 6figure salary now....admittedly after almost 40 years of being a nurse). The projected shortage of nurses is estimated to be 1 million by 2008, and it''s going to cause a serious healthcare problem simply because we don''t have enough people who can train nurses, and people who want to be nurses.

So the educational infrastructure of a nation is one that should not be overlooked even though it superficially appears to have little to do with the fighting effectiveness of a country''s military mights. You have to have people trained not just in the military, but all the support guys back on the homefront who build the equipment, repair it and design it. As a more solid example of this....Germany and Japan could not afford to lose fighter pilots not because they couldn''t build airplanes, but because they didn''t have the facilities and instructors to train new pilots.

Skill pool. . . that is a fairly accurate term. Something I haven't thought about until now is allocating personnel to educational facilities. This is ironic because I had decided to do this for construction facilities; I don't know why I didn't make the connection. A school can't teach without teachers, after all. In Dauntless's project, this idea is irrelevant because the player doesn't control education, but in my project it makes a great deal of sense.

Dauntless: I have indeed chosen to distinguish the construction capacity of factories. I've made quite a lot of development in the past 24 hours, so it could take a while to get it all out. The first and most important is that I've decided how research is going to work.

First, a note to Dauntless who will know what I'm talking about: I've added Metal to my list of resources. It's stored and used in exactly the same way as bricks.

I have four fields, adopted directly from Alpha Centauri , and they are: Expansion (Explore), Technology (Discover), Infrastructure (Build), and Military (Conquer). For the time being, I've opted to ignore out-of-field inflation costs for specialization, so players can enjoy free exploration of any field without having to pay through their nostrils. The amount of research you can complete is based on how many labs and scientists you put to work.

I'm going to do upgrades in one of two ways: either you choose what you want to upgrade, or the game chooses for you by weighing whatever technology you've been using most. In the former case, each of the four fields would be divided into sub-fields, such as Mobility, Scanners, Roads, Armor. In the latter case, whatever you've been building most is what your scientists concentrate on as a matter of implied necessity. In game terms, research points would be allocated to that sub-field first, and then leftover points would go into other sub-fields in the same category.

Before I go on, I should note that each lab receives and employs funds on an individual basis, so you can have each lab work on a different field if you want. You can also invoke macros that automatically direct research (e.g., "50 percent of labs research Expansion, the other 50 percent do Infrastructure"). I haven't decided whether or not a lab can research more than one field at a time, but for simplicity's sake, it would be best to stick with one field.

It's also worth noting that I do not distinguish between types of scientists. Professor X can research any field with equal efficacy, and so can Professors Y and Z. Other designers may want to take the next step and specialize their researchers.

solinear: I use that strategy all the time in games in which unit upgrades are individualized: I keep obsolete units in service until I can afford to replace them with better ones. In Stars! , I'll have age-old destroyers orbiting my worlds for a hundred years before I finally get around to scrapping the fleet and removing that design from my database. It's much more cost-effective to employ units until the duct tape stops holding them together. Commercial airlines have been using the same planes for over 40 years, with virtually no upgrades. There just isn't a reason. The technology hasn't really advanced, and since airliners cost on the order of a hundred-million dollars, it's much cheaper to keep fixing up the old ones.

Of course, airliners are also built to last. Another thing to consider is how durable your technology is. Indeed, we've already discussed this to a lesser degree. Prototypical units will have some flaws -- they always do -- and therefore might be in need of constant repair. (I'm sure we all remember the Apache helicopter during Desert Storm. It couldn't fly more than 14 hours without malfunctioning.) That would be the drawback to using "superior" technology, until you've had a chance to perfect and miniaturize it. I'm not planning to do this myself because it would detract from my game, but Dauntless could probably use this to great effect.

Another note to Dauntless: I'm glad you mentioned weight limits on your chasses. For the longest time I couldn't figure out how to employ component constraints on my chasses, when the answer was so obvious: weight. Thanks a million for bringing that up. Now I have a self-limiting factor for vehicles.

Another note to solinear: MechCommander is the only game I've seen in which pilot experience was integral to success. The sequel is no different, and indeed they improved pilots by allowing you to choose "specialties" for them each time they went up in rank. This is a very cool system, something I think every game with individualized units (hint hint Dauntless) should employ. I know mine will.

Edit: This just occurred to me: upgrading an item that hasn't been in service should be extremely difficult. Let's say you build a chassis; we'll call it Light Rover. You want to make an enhanced version called Light Rover II, but all you have in service are Medium Rovers. There's nothing preventing you from upgrading a unit that doesn't technically exist (except in a controlled laboratory), but it should take a ridiculously long time. Acquiring actual field experience immediately unveils the problems a piece of equipment has (look at seismology scanning equipment -- it isn't worth crap in the field) and makes room for upgrades. Without that experience, it's difficult (if not impossible) to locate problems.

This makes upgrades even more important. As you discover problems with your units, you can immediately notify your labs, and they can look at the problem and patch it up. (This may require that you send the malfunctioning unit back to the lab for analysis.) Either way, my suggestion is that upgrades should occur faster if you're actually using them as they come. This encourages players to spend resources on prototyping their units. It pays off almost immediately.

[edited by - Tom on April 4, 2003 8:26:24 AM]