Announcement

Collapse
No announcement yet.

Military Model VI

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #46
    Yes, loading on a ship is terrific as you don't know what happens to units, elements, TFs...
    As far as I know in D4, ships fought in the first round of fight.
    I haven't tackled sea combat yet, and there is no model for it. It is fairly easy to prevent boats from fighting by putting them in reserve with a specific preferred order like "going to sea".
    Clash of Civilization team member
    (a civ-like game whose goal is low micromanagement and good AI)
    web site http://clash.apolyton.net/frame/index.shtml and forum here on apolyton)

    Comment


    • #47
      Hi gents:

      I'm not going to reply in too much detail or attempt to make much in the way of proposals since I don't want to slow down D7 work. But here are a few quickie responses.

      Originally posted by Gary Thomas
      Then the land units would fight like ships.
      I had envisioned a more sophisticated combat system, where naval and land fights in a square can be distinct, as Laurent has outlined. I believe the same general problem occurs in running fights even where land and naval TFs are distinct.

      Since the triremes move a lot faster than troops, moving out to sea them back will not cause them to lag behind.

      Soon (ha!) I will implement the notion I had in designing the command system. There is nothing to prevent a higher level command having a land and a sea element, and getting a single move order which will cause them to move together if they are able.
      I agree that the higher-level command capabilities you talk about is good stuff, and is of importance longer-term.

      On another tack, I am having a great deal of difficulty with loading units onto transport. The problem is that loading is done on a unit to unit basis. So, in general, a land task force will get split up among different sea task forces, perhaps going to different destinations, and perhaps with some left behind. With disastrous results.

      My preference is to restrict boarding to the task force level. That is, an entire task force boards another task force and thus stays together. There is nothing to stop someone splitting the land task force up if they want to, and putting it on different sea task forces. Splitting up the sea task force will automatically also split up any land task force it is carrying.
      That sounds good to me! Laurent?

      [/QUOTE] (Laurent said) As far as I know in D4, ships fought in the first round of fight.[/QUOTE]

      IIRC ships fought in all rounds, but got a bonus in the first. The idea was to give a mobility bonus to the side that had the ships. The biggest factor this was supposed to simulate is that if a landing of troops was attempted that the naval forces of an opponent could try to contest it before the troops disembarked. This was a very simple early implementation, and I'm sure well do a lot better this time!


      When looking at the D4 manual I came across this oldie:

      "Currently, moving an attacking force costs $2 per point of Military Power, and a defending force $1. " The cost was meant to represent organizational costs that go beyond supplies, and also weapon/ammunition destruction/depletion. We should include some notion of this sort of thing eventually in the supply model. Perhaps a cash cost and also an increased supply cost for combat? Just a discussion starter, meant more to indicate a discussion point after D7.
      Project Lead for The Clash of Civilizations
      A Unique civ-like game that will feature low micromanagement, great AI, and a Detailed Government model including internal power struggles. Demo 8 available Now! (go to D8 thread at top of forum).
      Check it out at the Clash Web Site and Forum right here at Apolyton!

      Comment


      • #48
        On another tack, I am having a great deal of difficulty with loading units onto transport. The problem is that loading is done on a unit to unit basis. So, in general, a land task force will get split up among different sea task forces, perhaps going to different destinations, and perhaps with some left behind. With disastrous results.

        My preference is to restrict boarding to the task force level. That is, an entire task force boards another task force and thus stays together. There is nothing to stop someone splitting the land task force up if they want to, and putting it on different sea task forces. Splitting up the sea task force will automatically also split up any land task force it is carrying.
        That seems OK from a Command and UI point of view.
        Note that soon (probably D8) I will have to redo the boarding code as it now considers an element as a measuer of size. An element place on a ship should be based on the number of men in it times a scale factor (like ! for infantry, 3 for cavalry and 10 for elephants). This goes along with the single element with a number of men-code refactoring. This leads to long-term problems as, right now, a trireme (which we all know should be replaced by a round ship for transporting troops) has enough elements to carry any unit, but...
        Now a funny situation: You have a 1000-man unit and 2 transport units able to carry 500 men each. Can you board them? From a TF point of view, you should, as everyone has the place aboard. Now what if you split the transport TF at sea? How do you split the unit? Having a land unit on a single sea unit will probaby waste space but avoid bugs. Thus I'd rather stick with it at least short term.
        Otherwise, I'd have to have weird OrphanUnits who are created by splitting of their unit and who remember who they used to be... or I kill the buggers on all ships but one.

        About single element with variable number of men in it: How do we handle morale? Right now elements flee as a whole, and the unit flees as a result of all their elements having fled. The same behaviour with a single (bigger) element will lead to more random fights as people will flee en masse, unless the model proposes a better way to handle morale failure. I can for example give a current morale value to the unit and each time a morale check is required increment the current morale number of the unit. When it reaches a limit, the whole unit would break. I can also make a fraction of the manpower flee, but I don't think it right to have a few persons flee in an element while others continue fighting.
        Clash of Civilization team member
        (a civ-like game whose goal is low micromanagement and good AI)
        web site http://clash.apolyton.net/frame/index.shtml and forum here on apolyton)

        Comment


        • #49
          That seems OK from a Command and UI point of view.
          It is simple to code - I will assume that each task force can carry exactly one task force. I will also make a carrying task force unable to be split until it has unloaded. This will work until we have sea combat, and I can think about the next step then.

          Note that soon (probably D8) I will have to redo the boarding code as it now considers an element as a measuer of size. An element place on a ship should be based on the number of men in it times a scale factor (like ! for infantry, 3 for cavalry and 10 for elephants). This goes along with the single element with a number of men-code refactoring.
          I am fully in favour of this.

          This leads to long-term problems as, right now, a trireme (which we all know should be replaced by a round ship for transporting troops) has enough elements to carry any unit, but...
          Now a funny situation: You have a 1000-man unit and 2 transport units able to carry 500 men each. Can you board them? From a TF point of view, you should, as everyone has the place aboard. Now what if you split the transport TF at sea? How do you split the unit?
          Just say you can't do it.

          Having a land unit on a single sea unit will probaby waste space but avoid bugs. Thus I'd rather stick with it at least short term.
          I am quite sure that the contortions necessary for this will cause bugs, not avoid them.

          Otherwise, I'd have to have weird OrphanUnits who are created by splitting of their unit and who remember who they used to be... or I kill the buggers on all ships but one.
          As I said, don't let them split.

          [quote]About single element with variable number of men in it: How do we handle morale? Right now elements flee as a whole, and the unit flees as a result of all their elements having fled. The same behaviour with a single (bigger) element will lead to more random fights as people will flee en masse, unless the model proposes a better way to handle morale failure.[quote] Use the number of survivors as a morale effect. They flee when they have a certain proportion killed. Higher morale units would have a higher proportion of sustainable losses, right up to Leonidas whose morale could not be improved upon.

          I can for example give a current morale value to the unit and each time a morale check is required increment the current morale number of the unit. When it reaches a limit, the whole unit would break. I can also make a fraction of the manpower flee, but I don't think it right to have a few persons flee in an element while others continue fighting.
          See above.

          Cheers

          Comment


          • #50
            Do you mean I must know I cannot split the TF? I would have to look at every unit in the command everytime I look at a Command for it to split, and check if it is not perchance carrying part of the same unit. I hope the splitting/removing from a command code is centralized in a single method then, but somehow doubt it. That also means I must be able to report an error message to the player saying he can't split his TF because it cannot split unit XXX between the would-be TF's. That means an error mechanism (probably an Exception) which must be thrown by the Command objects when splitting/changing father command. This will have to be caught by the UI to show an explanation somewhere, and the AI in case it tries to act silly.
            Clash of Civilization team member
            (a civ-like game whose goal is low micromanagement and good AI)
            web site http://clash.apolyton.net/frame/index.shtml and forum here on apolyton)

            Comment


            • #51
              You can only split a command by clicking on on one of "assign unit to new TF", "assign unit to selected TF", "merge all", or "disband TF" in the task force popup.

              None of these choices will appear in the Task Force popup if the selected TF is carrying a TF or being carried. So you actually CAN'T do anything illegal.

              Cheers

              Comment


              • #52
                I don't like the idea much. Preventing the UI from splitting is, IMO, a patch. How do I make sure the AI doesn't try the same things without going thru the UI? How do I warn it the splitting didn't work?
                From a player point of view, why shouldn't a player be allowed to split a fleet at sea? Agreed, knowing which land unit goes where may be difficult. Probably I'd want to split a sea TF by splitting the land units and the non-transport/empty ships.
                Clash of Civilization team member
                (a civ-like game whose goal is low micromanagement and good AI)
                web site http://clash.apolyton.net/frame/index.shtml and forum here on apolyton)

                Comment


                • #53
                  Can we just use the TF rearrangement UI when a loaded naval TF is at sea? I am not up on the most recent restrictions Gary has put in but here's a proposal for how the UI could work in the near-term. We can work on an ideal solution for the long-term later. However I think my idea may be useful in the long term also.

                  Lets say I have a 3-transport TF at sea, carrying a 3-unit TF, and I want to split off one transport with one unit and send it elsewhere. What I do is a synthetic unloading. In the TF window it looks like my army units are sitting in the sea. Perhaps they have some kind of red symbol that indicates if they're not 'embarked' again that they will be lost. Now I can use all the normal TF-rearrangement options to change the land and sea TFs to what I want. Then finally I load the new land TFs on the new sea TFs and voila! This allows for detailed player control, if they want it. The AI, when up to it, could use tis approach also.
                  Project Lead for The Clash of Civilizations
                  A Unique civ-like game that will feature low micromanagement, great AI, and a Detailed Government model including internal power struggles. Demo 8 available Now! (go to D8 thread at top of forum).
                  Check it out at the Clash Web Site and Forum right here at Apolyton!

                  Comment


                  • #54
                    D7 retreat problems

                    Gary Said (from an email re D7):
                    Combat still behaves very oddly, with, I suspect, too many retreats, and
                    often for no good reason.

                    This is how it seems to happen: you are following a smaller enemy unit. You
                    move ito its square from the square it last moved from, and beat it up. It
                    retreats to the last square it was in, that is, the square you just left. So
                    the two units swap placfes. The swapping does not happen in movement, but in
                    combat.

                    In cases where you try to move onto a square with an enemy in it, and fail,
                    theer are two possibilities. Either you did move and then retreated from
                    combat back to your previous square, or, alternatively, the enemy was trying
                    to move into your square, then you lost the race for the border, so your
                    orders were cancelled, the enemy entered your square, lost the battle and
                    retreated back to its previous square. In both cases it looks as though you
                    did not move.

                    One solution is to prevent retreat on the first turn in a square.


                    Getting the retreats squared away is definitely a top issue. I take responsibility for promoting it but its not ready for prime time, and seriously reduces the playing experience. I still think it is somewhat realistic, but in a game, it needs to also be fun, and it ain't right now. My preferred solution even before this was having a TF look at the odds Prior to moving, and if its attack would be suicide to switch orders. That was thought to be impractical short-term in our discussion of the issue on the forum.

                    I think one possible quick fix would be to put in a global that gives the probability of a TF retreating when it would otherwise like to. Effectively now that parameter seems to be 100% per round of fight, or maybe its just 100% at the start of fights? I think it could well be that with that chance in the 20-40% range it might work ok. Having to chase a unit occasionally would not be a big deal IMO, its when it happens continuously that it's mind-numbing.

                    Another quick fix that I think we should use longer-term is to Charge any Retreating TF for the ticks it uses in the withdrawal. That would both be realistic, and lead to some interesting pursuit dynamics. Details TBD. I don't know if this is something that can be done quickly for D7. If it is, I'd be in favor of implementing it. In conjunction with the reduced probability of flight I think it would give us an interesting and unique system that as an added bonus doesn't annoy the player
                    Project Lead for The Clash of Civilizations
                    A Unique civ-like game that will feature low micromanagement, great AI, and a Detailed Government model including internal power struggles. Demo 8 available Now! (go to D8 thread at top of forum).
                    Check it out at the Clash Web Site and Forum right here at Apolyton!

                    Comment


                    • #55
                      I don't like the idea much. Preventing the UI from splitting is, IMO, a patch. How do I make sure the AI doesn't try the same things without going thru the UI? How do I warn it the splitting didn't work?
                      When we have an AI I will answer that question.

                      From a player point of view, why shouldn't a player be allowed to split a fleet at sea?
                      One reason is that it has never happened to a transporting fleet in the entire history of the human race. To me that is sufficient reason.

                      Agreed, knowing which land unit goes where may be difficult. Probably I'd want to split a sea TF by splitting the land units and the non-transport/empty ships.
                      I have no problem with allowing sea units that are not carrying land units to be split off and see no problem with the implementation.

                      Cheers

                      Comment


                      • #56
                        Another quick fix that I think we should use longer-term is to Charge any Retreating TF for the ticks it uses in the withdrawal. That would both be realistic, and lead to some interesting pursuit dynamics. Details TBD. I don't know if this is something that can be done quickly for D7. If it is, I'd be in favor of implementing it.
                        It is already done. Retreat is done through an order, thus it takes some ticks to get done.
                        Cancelling orders is there to allow pickets, so it should stay.
                        The simplest thing is to allow retreat to fail: It is currently a low probability per round of fight, and 100% at the end of each tick. At the end of a tick, this means new move orders are issued. Giving less than 100% (I think 10% probably is best - consider there are 10 ticks per turn) would make things better, but swaps would still happen.
                        If it is possible to delay an order by replacing it with itelf (hopefully losing all ticks of movement accrued), then I can prevent a unit from fleeing to the square its opponent comes from or wants to go to. That would be better I think.

                        Reordering units in TFs at sea:
                        I wouldn't allow reordering of land units among boats. That is totally unrealistic: Army 1 jumps to water while army2 moves in their ship, then army3 moves to army2 previous ship and army1 swims to soak up on army3 previous ship?
                        TF-level boarding can be done, but I will throw an Exception of sort (an Error if needs be) if someone wants to split a TF which has somebody boarded on it or which is boarded by someone. Just to be sure.
                        Clash of Civilization team member
                        (a civ-like game whose goal is low micromanagement and good AI)
                        web site http://clash.apolyton.net/frame/index.shtml and forum here on apolyton)

                        Comment


                        • #57
                          Originally posted by LDiCesare
                          The simplest thing is to allow retreat to fail: It is currently a low probability per round of fight, and 100% at the end of each tick. At the end of a tick, this means new move orders are issued. Giving less than 100% (I think 10% probably is best - consider there are 10 ticks per turn) would make things better, but swaps would still happen.
                          If it is possible to delay an order by replacing it with itelf (hopefully losing all ticks of movement accrued), then I can prevent a unit from fleeing to the square its opponent comes from or wants to go to. That would be better I think.
                          That sounds ok to me

                          Reordering units in TFs at sea:
                          I wouldn't allow reordering of land units among boats. That is totally unrealistic (snip)
                          It wasn't meant to be realistic, it was meant to be fun and relatively easy for the player and in the code.

                          Gary said:
                          One reason is that it has never happened to a transporting fleet in the entire history of the human race.
                          Wow, you have knowledge of every naval transport operation ever in history, I'm Impressed . I agree that switching around units on fleets happens way too often in civ. And also that trasport fleets generally throughout history only move an attacking army something like 250 km or less. Nonetheless, I think long-term the system needs to be flexible. But we can put off a detailed handling of that for a bit due to other pressing issues.

                          Gary's by-TF method seems to me quite adequate for D7 or D7.1
                          Project Lead for The Clash of Civilizations
                          A Unique civ-like game that will feature low micromanagement, great AI, and a Detailed Government model including internal power struggles. Demo 8 available Now! (go to D8 thread at top of forum).
                          Check it out at the Clash Web Site and Forum right here at Apolyton!

                          Comment


                          • #58
                            I am going to check the retreat bugs tonight. I don't know about the TF boarding. I can provide TF level API for the GUI to be easier to code. I won't refactor the code beneath yet because that will have to wait for the element/manpower refactoring, which I will do for D8 as it may take a bit of time.
                            Clash of Civilization team member
                            (a civ-like game whose goal is low micromanagement and good AI)
                            web site http://clash.apolyton.net/frame/index.shtml and forum here on apolyton)

                            Comment


                            • #59
                              I will do this (after D7 is released) - I have already figured out how to do it and it does not affect the game.military code at all.

                              Cheers

                              Comment


                              • #60
                                Manpower

                                I changed the manpower management in units. Now 1 element in the xml file describes the stats for one man. In turn, the number of elements in a unit is actually the number of men. Thus, for instance, a horde which was made of 8 warriors + 2 cavalry skirmishers is now made of 4000 warriors + 1000 cavalry skirmishers. The difference is 1 warrior used to say it was made of 500 men, now it no longer does. That doesn't change much the outside appearance of a Unit, but it raises some points regarding combat and particularly morale.
                                Previously, elements morale was checked per-element, and if an element fled, the unit lost part of its manpower for the fight. For instance, the horde could lose 1 warrior, thus 500 men, on a bad morale check. Now, the same code would make all the 4000 warriors to flee as they are coded as a single element with a number of 4000. Needless to say, 4000 morale checks are totally out of hte question.
                                The current morale system doesn't fit, because the random factor affects much greater numbers and you may end up with units made of 999 of 1 element and 1 of one other, and you could have situations where one single man would stand while the other 999 would flee.
                                Gary suggested in a mail a breakup number. For instance, your unit has 1000 men and will flee if it falls below 500.

                                The current morale model is rather complicated. The code surely is. Refer to the Military Coding thread to see what is indeed implemented.
                                We can probably simplify the whole morale stuff along Gary's lines:
                                Checks would be:
                                1)Appraisal of strengths, flee based on odds and current orders (independent of actual morale).
                                2)At the end of each round of fight, check per unit the number of casualties. If the unit is below a threshold, it tries to flee.
                                Odds to manage fleeing are always less than 100%, I don't change that.
                                The problem with 2) is that, right now units don't heal. Thus, a unit which fled once will always flee. This can be mended by adding unit healing. This healing of unit is, however, a problem, as it should require men and production/services/food for the unit to heal. Units probably don't heal in foreign territory. Healing units could be taken from the existing military econ orders to start with, but that could lead to wounded units being fully replenished after a battle, at a cost to the economy. The player may or may not want to spend huge sums on one given turn to heal a victorious army he will disband the next turn.
                                Considering the little response there was to my previous healing posts, I will end up doing this if noone says anything against it. We will then see if a separate heal/upgrade econ order is needed to give the player more control over his armies.
                                Clash of Civilization team member
                                (a civ-like game whose goal is low micromanagement and good AI)
                                web site http://clash.apolyton.net/frame/index.shtml and forum here on apolyton)

                                Comment

                                Working...
                                X