forum.freeciv.org

I have already written in many places about this concept, some of my patches that are prepared with it in mind are commited to git, but there is some controversy with other developers about details so I put it here for comment.

Different hardcoded rules and tokens of the game have different degree of interconnection with the bulk of other rules and the general conceptions that make Freeciv itself in our eyes. For example, the most general description of the game that seems not to be going to change ever within this project is sth like "playing in a tile-divided world where each tile may contain a stationary, resource-producing city and/or (usually) mobile, acting around units, both controlled by some human or AI player, with resources in general sense arriving and being spent in regular turns..." Some other conceptions (e.g. that citizens work tiles or are specialists, or the six main resource types) are discussable but changing them requires deep modification of both code and game rules. Some rules (e.g. ones of firepower modification, and especially coastal bombardment rule) can be changed in one or few observable patches, their effect on the game still needs good analysis but likely not much of it.

I name "gimmicks" the least fixed things in the game that act in one or two places in the code and might have acted much different in their form without much difference in the game's content if some programmer years ago would glance at another rock group picture on the wall. For example, Internet wonder reveals all cities, why wouldn't it, naturally, reveal cities of all civs having studied Computers to each other? The gimmicks I target specially as a developer are ones defined in effects: "Upgrade_Unit", "Reveal_Map", "Reveal_Cities" etc.

The callbacks I requested in a ticket were by intent placed at the moments when such bonuses arrive. Things random like these should be decided not by one idle mind but by as many as may bother writing a ruleset. An API flexible enough should be given to such ones, and let scripts do the thing in a softcoded way, cuz why to hardcode what is soft by its nature.

Some gimmicks are already softcoded to some extent, notably "Inspire_Partisans" one and hut entering (the former still is bound to a single unit type of the ruleset, and the latter uses special sort of extras but that is justified for the need of a workable explorer advisor). Why full softcoding is not done in v.3.1 even with "Upgrade_Unit" where the API is ready: the effects not only trigger the bonus, they also contribute to AI reasoning and to autohelp generation. My idea was using the effect hardcodedly for those purposes only while the actual bonus is given by a script that may or may not consult the effect value. But among other devs it kinda brought up shrugs and frowns since it's not a honest way of design; indeed it may misguide AI and give wrong help points, and the ruleset author needs much attention and reading lots of (hopefully, not yet written) friendly manuals to catch it. You can follow the links or search on the resources you know to see the other ideas how it should be done.

So, comments are welcome on should we actually unhardcode all the gimmick bonuses and how it should be done for better.

Unhardcoding stuff is good, but one point here is that you want to move stuff from the rulesets to lua scripts, which adds the requirement for ruleset authors to be able to code those scripts.

cazfi wrote:Unhardcoding stuff is good, but one point here is that you want to move stuff from the rulesets to lua scripts, which adds the requirement for ruleset authors to be able to code those scripts.

In my vision, all the stuff that is now hardcoded will be moved to default.lua. So, rulesets don't need containing any code on it if the author wants the standard behaviour. And for another behaviour, well they need some Lua but what could they expect else.

Ok. About that existing ticket, I hope that you and alienvalkyrie can somehow proceed with it earlier already, but if not, I plan to have a look to current master/3.2 development once I get S3_1-alpha3 out and don't need to focus to S3_1 so much.

cazfi wrote:Unhardcoding stuff is good, but one point here is that you want to move stuff from the rulesets to lua scripts, which adds the requirement for ruleset authors to be able to code those scripts.

Something to keep in mind here is that as rulesets become increasing arcane the 'programming' skills required for rulesets may rapidly approach those required for Lua. Ad hoc rules that get added from time to time just make this worse. Lua, at least, is (now?) reasonably stable, so once you learn it you're ready to roll.

A general issue discussed in the tickets is how to communicate back to the AI, (and this discussion is not new). In the case of hut enter one might consider providing a table of probabilities but this is a special case. There are various facilities already hardcoded that AI agents and advisors use to assess the value of 'doing something''. I have not read the code but I believe, for example, that this often involves actually doing 'the something' without commitment. Now this, of course, can be done in any programming language (see my version of _freeciv_state_dump for example), but in the short term use of the existing code would be expedient (unless one wanted to add more features - such as multi stage gardening by settlers).

Now maybe you guys are better placed to make informed opinions here but after considering this issue on and off for some time now the only idea that I could settle on was to provide a rather more direct environment for the AI in Lua. (And to a lesser extent other players.) I see that this can be approached from two directions. 1. A top down game director, that is Lua code that organises the end of turn activities. 2 A bottom up advisor/agent system, but one which would be reliant on hardcode primitives - at least in the short term.

An additional issue with (2) would be complex interactions with other parts of Lua coding, so I would consider a quarantined Lua environment. As I said elsewhere I would recommend starting with something simple such as the autoactivities. (Gardening, Goto, eXplore, patrol).