Jump to content

Micfild

Balancing Advisors
  • Posts

    66
  • Joined

  • Last visited

Posts posted by Micfild

  1. I agree with the overall sentiment that mobility is the main advantage of cavalry units and, as such, should come at a higher cost than just resources. I can accept them being mobile and having high damage (since a charge mechanic isn't available yet). The cost would be reduced durability. An overall reduction of Hitpoints and low armor values. This would emphasize they role as skirmishers and reduced their value as main combat units. I would also agree with a reduction of their ability to capture buildings, as they should be viewed as raiders, not a domination force (which would be the infantry's role).

    ===================================

    Using base melee infantry units as baseline (100HP ; 5 armor) i would suggest that melee cav units have 100HP or less ; 3 armor or less.

    As for the ranged cavalry, the same HP and armor stats of it's infantry counterparts (since then they would have the double advantage of being mobile and ranged).

    ===================================

    It would basically treat mobility as a higher valued attribute, the same way "Range" is treated.

    --------------------------------

    TL;DR Keep cost, damage and mobility. Reduce durability stats to get in line or below their infantry counterparts.

  2. Hi. Quick question. Is it possible to upscale unit models by altering some property in a .xml file somewhere or only by changing the model itself? I've searched the forum, but haven't been to find an answer to this.

    And just in case i've asked the wrong question, what i want is to be able to keep the current proportions of a unit, but make it larger, hopefully by just simply altering a multiplier in a .xml file.

    Thanks in advance!

  3. 50 minutes ago, Stan` said:

    f it was split I believe it could be a bit smaller. It would be a fun experiment to see how much space the civs really take.

    The civs' files are a bit spread out since it includes auras and other things. But if you take the simulation folder alone (with gaia and all the civs) it has only 4,22 MB of files with 8,24 MB of occupied disk space. Most of the size of the public folder comes from the Art folder (2,53 GB), Audio folder (177 MB) and the Maps folder (341 MB). The rest only weighs 31 MB.

    Overall, scripts and XML files are really light. :)

    • Like 1
  4. 52 minutes ago, Yekaterina said:

    Ranged are now the main damage output, but if ranged units deal less damage than melee then no-one will use ranged units..

    I don't agree with this statement. The benefits of ranged troops goes beyond their raw damage as they have the ability to attack from behind fortifications, focus fire important units and are less likely to die in combat, maintaining their experience and leveling up more easily. Of course when i say lower than melee i don't mean rock bottom. Let's say if a spearmen does 5.5 damage per second (dps) then i would like an archer to deal around 3.8 dps while a slinger would deal 5 dps and a javelineer 5.5 dps.

    I am currently toying with a mod that implement these changes (including the hp ones) and some more experimental ones, and in my tests those values were the ones that were feeling more balanced. Of course its still work in progress and subject to change, but my point is we really shouldn't underestimate the power of range.

  5. I love this idea. It's great to have a compiled list of suggestions.

    In my case i would like to support changing "Damage values of ranged compared to melee". 

    As for what should change, i think the damage of ranged units should be lower than melee units (not by much) mainly do to balancing concerns. Since ranged units can shoot from afar, they can shoot first, and all at the same time or a the same target. Melee units need to get close and often spend more time just maneuvering through the battlefield than actually fighting. This effect is mitigated a little by the lack of precision with increased distance, but in large battles the "missed" shot mostly still lands, just not on the intended target, negating the damage "reduction" granted by the lack of precision.

    ==========================

    Personaly i would also like to change the hp values of melee units to be the same as (or close to) ranged units. This way, the main difference in survivability between the two would be due to armor difference and faction specific bonuses/techs. It would also pair nicely with the damage value changes proposed above.

    And last, but not least, reduce the armor values of Pikemen. I feel they are a bit too much the way they are now. With normal spearmen being 5/5 i would like to se pikes at 7/7 or even 8/6, considering that the large pike makes it harder to wear a sizeble shield for cover.

    • Like 3
  6. Thanks @Stan`. I think i understand a few points of your reply, but not all of it. If possible, could you clarify a few things:

    1 - It seems that the moddable part of 0AD is treated (in some ways) as a mod itself (called empires_ascendant)  <-- is this correct?

    2 - If 1 is true, then it means that, much like mods, this one could be changed more frequently, and updated on mod.io

    3 - Empires_ascendant is a rather large mod (a few gigabytes in fact) and the only way to change parts of it would be to download and replace the entire thing (can't just change a few files)

    4 - " We can't maintain the current version and the next one at the same time. " <--> If i'm understanding this corrently, it means that current versions of 0AD in phabricator  (A26) have new features (like acceleration) that changes the game and most of it's .xml files. This way, patches for A25 couldn't be easily tested in Phab without messing with A26 stuff. Therefore it would be necessary to have two projects in Phab, one for A26 and one for A25, and that is just not feasible.

    If that is the case, then can't we test tentative patches as a simple mod and when eveything is set, officialy transmit them to the Empires_Ascendant "mod". It sounds a little vague because i don't have enough knowledge to know what is possible and what isn't, but if we can use a program, like the installer, to officialy replace files in Empires_Ascedant, it would make things simpler.

    This way, the workflow would be something like this:

    Tentative patch A25.01 --> as a simple mod (or .pyromod) file, like any other mods.

    Balance team downloads the mod, tests it and have discussions.

             - If the changes are insufficient, a new mod (A25.02) is created and the process is repeated)

             -If the changes are accepted then it can be implemented.

    After a final version is approved, an official patch (or something) can be downloaded to replace the original files in the Empires_Ascendant mod for the new ones, but only those that were changed (like a copy and replace).

    =======================================================

    I don't know if i got everything right or if this is even realistic, but if possible, it might be close to a good solution to this problem.

    • Like 2
  7. 3 hours ago, Yekaterina said:

    Unique features = new imbalances

    That is true, but imbalances are a natural part of the process, so it is unavoidable in some ways. The biggest issue, in my opinion, isn't that the game can become imbalanced, but that once it does, patches and fixes will only roll out 6-8months later.

    I'm somewhat aware of the hurdles of changing compiled code, but still can't understand why smaller changes (like numerical tweaks in the template .xml files) can't be updated more regularly, especially since theses changes can be easily modded. This way we wouldn't be so afraid of imbalances, since they could be fixed after a few weeks of discussion.

    • Like 3
  8. On 06/12/2021 at 6:29 PM, LetswaveaBook said:

    Team bonusses do not affect any player that is in p1.

    That is actually a great sugestion. I was thinking about giving each civ a specific tech or unit in p2 that would make it more desirable (like carthage has it's mercs), but this actually does the trick. Although most bonuses aren't really useful in p1 anyway, so this will disproportionaly affect those civs which have bonuses that do play a role in p1 (like the ptolomies).

    On 06/12/2021 at 6:29 PM, LetswaveaBook said:

    A counter argument is that it reduces diversity,

    it does only in p1, so not really. Delaying a tech or bonus isn't an actual reduction in diversity. What it does do is balance the playing field in p1, when most civs only have their base units and buildings.  This way p2 becomes more interesting, instead of being just a stepping stone to p3.

    --------------------------------------------------------------------------//-------------------------------------------------------------------

    Another sugestion i would make is to give a small experience boost to all units trained in later phases. Not enough to advance them in level in p2, but significant to the point where it might play a role (so like 50 to 75 exp in p2 and full level 2 in p3). Since it won't affect previously built units, it won't encourage mass production and then advancenment. On the other hand, it will make the small experience gained by garrisoning barracks more usefulness, since the gap it has to fill is smaller.

    But this is just an idea.

     

     

  9. 7 hours ago, Micfild said:

    But what it seems to make the most difference, for me, is the Friction aura

    @alre, Further testing revealed that the impact of the Friction aura in avoiding overlaping isn't as significant as i thought. I ran you mod without them and it felt almost the same (units were a bit faster though, as expected).

    It kind of reached a level of clumping that i'm ok with. It wasn't as eye catching as the base game (I still have to test it with siege though).

    Thanks

  10. 7 hours ago, alre said:

    How it would work in previous alphas is this: if some units is going to move in top of another, the engine stops it, and queues a new, equal, move order to it. As a result, units would stop for a brief moment, and then start moving again, this was described as "unit bumping on each other", all the bumps slowed down mobs nex to chockepoints or when manouvring, and all the move orders were heavy on the pathfinder.

    I remember that part of A24. A25 pushing mechanics really smoothed things quite a bit, which was great. Unfortualy it came with a cost, which is not so great. But at least it can be fixed (eventualy).

     

    7 hours ago, alre said:

    The way parameters in pathfinder.xml affect pushing is a bit counterintuitive, and in fact, in my mod for reducing unit overlapping, I actually reduced pushing radius. You can find it here.

    I checked you mod and your pathfinder values are indeed smaller than the base game. But what it seems to make the most difference, for me, is the Friction aura. It seems that slower units have a more difficult time overlaping. If i'm not mistaken, in another post by @nani, there was a discussion about how farm animals seem to overlap much less than other units, even with the push mechanics. Since they have the same "Default" parameters most other units in the game, it might be because of their speed (which is very slow).

     

    7 hours ago, alre said:

    also check Res Gestae mod, wich has another take still on reducing overlapping.

    Yeah, that mod also has a great AI, Catilina. It does 3-4 minute cav rushes and booms to full pop in 13 minutes. I went as far as extracting just the AI (and the pathfinder file + friction aura) just to play against it in the base game.

    • Like 2
  11. Some context:

    I've been messing around with the pathfinder.xml file in an attempt to stop units clumping too much when in battle or marching or gathering resources. But it didn't matter which variable i changed, the best result i could get was that units would overlap and then be pushed (rather slowly) away. If i make pushing zones too big, then those units can't hold formations properly.

    Then it occured to me that i might be going in the wrong way, and a question was formed: Why can units overlap in the first place? They don't overlap with buildings (as far as i know) or with terrain features, so why can they do it to themselves?

    Is this a feature? An unintended consequense of some obscure code?A bug that has yet to be fixed? Or something else entirely?

     

    Thanks and have a nice day!

  12. On personal experience, attack move seems most effective on small skirmishes, while Violent stance and Hold seems to work better for me on large army clashes. As a disclosure, the majority of my game are against the A.I. , so i don't know how much theses strategies would compare vs human players.

    I've also been trying formations a bit more, having good results with spartan CS hoplite in Phalanx (due to the tight formation). They don't seem to break rank that easily if i use Hold + Violent stance, instead of attack-move.

  13. 2 hours ago, Lion.Kanzen said:

    Without bonuses it makes no sense to have formations

    I mean, they don't help a lot during battles, but i find them pretty useful before one, to get my melee troops in the front and archers in the back before i attack-move. Otherwise my ranged troops tend to be in the front, since they are faster.

    • Like 2
  14. Ty Wow. Well, in this case i do agree with your previous statement. A decision should be made to either go Hard battalions or no battalions. The current builds seem to favor no battalion, since it would be the easiest to implement, considering the framework already in place. The current formation system seems more useful as a positioning tool rather than a marching or fighting tool. Also eveytime i set a group in formation and send them to collect resources, some of those units just remain idle. This doesn't happen when i take them out of formation (so i tend to set Formation Control to Walk/Patrol only, since this is where it seems more useful).

    One of the problems with hard battalions is how they would interact with the fact that militiary units can also build and collect resources. One idea might be to make battalions a champion exclusive feature (like they have propper military training and such). This way we can have both systems and they won't mess with each other.

    In any case, ty for the explanation Wow.

    • Like 1
    • Thanks 1
  15. 13 minutes ago, wowgetoffyourcellphone said:

    It's why soft battalions just will not work. It's either hard battalions or no battalions.

    I would like to understant this distinction. What is the general idea behind a "soft" battalion and a "hard" battalion? Is the current formation system considered a form of soft battalion or no battalion?

    • Thanks 1
  16. 1 hour ago, Grapjas said:

    I think you meant this positively(?)

    Yeah, it was a positive remark.

     

    1 hour ago, Grapjas said:

    There is a new unit at the fort called 'ammo cart'

    I knew about it, but it comes so late that i kind of forgot about it. Thank you, i'll test it out.

    • Like 1
  17. 9 hours ago, Dizaka said:

    A nice anti-snowballing mechanic to make sure players don't get penalized for forgetting a house early on, etc.

    It might help early one, but i think it might break the late game, because of the batch mechanic. In Age games you'll only get one unit, but in 0AD you could be pop capped, start Batching 20 something units (which take a long time) and when your army gets killed, its instantly back.

×
×
  • Create New...