Project direction ideas moving forward

[Lord-Knightmare]

I'd like too to have real ranged attacks implemented. While it might be true that it's a backend thing, it's also true that its frontend effects would be very evident, at least in UMCs.

That would be a nice feature to have if it's ever accomplished. Maybe one of the reworks stated to take place or planned new additions can utilise it or have it as one of the main highlights.

[inferno8]

On the topic of the asset elephant... Well, unfortunately, if you do stick to 3D this is very likely. Initially we had started by adapting the game as it is now, 2D tiles and everything, but recreating the terrain transitions and macros proved to be too much of a challenge, hence why we eventually built something from the ground up.

In 2019 I attempted to recreate some parts of BfW mechanics in Unity3D for my personal project and I even went pretty far with it, but those terrain transitions demotivated me entirely, so I can relate to that.
But unfortunately terrain transitions are fundamental for that visual aspect of the game we are used to. To me Haldric in its current state, albeit interesting, lacks that special "2D vibe" Wesnoth 1.x has. But perhaps I am too nostalgic. If only we could recreate all those terrain transitions there, it would be a great step forward, especially for those seeking classic aesthetics.

Personnally I would be up for it, because revisions of something are often timid and/or conservative as opposed to starting from scratch and allowing ourselves to make unconstrained decisions. But I reckon it would be a couple years at least before the game can offer to the type of content it currently has, so I can definitely see the issue.

If I am getting this right, Haldric offers a fresh start. This is tempting as it solves many (all?) issues with that terrible custom engine the game uses at the moment. But sacrificing all UMC in the process is a bad idea in my opinion. What I know for sure is that if Wesnoth was to go 3D at some point, I would probably give up making content for it. Porting EoMa (more than 240 units) to a 3D environment seems an impossible task for a single person. Not to mention Ageless Era (more than 2500 units?). So this potential Wesnoth successor would probably lack a lot of iconic add-ons. Even if Haldric was 2D but didn't support WML, this would require UMC creators to completely rewrite their add-ons to match a new standard. For complex add-ons like LotI that would probably take years.

I've been making user-made content for 15 years. If I had to start from scratch, you'd have to offer me something much better than WML and/or to provide me with tools such as a dedicated editor to make my work much easier and faster. And I am pretty sure other UMC creators could say the same.
To make things clear, I am not against Haldric. I sense an incredible potential and new opportunities coming with that Godot engine, but to me it should be an evolution, not a revolution. I'd really love to see a more classical 2D version of Haldric at some point in the future.

[Pentarctagon]

doofus-01's comment on the first page would be something to keep in mind as far as the terrain transitions go:

If Terrain Graphics are the thing holding back the transition to a new engine, let's talk. I don't know the C++ at all, but I have had to deal with the terrain-graphics/ macros, and can say a lot of that stuff is legacy. Provide an environment where the keys layer, base, and map mean the same thing as they currently do, and we can probably figure this out.

I know , it won't really be that simple, but we could figure out what needs to be done. Let's not panic.

---

As far as existing content, the impression I've gotten is that re-implementing WML even as just a simple data language instead of also being a scripting language (ActionWML, WFL/IPFs, the preprocessor, etc) would probably be a non-starter. It'd just be too complex to try to re-implement all that on top of Godot, much less trying to do so in a way that would actually keep backwards compatibility intact. Hell, we break backwards compatibility between stable releases of Wesnoth 1.x all the time as it is, often accidentally.

So probably the best we'd be able to offer would be to have lua be supported in Haldric (with https://github.com/gilzoide/godot-lua-pluginscript or something similar), and then try to re-implement 1.x's lua API in Haldric. So it would essentially be a middle ground - art, music, and lua code would be re-usable in Haldric, put anything WML-related would need to be ported. That would still be a lot of work, but at least it wouldn't be "redo literally everything".

[Celtic_Minstrel]

As far as existing content, the impression I've gotten is that re-implementing WML even as just a simple data language instead of also being a scripting language (ActionWML, WFL/IPFs, the preprocessor, etc) would probably be a non-starter.

Why? It's not all that different from XML or JSON or YAML, honestly. It's just a structured data language. And Wesnoth's config class is actually very close to being self-contained. It has a few dependencies on other parts of the engine, but off the top of my head, I think most of those are non-essential functionality that could be moved to global functions – for example, the "get deprecated key" class of functions. There's also the t_string dependency, but I think that could be extracted as a template parameter. There may be some utils dependencies as well, but if it were a standalone library, you would just duplicate the utils needed.

I think iceiceice even actually made an external libwml, though I'm not sure how close it is to Wesnoth's WML. It's also quite old, so it probably doesn't have the new preprocessor features (assuming it supports preprocessor at all, I don't remember).

Now… that only covers the WML language itself (and maybe the preprocessor; I'm less familiar with the preprocessor code, so it may be more entangled with other things than the config class is).

What about ActionWML? Well… ActionWML is something like a "WML application". It's just an engine that takes WML input and interprets it as code. As long as you have WML working, there wouldn't be any difficulty in making ActionWML work too.

Then, what about WFL? I think that too could possibly be extracted into a standalone library, and if that's done, then… everything's fine. WML doesn't have any innate support for WFL – it's just certain applications of WML read the value and parse it as WFL code.

And what about IPFs? Again… WML itself doesn't need to know anything about them. It's just the way other code interprets the values WML has given it.

Anyone wishing to create an independent WML library doesn't need to care about ActionWML, or WFL, or IPFs. They just need to make the parser, serializer, preprocessor, and config class work. If all of that worked, said independent WML could theoretically be swapped into the game with a moderate amount of effort.

And if you're looking at this in the context of moving to Godot? Well, certainly ActionWML and IPFs and WFL would be more work to implement in a Godot engine; but they're not entangled with WML.

I'm not saying all this wouldn't be a lot of work. It would be a fair amount of work. But I think people are making it out to be far worse than it is.

So probably the best we'd be able to offer would be to have lua be supported in Haldric (with https://github.com/gilzoide/godot-lua-pluginscript or something similar), and then try to re-implement 1.x's lua API in Haldric. So it would essentially be a middle ground - art, music, and lua code would be re-usable in Haldric, put anything WML-related would need to be ported. That would still be a lot of work, but at least it wouldn't be "redo literally everything".

I'll also note that just supporting Lua might be enough to build a fully-functional auto-converter tool that can read a 1.x campaign and spit out something that does almost exactly the same thing in Haldric. So even this approach may well be far less work than you're thinking.

[Pentarctagon]

Part of it too is the effort it would take to re-implement all of Wesnoth UMC APIs on top of Godot vs just the lua API, given the number of currently active developers who would be able and knowledgeable enough to contribute to that effort. At a minimum, I feel fairly confident it would be significantly less work (and therefore more likely to be successful and completed) to have the lua API re-implemented on top of Godot and then have data like unit types imported into Haldric's native representation.

[LordBob]

If I am getting this right, Haldric offers a fresh start. This is tempting as it solves many (all?) issues with that terrible custom engine the game uses at the moment. But sacrificing all UMC in the process is a bad idea in my opinion.

It does, but as you say, going full 3D would be a 2.0 in a much more radical way than any other option that's currently being discussed. We did consider this UMC wall as well while going forward with Haldric, and it is an issue that stayed. Taking that route may give renewed interest in the game, but it would definitely cut off part of the player base.

That being said, personally I've been wanting to see a visually revamped Wesnoth for years ; without even going 3D, high res 2D graphics that aren't optimized for a 20 year old 800*600 screen would be nice to have. But it's an endeavour for the long run, so if anything a viable option would be to create a graphic engine that isn't hard-wired with an unalterable 72*72 pixel grid. This way, if and when high res graphics can be a thing, we're not stuck with rules set in stone.

[Bitron]

Hello, lead dev on Haldric here.

First off, here's some quick video footage on the state of the Haldric Project.

We have a working Terrain Editor, the two maps that exist in the game were made in it.
https://streamable.com/2pt89s

And we have networking in place. We can actually log into a lobby, chat, join matchmaking, and play a networked match.
https://streamable.com/6kza4l

In terms of gameplay, we have movement + mp costs, combat, resistances, defenses + terrain type, villages, leaders, recruitment, level ups.
Basically all the core stuff is there. Plus haldric exclusive features: multi-tile villages, true ranges attacks, and terrain elevation.
What's still missing are secondary mechanics, like special attacks, traits, abilities, AMLA.

And the whole Singleplayer / Scenario scripting is also still missing, that's a big task still.

There is still a lot to do, but there also is quite a bit there already.

To UMC... the problem with wanting to support existing UMC from 1.x is not just porting WML to Godot - which is a daunting task in and of itself. If we were to port this, it would mean we'd have to support the entire feature set accumulated over 15 years of work by dozens if not hundreds of people, and also support outdated structures that only exist because of the limitations the 1.x engine has. (Looking at you, castle images.)

This is a task I personally do not want to tackle, because I think it is too much work, and I do not know enough about 1.x internals anyways.
And I also think it is not worth it, because it would only serve one thing: appease the existing wesnoth player base. I am honestly not sure the existing wesnoth player base is the right target audience.
You guys already have a fanstastic wesnoth game. You already have all the WML and UMC and pixel art and nostalgia you wish for.

There is no way we can fulfill all the requirements existing wesnoth players have to make the switch from old wesnoth to new wesnoth.
I don't think we should try.

I think we should make a wesnoth that appeals to people that are not already playing wesnoth because of the shortcomings it has.
People who like strategy but didn't get into wesnoth because they think it is too old, for example. Or people who simply don't like the pixel art look.
Pretty much every single friend I have that I showed wesnoth to in the recent years didn't want to get into it because it just felt outdated.
And then I show them what we're doing with haldric, and they are say that they'd play if it's done.
And with that in mind I think there is no reason to take over any systems from 1.x.
With Godot we already have a fantastic scripting language that integrates very well with the engine that is used: GDScript.
(EDIT: The game itself is actually written in C#, which is also supported by Godot. Though that does not mean we can't use GDScript for UMC specifically)
We can use that to make creating UMC in godot more approachable. No typing WML or XML or YAML out by hand into text files, but having an actual visual editor to create your UMC.
There is much potential for massive improvements over the current UMC creation work flow that we completely throw over board when we just port the existing one.

Lastly, 2D vs 3D.
Yes, there are wesnoth players who would not play haldric because it is 3D, but there is also a whole bunch of people who don't play wesnoth because it's 2D, (or more specifically pixel art)

Some parts of 3D are more difficult to handle, and yes, creating it from scratch is a tough nut to crack. But there is a lot that also speaks for 3D.
Many of the UMC creators just frankenstein their way through things. That is very much possible in 3D as well. I'd say once you get used to the tools it's even simpler, because you don't have to fight different poses / shading, etc.
A sword mesh is a sword mesh. You can put it into a dwarves hand and done. Shading and orientation does the engine for you. Even works with existing animations, so no new sprite frames for that either, because the animations only care about the bones. The Sword just moves with it.

that's some food for thought. For now I'll go get breakfast. :P

[doofus-01]

There's a lot going on here, it's getting hard to follow. I think there are related (but not necessarily inextricably linked) issues:

1. Overhauling the GUI and graphics engine to use some third-party software. Wesnoth 1.x wouldn't change fundamentally, but it could be updated more easily, features could be added, and people would be willing to work on something with transferable skills, rather than GUI1/GUi2. Not necessarily linked to other changes.
2. Overhauling the graphics completely (including 2D vs 3D debate). Linked to [a], at least.
3. Overhauling entire Wesnoth engine, like the Godot effort or something similar. Use lessons learned and some inspiration from Wesnoth, but basically a fresh start. Would obviously encompass everything here.
4. Focusing on specific issues, such as RNG, ranged attacks, or a UMC editor. Not necessarily linked to other changes, but could also depend on them.

I probably missed something, or maybe misrepresented it, just wanted to try to get a summary here, and if needed maybe we can split the ideas to different topics.

[octalot]

With Godot we already have a fantastic scripting language that integrates very well with the engine that is used: GDScript.
(EDIT: The game itself is actually written in C#, which is also supported by Godot. Though that does not mean we can't use GDScript for UMC specifically)
We can use that to make creating UMC in godot more approachable. No typing WML or XML or YAML out by hand into text files, but having an actual visual editor to create your UMC.

Wesnoth's current scripting languages try to be secure, it's a bug if the scripting language allows malicious code to affect things outside the game. That's certainly not bug-free (as in, UMC is still able to crash the game), but I believe it's at least good enough that an attacker is unlikely to choose Wesnoth as their attack route.

Many other games seem to be modded by allowing arbitrary code to run. Sometimes because modding is unofficial and the UMC authors are using their knowledge of Unreal or Unity to decompile the game engine and patch stuff in, sometimes because the modding is officially supported, with the official support being "here's some of our game's source code, use your knowledge of Unreal or Unity to patch your stuff in". That surprised me, it took me a long time to realise that "modding allows arbitrary code execution" is actually standard and expected behavior.

Godot has a wishlist issue to sandbox UMC scripts, but for the moment GDScript can do anything that the game's own code can do:

• https://github.com/godotengine/godot-pr ... issues/389 current issue
• https://github.com/godotengine/godot/issues/7753 previous discussion (closed because it moved to the godot-proposals tracker)

Steam and Flatpak put games in sandboxes. It's maybe something that Linux distributions should also do to games, but at least for the moment if we're aiming to be distributable outside of Steam and Flatpak then we need something providing security from malicious add-ons.

[Pentarctagon]

itch.io and the macOS app store do also have their own sandboxing, FWIW. So of 1.x's current distribution methods, it would affect SourceForge standalone downloads and downloads from Linux repositories.