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