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" <http://www.freeciv.org/wiki/Math_of_Freeciv#Global_Warming_and_Nuclear_Winter> 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 object? *** 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 that. * 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: <http://gna.org/patch/?4104> _______________________________________________ Message sent via/by Gna! http://gna.org/ _______________________________________________ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
