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

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]

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

I thought I should make a point about game balance since I'm sure someone will bring it up.

If the design rules are done well, then game balance should not be an issue. How does one design rules well? In another post about this same topic I suggested looking at how guns are made to give an idea. To really simplify things, guns are about ballistics. If you want your bullet to do a lot of damage, you have to impart a lot of kinetic energy to it. Kinetic energy (force) is the mass of the bullet, times the acceleration (velocity). There's a trade off though. A small bullet with a huge velocity behind it has problems with ballistics (smaller bullets tend to be more inaccurate since they are more affected by the wind, and even the rifling of the barrel). So your small caliber hyper velocity gun will be inaccurate. You can make the bullet more accurate by increasing the barrel length, but then that increases the weight of the gun. So you say, make the bullet huge. Well, if you do that, then you have to put more charge behind the bullet, that means the firing chamber has to be made sturdier, and therefore the gun is heavier. Also, there's some tricky things about bullets and the way they damage human beings and penetrate armor. That high velocity small caliber rifle may have a lot of force behind it, but it also has a high penetration factor (force/area). Which means it's really good at penetrating armor, but actually isn't as lethal (it'll make a nice clean hole through human tissue, without a lot of hydrostatic shock). Now the big caliber but slower bullet may have the same force as the smaller bullet, but lesser pentration....but it will do more damage to the human body because it may get slowed down by human tissue causing "shock waves" in the tissue (hydrostatic shock). The bad news is, it's not as good as penetrating armor....so you should hope your target isn't wearing any body armor.

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]

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]

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

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

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

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