Opened 6 years ago

Last modified 4 months ago

#1907 new enhancement

[PATCH] Herding / Corralling

Reported by: historic_bruno Owned by:
Priority: Should Have Milestone: Backlog
Component: Simulation Keywords: patch design
Cc: tjh.hts@…, odalman Patch:

Description (last modified by odalman)

Corrals are currently fairly useless in the game, they are only used to train animals to slaughter for meat. The details haven't been fully described so this is a first draft of how it could work:

  • Herd animals can be captured and brought back to the player's corral (see #997/#1310). I guess this would be goats, sheep, and maybe horses/elephants (depending on the biome and player's civ?)
  • The animals can just stand around the corral building, no need to show them physically inside it. Whether they are corralled or not could be based on distance from the structure. There could be limits per corral.
  • Once at the corral, the animals begin providing steady resources to the player, probably food
  • Some species can be purchased/bred as is currently possible (sheep/goats?)
  • There can be bonuses for some animals and civs. For example having horses at the corral could provide cavalry training bonuses (lower cost, faster rate, or something).
  • Animals can still be slaughtered for meat as before, but then the bonus they provide is lost.
  • An enemy player can raid and capture the animals if unguarded, bringing them back to their own corral (or slaughter them)

Attachments (7)

corral-mockup-2013a.jpg (437.6 KB) - added by michael 6 years ago.
Animals gathered around their respective "corral" structures. They play their idle/grazing animations when stationed here.
corral.diff (7.8 KB) - added by mimo 6 years ago.
corral_inside.jpg (318.1 KB) - added by mimo 6 years ago.
corral-v2.diff (21.0 KB) - added by mimo 6 years ago.
corral-v3.2.diff (20.7 KB) - added by mimo 6 years ago.
with the CRTL key to corral an animal
corral-v4.diff (25.1 KB) - added by mimo 6 years ago.
corral.png (2.2 KB) - added by mimo 6 years ago.
Just noticed that svn diff did not work with binary files. This one should be copied in art/textures/ui/session/icons/ to complete corral-v4.diff

Download all attachments as: .zip

Change History (60)

comment:1 Changed 6 years ago by historic_bruno

Description: modified (diff)

comment:2 Changed 6 years ago by michael

Your rundown of features pretty much echoes my thoughts.

I think capturing some animals that provide a special, non-food bonus (camels, horses, elephants) should require some kind of special command (with a hand or lasso cursor).

Changed 6 years ago by michael

Attachment: corral-mockup-2013a.jpg added

Animals gathered around their respective "corral" structures. They play their idle/grazing animations when stationed here.

comment:3 Changed 6 years ago by mimo

I've made an implementation of a corral. This is the patch attached.

The main difference with respect to the proposed description is that I've taken advantage of the fact that corrals are GarrisonHolder?, so instead of having animals stationned around as in the mockup, they are garrisoned inside. To nonetheless allow them to be captured by raiders, I've changed the EjectHeal? of corrals to be 70% instead of the usual 10% (as soon as the corral is slightly damaged, animals would escape).

For the rate of food production, it is for the moment put at 2 per mille of the amount of food of the garrisoned animals : a sheep (100) would then produce 0.2 food per second, thus 1 food every 5 sec. This 2 per mille rate is defined in the corral template.

Small point : there is no garrison flag on corral ? anybody knows why ?

comment:4 Changed 6 years ago by mimo

Keywords: patch review corral added
Summary: Herding / Corralling[PATCH] Herding / Corralling

Changed 6 years ago by mimo

Attachment: corral.diff added

comment:5 Changed 6 years ago by Erik Johansson

If animals are garrisoned in the corral they (or at least representations of them as that should be easier to implement) should be visible imho. If possible I would suggest a non-moving model, but with an eating animation. And either way that probably explains the garrison flag, animals have either been meant to be displayed in the corral, or grazing around it, so no need for a garrison flag.

comment:6 Changed 6 years ago by mimo

Sure, that is foreseen. But as I don't really like the mockup which looks a bit artificial with all these animals standing around, I'm working on a version where the animals appear inside the corral (see attached snapshot).

The main problem being that the corrals are quite small to accomodate lots of animals. So I'm thinking either to limit the number of animals to 6, or to display only the 6 first if more.

Changed 6 years ago by mimo

Attachment: corral_inside.jpg added

comment:7 Changed 6 years ago by Erik Johansson

Iirc at least the original idea was that you'd only be able to keep one kind of animal in the corral at the same time, so having a limited number of animals displayed should be fine. Maybe have them linked to the percentage of animals though. Say the max limit would be 10 and the max number of animals which can be displayed is six, just have e.g. 1 animal garrisoned=1 showing up, 5 garrisoned=3 showing up, etc.

For elephants the number of animals shown should probably be lowered though =)

comment:8 Changed 6 years ago by leper

(pretty much copy-pasta from IRC after k776 told me to take a look at it, if something doesn't work out nicely just complain ;-) )

!GetFoodRate can be made 5 lines shorter to begin with ;-) (using +this.template.!FoodProduction || 0) The if (!this.foodTimer && this.!GetFoodRate() > 0) could do a check if the garrisoned entity is actually worth starting a timer for. The 1000 constants in there could be replaced by some variable (as in ProductionQueue). The 100000 constant(s) aren't explained at all and I'm not sure if the interval of the timer shouldn't be dependent on the rate (as in UnitAI's GATHER).

comment:9 in reply to:  3 ; Changed 6 years ago by historic_bruno

Tying this into garrisoning doesn't seem like a good idea, logically or aesthetically. It risks adding a bunch of tangential logic to the garrison component, unused in the common case, while forcing us to live with the shortcomings of garrisoning that don't fit the concept of corrals.

What's wrong with having animals standing around the structure as in the mockup? It looks very tidy to me, and it's only an approximation, I'm not sure there's a gameplay requirement for the animals to actually be inside the corral. As you say, the structures aren't large enough, so why impose an artificial limit?

Other points:

  • Lowering eject health isn't really the same as the original idea of being able to capture the animals, it requires damaging the structure to a certain point first, which maybe not every unit will be able to do, while capturing animals is IMO something any unit could do.
  • Garrisoning would require ejecting the animals first to move them, while having them loose about the structure only requires a simple selection and move order, I think it's more convenient
  • Garrisoning is also less convenient for the alternate use of the animals, slaughtering them for meat, whether the owner does this or an enemy during a raid/siege
  • Garrisoning doesn't readily provide for bonuses, not only resources which might be hacked in the current patch, but training bonuses based on species, for example. I don't see the advantage of bloating the garrison component with all of that.

comment:10 Changed 6 years ago by historic_bruno

Milestone: BacklogAlpha 14

comment:11 in reply to:  9 ; Changed 6 years ago by mimo

Replying to historic_bruno:

Tying this into garrisoning doesn't seem like a good idea, logically or aesthetically. It risks adding a bunch of tangential logic to the garrison component, unused in the common case, while forcing us to live with the shortcomings of garrisoning that don't fit the concept of corrals.

The main reason for doing that is that all the gui and UnitAI logic to assign/remove an animal from a corral does not need to be dupplicated. The gain is bigger than the extra code added in GarrisonHolder?.js . But I agree that all the code used to manage corral specificities could be moved to a new component, keeping as clean as possible the genuine Garrisoning part. As a side comment, corrals were already GarrisonHolder?, so I guess somebody else had the same idea.

What's wrong with having animals standing around the structure as in the mockup? It looks very tidy to me, and it's only an approximation, I'm not sure there's a gameplay requirement for the animals to actually be inside the corral. As you say, the structures aren't large enough, so why impose an artificial limit?

Personnaly, I find it really unnatural, but I must say that my trials with animals inside are not really conclusive because corrals are really too small and I think I'll have to go back to the "standing around" option. May-be the best would be to increase a bit corral sizes, adding them some pastureland where we could put the animals ?

Other points:

  • Lowering eject health isn't really the same as the original idea of being able to capture the animals, it requires damaging the structure to a certain point first, which maybe not every unit will be able to do, while capturing animals is IMO something any unit could do.

As long as the exact way capturing works is not defined, I can't answer this.

  • Garrisoning would require ejecting the animals first to move them, while having them loose about the structure only requires a simple selection and move order, I think it's more convenient
  • Garrisoning is also less convenient for the alternate use of the animals, slaughtering them for meat, whether the owner does this or an enemy during a raid/siege

That's in fact an argument in favor of garrisoning. My idea was to have only a representation of the garrisoned unit (i.e. not selectionnable, not attackable, ...) : more often than otherwise, we won't want to select them (either by double-clicking or grabbing or whatever). The rare case where we will want to directly act on them, we would have to explicitely do it by ungarrison them to avoid an unwanted action which would stop your food income or your bonuses.

  • Garrisoning doesn't readily provide for bonuses, not only resources which might be hacked in the current patch, but training bonuses based on species, for example. I don't see the advantage of bloating the garrison component with all of that.

The way bonuses work has still to be defined, but I don't think the fact that we use garrisoning will make their implementation more difficult, especially if a new component is used to avoid putting non-garrison code in GarrisonHolder?.js

comment:12 in reply to:  11 Changed 6 years ago by historic_bruno

Replying to mimo:

The main reason for doing that is that all the gui and UnitAI logic to assign/remove an animal from a corral does not need to be dupplicated. The gain is bigger than the extra code added in GarrisonHolder?.js . But I agree that all the code used to manage corral specificities could be moved to a new component, keeping as clean as possible the genuine Garrisoning part. As a side comment, corrals were already GarrisonHolder?, so I guess somebody else had the same idea.

I don't agree that it's duplication. The only similarity is that both involve units being temporarily associated with a structure, but not much else. For example, garrisoning implies healing and improves the defense capabilities of the structure in some cases, but these make no sense for corrals. In the case of a corral, I think the association should be naturally looser, maybe only based on distance from the structure. Consider builders, they get arranged side-by-side around a structure they're building which isn't completely realistic either, but it works, looks good enough, and conveys to the player what is happening.

From a GUI perspective, "garrisoning" doesn't really indicate corralling, any more than it does "transport" (which also needs to change) :) So we could hack around that too by making animal garrisoning in corrals a special case, but it just gets uglier and uglier to make that work.

Here's how I envision herding in particular:

  • Unit(s) is ordered to herd a living herdable animal (maybe a "lasso" cursor for the action?) and approaches the animal
  • Capturing is tested, it either succeeds (ownership changes), fails, or the player already owns the animal so it's unnecessary
  • Any other animals in a herding range are also tested, to avoid having to micromanage each separately
  • The herdable animals now owned by the player follow the capturing unit back to the nearest corral, something like how AOK had sheep get herded back to the nearest food dropsite for slaughter
  • Animals arrive at the corral and walk up to the foundation. They are now corralled. One thing to consider is how we indicate they are corralled as opposed to standing around in the vicinity of a corral?
  • Movement is an interesting consideration. Can animals be moved with an invisible guiding hand like in AOK, or should it require a unit to actively herd them? E.g. with no unit they move around dumbly, if the herding unit dies or does something else, they stop being herded.

From a scripting point of view, we might need a Herdable component, that specifies not only when something can be herded but the bonuses it provides to the owning player when corralled. Consider different sizes of animals, like a baby and an adult, both could provide bonuses but different amounts - so that's another reason not to hack this into the garrison holder.

It's true that adding anything to UnitAI is annoying, in this case I think it can't be helped, to have proper herding will require a herd action for some units, the animals will need to move to the corral, etc.

Last edited 6 years ago by historic_bruno (previous) (diff)

comment:13 Changed 6 years ago by historic_bruno

Here are some points in favor of garrisoning:

  • Can reuse some existing logic
  • Protects the animals, since garrisoned units aren't damaged in attacks, this pretty much negates the threat of raids on animals IMO
  • Keeps the animals out of the way of the player
  • Would look more realistic if we could prop animals inside the corral (a very similar case to propping units on walls in fact)
Last edited 6 years ago by historic_bruno (previous) (diff)

comment:14 Changed 6 years ago by mimo

You seem to favor taking garrisoning at face value, but we can also take it as a way to deal with unit-building association, and that is to my mind what is already done. In your answer, you say that "garrisoning implies healing and improved defense", but this is not strictly true : healing is only possible in some buildings while improved defense is only possible in others (from my experience of the game, I think that only civil_centre has both). Futhermore garrisoning also already implies some improved trading gain for traders garrisoned inside ships. It is also used for transport and may-be some other features I do not remember. So why not extend a bit the concept and have a few other buildings have food production or bonuses when some specific units are "garrisoned" inside ?

It is true that all these features (food production, but also healing and increased defense) are not really connected to garrisoning and should may-be be moved to BuildingAI as is already the case for the increased defense [as a side remark, we could also add more features not strictly linked to garrison, i.e. even a building with no BuffHeal? but having a healer garrisoned inside would be able to heal its garrisoned units].

For me, using garrisoning for corral would reuse the gui code (we could nonetheless add some cosmetic changes as changing the icon for animals garrisoning) and UnitAI code. But I agree with you that we would have to define how the garrisonned animals can be captured or killed by raiders. My proposition is that they would be ejected as soon as the corral is slightly damaged, but there are may-be other possibilities.

Futhermore, as I said before, if in the future we can extend a bit the size of corrals, we could represent animals inside the corrals, and this would give a plus to the garrison approach.

Anyway, I think with this approach, we can have basic corral features quite fast (the limiting factors being that capturing is not yet available and the way bonuses work not yet defined. So basic features would be food production from domestic animals). I was interested to try this approch, but as there is no agreement on the approach, I will put this in standby for the moment.

comment:15 in reply to:  14 Changed 6 years ago by historic_bruno

Replying to mimo:

It is also used for transport and may-be some other features I do not remember. So why not extend a bit the concept and have a few other buildings have food production or bonuses when some specific units are "garrisoned" inside ?

Which is wrong, garrisoning and transporting are not the same, just like corralling and garrisoning are not the same. Actually, it has been reused as a hack because people were impatient/lazy, not because it's the best solution. It's perfectly OK to recognize that's a bad choice that needs to be fixed (it has been talked about many times over the years in fact).

If we want to reuse the logic of entities inside other entities, I would propose some other component like CmpInventory, which can be shared by garrisoning, transporting, and whatever else needs it. But that's more of a cleanup of existing game logic; for corralling I don't agree that entities inside the corral is even the best solution. It won't be significantly harder to implement without using garrisoning but if we're afraid of adding code to UnitAI or the GUI, we might as well abandon capturing and a bunch of other unimplemented features.

Last edited 6 years ago by historic_bruno (previous) (diff)

comment:16 Changed 6 years ago by historic_bruno

I thought about this some more and read a comment from Wijitmaker that sounds like indeed corrals were going to have a protective function. In that case, something like garrisoning makes more sense than having the animals standing around the structure. But I'm confused because Michael said that my outline is how he envisioned corrals working (without garrisoning). So maybe the design committee needs to review this. It makes a big difference, is the corral primarily a defensive structure or an economic structure?

But either way, I would still prefer if corral-specific logic happened in another component, to avoid adding corral bonuses to GarrisonHolder. It doesn't need to be a heavyweight component, see Loot and Looter for lightweight examples. Garrisoning could be reused for the storage until we make something more generic.

comment:17 Changed 6 years ago by historic_bruno

Keywords: design added; corral removed

comment:18 Changed 6 years ago by historic_bruno

Discussed this after today's staff meeting, here's the relevant IRC log:

22:49 <@historicbruno> Mythos_Ruler: Pureon:  Corrals. Do you care if animals are garrisoned in the corral or not? 
22:50 <@historicbruno> not for the visual effects though that's interesting, but more  gameplay-wise
23:39 < Pureon> historicbruno: I'm not sure what the final decision was on corrals. Perhaps the animals should be outside for raiding purposes - think that was it...
23:41 < Pureon> Mythos_Ruler will confirm. (And I hope he says keep the animals on the outside of corrals (not garrisoned or visually inside the pens)
23:56 < Pureon> *I might be completely wrong
23:57 < Pureon> AFAIR quantumstate and someone else decided the animals should remain outside for raiding, but then the plans might have changed
23:58 < Pureon> If you place 10 animals within a certain distance of the corral, the corral starts producing food
00:18 < Mythos_Ruler> historicbruno: I think it's just fine if the animals just stood on the outside.
00:19 < Mythos_Ruler> That way they're more prone to raiding and suchness.
00:19 < Mythos_Ruler> I think though that you should actually task them to the corral, not simply move them near it.
00:20 <@historicbruno> that's what I was thinking, but it wouldn't be fine if they garrisoned inside?
00:20 < Mythos_Ruler> It would be 'ok' and probably easier to implement (?), however I think for raiding and whatnot it's better if they were outside.
00:22 < Mythos_Ruler> Basically just like the Age of Empires III  'Livestock Pen'.
00:22 <@historicbruno> oh, I iidn't know other games had done it that way
00:22 <@historicbruno> http://www.ageofempires.co.nz/images/aoe3/buildings/livestockpen.jpg
00:23 <@historicbruno> doesn't exactly look like a pen in that screenshot, but it's what you're describing
00:24 <@historicbruno> ok, so it will serve more of an economic purpose than a defensive one
00:26 < Mythos_Ruler> Right
00:26 < Mythos_Ruler> Also, that screenshot looksa little extreme. lol
00:26 < Mythos_Ruler> Lots and lots of sheeps.
00:27 < Mythos_Ruler> in AOE3 though they didn't act like relics.
00:27 < Mythos_Ruler> They fattened when you tasked them to the pen
00:28 < Mythos_Ruler> So, they start out at only 50 food or 100 food and fatten to double that amount. Then they move away from the pen to tell you they are ready for death.
00:28 < Mythos_Ruler> That's in AOE3
00:28 < Mythos_Ruler> I like our relic idea a little better
00:28 < Mythos_Ruler> It's unique

comment:19 Changed 6 years ago by mimo

yes, I expected this and I'd started implementing a solution without garrison. Here is a new version following these lines. For the moment, I've only implemented food production from sheep or pigs, but extension to other animals is straightforward through templates.

Corraling use the Ctrl key, and corraled animals, while still selectable by clicking them, can't be selected by grabing or double-click (to avoid unwanted un-corraling). To force them to be selected by dragging or double-click, you have to also press the F1 key.

The number of corraled animals is added in the selection_detail panel of corrals (as the number of gatherers for resourceSupply), but this panel size is a bit too small when displayed numbers have two digits, and I've not found documention on how the size in session.xml works, any tip about it ?

Changed 6 years ago by mimo

Attachment: corral-v2.diff added

comment:20 in reply to:  19 ; Changed 6 years ago by historic_bruno

Replying to mimo:

Corraling use the Ctrl key, and corraled animals, while still selectable by clicking them, can't be selected by grabing or double-click (to avoid unwanted un-corraling). To force them to be selected by dragging or double-click, you have to also press the F1 key.

Is that really necessary? I think a similar issue exists for other units and orders, for example infantry, some could be attacking and some idle or gathering, but we don't have special keys to select them by order type. With hotkeys there is a risk of adding confusion and this one doesn't seem intuitive :(

comment:21 in reply to:  20 Changed 6 years ago by mimo

Replying to historic_bruno:

Replying to mimo:

Corraling use the Ctrl key, and corraled animals, while still selectable by clicking them, can't be selected by grabing or double-click (to avoid unwanted un-corraling). To force them to be selected by dragging or double-click, you have to also press the F1 key.

Is that really necessary? I think a similar issue exists for other units and orders, for example infantry, some could be attacking and some idle or gathering, but we don't have special keys to select them by order type. With hotkeys there is a risk of adding confusion and this one doesn't seem intuitive :(

As this problem is the same as in #2034, let's discuss there this point. See my comment 4

comment:22 Changed 6 years ago by michael

mimo, your hotkeys add a confusing solution to a really trivial (almost non-existent) problem. I suggest we don't add any hotkeys for the special case of selecting corralled animals. I am wondering why you can't just double-click or band-box them. Or if you are worried about accidentally selecting a bunch of them along with other units (like soldiers), then implement some kind of general "military select" hotkey so that you can only select military units when band-boxing if desired.

comment:23 Changed 6 years ago by historic_bruno

Keywords: design removed
Owner: set to mimo

comment:24 Changed 6 years ago by Kieran P

Milestone: Alpha 14Alpha 15

comment:25 Changed 6 years ago by mimo

As it seems that people do not like it, I've removed the special hotkey selection in this newer version.

comment:26 Changed 6 years ago by sanderd17

You seem to have forgot including the settings file that defines the hotkey needed to corral animals.

comment:27 Changed 6 years ago by mimo

Yep, sorry. I'll upload a new patch. In the meantime, add

hotkey.session.corral = Ctrl ; Modifier to corral an animal

in your local.cfg

comment:28 Changed 6 years ago by sanderd17

First of all, it looks like you have a bug with timers. You increase the timeout on every added animal, this causes the food to raise slower, which can't be what you want. But please read on, as there are better ways to use timers.

Some comments on the code:

  • input.js:1426: You shouldn't uncomment that line. Instead call a new sound file. This won't change anything, but it will be easier for the sound manager in the future to add his corral sound as he'll only need to edit the template XML
  • UnitAI.js: CorralType? and CorralRate? don't belong in UnitAI IMO (unitAI is already big enough). A small separate component file seems more logical. Also better make the corralRate technology-aware per animal (instead of doing that in Corral.js).
  • Corral.js: There will be a bug when you corral animals with different types. Only the type of the first corralled animal is counted. You should instead calculate the rate per type.
  • When you have a repeating function, it's better to use the SetInterval? function from cmpTimer. That's more perfomant and takes the turn lengths into account. I would simply add the function every second, and add the rate at that moment to it. Start the timer when the first animal is corraled, and stop it when the last one is gone.

Comments on the functionality:

  • It's a pity you can't automatically guide units to an other corral. If you f.e. set the rallypoint of your CC on a fortress, the units that are spawned from the CC automatically garrison inside the fortress. It would be nice if you could do that with corralling too.
  • It would be nice to show the current rate somewhere on the GUI. But please talk to alpha123 about this. He was also going to add the current gather rate of resources (so you see how much faster it goes when you add a worker). So you could use the same UI.

Thanks for working on this patch.

comment:29 in reply to:  28 ; Changed 6 years ago by mimo

Replying to sanderd17:

First of all, it looks like you have a bug with timers. You increase the timeout on every added animal, this causes the food to raise slower, which can't be what you want. But please read on, as there are better ways to use timers.

No, I think the code is correct. Have you tested the result or just looked at the code ? If for example the rate is 0.4 food/sec/animal, I add n food after 2.5 sec if I have n animals. The advantage of that method is its simplicity : we do not have to care about non-integer rate (which we would with your proposition of a 1s interval), and as the interval is of the order of the second or bigger we also do not care about subtleties of the best use of timers (here I've just taken the approach used in GarrisonHolder?). Futhermore, as the interval is recomputed at each step, it is automatically updated if we add or remove one animal, or improve the rate by technology.

Some comments on the code:

  • input.js:1426: You shouldn't uncomment that line. Instead call a new sound file. This won't change anything, but it will be easier for the sound manager in the future to add his corral sound as he'll only need to edit the template XML

of course, that's why I've just commented the line and not removed it :-) waiting to have a proper sound to uncomment it.

  • UnitAI.js: CorralType? and CorralRate? don't belong in UnitAI IMO (unitAI is already big enough). A small separate component file seems more logical. Also better make the corralRate technology-aware per animal (instead of doing that in Corral.js).

I would tend to agree with you, but as this would result in a very small component, I was not sure. Are there any guidelines about that ? For the technology-aware per animal, that's something which can be implemented, but a full design description of corral would be necessary : what animals and for what profit ? I've implemented only sheep and pig which produce food, so I believe a single technology is enough for both of them. Horses also can be added, but as they need capturing and a proper definition of the bonus they give, that will be for a second patch.

  • Corral.js: There will be a bug when you corral animals with different types. Only the type of the first corralled animal is counted. You should instead calculate the rate per type.

From my understanding, only one type of animal can be corraled inside a given corral (the first animal corraled would define which one can be added inside one corral). The code is then written accordingly, and I was waiting for a full design decision to add the code to allow only one animal type per corral.

  • When you have a repeating function, it's better to use the SetInterval? function from cmpTimer. That's more perfomant and takes the turn lengths into account. I would simply add the function every second, and add the rate at that moment to it. Start the timer when the first animal is corraled, and stop it when the last one is gone.

As I said before, with interval of the order of the second, that's not really important and futhermore this would add complication because the resource are integers.

Comments on the functionality:

  • It's a pity you can't automatically guide units to an other corral. If you f.e. set the rallypoint of your CC on a fortress, the units that are spawned from the CC automatically garrison inside the fortress. It would be nice if you could do that with corralling too.

I agree, but what is only possible now would be from one corral to another corral. I would much more like to have from one corral to itself, but some code is necessary for that (even for garrisoning, you can not yet garrison directly in a building the units produced by this building). Anyway, I will see how to add it from one corral to another one.

  • It would be nice to show the current rate somewhere on the GUI. But please talk to alpha123 about this. He was also going to add the current gather rate of resources (so you see how much faster it goes when you add a worker). So you could use the same UI.

As you said, let's wait and see what comes out from alpha123's work

Thanks for the review.

Thanks for working on this patch.

comment:30 in reply to:  29 Changed 6 years ago by mimo

Replying to mimo:

Replying to sanderd17:

Comments on the functionality:

  • It's a pity you can't automatically guide units to an other corral. If you f.e. set the rallypoint of your CC on a fortress, the units that are spawned from the CC automatically garrison inside the fortress. It would be nice if you could do that with corralling too.

I agree, but what is only possible now would be from one corral to another corral. I would much more like to have from one corral to itself, but some code is necessary for that (even for garrisoning, you can not yet garrison directly in a building the units produced by this building). Anyway, I will see how to add it from one corral to another one.

I've uploaded a new version with this change

comment:31 in reply to:  29 Changed 6 years ago by mimo

Replying to mimo:

Replying to sanderd17:

First of all, it looks like you have a bug with timers. You increase the timeout on every added animal, this causes the food to raise slower, which can't be what you want. But please read on, as there are better ways to use timers.

No, I think the code is correct. Have you tested the result or just looked at the code ? If for example the rate is 0.4 food/sec/animal, I add n food after 2.5 sec if I have n animals.

I've found the problem, it is when applying the technology, because the return value is cached ! That is quite misleading. So if the rate for an animal is r, I was calling it with n*r when n corraled animals but as the value for n=1 was cached, it was always returning 1*r. I guess I have to clear the cache each time the number of corraled animals changes ? Thanks for pointing it.

Changed 6 years ago by mimo

Attachment: corral-v3.2.diff added

with the CRTL key to corral an animal

comment:32 in reply to:  29 ; Changed 6 years ago by sanderd17

Replying to mimo:

Replying to sanderd17:

Some comments on the code:

  • input.js:1426: You shouldn't uncomment that line. Instead call a new sound file. This won't change anything, but it will be easier for the sound manager in the future to add his corral sound as he'll only need to edit the template XML

of course, that's why I've just commented the line and not removed it :-) waiting to have a proper sound to uncomment it.

AFAIK, the playsound plays a sound defined in the template, it doesn't play a sound file by its name directly (so you can have different sounds for each building). Just making up your own name would mean that the sound artists wouldn't have to touch the code (which they should never have to do IMO).

  • UnitAI.js: CorralType? and CorralRate? don't belong in UnitAI IMO (unitAI is already big enough). A small separate component file seems more logical. Also better make the corralRate technology-aware per animal (instead of doing that in Corral.js).

I would tend to agree with you, but as this would result in a very small component, I was not sure. Are there any guidelines about that ? For the technology-aware per animal, that's something which can be implemented, but a full design description of corral would be necessary : what animals and for what profit ? I've implemented only sheep and pig which produce food, so I believe a single technology is enough for both of them. Horses also can be added, but as they need capturing and a proper definition of the bonus they give, that will be for a second patch.

Small components are prefered. They make it easier to track code changes, they make it easier to read through the code etc. It would also avoid making these tags optional (which is a good thing).

  • Corral.js: There will be a bug when you corral animals with different types. Only the type of the first corralled animal is counted. You should instead calculate the rate per type.

From my understanding, only one type of animal can be corraled inside a given corral (the first animal corraled would define which one can be added inside one corral). The code is then written accordingly, and I was waiting for a full design decision to add the code to allow only one animal type per corral.

I don't know how it was discussed. In any way, your code should throw a warning when animals of a different type are corralled in the same building, OR you should correctly handle such cases (by separating the rates). Such silent failures can cause problems later.

  • When you have a repeating function, it's better to use the SetInterval? function from cmpTimer. That's more perfomant and takes the turn lengths into account. I would simply add the function every second, and add the rate at that moment to it. Start the timer when the first animal is corraled, and stop it when the last one is gone.

As I said before, with interval of the order of the second, that's not really important and futhermore this would add complication because the resource are integers.

Health also was an integer. But it's changed to a decimal because 1 hp couldn't be considered the minimum. The same could be done with resources, it just should be rounded (towards zero probably) in the GUI. But I'll check how you did it now.

Thanks for fixing the other issues.

comment:33 in reply to:  32 Changed 6 years ago by mimo

Replying to sanderd17:

  • UnitAI.js: CorralType? and CorralRate? don't belong in UnitAI IMO (unitAI is already big enough). A small separate component file seems more logical. Also better make the corralRate technology-aware per animal (instead of doing that in Corral.js).

I would tend to agree with you, but as this would result in a very small component, I was not sure. Are there any guidelines about that ? For the technology-aware per animal, that's something which can be implemented, but a full design description of corral would be necessary : what animals and for what profit ? I've implemented only sheep and pig which produce food, so I believe a single technology is enough for both of them. Horses also can be added, but as they need capturing and a proper definition of the bonus they give, that will be for a second patch.

Small components are prefered. They make it easier to track code changes, they make it easier to read through the code etc. It would also avoid making these tags optional (which is a good thing).

OK I will make a new component (CorralSupply? ?). But presently, it will be pretty empty: used only to define the two elements CorralType? and CorralRate?.

  • Corral.js: There will be a bug when you corral animals with different types. Only the type of the first corralled animal is counted. You should instead calculate the rate per type.

From my understanding, only one type of animal can be corraled inside a given corral (the first animal corraled would define which one can be added inside one corral). The code is then written accordingly, and I was waiting for a full design decision to add the code to allow only one animal type per corral.

I don't know how it was discussed. In any way, your code should throw a warning when animals of a different type are corralled in the same building, OR you should correctly handle such cases (by separating the rates). Such silent failures can cause problems later.

There are no silent failure. Everything is in principle already done consistently: in Corral.CanBeCorraled?, we check that the new animal to be corraled has the same type as the ones already corraled. And if not, it cannot be corraled. So if for example the first corraled animal provide food, we can only add animals providing food. When the corral specifications will be more complete, we can change that easily and require for example that the animal are from the same specy if that is what is desired.

Changed 6 years ago by mimo

Attachment: corral-v4.diff added

comment:34 Changed 6 years ago by mimo

Here is a new version. It should be complete concerning the food production at corrals. The bonuses when corraling "non-food" animals (horses for example which would give bonus for cavalry units production) are also partially implemented. What I could think of is, if we have n corraled horses, to reduce the cavalry's buildTime by min(sqrt(n)*5%, 15%) ? And what is missing is a way to propagate this reduction dynamically (as n may vary) in gui and simulation. Reusing the logic developped for Aura (ticket #2048) looks to me the simplest way. Any other proposition ?

As this bonus part needs also capturing to be useful, having to wait also for #2048 to complete it is ok. In the meantime, this patch is ready to provide food production at the corrals.

comment:35 Changed 6 years ago by sanderd17

For those other bonuses, it would indeed be better to wait for the auras. I can make a special "corral" aura, just like I have a "garrison" aura currently. Although the implementation would differ, it wouldn't add much code. This would mean though that the bonusClass doesn't need to be defined in the corral code, but that it will be a separate aura. I only would need to know when an entity is corralled and when it's uncoralled.

I would need to allow stacking of auras, (i.e. corralling an extra horse gives extra advantage), but that will be as less code as adding a boolean flag to the Auras component.

For you current patch, it does look quite good, and I think we can get it in when we're out feature freeze.

Changed 6 years ago by mimo

Attachment: corral.png added

Just noticed that svn diff did not work with binary files. This one should be copied in art/textures/ui/session/icons/ to complete corral-v4.diff

comment:36 Changed 6 years ago by sanderd17

Sorry for not living to my promise. But some people are still thinking on what's exactly needed for coralling. I agree it's a bit irritating to develop this way.

I think if you want to get this in game, you'll have to ask people's opinions, and convince the minorities of the majority's meaning. Maybe best to do it via a forum post and some additional chatting.

comment:37 Changed 6 years ago by Marcio

How works? may be you need to talk with us.

comment:38 Changed 6 years ago by sanderd17

New discussions happened on IRC: http://irclogs.wildfiregames.com/2013-12-03-QuakeNet-%230ad-dev.log (starting around 18:20)

The result is that sheep should be garrisoned to generate food (so I guess one of the previous patches could be updated/cleaned and used).

Next to that, players wouldn't be able to generate sheep (so autogarrison wasn't needed) but they should be able to convert gaia sheep via fidelity. This could be kept for a separate patch too.

Sheep should be ejected when the corral is a little damaged (garrisonholder already has code for this), and could then be stolen.

Some visualisation of the damage could also be nice, but probably requires a separate ticket.

comment:39 Changed 6 years ago by mimo

Owner: mimo deleted

Interesting to see how such an IRC discussion can lead to opposite conclusions compared to the ones from 6 months ago (see all the comments on this ticket). Let's see what the output will be in another six months. But in the meantime, having a real design discussion on such a feature would certainly help instead of going round in circles.

comment:40 Changed 6 years ago by Marcio

For now Mimo it's doing a great work, mostly of good features to A 15 he does well. May be need some help he is with many task.

comment:41 Changed 6 years ago by wraitii

Keywords: design added
Milestone: Alpha 15Alpha 16

Imo we need to think of this in the global scope of all food sources, like we did on the "new farming paradigm" (#1318). I also think we will need to test the main proposals for that, as we can't really feel how each work otherwise.

In the meantime, moving to A16.

comment:42 Changed 6 years ago by Radagast

Mimo, splendid work. I like both the garrison with your superb visualization and the animals gathering closely (perhaps even tied to the fences) solution.

I wonder why we should not adopt your patch? There is nothing wrong as you used garrison as demanded.

So why not implementing a hybrid solution: Using the principle of operation of gates (removal of obstruction elements for pathplanning like sanderd explained :) we could apply the following procedure:

  • Capturing (generic: i.e. select units, those approach the other unit(s) - a short fight just wants to ignite while the opposing units' combined strength is examined. If one side is heavily overpowered [easily the case for a herd of animals] this side will surrender unless orders have been put in place to NOT surrender and instead fight to death - you know, the common game. If the treshold for surrender was not reached, the stats AND health will be analyzed throughout the fighting that then erupts. Once one side gets heavily overpowered AND still no relieving units are underway. The units will either be captured/surrender one by one then starting from the one with the most severe injury and closest to enemies. For animals and females this procedure ensures that they get captured quickly by some experienced soldiers and the requirement to be very close to the capture target prevents that all moving units in the armies' influence region are captured at once (even they might be very healthy). [lower health of the unit to be captured => capture distance treshold increases so that enemy/neutral units can even be captured from some meter distance instead of VERY close (1m) if it [the unit, e.g. archer] has low health and his army is heavily overpowered. If an army is not overpowered or the individual unit is healthy for 100% then it's not possible to catch it. Only units are very overpowered 100% units can be captured if your units come very close to individual units. Those are then captured, the other have to be pursued until you have no more soldiers to capture anymore. Each unit can only capture as many units as the captives' combined health is below your health or half your health.)

  • Captives don't convert immediately after being caught and never change clothing for allowing to see in the aftermath which units are captives. Only their colour changes and their mode changes to 'Guard' the unit that captured them. This way they follow the unit.
  • The units having captured other units then try to reach the closed corral and towers, subsequently delivering their captives. They either stay garrisoned until they convert fully after a certain amount of time. Or they never convert fully and are working as slaves, what implies that they will change side all at once and immediately once foreign units are close and heavily overpowering by means of stats and health combined the units within reach of the captives.).
  • For the corall one could decide between two hybrid solutions:
  • Complicated: Make buildings composites, that is make fences and corral combinable and placeable as once.(just like it is for walls!) With some engine rework this might even allow for adding building parts (e.g. astro-towers) later on. They could be built and placed at once but may be invisible until researched/built. But the latter is optional.

E.g. one can build a corral and once it's placed/built there are the farmhouse and three or more fences. Fences can be converted to gates just like it is with walls. Now captives can be lead into the fences or farmcourt. Then the unit can leave them behind by either releasing the captives from the Guard command or making them follow their capturer in a delayed fashion such that the door can be locked quick enough before they leave.

For animal herds the capturer can either stay in place where the animals float around it or the captives can be delivered to a corall/building as described above.

  • Easy: Keep everything like it is and just deactive the obstruction in the middle of the corall and where the gate graphic is located in the fence. This way units with possibly herd animals as captives guarding them (thus following them into the middle of the fences of the corall) can be lead into the corall meadow. This way arbitrary meadows could be handled too.

The composite buildings solution just like it is for walls (where there result several objects even though only one building was placed) might be more flexible but it is possible to implement capturing and herding only using existing code and some health + stats comparison to detect which side is overpowered and the close enough for capture check. A button for preventing units that are capable to fight (soldiers) from surrender may be added lateron.

The effects of herded animals has already been implemented by Mimo (whereas next to the animal garrison option there then there also a range/surrounding check for captives guarding their capturer has to performed as well as a check for animals inside their building bounding box.)

Please let me know what you think of it? I hope I didn't offend anyone with my proposals.

Last edited 6 years ago by sanderd17 (previous) (diff)

comment:43 Changed 6 years ago by sanderd17

Radagast, please keep trac tickets on topic. Tickets are to discuss the code and behaviour of a single task. This one is about corralling, and doesn't care where the sheep come from. There's a different ticket about capturing.

Next to that, please keep the work reasonable. There are certain engine limitations that require obstructions (and obstruction holes) to be of a certain minimum size. So if you have a corral with an un-obstructed center, and a gate, it will become huge. It's even worse if you make it a composite building (let alone all the micro involved in this approach). So in short, your corralling approach isn't viable with the current engine.

comment:44 Changed 6 years ago by Radagast

Thank you for your edit and input. I will not mix it up anymore and will focus on coralling/herding in this ticket:

Instead of implementing one or the other approach couldn't we just make fences deployable as buildings and not only via Atlas map editor? Currently fences are already non-passable for objects (c. Gallic Fields map). By placing those fences one could design and construct the herding places oneself and the captives would simply be assigned to the capturing unit for the whole remainder of time until the animals are released or the capturer dies.

This way the bonus would be calculated just like in this patch but by examining/iterating all the guards units and checking if the guard unit is from the enemy. This indicates that this guard unit is a captive as otherwise it were not possible for enemies to guard each other.

Is that approach more realistic?

comment:45 Changed 5 years ago by sanderd17

Milestone: Alpha 16Alpha 17

comment:46 Changed 5 years ago by stanislas69

Do you think we could use sander's garisonning system for having animals inside ?

comment:47 Changed 5 years ago by Timothy Hamlett

Cc: tjh.hts@… added

probably

comment:48 Changed 5 years ago by leper

Milestone: Alpha 17Backlog

comment:49 Changed 5 years ago by Lionkanzen

An advantage provided by this features is gathering food without need use gatherer units like females like citizen males. You save pop capacity to focus in another tasks.p an example use to have a big army

comment:50 Changed 4 years ago by wraitii

Keywords: review removed

comment:52 Changed 3 years ago by Lionkanzen

its possible, have a fattening feature? the animal near, a drop side start to become fat(increasing stat own source of food )

comment:53 Changed 6 months ago by odalman

Cc: odalman added
Description: modified (diff)

comment:54 Changed 4 months ago by Imarok

Component: UI & SimulationSimulation

Move tickets to Simulation as UI & Simulation got some sub components.

Note: See TracTickets for help on using tickets.