 |
| |
|
|
LDiCesare
|
|
La Ferté sous Jouarre France
Jan 2001
time: 05:14
|
|
Previous discussion was in Map AI Coding thread ( here ).
I am implementing the ticks-based move code. I'd probably need that the road/no road be coded as cover, soil, etc are. That would help in order to prevent wheeled units from going where there are no roads. The problems I see with this is that you go from a no-road to a road state, which is a quantic jump. So, I try to think about the other kinds of terrain, and here is: If you want to dry some land, you'll go from wet to dry. This has been done extensively in Flandres and the Netherlands. Again, the jump is not quantic in one square.
So arise a question: Do we have primary terrain type/subtype and secondary terrain with figures explaining to what extent you are of a given kind?
e.g.
Terrain is flat (90%) rolling(10%), with no cover (50%), crops (50%), roads (5%) no roads (95%), dry (99%) wet (1%).
I could use that to make use of good infrastructure (lots of roads = faster movement).
On another point, I wonder about the modelisation of speed/movement. I think speed/movement should be a multiplier to the number of ticks needed to move to a square. Izzat correct?
|
|
| |
|
|
|
Mark_Everson
|
 |
Canton, MI
Jan 1970
time: 00:14
|
|
Bonjour Laurent:
IIRC Gary proposed that there be no 'dual-terrain' (flat (90%) rolling(10%)) squares. And I think that's the right way to go, since otherwise things can get Really complicated without much benefit to the player.
As for road infrastructure... it will probably exist in a gradiated fashion as you propose for the minor roads. The major ones (that show explicitly on the map) will either be there or not, although there might be levels to them like dirt, paved, etc.
On speed/movement for units vs ticks, it could have a proportional effect on ticks, but that could be tricky. Forest slows down infantry, but it slows down armor a lot more... So I'm not sure about the right general way to handle movement+terrain -> ticks at the moment. I'd say just keep it simple for now, perhaps ticks inversely proportional to movement as I think you're suggesting, but keep in mind that its just temporary until we figure out a good way to handle it.
|
|
| |
|
|
|
LDiCesare
|
|
La Ferté sous Jouarre France
Jan 2001
time: 05:14
|
|
Main terrain is not much of a concern to me, it's mainly having a lots of roads/few roads which I am interested in so that's OK.
The cover ticks cost will depend on unit type, so basically you would have things like this:
<Terrain>Forest
<MovementCost>2 foot 1 air 0
(close the tags)
This means that a land cover of forest adds 2 ticks for all units except foot units (1) and air units (0).
So you will have several terrain costs, one for cover, one for soil type (slower on sand than soil?), one for wetland/dryland, one for roads and one for main land type (flat, rolling,...).
If I have for instance:
Terrain road MovementCost 1 air 0 /MovementCost /Terrain
and
Terrain noroad MovementCost 3 air 0 wheel no track 2 /MovementCost /Terrain
I can make it so that if you have just a few roads, wheeled units can go in the square but at a high cost, (say +10 ticks). If the terrain is only 50% road, I could go for an average like (for a foot unit) 3 + 1/2 = 2 additional ticks.
Note that a system like that generates lots of ticks.
The best you could have would probably be:
(first figure for foot units, second for tracked units)
flat 4 4
railroad 0 0
dry 0 0
soil 0 0
no cover 0 0(4 ticks)
But you will soon get
mountain 10 15
no road 3 2
dry 0 0
rock 2 3
forest 2 3(17 ticks or 23 ticks - wheeles couldn't cross this).
These figures will all be in a xml file so testers can tune them to find good values.
|
|
| |
|
|
|
Gary Thomas
|
 |
New Zealand
Mar 2001
time: 17:14
|
|
Here is my comment on mixed terrain:
quote:
One of the things that will never, in my opinion, be relevant to the game is the possibility of partial terrain squares: 50% plain, 50% mountain. On the other hand, I feel that mixed cover (50% forest, 50% pasture) will play a very important part in the system.
|
The mixed cover allows a 10,000 km2 are of land to be gradually cleared. For movement purposes I would take the least movement cost cover - units will tend to move through pasture land rather than forest.
The terrain I proposed (in the ecology thread!) was:
quote:
1. Landform. This is the physical shape of the land. The categories I propose are: flat, rolling, broken, massif. Visible on map.
2. Material. What the land is made of: soil, sand, rock. Visible on map, unless covered.
3. Altitude. In metres, rounded to 100.
4. Landcover. None, crops, pasture, scrub, forest, jungle. Visible on map.
5. Climate. As specified by Simon. Not visible on map.
6. Watertable. As far as my purposes are concerned, this affects low altitude flat land only, producing swamps which are visible.
Linear features can be superimposed. Natural ones:
6. Rivers. Described in more detail below.
7. Lakes.
Human generated linear features:
8. Roads.
9. Railroads.
10. Canals.
Other humans artifacts:
11. Urban areas.
|
There are two different kinds of movement modifiers which must be recorded in the XML file, it is not sufficient to have a single value.
The two types are:
Modifier
Over-riding value
For example, giving road a value of 0.5 doesn't mean that moving through a mountain takes the mountain tick value plus half a tick. It means that the mountain value is ignored, and the road value is used.
There is an even more complicating factor - if the terrain has a road and a railroad, which takes precedence?
Another factor is that just adding tick costs has problems. If a unit has a base tick cost on a road of, say 0.25, it is unlikely that the flat land tick cost will be 0.25 + some value. It is more likely to be 0.25 * some value, or possible 0.25 * some vale + some other value.
It is also necessary to provide for the possiblility of forbidden movement. Horses can't go in swamps, for example.
It is because of thinking about resolving these factors that I haven't done more on the coding in the last few days.
It is also wrong to assume that military movement is the only kind of movement that will ever exist. The movement system should be general, it may be applied to couriers, diplomats, traders, explorers, migrants or whatever. There is no special reason to suppose that only military units can move.
For this reason I feel the movement mechanics should be outside the military model.
In fact the movement AI coding has all done and tested and is in the model.physical package.
The part that isn't (yet) done, is the tick management.
What are required are a resolution of the following issues:
Determination of the terrain specification format for the XML file.
It is my strong view that all terrain related matters should be in one place. I don't like the idea of a military movement XML file, plus a non-military movement XML file, plus a map graphic specs XML file, plus an economics XML file, all for the same terrain.
I posted (in the map AI thread) some possiblities:
quote:
<terrain>
<name>plain</name>
<type>landform</type>
<movement>4 lightwheel 3</movement>
<image>flat.gif</image>
<other stuff>...</other stuff>
</terrain>
|
This now seems a little simplistic, and I would prefer to enlarge it somewhat.
code:
<terrain>
<name>plain</name>
<type>landform land</type>
<movement>4 lightwheel 3</movement>
<image>flat.gif</image>
<other stuff>...</other stuff>
</terrain>
<terrain>
<name>road</name>
<type>built land</type>
<movement>4 lightwheel 3</movement>
<movementrank>3</movementrank>
<north>roadnorth.gif</north>
<northeast>roadnortheast.gif</northeast>
<east>roadeast.gif</east>
<southeast>roadsoutheast.gif</southeast>
<south>roadsouth.gif</south>
<southwest>roadsouthwest.gif</southwest>
<west>roadwest.gif</west>
<northwest>roadnorthwest.gif</northwest>
<other stuff>...</other stuff>
</terrain>
This contains (however messily) all the information the is currently required. The type tag could also have, say, landform water in it for a sea or lake square. I have strong reservations about a default movement value - the assumption that all categories of unit other than those listed have the same modifier. I also have covered the additive multiplicative aspect here.
The "other stuff" is for economic data, or anything else that people want to add.
As far as the coding is concerned the requirements, as I see them, are as follows
1. Create a new terrain object to hold the data listed above. The part that looks up the movement factors is partially done (it doesn't have the movement rank bit in it yet). This should be done (by me) today.
2. Write a tick manager. As far as I am aware, movement is the only thing that is affected by ticks. All the other things such as economics or technology are at the end of a turn or a t the end of a game year. The tick manager's detailed operation I will outline in another post. I will do this today.
3. Modify the military model so every unit in a task force can return a unit category (foot, etc), by a method .
4. Write a class (outside the military model) that goes through all the units in a task force and determines, for a particular terrain combination, what the movement requirement will be (in ticks). This probably belongs in the model, and I am inclined to put it in the physical package to keep it with the bits that use it (Path.java in particular). I will also do this today.
5. Modify path to use this.
6. Provide a military order which gives a destination square, and a tick cost of moving there. I will (as outlined above) calculate this and pass it to the relevant task force, which should store it, and any successive movement orders it gets. The destination square will ALWAYS be one square from either the current square, or the last destination square sent - that is, the map AI will ensure that movement is one square at a time. The TF should know which is the current order, and set moveLeft (the amount of ticks required to complete the move) for the current move.
7. The task force should have a tickMove() method. This should do the following (and nothing more): subtract one from the moveLeft. If that reduces the moveLeft to zero or less, move the unit by teleportation to the destination square (changing the map square contents at the origin and destination squares). It should then get the next movement order and add the movement cost to the moveLeft. If it is still less than or equal to zero, move again, until the moveLeft is greater than zero, or there are no more orders (in whic case moveLeft should be set to zero).
8. For testing purposes it would be nice to have a
code:
public void testMove(MapSquare destination)
method which just teleported the unit to the square in question. In theory the existing move method or the existing setLocation methods should do this, but they don't. The move method has some direction calculations that don't belong there.
Oops, work calls.
Cheers
|
|
| |
|
|
|
LDiCesare
|
|
La Ferté sous Jouarre France
Jan 2001
time: 05:14
|
|
quote:
Originally posted by Gary Thomas
There are two different kinds of movement modifiers which must be recorded in the XML file, it is not sufficient to have a single value.
The two types are:
Modifier
Over-riding value
|
Yes. To me the only overriding value is "can't go there". Otherwise, the modifiers would be of two types: + or *, as you say.
quote:
Originally posted by Gary Thomas
It is my strong view that all terrain related matters should be in one place. I don't like the idea of a military movement XML file, plus a non-military movement XML file, plus a map graphic specs XML file, plus an economics XML file, all for the same terrain.
|
Agree.
quote:
Originally posted by Gary Thomas
I have strong reservations about a default movement value - the assumption that all categories of unit other than those listed have the same modifier.
|
And I am strongly against not having a default value. If we ever allow people to add their own unit types (say you want to make a mod where you have tunneling units -why would you have to go ob the ground or above it when you can burrow after all-), how do you allow that? People can't define a new kind of units, and they would have to fill in values for each and every terrain, which in xml is a little tedious. Also, if you want to change the cost of flat lands, you just need to change 1 figure ang get 60% of work done...
quote:
Originally posted by Gary Thomas
2. Write a tick manager. As far as I am aware, movement is the only thing that is affected by ticks. All the other things such as economics or technology are at the end of a turn or a t the end of a game year. The tick manager's detailed operation I will outline in another post. I will do this today.
|
Actually you should out that in game.controller. EncounterManager is already there rather than in military package. There's a MoveManager in game.model.military that should either move there too or disappear. I must check, but I think many bits I have already done.
quote:
Originally posted by Gary Thomas
3. Modify the military model so every unit in a task force can return a unit category (foot, etc), by a method .
|
Done.
quote:
Originally posted by Gary Thomas
6. Provide a military order which gives a destination square, and a tick cost of moving there. I will (as outlined above) calculate this and pass it to the relevant task force, which should store it, and any successive movement orders it gets. The destination square will ALWAYS be one square from either the current square, or the last destination square sent - that is, the map AI will ensure that movement is one square at a time. The TF should know which is the current order, and set moveLeft (the amount of ticks required to complete the move) for the current move.
|
ALL military orders have a destination square, which may be far apart. Computation of the tick cost is of no interest to the order. It is of interest to the TF and the movement manager. Military orders are stored in the unit for as long as they are not completed. This sets the next square along the road, so you don't have to repeat the target square but just tell nextTick in the tick manager. Do I understand?
quote:
Originally posted by Gary Thomas
7. The task force should have a tickMove() method. This should do the following (and nothing more): subtract one from the moveLeft. If that reduces the moveLeft to zero or less, move the unit by teleportation to the destination square (changing the map square contents at the origin and destination squares). It should then get the next movement order and add the movement cost to the moveLeft. If it is still less than or equal to zero, move again, until the moveLeft is greater than zero, or there are no more orders (in whic case moveLeft should be set to zero).
|
There is a method like that already in. I think I put it in the move(Square) method.
quote:
Originally posted by Gary Thomas
It is also wrong to assume that military movement is the only kind of movement that will ever exist. The movement system should be general, it may be applied to couriers, diplomats, traders, explorers, migrants or whatever. There is no special reason to suppose that only military units can move.
|
Are you a pacifist Gary, never attacked diplomats or settlers,  ? Although I agree that non military units move, I stress that they can and will be attacked, so they are no different to me than regular military units (except they have no attack values, poor they). You could even make taskforces with settlers (like I'll settle over there, but I want to protect my guys). So I don't think there should be units outside the military model, since arnies have to be able to attack them. In particular, sea units like transports are prime military targets, even though they may only carry diplomats or settlers.
I will check my code and try to send a version of where I currently am so that we don't do things twice and differently.
|
|
| |
|
|
|
Gary Thomas
|
|
New Zealand
Mar 2001
time: 17:14
|
|
quote:
Yes. To me the only overriding value is "can't go there". Otherwise, the modifiers would be of two types: + or *, as you say.
|
What about my example of a road over a mountain? Doesn't the road value override the mountain's value?
quote:
And I am strongly against not having a default value. If we ever allow people to add their own unit types (say you want to make a mod where you have tunneling units -why would you have to go ob the ground or above it when you can burrow after all-), how do you allow that? People can't define a new kind of units, and they would have to fill in values for each and every terrain, which in xml is a little tedious. Also, if you want to change the cost of flat lands, you just need to change 1 figure ang get 60% of work done...
|
You have convinced me...
quote:
ALL military orders have a destination square, which may be far apart. Computation of the tick cost is of no interest to the order. It is of interest to the TF and the movement manager. Military orders are stored in the unit for as long as they are not completed. This sets the next square along the road, so you don't have to repeat the target square but just tell nextTick in the tick manager. Do I understand?
|
The issue here is "how do they get the destination square?". If it is from the GUI, using the map AI, it will ALWAYS come as a sequence of consecutive, adjacent squares. In effect, an order to move to a square includes the route to take. It may, of course, be cancelled and replaced by a different route or destination later. The reason I have chosen that method is that (although it isn't implemented yet) I would expect people to set move through waypoints - as in go to that square by the quickest route, then go to this other square by the quickest route. However, in each case the route is displayed for the user so they can decide whether they want that route or not. Then the route is fixed. When giving a real life order to a military unit the route is always specified.
It would certainly be possible for each unit to call the map AI each time they want to move, but the overhead would be horrendous - I would expect each turn to take quite a bit of time. By its very nature the A* algorithm is calculation intensive, particularly if the destination is distant. In my system the map AI calculation is done once only.
When implemented, I expect the general AI to mimic the way the GUI does it, and calculate the route once only.
quote:
Are you a pacifist Gary, never attacked diplomats or settlers, ? Although I agree that non military units move, I stress that they can and will be attacked, so they are no different to me than regular military units (except they have no attack values, poor they). You could even make taskforces with settlers (like I'll settle over there, but I want to protect my guys). So I don't think there should be units outside the military model, since arnies have to be able to attack them. In particular, sea units like transports are prime military targets, even though they may only carry diplomats or settlers.
|
I was fooled by the term "military.model" - I guess it should be mobil units model. Anyway, I surrender.
However, I do think that the terrain movement calculations belong with where they are now, in the model.physical package. The offence/defence effect of terrain will have to be sorted out though.
The movement system (which was working) has stopped working. I will try and check that out later today.
Unfortunately I am having health problems - this has slowed me down somewhat. I thought I had recovered, but it does not seem to be the case.
Cheers
|
|
| |
|
|
|
LDiCesare
|
|
La Ferté sous Jouarre France
Jan 2001
time: 05:14
|
|
I had a few glitches with my computer yesterevening, so I couldn't send the code 
Road over mountain is usually still slower than road over plains, so that's why I'd rather get a multiplier. This doesn't work for changing impassable terrain into passable, though, so you have a point.
I checked my code, and here is how it works now:
I have a tickmanager that calls newTick() on all Army instances it knows. This newTick checks the current order destination and asks to move there.
The move() method manages the tick count and teleport when done.
My problem is to know which is the next square to move to, since I'd expect the player or AI to say "go to that square N squares away", and I'd store that in my order queue. When the order first becomes active, I should ask the pathfinding algo what is the path, store it, and then my UnitOrder class would have the target square plus a path (array, ArrayList or whatever) telling me each intermediate square to go through.
As for finding the terrain calculation, yes, keep it where it is.
A question is: How many times do you refresh orders? It may happen that you no longer can go a certain route because a huge army just stopped by there. To change the path, we should avoid recomputing it every turn just in case something chabged (which also can lead to going to and fro some point where the computation result changes).
I guess we can give the paths to an AI (slightly above tactical level?) which knows when an enemy enters a square through which we wanted to go, and decides whether to recompute a new route or just ignore it (either they're far away and may have moved when we get there, or the unit isn't significant enough it can't be crushed through).
That may not be D5, though.
|
|
| |
|
|
|
F_Smith
|
|
Austin, Tx 78728
May 1999
time: 05:14
|
|
Hi, ya'll:
Can I suggest a 'Transportation' object? I favor all 'GamePiece' type objects encapsulating a 'Transportation' object.
The 'Transportation' object would be where the 'movement' decisions should be made, I believe. It should evaluate the terrain it's crossing, and return a movement value.
And you absolutely would gain from the ability to add and remove 'Transportation' objects. Plus, you can have greater diversity of 'Transportation' objects, which would enhance gameplay significantly.
The player then can have a choice between 'riding horses' and 'war horses', 'basic truck' or 'armored personell carrier'. You can easily change a gamepiece from riding trucks to riding in airplanes.
Etc.
Just a suggestion.
P.S. -- wish I had more time to contribute. Life is just so nuts. Fortunately/unfortunately, Java is really becoming the 'hot new tech' that everyone has to have . . . I still lurk, occasionally, but that's about all I can do.
Ciao.
|
|
| |
|
|
|
Gary Thomas
|
|
New Zealand
Mar 2001
time: 17:14
|
|
quote:
Road over mountain is usually still slower than road over plains, so that's why I'd rather get a multiplier. This doesn't work for changing impassable terrain into passable, though, so you have a point.
|
Even this doesn't work. If the mountain has the base value and the road is a multiplier, how does the program know which is which without some distinguishing tag in the xml file? Also, although a road over a mountain is slower than a road over a plain, a road over a swamp is not slower, so a simple multiplier will not do. What is required is a careful model of what happens in real life, rather than just coding it in a convenient way.
This then leads me to an extension of the reasoning that resulted in the unit categories. How about terrain categories? Say: easy, moderate, difficult, very difficult and impassable. We would still need the option of having a road override the underlying terrain, but it would certainly simplify the combinations.
quote:
I checked my code, and here is how it works now:
I have a tickmanager that calls newTick() on all Army instances it knows. This newTick checks the current order destination and asks to move there.
The move() method manages the tick count and teleport when done.
|
Could you email me a copy of the tickManager (I have one also, based on a separate thread so it won't interfere with the GUI)?
quote:
My problem is to know which is the next square to move to, since I'd expect the player or AI to say "go to that square N squares away", and I'd store that in my order queue. When the order first becomes active, I should ask the pathfinding algo what is the path, store it, and then my UnitOrder class would have the target square plus a path (array, ArrayList or whatever) telling me each intermediate square to go through.
A question is: How many times do you refresh orders? It may happen that you no longer can go a certain route because a huge army just stopped by there. To change the path, we should avoid recomputing it every turn just in case something chabged (which also can lead to going to and fro some point where the computation result changes).
I guess we can give the paths to an AI (slightly above tactical level?) which knows when an enemy enters a square through which we wanted to go, and decides whether to recompute a new route or just ignore it (either they're far away and may have moved when we get there, or the unit isn't significant enough it can't be crushed through).
That may not be D5, though. |
The GUI and the AI will never say "go to a certain square". They will say "here are your orders: go to this adjacent square, then go to the next adjacent square, then..."
There are three distinct reasons for this approach.
The first is the sheer calculation burden of recalculating the path algorithm every time a unit passes a square boundary. This I feel will have a serious impact on game speed.
The second comment is an answer to the argument that, say, a large enemy unit will get in the way. When a unit is ordered to move and it encounteres the enemy, the movement orders should be cancelled. If the enemy is further away than the next square, the moving unit is unlikely to know it is there and so will push on regardless.
The third is my real reason for not allowing units to change there route in mid-move. It is infuriating when units don't do what they are told. In the system at present the human player can try various options until a suitable route is found, then the orders are sent to the unit. Then player always has the option of cancelling the orders before they are completed, but one of the GUI options I will provide is for the player to display any unit's remaining proposed path after the orders have been given. It can be changed if it becomes out of date. If the unit can change its mind on the way, I can only ask why? The terrain won't have changed, though I suppose something like a flooded river or destroyed bridge could occur. In this case the unit wioll just wait after sending a message to the owner, just as would happen in real life. Again, running into an unexpected enemy unit in the next square (100 kms away), the unit would either stop, attack, or retreat, depending on more global orders. It wouldn't recalculate its path to go round the enemy unit (a process that could easily lead it thousands of kms out of its way, around a mountain range or sea).
So, in answer to the question, how often do we recalculate the path? We do it only when the original orders are given. This has the advantage that it is already coded, it minimizes cpu loading, it is realistic, and it is simple.
Cheers
|
|
| |
|
|
|
Mark_Everson
|
|
Canton, MI
Jan 1970
time: 00:14
|
|
I don't think Never recalculating the path is a viable option in the long term. For one thing one order will be 'attack army X' which needs to be recalculated basically every turn if the target army isn't intercepted immediately. Otherwise the player would have to re-issue the order every turn, which would be maddening.
I, however, have no problem with one-time calculation being all that happens for now, pending other more-important things being implemented. IMO eventually, the player at their option should be able to determine recalculation of path frequency etc. (Maybe just a 'level' for overall military AI to use?)
BTW, I don't know if you realize it, but I don't plan to use just A*, but also intelligently-determined waypoints as described on the map AI page. This should help quite a bit for calculating paths of TFs that move far.
Last edited by Mark_Everson on 16-07-2001 at 05:10
|
|
| |
|
|
|
Gary Thomas
|
|
New Zealand
Mar 2001
time: 17:14
|
|
quote:
I don't think Never recalculating the path is a viable option in the long term. For one thing one order will be 'attack army X' which needs to be recalculated basically every turn if the target army isn't intercepted immediately. Otherwise the player would have to re-issue the order every turn, which would be maddening.
I, however, have no problem with one-time calculation being all that happens for now, pending other more-important things being implemented. IMO eventually, the player at their option should be able to determine recalculation of path frequency etc. (Maybe just a 'level' for overall military AI to use?)
|
I wasn't suggesting that there shouldn't be any recalculating of paths, just that it should be under control. On the other hand, how far away is the army to be chased by the "attack a certain army". I wouldn't think such an order is very realistic if the target army is more than one square away. In any case, the recalculation is only needed if the target army moves. And, in most circumstance I can't see how on earth the attacking army would know the other army had moved. Even with modern technology this is difficult.
The "one-time" calculation only exists because we have no AI to issue successive orders.
quote:
BTW, I don't know if you realize it, but I don't plan to use just A*, but also intelligently-determined waypoints as described on the map AI page. This should help quite a bit for calculating paths of TFs that move far.
|
I did realize that, but again, anything more than a very few squares will cover vast distances, more suitable for strategic movement than tactical.
Cheers
|
|
| |
|
|
|
LDiCesare
|
|
La Ferté sous Jouarre France
Jan 2001
time: 05:14
|
|
I believe the player wants to go far away, so they give orders to go far away at times (particularly for things like relocation of units to border cities, btw you could even automate that order, like the reloc button in Mastor Of Orion).
We can say that the UI and AI both catch the path and the orders given to the army is always one square away for the moment, so I don't need to worry with a list of squares in the order, but you manage it at the terrain/movement level. (I think that's what you meant from the beginning but I may be slow at times  )
As for tags for multiplier/overrider, yes. Difficulties for terrain, Gary can you elaborate?
The attack a certain army order can be given timeouts of some kinds (don't get farther than... or just don't run more than N turns). I think it is realistic in the sense that e.g. Darius sent armies to intercept Alexander a very long distance away from Persia to Cilicia. And, realistic or not, I think I would probably like to use such an order as a player.
Gary, I'll send you code this evening (my time) so next morning (or noon) yours.
|
|
| |
|
|
|
Gary Thomas
|
|
New Zealand
Mar 2001
time: 17:14
|
|
quote:
I believe the player wants to go far away, so they give orders to go far away at times (particularly for things like relocation of units to border cities, btw you could even automate that order, like the reloc button in Mastor Of Orion).
We can say that the UI and AI both catch the path and the orders given to the army is always one square away for the moment, so I don't need to worry with a list of squares in the order, but you manage it at the terrain/movement level.
|
You are quite right, that is what I meant, and as I said, it is actually all done. The reason that I called the path algorithm at that level is that a player can try out different paths before deciding on one. Then they "commit" the orders for that path. The easiest way of doing that is to just send the path that was just calculated as a series of one square moves. This will also make it easier (later!) to include waypoints, and further series of moves. Eventually I would expect standard routes to be available, so a unit could be referred to the "take the train from your base to the west coast" route in some simple fashion. The route, however, would be a series of one square steps.
quote:
The attack a certain army order can be given timeouts of some kinds (don't get farther than... or just don't run more than N turns). I think it is realistic in the sense that e.g. Darius sent armies to intercept Alexander a very long distance away from Persia to Cilicia. And, realistic or not, I think I would probably like to use such an order as a player.
|
There needs to be a distiction between a deployment or strategic movement order, and a tactical order. When Darius sent his armies, he didn't say "go and attack the 2nd Pahalanx unit". He probably said something like "go and look for that barbarian upstart and deal with him". Certainly the Persians would have had only vague information about the composition and position of Alexander's army.
quote:
Gary, I'll send you code this evening (my time) so next morning (or noon) yours.
|
Thanks.
I just tried to post a large post to a new thread on terrain generally, and lost the lot when my internet connection went down. I will try again later.
Cheers
|
|
| |
|
|
|
Gary Thomas
|
|
New Zealand
Mar 2001
time: 17:14
|
|
I have been thinking (deeply!) about movement, and have reached some conclusions.
First, there are certain aspects of movement which shouldn't be forgotten, but which probably do not need implementing for D5 (my permanent obsession...).
General observations for later
Movement kinds:
Basic foot movement is of three kinds: normal movement (taking all necessary baggage along), rapid (normal movement, but leaving baggage behind) and forced march (as fast as possible). These are options that should be provided eventually.
Foraging:
This is terrain dependant and will impact on movement. It should not be forgotten.
Railway movement:
There are more issues than simple movement - the trains must be available and time must be allowed for embarkation and debarkation (is there such a word?). Also, troops leaving a train will be disorganized. In any case I propose to put that aside for the moment (at least for D5), since railway movement didn't have a lot of impact on the Romans and Carthaginians.
Air movement
I do not feel that this is the same kind of movement as land ot sea. The dominating factor for air movement at the strategic level is range, not speed. After all in one tick (3 days) an aircraft capable of 200 km per hour (a pretty slow plane by today's standards) could cover 144 squares, if it had the endurance. This is about a third of the way around the Earth.
In fact, the longest distance airstrike that I am aware of was the B52 raid from Diego Garcia to Iraq during Desert Storm. The round trip still took less than one tick. Accordingly I feel that air movement should be treated differently from land or sea movement, and postponed for D5 purposes.
Road movement.
After a lot of discussion about which terrain dominates and how to deal with overriding terrain (like roads), and multiplicative versus additive models (or both) I reached the conclusion that roads are different in kind from other types of terrain.
The model I propose is that the presence of a road leading from one square to another is recorded, but the road isn't considered terrain in the normal sense, after all the only characteristic it has is direction.
Although it is true that there could be grades of road, we have to realize that on the scale used any visible road is a major highway indeed, in effect, the best kind of road avaialble to the current technology. So we don't lose anything by having only one kind of road.
What I suggest is that the standard of movement for any unit be the number of kilometers that the unit can travel, under ordinary conditions, in one day, on a road, in sustained travel. For an infantry unit 20 to 30 km would be reasonable.
All other terrain would then be a modification of this, depending on the category of unit (foot, horse, etc), including impassible as a possibility.
If a road is present, it will be used, and in particular the road movement rate will be used. The unit will cover 3*m/100 squares per tick (a tick being a tenth of a turn, that is near enough to 3 days, and a square being 100 km). The program will, when calculating movement, convert this to the number of ticks required to reach the next square, giving 100/(3*m) ticks per square.
Other terrain
If there is no road present, the cumulative effect of other terrain is used. For each category of unit and each terrain type (except road) there will be a multiplier. These multipliers will be, not surprisingly, multiplied together to get the cumulative effect of the actual terrain. The ticks per square value derived above for roads will then be multiplied by that value, giving the number of ticks to reach the next square.
In passing, for diagonal movement the value is multiplied by sqrt(2), and where terrain differs in square moved from and the square moved to, the average value (half of each, added together) of the two ticks per square value used.
This all gives a system with a number of advantages:
It is simple.
It is easy to relate to actual speed on the ground.
Modification for different movement conditions is easy.
It avoids any problem of how to specify in an XML which terrain "dominates".
It still allows a great deal of differentiation between units.
Some examples might be, for foot:
| Terrain | Multiplier |
| Flat | 1.5 |
| Swamp | 2 |
| Forest | 1.5 |
| Massif | 5 |
So the multiplier for the Everglades (flat, swamp, forest) is 1.5*2*1.5 = 4.5, for example.
Cheers
|
|
| |
|
|
|
Gary Thomas
|
|
New Zealand
Mar 2001
time: 17:14
|
|
quote:
Why should the multiplier for flat be 1.5??? It seems to me flat should be the standard, and so have a multiplier of 1. |
Perhaps "flat" is a misnomer. My standard is a formed road.
"Flat" includes ditches, gullies, streamlets, bogs, detours around outcrops, small valleys or dells, and so forth.
Try walking over open ground for any length of time and compare it with walking on a formed road. I will change the name "flat" to "open ground" if you like. I don't like "plain" because that has overtones of no intersecting features (like gullies or streams).
There can be a lot of impediment to walking before you get to the level of rolling downs.
Also, doing it this way leaves the way open for different type of "flat". Bear in mind that, over the scale of 100 km a heck of a lot of dissected territory will still qualify as flat. Potentially we could have "flat" subdivided into "billiard ball" (or some similar but more suitable term), "slightly bumpy", "dissected" or whatever, each with their own characteristics. The only one of these that could be used as standard is "billiard ball" which would probably be the same as "road".
The reason for picking formed road as the standard is:
- it is outside the system (as explained in my previous post)
- it is the fastest surface for travel (in our context anyway) so all multipliers are greater than 1
- it is almost invariant over different landforms. At some stage we might want to penalize roads over mountains in some way, but we can assume that even such roads will find the easiest route and my suggestion has simplicity in its favour
- we don't have to pick out some other special terrain type that doesn't otherwise stand out and label it
- we don't have to include roads in the XML because they are always 1, and roads, if they were put in the XML would have to be identified as something special with overriding properties
Cheers
|
|
| |
|
|
|
LDiCesare
|
|
La Ferté sous Jouarre France
Jan 2001
time: 05:14
|
|
Gary, your specs sound good.
Movement kinds: Yes. There is a multiplier in the code btw, but it's always 1 for now and probably for D5.
One point: What about multipliers for settled areas? As you said elsewhere, there are lots of small roads in settled areas, so that should affect movement. Automatically have road in settled squares?
On the same topic, making non-roads unpassable for wheeled units seems good, but wheeled units should be able to go on settled areas because of the small roads. If roads are not terrain, how do you specify that not-roaded is impassable and roaded can be passed through? We need a special tag for that I believe.
|
|
| |
|
|
|
Gary Thomas
|
|
New Zealand
Mar 2001
time: 17:14
|
|
quote:
One point: What about multipliers for settled areas? As you said elsewhere, there are lots of small roads in settled areas, so that should affect movement. Automatically have road in settled squares?
On the same topic, making non-roads unpassable for wheeled units seems good, but wheeled units should be able to go on settled areas because of the small roads. If roads are not terrain, how do you specify that not-roaded is impassable and roaded can be passed through? We need a special tag for that I believe. |
That is a really good point which I hadn't considered carefully enough. One way around it would be to give setteled land a multiplier of around 0.8, so flat, settled land has a multiplier of 1.2 (1.5*0.8), compared to 1.0 for a highway, or 1.5 for unroaded flat land. These parameters, of course, can be fine tuned later.
The comment on wheeled vehicles is correct. We need to indicate that the presence of certain types of terrain (settlement in this case) negates the impassible state of the underlying terrain for some units. It is something I would like to set aside for a few days while I think about it. There isn't any hurry for this one. Whatever we decide can be incorporated when it is ready.
In passing, this multiplier system removes my last objection to having default movement values in the XML. I never thought that default movement costs made much sense, but default multipliers certainly do.
Cheers
Last edited by Gary Thomas on 18-07-2001 at 23:21
|
|
| |
|
|
|
Gary Thomas
|
|
New Zealand
Mar 2001
time: 17:14
|
|
I am having trouble with two areas of the system, relating to movement.
The old system had movement operating by pressing an arrow key, then the unit moved, then you could move it again, or switch to another unit and move it.
This is, essentially, incompatible with simultaneous movement. The unit doesn't move until the end of the turn. I could make the arrow movement system work like the mouse system, with a red line showing the path, until you switch to another unit.
My other problem arises from the fact that military units are not differentiated by owner (civilization). Each map square has a list of units, in order of arrival in the square, regardless of the civilization they belong to.
For each civilization in the square I need a single representative unit image to display, and I also need the total force of that civilization in that square.
While I could write the code to work all this out it is quite complex and really belongs in the military model.
What I would like is a sort of super-task-force, which includes all the units in the square that belong to a particular civilization. The mechanism for this is already in the task force class. The map square would be altered to just have a list of theses larger units, one entry per civilization.
This will make drawing the map quite simple, and will even cope with the situation where there are more than one civilization in the square.
Cheers
|
|
| |
|
|
|
Gary Thomas
|
|
New Zealand
Mar 2001
time: 17:14
|
|
quote:
1. Yes, the arrow movement should just work like the mouse does. An arrow push just indicates a movement order for the unit in question, not actual movement. |
OK, I will implement it with a red line.
quote:
This could result in a lot of confusion for players since something that looked like a catapult one turn could look like an infantry unit the next (when it enters the square with another TF), and then return to looking like a catapult when it leaves... |
I think that you misunderstood my intent. There will be absolutely no difference, as far as a player is concerned, between the system I proposed and the one you outlined (symbol for the largest unit, power circle for the total). If a different unit becomes the largest unit, then the symbol will change in both systems.
My intent was to try and use the mechanism that is already present in the military model for:
1. Finding the symbol for the biggest unit.
2. Adding up the power values for units belonging to a civilization in a square.
It really does seem silly to duplicate all that code in the GUI, and that is what it appears that I will have to do. In addition, for every square, on every tick, and every time a player makes a move, I will have to go through the list of units in the square and sort them by civilization and figure out how many civilizations are present. Then, for each civilization I have to go through all the task forces it has present to find the biggest, and also to add up their power.
As I said, most of that is already in the military model, and I would rather use that code. It is always extremely dangerous to have two separate sections of code doing exactly the same thing. It is too easy for them to get out of step.
I did not intend that the meta-unit would appear in the TF panel or be used for any other purpose.
I suppose I could just assemble these task forces, but I am worried about the possible impact onother aspects of the system - those observers hanging around for example.
Cheers.
|
|
| |
|
|
|
The Cid
|
 |
Canada
Aug 2001
time: 00:14
|
|
Hi there,
I was reading the discussion on the effect of roads on different terrains, and I was wondering if the best approach would not be to separate the problem of terrain mobility into two variables: topography, and groundcover, or something similar.
As I see it, in a simplified way, movement is affected by the topography, by which I understand mountains and hills, things that you have to turn around from or that you have to climb and come down from... on the macroscale, roads would do little to improve that, although modern construction techniques can to some degree. This could be the first multiplier of movement.... to which itself would be multiplied by the second modifier: ground cover.
By ground cover I understand the immediate surface on which we walk... mud, swap, forest. Putting a road would set this multiplier to 1 (or even better depending on road technology) but it would still be multiplied by the topography one since going up and down hills still keeps the distance longer, and more tiresome, but having to cross forests in the mountain would be much more of a penalty than walking on a road.
So having roads affects the groundcover multiplier, but not the topograph multiplier.
|
|
| |
|
|
|
LDiCesare
|
|
La Ferté sous Jouarre France
Jan 2001
time: 05:14
|
|
Gary, we can use the TempTaskForce class just for that.
I could even refactor some code in EncounterManager to reuse it, I 'll see. I think I'll recompute it everytime because I don't want to store an additional pointer/collection in MapSquare. I'll code and send a new MapSquare class to you, probably tomorrow.
Cid, I agree with you, but Gary raised the point of unpassable terrain, so unless we provide an "infinite" multiplier it doesn't work well. Also, roads on plains are faster than plains (say x2), but on mountains they are much faster (say x4, total still slower than road on plains), so it may not be that simpler.
|
|
| |
All times are GMT. The time now is 05:14.
Apolyton Time is 00:14. |
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
|
|
|
|
|
|
10-07-2001 13:51
|