Seat color is supposed to be used for teams

[Akien]

Like both of you, I'm not very fond of an ally being able to build in my base. But after all, if we take again an example on existing games (which is, IMHO, the easier way to find the best solution other people could find after thinking about the same stuff as we are), if we are ally, in most of RTS, I will be able to attack your buildings/units and build in your base (annoying you). And in a 2v2 game, if your ally is doing jerk stuff, you are sure to loose anyway. So I don't think we should go on something too complicated...

I mostly agree, I'd like the simplest solution to be implemented. As you say, it's not really our role to prevent allied players to doing funny stuff to each others base (in Warcraft for example, nothing prevents you from building a base inside an allied base, but of course there is no "claimed tile" mechanism there).

My main concern is that kobolds are not meant to be micromanaged, so they can end up doing funny stuff in the allied base against your will if for some reason their behavioural algorithm decides that the cave is darker, damper and more dangerous (thus more interesting!) at your ally's base :-). It's similar in other RTS (for example in Age of Empires your workers can end up snatching away the resources of allies if it's the nearest resource), but the difference here is that the impact is huge.

[Akien]

IMHO, we should just decide if :

- Can a kobold claim a tile if a neighboor is claimed by an allied
- Can we build on allied tiles
- Can we dig through allied claimed walls

It has already been suggested previously by Bertram I think, but how about going with something relatively simple such as this:

• Kobolds can't do anything on claimed tiles and walls of an ally
• Kobolds can't claim tiles or wall in a given radius around allied dungeon temples
• We implement a "I want these claimed tiles/walls, please give them to me" marker, that a player can use to mark claimed tiles/walls that he wants, and his ally can accept or deny the request. In later stages of development, it can evolve to be a bit more like Danimal's or Bertram's proposals (and to be better integrated in the game universe than a "request tiles" marker).

This would require a bit of implementation, but not too much IMO (we can reuse part of the code from the dig marker for example). WDYT?

[hwoarangmy]

My main concern is that kobolds are not meant to be micromanaged, so they can end up doing funny stuff in the allied base against your will if for some reason their behavioural algorithm decides that the cave is darker, damper and more dangerous (thus more interesting!) at your ally's base :-). It's similar in other RTS (for example in Age of Empires your workers can end up snatching away the resources of allies if it's the nearest resource), but the difference here is that the impact is huge.

That's exactly why I would allow to build on ally claimed tiles or to dig on ally claimed wall. Again, if your ally wants to harm you, he will be able to do so (at least by letting you fight 2v1). So, I don't think it is a problem to let him be able to build on allied tiles. This way, if he does that, you can leave the game earlier avoiding loosing time

And I can also see a good point with that by helping an ally to claim a strategical room or helping him to wall if strong heroes are nearby. Especially if it is an AI

BTW, I'm almost done with the patch. If you want, I can do a pull request and you will be able to test by yourselves

[Akien]

That's exactly why I would allow to build on ally claimed tiles or to dig on ally claimed wall. Again, if your ally wants to harm you, he will be able to do so (at least by letting you fight 2v1). So, I don't think it is a problem to let him be able to build on allied tiles. This way, if he does that, you can leave the game earlier avoiding loosing time

Actually yes, this doesn't sound as bad as it did. We can let allies build on your claimed tiles and consider that they won't do it without a sensible reason. For example an ally could build traps in your base to help you defend yourself. That's actually how most RTS handle it.

[hwoarangmy]

That's actually how most RTS handle it.

And to quote your example, as an RTS player, when I build something in my allies base, it is usually to defend them. Not to annoy them

[Danimal]

ok, seems sensible. Simple is best for now

[Bertram]

Seems you convinced everyone hwoarangmy.

Well, as it seems your idea is almost ready, let's see how it turns.

If we make maps that takes in account the fact that your ally must not step on your toes for the rest, sharing claimed tiles may be a good thing in the end.
Let's try it!!

[Bertram]

Thanks everyone for the whole discussion. Seems we are able to communicate even for tricky stuff, and I'm simply happy about this.

[hwoarangmy]

Seems you convinced everyone hwoarangmy.

Not really. It's just that it is the easiest way for now. As I said from the beginning, I've already gathered the code about that in the Seat class so it is easy to change. But for now, it would be enough

Thanks everyone for the whole discussion. Seems we are able to communicate even for tricky stuff, and I'm simply happy about this.

Yes, that's cool to have several opinions. Sometimes, point of views that sound tricky can open your eyes

[hwoarangmy]

Now that I think about it, I think the idea of the original coders for seats was to have several players in one Seat (not the best name for it, btw ) as we can see there :
https://github.com/OpenDungeons/OpenDun ... eat.h#L133

That would also explain why there was so much care about handling several dungeon hearts or portals. But it was a bit limitating since the only option in multiplayer would be to share everything (creatures, gold, ...).

What we have done is closer to what most RTS games do so it's probably better suited

[Bertram]

Heya,

What we have done is closer to what most RTS games do so it's probably better suited

I do strongly agree. The concept looks more streamlined in regards of the code readability, but...

Seat (not the best name for it, btw )

... as you say, not the best name for it, and neither for the "color", "colorValue", (and "colourDouble" even if it's a different area).

What do you think about: "GameSlot" or "Playerslot" instead maybe?


Best regards,

[Akien]

What does this "Seat" design precisely? Isn't it simply a player ID, and thus could be named "PlayerID"?

[hwoarangmy]

What does this "Seat" design precisely? Isn't it simply a player ID, and thus could be named "PlayerID"?

No it is a class where many things from the level file are stored (spawn pool, team, ...)

... as you say, not the best name for it, and neither for the "color", "colorValue", (and "colourDouble" even if it's a different area).

In my next pull request, as we said on github, I will change color -> teamId and colorDouble -> claimedPercentage (BTW, I will set it to private space).
Concerning "colorValue", it is an Ogre::ColorValue so that's not that bad.

What do you think about: "GameSlot" or "Playerslot" instead maybe?

Would be better names but do we want to rename that everywhere (Seats are much used) ?

[Bertram]

Hi,

In my next pull request, as we said on github, I will change color -> teamId and colorDouble -> claimedPercentage (BTW, I will set it to private space).
Concerning "colorValue", it is an Ogre::ColorValue so that's not that bad.

Fine to me.

Would be better names but do we want to rename that everywhere (Seats are much used) ?

If this is too much work, let's add an issue about it, and let that for later.
I don't want to put any useless pressure on your shoulders or anyone else's, we all have enough to do, anyway.

Best regards,