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)

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

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

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.

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.

I agree with Sandman. There is more to balancing units than the cost of a unit. There are inherent limitations to every design, and simply thworing more money at it won''t work. That''s why trying to find that "checks and balances system" in your rules design is so critical.

Now, let''s suppose that you DID create a land carrier (a concept which seems to be popular in many Japanese manga and anime series and I''m presuming you''ve probably taken a yearning too.....Big War perchance or Heavy Gear?). Where would you use such a thing? In the Heavy Gear universe since the planet had vast deserts, these magnetic lev carriers "sailed" on the magnetic "waves" of the planet. Makes partial sense since a desert landscape is fairly similiar to a sea. But imagine how perfectly flat that land must be. If you have any hills or depressions, either you have to develop a way for the track or wheeled system to compensate for this, or the ship has to be able to "plow" through the non-level landscape. Imagine those ridiculous SUV limos trying to go cross country, and it meets some land that has an incline angle that is steeper than its wheelbase can allow. That''s exactly what a land carrier will have to face. If you design it so that the tires or tracks run high enough to clear say, a 10 degree incline over a 500'' span, then you have the problem of exposing the underbelly to attacks and requiring more armor for that position. You have the same problem if you design a ground effect mobility system since the air skirt and the lift fans will be very vulnerable to damage (and for that matter, the wheels and tracks to a land carrier will be very vulnerable as well).

So there''s your number one disadvantage right there. The terrain in which it can fight in is incredibly limited and any form of mobility system it has (unless your technology is so advanced that it has anti-grav capabilities) is very vulnerable to attack.

These are the kinds of things you have to think about. As Sandman said, don''t think of the entire unit itself as a whole, but think of the seperate components that make up the unit. In my module system, each module essentially provides the functionality for that unit (what it can do), and holds the data necessary to do those jobs. I had a hard time when I was thinking of an inheritance based unit design system of trying to figure out how to handle unit creation design. I also found it hard to come up with something that ALL units had. That''s when I started looking at the problem from a composition point instead of inheritance, and to me, it fit the problem domain better than a pure inheritance based system (though there is still a lot of class derivation in my system now, it''s just not the main method of determining new unit types).

I suggest buying some older paper and pen wargames like Car Wars, BattleTech, Dirtside 2 (I can''t recommend this game enough), and Heavy Gear to get an idea on how to do construction rules. Matter of fact, I also recommend the Champions Hero system for its design rules. While it concentrates on RPG gaming, you can make vehicles, buildings, even powers themselves. Other than Heavy Gear, all of these games have been around for more than 10 years (and are still popular today), and significant playtesting and balancing have already been done.

I agree that cost is not everything, but it IS a big deal. It takes time to get resources and time to use them, so they can help balance easily and with great effect. Just look at all the games out there that have balanced units - cost is the most widely and most often varied variable =-)

I like the point that large vehicles can not travel over rough terrain, but I was thinking of maybe having the craft either a crush the rocks from the brute force, or having small lasers in front of the ship so that it could flatten the ground infront of it to make travel easier. This obviously isn''t a method that would allow it to climb steep grades, but would alow it to overcome say large boulders in the way. A very large disadvantage that all of the small lasers have is: the heat they generate, the energy they consume, and their importance to mention a few. Any unit that is so dependant on one thing has a disadvantage that if the enimy takes out the lasers, you might as well forget about moving the thing. Just some ideas. I was hoping to not have to deal with determining where damage on a unit is because of the complexity it adds, but I guess that it also adds a lot to the gameplay and the reality of the game. I guess for a craft that massive, any propultion system will be a major weekness. As well as its fuel consumption, cost, manufacture time ect. Thanx for the thought provocing ideas Dauntles!

Also I never actually have seen one of these large land carriers in movies or anything, I just thought, "What would I do if I was a gamer trying to take advantage of this current game system?" and came up with, "I''d build a massive monster unit that would be able to witstand any attack, maybe have its own droids for repairing, basically every bell and whistle available.

Oh and I do like the idea that Extrarius had where cancel time is not instantaneous and so there is a large concern about having the unit destroyed before it''s finished being built.

Also, as much as I love making GAs and NNs, I think that Extrarius is right that using an FSM is better for unit classification than an NN or GA. Actually It''s perfect for the job... about as perfect as they get... *sigh*

I could also have say 15 different FSMs. Each one representing a different AI. As you research more about AI, you get the better FSM... The first one might only be able to tell basic information. The best one might be able to tell you things like: "another 5km and it looks like that tank will be in range to use its nukes..." maybe not that detailed but you know what I mean.

very good posts guys! What other kinds of things are you implementing in your RTS? just curious. Seems like if we''re all working on the same type of game, we might as well share other kind of info too... or not.. w/e

Tazzel3d ~ Dwiel

While this might be different from what you had in mind, has anyone played Earth 2150? You get to design your units to an extent. It was pretty cool to see your own designs dominate the battlefield.

I definitely don''t like the real time approach to building units since the time scale is all wrong. It doesn''t make sense that you can immediately order new unit objects depending on whether or not you did or didn''t do well in a battle. What Extrarius mentioned is true too in that it''s not right to be able to immediately cancel unit production even if you penalize the player by making him lose any resources.

If anything, resources aren''t lost, as the partially completed project can be mothballed, but the units have to be taken off the assembly line and the factories may have to be retooled or workforce re-allocated. So the real disadvantage would be a time factor.

As for the land carrier, if your planet''s terrain could suit such a vehicle then I suppose you could make something like that. But again, terrain will be its limiting factor. If the other side can hide in rough terrain, then by putting all your eggs in one basket, you won''t be able to do as much. These are the kinds of tradeoffs I mean. And while cost isn''t everything, like Extrarius said, it is important. It just shouldn''t be used as Sandman said to counter an ill-balanced design. While you have spent huge sums of money on resources, which was a good investment if your opponent fights on the terrain you wish to defend, if your opponent is in terrain the land carrier can''t go, it will only have its internal troop capacity to fight with (the intrinsic limitation of a unit as opposed to a cost limitation)