 |
| |
|
|
MrBaggins
|
|
To quote Dr. McCoy... "I'm a Doctor, not a magician". Just because a lot of people want something doesn't mean a designer/programmer can conjure a new algorithm to do so with little or no CPU cost.
I agree that units have different movement rates... this doesn't "solve" any problem for us when discussing terrain-based boni, except sofar as giving a range to A* pathfinding, which isn't the cost I'm concerned about... thats actually an optimization.
Theres no evidence to suggest that the AI attempts to avoid or take advantage of enslavement, except in the grossest and most simplistic terms.
You mention that the AI has improved since Civ2. Thats true... although its also true to say that Civ3 uses object orientation and that Civ2 doesn't. OOP allows for implementations that are difficult, inefficient and messy in standard programming languages. C++ has allowed for implementation of algorithms that are now standard in FPS's... that would have been impractical in C. Standard algorithms (including typical AI solutions) haven't changed in that time period, or since, however.
Zero range bombardment is absolutely not an extention of AI behavior, if you are already considering bombardment with range in the AI. Its a tiny tweak.
The improvement in the AI during the patches isn't due to any special new algorithms being developed, either... they are merely incremental tweaks. Since the Civ3 AI is static, noticable gains can be made when a large playtest group points out simple AI flaws in finite circumstances. Finite decision spaces can be easily (and thus quickly) solved.
I have concerns about the apparent intelligence and performance of the AI, that I consider more important to Civ4, than minor enhancements to gameplay. I've not been posting saying "this can't be done". I've been posting saying "this will be too slow", based on commonly available knowledge.
|
|
| |
|
|
|
MrBaggins
|
|
They might have implemented terrain-based boni, but that doesn't mean the AI considered them. As I recall, the AI for Warlords II Deluxe was pretty dumb, and the only real challenge was fighting 7 opponents simultaneously.
|
|
| |
|
|
|
lajzar
|
 |
Japan
Jun 2003
time: 14:32
|
|
quote:
Originally posted by Switch
I would have to disagree whole heartedly on this. Civ3's ZOC is much better than civ2's, IMO, and is actually more realistic. Say you're playing a giga earth map, 256x256 or whatever...I'm not sure how wide the tiles are, but each tile works out to be several hundred km...sometimes even the civ3 style is a bit much, but i think it works fine.
|
The zoc issue seems to be religious in nature. Either you want it for the map simplification, or you think it is excessive for a world map. However, you dohave your numbers wrong. For a 100x100 map (the largest unpatched in civ2), each tile represents a square 180 km across. For a 256x256 map, each tile represents a square 70 km across. At that scale, zoc makes sense for more modern weapons. Note that in my proposal, this is a flag that can be toggled for modders, and also note that I did not say every unit would have it. I only proposed that missile units would have it. Perhaps that could be modified a bit. Maybe ancient generals might have it, and riflemen onwards too. Archers probably shouldn't.
quote:
Originally posted by Switch
Agree with you here. The way it works now, it's as if planes teleported  . And paradropping was nice too, in SMAC. Maybe make it so that paratroopers can paradrop, ie a limited range from the city, and modern paratroopers can do strategic insertions, ie no range limit (like SMAC's orbital insertions). |
I'd have ww2 type paras limited to say, 6 tiles, and modern paras to 12 tiles. Even today, round the world paradrops are unheard of. When modern military tech reaches the orbital insertion stage, perhaps unlimited range paradrops would be acceptable.
ps: as a military tactic in ww2, paradrops weren't that useful. Good for sending in advisors/saboteurs (perhaps spy units should have paradrop) and supplies, but reforming a regiment after a paradrop is a non-trivial task. To reflect this, paras absolutely should not be allowed to move on the same turn they use a paradrop. Their combat stats should also be weaker than equivalent units of the day, to represent a smaller number of men present.
|
|
| |
|
|
|
MrBaggins
|
|
Thats a universal bonus for any unit on a given terrain. Simple to calculate, and an utterly different complexity.
|
|
| |
|
|
|
wrylachlan
|
|
quote:
Originally posted by skywalker
quote:
The movement bonuses are already essentially in the code since wheeled units have different movement penalties than foot soldiers. There's no reason that expanding that concept to allow other special cases wouldn't be a no brainer. |
I'm not sure you're correct, that the AI takes into account the varying move penalties. I think it just calculates the shortest path for the unit or stack (and a pathing algorithm is obviously necessary to include, so there's no downside to using it). |
My point was that given two 2-Move units, 1 with the wheeled flag, one without, the pathing algorithm needs to be run twice, since rivers, mountains, etc. may make their potential ranges different. Therefore there is already code in the system that says "hey, does this unit have any special movement flags that would cause me to have to redo the pathing algorithm, or can I reuse the results from the other unit with the same movement points."
Any terrain specific movement bonus would simply include a similar flag.
And in response to Mr. Baggins... please. I've never suggested miracles. But guess what? Miracles do happen. And though you may be an excellent AI programmer, it seems shortsighted to dogmaticallyrule out the possibility that another programmer might be able to do something that you consider difficult. I say that not to be insulting, but practical. There are many things that I am knowledgeable about, and pride myself in where I have been caught unawares by a possibility I had not opened my mind to.
More importantly, I think your AI based criticisms would be easier to take if you phrased them more diplomatically. Essentially every choice of added features involves a certain level of AI programming. And the choice rests on whether the percieved benefit outweighs the downsides. Move interesting terrain oriented combat model vs. some more time between turns. My vision of Civ4 involves doing things like, making the number of total units fewer, fewer cities, and providing better high level tools to automate tedious repetition. Those gains on turn time I would like to use to "buy" a more interesting and complex combat model. So I for one am solidly for the idea of terrain based bonuses even if it does slow some things down.
What I take exception to isn't that you voice your opinion about which trade-offs you prefer, but that you use phrases such as "Do you have any clue" in an attempt to shut down discussion of ideas you don't like. Its rude and arrogant, and too bad - I'm gonna discuss them anyways.
|
|
| |
|
|
|
MrBaggins
|
|
quote:
Originally posted by wrylachlan
And in response to Mr. Baggins... please. I've never suggested miracles. But guess what? Miracles do happen. And though you may be an excellent AI programmer, it seems shortsighted to dogmaticallyrule out the possibility that another programmer might be able to do something that you consider difficult. I say that not to be insulting, but practical. There are many things that I am knowledgeable about, and pride myself in where I have been caught unawares by a possibility I had not opened my mind to.
|
Miracles don't happen in algorithms. A fundemental algorithm has a minimum, average and maximum time (and sometimes memory) cost. These are universal constants. You can occassionally optimize an algorithm, but these algorithms are typically highly optimized already. In Civ, maps, where weighted costs can change, and actors can block and be blocked are troublesome, because you can no longer guarantee that you can cache an A* path, therefore your options for optimizing pathing are limited.
In this same vein, if you have to check tiles surrounding a particular (square, iso) tile, then that ALWAYS means 8 conditional checks. No miracles involved. If you tried to optimize by checking where its unnecessary to look, then that still requires A* pathing costs (because the map and units aren't static), which will average to be more expensive.
A weighted cost is always more expensive than a simple boolean cost, because it requires a more costly operand to perform.
These aren't avoidable by skillful programming. They are universal constants. Limitations on caching and optimization aren't industry secrets, they're widely known. No miracles involved.
quote:
More importantly, I think your AI based criticisms would be easier to take if you phrased them more diplomatically. Essentially every choice of added features involves a certain level of AI programming. And the choice rests on whether the percieved benefit outweighs the downsides. Move interesting terrain oriented combat model vs. some more time between turns. My vision of Civ4 involves doing things like, making the number of total units fewer, fewer cities, and providing better high level tools to automate tedious repetition. Those gains on turn time I would like to use to "buy" a more interesting and complex combat model. So I for one am solidly for the idea of terrain based bonuses even if it does slow some things down.
What I take exception to isn't that you voice your opinion about which trade-offs you prefer, but that you use phrases such as "Do you have any clue" in an attempt to shut down discussion of ideas you don't like. Its rude and arrogant, and too bad - I'm gonna discuss them anyways. |
I don't have to sugar coat my discussions for you, and the truth is, that you really DON'T have any clue as to how much each relative change costs and saves, because you don't comprehend the data representations and algorithms involved.
You can discuss whatever ideas you like, but I can point out when an idea is inefficient and slow. If you'd like to learn about AI systems, so that you can add something useful to a discussion about CPU efficiency, I can recommend some books that explain the topics I've discussed.
I still disagree that the inevitably much longer turn times mandated by terrain-based boni would justify the additional feature.
|
|
| |
|
|
|
MrBaggins
|
|
Wrong.
We aren't talking about where a group of units can move, we are talking about where a group of units should move, considering the defensive advantage to these specific units, and the theoretical offensive advantage of the surrounding 8 tiles to the specific unit's of the opposition that can reach them.
This is utterly dissimilar.
|
|
| |
|
|
|
wrylachlan
|
|
quote:
Originally posted by MrBaggins I don't have to sugar coat my discussions for you, and the truth is, that you really DON'T have any clue as to how much each relative change costs and saves, because you don't comprehend the data representations and algorithms involved. |
If you are of the opinion that choosing a less rude way to say something than "You don't have a clue" is sugar-coating it... then I'm afraid we have nothing to discuss.
|
|
| |
|
|
|
MrBaggins
|
|
Right. Its easy to program battles to have these advantages, but to get the AI to understand how it should utilize them is costly.
Its a rock and a hard place, unfortunately, since if you include them, but don't allow the AI to understand these, then the human can exploit this AI weakness. The AI is put at a disadvantage, and the AI is weaker in general. Or, you include it, and end of turn times are slow.
Not worth it.
|
|
| |
|
|
|
MrBaggins
|
|
Sure.. you use simple conditions to check for a limited number of situations which provide advantage or penalty, based on the very specific unit bonuses per terrain, in the game file, as shipped.
If you want the engine to adapt to a flexible bonus, which a player changes, then you need to calculate it dynamically... which is costly.
You could save a tiny bit by using a flat modifier instead of a coefficient, in the final weighting, but you'd need to assume X units, for that approach, and if there are more or less in a particular defense or attack, that will lead to poor technique by the AI.
|
|
| |
|
|
|
Kuciwalker
|
 |
of Schmooism
Feb 2001
time: 00:32
|
|
[QUOTE] Originally posted by wrylachlan
My point was that given two 2-Move units, 1 with the wheeled flag, one without, the pathing algorithm needs to be run twice, since rivers, mountains, etc. may make their potential ranges different. Therefore there is already code in the system that says "hey, does this unit have any special movement flags that would cause me to have to redo the pathing algorithm, or can I reuse the results from the other unit with the same movement points."[/q]
No, it runs the pathing algorithm once, for the slowest MP in the stack and whether or not there's a wheeled unit in the stack (if it runs it once for each unit in the stack, it's poorly designed).
quote:
Any terrain specific movement bonus would simply include a similar flag. |
No, because you can't just say "worst unit" like you can "worst move".
|
|
| |
|
|
|
wrylachlan
|
|
quote:
Originally posted by skywalker No, it runs the pathing algorithm once, for the slowest MP in the stack and whether or not there's a wheeled unit in the stack (if it runs it once for each unit in the stack, it's poorly designed).quote:
Any terrain specific movement bonus would simply include a similar flag. |
No, because you can't just say "worst unit" like you can "worst move". |
We have no way to know whether you're right or not without looking at the code, but the mechanism you're suggesting doesn't make sense. If it looks at the worst MP in a stack, what happens in a mixed stack with cannon and cavalry? If it used the same algorithm for cavalry as it used for cannons, then you would be safe from that stack by simply staying 2 tiles, which isn't the case. I've often seen the AI split its stacks, advancing cavalry in front of cannons to take advantage of a target of oportunity.
Thus obviously, at the very least, it runs the pathing algorithm once for each MP value in the stack. Which doesn't mean for each unit, since all 1 MP units can reuse the same pathing, as can all the 2MP units, etc. The exception to this is wheeled units. Given 2 units of the same MP one wheeled, the other not, it has to run the pathing algorithm twice.
But this doesn't mean a drastically larger amount of runs. Since there are no 1 MP wheeled units, and the Max MP in the epic game is 3, you have at most 5 runs per stack for a stack of unlimited size.
|
|
| |
|
|
|
MrBaggins
|
|
quote:
Originally posted by wrylachlan
We have no way to know whether you're right or not without looking at the code, but the mechanism you're suggesting doesn't make sense. If it looks at the worst MP in a stack, what happens in a mixed stack with cannon and cavalry? If it used the same algorithm for cavalry as it used for cannons, then you would be safe from that stack by simply staying 2 tiles, which isn't the case. I've often seen the AI split its stacks, advancing cavalry in front of cannons to take advantage of a target of oportunity.
|
Different groupings of units with different movement rates/types would each use an independent search. The threat matching system might choose to split a group of units off, which then becomes an independent group.
quote:
Thus obviously, at the very least, it runs the pathing algorithm once for each MP value in the stack. Which doesn't mean for each unit, since all 1 MP units can reuse the same pathing, as can all the 2MP units, etc. The exception to this is wheeled units. Given 2 units of the same MP one wheeled, the other not, it has to run the pathing algorithm twice.
But this doesn't mean a drastically larger amount of runs. Since there are no 1 MP wheeled units, and the Max MP in the epic game is 3, you have at most 5 runs per stack for a stack of unlimited size. |
You're forgetting roads, and railroads. A value rather than flags would be necessary to deal with these. Also pathfinding algorithms use recursion, and the only parameter that makes sense of this would be a value, rather than a flag.
|
|
| |
|
|
|
wrylachlan
|
|
quote:
Originally posted by MrBaggins You're forgetting roads, and railroads. A value rather than flags would be necessary to deal with these. Also pathfinding algorithms use recursion, and the only parameter that makes sense of this would be a value, rather than a flag. |
I think you're missing what I'm saying. The flag is merely to tell the AI whether it needs to re-run the algorithm. Correct me if I'm wrong, but I imagine the AI checks the units in a stack in order. Say the first one is a 2 MP unit. It runs the pathing algorithm for 2MP. It gets to the second unit. If the second unit is also 2MP, it knows that unless this is a wheeled unit, it doesn't have to re-run the algorithm. So it checks the wheeled flag. If the unit is not wheeled, it reuses the 1st unit's run of the algorithm. If the second unit is wheeled, it does a seperate run. From that point on, if it finds another 2MP non-wheeled unit, it reuses the first run. If it finds a 2MP wheeled unit, it reuses the second run.
|
|
| |
|
|
|
MrBaggins
|
|
Kind of.
The identifiable data for units is listed here
Some info we'd be interested in would be
4 long movement
and a number of the unit abilities... for example
4 long unit abilities (binary):
00000000
wheeled .......1
cruise missile ....1...
all terrain as roads ...1....
and
4 long class 0=land, 1=sea, 2=air
It would group by movement categories FIRST, then by move rate. It wouldn't assume that a unit with a wheeled flag necessarily had a certain number of move points, its a limitation on movement.
If the AI decides that it wishes to keep the grouping together, for defensive purposes, then it may limit a longer range subgroups move to the slowest movement.
Last edited by MrBaggins on 11-02-2004 at 22:15
|
|
| |
|
|
|
wrylachlan
|
|
quote:
Originally posted by Urban Ranger A lot of people are still forgetting that a turn is at least a year in Civ. We are not talking about days or weeks. Any sort of terrain movement bonus is meaningless on this scale. |
When you play civ you have to accept that the time scale is not going to be realistic. A unit that used to take 5 years to move 1 tile, then next turn takes just 1 year to make the same move. What is more important is the relative movement. If we accept that for game play reasons a tank moves 2 tiles per turn on grassland, what should be its relative movement on hills? Mountains? And if we accept that a regular infantry unit moves 1 tile in mountains, is it outrageous to think that there might be a special forces type unit that might move faster in the mountains?
Seriously. People who get their underwear in a bunch over "a tile is x km wide" or "that unit could move many more km in a year" need to just get over it.
|
|
| |
|
| |
|
|
|
okblacke
|
|
quote:
Originally posted by Urban Ranger
What's your point? Are you arguing that more anomalies should be added? |
If they help gameplay? Sure. Absolutely. No contest. F*ck reality.
[ok]
|
|
| |
|
|
|
wrylachlan
|
|
quote:
Originally posted by Urban Ranger What's your point? Are you arguing that more anomalies should be added? |
No. I'm saying that what's important is cutting down on the relative anomalies. We've already accepted the anomaly that it takes an infantry unit a full year to walk 55km in the mountains. But to say that a special forces unit is incapable of covering more ground in the same amount of time is itself an anomaly.
What's important for game play is not the absolute realism, but the gameplay realism of each unit in relation to each other.
And over and above that, realism makes the game fun to play. But interesting strategic game mechanics also make games fun to play. So if the amount of strategic fun an anomaly adds, outweighs the loss of realism, by all means I'll argue that more anomalies should be added.
|
|
| |
|
| |
All times are GMT. The time now is 05:32.
Apolyton Time is 00:32. |
top of page
|
|
|
Forum Rules:
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
|
HTML code is ON
vB code is ON
Smilies are ON
[IMG] code is ON
|
|
|
|
|
|
09-02-2004 23:51
|