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
[email protected]
https://mail.gna.org/listinfo/freeciv-dev
