Share kingdom on multiplayer

[aggro80]

Several people are missing the feature that original
Settlers had, where you can share a kingdom in
multiplayer mode and work together to build and defend it.

[nobody (nobody-users)]

Logged In: NO

That would be sweet!

[Raul Ferriz (raul.ferriz)]

Please create a complete blueprint for that if anyone is interested on.

[SirVer (sirver)]

I'd also love this feature ;). 2 on 2 games with just 2 tribes on a big map. SWEET!

[Nasenbaer (nasenbaer)]

I added basical support for this feature in bzr revision 5511 of trunk

General behaviour until now:
if a player selects this option, the script checks if a player with smaller playernumber is in the same team, as the player and if yes, combines these two players. Else the player will be handled similiar to the "headquarters medium" initialization.

What the script does not do:
It neither checks for team mates with higher player numbers (that did not select "share kingdom" nor does it change the behaviour of the initialization of the other mates.
And it does not care about savegame loading - this is one is a "must have", thus I set the report to "in progress" until that feature is implemented.

I think the easiest way to implement this, would be to start a corountine, that switches players automatically, but I am not yet sure about the best way to implement this.

[Nasenbaer (nasenbaer)]

Savegame loading works via a coroutine, so I set this to fix committed. :)

[SirVer (sirver)]

Mmh... I feel this is a bit an hackish approach. Imho it should be possible to play all win conditions as a shared kingdom. I guess we need to implement this in c++ then. I'd vote for setting this to in progress.

[Nasenbaer (nasenbaer)]

Well I think this is a mixture of missunderstanding and feature design question. :)

First of all: this is not a win condition, so you can play "shared kingdom" with all available win conditions. How the seperate players are handled in a win is another question - however it should not be to hard to add a function call that tells the point calculator, that a player was in a shared kingdom (so the player was not defeated, if the win condition says so, but was never initialized).

In case you wanted to write "it should be possible to play all starting conditions as a shared kingdom" - somehow this is possible - here is the game design question.
As far as I can remember the shared kingdom feature of settlers 1 was a normal start (like the start of a single player). So nothing more than the normal headquarters.
Here is the difference to the implementation I wrote, as every player in a shared kingdom gets it's own headquarters - this can of course be changed, so only one starting position with one starting condition is used. The first player in a shared kingdom game can choose any starting condition anyways - so if only one starting condition is used and all other "sharing" players are just assigned, the starting conditions for shared kingdoms and normal players would be 100% the same.

However you of course can not have different shared kingdoms in a team (although 1 shared kingdom + other players is possible), so I agree, that the implementation is not optimal. :)

And last but not least:
If this feature should be rewritten in c++ code, please unassign me, as I do not have the motivation to rewrite it at the moment ;)

[SirVer (sirver)]

I jut want to report that it doesn't work as advertised. Hanna and I just tried to play together, but even though we had a shared kingdom and she could see all that I was doing, her commands were completely ignored. She was unable to build anything or do anything that requires a playercommand to be send.

[Nasenbaer (nasenbaer)]

Oh... In fact quite a logical thing - clients can only send playercommands for "their" player - haven't noticed that problem, as i mostly tried it in local games (and so as host)

Okay so one more point *for* a c++ implementation.. :-/.
I will see whether there is an easy way to fix this.

[Nasenbaer (nasenbaer)]

Well... forget everything I wrote ;). I will reimplement this feature in c++ code.

Sorry for the inconvenience!
Again I have to see, that it's better to create a dev branch at first, even if the change seems unproblematic...

[SirVer (sirver)]

no problem. Will you back out your changes or are they to be kept in trunk?

[Nasenbaer (nasenbaer)]

I think I will leave the lua switchplayercommand in the c++ code - might be useful for scenarios (who knows perhaps someone changes sides ;) )
However i will remove the lua starting conditions, as they do more harm than they are useful at the moment.

[SirVer (sirver)]

nice work dude. I will test drive this with Hanna as soon as possible :)

[SirVer (sirver)]

Released in build16-rc1