Conversation with #freelords at Sat Jul 21 16:02:06 2012 on ulf82@irc.freenode.net (irc)

(16:02:08) ulf82: hi
(16:02:52) Renn: hey
(16:03:26) ulf82: Ok, give me one or two minutes to get started...
(16:03:26) Renn: so whats on the menu today?:)
(16:03:30) Renn: sure
(16:05:30) ulf82: Ok.
(16:06:12) ulf82: I am a bit ill-prepared, so... I remember that there was some discussion about the how of these army-wide modifiers, and there was some confusion, but I do not recall the details.
(16:06:29) ulf82: So do we start from scratch or do you want to remind me how far you came last time?
(16:07:43) Renn: well, manish said he needs to check the code more, before continuing our chat
(16:07:47) Renn: it stayed on that
(16:08:10) Renn: so we didnt do much actually :/
(16:08:10) ulf82: ok.
(16:08:26) Renn: you said we'll concentrate on the gui stuff?
(16:08:37) ulf82: No.
(16:09:03) ulf82: I am currently trying to figure out how to make the basic gui with Andrea, and in case of time constraints, I would give priority to the gui.
(16:09:09) ulf82: That was meant.
(16:09:14) Renn: aha, i get it, ok
(16:09:23) ulf82: But the next chat is on Monday, so this should not interfere.
(16:09:31) Renn: ok
(16:10:00) ulf82: Ok. You are familiar with the code, how modifiers are handled?
(16:10:14) Renn: yes
(16:10:30) ulf82: ok.
(16:10:40) ulf82: give me one minute to look something up...
(16:11:17) Renn: ok
(16:11:17) ulf82: finished.
(16:11:42) ulf82: So we somehow need to store when a unit has army-wide modifiers.
(16:11:50) ulf82: I think there are three parts:
(16:12:02) ulf82: 1. The unit has to offer an interface to query which modifiers it offers
(16:12:22) ulf82: 2. The modifiers need to be stored in an army-wide way.
(16:12:51) ulf82: 3. The other units need to know about the modifiers and apply them when calculating their stats.
(16:13:04) ulf82: This seems to be a reasonable way to split this task up.
(16:13:13) ulf82: ?
(16:13:17) Renn: yes
(16:13:40) Renn: army wide modifiers will be applied to every unit in the army right?
(16:13:41) ulf82: Then let's maybe start with the first part.
(16:13:45) ulf82: yes.
(16:13:53) Renn: ok
(16:14:57) ulf82: So, somehow an army can be queried which army-wide modifiers it offers. How do we do this? For the start, I see two ways:
(16:15:35) ulf82: Also the army needs to store this data, also in xml, that was the issue.
(16:15:52) ulf82: Maybe we start from top level.
(16:16:05) ulf82: I guess the army should have another function getArmyWideModifiers() or so.
(16:16:30) ulf82: (forget the last few lines except the very last, I changed my mind)
(16:16:56) Renn: i'm thinking about removoving stat calc from unit to army
(16:17:22) Renn: because if we put all the modifiers inside calcs of every unit
(16:17:29) Renn: it will mean we have many duplicate modifiers
(16:17:42) ulf82: We can reuse the same modifier.
(16:17:42) Renn: and if modifier changes stats of all units, why not have it in army, or some army manager
(16:18:29) Renn: also when we'll need those modifiers, we wouldn't need to check every unit, but we would have it on one place
(16:19:11) ulf82: The counter argument would be that the stats are usually calculated on a per-unit basis.
(16:20:07) ulf82: So an army-wide calculator would have to query in addition all unit-specific modifiers and base stats. This is not a killer argument, though.
(16:20:08) Renn: true, but you said you wanted to get from army all modifiers... in that case we would need to go through all units to get it from the stat calc
(16:21:10) ulf82: There is a principal problem here that modifiers can be changed e.g. by unequipping a hero item.
(16:21:10) Renn: btw, you said except heroes we might have other units that will affect stats of other units
(16:21:29) ulf82: yes, it should be rare, but in principle doable.
(16:21:44) Renn: will those special units also have items with modifiers that will affect other units?
(16:21:55) ulf82: no
(16:22:03) ulf82: items are hero-only
(16:22:30) Renn: aha
(16:23:05) Renn: because i was thinking that unit without army wide modifier doesnt need to have its own modifier that would change only its' stats... because you can automatically calculate those as base stats
(16:23:38) ulf82: true, but maybe in a year or two we decide to allow magic.
(16:23:48) ulf82: to change a unit's stats.
(16:24:24) Renn: ok, but for now this looks cleaner to me:
(16:24:34) ulf82: This can be complicated but I would not close the possibility for unit-specific modifications.
(16:24:41) ulf82: yes?
(16:24:52) Renn: 1) so when you add an unit with army modifier then we would put it only on one place, we wouldn't need to go through every unit to put it inside their stat calc
(16:25:18) Renn: 2) if we need to remove that unit with modifiers, we'll just change that one place with modifiers, also no need to go through every unit to change stat clac
(16:25:55) ulf82: However,
(16:26:09) Renn: 3) when we need to change unit stats, well, there is no other way but go through all units and change it, regardless if modifiers are inside stat calc or somewhere else... although it is better here to be in stat calc
(16:26:34) ulf82: 3) If you want to calculate a unit's stats, you need to query the army object, pass the unit, and the unit must offer the base stats and the (unit-specific) modifiers to the outside world.
(16:26:44) ulf82: that would be 4), then.
(16:27:07) ulf82: The basic idea of keeping things that belong to a unit inside the unit seem appealing to me.
(16:27:18) ulf82: seems
(16:28:03) ulf82: Admittedly, if we want to give the player feedback, the unit will have to offer the base stats and the modifiers anyway.
(16:29:17) Renn: it would be best if we could combine my first 2 points and still have modifiers inside units... hm
(16:29:47) Renn: ofc, stats need to stay separate
(16:30:48) Renn: will every modifier have unique name, or how are we gonna separate them? by stats?
(16:30:52) ulf82: The practical implications are of course only that in one case, we have two loops over all units that are rarely used, in the other case, the army gets another property instead.
(16:31:09) Renn: name and stats as in equals
(16:31:36) ulf82: By reference, I would say.
(16:31:51) ulf82: Every modifier is a unique object created when the whole game is loaded.
(16:32:09) ulf82: The post-processing (extracting which units affect army stats) would be part of the setup process.
(16:33:01) Renn: we could always have unitmodifiers and armymodifiers
(16:34:50) Renn: we could put enum inside modifier that would be like modifier type, if there ever be something like an modifier that changes not only single army, but multiple/all armies or something like that... it would be better than just put a boolean that would be isArmyModifier
(16:35:08) ulf82: There is one nice thing with separating the stat calculators, which is that they do not have this double function of containing the base stats, and doing the stat calculation.
(16:36:23) ulf82: Mmh...., this might be nice.
(16:36:30) ulf82: A suggestion, let's see if you like it.
(16:37:01) ulf82: 1. A unit has the property stats, which is a map<UnitStat,Integer>.
(16:37:11) ulf82: This is returned by some function getBaseStats() or so.
(16:37:51) ulf82: 2. A unit has a couple of (unit-specific) modifiers, these are never returned, but there is a function applyModifiers(StatCalculator), which adds these internal modifiers to a stat calculator.
(16:39:09) ulf82: 3. The stat calculator has a constructor that, mmhh, this can grow out of hand.
(16:39:11) ulf82: Anyway.
(16:39:16) ulf82: The usage would be like this:
(16:39:26) ulf82: You want to know a unit's, say, hitpoints.
(16:39:29) ulf82: Then you do
(16:39:57) ulf82: StatCalculator calc = new StatCalculator(unit, army_wide_modifers);
(16:40:09) ulf82: calc.getStat(UnitStat.HITPOINT);
(16:40:15) ulf82: Something like this.
(16:40:41) ulf82: So whenever you want to calculate some stat, you do not query the unit, but create a StatCalculator.
(16:40:56) ulf82: Disadvantage is that this might be a bit ... unintuitive.
(16:41:43) ulf82: What do you say?
(16:42:16) ulf82: In general, if you store the army-wide modifiers inside the army, you always need to somehow draw the army into the calculation of the stats.
(16:42:22) Renn: i think its fine, only don't know abuot applyModifiers method... it might be better to call it getModifiedStats, that would apply modifiers and return the modified stats, which would then stat calc use before applying army wide modifiers
(16:42:26) ulf82: of the stats of the unit.
(16:43:45) ulf82: In fact, if we use the StatCalculator in this way, we do not even need to store the army-wide modifiers anywhere.
(16:43:45) Renn: i know, i just thought we'll deal more with army than with separate units inside the army.. but that ofc can change overtime
(16:44:22) ulf82: Because the calculator is specific for a certain army anyway (it is somehow initialised with the army-wide modifiers)
(16:44:35) ulf82: so it might just as well also collect these modifiers on initialisation.
(16:44:50) Renn: yes, true
(16:45:33) ulf82: This is a bit slow, but I don't think that these calculations will be looped that often.
(16:46:21) ulf82: Ok, so let's summarize the basic idea:
(16:46:33) Renn: also, i think we should give a list of units to stat calc, not a single unit. so we wont have calc for every unit, but the army, as army modifiers should apply to all other units
(16:47:47) ulf82: Well, you setup the calculator for the entire army, and can then run it on every unit.
(16:49:00) ulf82: Or what exactly was your suggestion?
(16:49:59) Renn: yes, but if we give a unit to calc, units have their own modifiers inside them, so we would have the same army modifiers list for every unit inside stat calc...with a single stat calc we have a single list (as it is) and list of units on which it is applied
(16:50:37) ulf82: Well, the usage would be
(16:51:03) ulf82: 1. Create a new StatCalculator for a specific army (or list of units); it gets all the army-wide modifiers.
(16:51:25) ulf82: 2. Run calc.getStat(unit, stat) to get the stat for a unit from this army.
(16:52:33) Renn: ok, then we wouldn't store a unit inside stat calc, and this is fine i think, better than to have different stat calcs for every unit
(16:52:48) ulf82: yes, sure.
(16:52:58) ulf82: This also elegantly solves the problem of unequipping items.
(16:53:17) ulf82: If we stored this anywhere, a hero that unequips an item would have to talk back to the army about it.
(16:53:46) Renn: now it needs to talk to stat calc
(16:53:47) ulf82: However, since the list of army-wide modifiers is assembled on-the-fly, this is not required.
(16:54:15) ulf82: or rather, the StatCalc pulls the information when needed.
(16:55:06) ulf82: Ok. Do we want to cast this into a proper task shape?
(16:56:04) Renn: hm, sec
(16:56:27) Renn: i dont think list of modifiers should be made on fly every time for every unit
(16:56:32) Renn: so we would need to save it somewhere
(16:56:54) ulf82: which modifiers, the army-wide or the stack-wide?
(16:56:59) ulf82: unit-wide
(16:57:05) Renn: army wide
(16:57:18) Renn: unit specific ones are inside the unit
(16:57:23) ulf82: The calculator would store it, sure.
(16:58:43) Renn: ok
(16:58:56) Renn: we can make it as a task then
(16:59:02) ulf82: And would of course be invalidated if an army changes; not sure if we can reasonably enforce this or if we should leave this to the sanity of the developer.
(16:59:54) ulf82: ok.
(16:59:57) ulf82: Do you want to summarize?
(17:00:41) Renn: yes
(17:00:46) ulf82: ok, then fire away.
(17:01:13) Renn: 1) we would need to put stat calc from the unit to the army
(17:02:04) Renn: 2) unit would get list of modifiers that would be only unit specific modifiers (not army wide ones)
(17:02:44) Renn: 3) unit gets map of stats that would represent base stats
(17:03:10) Renn: 4) unit gets a method, getModifiedStats, that uses list of modifiers, applies it to the base stats and returns it
(17:03:28) Renn: 5) also, a method getBaseStats that would return base stat
(17:04:04) Renn: 6) remove map of stats from stat calc
(17:05:16) Renn: 7) add a method, getStat(unit, stat) that would get stats from the unit with method getModifiedStat, use army wide modifiers that it has for that stat and return modified stat back
(17:05:45) Renn: getStat should replace calculate(stat) method
(17:06:20) ulf82: Ok, then I would have two issues.
(17:06:28) Renn: ok
(17:06:52) ulf82: First, I would not put the StatCalculator inside the army, but completely outside. You create a new StatCalculator whenever you need it.
(17:07:14) ulf82: So this is sort of a stand-alone object that you use to calculate stats with modifiers.
(17:07:48) Renn: ah
(17:07:53) Renn: ok
(17:08:33) Renn: hm, then we would need to have army available there also, to use it on stat calc
(17:08:40) ulf82: So that the calculation of stats is completely separated from unit/army, which only carry the modifiers and base stats
(17:08:53) ulf82: You can supply the army in the constructor.
(17:09:05) Renn: hm, it would be somewhere that we wont confuse different calcs for different armies
(17:09:28) Renn: but then we'll need to have calc there where we add a unit to army
(17:09:37) Renn: so that we know that modifiers might need to change
(17:09:42) ulf82: the easiest way here: the calculator stores which armies it may calculate for, and throws an exception if a unit is not in the list.
(17:09:55) ulf82: which army.
(17:10:15) ulf82: well, if you modify the army, you should recreate the calculator.
(17:10:16) Renn: we'll have stat calc for every army
(17:10:39) ulf82: "have" is maybe a strong word, we create one when needed, yes.
(17:10:45) Renn: so we'll need to know which stat calc is for which army, and we'll need to know when to change modifiers
(17:12:13) ulf82: Yes. However, when do you usually need a calculator?
(17:12:29) ulf82: You want to move an army -> you need to know its movement points -> you create a stat calculator
(17:12:40) ulf82: and drop it when the army has moved.
(17:13:05) Renn: so you would recreate stat calc for every action that would need to get unit stats?
(17:13:06) ulf82: Two armies fight -> you create a new stat calculator for each round (in case someone died)
(17:13:24) ulf82: you can reuse it if you need multiple stats, but in principle, yes.
(17:14:35) ulf82: Or rather: You can reuse it as long as you know that the modifiers or the composition of the army have not changed
(17:14:59) Renn: i would rather not recreate it after every turn, but this can work too, i guess it shouldnt have a big performance impact
(17:15:31) ulf82: And we can always think about caching or so if it does.
(17:15:34) Renn: well, then you wouldn't need methods for adding/removing modifiers, as you would recreate whole calc every time
(17:15:42) ulf82: Yes.
(17:15:43) Renn: you'd give it through constructor
(17:15:52) Renn: ok
(17:15:58) Renn: we can do that
(17:16:21) ulf82: And for the same reason, using the stat calculator for every calculation of modified stats, I would not calculate anything inside the unit.
(17:16:44) ulf82: So, the unit should offer its base stats and the modifiers, and the stat calculator applies the modifiers.
(17:17:08) ulf82: So that it is absolutely clear that you have to use a stat calculator if you want to calculate modified stats
(17:17:10) Renn: ok, you said before that unit wouldn't give out those modifiers, that is why i wrote that unit would calculate them then
(17:17:16) Renn: but stat calc can do it too
(17:17:43) ulf82: yes, I thought about passing the stat calculator to the unit, and having some method there that gets the unit's modifiers, but this seems to complicated.
(17:18:22) Renn: i'm fine with stat calc calculating all the stats
(17:18:27) ulf82: ok.
(17:19:00) ulf82: Summarize again?
(17:19:02) Renn: but we would need 2 methods for modified stats inside calc then... for the ones that uses only unit specific modifiers, and for the unit and army modifiers
(17:19:30) ulf82: Is there any good reason for applying only unit-specific modifiers?
(17:19:44) ulf82: not reason, use-case
(17:20:46) Renn: me, as a player, would want to see stats with unit specific modifiers if we'll ever have them
(17:21:04) Renn: if you think that wouldn't be the case with most of ppl, we can disregard that then
(17:22:21) Renn: for example
(17:22:24) ulf82: Well, one could always add a query which stats affect the unit; for the player, the whole list of (unit + army) stats should be comprehensive enough, shouldn't it?
(17:22:35) ulf82: add the query to the calculator.
(17:23:17) Renn: in league of legends, you can see your stats as 1.234(1.0 + 0.234), so you know what bonus stat you get from the equipment you are having... without unit modifiers you wouldn't know exactly how much you get bonus from stuff, you'd need to calculate separately
(17:23:31) ulf82: you could list it like this:
(17:23:35) ulf82: base stats
(17:23:45) ulf82: and then a list of all modifiers with the stats they modify.
(17:24:09) ulf82: Then you need not distinguish between unit and army modifiers, this should become clear from the names, for example.
(17:25:45) Renn: i dont quite get it what you mean... you mean you would add all modifiers, unti and army, inside stat calc?
(17:27:10) ulf82: I mean, if the player wants to know what modifiers a unit has, you can offer in the dialog to split up the stats by modifier (unit and army, without distinguishing between them), and the names should give him a hint what modifier comes from which source
(17:27:41) ulf82: But the distinction between unit and army modifiers for the calculation of stats looks artificial to me.
(17:29:33) ulf82: so I would not make it anywhere in the code (e.g., by offering functions that apply only unit or unit+army modifiers)
(17:30:05) Renn: yes, but then you would only see something like, unit modifier gives +3% hp, army modifier gives +10% hp, and you would see base stat and fully modified stat, not how much you get only from army modifiers( which would mostly bee items)... a player would need to calculate those things separately, so imo it would be easier if we just show the calculations
(17:30:09) Renn: but thats just me
(17:30:52) ulf82: another suggestion then: We do not do it now, and you open up the discussion when we get to this point.
(17:30:55) Renn: because i think it would be important to know what items to use, to maximize stats
(17:31:25) ulf82: It is easy to add, but as long as we do not need it, we do not need to have unneccessary functionality being around.
(17:31:35) Renn: yes, it shouldn't be a problem to implement it, we can ask in later stages if ppl think it is good to implement it
(17:31:56) ulf82: ok.
(17:32:15) ulf82: Do you want to summarize again or should I do it?
(17:32:17) Renn: ok, then i'll summarize again
(17:32:22) ulf82: ok
(17:33:29) Renn: 1) stat calc is removed from unit
(17:34:20) ulf82: ok
(17:35:22) Renn: 2) stat calc should have only a list of modifiers (army wide only), and a single method, getStat(unit, stat), that would then use list of modifiers, list of modifiers inside the unit (unit specific only) and apply those to the base state of the unit and return it
(17:35:49) Renn: 3) stat calc would get list of army modifiers through constructor
(17:36:02) Renn: 4) we'll have 1 stat calc per army
(17:36:49) Renn: 5) unit would get list of modifiers that would be only unit specific modifiers (not army wide ones)
(17:37:11) Renn: there would be a getter/setter for it
(17:37:23) Renn: 6) unit gets map of stats that would represent base stats
(17:38:09) Renn: i think that's all?
(17:38:35) ulf82: Well, the army-wide modifiers would also need to be stored (or rather returned)
(17:39:05) ulf82: and one last issue:
(17:39:10) Renn: ah right, for the case above we could have a method getAllModifiers(unit) that would return all army, unit modifiers
(17:40:12) ulf82: Maybe something that I posted before was confusing. So, the unit should have a separate getter for army-wide modifiers and for unit-specific modifiers; we need those anyway because they behave differently
(17:40:53) ulf82: Regarding the last issue: I would suggest that the stat calculator gets the army in the constructor, and filters out all army-wide modifiers.
(17:41:10) Renn: but how will unit have getter for army wide modifiers if it doesn't have them? they are inside stat calc
(17:41:36) Renn: i was thinking doing that outside calculator, but it can be inside too then
(17:41:47) ulf82: My idea was to pass the army to the stat calc in the constructor, then the stat calc manually goes through the list of units and collects all army-wide modifiers.
(17:43:45) ulf82: So the unit just behaves as a collection (base stats, unit modifiers, army modifiers), and the calculator does all the work to put these together.
(17:44:13) Renn: i didnt' mean it would be done inside unit, but ok, it can all be done inside calc
(17:44:56) ulf82: And another thing: Since the calculator is specific to an army, how should it behave if you try to apply it to a unit outside the army?
(17:47:05) Renn: it could throw an exception, something like, UnitNotFoundException, or IllegalArgumentException
(17:47:23) ulf82: ok, so we agree on this point.
(17:47:33) ulf82: Otherwise, I have nothing to comment. I think.
(17:47:38) ulf82: Who writes up the task?
(17:48:09) Renn: can you?:)
(17:48:12) ulf82: ok.
(17:56:27) ulf82: ok, task 92.
(17:59:21) Renn: ist ok
(17:59:24) Renn: it's
(17:59:28) ulf82: good.
(17:59:57) ulf82: Then I would suggest that this should be implemented to see if there are conceptual problems on the way.
(18:00:12) ulf82: And when this is done, we can have a look at actually using army-wide modifiers in the heroes.
(18:00:30) ulf82: and testing the whole thing in context
(18:00:32) Renn: ok
(18:00:44) ulf82: It was a nice chat, I think.
(18:00:48) Renn: yes
(18:01:34) Renn: ok, then when i apply those modifications to the code, i'll post on ML
(18:01:38) ulf82: ok.
(18:01:43) Renn: can't guarantee i'll do it till sunday as i'm not at home atm
(18:01:54) ulf82: I would not aim for it, then.
(18:02:03) ulf82: Some of the changes go also a bit deep
(18:02:29) ulf82: sorry, that was wrong.
(18:02:39) ulf82: no Xml converter changes required.
(18:02:41) Renn: yes, i'll just post on ML when i'm done
(18:02:44) Renn: ok
(18:02:47) ulf82: ok.
(18:03:03) ulf82: In the worst case I do not have time before my holiday, then we need to finish it at the beginning of August.
(18:03:14) ulf82: otherwise, we chat next week.
(18:04:03) Renn: hm, i'm probably on my holiday from 4. or so, wont be having internet then xD
(18:04:20) ulf82: ok, then let's aim for next week. :)
(18:04:28) Renn: yes
(18:04:43) Renn: have a nice weekend then :)
(18:04:53) ulf82: you too.
(18:05:04) Renn: will you post the chat? as you put already the link
(18:05:07) ulf82: and see you next week. :)
(18:05:09) ulf82: I would do this.
(18:05:18) Renn: ok, cya then
(18:05:22) ulf82: cu
(18:05:28) Renn left the room.