Follow-up Comment #7, patch #4156 (project freeciv): > When you read my reply please remember that I'm not a native > speaker. If I got the tone wrong try to remember that I'm not > trying to insult you. You've nothing to worry about with your tone. I hope you didn't take any offense from mine; I'm just thinking out loud, really. And sorry for taking so long to reply! -- thanks for the changes in this area you've submitted in the meantime.
(This is a bit rushed as I have to be elsewhere; sorry I've not replied to all of your points explicitly.) ---- > A possible solution that would avoid leaking any information > at all is to have the server send true, uncertain or false. I've been thinking about this, and have come up with an elaboration: for each action, the server sends a percentage chance of success along with each possible action, or some sentinel value like -1 for "unknown". This would incorporate any existing well-known success chances for diplomat actions, which previously players have only known to players through documentation. It's displayed thus: * chance > 0: option displayed as "Poison City Water (75%)" * chance = 0: option displayed as "Poison City Water (0%)"?, greyed out and unselectable * chance = -1: option displayed as just "Poison City Water" This way, the uncertainty is signalled to the player by the _lack_ of a percentage chance that's usually there. (We can back it up with a tooltip.) (Alternatively: server supplies a range of chances, like "25,50" for 25-50%. Total uncertainty is signalled by "0,100".) Combining this with my previous notion: >> an explicit "what actions are available for this unit to do >> at this target tile" request from the client and response >> from the server (yes/no bitmap per action, or percentage >> chance of success, or something) here's a message sequence chart showing how the revised interaction would work: Player Client Server | | | move_unit |------>| | UNIT_MOVE | |------>| Attempted move | | | (optionally charge movement for information) UNIT_ACTIONS | |<------| List of available actions + chances pop_up_menu |<------| | choose_action |------>| | UNIT_ACTION | |------>| Chosen action type | | | (take action) | | | (charge rest of movement for actual action) stuff | |<------| Results of action | | | (There would need to be similar arrangements for "sub-menus" of actions, like choosing which building to sabotage.) The "forfeit" here is slightly different from what's implemented in patch #4199: in my design the cost is for information, in yours it's the cost of failure. We might want to add the option for the client to try a particular action "blind" without getting the menu first (I've found my diplomats tend to get killed while I'm choosing from the pop-up), in which case your style of forfeit would apply. Aside: one thing I like about moving to this model is that it allows actions other than movement/attack to be made by other kinds of units: as far as the client is concerned, UNIT_ACTIONS can be sent for any unit in response to a move request. (If an attack-capable unit had other possible actions, we'd just add an action "Attack" to the menu sent by the server, probably with chance=-1; in the common case where units can't do anything other than attack this would be considered implicit by the server, and the interaction would be as before.) ---- Exactly how much ruleset authors get to configure what the server sends for these action "menus" I'm less sure about. I feel that ruleset authors should have some influence over: * How much movement, if any, is charged for just getting information (I think free information on request is bad game design, but I think that should be left to the ruleset author) * Whether an action is reported as chance=-1, probably via the effects system (parameterised on action and everything else, so e.g. you can require improved spies/tech can allow you to get a better idea of chance of success before committing. ** (Or if server supplies a range of chances, numeric value of effects let you specify how accurate the range the client sees is. E.g., action_change_reporting = 4 allows ranges 0-25%, 25-50%, 50-75%, 75-100%; =100 gives you full accuracy; =0 gives you full uncertainty.) ---- [re "meta knowledge" data file] > I was thinking about using a decision tree structure. Each > attribute is tested only once (if at all). C code for > checking each attribute has to be added. The knowledge about > what attributes proves that a requirement is known is data. > (When it comes to the file format many options are on the > table) Sane? >  "Can I see this tile?" "Do I have an embassy with this > player?" I still think that most of the work here is in exposing the right attributes, rather defining new combinations of already-exposed attributes -- especially for attributes that are parameterised ("visible(tile)", "embassy(player)" -- of course you need to represent whether e.g. "player" is you or the action target or whatever in context). We've already got two places where these kinds of attributes can be exposed outside C -- the effects system, and Lua -- and we're forever finding attributes that are readily available to C code but not exposed in this way, and generally it's a moderate amount of work to expose a game property as e.g. an effect. I'd rather not add a third kind of thing like that. I guess it would be instructive to consider how much harder a change like patch #4203 might have been if the logic was expressed in external tabular form -- what attributes might we have needed to add? (Unfortunately I've run out of time today to try the thought experiment.) _______________________________________________________ Reply to this item at: <http://gna.org/patch/?4156> _______________________________________________ Message sent via/by Gna! http://gna.org/ _______________________________________________ Freeciv-dev mailing list Freecivemail@example.com https://mail.gna.org/listinfo/freeciv-dev