URL:
<http://gna.org/patch/?3756>
Summary: RFC: UI for building generic roads, bases, etc
Project: Freeciv
Submitted by: jtn
Submitted on: Tue Feb 26 23:46:55 2013
Category: client
Priority: 5 - Normal
Status: None
Privacy: Public
Assigned to: None
Originator Email:
Open/Closed: Open
Discussion Lock: Any
Planned Release:
_______________________________________________________
Details:
(Updated from a [http://mail.gna.org/public/freeciv-dev/2012-02/msg00224.html
post to freeciv-dev in Feb 2012.)
We now allow rulesets to define arbitrary sets of bases, and from 2.5, roads;
we're heading towards all tile "extras" being handled the same way (see
comments in patch #2951). However, we only have a fixed set of keystrokes
available in the UI, which is going to be an obstacle to ruleset authors
making use of this.
For bases, we fudged this for bases with fortress-like / Type A ("F") and
airbase-like / Type B ("E"), assigned in the ruleset, but if we're introducing
the same generality to much more frequently built infrastructure like roads,
we need a better solution, I think.
On the one hand, we don't want to restrict rulesets to having at most one
valid road-like activity in a given situation (as with the default rulesets)
-- I think ruleset authors should have the freedom to have a unit that can
build any of five different road types on a given tile at a given time, if
they want. Nor should rulesets be penalised by forcing players to go through
menus to select activities if the ruleset differs too much from a traditional
one -- activities should always be keyboard-selectable.
On the other hand, available keystrokes are a scarce resource, so we probably
can't give ruleset authors free rein over the entire keyboard -- we need the
freedom to assign new keystrokes in future (for activities like "convert", or
for out-of-game actions). I suspect we'll have to limit all these activities
to using R/I/M/F/E.
Here's a sketch of a UI design to deal with this:
* each activity gets a keystroke specified in the ruleset from the limited
pool
* each activity within the same keystroke group gets assigned a unique number
from 0 to 9 (by the server, or maybe the ruleset)
* if a keystroke is ambiguous -- say, "R" is for both Road and, er, Cycle-path
-- then the player can type "R" followed by "1" for Road and "R", "2" for
Cycle-path
* the game pops up a little menu after "R" is pressed listing "R,1: Road, R,2:
Cycle-path" to remind/introduce the mappings; this goes away when a number key
(or Esc) is pressed
* the game tries to spot cases where the keystroke is unambiguous (like
today's Road / Railroad -- only one is ever valid, at least for a single unit
or units on the same tile) and enacts the relevant activity immediately on
pressing "R" (so simple rulesets don't get the penalty of the multi-level
selection system)
* keystrokes "0" through "9" do nothing if typed outside of activity selection
(so if you type "R,1" where Road was the only option, you end up with what you
wanted -- you don't have to second-guess whether you're about to press an
ambiguous key)
This satisfies the following criteria:
* Can have lots of activities (up to 10 per keystroke -- still an arbitrary
limit, but a much bigger one)
* Keystrokes for a given ruleset are discoverable (through the menu system, or
the popup when you press "R")
* But experienced players don't need to use the menus, and keystrokes for a
given ruleset can be learned and communicated ("R,1" always means the same
thing)
One of the trickier parts of the above system will be the logic to spot
unambiguous situations. However, it doesn't matter if it's not perfect.
Would also need to account for "connect-with-X", but that seems do-able as an
extension to the above.
The other awkwardness with bringing the existing irrigation and mines into
this system is the terrain conversions that the "I" and "M" keystrokes can
trigger (e.g., "mining" grassland to forest). So, terrain conversions would
need to be pulled into the above keystroke system, or whatever else anyone
suggests.
With the above system, there would be no need to restrict given keystrokes to
"activity classes" -- R wouldn't have to be only for roads (although ruleset
authors may choose to do it that way). That would allow the I/M keys to retain
their current behaviour in the standard rulesets (and probably add "O" to the
pool of available keystrokes).
(This idea should probably be considered in combination with the ideas in
patch #3713 and bug #16905 -- particularly the ideas of non-focus-stealing
popups during keyboard action selection, and entering long strings of orders.
But there's no particular reason their implementation would have to happen all
at the same time, I think.)
_______________________________________________________
Reply to this item at:
<http://gna.org/patch/?3756>
_______________________________________________
Message sent via/by Gna!
http://gna.org/
_______________________________________________
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
