Roadmap for Wesnoth 2.0 Alpha

Wesnoth 2.0 Alpha

Gameplay

Classic

• [x] upkeep
• [x] rest / village healing
• [x] advancement (#56)
• [x] AMLA (#62)
• [x] combat (#57)
• [x] recruitment (#58)
• [ ] factions (#58)
• [x] traits (#84)
• [x] abilities (#20)
• [x] weapon specials ( #59)
• [x] recalls (#60)
• [ ] define next scenario for campaigns
• [x] AI

New Mechanics

• [ ] Inventory (#66)

Terrain

• [ ] add missing terrains
• [x] two-way transitions (#64)
• [x] to-terrain transitions (#65)
• [ ] mulit-hex terrains
• [x] castles
• [x] animated terrains

Map Editor

• [ ] define ToD schedule
• [x] define number and start positions of sides

Interface

• [ ] define main menu visuals
• [ ] define game HUD visuals
• [ ] scenario settings (selectable factions, gold, income, stuff)
• [ ] story screen for campaigns

WDK (Wesnoth Development Kit)

We should set this up and use it for core content as well.

• [ ] create units
• [ ] create scenarios
• [ ] create campaigns
• [ ] create events

Networking

• [ ] MP Matches
• [ ] MP Moderation Tools
• [ ] ? Player Profiles (SteamWorks?)
• [ ] ? MySQL Module

Content

Units

• [ ] Rebels
• [ ] Undead
• [ ] Loyalists
• [ ] Knalgan Alliance
• [ ] Drakes
• [ ] Northerners
• [ ] Dunefolk

Campaigns

• [ ] Heir to the Throne

I18N

It may not be fully translated, but it should at least use it to proof concept

• [ ] English
• [ ] German

Perhaps i18n should be looked into too. Translation infrastructure is important aspect of wesnoth too.

Added i18n to the list.

Also, to 6. we could use Godot's signals for an event system. Setting up a global .gd file with signals like "turn end", "turn begin", "move to" and alike. Within the script for a scenario, we could then connect to the signal and they get called whenever the signal gets emitted in the code.

For (3): I'd say we don't need working networked MP for the prototype, since I can't imagine an engine like Godot wouldn't be able to support that, but it would be good to at least know if we'd be able to re-use any of the current campaignd(add-ons server)/wesnothd(MP server) code or whether Godot would require something completely from scratch for that as well. IIRC there's a simple_wml concept that they use which would at the very least need to be converted to using YAML or (more probably)JSON instead if they were kept. The ability to query forum ban status before allowing access to the MP server that was enabled by default in 1.14 has also been invaluable, so if we can't re-use the current server software then it would need to be known that there's some way to run SQL.

There should also be a save/reload feature, which IIRC it was said that JSON would be used for that.

For (5): I'd add animated terrains as well. Visually it's one of the things I like the most about Wesnoth 1, and is one of the places that Godot should be able to really show improved performance over Wesnoth 1's software rendering.

For (6): One thing that would need to be decided for this is whether to try to re-use any of the current lua API from Wesnoth 1 or not, since I know that has been mentioned. IPFs are another thing that should be considered, and perhaps it would be possible to re-use the current C++ implementation of them as a Module/GDNative.

Something else to consider would be how to implement a full API versioning scheme to allow multiple versions of the API implementation to exist and be usable.

A question I have as well would be whether to have any pre-processor sort of functionality. It woudn't need to be as flexible as Wesnoth's pre-processor, especially since it wouldn't be needed in the lua scripting, but a simple text replace ability for things like ability/weapon special macros would still be useful.

For (9): The one thing I would caution against would be commissioning any sort of improved graphics during the prototype, unless they would also be able to be used for Wesnoth 1. I don't know anything about how much money Wesnoth Inc has available from the iOS port, but I don't think it makes sense to pay to create new things that would be Wesnoth 2-only before we know that Wesnoth 2 is even possible. I mostly mention this because I know @Vultraz has already said that Lord Bob would be interested in creating some HD terrains for Wesnoth 2.

I can't imagine an engine like Godot wouldn't be able to support that

Godot Networking

it would need to be known that there's some way to run SQL

Godot right now does not support SQL, but there is a GDNative addon that could be used for SQLite.

There should also be a save/reload feature, which IIRC it was said that JSON would be used for that.

Ah, right, that indeed is important. I'll add it to the list.

I'd add animated terrains as well.

That, too. I know two ways for that from the top of my head. Either with an AnimationPlayer node or with a shader script, so it definitely is possible. I'm not sure though how accessible it would be for UMC creators. But I guess there is a way for that, too.

Godot right now does not support SQL, but there is a GDNative addon that could be used for SQLite.

The problem with that being that Wesnoth's forum database is MySQL. Additionally, SQLite is an embedded type of database, so while it could perhaps be used to store statistics locally across multiple games/campaigns/etc, it can't be a replacement for the forum ban verification/forum accounts requirement that currently is done.

The problem with that being that Wesnoth's forum database is MySQL. Additionally, SQLite is an embedded type of database, so while it could perhaps be used to store statistics locally across multiple games/campaigns/etc, it can't be a replacement for the forum ban verification that currently is done.

I see. Maybe this module does what you need then. Though it being a module does require a rebuild of the engine.

That looks closer to what would be needed, yeah. Only being able to select 1 row would be somewhat limiting, though not a deal breaker. It doesn't look like it supports query parameters though, which is... odd to say the least in 2018, and is a deal breaker just in terms of basic security.

Well, it's two years old. Also, I think we have some devs who are fairly good in working with C++ and could extend upon this module as basis.

SQL injection is quite an old vulnerability though. But in any case, it looks like MySQL support would definitely need to be a module and probably one that we support ourselves.

But I think it's save to say that it's possible, then.

Also, on tile animation again, I found this tutorial that might be useful, on how to animate tiles with shaders. This might also be helpful for transitions, actually.

Maybe it is an stupid idea... but... how about an an REST API to solve the issue related to mySQL support?

What's a REST API? I'm not sure if the SQL issue needs to be solved for the prototype. We do know that it's possible to write what we need as module, thus there is no need for proof.

Also: I updated the original post, added Wiki and extended the Scripting point. I had a few rough ideas for scripting with GDScript. I'm not sure if it's possible, but it might. I will definitely look into that. Maybe I can get one small UMC add-on (like one scenario and a few units) done, which should be enough for proving it possible to do.

A REST API is overkill. There is no need to add a web server to the mix.

What you're trying to say is that the MySQL interface should be refactored to a standardized interface (if it's not already, it's been a few months since I last looked at it). That way, if someone wants to swap out the MySQL interface to something else (say, a flat-file reader) it's a simple matter of replacing a few source files, or swapping one library for another. (And, yes, one of those replacement modules could use a RESTful API if you really feel you need to check the box to assure upper management you're using all the latest buzzwords.)

---

Just realized this is the prototype project.

1. Design to be vastly more modular than Wesnoth. Even if it's just a couple source files and a tiny library, make "user authentication and authorization" a separate, sub-project instead of scattering it willy-nilly throughout the code base.

2. You don't need to actually DO authroization and authentication for the proof-of-concept. Just design for the library and have library approve some and disapprove others, either from a hard-coded list or using some rule. It's a proof-of-concept project. Don't spend weeks doing a full implementation when 10 minutes will serve to show if it can be made to work as intended.

The ability to query forum ban status before allowing access to the MP server that was enabled by default in 1.14 has also been invaluable, so if we can't re-use the current server software then it would need to be known that there's some way to run SQL.

So, I probably misunderstood this... 'Cause the idea to have some Rest API is only valid if there's some integration with user's forum or something like this for the MP.

At present, the integration is at the MySQL level. The Forums and Wesnothd both reach directly into the SQL database.

Yes, there should be an API. But it should be at the library-call level at compile/link time and not at the network level. That way the MySQL database could be replaced with PostgreSQL, Oracle, MS SQL Server or anything else simply by changing the runtime used. And, if dynamic linking is used, the decision could be made at config/startup instead. Or multiple schemes could be even be used. All those are implementation details which don't need to be done simply to prove the concept.

Adding a web server and a HTTP conversation, simply to use a RESTful API to hide the MySQL transaction (which might, or might not, also be a network transaction) is overkill.

Right, it doesn't need to be the full implementation, but given some of the issues that have happened when the MP server didn't check the forum ban status, being able to do this in Godot is a "must have" feature from my perspective.

As I mentioned on Discord, the mySQL integration for Series 2 should be written as a self-contained Godot module that others could use as well.

I updated the first post and made some points a bit more concrete by adding can-do's and to-do's.

@Byteron you can use checkboxes for the list so we can even better keep track of what is still open to do. - [ ] Sample checkbox

• [ ] Sample checkbox

@LawnCable thanks, updated. I will go over it again as soon as I have more time to work out a more detailed plan. In a bit of a rush right now.

Updated initial post.

The Units item should have Dunefolk underneath it, I would think.

@Pentarctagon added Dunefolk.

I know nothing about this 2.0 prototype (just found it on by going down the ol' google rabbit hole) but something I think is sorely missing from wesnoth as it stands and will only hurt it as more time goes on is the lack of a dynamic GUI scale.

Wesnoth 2.0 shouldn't use a mobile GUI spritesheet and a separate desktop GUI spritesheet but instead include a slider that allows the visual scale of the GUI to be made larger or smaller with dynamic graphics that let the user play easily on anything from mobile to future 8k displays without the user having to change out of their native resolution.

I'd also add German or maybe Spanish under the i18n - you can't really prove translations work if there's only English.

Campaings is spelled incorrectly.

And finally, there should be some mention of MySQL, or at least implementing moderation tools for MP.

@spartanatreyu 4K maybe, but it's probably more than a decade away until 8K is relevant.

Updated. Fixed typo, added Networking section.

Also, while it's kind of implicit, AI would be another thing to add to the list. I assume mattsc would be the person to talk to once that becomes necessary to implement.

@spartanatreyu 4K maybe, but it's probably more than a decade away until 8K is relevant.

I mention 8K not as a modern requirement but for the purposes of future-proofing. 8K would likely be a standardised target size to prove a scaling GUI's implementation works correctly at larger resolutions. Non-16:9 ratio displays would also be useful to playtest too.

I'd also add German or maybe Spanish under the i18n - you can't really prove translations work if there's only English.

I actually deal with translations as a web/app dev amound other things as part of my profession. We've found that the four best languages to test/build GUI elements against/for are English, Russian, Japanese and Arabic. (buttons, menus, tooltips, description text, etc...) If your GUI works in these four languages, it will likely work with every translation you're likely to include without having to cut out and reimplement something in the future.

English is useful as a standard size.

Russian requires roughly 150% the amount of characters as English to carry the same meaning. This makes it a good language to stress-test the maximum size your buttons will support. (in my own experience, it has helped me to force all buttons to support multiple lines from the start of development).

Japanese can sometimes convey meaning in around 30% the same characters as English, sometimes as few as 2-4 characters. This is because regularly used words can be represented as a single character, like & for "and", or @ for "at", except a regular Japanese person will know single characters for about 2000+ commonly used words. If you're trying to make the app child friendly, the content of the text will change to characters to phonetically sound out the components of a word (like English).

Support for Arabic is very useful to build in from the get go to ensure you can support RTL (right to left) languages. Nothing is more painful than trying to bolt on RTL support for your GUI elements and layout after you've already made a GUI. Build it in from the start and control it with a simple boolean/flag/enum.

Supporting these four languages will ensure you have no issues with variable content sizes, RTL layouts, unicode and CJK fonts. If I were you I would add them to your I18N proof of concept checklist. Spanish and German aren't that useful for testing as they both mainly use the same Latin character set with German only being about 130% as many characters as English.

that's some pretty good insight, thanks!

My guess is that Pent mentioned German because he knows that I did some German translation on 1.x, thus it's a language we already have a translator for. :P