patchFreeciv - Patches: patch #4156, Tracking player meta knowledge

 
 
Show feedback again

patch #4156: Tracking player meta knowledge

Submitted by:  Sveinung Kvilhaugsvik <sveinung>
Submitted on:  Fri 06 Sep 2013 04:54:17 PM UTC  
Votes:  10  
 
Category: generalPriority: 5 - Normal
Status: Need InfoPrivacy: Public
Assigned to: Sveinung Kvilhaugsvik <sveinung>Open/Closed: Open
Planned Release: 

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Tue 15 Oct 2013 09:41:32 AM UTC, comment #8:

> You've nothing to worry about with your tone.

Glad to hear it.

> I hope you didn't take any offense from mine

Not at all.


I did some work on server side action enabler evaluation last week using the two bit vectors approach. It wasn't posted since it wasn't finished.

> This way, the uncertainty is signalled to the player by the lack of a percentage chance that's usually there.

I like this idea. It should be broken down in smaller steps. By (at least temporarily) adding a special value for "probability not correct yet" the probabilities can be added in follow up patches. I'll try to port the work I did last week to this approach.

> here's a message sequence chart showing how the revised interaction would work:

I think it should be modified so it won't present the player with possible outdated information. Especially if the player must pay for it.
The approach I have used in my existing work is to add an extra round trip in cases where the server discover that multiple actions are possible. When the server discover many alternatives exist (say in a move) it will send a hint (actor and targets) to the client. The client will then queue the hint. When time has come to process it the client will ask the server about what the choices are in the same way as if the player took initiative to do a diplomatic action without moving the unit. (This will also fit better with the information price you are suggesting) The client then chooses like in your diagram.

> We might want to add the option for the client to try a particular action "blind" without getting the menu first

My plan is to add something that in the client will appear like "go to and do $ACTION".

> Exactly how much ruleset authors get to configure what the server sends for these action "menus" I'm less sure about.

I'll probably end up generalizing actions. Cost (and when its payed) should then be configurable.


> 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

Not trying to argue against sending the probability (your UI idea convinced me). How would the 3 states design would prevent this? Since I had moving regular attacks, movement and more to it in mind when I created it I would appreciate to know what I did wrong so I can learn.


> Whether an action is reported as chance=-1, probably via the effects system

As "counter effects" probably will show up as well a new concept may be required to make room for an extra requirement vector.

> I'd rather not add a third kind of thing like that.

If it is server side it could use requirement vectors, become rule set specific and be combined with the above.

Hmm... It we rename meta knowledge to "sensors" and rename "actions" to "actuators" our terminology will match the one used in AI text books.

Sveinung Kvilhaugsvik <sveinung>
Project MemberIn charge of this item.
Sun 13 Oct 2013 02:56:02 PM UTC, comment #7:

> 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:

(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.)

Jacob Nevins <jtn>
Project Administrator
Mon 16 Sep 2013 12:55:53 PM UTC, comment #6:

> The UI for presenting uncertain actions to the player is problematic.

Would you prefer that I keep the GTK2, QT, SDL and SDL2 clients in their current state (show without marking) in stead of adding a non obvious marking?

Sveinung Kvilhaugsvik <sveinung>
Project MemberIn charge of this item.
Sun 15 Sep 2013 07:28:24 PM UTC, comment #5:

> Sane?

For the record: If not I don't mind adding the data in C.

Sveinung Kvilhaugsvik <sveinung>
Project MemberIn charge of this item.
Sun 15 Sep 2013 07:26:37 PM UTC, comment #4:

> here's a brain-dump of my thoughts on the subject

Thank you for your feed back, Jacob. It is good to have a fresh pair of eyes look at the subject. 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.


> One reason is that if a bug is found in common code implementing game rules, only the server needs to be updated to fix the issue.

Good point. Even if the server sends the meta knowledge it would not fix reasoning bugs in the client. You mention the information leak (something I wish I had discovered before writing my own wall of text about it ;) ). A possible solution that would avoid leaking any information at all is to have the server send true, uncertain or false. To add a price (movement points, the life of the spy, etc) for the information like you (and Cazfi in bug #21105) mentioned is also possible. I have to think more about this issue.


> I think it would help to have examples of rules that you hope to implement through this.

Originally it was about fixing a problem I had introduced. Now I can imagine many different uses for it. It can be technical like a counter intelligence office building. It can also be something else, like a form of government that permit the player to poison cities belonging to less technologically advanced societies.


> It's not obvious that's always what you want; depending on what you're modelling, the spy might realise full well on that her failure is due to the Public-Key Cryptography tech possessed by her target, once she's tried intercepting the communications.

Agreed. I tried to improve the situation over the silent failure. I wanted to communicate that the reason may be unknown. I didn't want the game to "break the third wall". The plan was to get back to it later. Finding a way to make it configurable or come up with a better formulation is on my TODO list. If you think "Your Spy was unable to Sabotage Unit." is better I'll change it to that. (Unless you wish to change it your self)

> The UI for presenting uncertain actions to the player is problematic.

Agreed. I tired to improve the situation over not presenting them / presenting them unmarked. When adding support to the Qt client I added the standard warning icon. (Not sure if that is better) A "perfect" solution to this is still on my TODO list. How would "May be impossible at the moment" in a tool tip sound?

Should I start opening issues in the patch tracker for the stuff I have improved but aren't 100% happy about?


> I'd like to know more about your plan of moving "meta knowledge" into a data file;

The idea is a common data file no matter what rule set you use. This avoids maintaining a big "table" in C. It allows the server to send updated meta knowledge to the client (not relevant if its use is moved to the server). It is usable by non omniscient AIs not using the Freeciv C code that wish to plan many steps ahead.

> I don't see any sane way this sort of logic can be represented other than code, and compiled-in C code at that

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?"

Sveinung Kvilhaugsvik <sveinung>
Project MemberIn charge of this item.
Sun 15 Sep 2013 02:51:39 PM UTC, comment #3:

I'm kind of uneasy about this, but I don't have concrete suggestions, so here's a brain-dump of my thoughts on the subject. Sorry for the wall of text.


In general, I quite like the design we mostly seem to have where the client relies on explicit information that the server has provided about a game property in case of ambiguity, rather than inferring it from the client's knowledge of the game rules. (The existing bribe cost display is in violation of this unwritten principle.)
One reason is that if a bug is found in common code implementing game rules, only the server needs to be updated to fix the issue.

However, this is in tension with cases where the client UI needs to be more responsive than a conversation with the server would allow (e.g., drawing a goto line), and there the client uses its own knowledge of the rules. Ambiguities are rare, but one such is resolved by the client option "Allow goto into the unknown".

(This argument only applies to the client. Metaknowledge could be used by AIs without violating this principle.)

For the specific case of action enablers (e.g., for spy actions), I wondered if a bitmap of available actions could be maintained in the unit packet, hoping that delta compression would avoid too much overhead.
But spy/diplomat actions are in the context of a target tile (not the unit's current tile), so I think it'd have to be 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), whenever the client is about to do an action or is considering one, which implicitly leaks bits of server knowledge (e.g. player can infer from 0% chance of success in response that target must not have XYZ tech, if player knows the rules).
My instinctual preference is for this sort of an arrangement, but it would limit options for responsiveness (e.g. client display of possible actions when just hovering over target tile).

As cazfi has said, existing paradrop is a model for some of this -- you are allowed to try paradropping without certain knowledge (here the uncertainty is communicated implicitly to the player through map display -- fog-of-war -- rather than explicitly through menu markings), but if they fail, you get specific feedback -- the server grants you fresh knowledge of the map area around the paradrop, and a specific message like "Your Paratroopers paradropped into the Ocean and was lost / was killed by enemy units at the paradrop destination".
(In general, the map is where the most advanced existing notion of "meta knowledge" is -- the client has its map and knows it's incomplete, and the server has "player maps" and sometimes uses them, e.g. in do_paradrop().)

The paradrop example has the property that the client must commit to a course of action to get privileged information from the server, which my above design for actions does not; if no commitment is required then good game design suggests that all clients must request and present the "free" information automatically, rather than forcing the player to tediously scrub/micro-manage it out of the UI (or, worse, make a trick client to do it automatically). (See the "BTS Unaltered Gameplay" mod for commercial Civ4, which takes all the previous information you could extract by careful tracking or polling, such as when AIs become willing to make peace, and presents it right there in the UI, removing un-fun cognitive burden.)
So, to fix my design, we'd need "payment", which in this case could be, err, once the server has sent the information about available actions, the client must choose one of them or cancel, in which case it forfeits a movement point (because, erm, the Spy has spent time on reconnaissance to get the info)?

I think it would help to have examples of rules that you hope to implement through this.
I gather from bug #21105 that one such is a technology owned by the target which can prevent/enable spy actions; in this case, if the client doesn't know about the tech and sends a command which fails for this reason, I think (as of patch #4140) you've got the message "Your Spy was unable to Sabotage Unit and don't know why." I assume this means the Spy herself is supposed to be baffled as to the cause of her failure.
It's not obvious that's always what you want; depending on what you're modelling, the spy might realise full well on that her failure is due to the Public-Key Cryptography tech possessed by her target, once she's tried intercepting the communications. (Not that I can see how to do that sensibly with effects-based restrictions, but it does suggest that the "doesn't know why" message should be toned down to an unspecific failure -- "Your Spy was unable to Sabotage Unit.")


The UI for presenting uncertain actions to the player is problematic. Colouring menu options red has been suggested, but I don't think this is sufficiently obvious. Text coloration can't be the only way this sort of information is presented to users -- there has to be some more explicit explanation that the action is uncertain/dangerous, of which the colour is just a reminder once users understand the concept.
(We already have both red and blue tab coloration in the client, which at least one player I've spoken to doesn't know what it's trying to tell them and finds confusing. Seems to be gui_dialog_present()/gui_dialog_alert(), now I come to look it up.)

But I don't know what else. Maybe a tooltip on the action button? Clumsy, but the best I can think of. Also, I can't think what it would say -- "action may fail" is also true of actions the spy may try which have an inherent random chance of failure even with full knowledge. We can't even say "action may turn out never to be possible" as the relevant blocker may be relatively transient e.g. presence of a SuperSpy.
Which suggests to me that what we're trying to do here will end up being too subtle for players.


I'd like to know more about your plan of moving "meta knowledge" into a data file; I'm not sure what sort of data representation you have in mind, and am wary that it'd end up being code masquerading as data.

The stuff now in metaknowledge.c is not ruleset-specific, but rather an incomplete collection of inferences of the form "this action has a tech requirement" + "I don't have an embassy" => "display as uncertain", which (once made) are good for any ruleset. I don't see any sane way this sort of logic can be represented other than code, and compiled-in C code at that (trying to do it even in Lua would fail, I think, because every new thing you wanted to check in your logic would require C changes anyway to expose some new aspect of the server state.)

Maintaining the knowledge in metaknowledge.c feels quite similar to maintaining the on-line help that's autogenerated from effects: we can't hope to cover every corner, but we add cases for common patterns of requirements that people actually use in rulesets.
(However, for the help, I have the get-out of remaining silent if a condition is too complex to be matched by one of the existing patterns, and requiring ruleset authors to document their complex thing manually wherever they see fit; as the sophistication of autogenerated help covers more of the pattern space, sometimes we have to remove manual descriptions from rulesets because they're now duplicated. In your case I guess the equivalent would be defaulting to uncertainty.)

Jacob Nevins <jtn>
Project Administrator
Thu 12 Sep 2013 12:24:44 AM UTC, comment #2:

> make it possible to be more accurate (more FALSE, less uncertain) by sacrificing some performance.

To be clear: The current code in bug #21105 returns uncertain in some cases cases where it should be able to reason about what the real answer is. Returning uncertain is safer than giving the wrong answer as it won't surprise the user. Some potential ways of eliminating uncertainty will cost performance.

Sveinung Kvilhaugsvik <sveinung>
Project MemberIn charge of this item.
Wed 11 Sep 2013 11:32:19 PM UTC, comment #1:

Missing:

  • add support for gtk2, qt, sdl and sdl2
  • add more meta knowledge
  • make it possible for non programmers to contribute missing meta knowledge
  • support meta knowledge about requirements outside of requirement vectors.
  • make it possible to be more accurate (more FALSE, less uncertain) by sacrificing some performance.
Sveinung Kvilhaugsvik <sveinung>
Project MemberIn charge of this item.
Fri 06 Sep 2013 04:54:17 PM UTC, original submission:

The client isn't omniscient. If it was a modified or alternative client could cheat (by accident or intentionally). When a client evaluates a rule it has to use the incomplete information it has. Some of that information is always accurate. Some of it is uncertain but based on reality. Some of it is made up since the real information simply isn't there. It doesn't always know what is what. That should change.

This is a huge task. Many different kinds of knowledge are used by the client. Situations can change the status of one kind of knowledge. Many parts of the client use knowledge. Those should be reviewed. This has to be done in smaller steps.

I suggest starting by adding a function that tell how certain the result of a requirement vector on a collection of entities is when seen from the point of view of pow_player. It has the effect an embassy has on pow_player's knowledge of tech (flag) requirements hard coded. Perhaps the unseen/fogged/seen tile should be hard coded as well. When this is done a solution to bug #21105 can be written.

When that is done I suggest moving the meta knowledge to a data file. A data file don't have to be recompiled. It is easier for non programmers to contribute to. It will let programs that don't use Freeciv common, like clients that aren't written in C, use the data. If server side it will also let a fixed server give an old client improved meta knowledge.

After that more meta knowledge should be added. I'll update my Freeciv recorder to work with current trunk so its record viewer can be used to spot what information is sent to the client. Meta knowledge (fixes) should be requested in the help wanted forum (and reviewed quickly).

In the long run other users of knowledge in the clients should be reviewed in case problems similar to bug #21105 have appeared. Part of that will come for free as a side effect of my work on action enablers.

Sveinung Kvilhaugsvik <sveinung>
Project MemberIn charge of this item.

 

(Note: upload size limit is set to 1024 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Digest:
   patch dependencies.

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by gorb (Voted in favor of this item)
  • -unavailable- added by jtn (Posted a comment)
  • -unavailable- added by sveinung (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 10 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 5 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Fri 28 Feb 2014 11:31:32 AM UTCgorbCarbon-Copy-=>Added gorb
    Sun 15 Sep 2013 02:51:39 PM UTCjtnStatusIn Progress=>Need Info
    Sun 15 Sep 2013 12:44:50 AM UTCsveinungDependencies-=>Depends on patch #4182
    Sat 14 Sep 2013 08:38:42 PM UTCsveinungStatusNeed Info=>In Progress
      SummaryRFC: Player meta knowledge=>Tracking player meta knowledge
    Show feedback again

    Back to the top


    Powered by Savane 3.1-cleanup