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.

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))

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)

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.

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

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.

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.

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

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.

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.