Players are not interested in competitive?

[Hejnewar]

(2-3 minutes) 30-45 is for 1v1. Well still depends on how exactly you set up your timer, how much time you need to play your turn etc. etc.

In that case the unofficial ladder is just as good a solution as anything else. Only people "in the know" get to play ranked.

I can't say that unofficial ladder is bad but I also can't say that it's good, it's better than nothing. I often see new people that just got into mp and they look for ladder instantly, this is not something uncommon, but then good half of them drops out when they hear that they need to register on another site, not to mention reporting victories. Word "Official" also has its power and I believe it would attract people that are new as well as regular every day players.

Above all else you can make great advertisement from this.
Wesnoth 1.16 now with Official Ranking System, Improved Campaigns and Reworked Faction of Dunefolk. Check it out Now.

[Iris]

I can't say that unofficial ladder is bad but I also can't say that it's good, it's better than nothing. I often see new people that just got into mp and they look for ladder instantly, this is not something uncommon, but then good half of them drops out when they hear that they need to register on another site, not to mention reporting victories. Word "Official" also has its power and I believe it would attract people that are new as well as regular every day players.

Bearing in mind that the MP server's maintenance is primarily a joint effort by Soliton and Pentarctagon at the moment, personally I'd not be opposed to the community making an effort to build an experimental official ladder into the game and see if that somehow attracts the necessary changes to the game client and server to make it a solid thing that we can capitalize on in the future.

But as it stands right now, most of the dev team is focused on single-player mode since they have little to no familiarity with the multiplayer aspect of the game, and we've been burned too many times in the past by people who throw a new feature into the game (e.g. Planning Mode and the original 1.8 GUI2 MP lobby), leave it in half-baked, and only create more technical debt that nobody is willing or knowledgeable enough to fix before it degrades the game's overall quality for one or more stable series. Hence the cynicism on my part when it comes to big stuff like this.

[Hejnewar]

I guess we should be glad that we have them.

I have some generic idea how such project should look like but I don't have necessary skills to help with it. Unfortunate but I guess I should be happy that I can help with other things.

My main argument for this would be that increase in player retention is necessary for wesnoth future and this would help with that. It's just my opinion but I think that sp doesn't keep players for long (and I don't think that players from steam that play only sp ever had a chance to see discord link, it also disappeared from mp lobby, pity because I really consider discord as part of net that is supposed to not let players drop out as fast) and keeping them is important, sure there might be people that play a bit, see that there is github and help but usually transition from player into UMC creator into contributor is taking long time. Well even reaching stage of UMC creator is good because they help in their own way. Sorry for offtopic.

[Pentarctagon]

If everything works out, one of my goals for 1.15/1.16 is to add in a UI to the client that will allow viewing MP game history. Adding another checkbox to the game creation screen to indicate if the game is competitive or not would be pretty easy at that point. Overhauling wesnoth's current client-server structure is far beyond anything I have the time or knowledge to do though.

[gfgtdf]

If everything works out, one of my goals for 1.15/1.16 is to add in a UI to the client that will allow viewing MP game history. Adding another checkbox to the game creation screen to indicate if the game is competitive or not would be pretty easy at that point. Overhauling wesnoth's current client-server structure is far beyond anything I have the time or knowledge to do though.

I don't think the game stores the winner of the game already though? Actually i think the current way the clients update the server is not reliable enough.

When it comes to cheating, i don't think there is much we can do actually, there are basicially 3 ways to cheat:

1) A player can uncover any information about the current gamestate.
2) The host can inject any wml cod einto the initial scenario, that he sends to the other cllients.
3) A player coudl intentionally make the game error (oos error) when he is about to loose.

We could make (2) a little more difficlut, but the rest i really hard, i also don't think a topic about player interest in competitive is a good place to discuss about overhauling wesnoth's current client-server structure, if anyone want to talk about that you can make a proposal via a github issue or a new topic.

[Pentarctagon]

I don't mean store who the winner was, just a flag of whether or not it was a competitive game.

[gfgtdf]

I don't mean store who the winner was, just a flag of whether or not it was a competitive game.

yes i know but if we want to use this data to implement a ladder system it'd be important to know who the winner was.

[Pentarctagon]

Best case for that would probably be to check with both sides if they agree that a surrender or leader-death happened, otherwise some way to confirm a disconnect/afk vs agreeing to reload and continue later.

[l1onsun]

About cheating: i think it a sad problem. But this won't completely kill the potential of the ladder games.
For example in chess any can easily cheat by using stockfish engine. However ranking chess are very popular.

So i think even very simple competitive system - without any additional servers and any care about cheating (or blacklisting at least)- will work more or less

[Hejnewar]

When it comes to cheating, i don't think there is much we can do actually, there are basicially 3 ways to cheat:

1) A player can uncover any information about the current gamestate.
2) The host can inject any wml cod einto the initial scenario, that he sends to the other cllients.
3) A player coudl intentionally make the game error (oos error) when he is about to loose.

1) Disable saving game during competitive matches for players. This much is enough.
2) Very easy to catch and I have never seen that happen before.
3) I have never seen that happen before and it's much more likely that host just kicks you.

[gfgtdf]

When it comes to cheating, i don't think there is much we can do actually, there are basicially 3 ways to cheat:

1) A player can uncover any information about the current gamestate.
2) The host can inject any wml cod einto the initial scenario, that he sends to the other cllients.
3) A player coudl intentionally make the game error (oos error) when he is about to loose.

1) Disable saving game during competitive matches for players. This much is enough.
2) Very easy to catch and I have never seen that happen before.
3) I have never seen that happen before and it's much more likely that host just kicks you.

1) You can still use unsynced debug commands or custom cheat addons.

2) How would you catch it? the host can simply inject any event that for example gives the host 20 gold on turn 10 or something like that or even rig the attack proabilities in his favour.

3) how does the host know that it was you who intentially made made the game error and not that it was an error for other reasons? also the player that does this could also be the host, afterall in a 1vs1 match there is a 50% change of him being the host.

[Ravana]

3) is the only one where I can see possible solutions. But other ones remain available.

To clarify, 2) does not leave any evidence if it is only used to achieve 1), but it does show up in replay/save if it changes gamestate.

[Pentarctagon]

When it comes to cheating, i don't think there is much we can do actually, there are basicially 3 ways to cheat:

1) A player can uncover any information about the current gamestate.
2) The host can inject any wml cod einto the initial scenario, that he sends to the other cllients.
3) A player coudl intentionally make the game error (oos error) when he is about to loose.

1) Disable saving game during competitive matches for players. This much is enough.
2) Very easy to catch and I have never seen that happen before.
3) I have never seen that happen before and it's much more likely that host just kicks you.

The problem with any serious attempt to prevent cheating is that the first rule of security in general is for the server to not implicitly trust the client, because people can do whatever they want to the client and modify it to send any sort of input to the server. The current architecture does almost exactly the opposite however - wesnothd has very little knowledge of the game's state, and mostly just sends commands between the wesnoth clients. OOS errors for example aren't because wesnothd is doing any sort of validation; OOS errors are one wesnoth client telling wesnothd to tell the other clients that one of them tried to do something that should be impossible.

For (1) for example - how would you verify that saves are actually disabled? wesnothd can send a command to tell the client to disable making saves, but someone could modify and recompile the client to ignore that command and still create saves anyway. Or likewise, checking the "Competitive" checkbox could be set to also disable saves, but someone could still modify and recompile their client to instead still create saves. There's no way for wesnothd to verify with 100% certainty what the client is doing.

So at a minimum, the starting point for any serious sort of anti-cheating effort to be worth it would be:

• The wesnothd server would need to be improved to maintain the game's state and do validation of expected commands against a a whitelist of era(s) and maps - aka Default Era plus a list of the more balanced 1v1 maps. There's no way to have effective anti-cheat that works with Wesnoth mods that can do almost anything to almost anything.
• The wesnothd server would also need to be the initial source of the game's data. Currently client 1 tells wesnothd what the scenario's data is, and then wesnothd sends that on to client 2. Instead, wesnothd would need to be the one telling both clients 1 and 2 what the scenario's data is.
• The wesnothd server would need to be modified to only send updates to the game's state to clients that would know about it. This would address (1), for example, since then even if the client was creating local saves, it wouldn't do any good to load them since the would be no information available about how much gold their opponent has, where their units are under fog, etc in the first place.
• The wesnoth client would need to be modified to be able to handle only having partial information about the game's state.

There's probably more that would need to be done as well, which someone more familiar with Wesnoth's codebase would need to elaborate on.

[Hejnewar]

So 2) is exactly like Ravana said. It leaves traces of doing so and can easily be uncovered. Doing this is very dangerous really.

3) is not big problem because people usually save and reload and that's all, even without saves there often are replays on replay server. Because of that person trying to force draw would most likely do this many times and that can be suspicious. Some could say that players would use 3) in order to use 2) but that is even easier to see.

That pretty much leaves 1) and instance of 2) being used in order to achieve 1). Problem with this one is that it's very hard to see and you can't most of the time be 100% sure that someone is using this. There are maps that are good to test for this kind of stuff but that's still often not enough if cheater is hiding this very well.

[gfgtdf]

The wesnothd server would also need to be the initial source of the game's data. Currently client 1 tells wesnothd what the scenario's data is, and then wesnothd sends that on to client 2. Instead, wesnothd would need to be the one telling both clients 1 and 2 what the scenario's data is.

I think this is a good idea and at lest somewhat possible, but not easy to implement.

[*][*]The wesnothd server would need to be modified to only send updates to the game's state to clients that would know about it. This would address (1), for example, since then even if the client was creating local saves, it wouldn't do any good to load them since the would be no information available about how much gold their opponent has, where their units are under fog, etc in the first place.
[*]The wesnoth client would need to be modified to be able to handle only having partial information about the game's state.[/list]

There's probably more that would need to be done as well, which someone more familiar with Wesnoth's codebase would need to elaborate on.

This would be a complete overhauling wesnoth's current client-server structure, and probably to much to dicuss in this thread.

So 2) is exactly like Ravana said. It leaves traces of doing so and can easily be uncovered. Doing this is very dangerous really.

Iif you are willing to look at all he savefiles by hand and know wml/lua well enough you can uncover this, quite sure that this does not apply to the majority of players.

3) is not big problem because people usually save and reload and that's all, even without saves there often are replays on replay server. Because of that person trying to force draw would most likely do this many times and that can be suspicious.

hmm maybe.