1. We have added a Gift Upgrades feature that allows you to gift an account upgrade to another member, just in time for the holiday season. You can see the gift option when going to the Account Upgrades screen, or on any user profile screen.
    Dismiss Notice

M:C Medieval Combat

Discussion in 'Civ4Col - Medieval: Conquests' started by Kailric, Mar 7, 2015.

  1. Nightinggale

    Nightinggale Chieftain Supporter

    Joined:
    Feb 2, 2009
    Messages:
    3,986
    I think the weapons/armor production needs an overhaul like altEquipment was changed into something more vanilla like. One profession for each yield production sounds right, possibly using subprofessions to group all armorsmith professions.

    However it isn't top priority right now. We better aim for next release instead and I don't think we should change anything regarding combat before next release.
     
  2. orlanth

    orlanth Storm God. Yarr!

    Joined:
    Nov 17, 2001
    Messages:
    1,759
    Hear hear :king: I definitely agree with each of these ideas. :viking:

    The idea of Damage Types would be particularly awesome to enable some actual military strategy - an interesting rock/paper/scissors mechanic is always a lot more fun than just seeing who can stacking up the most generic Civ4 "plus x to Strength!" promos. :lol: In general, most of these kinds of modifiers would likely be better and more flexible for modding when handled through PromotionsInfos rather than UnitInfos; that way the CivEffects system could be leveraged to apply effects to whatever Units/UnitClasses are desired. I would even say that Equipment (especially at least Armors) would fit better if simplified into a Promotion that could be applied to units (as was done successfully in Civ4 mods like Fall From Heaven, Planetfall, Dune Wars and Fall Further), thus avoiding the need to cope with myriad SubProfessions, as well as allowing this system to be used with noncitizen units (naval vessels, artillery, animals etc etc) that don't adopt Professions.

    Nightinggale
    Yes again, I agree this could be simplified and cleaned up (ie there is not actually a need for a separate hardcoded system for things such as Armor, if the same outcome can be achieved by assigning an appropriate Profession for the Yield you want to produce).

    About the question of considering tactical combat in Col, I think Raystuttgart had actually looked into this at one point and found a BtS mod that was trying to implement tactical combat; however after looking further there were apparently a lot of technical problems with this approach and he ended up concluding it would likely not be feasible given the engine, you may want to PM him re details in case I'm remembering totally incorrectly :crazyeye: Though as a major fellow Master of Magic fan from way back, I can definitely see the appeal, and can totally get behind tactical combat ideas if its feasible to get working. (A fantasy or Master of Magic style submod would be awesome even without tactical combat; ie with various Mana types as Yields, which could be used to cast various "Spells" using the CivEffects / Perks system. IIRC Kailric had been thinking of this too at one point?:science:)

    true true! anyway if feature creep adds too much stuff MC will never get finished, and the vanilla AI is already sadly unable to cope with vanilla complexity as it is :sad::lol:
     
  3. Nightinggale

    Nightinggale Chieftain Supporter

    Joined:
    Feb 2, 2009
    Messages:
    3,986
    My experience has told me that plenty of people make statements on the game engine on the forum regarding how it works and what is impossible. Sadly the accuracy isn't as high as I expected when I started modding and I have found plenty of false information. Often it is hard to spot because the writers tend to believe it themselves and overall it fits, but if you go into the details, it no longer adds up. Besides proving something is possible is relatively easy. You just do it. End of story. However proving that something is impossible is much harder. Even if your idea is impossible to implement, somebody else might get a completely different idea for an implementation, which does more or less the same ingame, but is possible. It is tricky to proof you can't reach the same goal using some idea nobody thought of yet.

    From my knowledge of the engine, I haven't found any serious flaws in the idea to implement a combat map. Simply put, it's a matter of tricking the exe to think the game now has a 16x16 map (or whatever the combat zone is) and then mark the entire screen dirty. Once combat is over, CvGame::getMap() (or whatever the pointer access function is called) then returns the pointer to the real map again. This switch once again marks the entire screen dirty and force redrawing everything to delete cached graphics from the combat.

    This way the actual combat can be a 100% DLL change, which makes it doable. We will encounter issues like units moving without moving on the real map and stuff like that, but they are DLL issues and can be fixed with the correct thinking, possibly with a bit of backup/sandboxing certain data from CvUnit. None of the problems with be in the realm of inaccessible functionality in the exe.

    I think the backup system would be something like making a struct, which contains a pointer to a unit and original data, such as movement left, facing direction and whatever. We then add a list/vector of that struct and once combat is over, that list is looped and the units are restored to their original data. (TODO: figure out what to do about units, which died in combat). If we back up data we aren't supposed to change during combat like this, we can then move on to change those numbers during the combat and less special combat code will be needed.

    Network games and taking human turns at the same time could be an issue. I suspect everybody would have to watch all combat, possibly on a map, which will be all black (not revealed) for teams not present in the combat. This will require some thinking, but so far this is the only real issue I can see in the game engine.
     
  4. orlanth

    orlanth Storm God. Yarr!

    Joined:
    Nov 17, 2001
    Messages:
    1,759
    Hmm, sounds potentially interesting :hmm: Another thing they were interested in this for in RaR was the idea of enabling a few separate regional maps in the regular game itself. i.e. when leaving the Europe screen you could choose to travel to The Americas, The Orient, or Africa; where each of these could be its own small regional map where players could build colonies, encounter natives, etc. This would play somewhat like Total War Empire which had several regional "theaters" which worked quite well.

    This might be possible even without making separate "sub-maps" in the true sense; for 2071 I was thinking of dividing the map into 4 "quadrants" by placing impassable Nebula terrain barrier shaped like a + sign; if Civ4EuropeInfos travel paths were unlockable by CivEffects then you could allow players to gradually unlock access to unexplored Quadrants (and Boldly Go Where No One Has Gone Before! :scan::scan::science:)

    Make it so! Tea, Earl Grey, Hot! :coffee:
     
  5. Nightinggale

    Nightinggale Chieftain Supporter

    Joined:
    Feb 2, 2009
    Messages:
    3,986
    I'm not sure I like that because I'm not sure how to teach the AI to use multiple maps like that. Also pathfinding for going from city A to B could be tricky if they aren't on the same map. Caveman2Cosmos has some viewport feature to overcome some internal limitation, but I haven't looked into what it actually does. Something about oversized maps and only showing parts of it to the exe, but the DLL (game logic) always has full sized map.

    We talked about this before. Something like allowing promotions to allow movement on certain terrain/plot types and then make CivEffects, which gives free promotions to unlock as you progress through the game. That solution would technically be completely unrelated to anything mentioned in this thread so far. We talked about doing something similar with ships, which can go further and further away from the coast based on the same system.


    EDIT
    I just realized an easy solution on how to kill units from the battlefield without causing problems with removing them from the regular map. The answer is surprisingly simple. If health goes <= 0, then play the death animation and remove the unit from the battlefield, but do not call the actual kill/destroy function. Once the battle is over, resume the regular map and move the units back into place. Now loop the units and kill those with no health. That way plot cache and stuff like that will update correctly.
     
  6. Lib.Spi't

    Lib.Spi't Overlord of the Wasteland

    Joined:
    Feb 12, 2009
    Messages:
    3,671
    Location:
    UK
    NIGHT

    at some point I want to dig deep into combat and give it a major overhaul

    right now it has rounds where the winner damages the loser. Instead it should be something like D&D where each round means each unit attacks, some tohit, damage resistance and stuff applies, the other unit is damaged and then the roles are reversed where the defender attacks the attacker and tries to damage it

    once such a system is set up, we can add options the units can do, like withdraw. Odds for withdrawal can then be based on unit speed, terrain and stuff as well as the enemy. If your cavalry tries to flee some archers, the archers might get two free attacks or something

    while if it is cavalry fleeing some foot soldiers with swords, they are out of range right away

    and if it's archers fleeing cavalry, well they won't get away due to being too slow

    we can add features to a combat system like this where you use a mixed army because your archers are awesome for some combat while they need to be protected by pikemen or they will be slaughtered by cavalry

    with a max military unit on plot, this could turn quite interesting

    the limit shouldn't be 1

    Imperialism 2 has the limit of 9 as well as a tech, which gives +3

    the AI would figure it out on their own

    because the mod would be in CvUnit::canMoveInto()

    the AI and pathfinding will realize that the unit can't move into the plot. It won't know it's because of the limit. It might as well be impassable mountains, water or something else

    this will also solve another issue. If the cap is lowered, units already on the plot will still be there without crashing issues

    which would be exploitable, though we could give units a combat penalty if they are overcrowded to prevent this from being exploited on purpose

    we could also give archers long range attack where they cause minor damage to all units on a plot. That will give a strategic bonus for not placing all your units on just one plot

    but it runs the risk of spreading too thin and the enemy can kill all units on one plot and get to the weak archers and kill those or something

    I'm thinking of going the Fallout 1+2 approach where armor can have different defenses depending on what weapon they defend against. For instance the metal armor is supreme against laser as it just bounces off while there are other types of armor, which is better suited against bullets

    and each unit will then have one weapon and one armor type

    both from xml but I haven't worked out the details

    heavy armor might be better at reducing damage when hit while light/no armor might decrease the enemy's chance to hit as the light unit can quickly move away from the point of impact

    yeah, we already have unitcombat. It will likely be a replacement for that, or some of those, or it could be used for armor, or weapons, or both
     

Share This Page