Almost exactly a year ago, I wrote a long idea about a UI for coping
with generic roads and bases. I've reproduced it below.

Does anyone fundamentally object to this sort of thing in principle? If
not, I'll raise a ticket and, who knows, maybe one day even look at
implementing it.

Previously I wrote:
> In patch #2951, Marko Lindqvist writes:
> > I'm playing with the idea of retiring simple specials completely. They all
> > could be made in to bases (ones that cover single tile) or roads (ones that
> > connect between tiles).
> 
> I was thinking the same thing.
> 
> If nothing else, the built-in help is going to be a bit odd when each
> road type has its own topic, and irrigation/mining are the only
> activities left in the main help.
> Clearly irrigation/farmland could be "roads" (although we'd need a new
> name for the "activity class") and mines could be "bases".
> 
> The main obstacle I can think of will be UI, and in particular,
> assigning keystrokes to activities. We fudged this for bases with
> fortress-like / Type A ("F") and airbase-like / Type B ("E"), 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.
> 
> I'm not sure what the answer is. The best idea I've thought of so far:
>  - 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).
> 
> Any thoughts on this solution, or alternative ways of solving these
> problems?

_______________________________________________
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

Reply via email to