[Freeciv-Dev] Re: (PR#8455) Bombardment (aka ranged attack)

["Per I. Mathisen" <per@xxxxxxxxxxx>]

<URL: http://rt.freeciv.org/Ticket/Display.html?id=8455 >

On Mon, 5 Apr 2004, rwetmore@xxxxxxxxxxxx wrote:
> It is not unreasonable for there to be an options effect and test strategy
> document along with results and even code/test plan created as part of the
> review proces for this patch. That would both show up any problems and
> hopefully make the future maintenance manageable without leaving it all to
> the maintainers downstream, i.e. calm the FUD aspects.

The problem is that even if you did this, we would still have creeping
bugs surface due to changes in other, seemingly unrelated code, that are
never (or takes a long time to be) detected by developers or reported by
users. (Most users do not report bugs.)

The real solution to handle this is unit testing and release test plans.
However, these balloon up in size for each added option, and we currently
have neither. Not to mention that such things that a lot of time to make
(and ridiculously boring - trust me, I've done this in my day job; I also
started writing unit testing for freeciv a few years ago).

<rant>

This idea that everything should be configurable or optional is annoying
me no end. It is a downwards spiral that does not seem to end until we
hand the user a C compiler and tell him that he now has everything he
needs to implement his own Turing machine.

We should identify the real _needs_ for configurability, as in "what game
mechanics will this allow that people may want to use in a modpack", not
as in "it is entirely possible that someone somewhere will want to run
freeciv with this option tuned a little bit different than everyone else".

Instead of catering to the tiny percentage of users who might want to fine
tune their own freeciv ruleset, we should work to fine tune the default
freeciv ruleset for everybody.

Example: tech_cost_style (www.freeciv.org/lxr/source/common/tech.c#L344).
How many players have tested this? It sounds really good. The code is
presumably still good, after I discovered and fixed some bugs two years
ago that had been there, undetected for quite a while. Briefly before the
1.13.0 release we tried to make tech_cost_style 1 the new default. Turns
out, this option was not really thought through very well. The resulting
tech cost curve was not workable (nor was it intended or documented), so
we reverted back to the old default again. But the option was not fixed,
and it is still not good, although it still looks like a nice
configurability option. How many other options, almost never used, are in
the same shape? I don't know. Nobody knows. That is _not_ good. It is a
false pretense of configurability.

</rant>

  - Per