Real Battle in RTS

An rts is far different from a real battle, you are speaking of rpg, in a rts a single unit is supposed to rappresent a bunch of soldiers (or I have always sopposed it), the recent rts on Warhammer hits the point. Semplicity of the single unit is all in a rts where you have 30/40 units to control, too much precision is a work for the AI too complex in a 40vs40 battle with buildings too.

Semplicity of the single unit, in my opinion, is a must. You may adopt the "hero" line of warcraft series and construct 1 or 2 units per faction very detailed, and merge them in the moltitude of other simple units.

Speaking of the archer that destroy the castle... I agree this point, a damage differentiation, like "40 damage to unit + 10 to buildings" wold do the trick without killing the machine.

For the sake of pedantry, the original idea of the concept "hit points" was not equivalent to health. It included things such as blocking, fatigue, etc. That is the reason for the big increase in hit points when gaining levels, at least originally — you don't really gain "durability", but rather skill in fighting. Similar argument can be had about gaining hit points back. The whole "hit point" idea is really a simplification of all aspects of battle, in its original form.

Of course, nowadays the term "hit points" (at least in computer rpg sense) doesn't really mean anything exact. I mean, in most games losing hit points is represented by a flow of blood and guts, you can regain hit points by resting a bit and still issues such as fatigue and blocking are modeled separately. As far as modern rts games go, I have no idea what "hit points" really means, but I'd say it's closer to the original meaning of the concept "hit points". The reason I go on about this is that I don't consider this a bad model for battle, if you want to simplify it — as long as people know what the concept "hit points" means in that specific context.

One other problem with a more complex model is that despite the semi-realistic depiction of the game world, the concepts are usually rather abstract. One unit might mean actually a group of soldiers and not an individual. A battle with 50 units on each side, each unit representing a batallion of men would be epic, a battle with 50 men on each side is hardly a skirmish. If you make single units weaker, you should allow creating larger armies and make the units cheaper, I'd reckon. Personally I would be in favour of this de-abstraction.

If you want to have separately health, fatigue, blocking skills, parry skills, what have you, that's all fine and good, but make it consistent and don't mix the different aspects with each other arbitrarily (one thing not strictly related to here would be Empire Earth's sharpshooters/snipers: a sharpshooter can kill enemy infantry units with only one shot, but a heavy machine gun unit needs to fire quite a lot of rounds even from a distance of one meter — a perfect example of not being consistent).

I do think you could add a lot more strategy and mood in the game by increasing the depth of the game and removing some of the abstractions. Wounded soldiers should be carried to the nearest base/castle/whatever to tend the wounds, soldiers that are far away from the nearest food supply start to get weaker from hunger (even though I don't like the attrition aspect in Rise of Nations as such), weapons would break if you didn't have someone (possibly someone less effective in combat) to maintain them, etc.

As for having to look after 200 soldiers with all the minute attributes, the problem is the not the number of the attributes, but rather the number of the soldiers, 200. What I'm trying to say, it's not great fun having to look after 200 soldiers even without all these bazillions of attributes, if you have to control each unit individually. What we really need is a complete overhaul of the rts controlling system. Instead of giving orders to single units you should have the ability to make plans on a more abstract level and let the computer worry about the specifics. Note that this does not mean you still couldn't control single units, but rather that you wouldn't have to. This is, however, beside the original point (more realistic battle), so I won't start raving about it now. However, as you stated your interest in suggestions, you might be interested in my ravings on the subject previously, so here's a link:

Those distant, storm-beaten ships...

Grim hit all the problems of doing this that I see. My suggestion for doing this is focusing on a small number of chracters instead of the usual 200. The level of detail/depth you strive for and the number of characters allowable are inversely proportional. Because no user wants to check the "hand speed" of 200 characters before while preparing for battle. But say I only have 10 characters, then it may be permissible. It's not a game for everyone, because it inherently involves tactics(if the game is done right) that the average doom-player doesn't care about, but it is viable. In fact, to an extent, many games do this already. Mostly they are strategy-rpgs, final fantasy tactics comes to my mind.

A small number of characters also might make programming easier and will ease system usage. Let's think of your fight between two swordsmen. One attacks first, weapon in his right hand. The strength of his attack is based on his age, fatigue, confidence, skill, dexterity, handed-ness(left or right), and a bunch of other stats. Then you need to calculate the other guys blocking ability based on a bunch of stats, or maybe he tries to counter, or dodges, etc. Now do all that again for 199 other pairs of combatants. Your computer is crying from all the work. Then after that round of attacks, rinse and repeat until there is a victor in the battle. That's a huge load on your computer(and the user to comprehend and manage).

Actually I'm not sure if less people would make the programming much easier. But I'm sure that it will ease the load of the user and computer. And you want 3d models, which involves loads of graphics work and animations, tons of animations. All this be eased by using less characters. Sorry if i sound condescending, i don't mean to. I just ran with the tangent of "don't use lotsa of characters because..."

Another worry is because of the depth involved in playing a game like this, the other parts of game can't get in the way of the tactics. Your interface and such must be tight.

actually as Grim said, hitpoints these days aren't really health.

If you want to do away with health, and make for more realistic combat here's my suggestion:

forget non-fatal wounds, make (multiple) coupled animations of parried/blocked/landed attacks (ala KOTOR i believe) and switch between them with dice and levels. Have some levels change during the fight.

for example:

levels for each char:
defense [0-1]
attack [0-1]
stamina [0-1]

then roll the dice for each character. using each level as a threshold, you get:

the attack lands or gets parried
a landed attack gets blocked or not
a non-blocked landed attack means instant death
defense and attack should steadily go down with stamina, probably acting as a multiplier: real attack = stamina*attack, stamina starts as 1 when the character is rested, and slowly goes down to 0 with running(?) and fighting.

Yes, defense would have to be rather high for all characters.

About speed: yes, you could have all different values for different soldiers, and this wouldn't make the game run much slower (considering linear access time). It would however, consume much more memory. Balance accordingly, it depends on how big you want the battles to be. Run some numbers. It probably is around the same that other RTS though.

About micromanaging: i have yet to see a game where in the "stats" area they show actual statistics. not just values, but calculated statistics. Things like:
your character selection averages 77% attack with 5% variance
this is not-so-easily calculated, but its only done once (on selection) and its easy to understand once explained. you could simplify the display with:

    Avg  VarAtt  77    5Def  85   20Stm  70    3

now, what would be sweet is a small clickable histogram of your selection's stats, where you could single out percentiles (say, select the best 70% of the group, or select the ones over 80% defense...)

Oooh... that would be so nice.

I'd say that if you want to have one-blow kills, you really should have huge armies.

While it is true that not many would want to have to control every little aspect of a huge army, this doesn't necessarily mean you had to make the army smaller. I'm not saying that a smaller scale tactical game would be bad at all, but rather that the genre wouldn't be exactly the same (usually rts games tend to try to have an grand, mind-staggeringly hugely epic feel). Anyway, I still claim the controlling system should be made easier. Give objectives with priorities and let the computer worry about which units to assign to those objectives. The degree of automation can be arbitrary here; you could also have the ability to assign soldiers to certain objectives manually. Madster's idea of having the statistics of selected units as part of the user interface would be a great help in such a system.

If you want to have truly different values in each ability for each unit, this could easily take up memory, as Madster said. However, you could just have some ability/equipment-prototypes and just have a pointer to the weapon/armor/skill set/whatever for each unit. Sure, it would still take memory, but not as much as if you just had all the variables in the unit description. Much like in action rpgs such as Diablo, with the exception that you would only have one of each item (a prototype or an archetype, if you will) and just have a pointer to that for each unit using that item. Similarily, there could be similar archetypes for different combinations of skills and mentalities. Of course, this is not all that unlike the current system of rts games (as you do have different types of units), but more detailed. Instead of having just one maceman and one swordman etc. I could have a set of weapons (mace, sword, axe, etc.), a set of armors (leather armor, plate mail, chain mail, Markov chain mail ([grin] I had to get that in...), etc.) and thus have a lot of options when I choose what combinations I want. It doesn't even have to make the user interface cumbersome and flooded with bazillions of little buttons: you could design some combinations before starting the game and in the game you could easily train these units like in the way you do it in, say, Age of Empires. If you wanted something different in-game, you could use the unit designer to alter the selection offered in, say, the barracks building in the middle of the game.

As for the calculations for AI, you wouldn't need to take every aspect into consideration but rather simplify the stats of the units. That's what people usually do, anyway, instead of considering every detail of the units. You could calculate a weighted average of the values, or whatever, and use that for AI calculations. Use the real, detailed description of the units only if necessary.

Then again, with this kind of problem it is important to ask yourself whether you really want a complicated system like this or an illusion of one — thus you don't necessarily have to change the underlying system, but rather its representation on the screen. If the player can't tell the difference, it doesn't really matter which model you use.

I would agree with most of the posts here that simplicity is key when dealing with a RTS. If you wanted a more realistic feel to the game, then make special rules for units, such as archers do no damage to buildings. This would require players to use alternate strategies if they wanted to destroy that building. Another thing you could do (but would be an AI nightmare) is to make each unit into may seperate individuals. The player has control over the unit, and can say attack Target A. The individuals within that unit, working together, go on to attack Target A, which may be another unit of individuals working together. These still allows for the player to have a simple interface, not having to deal with, in some cases, thousands of individuals, but still allows for the realism of having 50 soldiers destroying a building, instead of just one. Just some ideas, take them for what they're worth.

********
Gwyddion

First of all thanks for the attention and suggestions.

Now: i want to do something new. Making an other AOE or Warcraft would be simply needless and the only reason to bother with would be just for educational reasons. I want real innovation here!

About the Real Battle: there would be predefined attacs, defenses, etc with each attack,ie, to have a degree: lets say 50. A fighter will require some skills to access this attack (lets say level 3 etc). The same story goes for the def's and a theoritically better fighter should easilly win a not-that-good one. The ccomputations for that kinda fight would be very simple: fighter1:attack #2, fighter2:defend #13, etc where the real battle would be (not that much) just an illustration. Of course i cant make a street fighter where fighters have swords-its an other game. I want to make it look a little bit different and to show something good looking. Not that real battle wont be happening but it would too simple in the background: PREDEFINED MOVES with good illustration.

About simplicity:
There will be several types of weapons, armors, shields etc with a quality level for each weapon (Level 1 to Level 8 ie) and a fighter gets trained to a weapon made by the Gunsmith (a building that creates weapons, armors etc by iron and wood) and he can change the weapon,armor etc whenever he wants. In fact he can get the enemy weapon,armor etc if he gets the chance(from a dead guy)! BUT!!!!!! The user will not have to worry about every single detail: instead of have weapons,armors etc global upgrades (AOE like) the trained unit will go and take (if any) its armor etc from the smithy. To upgrade simply go back to the smithy, give its former armor etc(if you want to melt it to regain the materials) and take the new one. I am thinking even about a supply cart to take the armors etc to the fighters.
ALL THESE WOULD BE FOR I-L-L-U-S-T-R-A-T-E-D DETAIL. The user will just command each units like in AOE, Warcraft, Warhammer etc -OR- he will assign some units to captains etc ordering a captain a job and the he(the AI) will move and position the units aproprietly. Of course units coordinated by a captain will have better moral, positioning etc.

About health:
Units will also have health: a unit can also get WOUNDED by a fight or be hit by someone (lets say by a hammer, flail etc) which slows him down, easier to kill etc. And of course there will be the appropriate doctors (priests-the name doesnt matter) to heal them

About strategy and good GAMEPLAY:
For me? Gameplay is the TOPMOST important issue about an RTS. The user has to give orders as easy as possible. The quality selection is a VERY GOOD adition to the gameplay, really matching to this kinda game as in AOE ie there are archers of the same level, swordsmen of the same level etc. Here there are units with different training which makes different armies. A user that trains his soldiers for longer time gets a fairly better army than the one with less training BUT in the cost of time. A user that trains his soldiers for less time gets a fairly bigger army- but his soldiers dont stand much chance individually against the former's army. Strategies will be many: go somewhere from the sortest path or from the safiest path. Engage recklessly or just defend your town. And of course quite many formations and positionings (swordsmen suround archers and defend them from enemy archers with their shields ie).

OF COURSE SIMPLICITY:
The user wont be worring about every one soldier but will have an average of his army quality display and units will automaticly go for some train between them will not fighting, get armors etc.

This for now, give me your opinions and i will come back with other ideas and aspects of the game.

Can anyone get me in contact with modelers? I only know some programming not much more...

Grim:
I havent time to check on your link. I will thouhg...

[Edited by - costasgr43 on December 6, 2004 5:08:06 AM]

Battle Realms, I believed, tried the small-force approach. I didn't care much for it.

I'm of the "if it ain't broke don't fix it" mindset. Adding all those little variables might be fun for a programmer, but it strikes me as boring as hell for players.

Just a little note about simplicity: It only needs to be simple for the player.

You're free to use as complex methods as you'd like underneath, so long as they're represented in a simple manner to the player.

For example, you could determine each class in the game, and what it's base attributes would be. What they are doesn't matter as long as they're consistant with their role. Then if you were to provide upgrades, such as improved armor, weapons, training, etc... instead of saying (for say, Heavy Armor) "This increases the unit's shield quality by 100% but decreases foot agility, and shield arm agility by 25%" Just say "Greatly increases the unit's chances of successfully blocking an attack, but at a moderate cost to agility".

Note the lack of numbers. Note that even when you do know the numbers, it doesn't really tell you what it really does. 100% sounds great, but 100% of what? Will that let me defend an Ogre's attack? With consistant text only descriptions, you can actually get a lot more across to the player, without losing any of the internal simulation's complexity.

Bitmap Bros "Z" was good at this - there was anti-infantry and anti-armour gear, and anti-infantry machineguns were completely innefective against certain hardened targets, while explosive weapons could even dig through rock walls.

Still, a medieval RTS with this sort of realism would be horrendously overcomplicated - you'd have to build battering rams, or have squads of workmen chop down a tree to build a ram on the fly.

A simpler, mathematical solution is having an "armour value" that is taken off of all attacks.

Its not only a problem in RTS games too - remember chipping a Star Destroyer to death with an A-Wing in X-Wing?

Quote:

Original post by nuvem Just a little note about simplicity: It only needs to be simple for the player. You're free to use as complex methods as you'd like underneath, so long as they're represented in a simple manner to the player. For example, you could determine each class in the game, and what it's base attributes would be. What they are doesn't matter as long as they're consistant with their role. Then if you were to provide upgrades, such as improved armor, weapons, training, etc... instead of saying (for say, Heavy Armor) "This increases the unit's shield quality by 100% but decreases foot agility, and shield arm agility by 25%" Just say "Greatly increases the unit's chances of successfully blocking an attack, but at a moderate cost to agility". Note the lack of numbers. Note that even when you do know the numbers, it doesn't really tell you what it really does. 100% sounds great, but 100% of what? Will that let me defend an Ogre's attack? With consistant text only descriptions, you can actually get a lot more across to the player, without losing any of the internal simulation's complexity.

Remember the lesson of MOO3: even if you hide complexity under the hood, its still complexity. The player wants to know how thigns actually work so they can plan based on that. Plus, by spending time coding hidden complexities, you increase the difficulty of balancing and creating the game without adding any perceived value.

I disagree. MOO3 abstracted complexity just fine; the problem was that the game mechanic is overused, tired, and the game was buggy as hell.

I don't think players want numbers so much as they just want to know what they're doing so they can play. Games are not spreadsheets. A TBS? Fine. Medieval: Total War has plenty of numbers, and I can dig that. But in an RTS too many numbers kills you.

Quote:

Original post by Pxtl Remember the lesson of MOO3: even if you hide complexity under the hood, its still complexity. The player wants to know how thigns actually work so they can plan based on that. Plus, by spending time coding hidden complexities, you increase the difficulty of balancing and creating the game without adding any perceived value.

MOO3's complexity hiding in action ;)

There is most definitely a desire for some of the more mathematically inclined players to spreadsheet out values and figure out the internal computations. To them, I say too bad. I'd rather serve the much larger group who simply want to understand enough to play the game well, and accurate text descriptions serve that purpose.

As far as the level of internal complexity, that's another debate, and depends greatly on the system in question. Certainly, frivilous simulation should be reduced and abstracted, but one can argue that detailed simulation can provide interactions that would not be possible with more simplified systems. Either way, my post was simply about hiding that complexity from the player.

Again, thanks for the attention

Some answers first:

Quote:

Original post by Edward Ropple I'm of the "if it ain't broke don't fix it" mindset.

Sorry about what i am going to say but if everyone was thinking like you then we would be still living into caves! For me ,at least, evolution of something is a very good motivation to get busy with it. Even if all the evolution is just to go 1/10 of a step forward or to just improve something existing it worths working with. Even if this wont work out then... its ok nobody gets hurt. I will just have learned some more programming (experience is what makes a good programmer) and the next will know some more good and bad ideas about the subject.
Dont misunderstand me... ;-)

Quote:

Original post by nuvem Just a little note about simplicity: It only needs to be simple for the player.

Quote:

Original post by pxtl The player wants to know how thigns actually work so they can plan based on that. Plus, by spending time coding hidden complexities, you increase the difficulty of balancing and creating the game without adding any perceived value.

I agree with pxtl: it doesnt worth making the best-most innovating-most sophisticated managing system if the user doest even know about it! Work by the programmer is supposed to be done in order (1)to make the users life easier, (2)to make the game more robust and (3)to make the game more interesting. (Not all objectives were presented here)

So nice things now (the game stuff):

The specific game is not that complex as it may be presented now. To explain myself: the stats for each unit will be:

• fatigue, that will affect the speed and fighting ability in form of current fatigue/maximum fatigue, something like energy that will be reduced by running and constant fighting
  
• strength, that will affect the fighting ability if form of energy (see fatigue) that will be reduced by armor, weapon etc weight
  
• experience points, that will affect fighting ability and will increase while fighting, while the increase depends the enemy XPs meaning that if the units doesnt fight for a long time or fight with a unit with significantly (sorry if i have misspelled it...) lower XPs (ie 3000 against 500 (!)). Of course the decrease rate will be very low so that units dont lose XPs for just sleeping one night(!) but also in order to keep interest so that the user doesnt send always his best troops to resolve battles.
  
• health, that will be in form of energy, meaning healable. It will be decrease if dodged, hit by a hammer that will not kill him, a bow that hit him at the shoulder etc.
  
• hit points(why? why? why?), that will not be healable and will specify the "power" needed by someone to kill him. So, if a hit (swords, lances etc will have infitive HPs attack that will kill a unit no matter how many HPs it has, or something like that (very great creatures ,ie dragons, may need several "killing" hits)) wont kill him it will reduce his health.
  

The weight:

Each item carried by a unit will have weight and volume so that a cart carrying 10 villagers will run faster than carrying ten hammer-men as of course the hammer-men will carry heave armors and the heavy hammers. Also carts may carry armors, weapons etc and the cant carry ie 20 swords maximum OR 20 hammers maximum! It may only carry 5 hammers (for this example) as a hammer takes up four times the space of a sword.

The Mounts!:

Units may be mounted meaning that they can mount a horse, unicorn, camels, pegasus, wolfs(!), dragons(!), elephants, etc. Of course a tamer (in a way of animal trainer equiv to the barracks trainer) will have to tame the horses, camels, elephants BUT BUT BUT BUT he will have to find ,if any in the map, the other mounts. So you may produce as many horses you want but you must be lucky if you find lets say a dragon. Of course it would be easier to tame some "Dire Wolves" that would be more in a map than a dragon but a dragon can fly and spit fire(not the ww spitfire airplane ;-))...
Of course the unit is not bound to the mount meaning that the mount or unit can die without having both to die or that the unit can unmount the mount.

Thats all for now, i will come back...
If you want to help me with 3D models or artwork OR know where to look or you know someone that wants please let me know! costasgr43@yahoo.com

Quote:

Original post by costasgr43 Quote: Original post by nuvem Just a little note about simplicity: It only needs to be simple for the player. Quote: Original post by pxtl The player wants to know how thigns actually work so they can plan based on that. Plus, by spending time coding hidden complexities, you increase the difficulty of balancing and creating the game without adding any perceived value. I agree with pxtl: it doesnt worth making the best-most innovating-most sophisticated managing system if the user doest even know about it! Work by the programmer is supposed to be done in order (1)to make the users life easier, (2)to make the game more robust and (3)to make the game more interesting. (Not all objectives were presented here)

My point was not that you hide everything, simply that if you're going to have a complex model, don't inundate players with stats. My suggestion being that consistant text descriptions can be used to make the game mechanics far more understandable, while maintaining the benefits of the system underneath. What those benefits are is entirely dependent on the system in question.

In Halo2 for example, there's no number telling me the exact % of shield I have, no information screen telling me for each weapon how much damage each bullet does and how many rounds/s it fires, or how accurate it is. Complex simulation, simple UI.

Weird, i'm seeing here lot's of not so positive opinions about large/epic armies, 200+ units. I had the feeling larger armies would be more fun.

I for one would love a game in the line of Lord of the Rings with huge armies. The unit's control didn't have to be too complex since most of them would be of the same type, and most would just be grunts with close to no special skills at all(the clay of the army ).

What i thought would be fun was, having a sorceror or something cast diferent spells in diferent parts of the army, depending on factors like, if that part of the army was being flanked, if it was under siege from archers, if chavelary charged them, or they got any negative buffs from the other sorcerors. The complexity would pretty much come down to a few key units.

With a small army places that are good for ambushes just aren't ambushy enough i mean, here they are crossing a canyon, well if there are archers up there, the army is so small that just pulling back the intire army will cost them next to nothing, plus since the armies are small, there won't be many archers up there to begin with. Things like flanking just aren't that much possible, the army isn't large enough, there are no local strategies, the battle doesn't take long enough for us to even enjoy it. You guys ever played Warcraft III? A battle between two big armies would be decided in a few seconds, that's it.

Micro management could just go out the window, most micro management tactics could be easily coded in the AI of the game. When a unit is getting too weak, leave for a bit(to possibly lose any melle attackers) and come back, ranged attackers focus fire on a single unit preferably the weaker ones, implement auto heal, or auto whatever other skill some non-key unit might have, and we have some pretty decent MM.

Something in the line of Starcraft/Warcraft, but bigger!

[Edited by - xor on December 8, 2004 6:52:40 AM]

Quote:

Original post by costasgr43 Again, thanks for the attention Some answers first: Quote: Original post by Edward Ropple I'm of the "if it ain't broke don't fix it" mindset. Sorry about what i am going to say but if everyone was thinking like you then we would be still living into caves! For me ,at least, evolution of something is a very good motivation to get busy with it. Even if all the evolution is just to go 1/10 of a step forward or to just improve something existing it worths working with. Even if this wont work out then... its ok nobody gets hurt. I will just have learned some more programming (experience is what makes a good programmer) and the next will know some more good and bad ideas about the subject. Dont misunderstand me... ;-)

No need to misunderstand you. You're just not looking at it from the user's POV, just that of a programmer.

Users don't care about under-the-hood complexity. Users want a game that's fun and not many of the spreadsheet monkeys still play modern games.

Large armies can be done just fine in an RTS - you just have to design the gameplay for it. For example, some games like Dawn of War and Z handle units as aggregates of soliders, and other games just have a really nice UI for handling obscene numbers of units (like Total Annihilation). Of course, most just go for a very rigidly strucutred "formation" oriented style of play, as many of the more "realistic" RTS games attempt to conform their "realism" to historic battles, which to me makes the game dull.

Realism is necessary in a historical RTS, and none of them are even that realistic. I've yet to see one that is negatively impacted by its adherency to historical fact.