#### Archived

This topic is now archived and is closed to further replies.

# RTS where Players create custom units

This topic is 5490 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hello, I am working on an RTS where the player can deside what the attributes are for each of the units he creates. This btw has a futuristic setting. the user would be able to for example make 10 units that had very high accuracy while shooting lasers, but had fairly weak armor. The better the attributes for the unit the user wants, the more time/rescources the unit will take. I am having trouble though trying to figure out how I should display the units. If there are theoretically an infinate number of types of units the user could create, how can we have models that represent each one, and at a glance inform the user what kind of specs the unit has. For example, how will the user be able to tell if a unit is a fighter with high payload, and high energy consumption, and low speeds or a fighter with high agility, low payload, low detectivity. I think that the best way to do it might be to have many different base units that the user can derive their custom ones from. This way, they don''t have to custom build each type of unit, many presets are there for them. I would definately make the game so that each time you make a unit there is an option to save the configuration for later use. Any ideas on how to display minute differences in attributes easily? Thanx Tazzel3d ~ Dwiel

##### Share on other sites
That sounds simmilar to and what I'm planning on doing in my RTS - I'll make an external program (or maybe even build it into the game - point is it will be done offline while not playing and saved for later use) where you can select abilities etc for units and make them however you want. I was planning on just having several models the user could choose from as one of the properties (and it would come at 0 cost since models don't make a difference =-)

Let the user pick what they want each to look like. Might be a nice tactic in itself, to make your strong units look really wimpy and your weak units look really strong. Maybe on the loading screen have it show your enemies what abilities you picked for each unit and what model it has to make it a little more fair... or maybe not because a surprise can be nice too =-) If you don't show them on the loading screen though, make some way for the player to find out what units he should be targetting, maybe clicking on an enemy unit shows its abilities, or maybe make one the abilities a 'sense talents' that you cast on an enemy unit to know what it can do.

The only thing holding me back right now is the scripting language - Can't have an RTS with out a scripting language =-P And since its MY RTS, it can't be just ANY scripting language, it has to be the bestest of the best. Which isnt gonna happen =-( But I got several book reccomendations so maybe I'll be able to pull of something at least somewhat complex.

[edited by - Extrarius on January 22, 2003 12:57:50 AM]

##### Share on other sites
Extrarius-
It seems like we have a lot of ideas in common. I''m trying to come up with something so that players can design their own units as well. Like your game, it too will have a program that allows the creation of individual units and logical organizations of those units outside of the game itself. I''m currently thinking of creating a python scripting engine to handle this since I''m trying to learn Python now (which is kinda bad, since I''m not even a true C++ coder yet).

Matter of fact, the thing I''m most concentrating on right now, is the design rules to create the units, a container class that holds the units (and makes a dynamic list of all the units'' abilities), and the Order system (which encapsulates function calls and are passed to the container class to execute unit functions).

I''ve been trying to figure out how to visually represent these elements though. In my game, an icon does not represent one item. More importantly, the container class that holds the units may be heterogenous....in which case how do I represent the units? If you simply say that one tank icon = a tank platoon = 4 tanks....that doesn''t account for mixed units (say combined infantry and tanks in a container). Since I want my battle system to be able to (symbolically) handle about 5,000-10,000 infantry and roughly 400-1000 armored units, it''s simply not reasonable to account for a one-to-one relationship between icons per unit. Instead, I''ll have to focus on icons per container class (especially since the gameplay revolves around the container classes which I call Clusters). This way, you''re handling about 166-300 infantry icons and about 100-250 armored icons (which is alot more than the 100-300 controllable icons I had originally planned on). So, since things are going to have to be abstracted somewhat, I''m not going to worry too much about the specific model for every unit design.

A friend asked me why I wanted to go through all the trouble of having unit design when he knew how much of a stickler I was about historical usage of units and the rigid structure of logical organization of units (the reason you don''t see a bajillion kinds of tanks in any military is several fold: you don''t have to train the crew for a bajillion kinds of systems, you don''t have to create parts for a bajillion kinds of systems, you don''t have train technicians how to repair a bajillion kinds of systems.....well, you get the point now). In my system, while the player is free to design to his hearts content, there is a price to pay for a country to have too many designs. I haven''t worked out the rules yet, but the upshot will be higher maintenance costs, and higher training costs (in my system there are raw resources, refined resources and "people" resources). But to answer my friend, I think the advantage in being able to create unique units is two fold. Firstly, it means your opponent doesn''t really know what he is up against. His intelligence will indicate that he is facing a "medium armor" unit for example, but does he know if it has anti-aircraft capability? Maybe it has a weak gun but excellent armor (think British WWII Mathilda). But the next "medium armor" unit a scout might face might have some weak armor, but excellent speed, and a decent AT gun (think M3 Bradley). In time, Commanders can learn to recognize units, but the player will have to be cautious at first. The second advantage lay in being able to determine how your army fights instead of the game designer himself determining how your army fights.

This last point is very important. In all RTS games to date, the game designers essentially dictate to the player the effective tactics and strategies that the player must use because of the inherent strengths and weaknesses of his units. Not only this, but RTS games don''t really stress the concept of how armies are organized (with a few notable exceptions). But even for the games that do consider logical groupings of units, none allow you how to organize those units into a logical hierarchy (even Kohan which allowed you to put different units into the "company" container class....you couldn''t change the container itself...it always held 4 main units, and 2 support). By allowing the player to design not just the units, but how those units are grouped allows for almost total freedom in the tactical and strategic capabilities of the player.

Think about it....in real life, countries decide not just what their armed forces are composed of (designing the units), but the rank system and the chain of command of those units as well. This is I believe, the most underrated aspect of strategy games (I believe it is perhaps the essence of strategy).

##### Share on other sites
I thought I should make a point about game balance since I'm sure someone will bring it up.

See the trade offs? That's why there's no such thing as the uber-gun no matter how much money you want to throw at it. Yes, you can make lighter weight materials that can withstand more stress, but essentially physics has no loopholes. Since as designers we are creating a closed-end system, we should be able to make a system which also has no loopholes for players to exploit. By designing a system in which every system is reliant on or dependant on another, then you can put in a system of checks and balances.

In fact, I do not think that coming up with a design rules system that is balanced is no more diffucult than coming up with units which just seem cool but are just arbitrarily made up because it fit the designers notion of what that army should have. These systems require playtesting to tweak the balance. With a well thought out design construction system, the design rules themself will be the measure of balance, and playtesting should not be the main method of determining balance (though it's still a good idea to playtest to make sure that all the cogs of the wheel fit, and no one cog is too small, missing or too large to throw the wheel out of whack).

[edited by - dauntless on January 23, 2003 4:35:21 AM]

##### Share on other sites
quote:
Original post by Dauntless
I haven''t worked out the rules yet, but the upshot will be higher maintenance costs, and higher training costs (in my system there are raw resources, refined resources and "people" resources).

Won''t this encourage players to just mass-produce the same unit? Why bother making 3 different tanks with different strengths, if you can just make one supertank and get it relatively cheaper? Or even make one tank at about the same "base cost" as one of those 3, but get it cheaper because you only have one design? meeaning you can build twice as many? Most RTS games are struggling to get players to use several different units (to avoid any specific unit dominating the entire battle), so isn''t this idea going the wrong way? Just because it''s realistic doesn''t neccesarily mean it''ll make a better game.

##### Share on other sites
quote:
Original post by Spoonster
quote:
Original post by Dauntless
I haven't worked out the rules yet, but the upshot will be higher maintenance costs, and higher training costs (in my system there are raw resources, refined resources and "people" resources).

[...]Most RTS games are struggling to get players to use several different units (to avoid any specific unit dominating the entire battle), so isn't this idea going the wrong way? Just because it's realistic doesn't neccesarily mean it'll make a better game.
I agree that mass production of a unit generally makes a game boring. I plan on combatting massing by making the cost of every ability variable, based on how common the ability is. After every game, all the clients will upload statistics on which abilities they chose for their units and which units they built the most of. Then a program on the server can use that data to see if one ability is used too much or not enough and adjust the prices. When a game starts, the new prices would be downloaded and used to calculate unit cost. It might be a little unfair because you can never be sure what your units will cost, but it shouldnt change the prices a whole lot between games.
If I assign a weight to each ability/stat/whatever, I can tell the balance engine expect to see more of X than Y... Damage upgrades will probably be pretty common, since the object is to defeat the enemy by destroying his units and his base, so I would assign them a higher weight. When calculating new prices, the program would do something like dividing usage by weight, so if I want attack upgrades to be twice as common as any single other upgrade, I just use '2' as the weight and its taken care of. If people complain, I explain the system and ask the public to make up the weights and take an average from the replies and use that =-)

[edited by - Extrarius on January 23, 2003 2:17:12 PM]

##### Share on other sites
In response to what Extrarius said, You might want to update the prices as the objects are built for each game. The prices start at the downloaded prices and then changed as you buy more of them. This isn''t very realistic though... Its normally nice to be able to balance gameplay while having logical reasons for things to occur. Why on earth would buying one tank make the next one more expensive?! Good point Spoonster about the problem with making mass amounts of one unit, when normally it is better to descourage this. Still thinking about how to overcome this... Will get back in a bit...

Tazzel3d ~ Dwiel

##### Share on other sites
Actually there is a perfectly logical reason for prices to raise as you buy stuff. Ever notice how when a new cool thing comes out around various hollidays, its price rises as more people buy it? The more people want something, the more people will pay. Suppliers realized this long ago and decided to make popular items more expensive to get more money. Also, if nobody buys stuff for a long time, usually it goes on clearange, gets prices cuts, etc because the store wants to get rid of it to make room for something more popular that will earn more money.

Of course, this is assuming you are buying your units and not manufacturing/training them yourself (which is how my RTS will work).

##### Share on other sites
Spoonster-
This is almost exactly what the Americans did with tank production in WWII. The germans for the most part had superior tank designs, however, they were so zealous about constantly designing new tanks, that they frequently broke down, and spare parts were hard to come by. The Americans on the other hand relied on the Sherman tank as their main battle tank, with M7 Priests, M10 Bulldogs, and some variants of the Shermans as their supporting MBT''s.

So in a way, you''re right....by having one design and then capitalizing on it, in effect, it is cheaper. However, if you only have one design, then you will run into some problems. Like I said in the gun analogy, everything has a trade off. If you make an all-purpose design (like the Sherman), while it is an average performer in all categories, it excels in none. A German Panzer Corp officer once remarked, "the Panzer is worth 8 Shermans...but damnit, there was almost always a 9th one." That''s why the Americans came up with the Priests which had a light main gun, but a large howitzer as well (for infantry support), and the Bulldog had a much larger and more powerful main gun (to help it combat the more well armored Panzers).

If you try to design one unit that does everything, then either it will cost more, or it will only be average in many areas. This is the whole reason why units are created to work synergistically. An aircraft carrier without escorts is a sitting duck. It can not rely 100% on its own air capabilities to defend itself. In WWII, the Japanese and the Americans had a different design concept in design than the British did. The American and Japanese designers had open hanger bays whose only protection was the flight deck itself. The advantage of this scheme lay in the ability to sortie many flights in a small amount of time. The British however felt that this was too vulnerable, and they had "box hangers" which shunted the ventilation away from the hangers and armored the hangers themselves. The results of these design choices were that the British carriers were extremely damage resistant but they couldn''t sortie as many aircraft at once. The Japanese and American carriers could though...but this proved to be a double edged sword for them. On one hand, they could very quickly launch attacks and recover their aircraft, but on the other hand....once the BARCAP was gone, the Aircraft carriers were very vulnerable. In essence, with the Japanese and American designs, the first person to spot the others warships had a HUGE advantage. In many respects, the Americans won Midway by sheer luck (we found them first, we were lucky that we caught one of the carriers while a flight was still on deck with ammo and fuel, and the Japanese made a critical error in assuming all of our carriers were destroyed). The British designs on the other hand weren''t so heavily dependent on any air defense (BARCAP) and could take quite a beating (in the Mediterrenean campiagnin preparation for defending Crete, the Ark Royal took several German radio guided bombs...the first guided bombs in history...to its flight deck...a feat which many say Japanese and American carriers would not have survived).

What is my point? That a unit no matter how powerful will have tradeoffs. The design considerations will prevent this from happening and therefore the smart player will design units that complement each other. The trick however is in not building too many designs (like the Germans did with tank design). General purpose designs are almost never as good as units which specifically excel at them (for example, the Navy introduced the FA-18 hornet....and FA stands for fighter/attack....that is replacing the aging F14 Tomcats, however, the F14 are superior air superiority fighters as they have superior electronics suite and weapon payloads, but they are not as good a dogfighter as the FA-18''s are, but the FA-18 is a decent dogfighter and a decent attack role craft but not as good an attack aircraft as say a Harrier jump jet or Tornado fighters).

##### Share on other sites
I think that the best way to handel some of the problems here is to make all of the attributes of a unit only indirectly alterable by the player. For example, instead of letting the user deside what the HP of an engine for a tank will be will obviously effect the max speed of the tank, but so will the tanks final weight. This way, the user can not directly change any attributes of the unit, so that they can have balances on them. As in the tank example, the bigger the engine, the heavier the tank will weigh, the more fuel it will need to carry. It will also use the fuel very quickly. By letting physics taking care of the balancing, makes it much easier to make a balanced unit everytime.

just some ideas...

Tazzel3d ~ dwiel

##### Share on other sites
I was surprised to see that no one has mentioned the recently released Impossible Creatures. It''s a RTS where you build your own units through combining different creatures. Apparently this part of the game is very well done, you may want to look at that for inspiration.

##### Share on other sites
Tazzel3d-
That''s exactly what I had planned in mind. In my unit creation system, a Unit class is composed of several "module" classes. Every unit module starts with the BaseModule class which essentially just carries the data for the module''s mass, volume, cost and maintenance. All other modules derive from this class. Then you have the specialized modules, like Offense, Defense, Mobility, Engine, Intelligence and Special. If the unit has no attack capability, then if a unit is given an attack order, it will return a null object.

Now, lets say you want to design a gun (Offense module). Since characteristics like DamageClass, Penetration, AccuracyClass, MaxRange, AmmoCap, etc are all private data variables, the player can not manipulate them directly. Instead, the Unit scripting engine will have build functions that design things like the caliber of the ammo, the length of the barrel, the kinetic energy, etc etc. Once you have answered these step by step, the OffenseModule takes its accessor functions and reads the UnitScriptOffense file to set the private member data.

The same thing goes for example for building an engine. The player answers a series of questions...for example, what the maximum weight of the unit will be, the mobility system the unit will use (wheeled, tracked, hover, etc) and what the desired max speed of the unit will be. Obviously, the Mobility module and the Engine module are closely related, but the Move() will be a member function of the Mobility class (i.e. Path MobilityModule::Move(Map Coord))

##### Share on other sites
Dauntless:
My point is that getting people to use more than one unit design is *very* difficult. Look at current RTS games like the C&C series or Warcraft... In pretty much every single one, players soon figured out which unit to massproduce and rush at the enemy...

It''s extremely difficult to balance things enough that building different units actually pays off. Remember that it in itself gives the player more things to keep track off (keep infantry safe behind heavy armor, coordinate different forces, so the air units sweeps in just before your main force, try to take out SAM''s before that, and so on). If any one model is just a tiny bit better compared to its price, no one will ever build anything else. So I''m just wondering if you''ll really add anything to the game by making it cheaper to concentrate on fewer designs. From a gameplay point of view, it seems that you should, if anything, push the other way, trying to force people to use a bigger number of specialized designs.

Anyway, the fact that having more different designs automatically becomes more complex for the player to manage actually simulates the effect you want, so you don''t really need to include it in the game for reality''s sake... It''s already there. (in a diferent form, yes, but it is a game after all... It can''t be real anyway)

##### Share on other sites
Spoonster-
The problem with people wanting to buy the most "cost effective" design is that they don''t take the contex of the situation into consideration.

What if most battles took place out in open fields and a player realized that his Tanks were great buys so he loads up on them. But after a series of rouding victories and the enemy has been pushed back (perhaps to a different continent or planet even), all of a sudden, the terrain changes to lots of forrest and city fighting. Now all those tanks that PlayerA has bought for 100pts a piece are getting eaten alive by pitiful infantry that only cost 20pts a piece (and were getting eaten alive by Player A''s artillery and tanks before).

Or what if a player finds that bombers can take out anything as long as they have fighter escorts protecting them? So the player ramps up his fighter and bomber production until he he has destroyed everything within the fighter escort range. But Player B has decided to balance his forces between airpower and land units. Moreover, Player B develops radar before his opponent does, and now he can detect when his enemy''s forces are, and shoot them down one by one. By putting all of his eggs in one basket, Player A has doomed himself.

Another historical example is Germany''s reliance on submarines for their naval power. In terms of cost efficieny, submarines are amazing vessels, and are probably the most cost efficient warship there is. But if you develop a counter-measure, then you''ve essentially nullified it, and this is precisely what happened with the advent of sonar, and new escort strategies to defeat wolfpack tactics.

The reason why one unit dominance is so commonplace in RTS games is that they do not take into account the context of the situation. The rocks/papers/scissors equation that many games use do not factor in how or where a unit is being used, or how effective its leadership is. Therefore players quickly develop the most potent combos to ensure their victory.

I believe this is easily taken care of by making sure that every unit has built-in strengths and weaknesses across differing contexts.

##### Share on other sites
do you think that giving your units more complex commands and making the game run slower would be a good idea? For example instead of being able to give simple command like "move to position x", a player would be able to give such commands as "move to position x after the planes attack the city" then give another command to a group of units to "if enemy planes are flying, attack them, otherwise attack the city". Do you guys think that these kind of complex commands would enable the player to use more complex stradegies and give him/her better control of his army, or would it make everything to complicated and confuse the player. One problem I need to iron out in this design is the amount of time it would take to give commands to an army that needs to act very quickly where time is crucial. Maybe have predefined commands that the player makes which are placed in the form of icons in the corner for quick use. Not sure exactly how this would work though. Also I would like to make the method of giving commands as basic as possible and limit the audience to people who can think like programmers. Just some thoughts. Also have any of you come up with any ideas of how to display minor differences in attributes of units? Maybe a color coded system that is displayed above each unit.....

Tazzel3d ~ Dwiel

##### Share on other sites
Tazzel3D: That''s an interesting idea, and I think it could be easily done if the game had a scripting language. Allow the player to create simple commands like that and bind it to a key (maybe modifier+function key). Having a pretty-print editor would be good to make the game fair for the non-programmers, where it walks you through the conditional start with something like "Order selected units to _action_ if _condition_" and each __ part has a dropdown. Maybe even allow a single key to be bound to several actions, so you could have your units wait for any 1 of 10 conditions and act acordingly.
Problems occur if you allow players to create custom units, unless you have specific base units like maybe ''bomber plane'', ''fighter plane'' etc because you probably want the guys to react differently to each one.

##### Share on other sites
Time scale in real time games has always been out of whack. In RTS games, if the game map represents the "world", then you can march off your army towards the enemy in the same time it takes to create an entire army. In real life though, think how long it takes to mobilize an army, and then how long it takes to manufacture several thousand units and train tens of thousands of troops.

To put it simply, time scale is very out of whack in most RTS games. That''s why I really liked Total Wars concept of dividing the game into a hybrid turn and real time system. The battles are fought in real time, but the overall strategic planning is done in turns.

But I''ve taken this one step further and made the battles themselves hybrid. Real time happens in intervals...say 5 minutes, and then the game freezes and the player has a chance to order all of his troops. This allows for complex sets of orders to be given. Also, I''m trying to figure out how to implement an AI system that allows for autonomous action, and a Rules of Engagement system that allows for limited conditional logic.

For example, when you select a Commander (my game is controlled through AI commanders and not directly on the units) you issue one of several basic orders, like Attack(), Move(), Form(), Rally(), Resupply() etc etc. Once this is selected from the GUI interface, then you chose modifiers to the basic function...for example on an Attack() order, you might set it to "suppressive", or for Artillery it might be "fire for effect". Now comes the conditional logic part of the GUI interface. From here you can select conditions that affect whether the action occurs, or possibly the function modifiers. Most logic will be like IF statement, THEN statement logic.

For example, you can set, "IF target moves North, THEN hold fire". Or "IF my unit is fired on, THEN retreat to this position". Obviously, this is a lot of parameters, but the GUI interface can walk the player through each step depending on what kind of function will be called in the first IF statement to determine all the arguments.

So if you either slow down the time scale a lot to make it more realistic, or have a RTS version of "bullet time", then I think you can do it this way too. Also, if you have a system in place that can organize large groups of units effectively, it means you will need less time to issue complicated orders.

The disadvantage is that it requires a certain mindset and mentality on the part of the players. Many simply will not like this, but I think that people who appreciate chess will appreciate a system like this.

##### Share on other sites
quote:
Original post by Extrarius
Problems occur if you allow players to create custom units, unless you have specific base units like maybe ''bomber plane'', ''fighter plane'' etc because you probably want the guys to react differently to each one.

very good point, one I haven''t thought about yet... I was thinking of having something like an NN/GA that would look at all of the attributes of a unit and classify it accordingly. This way, you would be able to have unit react differently to different unit types which would work just like a model with base units. This NN/GA would also be used to classify custom units and give the unit a corrisponding 3d model/type name.

Tazzel3d ~ Dwiel

##### Share on other sites
I didn''t read all the posts, so forgive me if this has already been mentioned.

A game called Warzone 2100 or something, allowed players to mix and match pieces of units. IE, half-track drive with a medium tank chassis and a laser turret. The game was in 3D and simply stuck the models together to create the custom vechicle.

As for game balance, if you allow people to basically invent their own units, model the material stresses. IE, if you slap a guy on a horse, the user can only pile so much armor on him before the horse collapses. Your hover units will have x engine power and to much weaponry will result in speed loss and eventually just cause the unit to collapse. You would want to offer techs that would allow the user to upgrade his various pieces of equipment.

##### Share on other sites
Extrarius brings up a point that''s bothered me as well....how do units recognize what other units are? In a way, this is a valid question since if that nation has never seen these vehicles before, he won''t know their capabilties. On the other hand, general information should be possible, like realizing it is a medium class armored unit and that it appears to have a large caliber gun and is tracked.

I don''t want to do something like have base classes that are then derived to form more concrete classes. For example, have class Armor, then further derive it into class LightArmor, MediumArmor, HeavyArmor, AssaultArmor, MobileArtillery, AntiAir, etc etc. While that WOULD solve the base identification problem (each object could see the class derivation type, it''s not how I envision vehicles to be built.

Instead of an inheritance scheme, I''m leaning towards a composition basis of building units. Now, there are still base classes, for example, class Infantry, class Vehicle, class Building, but each class is an aggregate of other classes. Right now, I''m calling the component class objects "modules". A vehicle has for example, an OffenseModule, DefenseModule, HullModule, MobilityModule, EngineModule, IntelligenceModule, and SpecialModule. These modules all inherit from the BaseModule class, which simply have protected members like mass, volume, cost, and maintenance.

Now, since each ModuleClass has private data members, the player does not directly manipulate the Modules characteristics. Instead, there will be a script engine that asks questions for each module. Each Module class will have accessor functions that reads data from the generated script file, and sets the private member data that way.

So you can''t just arbitrarily set a gun''s DamageClass to 10. Instead you have to go through the scripts build process that generates the data file. For example, in gun design, you start by considering how powerful of a weapon you want (it''s DamageClass). From this starting point you then have consider factors like what max range you want it to have, how accurate it is, muzzle velocity, etc. etc. Once these factors are all calculated, the accessor functions from the BaseModule class figure out how much that Module will cost, weigh, the volume it takes up in the HullModule (or the volume of the Hull itself if you are designing the HullModule itself) and any maintenance.

Trust me though that the hardest part is coming up with the design construction rules. If the construction rules don''t have built in checks and balances, then you can wind up with uber units.

##### Share on other sites
I realized I never really explained how players might be able to tell unit characteristics of custom designed units.

In my system, since units are not inherited from archtype classes but are built around a composite module system, somehow when a unit spots another unit, it has to be able to read some of the member data of that unit. I suppose this could be done via a public function that reads off a public DataID member variable.

As a unit watches the capabilities of another unit, somehow it would have to categorize what it sees so that it can attach those capabilities to that module type in the future. Here again I see an advantage of a module system over an inheritance system. If you have an inheritance system, you might have two tanks which are both

class MainBattleTank : protected HeavyArmor

but each one has different guns (each class has a different Attack function capability. When a unit observes both tanks, all it knows is that they are both HeavyArmor units, but should it assume they have the same Attack capabilities? No it shouldn''t. In a module system though, each module gives it''s own DataID type, so that when a unit sees that a Main Battle Tank is armed with a 120mm rifled gun, and a wheeled tank destroyer which it has never seen before has the same gun, it now knows the attack capabilities of the wheeled tank destroyer (it may not however know it''s IntelligenceModule capabilities which cover targeting systems and sensor apparatus).

The suggestion of using NN or GA seems like a good one too if you want to keep more of a mystery for certain DataID tags. The NN/GA brain would then have to learn what the DataID tags truly mean. This could also be a means of identifying threat levels ("Sir, that huge vehicle that just appeared out of the forrest is huge, but the Sensors haven''t revealed any weapons systems that we are familiar with or can detect").

Take everything I say here with a grain of salt though, because I''m definitely not a programmer yet (I know enough to have a feel for what I want to do, but the gap between my theoretical knowledge and practical usage is huge)

##### Share on other sites
Another plus, for me, that an NN/GA has is that you can incorperate AI as something that is upgradable. In short, my game involves taking over a distant planet. The planet is radioactive, but full of materials such as many precious metals and very useful gases in the atmosphere. Because it is very radioactive, humans can not go there. This bieng the case, robots are fighting a war on the planet between nations as to who gets to take the planet''s rescources. Because all robots are powered by AI, you will be able to upgrade it, thus making your fighting machines better at fighting. Upgrading the AI would then also increase the ability to recognize enimy units at a distance and give better descriptions of their specs. That idea, I had not completely thought of until Dauntless mentioned something very similar.

One question for you guys though... What do you think would be the best way to keep players from building a massive ''aircraft carrier with wheels''? I guess the rescources would be incrediblly high, and it would take a while to research and develop engine that would operate such a heavy craft. My thinking is that if you are able to build one of these moving bases, you will have a very large advantage. In real life, what disadvantages would such a craft have? Is the massive consumption of rescources/fuel a big enough disadvantage in your opinion?

just for the record, what would values such as the HP of an engine, the volume of a fuel tank, the max storage cappasity of a battery, the efficiency of a laser, that indirectly effect attributes of the unit such as max speed, max flight time, max energy consumption, max energy output of a laser? just for now, they will be called indirect attributes in my posts...

I think I''m going to design my game so that the user chooses all of the indirect attributes of his unit, and then the NN/GA determines what it should be classified as, all of the units attributes, and such....

I will explain a bit more when I get to school... I have to leave right now

Tazzel3d ~ Dwiel

##### Share on other sites
The major disadvantage of a mobile base is the time it takes to build it. During all that time, it is completely vulnerable to destruction. If you changed the way ''cancel building'' worked so that it takes time to desconstruct a partially constructed building and get the resources back, it becomes a HUGE risk to spend all your resources on a massive mobile base, because if the enemy attacks it you can''t just press cancel to get the resources back. If the enemy attacks and kills the base before completion, you just pretty much lost the war.

About AI: I really don''t think that NN or GA are a good solution for realtime analysis. [technical stuff snipped because I remebered this is the game design forum =-] There are better ways to classify simple stuff. Just use fuzzy logic to classify the parts of something - is the gun long range or just medium; does it have heavy armor, or light armor; etc. You just use simple numeric ranges to classify each part into 1 of 3-4 categories based on its abilities, and then code the AI to act according to the abilities.
If it has heavy armor, there isnt much reason to shoot the weak guns at it. Slow reload? Run up close while its being reloaded. etc

##### Share on other sites
quote:
Original post by Tazzel3D
One question for you guys though... What do you think would be the best way to keep players from building a massive ''aircraft carrier with wheels''? I guess the rescources would be incrediblly high, and it would take a while to research and develop engine that would operate such a heavy craft. My thinking is that if you are able to build one of these moving bases, you will have a very large advantage. In real life, what disadvantages would such a craft have? Is the massive consumption of rescources/fuel a big enough disadvantage in your opinion?

No, I don''t think it is. Increasing the cost of a unit because it is too powerful is an inadequate method of balancing in my opinion: it''s like a quick fix for a system which is already broken.

You can apply the role based design principle to individual components, rather than units. Each chassis, weapon and device could be designed with a particular purpose in mind. Whenever there is an increase in power, there is a decrease in flexibility. Finally, you limit the number of hardpoints the player has to play with - so he can''t just equip it with one each of all the most extreme, specialized weapons in the game.

##### Share on other sites
Making something cost enourmous amounts of resources (including time) to create helps ballance it out a lot, assuming that if player 1 spends X resources on a varied army and player 2 builds 1 unit with all X resources either can still win. Making a superbase cost as much as several of every other kind of unit makes it less practical to build because while your building a single huge unit the enemy is assembling an army. Since their units take less time to build, they have tim to make a large offensive force and a large defensive force before you finish. If you find out you are making a superbase and attack when you are only half way done, the base is dead and there is nothing you can do about it.
If you build a few troops first and then try to build the base, the enemy will be building many smaller units while you save resources, and then many more small units while you build the base. They would be able to overwhelm your small army easily, and assuming each player plays as well, the person with the huge army could take out the one building the superbase.