Update of patch #4156 (project freeciv):

                  Status:             In Progress => Need Info              

    _______________________________________________________

Follow-up 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 <http://langsec.org/occupy> 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.)

    _______________________________________________________

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

Reply via email to