OD - Fixing the Multiplayer

[Bertram]

I'm eager to test it.

Btw, have you seen my comment about the node names vs several game map instance? I don't know whether I'm clear enough and whether my comment isn't stupid, yet. But I will investigate more asap.

In the meanwhile, could you tell me a few things? (I'm starting with the basics to make sure of a few things.)
- In multiplayer mode, is the local player (the one hosting) sharing the game map with the server or is there actually two game maps instance even in that case?
EDIT: Well, now I've looked at the code, the answer is rather obvious, eh. Yes there are two game map, not shared.
One in the ODFrameListener, and one in the ODServer.

- Is it the same in single player mode?
- Are remote players only using one game map instance?
EDIT: It is the same way to work (as for game maps) on both side. And I have seen you answered on github. So let's finish this there.

Regards,

[hwoarangmy]

Since the full server patch, the behaviour is the same on single player or multiplayer : 2 different game maps.

I was planning on writing a wiki on how to handle that when the site is updated (if I remember well, elvano told he was going to delete everything we could add until he finishes his update).

To say things simply, the server gamemap is located in ODServer.
The client gamemap is in ODFrameListener.
The most important thing is that there is no thread protection between the GameMaps. That means that the client game map should be used only by the rendering thread and the server gamemap should be used only by the server thread. The rule is that communication between them should be throught ClientNotification/ServerNotification.

As you already guessed, client players only have client gamemap.

The reference GameMap is the server one. You can considere client GameMap as a copy of the server GameMap. The rule is that doTurn only happens in the server GameMap. Then, whatever is computed is sent to the clients to keep them up to date.

[Bertram]

Thanks for the explanation (even if we already did on github.).

Just to let you know, I think this implementation is good and that we should just fix the few regressions we have.

Then, I'll be finally able to crush you all on dirty dungeon floors, ... well, or be crushed. But not without a fight. Mwahaha.

[Bertram]

Good news!!

hwoarangmy and me just found the fix for rooms almost at the same time.
Marked tiles might even be fixed the same way.

Stay tuned! (And thanks to hwoarangmy for the help!)

[Bertram]

The game has been fixed and we have made a few multiplayer sessions!! D Woohoo!

It's still unstable but I was able to see Akien play for a while. A lot of kudos to hwoarangmy for all the hard work done!

[Akien]

Some screenshots taken during a multiplayer game:

Arrival on server and chat box

Shiny little dungeon :-)

Literate rock troll

Time to hit some dummies

Or build some weapons

[charlie]

Well done guys! I can't help but think this is a watershed moment for OpenDungeons. The game can only get better from here.

[hwoarangmy]

Too bad I couldn't play more yesterday
But it was a nice way to find bugs and I'm glad multiplayer seems to work quite well. BTW, have you tried games with 4 players on the big map ? If yes, was it laggy ?

[Bertram]

Heya

Well done guys! I can't help but think this is a watershed moment for OpenDungeons. The game can only get better from here.

Yeah, it was a great time. The next rolling release will rock.

Too bad I couldn't play more yesterday
But it was a nice way to find bugs and I'm glad multiplayer seems to work quite well. BTW, have you tried games with 4 players on the big map ? If yes, was it laggy ?

Don't worry, we'll have a few games asap.
We didn't try the big map, only the fast skirmish one, and I clearly saw Akien prepare his rooms in the wait of my creatures.
Once the latest stabilization fixes will be merged, I guess a new rolling release is to be done, as the big new feature should be tested by other people as well.
What do you think?

Regards,

[Akien]

We didn't try the big map, only the fast skirmish one, and I clearly saw Akien prepare his rooms in the wait of my creatures.
Once the latest stabilization fixes will be merged, I guess a new rolling release is to be done, as the big new feature should be tested by other people as well.
What do you think?

That sounds good, yes. The next milestone would be to make sure no segfaults happen for unknown reasons, and that a game can be played through and won without segfault when distroying a base :-D
BTW on a local game I had trouble directing my creatures towards enemy bases, it seemed they were not too eager to go fighting. How should it be done gameplay-wise normally?

[Bertram]

and that a game can be played through and won without segfault when distroying a base :-D

Ah yes, you're right, the AI segfault should be fixed first. For eveyone: https://github.com/OpenDungeons/OpenDungeons/issues/56

BTW on a local game I had trouble directing my creatures towards enemy bases, it seemed they were not too eager to go fighting. How should it be done gameplay-wise normally?

The creatures are computing something I'd call a risk table with a risk ratio on each tiles near enemies. See: https://github.com/OpenDungeons/OpenDun ... eField.cpp

When the ratio becomes too high, and they lack ally support, they're fleeing instead of attacking. The code there might be tweaked so fighters are more reliable, even if I do think the actual attacking behavior should be triggered when you drop them in front of enemies or rooms, just like a forced behavior is triggered when you drop workers.

Regards,

[Akien]

BTW on a local game I had trouble directing my creatures towards enemy bases, it seemed they were not too eager to go fighting. How should it be done gameplay-wise normally?

When the ratio becomes too high, and they lack ally support, they're fleeing instead of attacking. The code there might be tweaked so fighters are more reliable, even if I do think the actual attacking behavior should be triggered when you drop them in front of enemies or rooms, just like a forced behavior is triggered when you drop workers.

The fact is, on my test game I wasn't able to drop my fighters in front of enemies, because I could only drop them (as far as I understood) on claimed tiles. So I thought the gameplay might be to "claim a path" towards the enemy base (i.e. "the cave is all mine and I'll crush you, mouahahaha!"), but I couldn't really get my workers to claim tiles out of my base. I might do a quick DK1 playthrough to get a better grip on the spirit of what we're trying to achieve gameplay wise.

[Bertram]

The fact is, on my test game I wasn't able to drop my fighters in front of enemies, because I could only drop them (as far as I understood) on claimed tiles. So I thought the gameplay might be to "claim a path" towards the enemy base (i.e. "the cave is all mine and I'll crush you, mouahahaha!"), but I couldn't really get my workers to claim tiles out of my base.

Ah, I see. Did you try dropping workers next a claimed tile, so that they keep claiming as the latest patches should trigger?

Also, in DK, there is a spell used a war flag. You put the flag somewhere and all your fighting minions rush to it if they can reach it. That's how your provoking an attack in DK usually.

I might do a quick DK1 playthrough to get a better grip on the spirit of what we're trying to achieve gameplay wise.

NOOO!!!! Your spirit would dissolve into demonic oblivion, and you would wander heedless for eternity!
More seriously, I think we're trying to inspire from this game so it's a good reference, but fresh concepts aren't out of the question.

[Akien]

The fact is, on my test game I wasn't able to drop my fighters in front of enemies, because I could only drop them (as far as I understood) on claimed tiles. So I thought the gameplay might be to "claim a path" towards the enemy base (i.e. "the cave is all mine and I'll crush you, mouahahaha!"), but I couldn't really get my workers to claim tiles out of my base.

Ah, I see. Did you try dropping workers next a claimed tile, so that they keep claiming as the latest patches should trigger?

I'd have to check whether I was already using these patches. That was with the version from our Friday testing party, I'm not sure if the behavioural patches were already implemented?

Also, in DK, there is a spell used a war flag. You put the flag somewhere and all your fighting minions rush to it if they can reach it. That's how your provoking an attack in DK usually.

Sounds useful indeed :-)

I might do a quick DK1 playthrough to get a better grip on the spirit of what we're trying to achieve gameplay wise.

NOOO!!!! Your spirit would dissolve into demonic oblivion, and you would wander heedless for eternity!
More seriously, I think we're trying to inspire from this game so it's a good reference, but fresh concepts aren't out of the question.

Hehe I've got some good spiritual resistance, I'm wearing a prismatic ring found in the Layna forest! :-p
I'll just have a quick look at how it's played, but will try to keep my fresh look on OD so that it can still evolve to differ from DK if the gameplay could be better.

[hwoarangmy]

The fact is, on my test game I wasn't able to drop my fighters in front of enemies, because I could only drop them (as far as I understood) on claimed tiles

That's correct and the same as DK1 (as far as I remember). Workers can be dropped on claimed or unclaimed tiles but fighters on claimed tiles only.

but I couldn't really get my workers to claim tiles out of my base.

Even with the patch to force behaviour, they still flee/attack if they see ennemies (the patch do not override behaviour if there are ennemies around). I agree, it is annoying and we might try to find a way to improve that. But concerning fighters, I never had problems to send them fight. When I drop them on the nearest tile, they usually go to fight.

[Bertram]

That's correct and the same as DK1 (as far as I remember). Workers can be dropped on claimed or unclaimed tiles but fighters on claimed tiles only.

I confirm this logic. There is a flaw atm. If you drop workers on area far away from the temple and with no clear path to it, sometimes they get stuck in idle mode.
This might be related to other creature bugs, though. IMHO, this is not forcefully something to fix, as you shouldn't be able to see area not discovered yet by your workers.

Once some kind of fog of war is implemented, to discover new area will be part of the worker logic I guess by claiming stuff more and more into the unknown.

Even with the patch to force behaviour, they still flee/attack if they see ennemies (the patch do not override behaviour if there are ennemies around). I agree, it is annoying and we might try to find a way to improve that. But concerning fighters, I never had problems to send them fight. When I drop them on the nearest tile, they usually go to fight.

Maybe we should make them flee only when they are being attacked? For instance, when a blow is struck to them (damaging them or not.)?
In my example, workers would not flee enemy creatures while claiming until they get one blow.

This may help when you're in need of new tiles closer from the enemy base. What do you think?

[hwoarangmy]

Maybe we should make them flee only when they are being attacked? For instance, when a blow is struck to them (damaging them or not.)?
In my example, workers would not flee enemy creatures while claiming until they get one blow.

Yes, seems like a good idea. If everybody agrees, I will open an issue.

[Akien]

Maybe we should make them flee only when they are being attacked? For instance, when a blow is struck to them (damaging them or not.)?
In my example, workers would not flee enemy creatures while claiming until they get one blow.

Yes, seems like a good idea. If everybody agrees, I will open an issue.

Seconded, that would really help expanding one's territory. My main problem in the TestLevelSmall was that the workers I dropped at the end of my claimed path would often go wander in the enemy base chasing some foe instead of claiming more tiles (or digging for gold btw).