Re: gnibbles, choosing time to spend on level

[Luke Page <eatthebean gmail com>]

> > Not too push the boat too much but the suggestion given last month to
> > another guy to make it so that in multiplayer when one worm dies, it
> > stays there but the live worm(s) can carry on (or possibly when more
> > than 1 player is left it carries on although one person is dead)... is
> > this something you would like to see and would you want it as an
> > option or hard-coded?
> Because of the whole network game thing we are going to have to have
> multiple rules sets (i.e. newer versions would have to play with the
> rules when connected to older versions) so within the game there has to
> be some sort of option, although it should probably only be exposed in
> the new network game dialog as a choice of which rules to play.

So a new version of gnibbles plays with an old version of gnibbles by
detecting its an old version and using the old version ruleset... So
initially any game changes would be invisible and internally treated
as preferences.

I may achieve this by having two properties values... (e.g. struct
properties ui_properties; struct properties properties; ) a user
interface properties and a game properties that then gets updated at
the end of a game.. e.g. to sepeate the preferences shown in the UI
with those in the game by a layer... then network games can change the
preferences to be compatible and not worry about it changing user
preferences. certain things such as key-press's, colours can allways
be updated immediately.

the settings menu needs to be disabled during the network game
start-up process.. this means I will have to alter network games to
call a network_game_cancel when a game is not started.. this will
enable the settings menu to fix my bug.
 
> So, in response to your other email about network games. There has to be
> ruleset negotiation in the protocol (I had the vague feeling there is
> room for it, but I haven't looked at the code recently). To keep it
> simple, a set of versioned rulesets where each clients supports
> everything up to their version is probably the way to go. If the
> parameters are generalised internally this shouldn't be a problem.

There is room yes.

> As far as enabling/disabling preferences, my desire is that every game
> can always have its preferences altered. For single-player games
> settings which change the form of the game start a new game. For
> multi-player games there should be some UI to negotiate the end of the
> current game (in the first instance it should tell the person fiddling
> with the settings that they are about to break something and get
> confirmation before telling their opponent so they can avoid doing
> appearing stupid).

Remember that during a network game, settings do not pause the game...

so you are suggesting ... (to check)

Network Game
----------------------

1) Settings pause the player who clicks settings (this would be
backwards compatible but means disabling pause would be a waste of
time)

2) The normally disabled options that break the game e.g. number of
players, level start etc. (I forget them all) will be enabled but on
close options say "are you sure, this will end the current game?".

3) The normally disabled options that don't break the game e.g. speed,
random level will update the options via network if the version is
high enough and carry on, otherwise warn user.

4) The local options that are enabled will continue to work as normal

Normal Game
--------------------

I don't see how any option has to break the game...

Having defined what I think your saying I'll disagree (sorry!).. As
above but I think that options that break the game, e.g. number of
players in network game should be disabled. I think this because
seeing it enabled the user will assume it updates instantly..
otherwise what reason does a user have for changing options that will
break the game?

E.g. If I am playing a multiplayer game then why would I want to pause
the game to change options that won't take effect till the next game?
If I was playing x games in a row then this might affect things, but
it is not currently possible (or desireable?).

> In the case of the worms-hang-around suggestion, my thoughts are that
> the worm should probably hang around, but slowly decay (i.e. the end
> disappears as normal, but the head isn't progressing).

thats a good idea.