Feedback on Wesnoth from a year's old user
Moderator: Forum Moderators
Feedback on Wesnoth from a year's old user
Hello.
This is some feedback, perhaps it may be helpful in the long run.
I think I first heard of Wesnoth in 2004 or so, not entirely sure.
I tried it out, did not like it, and let it slide down.
A year or two years lateron I tried it again, and this time I liked it.
Especially the campaigns were nice.
Eventually I lost interest again.
Now, most of this has nothing to do with Wesnoth itself, but there are also a few problems that would seem, to me, inherent to the project.
(1) The codebase increased:
It may not be a problem for other people but 330 MB, and the sudden dependency on boost, really really really really annoyed me.
There is just so much size now! And not long afterwards ... you lack about developers being active on the project.
How about keeping things simple? Small? What's wrong with that philosophy? Lower the entry barrier to developers, don't let only
old C++ gurus work on things with a PhD to understand what is going on.
(2) There has not been enough of a focus on the game mechanic. Sure, there were new abilities and such, but the game mechanic
in itself stayed the same. And very simple. Nothing wrong with simple, mind you, but I believe in the long run, there has to be
more creative incentive. Heroes could have more abilities for instance. Or perhaps allow them to help lead army stacks, not
unlike the old Warlords game had.
(3) WML.
I really really hate WML. It would have been nice to move to something else. I once wanted to create a campaign but I gave up
due to WML. If you want to make campaign creation easier then simplify the creation of WMLs.
To use XML as programming logic was really a bad choice. [if something]
come on...
This is some feedback, perhaps it may be helpful in the long run.
I think I first heard of Wesnoth in 2004 or so, not entirely sure.
I tried it out, did not like it, and let it slide down.
A year or two years lateron I tried it again, and this time I liked it.
Especially the campaigns were nice.
Eventually I lost interest again.
Now, most of this has nothing to do with Wesnoth itself, but there are also a few problems that would seem, to me, inherent to the project.
(1) The codebase increased:
It may not be a problem for other people but 330 MB, and the sudden dependency on boost, really really really really annoyed me.
There is just so much size now! And not long afterwards ... you lack about developers being active on the project.
How about keeping things simple? Small? What's wrong with that philosophy? Lower the entry barrier to developers, don't let only
old C++ gurus work on things with a PhD to understand what is going on.
(2) There has not been enough of a focus on the game mechanic. Sure, there were new abilities and such, but the game mechanic
in itself stayed the same. And very simple. Nothing wrong with simple, mind you, but I believe in the long run, there has to be
more creative incentive. Heroes could have more abilities for instance. Or perhaps allow them to help lead army stacks, not
unlike the old Warlords game had.
(3) WML.
I really really hate WML. It would have been nice to move to something else. I once wanted to create a campaign but I gave up
due to WML. If you want to make campaign creation easier then simplify the creation of WMLs.
To use XML as programming logic was really a bad choice. [if something]
come on...
Re: Feedback on Wesnoth from a year's old user
Yep, i would replace c++ and wml for c#/java and python.
Re: Feedback on Wesnoth from a year's old user
OK... But what is the problem, exactly?shevegen wrote:I really really hate WML.
I think it's pretty unlikely that someone who has problems with WML would have had a better time with python. Maybe someone who already knew python and didn't care to learn WML would have a better time.Slann wrote:Yep, i would replace c++ and wml for c#/java and python.
Or, more seriously, maybe someone who didn't know either would be more willing to invest greater time and effort in something that is more generally useful outside a game. And I'm pretty sure it would take a greater effort.
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: Feedback on Wesnoth from a year's old user
I think WML is very nice, to be honest. I feel very comfortable using it, and it looks quite clean.
Re: Feedback on Wesnoth from a year's old user
Yeah, I don't know what actual language you think you could make easier to use than WML.
"There are two kinds of old men in the world. The kind who didn't go to war and who say that they should have lived fast died young and left a handsome corpse and the old men who did go to war and who say that there is no such thing as a handsome corpse."
Re: Feedback on Wesnoth from a year's old user
For the most part, the “sudden dependency on boost” is only a concern for packagers and developers, not users — unless you are running one of those niche Linux distributions where every single thing you install must be built from source on your own machine, that is, in which case I’d suggest sticking with one of the mainstream binary distributions like Ubuntu, Debian or Fedora instead if it’s such a hassle to deal with a single game’s dependencies.shevegen wrote:(1) The codebase increased:
It may not be a problem for other people but 330 MB, and the sudden dependency on boost, really really really really annoyed me.
There is just so much size now! And not long afterwards ... you lack about developers being active on the project.
How about keeping things simple? Small? What's wrong with that philosophy? Lower the entry barrier to developers, don't let only
old C++ gurus work on things with a PhD to understand what is going on.
If you take a look at Wesnoth’s evolution since 1.0, you’ll notice that for the most part, the increased C++ code complexity stems from the usage of templates and inheritance in order to make certain parts of the engine more generic and reusable in different contexts and configurations — GUI2 (
src/gui/
since 1.5.x) and the AI engine (src/ai/
since 1.7.x) are the most obvious offenders in this regard. Perhaps it may seem excessive for mainline usage, but on the other hand we have gained the ability to write our own GUI dialogs in user-made content (without having to worry about giving specific coordinates for every widget), and tweak the AI in all kinds of ways, such as extending it with custom scripts written in Lua.This kind of thing is always open to discussion, especially so with campaign-specific units. As I recall, Li’sar’s initiative ability added in 1.12 was born from an Ideas topic. However, changing the core game rules (e.g. ranged attacks requiring units to be adjacent to each other, attack swings having an RNG-determined outcome, there not being fractional damage values, among others) is usually out of the question just like you wouldn’t ask people to play chess on a football stadium by tossing a ball around.shevegen wrote:(2) There has not been enough of a focus on the game mechanic. Sure, there were new abilities and such, but the game mechanic
in itself stayed the same. And very simple. Nothing wrong with simple, mind you, but I believe in the long run, there has to be
more creative incentive. Heroes could have more abilities for instance.
Since 1.9.x (and to a much lesser extent 1.7.x), people have the option to implement most event logic in Lua if they want, but they’ll find that Lua is somewhat inadequate for situations where it’s needed to express heterogeneous data objects such as unit types, unit filters, terrain graphics rules, and scenario settings.shevegen wrote:(3) WML.
I really really hate WML. It would have been nice to move to something else. I once wanted to create a campaign but I gave up
due to WML. If you want to make campaign creation easier then simplify the creation of WMLs.
—
Also, since you appeared to be equating Wesnoth’s distribution size with code complexity earlier, perhaps you’d like to see some numbers:
Code: Select all
shadowm@nanacore:~/src/wesnoth% du -sh images data/core/images data/core/music sounds data/core/sounds src translations fonts
7.9M images
115M data/core/images
139M data/core/music
612K sounds
7.6M data/core/sounds
16M src
98M translations
9.3M fonts
shadowm@nanacore:~/src/wesnoth% du -csh data/campaigns/*/images | tail -n 1
92M total
Author of the unofficial UtBS sequels Invasion from the Unknown and After the Storm.
Re: Feedback on Wesnoth from a year's old user
So I'm also in the WML is a really bad language camp.
Here are some of the reasons:
1.) Reliance on macros
2.) No ability to define functions
3.) No ability to pass functions as arguments. Passing macros as arguments is not an acceptable substitute, it's not really the same thing and it makes things hard to debug.
4.) Very poor error reporting. In other languages, like QBasic, if I miss a $ on a variable name when I try to use it, it's a syntax error that gets reported immediately. In WML your scenario is just silently broken. There are many other similar examples where wesnoth silently ignores things that would be syntax errors in better languages.
5.) No assignment syntax. In essentially all programming languages since 1980, a syntax "X = Y" is supported for assigning values to variables.
In WML if i want to e.g. change a unit's side to match the side of a different unit, it's very clumsy and complicated:
[store_unit]
to_variable = X
...
[/store_unit]
[store_unit]
to_variable = Y
...
[/store_unit]
{VARIABLE X.side $Y.side}
[unstore_unit]
variable = X
...
[/unstore_unit]
In a modern language, this would be a one liner:
Units["first unit"].side = Units["second unit"].side
or similar.
In general assignment syntax is good because it's very simple and readable, and avoids the need to create temporary variables, which are also a maintenance burden.
In Wesnoth, tons of things have to be done with all these one-off "store" and "unstore" commands, as though its some kind of bizarre assembly language. To top it off most of these have slightly different syntax...
As a general rule, I think it's always a bad idea to "invent your own programming language" just for a single application. It's always better to use an existing, professional-quality programming language and create an API for it, or if you need to, write extensions for it. Making your own programming language is essentially either a huge time sink (think multiple man years of testing and refining) or the result is going to end up very subpar and then you will waste your time struggling to use a subpar tool.
If we had from the start used lua or javascript or some other general purpose thing exclusively as the programming language of choice, we would have
(1) less documentation to write, and things would be more intuitive for new people
(2) all the content, all the scenarios, would be in an independent, easy to use programming language. Someone could make a brand new engine for the game and easily parse all the old scenarios, by importing the lua library, or embedding javascript, or similar. If they want to implement WML from scratch though, they have a huge, huge job ahead of them. Today, WML is basically a data jail for our content, just the same way that GNA is a data jail for our bug tracker info (if your desire is to rewrite the engine).
Here are some of the reasons:
1.) Reliance on macros
2.) No ability to define functions
3.) No ability to pass functions as arguments. Passing macros as arguments is not an acceptable substitute, it's not really the same thing and it makes things hard to debug.
4.) Very poor error reporting. In other languages, like QBasic, if I miss a $ on a variable name when I try to use it, it's a syntax error that gets reported immediately. In WML your scenario is just silently broken. There are many other similar examples where wesnoth silently ignores things that would be syntax errors in better languages.
5.) No assignment syntax. In essentially all programming languages since 1980, a syntax "X = Y" is supported for assigning values to variables.
In WML if i want to e.g. change a unit's side to match the side of a different unit, it's very clumsy and complicated:
[store_unit]
to_variable = X
...
[/store_unit]
[store_unit]
to_variable = Y
...
[/store_unit]
{VARIABLE X.side $Y.side}
[unstore_unit]
variable = X
...
[/unstore_unit]
In a modern language, this would be a one liner:
Units["first unit"].side = Units["second unit"].side
or similar.
In general assignment syntax is good because it's very simple and readable, and avoids the need to create temporary variables, which are also a maintenance burden.
In Wesnoth, tons of things have to be done with all these one-off "store" and "unstore" commands, as though its some kind of bizarre assembly language. To top it off most of these have slightly different syntax...
As a general rule, I think it's always a bad idea to "invent your own programming language" just for a single application. It's always better to use an existing, professional-quality programming language and create an API for it, or if you need to, write extensions for it. Making your own programming language is essentially either a huge time sink (think multiple man years of testing and refining) or the result is going to end up very subpar and then you will waste your time struggling to use a subpar tool.
If we had from the start used lua or javascript or some other general purpose thing exclusively as the programming language of choice, we would have
(1) less documentation to write, and things would be more intuitive for new people
(2) all the content, all the scenarios, would be in an independent, easy to use programming language. Someone could make a brand new engine for the game and easily parse all the old scenarios, by importing the lua library, or embedding javascript, or similar. If they want to implement WML from scratch though, they have a huge, huge job ahead of them. Today, WML is basically a data jail for our content, just the same way that GNA is a data jail for our bug tracker info (if your desire is to rewrite the engine).
- Pentarctagon
- Project Manager
- Posts: 5564
- Joined: March 22nd, 2009, 10:50 pm
- Location: Earth (occasionally)
Re: Feedback on Wesnoth from a year's old user
In my mind, WML is in some ways what would have happened if javascript got merged straight into HTML rather than being a separate scripting language. That said, if Wesnoth had used lua for everything I would probably have never gotten anywhere making any add-ons at all since when I first started I had zero programming knowledge, and jumping straight into lua would have been a non-starter.
edit:
Some more specific data from a fresh git clone:
edit:
Some more specific data from a fresh git clone:
Code: Select all
Total size of all counted files: 2.86 GB
Total number of files counted: 19042
There were 1 files of type .pack which take up 2.18 GB
There were 1596 files of type .po which take up 284.32 MB
There were 13065 files of type .png which take up 177.91 MB
There were 264 files of type .ogg which take up 143.44 MB
There were 1 files of type .idx which take up 25.01 MB
There were 128 files of type .jpg which take up 12.71 MB
There were 1214 files of type .cfg which take up 8.87 MB
There were 8 files of type .ttf which take up 8.78 MB
There were 659 files of type .cpp which take up 7.50 MB
There were 212 files of type no_extension which take up 3.92 MB
There were 28 files of type .pot which take up 3.69 MB
There were 302 files of type .map which take up 3.00 MB
There were 1 files of type .fo which take up 2.82 MB
There were 45 files of type .html which take up 2.81 MB
There were 54 files of type .wav which take up 2.74 MB
There were 650 files of type .hpp which take up 2.55 MB
There were 211 files of type .java which take up 1.93 MB
There were 43 files of type .h which take up 1.25 MB
There were 14 files of type .c which take up 887.75 KB
There were 6 files of type .vcproj which take up 617.20 KB
There were 51 files of type .6 which take up 609.31 KB
There were 9 files of type .bmp which take up 575.48 KB
There were 86 files of type .lua which take up 573.76 KB
There were 1 files of type .pbxproj which take up 545.26 KB
There were 2 files of type .nib which take up 465.62 KB
There were 48 files of type .py which take up 413.54 KB
There were 2 files of type .xcf which take up 404.45 KB
There were 3 files of type .el which take up 296.91 KB
There were 6 files of type .project which take up 270.34 KB
There were 24 files of type .mask which take up 230.07 KB
There were 2 files of type .inl which take up 208.86 KB
There were 46 files of type .txt which take up 195.47 KB
There were 4 files of type .so which take up 191.07 KB
There were 3 files of type .ico which take up 169.82 KB
There were 5 files of type .cbp which take up 147.65 KB
There were 1 files of type .4 which take up 102.79 KB
There were 12 files of type .prefs which take up 100.66 KB
There were 15 files of type .tex which take up 96.70 KB
There were 2 files of type .g which take up 83.11 KB
There were 6 files of type .js which take up 80.81 KB
There were 1 files of type .pyw which take up 72.00 KB
There were 16 files of type .cmake which take up 71.25 KB
There were 13 files of type .xml which take up 67.70 KB
There were 1 files of type .icns which take up 58.75 KB
There were 1 files of type .xpm which take up 35.46 KB
There were 15 files of type .fai which take up 33.44 KB
There were 31 files of type .in which take up 33.23 KB
There were 6 files of type .tpp which take up 29.35 KB
There were 3 files of type .vim which take up 28.72 KB
There were 1 files of type .xmi which take up 27.31 KB
There were 1 files of type .product which take up 22.29 KB
There were 4 files of type .css which take up 21.59 KB
There were 8 files of type .properties which take up 21.09 KB
There were 20 files of type .sh which take up 19.89 KB
There were 5 files of type .md which take up 19.02 KB
There were 1 files of type .texi which take up 18.43 KB
There were 3 files of type .pm which take up 16.20 KB
There were 11 files of type .sample which take up 15.14 KB
There were 1 files of type .ecore which take up 13.82 KB
There were 1 files of type .genmodel which take up 9.27 KB
There were 1 files of type .pl which take up 9.21 KB
There were 1 files of type .cc which take up 8.08 KB
There were 2 files of type .ii which take up 7.76 KB
There were 2 files of type .php which take up 7.74 KB
There were 2 files of type .xml_gen which take up 7.10 KB
There were 2 files of type .conf which take up 6.44 KB
There were 1 files of type .ext which take up 6.05 KB
There were 1 files of type .supp which take up 5.94 KB
There were 1 files of type .sln which take up 5.61 KB
There were 3 files of type .MF which take up 4.57 KB
There were 1 files of type .mm which take up 4.27 KB
There were 1 files of type .yml which take up 4.26 KB
There were 1 files of type .sqlite which take up 4.00 KB
There were 4 files of type .user which take up 3.76 KB
There were 2 files of type .m which take up 3.45 KB
There were 1 files of type .desktop which take up 3.07 KB
There were 1 files of type .ebuild which take up 2.92 KB
There were 1 files of type .mwe2 which take up 2.91 KB
There were 1 files of type .xtext which take up 2.85 KB
There were 4 files of type .gitignore which take up 2.82 KB
There were 2 files of type .cmd which take up 2.08 KB
There were 2 files of type .rc which take up 2.01 KB
There were 1 files of type .dox which take up 1.83 KB
There were 1 files of type .nmf which take up 1.64 KB
There were 1 files of type .clang-format which take up 1.42 KB
There were 1 files of type .modules which take up 1.20 KB
There were 1 files of type .manifest which take up 1.17 KB
There were 3 files of type .workspace which take up 1.14 KB
There were 1 files of type .vert which take up 1.12 KB
There were 3 files of type .classpath which take up 1.12 KB
There were 2 files of type .tokens which take up 1.08 KB
There were 1 files of type .sty which take up 1.05 KB
There were 1 files of type .plist which take up 1.02 KB
There were 1 files of type .frag which take up 1.02 KB
There were 1 files of type .mk which take up 894.00 Bytes
There were 2 files of type .ini which take up 607.00 Bytes
There were 1 files of type .pch which take up 535.00 Bytes
There were 4 files of type .tmpl which take up 512.00 Bytes
There were 1 files of type .growlRegDict which take up 482.00 Bytes
There were 1 files of type .inf which take up 245.00 Bytes
There were 1 files of type .strings which take up 210.00 Bytes
There were 1 files of type .gitattributes which take up 198.00 Bytes
There were 3 files of type .gif which take up 172.00 Bytes
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: Feedback on Wesnoth from a year's old user
I think lua is actually a much simpler and more intuitive language than WML, but the wesnoth lua bindings are somewhat poorly designed. Especially, its needlessly awkward because WML tables are not exactly compatible with lua tables (that's why the lua interface has this extra [1] [2] stuff when you want to get the children tables of a wml table, and requires all these "helper" libraries for comfortable use). If we had built appropriate things like the lua console, and a gamestate inspector in lua, it would be much more usable imo, and would generally give better error messages and run in a general safer, more "fail fast" manner than wesnoth wml does.
Re: Feedback on Wesnoth from a year's old user
It might not be an ideal programming language, but it was not meant to be used for programming. It is perfect for units, scenario properties and dialogues. In most cases, that is all an author needs. Only a few people are crazy enough to try to mod the game using it.shevegen wrote:To use XML as programming logic was really a bad choice.
Can you imagine coding the units in some normal programming language? Or dialogues? It is possible, but insanely ugly. Programming languages are not meant for that. Most larger programs use some kind of configuration language that is separate from the program. The case of some games, they are edited using some 'level editors'. In the case of WML, a proper level editor was never created, so you see its guts yourself. Since wesnoth 1.8, it is possible to use lua for doing the more complex tasks, but one config language to do it all is the easier choice for most people. Lua could be replaced by python that is known by more people, but I think that it's too late for that (however, I don't know python, so maybe there is a reason why it's not used).
Amazing idea. Switching to a programming language that less people know and whose coders are therefore harder to find. Check. Increasing the requirements of the game threefold. Check. Becoming more platform dependant. Check. Three goals achieved with a single idea.Slann wrote:Yep, i would replace c++ and wml for c#/java and python.
Re: Feedback on Wesnoth from a year's old user
Not sure if I have enough weight to convice you for anything.
I'm agree that WML is indeed a huge pain to debug at the moment.
I'm also agree that WML is not a reusable skill. I can't advise to study it to my students.
But it is wrong time to take any decisions about its design. Revolution is never a good choice.
Best thing which can be done is to continue integration of WML and lua.
I'm agree that WML is indeed a huge pain to debug at the moment.
I'm also agree that WML is not a reusable skill. I can't advise to study it to my students.
But it is wrong time to take any decisions about its design. Revolution is never a good choice.
Best thing which can be done is to continue integration of WML and lua.
Re: Feedback on Wesnoth from a year's old user
FWIW as I understand we used to have python AIs built into the game. But the problem is apparently that, python is sort of "too powerful", it's hard to restrict it so that it does not have permission to access your hard drive and things like that. It's really meant to be used for external programs and shell scripting, not internal scripting in a game. (This is all second hand, I've never tried to use embedded python for anything and it might have changed in recent years.) I guess that it was viewed as creating security problems, we don't want UMC content to be able to do bad things to your computer.Dugi wrote: (however, I don't know python, so maybe there is a reason why it's not used).
Re: Feedback on Wesnoth from a year's old user
See also: bug #13048 [Gna.org] and CVE-2009-0367.iceiceice wrote:FWIW as I understand we used to have python AIs built into the game. But the problem is apparently that, python is sort of "too powerful", it's hard to restrict it so that it does not have permission to access your hard drive and things like that. [...]Dugi wrote: (however, I don't know python, so maybe there is a reason why it's not used).
Author of the unofficial UtBS sequels Invasion from the Unknown and After the Storm.
Re: Feedback on Wesnoth from a year's old user
Python is actually well known as an easy and powerful scripting language which puts a lof of emphasis in removing redundant code. I would argue that most will find it easier to learn (since you can find more tutorials on it) and its popularity reduces the burden to find people that will contribute with their own addons.doofus-01 wrote:I think it's pretty unlikely that someone who has problems with WML would have had a better time with python. Maybe someone who already knew python and didn't care to learn WML would have a better time.
Java is at least more used than c++. And c# is safest and cleaner, which would make the maintenance easierDugi wrote:Amazing idea. Switching to a programming language that less people know and whose coders are therefore harder to find. Check.
Of course i'm talking about an ideal. I don't expect anything to change at this point of BfW's life.Dugi wrote:Increasing the requirements of the game threefold. Check.
Which platforms are you missing in Java? maybe apple's iWatch or some more obscure platform? C# on the other side is becoming more open. Yes, not as compatible as c++, but i'm not sure on how many machines should BfW work. Rather i'd put my effort in making a game easier to grow in spite of platform independance for the shake of it.Dugi wrote:Becoming more platform dependant. Check
Those were your own ideas, my ideas are:Dugi wrote:Three goals achieved with a single idea.
* Languages that where made with maintenance and safety in mind.
* Languages that are actually popular and easier to find maintainers/contributors.
* Languages suited for the kind of game BfW is (soft real time)
But it is ok, i know nothing will change. It was just my opinion.
Re: Feedback on Wesnoth from a year's old user
@iceiceice & shadowm
Thanks for the info, I did not think that.
Thanks for the info, I did not think that.
@Slann (long reply):