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[1] 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?
> [1] "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
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
