Wesnoth for Löve

Discussion of all aspects of the game engine, including development of new and existing features.

Moderator: Forum Moderators

fabi
Inactive Developer
Posts: 1260
Joined: March 21st, 2004, 2:42 pm
Location: Germany

Wesnoth for Löve

Post by fabi »

Wesnoth for Löve is a port of Wesnoth to the Löve game engine.
There is no release yet, although I am working towards releasing a not playable Techdemo during the rest of the month.

Löve offers some nice features the current Wesnoth engine can't provide easily.
The particle system might be the one with the most user visible impact if put in use, while being a relatively low hanging fruit.

The project's goal is to provide the future engine Wesnoth is being played with while reducing complexity and maintenance by a huge amount.

Wesnoth for Löve (or short W4L) is nearly entirely written in Moonscript, a language that compiles to Lua.
It is licensed under the GPL2+ like Wesnoth, making sure parts of Wesnoth's codebase can be reused after translation to Moonscript.

W4L's content is written in the "Wesnoth Script Language" (WSL), which is a slightly modified Moonscript with Macro support.
WSL's api is very similar to Wesnoth's WML api, also supporting the Lua api. (all action WSL is implemented using the Lua api)
The Wesnoth Markup Language (WML) is no longer supported, although there is a transcompiler (from WML into WSL) in the works which will be used to keep most of the old content alive without much porting effort involved.

Please feel free to join the newly created Discord server to discuss W4L.
Download
Windows self extracting archive
Debian package
Macos zip archive

The Debian packages have been tested on Ubuntu 20.04.
The MacOsX version is known to work when started from the command-line, but fails finding a library else.
It is updated as soon as someone finds a solution (I can't test it myself).
The Windows version has been tested under Ubuntu 20.04 using the Wine emulation.
NotTODO
This section is about features you find in Wesnoth I don't plan to support in W4L.

1) Undo feature
Undo can be used to cheat, "Wose Probing", you know about the Wose but not the exact location? Want to be ambushed?
Is it north? No, Undo. South? No, Undo. ...
It is also unreliable.
Some years in the past a player asked me to implement a new feature, that displays if a move can be undone regarding fog/shroud.
So in my opinion that feature is broken and I don't plan to implement it, also reducing the complexity.
Most errors I make when playing are not moves I did deliberately that I want to rethink, but mistakes I make because of the ancient control sheme the game comes with.
So my hope is that a better user interface will compensate the loss of the undo feature to some degree.

2) The Whiteboard
For now I don't plan to port this one.
I guess this needs more discussion, I will write more later.

3) Multiple Turn paths
Wesnoth usually does not allow for exact planing of even only one turn further.
Whenever I play and there is a multiturn path set and my unit thus moves at the beginning of my turn, it is annoying for me and I want to undo.
That might not be true for some RPG like scenarios with huge maps where the player can walk 10 turns without any enemy contact but vanilla Wesnoth simply does not need that feature.
Contributors
W4L is not based on my thoughts alone.
There has been input from plenty of people.

Iceiceice is especially to mention, he subscribed himself to the development of a new engine first and convinced me later.
A lot of W4L is influenced by his plans.
Screenshots
The Launcher
The Launcher
Preferences Dialog
Preferences Dialog
Title Screen
Title Screen
Campaign selection dialog
Campaign selection dialog
Story Screen
Story Screen
Message Dialog
Message Dialog
Last edited by fabi on October 1st, 2020, 12:08 am, edited 4 times in total.
"Wesnoth has many strong points but team and users management are certainly not in them." -- pyrophorus
User avatar
doofus-01
Art Director
Posts: 3933
Joined: January 6th, 2008, 9:27 pm
Location: USA

Re: Wesnoth for Löve

Post by doofus-01 »

From what I can tell, Love supports parallax scrolling. If there's a WML -> WSL converter, so existing UMC doesn't have to be rewritten from scratch, this sounds great to me.

The clean break from WML that Haldric is taking, no backwards compatibility, is a killer for me. I doubt I'm the only one that feels that way.

Recreating the terrain graphics seems daunting. If it's early enough still, would it makes sense to try rotating the hexes 90 degrees, so there is NE, E, SE, SW, etc. instead of N, NE, SE, S, etc.? This would make unit animations easier, though certain things like the castles would need significant revisions.
BfW 1.12 supported, but active development only for BfW 1.13/1.14: Bad Moon Rising | Trinity | Archaic Era |
| Abandoned: Tales of the Setting Sun
GitHub link for these projects
fabi
Inactive Developer
Posts: 1260
Joined: March 21st, 2004, 2:42 pm
Location: Germany

Re: Wesnoth for Löve

Post by fabi »

doofus-01 wrote: September 14th, 2020, 1:57 am From what I can tell, Love supports parallax scrolling.
From what I have learned about Löve so far (which is not all there is) it is not supporting parallax scrolling directly but there are libs out there which add support for it.
Do you have a usecase in mind? How would the wml/wsl api support it?
Please feel free to fill a feature request.
If there's a WML -> WSL converter, so existing UMC doesn't have to be rewritten from scratch, this sounds great to me.
The prototype is still very limited but was able to successfully transcompile AoI.
I guess it will never be perfect, but with a bit of manual help it should do most add-ons in the end.
The clean break from WML that Haldric is taking, no backwards compatibility, is a killer for me. I doubt I'm the only one that feels that way.
No, you are not the only one that feels that way. :D
Recreating the terrain graphics seems daunting.
Not really.
wml2wsl (the transcompiler) will give me the terrain definitions.
The backend c++ code is to be translated by hand into Moonscript.
That worked for the pathfinding before, it is some work, but nothing scary.
edit: Moonscript comes with support for Classes, making translating OO-code more easy.

The only reason I haven't proceeded on that front is the macro heaviness of the terrain graphics wml.
The wml2wsl prototype can't handle everything macro yet.
Thus proper terrain transitions (and animations) have to wait until wml2wsl got a rewrite.
If it's early enough still, would it makes sense to try rotating the hexes 90 degrees, so there is NE, E, SE, SW, etc. instead of N, NE, SE, S, etc.? This would make unit animations easier, though certain things like the castles would need significant revisions.
Well, I am not an artist. Rotating the terrains will result in a lot of images to be redone...
Or maybe I misunderstood your suggestion?
"Wesnoth has many strong points but team and users management are certainly not in them." -- pyrophorus
User avatar
doofus-01
Art Director
Posts: 3933
Joined: January 6th, 2008, 9:27 pm
Location: USA

Re: Wesnoth for Löve

Post by doofus-01 »

Yes, it would require rework of the images for existing assets, but it would make future contributions much simpler. More for the unit sprites than the terrain graphics. It might not be worth it in the end, but best to think about it now, before too much is invested.
Don't worry, the support for the current terrains is not too much work. (Simply because I can reuse the existing c++ code)
Adding support for your proposed map format is on the todo list now, no matter if the artwork is ever reworked.
Their might be other projects making use of the engine in the future and I have read about the advantages and disadvantages of different hex field layouts before, so that was already on my mind for some time.
The two use cases I see are (there may be more):
1. Weather (clouds closer to the camera, maybe rain or snow) and possibly something similar to Time of Day tinting
2. Backdrops - for example, there is a floor below the playable map, visible through the chasms. Or the playable map is up in the air, either it is a mountaintop or it is floating.

Basically an image or layer that pans at a different speed than the playable map.
I see. This should not be hard, it is noted and also added to the todo.
BfW 1.12 supported, but active development only for BfW 1.13/1.14: Bad Moon Rising | Trinity | Archaic Era |
| Abandoned: Tales of the Setting Sun
GitHub link for these projects
User avatar
Pentarctagon
Project Manager
Posts: 4532
Joined: March 22nd, 2009, 10:50 pm
Location: Earth (occasionally)

Re: Wesnoth for Löve

Post by Pentarctagon »

Does this/would this be able to support iOS? Currently the iOS port is the source of the vast majority of Wesnoth, Inc's income. The Liberapay is helpful too, but currently it isn't close to being enough by itself.
99 little bugs in the code, 99 little bugs
take one down, patch it around
-2,147,483,648 little bugs in the code
fabi
Inactive Developer
Posts: 1260
Joined: March 21st, 2004, 2:42 pm
Location: Germany

Re: Wesnoth for Löve

Post by fabi »

Pentarctagon wrote: September 14th, 2020, 3:56 am Does this/would this be able to support iOS? Currently the iOS port is the source of the vast majority of Wesnoth, Inc's income. The Liberapay is helpful too, but currently it isn't close to being enough by itself.
Löve's homepage wrote: Hi there! LÖVE is an *awesome* framework you can use to make 2D games in Lua. It's free, open-source, and works on Windows, Mac OS X, Linux, Android and iOS.
edit: Keep in mind, I have not checked if my only dependency so far, the lpeg library is available on the mobile platforms.
Although not having that library available can be work arounded, so the answer should be,
Yes, it can run on Android and iOS
"Wesnoth has many strong points but team and users management are certainly not in them." -- pyrophorus
fabi
Inactive Developer
Posts: 1260
Joined: March 21st, 2004, 2:42 pm
Location: Germany

Re: Wesnoth for Löve

Post by fabi »

doofus-01 wrote: September 14th, 2020, 3:37 amYes, it would require rework of the images for existing assets, but it would make future contributions much simpler. More for the unit sprites than the terrain graphics. It might not be worth it in the end, but best to think about it now, before too much is invested.
Another reason to make your suggested change:
Hex field height is 72 pixels, but the effective width of Wesnoth's hex fields is only 54 pixels.
Thus a square map is higher than it is wide.
Modern Displays tend to get wider and more wider.
Thus having the effective 54 pixels in the height and not in the width is an advantage.
"Wesnoth has many strong points but team and users management are certainly not in them." -- pyrophorus
gnombat
Posts: 302
Joined: June 10th, 2010, 8:49 pm

Re: Wesnoth for Löve

Post by gnombat »

fabi wrote: September 14th, 2020, 6:01 am Another reason to make your suggested change:
Hex field height is 72 pixels, but the effective width of Wesnoth's hex fields is only 54 pixels.
Thus a square map is higher than it is wide.
Modern Displays tend to get wider and more wider.
Thus having the effective 54 pixels in the height and not in the width is an advantage.
There is an interesting discussion about the advantages and disadvantages of each layout here:

https://gamedev.stackexchange.com/quest ... s-and-cons
gfgtdf
General Code Maintainer
Posts: 1343
Joined: February 10th, 2013, 2:25 pm

Re: Wesnoth for Löve

Post by gfgtdf »

This looks like a promising appoach.

Out or curiosity, have you thought about how to implement addon support and the sandboxing of addons? Tbh if i were to do it now again i'd probably try to use operating system level sandboxing with child processes rather than blocking lua api as we do now.
Scenario with Robots SP scenario (1.11/1.12), allows you to build your units with components, PYR No preperation turn 1.12 mp-mod that allows you to select your units immideately after the game begins.
gfgtdf
General Code Maintainer
Posts: 1343
Joined: February 10th, 2013, 2:25 pm

Re: Wesnoth for Löve

Post by gfgtdf »

I also want to say that i really like being able to use luajit over classic lua. When writing add-ons i was once in the situation where my code was just not fast enough so i added a lua api for an existent c++ core wesnoth function which does the same job (which i usually dislike to do (unlike some other people), if its possibel in lua i usually prefer just letting people do things in lua). when i then tested my original code in luajit however it ran just as fast as the c++ code.
Scenario with Robots SP scenario (1.11/1.12), allows you to build your units with components, PYR No preperation turn 1.12 mp-mod that allows you to select your units immideately after the game begins.
User avatar
Pentarctagon
Project Manager
Posts: 4532
Joined: March 22nd, 2009, 10:50 pm
Location: Earth (occasionally)

Re: Wesnoth for Löve

Post by Pentarctagon »

#3195 for reference of the previous discussion about luajit.
99 little bugs in the code, 99 little bugs
take one down, patch it around
-2,147,483,648 little bugs in the code
fabi
Inactive Developer
Posts: 1260
Joined: March 21st, 2004, 2:42 pm
Location: Germany

Re: Wesnoth for Löve

Post by fabi »

gfgtdf wrote: September 14th, 2020, 7:02 pm Out or curiosity, have you thought about how to implement addon support and the sandboxing of addons? Tbh if i were to do it now again i'd probably try to use operating system level sandboxing with child processes rather than blocking lua api as we do now.
Löve supports the mounting of zip files inside its virtual filesystem.
So add-ons are just zips containing the content, named <addon_name>.wesnoth.

You can already drag and drop a file on the window of the launcher.
It will ask if you want to install the addon if the file extension matches ''.wesnoth'.

Löve ships with luajit and only luajit, so there is simply no option.
(Considering love2d is not modified, but I really do want to avoid that)

Löve does not offer access to operating system level sandboxing,
I need to trust that Löve secures the lua code execution well enough.

When I load data files the execution is done in its own environment containing only the needed functions plus some more to make the live of content creators easier. But that is all done using lua build in mechanics.
"Wesnoth has many strong points but team and users management are certainly not in them." -- pyrophorus
gfgtdf
General Code Maintainer
Posts: 1343
Joined: February 10th, 2013, 2:25 pm

Re: Wesnoth for Löve

Post by gfgtdf »

fabi wrote: September 14th, 2020, 8:26 pm
I need to trust that Löve secures the lua code execution well enough.
I would not assume that this is the case in particular since i have seen no place so far where they claim that they do this. running 'untrusted' code is still a somewhat rare requirement for games


EDIT: furthermore if you want to implement server in a server-client model where the actual code is run on the server (unliek currentl wesnoth where umc code is only executed on the client), you need some operating system specific code to limits a games resourses usage. Once you have that, implementing full os-level sandbooxing via functions like seccomp-bpf (on Linux, din't look up the equivalents on other OS) might be a rather small step.
Scenario with Robots SP scenario (1.11/1.12), allows you to build your units with components, PYR No preperation turn 1.12 mp-mod that allows you to select your units immideately after the game begins.
User avatar
Pentarctagon
Project Manager
Posts: 4532
Joined: March 22nd, 2009, 10:50 pm
Location: Earth (occasionally)

Re: Wesnoth for Löve

Post by Pentarctagon »

fabi wrote: September 14th, 2020, 8:26 pm Löve ships with luajit and only luajit, so there is simply no option.
(Considering love2d is not modified, but I really do want to avoid that)
I agree that it'd be best to not modify love2d. Another issue with luajit though is it supports an older version of lua than Wesnoth currently does, so that would be another point of potential incompatibility for current add-ons/mainline.
99 little bugs in the code, 99 little bugs
take one down, patch it around
-2,147,483,648 little bugs in the code
gfgtdf
General Code Maintainer
Posts: 1343
Joined: February 10th, 2013, 2:25 pm

Re: Wesnoth for Löve

Post by gfgtdf »

Pentarctagon wrote: September 14th, 2020, 9:01 pm
fabi wrote: September 14th, 2020, 8:26 pm Löve ships with luajit and only luajit, so there is simply no option.
(Considering love2d is not modified, but I really do want to avoid that)
I agree that it'd be best to not modify love2d. Another issue with luajit though is it supports an older version of lua than Wesnoth currently does, so that would be another point of potential incompatibility for current add-ons/mainline.
while technicality true i think the cases of incompatibilities are rare and easy to fix, i don't expect full compatibility anyways, so this is probably a really minor issue.
Scenario with Robots SP scenario (1.11/1.12), allows you to build your units with components, PYR No preperation turn 1.12 mp-mod that allows you to select your units immideately after the game begins.
Post Reply