The Battle for Wesnoth Forums

I think it'd be very cool if allies who follow each other in the turn order in a multiplayer game could move at the same time as each other.

Here's my proposal as to how it'd be implemented:

Initially, at least, sim-move games would only be supported on a server. Not with direct connection (we might try to allow it on direct connection later though).

Players who are allies and whose moves directly follow each other could move simultaneously. The last player to move could not play simultaneously with the first player to move, since the current turn and time of day would be ambiguous.

Every time a player tries to move a unit somewhere, the client sends a [lock] request to the server. The [lock] simply contains the (x,y) location that the unit would end up at should the move go ahead.

That is, if the unit would stop early due to triggering an invisibility ambush or sighting enemy units then that is the position that would be locked.

The server sees if any other clients have that position locked. If another client has the position locked, then the server will respond that the lock cannot be made, since the position is already locked.

If the position can be locked, then the server records the lock, and sends a message to all other players notifying that the position has been locked.

Once a client commits its moves (can no longer undo) it will send the moves to the server, followed by a command to relinquish all locks. The server will then forward a message to other clients notifying them that all locks have been relinquished.

If a client undoes a move, it will send a message relinquishing the lock on the position originally moved to. Clients will record if a position is locked multiple times (e.g. if unit A moves to x and then to y, and unit B moves to X, then unit B's move is undone, the client will still maintain a lock on x because unit A still has it locked), and only tell the server that the position is unlocked if the lock count falls to 0.

Locks that other clients have will be displayed on one's client. Probably as a red tint over the hex. So, in the vast majority of cases, if one moves to a hex that isn't marked as locked, the move will go ahead once the server confirms that the hex can indeed be locked.

If a player does try to move to a hex that has just been locked, the player will soon see the hex marked as locked, and so it should be easy for her to understand why the move couldn't be completed.

If a position is locked on which a unit would stop to display a "unit's sighted" message, then that unit will behave as if a friendly unit were occupying that position, and will move to the next available hex and then display the "unit's sighted" message.

If a position is locked in a vacant hex next to an invisible enemy unit, then that unit will be considered visible. This is because it is now considered inevitable that the remote client will move next to that unit, since a movement next to an invisible unit cannot be undone.

If a player chooses to attack an enemy unit, then the location the enemy unit is on will be locked, using the normal lock method. An enemy unit can only be attacked if one has it locked.

When an allied unit moves in sim-move mode, the screen does not scroll to that unit and display its move as is the current behavior. Instead, if the destination and origin of the movement are both completely off the screen, the move will take place instantly. If the destination or origin are visible, then the move will take place, but the player will still have the freedom to move the screen around and control their units as normal.

(Of course, a lock will be held by the remote client on the hex being moved to, so the player won't be able to move a unit onto the destination the unit is headed for).

If a battle takes place it will run at normal speed whether it is on-screen or off-screen, and sounds will be played as normal. It is possible that if the battle is off-screen, the sounds will be softer. As with movement, this will happen simultaneously with the player commanding her units.

Once a player is finished with their turn, they can end it as normal, and the program will then consider it to be another player's move and behave as it normally does when it's another player's move. When all players in the team have finished their moves, then play will continue on to the next side after the sim-group.

It is possible that we could also implement sim-moves on direct connection games by having the host control locks. The major problem with this would be making sure the host always responds promptly.

Some WML tags may be difficult or impossible to support when using sim-moves. Among other things, events fired at the start of a player's turn would have different behavior. Events which move a unit from one location to another would probably work okay: they would try to lock the hex being moved to, and if a lock cannot be made, then the normal behavior that is used when another unit is on that tile would be used.

So...any thoughts on this? Any nasty problems which I might have missed?

David

Dave wrote:So...any thoughts on this? Any nasty problems which I might have missed?

I think it would make coordination between allies more complicated and require more conversation, which IMO is a bad thing due to the limited text-based communication in multiplayer.

It would also make hotseat multiplayer functionally different from network multiplayer, which is also a bad thing.

Also, how would the AI handle it?

I may have missed it in your description. Recruiting/recalling need to lock an hex too. The idea of locking is fine. But I have a major concern with events, see below.

Simultaneous friendly move is something I had envisionned some times ago, but I finally discarded the idea. For a reason you also thought about: start of turn events. This is a point I had absolutely no idea how to deal with, since it would have broken a lot of Wesnoth concepts. For example, units gain and lose HP at start of turn, players gain and lose money at start of turn.

So all the turns of allied players should start at the same time. Otherwise we would get dumb situations. For example, the allied players would rush to buy units before they lose money because they don't have enough villages. The allied players would rush their poisoned units on the enemy before they lose HP because of the poison (poison doesn't kill, so it's more interesting to fight first and then suffer from poison). And so on.

On the other hand, having all the players from a team start their turn at the same time seems strange too. In that case, it would be almost better to replace simultaneous friendly moves by shared ownership. All the allied players would be allowed to move all the units in one single turn. It wouldn't change much on the game mechanisms, except that the gold would be shared between the players. And I don't think it is that good an idea.

And so it's where I stopped thinking about this idea.

silene wrote: Recruiting/recalling need to lock an hex too

Oh yes, absolutely.

silene wrote: So all the turns of allied players should start at the same time.

Oh, yes, absolutely. I forgot to mention that. If sides 1, 2, and 3 are allied, then at the start of side 1's turn it'd also be the start of side 2 and 3's turn. They'd get gold, healing, etc, all at the same time.

Elvish Pillager wrote: I think it would make coordination between allies more complicated and require more conversation, which IMO is a bad thing due to the limited text-based communication in multiplayer.

It would also make hotseat multiplayer functionally different from network multiplayer, which is also a bad thing.

Well it'd be optional. People who don't like it don't have to use it.

But....discussing with other developers, there are alot of developers who DO want to use it very much.

Elvish Pillager wrote: Also, how would the AI handle it?

A good question. The AI probably wouldn't be allowed to be part of a sim-turn group initially, though later it might not be that hard to make the AI use it.

Hmmm...Couple of questions. If allies are considered to have different shifts during their turns, and I normally would be fighting at dawn, while my ally is fighting in the morning, then when we attack, we can alternate between different times of day in the same turn...this seems odd, so, wouldn't that say that all the allies turns would have to be the same time of day, or essentially, the same turn? If it is the same turn, I suspect that lots of things beyond just the movement and attack will need to be locked. For example, if I start an attack, I lock the attack, knowing that I will benefit from an aura of my allies unit. Does that supporting unit get locked from moving until after my attack goes through? Similarly if there ever were negative auras. Why just allies and not allow a free for all in simultatneous movement? If I trigger an undoable event, does that make all my allies turns undoable? If yes, ouch. If no, I can forsee certain abuses creeping up...

While it is an interesting idea, I also see it requiring quite a bit of work to get it to work properly. I personally love the idea of simultaneuous move games, I just don't see Wesnoth as really having been designed around it as a concept and think that it will end up feeling very Kludgy. Then again, maybe this is just because I don't play enough MPlayer games.

At the risk of being banned for life

"A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away." -- Antoine de Saint-Exupéry

edit: thinking about it more, it all might work, if you allowed whoever the next player is to prepare moves, while the preceeding player is making his moves. Perhaps this is what you had in mind and I just didn't get it. If so then it is A's turn, and he happily runs around doing his stuff. Instead of waiting B can start putting in moves, analagous to what is done when you tell a unit to move to a hex that is more than one turn away. When A is done with his turn, it becomes B's turn, and the moves he has queued up take place, just as if he had units that still had movement towards their target left over from the previous turn. I could see this working (and perhaps even improving Multiplayer delays) without having a significant negative effect on the game. In this case, your locking mechanism would have A making moves that lock B's moves, but B does not lock A's moves. If there was fog of war, this would enable some sort of faster than gryphon communication, but I don't see this as a problem.

Darth Fool wrote:If it is the same turn, I suspect that lots of things beyond just the movement and attack will need to be locked. For example, if I start an attack, I lock the attack, knowing that I will benefit from an aura of my allies unit. Does that supporting unit get locked from moving until after my attack goes through? Similarly if there ever were negative auras.

Good point. A situation may happen when I attack next to ally's White Mage, expecting his aura to work for me... and at the same moment ally decides to go away.

Darth Fool wrote:If I trigger an undoable event, does that make all my allies turns undoable? If yes, ouch. If no, I can forsee certain abuses creeping up...

Undoing turns simultaneusly... For example I move my unit somewhere else. Ally moves his unit to place where my unit was originally. Now I cannot move my unit back; I cannot undo my turn.

Generally, players could gain more advantage then only faster playing. When together attacking enemy, changed order of attacks could help; e.g. my ally (player #2) will use "slow" attack, and then I (player #1) will kill the slowed enemy unit. Or ally will kill an enemy unit to make place, where I can put my unit. Etc. I do not know how much these advantages would be profitable, but there are some things to exploit. In the game "2 players against 2 players", if one side (ab)uses this feature, and the other side does not, they may feel like the opponent is cheating.

The #1 benefit of this, of course, lies in the ability of it to provide for a much quicker playing experience. Playing an online game of wesnoth is dog-slow right now - a decent 4-player game takes several hours.

This, I think, is somewhat of a basic flaw - a truly root problem in the game. It ruins most large games played online - I don't think I've finished much of anything bigger than a 3 player free-for-all game. Most four-player games I've been in have had a player drop, and then the game bugs out.

In any event - I really do think we should investigate this, even if it is a difficult and complex thing to do. Making wesnoth is like building a bridge - we can build a lot of little parts, but every once in a while, we need a big part to hold the rest together - even bridges built of small stones needed a huge wooden frame when the rocks were being laid.

I think the idea is interesting, though a bit complicated, but if the devs want to try it, I see no problem at all: If it becomes of little interest or problematic, you will indeed note it and take the appropiate actions.

About the idea itself, I think it would be nice if there were a way to 'see' the movements your allies are making while you make yours, and not just a 'commit all', because then it's easier to coordinate moves (like, say placing your healers behind the fighters of ally B, while C places his leaders as well). Something like a half-transparent image of the units in their planned positions and maybe a 'commit now' button, so it is easy to note what are the correct positions of the units to plan your moves, and it's easier to use shared time between allies (no big updates)

Nice idea, overall.

I disagree with this, because it fundamentally changes the game. It will become RTS instead of TBS, and it will be harder for allies to work together. Also, it will be harder to implement events.

Uhh...sorry for not being clear: this thread is for coders to discuss the code implications of this change. Not for people to generally say whether they like the idea or not. (Hence it's presence in the Coder's forum).

If you want to discuss whether you like the actual idea or not, please take it to another forum.

David

Hmm, most MP scenarios try to alternate sides for balance, something like

side 1 player A
side 2 player a
side 1 player B
side 2 player b
....

with this method there would be only two turns
side 1
side 2
side 1
side 2

this would mean a much stronger "rush effect" since all your oponents would move together against you, then you against them...

I think it would be much less interesting on a strategic point of view...

no the only way I thought of having simultaneous move working would be to have it limited to units that are not yet in the fight i.e that are out of all potential LOS of ennemy units...

Looking at this old(ish) thread, and mulling over all the coding complications, I wondered if you had considered the idea of permitting players to claim areas of the map. A screenful at a time, say, perhaps much more. Each player has total control within whatever areas he has claimed. [Edit: "If you move a unit of yours into an area controlled by an ally, you relinquish control." No, that's not right. See next para.] You might still have problems along the boundaries, but as long as the edges of control are clearly visible, squabbles should become a non-issue. Especially as I gather this idea is to speed the game up rather than to offer new tactical opportunities.

You would be able to see which areas you and your allies control. To transfer control, you would presumably move your unit towards where it's wanted, and where it doesn't interfere with the rest of your own side, then assign control of it to your ally.

I think you would need to be able to give control to anyone, but only /take/ control with other players' agreement. Where you have a wild melee where all sides are mixed together and no one wants to give up control of their own units, just use the existing turn sequence. i.e. those areas would be flagged as 'only the active player has control, and then only of his own units'.

Five obvious areas to define spring to mind: A given radius around each player's keep; a particular screen-sized area of the map; subject to agreement with your allies, the one-turn movement radius of a particular selected unit (Chat: "Even though he's on your keep, I want to take control of my scout. Is that OK?"); a drag-box area as chosen by a player; and, probably the easiest, all hexes that only one player can move to. In all cases I'd add an extra hex or two radius round the outside to give some margin for error, or to allow for ZOCs and what have you.