Wesnoth Philosophy II: Where Next?

[Viliam]

Should it apply only to units discovered in campaigns, to give it a sense of mystery, or should it just be there as a boring tool?

Perhaps when playing single-player, it should describe only units seen in this campaign; when playing multi-player, it should describe all possible multiplayer units (i.e. all units, or all units except some specials).

Note: The "known" units are not only units whom player has seen in scenario, but also those whom player can recruit (because then s/he can read their descriptions in recruit dialog anyway).

[Dacyn]

Note: The "known" units are not only units whom player has seen in scenario, but also those whom player can recruit (because then s/he can read their descriptions in recruit dialog anyway).

IIRC, only the status field can be read from the recruit screen...

[Elvish_Pillager]

There is now a 'profile' button there.

[telex4]

Should it apply only to units discovered in campaigns, to give it a sense of mystery, or should it just be there as a boring tool?

Perhaps when playing single-player, it should describe only units seen in this campaign; when playing multi-player, it should describe all possible multiplayer units (i.e. all units, or all units except some specials).

The thing I like about only showing units discovered or used in single player when using the wesnothpedia in multiplayer is that it links the two modes. It gives the player a sense that, by playing campaigns, they can unlock areas of multiplayer.

[Blackbeard]

I have been working on a GUI framework for Wesnoth, for either a pre or post 1.0 release. It is an abstraction layer that completely hides SDL and STL functions and classes. It supports themes (change the application colours) and can extend to styles (change button shapes, etc.). All GUI objects use a single draw() function that handles text, lines, and images.
It is a single thread event loop model that (currently) does not use callback functions or signal/slots.

There is a string class specifically designed for converting text formats (UTF-8, UTF-16, etc) and language translations (I18n). Since it is a class, it can be adapted to use gettext or similar functionality without breaking the game.

The goal of the framework is to intergrate visuals, audio, and networking into the event loop and separate the GUI details from Wesnoth's game engine.

Included is a screenshot showing the application with a (blank) menubar, a toolbar (with text buttons), a statusbar (bottom), and two framed dialogs.

It lacks move, resize, and update clipping, but the capability is designed into the framework and will be implemented.

I'd propose to make gettext support a required condition. It's a large change and 1.0 should have easily translatable strings in it. It should especially be easy to translate user campaings which are not yet included.
IMHO, this is a major aspect of getting status: polished.

I would like for gettext to get in, however I refuse to make it a required condition.
...
If Ayin were to commit to working on gettext, and give me assurances of its prompt completion, I would be willing to delay a little more, since I have confidence in Ayin's programming and internationalization skills.
David

I'd like to use gettext, too, so I'd like to hear from Ayin.

Do you think its worth porting Wesnoth to a framework at some point?

[mbabuskov]

We'd just change the string in the translation file to say something more sensible once campaigns are actually complete.

How about displaying some nice picture and text (like at the beginning of the campaign) ?

[Dave]

We'd just change the string in the translation file to say something more sensible once campaigns are actually complete.

How about displaying some nice picture and text (like at the beginning of the campaign) ?

Sure, that's what I meant when I mentioned the possibility of displaying a 'dummy scenario' with a storyline sequence only.

David

[Dave]

Do you think its worth porting Wesnoth to a framework at some point?

Possibly, if the framework is high quality, and there are noticeable improvements in Wesnoth from porting to it.

David

[Blackbeard]

David, it's good to know you'll consider porting Wesnoth to a GUI framework. My post is premature, but thought you should be aware that someone is working on this. I'd love to pester you about how Wesnoth handles overlays and other surface details, but I have the source and it's more important that release 1.0 is made soon.

I don't want to burden developers with another (buggy) package to hack on while trying to complete the last 10%. On the other hand, I would like feedback on what a Wesnoth GUI should (and shouldn't) do, so I don't waste my time on needless stuff.

The source is not ready for distribution, but I have doxygen API HTML docs that gives an overview of the package, if anyone is interested.

[Ayin]

I have been working on a GUI framework for Wesnoth, for either a pre or post 1.0 release. It is an abstraction layer that completely hides SDL and STL functions and classes.

I understand one may want to do an abstraction of SDL functions (I am not really sure it would be a good idea, but it's up to you to prove the opposite ; ) )

But I really do not understand why you would want do do an abstraction of STL. STL is used everywhere in Wesnoth, and it is a fundamental element of C++; rewriting Wesnoth so it does not (directly) use the STL would be akin to rewriting it in C.

It supports themes (change the application colours) and can extend to styles (change button shapes, etc.). All GUI objects use a single draw() function that handles text, lines, and images.

(...)

The goal of the framework is to intergrate visuals, audio, and networking into the event loop and separate the GUI details from Wesnoth's game engine.

This may be a good thing. For one, using a custom "widget" system in Wesnoth has never been something I have been a big fan of, even if it was the most practical solution given the game's evolution (or given the state or current SDL GUI toolkits, maybe).
If I correctly understood your message, you plan to develop, _for wesnoth_, a GUI toolkit on top of SDL (and SDL_net, SDL_audio, etc). Would it be usable for developing other applications, then?

I do not want to discourage you; I am just being curious: what would be the advantages of your GUI toolkit over others SDL GUI toolkits?

I'd like to use gettext, too, so I'd like to hear from Ayin.

Here, you hear from me :)

I did not have yet the time to start working/helping on the gettext. I'll answer that when I've done with my current tasks. But I will try to answer your questions if you have some (I am not a gettext espert, though)

Do you think its worth porting Wesnoth to a framework at some point?

Same opinion that Dave on that. If the framework:
* Is of good quality
* Provides some significant advantages to Wesnoth
then we'll consider porting the game with interest ; )

[Blackbeard]

I understand one may want to do an abstraction of SDL functions (I am not really sure it would be a good idea, but it's up to you to prove the opposite ; ) )

1- Unified language.
The SDL functions are C, we're using C++. The app (Wesnoth) should not mix languages - unless its absolutely neccessary and its not the case here. Wesnoth will be hacked on by many people with various language skills. It's not good needlessly demanding higher coding skills - particularly with Free Software. The GUI framework, otoh, has no choice, SDL is C, so the framework must use a mix, but it should not demand app developers do so.

Note: Almost all SDL structs are available from the classes, so developers can work around any GUI framework limitations.

2- Data encapsulation (information hiding).
By wrapping SDL data structures in classes you present an abstract data structure more familiar to application developers. You can do data transformations without exposing the details to the developers. For example, writing a pixel to the SDL_Surface is reduced to

WBuffer->setPixel( WPoint, WColour);

or even

WBuffer->drawLine( WRect, WColour);

All the endianness, pitch, depth, byteperpixel details are handled by the classes themselves.

3- Maintenance.
Changes to SDL functions are limited to their containing classes. This minimises breaking apps when the SDL API changes. Further, we can extend SDL classes to include game specific functions, such as animating an Unit image set, rather than messing with SDL_Timer and IMG_Load functions directly. It is theoretically possible to completely replace or remove SDL dependency without affecting any apps at all.

4- Consistency. Write Once - Use Everywhere
Each developer rewrites the same function using different algorithms. This is not only wasted effort, but tough to maintain (see point 5). By using predefined classes you can subclass and extend so developers can reuse each other's code.

For Example, the GUI provides a WMap class to tile a background. An app developer can extend this to WHexMap that tiles hexes, so all developers (editors, utils, etc) can use the WHexMap directly. If there is a bug in the tiling, there is only one place to fix it.

5- Readability
Its easier to read app specific classes than some estoric library jargon. For example, SDL_Surface and SDL_PixelInfo has no meaning in Wesnoth. However a Tile class that contains SDL_Surface functions makes the code more readable. (Tile.update(), Tile.refresh(), Tile.animate(), for example). Similarly, Font.load( fileName ) and Image.setBlend( midBlue ) has self-evident meaning, and the most important Button.draw() collects all the rendering into one place.

But I really do not understand why you would want do do an abstraction of STL. STL is used everywhere in Wesnoth, and it is a fundamental element of C++; rewriting Wesnoth so it does not (directly) use the STL would be akin to rewriting it in C.

Exactly, STL typdefs are all over the place, not centralised and coherrent.
No, the classes inherit STL classes, so all the STL functions are directly available. In most cases, it just means replacing the STL typedef with a framework class. For the rest, recoding is required, but that's part of porting anyway.

iirc (oops, if I recall correctly) developers are expected to use an array class, not C arrays directly, so this is consistent with current practice. (technically they're not C arrays, but a C++ data structure with the same C semantics. The fact that some C++ grammars are identical to C, does not make it C code! The same applies for C/C++ struct data type.)

For example, Unit lists may be defined as

Code: Select all

#include <vector>
class WUnit;
typedef std::vector<WUint> unitVector;
class WUnitList : public unitVector
{
...
virtual WUnitList findRanged( attackType );
};
typedef std::vector<WUnit*> unitPtrVector;
class WUnitPtrList : public unitPtrVector
{
...
virtual WUnitPtrList findRanged( attackType );
};

This doesn't prevent app developers from using STL if they want to. You see, we take the STL classes and teach them about Wesnoth. They now model Wesnoth data structures and algorithms, not generic abstractions.

Some more points:

1- Readability.

A) Consistent naming convention.
STL members are horrible! To add/remove to a list you must push_xxx() and pop_xxx(), which is academic jargon. UnitList.addFirst( Unit ), is far more consistent and readable.

B) Abstract complex data structures.
You can customise STL classes to do Wesnoth specific things, like combine two STL classes into one Wesnoth class, e.g. UnitList, and then search the data structure using custom members, e.g. UnitList.FindRanged( attackMagic ) and UnitList.FindTrait( "Scholarship" ) (heh). The STL (or any class for that matter) should not be required reading to understand the app. I don't care how the computer handles UnitList, I just want to know how the game works. Once the game logic is understood, finding (logical) errors or making improvements is much easier.

C) Avoid iterators.
Don't you just hate them? Let the Wesnoth classes handle them and simply pass and receive Wesnoth objects. KISS

D) Avoid obscure syntax.
std::list<std::map<int,std::vector<Tile> > >(), is tough to read - nevermind understand, but TileList() is instantly groked.

2- Maintenance.
The Standard Template Libaray may not be the same standard across all platforms. Any irregularities can be hidden by wrapping them in framework classes. All the template definitions are collected into well defined classes, so maintenance is centralised. theoretically, STL can be replaced or removed without breaking any apps.

If I correctly understood your message, you plan to develop, _for wesnoth_, a GUI toolkit on top of SDL (and SDL_net, SDL_audio, etc). Would it be usable for developing other applications, then?

Yes! It is a stand-alone library, but can be statically linked to produce a single app binary.

Here, you hear from me

I did not have yet the time to start working/helping on the gettext. I'll answer that when I've done with my current tasks. But I will try to answer your questions if you have some (I am not a gettext espert, though)

Well, gettext is a C library, so ... I'll want to wrap it in C++ classes as a first step. Then, create a member to the WString class WString::i18n() which accesses the WGettext classes to do the language translation. For example,

Code: Select all

// language set to German
WString defeated = "You have been defeated"; // default text
WString victory = WString::i18n("You have emerged vicorious!"); // static call, translates to German
....
WString Message;
if( lost)
  Message = defeated.i18n(); // translates to German
else
  Message = victory; // already translated
Message.draw();  // Displays German text

As a last step, provide some plugin ability, so new translations can be pluged-in at run-time.

Again, by wrapping gettext, it is theoretically possible to replace or remove it without breaking any apps.

btw (argh, by the way), on the topic of plugins, I think the AI (*groan*, Artificial Intelligence) is a good candidate for a plugin. These AI's can be given names and descriptions (Frightening Fred, Bob the Bezerker, Armagedon, Death, Scared Silly, .. whatever).

Thanks for your feedback, the framework still needs much work and unlike David, I have no idea how to implement many things. It's Monkey-C++ Monkey-Do most of the time (surf...read..code, surf..read..code, ..). I know exactly what I want, just don't know how, yet.

[Dave]

I personally think the standard C++ containers are generally very well designed. I have no interest whatsoever in somehow abstracting them away, as to a skilled C++ programmer, this makes things more confusing, rather than less.

David

[Blackbeard]

I personally think the standard C++ containers are generally very well designed.

Agreed. They are subclassed to provide convenient Wesnoth data structures and algorithms, not because they're badly designed. The iterators are excellent tools and do their job efficiently. I'm not against STL at all, in fact the framework only uses containers.

I have no interest whatsoever in somehow abstracting them away, as to a skilled C++ programmer, this makes things more confusing, rather than less.

I'm actually surprised by your remark. In fact I'm stunned. I don't think we're on the same page. Can you please explain what you mean?

[Jetrel]

Back on Topic:

What I think should be done for 1.0:

Code: Uh, I'm not involved yet. freeze it. Do your thing.

With one exception - I would like to see the gender support I had opted for earlier. I will have most of those graphics done in the next few weeks, and I think it would look awesome to have such things in the final version.

Campaigns: Preferably, finish them all, but at least fininsh HTTT and SOTBE.

Units: Female units I had mentioned - I'll get to work on those. I think the dwarves need the runemaster tree added, as well as the unfinished scout.

I would like to see the Goblin Spearman finished and added, and the Saurians spun off into their own faction - or at the least, replaced with the Spearman and put into cold storage.

Music: More added, I'm not involved. It's alright, right now, except for that doggone Undead theme.

Portraits: Replace them all. WML in map support for the different emotions we'll be making.




I would say the goal for code completion would be the next few weeks, and for graphics completion, the end of the summer.

[torangan]

I'm actually surprised by your remark. In fact I'm stunned. I don't think we're on the same page. Can you please explain what you mean?

While I can't answer for Dave, I'd say it's a very simple answer. I do know C++ quite well, so I can read STL code without problems. Your framework may have nice, speaking names but I'll still have to look up the documentation to make sure, that you mean the things I expect. You know, the same names are quite often used to represent (slightly) different concepts...
Another important point: for your classes, I need your documentation and I don't think you'll write as much as there are (good) books about C++ and STL. That you consider iterators awfull is to me a strong indication, that you've not yet worked really much with the STL. They're a powerfull and very clever concept, it just takes some time to get used to it before you can see and use it's advantages.