Wesnoth for Löve
Moderator: Forum Moderators
Wesnoth for Löve
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.
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
NotTODO
Contributors
Screenshots
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
Re: Wesnoth for Löve
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.
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
| Abandoned: Tales of the Setting Sun
GitHub link for these projects
Re: Wesnoth for Löve
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.
The prototype is still very limited but was able to successfully transcompile AoI.If there's a WML -> WSL converter, so existing UMC doesn't have to be rewritten from scratch, this sounds great to me.
I guess it will never be perfect, but with a bit of manual help it should do most add-ons in the end.
No, you are not the only one that feels that way.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.
Not really.Recreating the terrain graphics seems daunting.
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.
Well, I am not an artist. Rotating the terrains will result in a lot of images to be redone...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.
Or maybe I misunderstood your suggestion?
"Wesnoth has many strong points but team and users management are certainly not in them." -- pyrophorus
Re: Wesnoth for Löve
Don't worry, the support for the current terrains is not too much work. (Simply because I can reuse the existing c++ code)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.
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.
I see. This should not be hard, it is noted and also added to the todo.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.
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
| Abandoned: Tales of the Setting Sun
GitHub link for these projects
- Pentarctagon
- Project Manager
- Posts: 5592
- Joined: March 22nd, 2009, 10:50 pm
- Location: Earth (occasionally)
Re: Wesnoth for Löve
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
take one down, patch it around
-2,147,483,648 little bugs in the code
Re: Wesnoth for Löve
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.
edit: Keep in mind, I have not checked if my only dependency so far, the lpeg library is available on the mobile platforms.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.
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
Re: Wesnoth for Löve
Another reason to make your suggested change: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.
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
Re: Wesnoth for Löve
There is an interesting discussion about the advantages and disadvantages of each layout here: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.
https://gamedev.stackexchange.com/quest ... s-and-cons
Re: Wesnoth for Löve
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.
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.
Re: Wesnoth for Löve
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.
- Pentarctagon
- Project Manager
- Posts: 5592
- Joined: March 22nd, 2009, 10:50 pm
- Location: Earth (occasionally)
Re: Wesnoth for Löve
#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
take one down, patch it around
-2,147,483,648 little bugs in the code
Re: Wesnoth for Löve
Löve supports the mounting of zip files inside its virtual filesystem.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.
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
Re: Wesnoth for Löve
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.
- Pentarctagon
- Project Manager
- Posts: 5592
- Joined: March 22nd, 2009, 10:50 pm
- Location: Earth (occasionally)
Re: Wesnoth for Löve
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
take one down, patch it around
-2,147,483,648 little bugs in the code
Re: Wesnoth for Löve
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.Pentarctagon wrote: ↑September 14th, 2020, 9:01 pmI 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.
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.