Feedback on Wesnoth from a year's old user

General feedback and discussion of the game.

Moderators: Forum Moderators, Developers

shevegen
Posts: 247
Joined: June 3rd, 2004, 4:35 pm

Feedback on Wesnoth from a year's old user

Post by shevegen »

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...

User avatar
Slann
Posts: 66
Joined: March 2nd, 2008, 3:47 pm

Re: Feedback on Wesnoth from a year's old user

Post by Slann »

Yep, i would replace c++ and wml for c#/java and python.

User avatar
doofus-01
Art Contributor
Posts: 3836
Joined: January 6th, 2008, 9:27 pm
Location: land of small toilets, according to (impeached) dear leader.

Re: Feedback on Wesnoth from a year's old user

Post by doofus-01 »

shevegen wrote:I really really hate WML.
OK... But what is the problem, exactly?
Slann wrote:Yep, i would replace c++ and wml for c#/java and python.
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.
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

Andrettin
Posts: 187
Joined: September 2nd, 2013, 5:40 pm
Location: Vienna, Austria

Re: Feedback on Wesnoth from a year's old user

Post by Andrettin »

I think WML is very nice, to be honest. I feel very comfortable using it, and it looks quite clean.

Velensk
Multiplayer Contributor
Posts: 3989
Joined: January 24th, 2007, 12:56 am

Re: Feedback on Wesnoth from a year's old user

Post by Velensk »

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."

User avatar
Iris
Site Administrator
Posts: 6607
Joined: November 14th, 2006, 5:54 pm
Location: Chile
Contact:

Re: Feedback on Wesnoth from a year's old user

Post by Iris »

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.
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.

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.
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.
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:(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.
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.



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.

User avatar
iceiceice
Developer
Posts: 1056
Joined: August 23rd, 2013, 2:10 am

Re: Feedback on Wesnoth from a year's old user

Post by iceiceice »

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).

User avatar
Pentarctagon
Forum Administrator
Posts: 4137
Joined: March 22nd, 2009, 10:50 pm
Location: Earth (occasionally)

Re: Feedback on Wesnoth from a year's old user

Post by Pentarctagon »

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:

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

User avatar
iceiceice
Developer
Posts: 1056
Joined: August 23rd, 2013, 2:10 am

Re: Feedback on Wesnoth from a year's old user

Post by iceiceice »

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.

User avatar
Dugi
Posts: 4944
Joined: July 22nd, 2010, 10:29 am
Location: Carpathian Mountains
Contact:

Re: Feedback on Wesnoth from a year's old user

Post by Dugi »

shevegen wrote:To use XML as programming logic was really a bad choice.
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.

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).
Slann wrote:Yep, i would replace c++ and wml for c#/java and python.
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.

User avatar
Xudo
Posts: 561
Joined: April 3rd, 2009, 5:26 pm

Re: Feedback on Wesnoth from a year's old user

Post by Xudo »

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.

User avatar
iceiceice
Developer
Posts: 1056
Joined: August 23rd, 2013, 2:10 am

Re: Feedback on Wesnoth from a year's old user

Post by iceiceice »

Dugi wrote: (however, I don't know python, so maybe there is a reason why it's not used).
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.

User avatar
Iris
Site Administrator
Posts: 6607
Joined: November 14th, 2006, 5:54 pm
Location: Chile
Contact:

Re: Feedback on Wesnoth from a year's old user

Post by Iris »

iceiceice wrote:
Dugi wrote: (however, I don't know python, so maybe there is a reason why it's not used).
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. [...]
See also: bug #13048 [Gna.org] and CVE-2009-0367.
Author of the unofficial UtBS sequels Invasion from the Unknown and After the Storm.

User avatar
Slann
Posts: 66
Joined: March 2nd, 2008, 3:47 pm

Re: Feedback on Wesnoth from a year's old user

Post by Slann »

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.
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.

Dugi wrote:Amazing idea. Switching to a programming language that less people know and whose coders are therefore harder to find. Check.
Java is at least more used than c++. And c# is safest and cleaner, which would make the maintenance easier
Dugi wrote:Increasing the requirements of the game threefold. 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:Becoming more platform dependant. 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:Three goals achieved with a single idea.
Those were your own ideas, my ideas are:
* 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.

User avatar
Dugi
Posts: 4944
Joined: July 22nd, 2010, 10:29 am
Location: Carpathian Mountains
Contact:

Re: Feedback on Wesnoth from a year's old user

Post by Dugi »

@iceiceice & shadowm
Thanks for the info, I did not think that.
@Slann (long reply):

Post Reply