wesnoth-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Wesnoth-dev] Simultaneous moves


From: David White
Subject: Re: [Wesnoth-dev] Simultaneous moves
Date: Thu, 10 Feb 2005 18:43:37 -0600
User-agent: Mozilla Thunderbird 0.8 (Windows/20040913)


I was however wondering if the optionality should not in fact be set by WML, that is left to the map/campaign developers? If it was, then it would be up to them/possible for them to take simultaneous moves into account when balancing the scenarios. Because I think it would be very hard to balance a scenario so it works well both with and without simultaneous moves.

Personally I don't think that the effect on the game will be as much as many people seem to suppose. In most human-ally-vs-AI games I play, I would say that 80+% of moves I make are in theaters of battle totally seperate from my human allies. I would imagine that in the remaining 20% of situations, where human allies are fighting with their units in close proximity, a simple convention would arise: something like the player with the lower side number moves their units in the shared theater first, and then the next player moves, except in situations where it would be of tactical advantage for the second player to move some units first, in which case the first player might say so, and the players could discuss it.

I think that the only time it would be of real concern is in scenarios where there are extensive complicated events. A campaign such as HttT could probably handle sim-moves very easily, because it's not event-intensive. A campaign such as Under the Burning Suns possibly couldn't. For that reason, we might want to have a way to disable it in WML. But by default, I think it'd be up to the player.

Personally, the kind of games I'd want to play co-op wouldn't be very storyline or event-intensive. I don't think such games work so well in co-op mode anyway.

Anyhow, after talking it over in the forums, and the very helpful feedback from silene, I am thinking we should delay implementation of this feature until after 1.0, since it will be quite difficult.

David




reply via email to

[Prev in Thread] Current Thread [Next in Thread]