Skip to content
This repository has been archived by the owner on Oct 27, 2022. It is now read-only.

Of Strengths and Weaknesses #142

Open
Byteron opened this issue Jun 7, 2020 · 6 comments
Open

Of Strengths and Weaknesses #142

Byteron opened this issue Jun 7, 2020 · 6 comments
Labels
discussion Things to be discussed

Comments

@Byteron
Copy link
Contributor

Byteron commented Jun 7, 2020

Wesnoth is a great game and we all love it. But there are things that could be better.
With Haldric, we have the opportunity to address these weaknesses right from the get go.

  1. Mainline Campaigns
    The mainline campaigns are not bad, but they could be better.
    We won't get around implementing them from scratch in a very different technology, so we might as well take that opportunity and heighten the bar for quality, as well as make them more interesting by using more advanced mechanics.

  2. Coop:
    Good coop campaigns are rare. For Haldric, we could put a higher focus on this to provide good coop experiences in the base game, as well as making it easier for UMC creators to create addons to be played in coop.

  3. Multiplayer Experience
    The current multiplayer experience is lacking in a few regards too. OOS errors are not rare. Cheatings is fairly simple. There essentially is no match making, as this is done manually by the players.
    With the potential of Nakama on the horizon, we might be able to improve on these areas.
    Meaning server authoritative multiplayer, finding matches with a single click, an overall better experience in-game (e.g. simultaneous movement for allied players).

@Byteron Byteron added the discussion Things to be discussed label Jun 7, 2020
@Pentarctagon
Copy link
Member

From the moderation perspective, 1.x is also lacking currently since it has only text command that users have to use, which accepts free-form text which is then sent to the MP Moderator IRC channel.

Having a UI dialog where users can have things like a specific "description" field, indicate whether they're reporting a game or a user, etc would make these reports much easier to act on. This then would make the MP experience more enjoyable, since moderators would be better able to find out about and deal with toxic players.

@gfgtdf
Copy link

gfgtdf commented Jun 7, 2020

server authoritative multiplayer

From wesnoth i can tell you that the main reason why it's currently so hard to switch to a multiplayer engine where the gamestate is actually calculated on the server is related to the umc api. An explanation (from the wesnoth perspective):

  1. We'd need to execute umc code that we didn't write ourselves on the mp server:
    .
    This is really nontrivial, i am not talking about malicious code here that could attack your server infrastructure, i'm mostly talking about simply bad code that might for example get stuck in an infinite loop. To guard against those cases we'd need to run every game in a separate process/thread and use platform-dependent code (meaning we need different implementation for windows and Linux) for monitoring a processes resources and kill it if i'd need to much cpu/ram.
  2. We'd probably still need to offer a way to run umc code on the clients:
    .
    Some features, that are tightly related to the ui, in particular lua code that is called on handled click/mouse-over callback (theme items callbacks, lua gui2 code), cannot be easily moved to the server, because these need to react immediately to mouse moves, and for people with average internet connections this might be noticeably slow. So it we want to keep these feature, we'd have to figure out some way for cum authors to write code that runs on the clients and on the server, while not necessarily problematic, this would at least make things more complicated compared to the current "everything run on the client" approach.
  3. Even if we could figure out how to do it, it'd clearly imply a compatibility break.
    .
    Obviously this is the case

In your case 3. is not of concern and 1. is something that can be implemented with a bit of work. This leaves 2. So if i were at your place, i'd clearly give a server authoritative multiplayer approach try (unlike the wesnoth code), even if its just for curiosity.

as well as making it easier for UMC creators to create addons to be played in coop.

i don't think its is actually hard to do in wesnoth.

@nemaara
Copy link

nemaara commented Jun 7, 2020

  1. There's a lot of things we can improve on mainline campaigns, with a lot of tricks to level design and how to keep things fresh beyond using vanilla wesnoth gameplay. Vanilla gameplay tends to be fine for smaller campaigns, but not for longer ones (even in smaller ones it can get monotonous if there isn't enough objective/unit diversity). The biggest one for Haldric I'd say is to have a connected storyline between campaigns, which we do not have for 1.x. First thing though is to get a working campaign in order.

  2. Coop - this is very much lacking in current wesnoth 1.x, but some SP campaigns can't really be simply adapted for MP. I'm thinking we should add more dedicated MP coop scenarios, such as things like Bob the Mighty's scenarios and WCII. These would not be connected to the lore strongly (maybe only taking some inspiration is all), so lore conflicts with SP would not be something to consider.

  3. For a PvP MP experience, some kind of rating system or competitive system would eventually be nice to have, but as Bitron mentions, there's a lot to do for the engine on the technical side before that can be accomplished.

Overall strengths: Wesnoth is extremely versatile in 1.x. As long as it's turnbased, you can make almost anything you want in it (a true RPG, strict strategy, open world, etc.). There is a lot of depth to the gameplay and a boatload of content (especially in UMC).

Weaknesses: 1.x's UI feels dated and is pretty unintuitive in several places to me. The RNG feels bad for many people. The lore feels somewhat discombobulated since it was kind of community written. We don't have much marketing or dedicated community building.

@Pentarctagon
Copy link
Member

@gfgtdf For (2), I'd guess that there's a lot of UI-related functionality that really wouldn't make any sense to need to ask the server about anything (hovering over a unit or opening the ingame help, for example) since they don't alter the gamestate at all. What might also help would be to batch up actions that do affect the gamestate but don't interact with other players, similar to 1.x's Delay Shroud Updates option or even Planning Mode.

@jay20162016
Copy link
Contributor

According to the official Add-on server, Legend of the Invincibles is the 3rd most downloaded addon, preceded by Ageless Era and Era of Magic Resources. In addition, there are many people who would install the beta version, or directly from github. Legend of the Invincibles introduces many features, including item drops, a inventory system, custom AMLAs, and many others. It would be a good idea to take some features and ideas from the campaign for Haldric.

@gfgtdf
Copy link

gfgtdf commented Jun 8, 2020

@Pentarctagon yes those actions usually don't modify the gamestate but they still need information about it, think for example of custom unit property "mana" (that is stores inside te unit variables) in the ui bar as the simplest example. in wesnoth its rather easy to add a new mana bar to a units right side panel.

In a server authoritative multiplayer the client does not have the full gamestate information, (also to prevent cheats) since it only needs to know what that player should know, and for custom data like for example unit variables, the umc server code must somehow mark these as "available" to the players that have it, and how exactly this works is something we must think about.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
discussion Things to be discussed
Projects
None yet
Development

No branches or pull requests

5 participants