Submitted by salimiles
The repair costs for fixing bots are way too high, especially in time.

Someone needs to lower them to something more reasonable.

Can you give some more details on that Miles?

The formula that I used initially quickly makes it too expensive (in time, temperatures, and credits) to repair bots. IMHO.

In order to make it fairer, and more fun, I think repairs shouldn't cost more than ~10 seconds, ~200 credits, or ~100 heating.

So yeah, a set of new formulas is needed.

--- On Wed, 7/27/11, Matthias Krüger - Roundup <bugs@freedroid.org> wrote:

> From: Matthias Krüger - Roundup <bugs@freedroid.org>
> Subject: [issue337] Better balancing of repair costs for bots
> To: freedroid-bugs@lists.sourceforge.net, stinkyfishheadisred@yahoo.com
> Date: Wednesday, July 27, 2011, 5:09 AM
> 
> Matthias Krüger <matthias.krueger@famsik.de>
> added the comment:
> 
> Can you give some more details on that Miles?
> 
> ----------
> nosy: +salimiles
> priority: bug -> minor
> 
> ________________________________________
> FreedroidRPG issues <bugs@freedroid.org>
> <http://bugs.freedroid.org/b/issue337>
> ________________________________________
>

While we're at it - I think currently the system doesn't check for your
maximal temperature, which leads to emergency shutdowns due to overheating.

Hum, it looks like we'd need to add a lua function to check for max temperature. I'll include it in the patch I'm working on.

--- On Sun, 7/31/11, Arthur Huillet - Roundup <bugs@freedroid.org> wrote:

> From: Arthur Huillet - Roundup <bugs@freedroid.org>
> Subject: [issue337] Better balancing of repair costs for bots
> To: freedroid-bugs@lists.sourceforge.net, stinkyfishheadisred@yahoo.com
> Date: Sunday, July 31, 2011, 10:36 AM
> 
> Arthur Huillet <ahuillet@freedroid.org>
> added the comment:
> 
> While we're at it - I think currently the system doesn't
> check for your
> maximal temperature, which leads to emergency shutdowns due
> to overheating.
> 
> ________________________________________
> FreedroidRPG issues <bugs@freedroid.org>
> <http://bugs.freedroid.org/b/issue337>
> ________________________________________
>

OK, after playing around with a number of equations, I think this set works the
best.

I like the idea, so I also made a spreadsheet document for the formulas proposed
in my latest comment at rb (November 10th, 2011, 8:52 a.m).

In your spreadsheet you forgot to factor in that the self repairs only happen
once every three seconds. The repair rate also depends on the difficulty
settings, currently easy: 0.1, medium: 0.05, and hard: 0.05 in
map/difficulty_params.dat.

Finally the equations indicate that Tux would be frozen for well over a minute
in some circumstances.


The main reason why we are changing this, is that Tux can be frozen for too long.

How about the attached:

I did not forgot the factor - the factor is irrelevant for the repair rate, see
also my comment on your spreadsheet in the rb: "6. The spreadsheet uses a
constant of 3 in the computation of the self_repair_rate. As I understand the
code of the self-repair, the constant is not a modifier of quantity, but only
defines in which intervals the healing is taking place. But the quantity of
healing for each interval step is also multiplied with this constant. Therefore,
the repair_rate in the game does not change with the interval_constant."
In the spreadsheet I just used the difficulty_modifier 0.1 for every bot, please
feel free to add an additional field for it.

Now, there are some conflicting conditions:
"the basic idea that damage repair should take approx. 1 second, 10 credits, and
5 heat per point of damage to repair (these are the constants), but no more than
this, but not significantly less."
"Tux would be frozen for well over a minute in some circumstances[...]is that
Tux can be frozen for too long"

S

Since the damage can be up to 299 points, the approx. 1 second repair_time per
damage would result in bigger repair_times than 60 seconds. This is especially
not preventable, if you want bigger bots to be more expansive to repair then
smaller bots.
If you accept that the first condition can be canceled, I can easily make you
formulas that do the work - for example with an upper bound of 60s or 30s.

For your new spreadsheet: You have formulas like
=F$8*($F$5-F$2/$F$8)*($D11/$A11). Easily to say, F8 can be discarded, since it
is a factor in numerator and denominator. Most of the problems mentioned in the
rb and the problem of the confliciting conditions remain and there is a new one:
one of the factors in the numerator is (1.1 - ability_value), this is negative
in most cases. Therefore, after learning the first level of the abilities csi,
ebp, hack, the repair cost will in every case be computed to 1 (since if penalty
< 1 the value 1 is used).

A small correction of my previous comment: the discarding of F8 is not possible,
I missread the parenthesis. The other problems remain.

I think, we should first get clear about the condition the formula should
achieve. The things I see are:
- The costs should be proportional to the damage amount.
- The costs for bigger bots should be not smaller than the costs for smaller
bots (ideally a little bit higher).
- The costs for repairing one damage point should in no case (different bots
etc.) differ more than factor 2. (60% of the max cost of one point is ok, but
45% would be not).
- The time costs should not exceed 30s.
- The healing rate have to be considered (ideally it should be seen as healing
itself during repair in the same way it heals normally).
- [The circuit costs and heat costs should be proportional to the time costs.]

I have skipped "damage repair should take approx. 1 second[...] per point of
damage to repair".
Are you alright this these conditions? Do you see other conditions the formulas
would have to fulfill?

Another constraint:
- Every ability level should reduce the costs by a definite factor.

I modified my formula (as in diff 5 at rb) to fulfill the time limit 30 s
constraint. It also fulfills all the other constraints I mentioned (obviously
except the "1 s per point", which is conflicting to the other one).
I made a new diff (attached) for it and playtested it with 123, 139, 296, 302,
493, 598, 711, 742 and 999 at minor and major damages. I also ran -b dialog.
The costs seem very appropriate. I also tested the new check that the repair can
not be performed if Tux would overheat.

Again, the main characteristics of the formula:
cost = constant * bot_modifier * ability_modifier * healing_modifier * damage

-- the bot_modifier ranges from 0.8 (small bots) to 1 (big bots) [realized by
(1200 + npc_max_health())/1500]¹
-- the ability_modifier reduces the costs by ~2% per ability_level [realized by
math.exp(-0.02 * ability_value)]
-- the healing_modifier takes the (self-)healing of the bot in account, i.e. it
reduces the damage to be repaired in exactly that amount that the bot could heal
within the repair_time [realized by 1/(1 + bot_repair_time *
get_bot_healing_rate())]
-- damage is the npc_damage_amount()
-- constant limits the repair_time to a maximum of 30s and modifies the
cost-types (circ_costs are ~7 times and heat_costs ~3 times the time_cost)

The upper limit is hardcoded under the assumption that a 300 HP-bot with healing
rate 2 (i.e 0.2 with difficulty-modifier 0.1) is the most expensive bot to be
repaired. It could be dehardcoded or be computed by given most expensive bot
specs or whatever, if somebody wants that, but by now I don't see a benefit from
that ;)

¹ I skipped the logarithm, since it is not strictly necessary.

Hey, can you include a spreadsheet with your equations implemented in it?

The shear number of factors that we are using makes it very hard to evaluate how
well a set of equations works through playtesting alone. I think that we should
figure out the equations we want to use, and not worry about the actual
implementation yet, especially since the results are randomized to +/- 20% anyways.

---

To me the most important thing is that repairing the bots is:
1) fun, as in not freezing for too long, and 
2) balanced, as in not making the game too easy (e.g. repairing a Sawmill bot in
one second with no other penalty).

All of the other factors are by far secondary. It would be nice (but not
necessary) if the penalties went down as Tux improved various skills.

I think that the bot healing rate ( Druidmap[bot->type].healing_friendly ) can
be used as a proxy for the size of the bot. However, since this value is also
dependent on the difficulty level I think it might just be better to explicitly
use the difficulty level and the size of the bot here.

The spreadsheet is attached (bot_repair_eqs2.ods). However, I have to say, for
the biggest_bot_repair_value (that is the repair time of the Sawmill at max
damage) I used 241 in the diff, whereas the exact correct value would be 294.
You can easily adjust that in the spreadsheet in the cell
"biggest_bot_modifier". Obviously, the differences aren't that big. Please let
me know if you prefer the one or the other.

"The shear number of factors that we are using makes it very hard to evaluate
how well a set of equations works through playtesting alone"
I could make mathematical proofs, the formula will satisfy each constraint
listed above, if that would be necessary - maybe the constraint about the fun
could be a little bit difficult :D
However, the beauty of (multiplicative) factors is, that even an
non-mathematical user easily can see the changes from each input value without
even knowing the other inputs. That means, if you only now, that the
damage_amount afflicts the costs, but don't know any of the other factors, you
will easily see from the values ingame that double the damage will double the
costs. 
An other examples:
- If you increase your Repair_ability by one, all costs will be reduced by
approx. 2% - independently from the other inputs as bot types and damages (so
this is true not only for Acolytes, but also Sawmills and all in between and not
only if the bot has 1 damage or 299, but also in between).
etc. (I am sure, you've got the point :) ).

So, each input value can be evaluated on its own. That would not be possible, if
they were added/subtracted before multiplication.

Concerning the bot size:
In my proposal I used the max_HP for the bot size - as you intially proposed.
The healing_rate is NOT used for determing the bot_size, but only for the
computation of the healing the bot can make itself. Therefore, the bigger the
healing_rate the less costs the repair. Please also note, that the
difficulty_modifier is already included in Druidmap[bot->type].healing_friendly

I am totally ok with it, if you say, that the bot size should be computed by the
class or a some more sophisticated combination of bot attributes and not only
the max_HP. But for now, the max_HP are an easy and for the users easily
recognizable choice.
I would have no problem replacing it with a factor computed from the bot-class
or whatever. And it would be no problem at all for the formula, since you would
only have to change the one factor (bot_modifier) of the formula and it would
perfectly match into the overall formula without throwing up any problems with
the other factors. That's the second good thing about (multiplicative) factors. :)

Too much is being written about this small issue. Please take care not to paint
bikesheds, guys. :)

Patch committed in r5369. Thanks!