Follow-up Comment #3, patch #4104 (project freeciv):

Maybe this is an appropriate point to post a musing I've had for a while.

== Lua-scripted climate change ==

The current rules for climate change (see "Math of Freeciv"
on the wiki) are somewhat arbitrary, and ruleset authors might well want to
customise them, but they are baked into the game engine and not very
configurable at all (even numerically).

As a thought experiment, how much of the climate change engine could we move
into Lua script? What could we do to our Lua framework to enable this, and
ideally other similar ruleset-specific game features? What would we (or
ruleset authors) lose from this?

*Input:* It should be possible to hook this all onto the 'turn_started'
signal. To implement today's behaviour where it depends on pollution/fallout
on the map, the Lua function can do a 'whole_map_iterate'. _Missing:_ Lua code
can't actually see if pollution/fallout is on a tile currently; that would
need adding. (Per this ticket, this would be the code you edited to remove
that hardcoding.)
I don't know how much slower Lua is than C code, but hopefully any overhead
would be bearable once per turn.

*State:* The variables that accumulate climate change risk
(heating/warminglevel/globalwarming etc) could perfectly well be Lua global
variables; simply-typed variables are saved and reloaded in savegames, so can
be removed from the server C code (but see below for more on this). The most
arbitrary/tweakable part of the engine, the calculation, could be implemented
entirely in Lua and be completely up to the ruleset author.

*Output:* When the algorithm decides climate change has occurred, it must
change the world. In principle do-able, but there are several missing parts
(easily added): Lua can't change terrain type; nor has it got a way to know
map dimensions, necessary for current random terrain alteration (maybe it can
use 'server.setting.get()' on xsize/ysize but that's a bit of a hack). It also
needs to emit a message to players, which it can do with 'notify.event' (there
is a special event type E.GLOBAL_ECO that users can filter on, but in general
Lua-added functionality that we haven't foreseen won't be able to have its own
distinct event types).
To implement today's behaviour, this code would need access to
terrain.warmer_wetter_result etc from the ruleset (more on this below), and
also to terrain_control.ocean_reclaim_requirement_pct (can_reclaim_ocean()),
and to terrain type flags (TER_NO_CITIES), none of which are exposed currently
but could easily be.

*UI:* What the client sees must necessarily be fixed; we can't generalise away
from there being exactly two kinds of catastrophe ('global warming' and
'nuclear winter') which have a linear scale and particular sprites, because
that's baked into clients and the network protocol, and we have no way of
generalising it.
This is the strongest hindrance to ruleset authors unilaterally adding new
similar features entirely via script; at most they can notify players by
textual messages (perhaps disasters could have been implemented like this).

*Configurability:* One of the problems about pushing functionality and
configurability to Lua script rather than providing server and ruleset options
is that, if done lazily, it forces ruleset authors to code. It would be nice
if the requirement for this could be minimised; ideally an engine author in
Lua could make a parameterised engine which non-coding ruleset authors could
tweak by editing simple setting-like parameters. (For instance, we'd probably
want to provide a ruleset-adaptive Lua version of the current engine in
default.lua taking its parameters from the ruleset.)
Thoughts on possible parameterisation and how it might be achieved:
* The terrain transformations (warmer_wetter_result etc). Currently these four
ruleset parameters are *only* used in the climate change code, so if that were
moved to Lua the presence of these parameters remaining hardcoded in the
ruleset format would be an ugly restriction.
** Of course, once the climate change script becomes ruleset-dependent then
the transformation arcs could just be rendered directly in the code: "if
forest then jungle" etc. Can we do better?
** Perhaps we could arrange for arbitrary key/value properties not understood
by the Freeciv core to come from the ruleset (associated with terrains and
similar objects) and be accessible by name from Lua in a dictionary-like
*** We could just implicitly put any unrecognised property seen in the ruleset
in this dictionary (but this loses ability to spot ruleset typos and also
potential namespace management problems between us and script authors);
*** or we could give script-accessible properties their own namespace (and
move warmer_wetter_result etc into it).
** This would keep all the terrain knowledge in one place in the ruleset.
* Maybe the causes of climate change: if pollution/fallout become objects
(extras?) which are available as a type in Lua (not currently true), they can
have a property or flag associated with them in the ruleset ("WarmingCause")
that causes the Lua script to take notice of them. If ruleset authors want to
configure this they just change which extras have the "WarmingClause" flag and
don't have to understand whether it's the script or server that's interpreting
* The various parameters of the current calculation (currently not
configurable). Could these go in a specific ruleset's [script] section as
simple name=value type code setting global variables, and be picked up by the
parameterised climate change engine? (This also opens the possibility of
server operators being able to tweak these on a per-game basis via the /lua
command, where otherwise we'd have to add a full server setting.)

=== Conclusion ===

It would be possible with a fair amount of work to move the climate logic
entirely into Lua script where ruleset authors could play with it.
As usual when trying to do anything with our Lua interface, the gaps in what
we've got round to exposing become evident (usually when I think of trying to
do something I find at least one essential function/property I need is
missing). But it's just work to fill those gaps, nothing complicated.
There are some simple things we could do in the core to make script
parameterisation and configurability easier and not force ruleset authors to
become Lua coders.


Reply to this item at:


  Message sent via/by Gna!

Freeciv-dev mailing list

Reply via email to