[Freeciv-Dev] Re: (PR#11858) Voting clean up

["Jason Short" <jdorje@xxxxxxxxxxxxxxxxxxxxx>]

<URL: http://bugs.freeciv.org/Ticket/Display.html?id=11858 >

Per I. Mathisen wrote:
> <URL: http://bugs.freeciv.org/Ticket/Display.html?id=11858 >
> 
> Playtesting yesterday revealed to me a huge problem in voting: The nice
> 'more options' button, if used in pubserver games, or other games where
> you do not have CTRL cmdlevel, is unable to set more than one option at a
> time, and each of those have to be voted upon by everyone present.

Of course.  I thought this had been reported long ago.

> So what do we do? There are several options. First, we can make the /set
> command cmdlevel_info until the game has started. This fixes the problem
> for 'more options' button, but not for commands like /cre a, /team a ai,
> etc.. We could make a whole lot of commands cmdlevel_info in pregame only,
> though (set, create, team, ai, novice, hard, easy and normal).

Not a bad idea.

> Second, we can change voting so that instead of overwriting your previous
> vote and getting a vote on each suggestion, as is now, each command that
> needs voting for is queued up until you type "/vote start". Then a list of
> options to be voted over is displayed and is voted over as a whole. This
> has the disadvantage that such changesets, like votes are now, can be
> rather cryptic, like "set endy 5000, cr ai1, tea ai1 ai". Expanding these
> on the fly is non-trivial, I think.

Doesn't sound so good.  You could have an extremely long voting session 
since you can have multiple votes on the same thing.

> Third, we can grant automatic firstlevel to the first player (the "game
> owner") to join. This is the only player who can change stuff in pregame,
> and has cmdlevel_ctrl to do this. If that player disconnects during
> pregame, the game is reset. This has the advantage of being very simple
> and easy to understand.

But in that case why do we have voting at all?

> However, none of the above solutions bring us any closer to a solid and
> user-friendly way to represent any vote for the user with a GUI. While the
> third solution removes voting from pregame (perhaps excepting /start?), we
> will still have voting during the game.

My suggestion would be to remove voting and replace it with a game-host 
method.  The host is the player who has been connected for the longest 
and automatically (regardless of any firstlevel settings) is bumped up 
to ctrl access.  This is, I think, what just about every other 
multiplayer game does so it's what players are used to.

-jason