Wesnoth Philosophy II: Where Next?

Discussion among members of the development team.

Moderators: Forum Moderators, Developers

User avatar
Viliam
Translator
Posts: 1341
Joined: January 30th, 2004, 11:07 am
Location: Bratislava, Slovakia
Contact:

Post by Viliam »

telex4 wrote: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
Posts: 1855
Joined: May 1st, 2004, 9:34 am
Location: Texas

Post by Dacyn »

Viliam wrote: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...
User avatar
Elvish_Pillager
Posts: 8129
Joined: May 28th, 2004, 10:21 am
Location: Everywhere you think, nowhere you can possibly imagine.
Contact:

Post by Elvish_Pillager »

There is now a 'profile' button there.
It's all fun and games until someone loses a lawsuit. Oh, and by the way, sending me private messages won't work. :/ If you must contact me, there's an e-mail address listed on the website in my profile.
telex4
Posts: 404
Joined: December 14th, 2003, 1:24 am
Location: Reading, UK
Contact:

Post by telex4 »

Viliam wrote:
telex4 wrote: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
Posts: 87
Joined: January 23rd, 2004, 9:30 pm

Post by 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.
Dave wrote:
torangan wrote: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
Posts: 89
Joined: April 7th, 2004, 1:23 pm
Contact:

Post by mbabuskov »

Dave wrote: 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
Founding Developer
Posts: 7071
Joined: August 17th, 2003, 5:07 am
Location: Seattle
Contact:

Post by Dave »

mbabuskov wrote:
Dave wrote: 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
“At Gambling, the deadly sin is to mistake bad play for bad luck.” -- Ian Fleming
Dave
Founding Developer
Posts: 7071
Joined: August 17th, 2003, 5:07 am
Location: Seattle
Contact:

Post by Dave »

Blackbeard wrote: 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
“At Gambling, the deadly sin is to mistake bad play for bad luck.” -- Ian Fleming
Blackbeard
Posts: 87
Joined: January 23rd, 2004, 9:30 pm

Post by 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
Inactive Developer
Posts: 294
Joined: March 30th, 2004, 4:45 pm
Location: Nîmes, France
Contact:

Post by Ayin »

Blackbeard wrote: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
Posts: 87
Joined: January 23rd, 2004, 9:30 pm

Post by Blackbeard »

Ayin wrote: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.
Ayin wrote: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.
Ayin wrote: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.
Ayin wrote: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
Founding Developer
Posts: 7071
Joined: August 17th, 2003, 5:07 am
Location: Seattle
Contact:

Post by 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
“At Gambling, the deadly sin is to mistake bad play for bad luck.” -- Ian Fleming
Blackbeard
Posts: 87
Joined: January 23rd, 2004, 9:30 pm

Post by Blackbeard »

Dave wrote: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.
Dave wrote: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?
User avatar
Jetrel
Art Director
Posts: 7242
Joined: February 23rd, 2004, 3:36 am
Location: Midwest US

Post by 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
Retired Developer
Posts: 1365
Joined: March 27th, 2004, 12:25 am
Location: Germany

Post by torangan »

Blackbeard wrote: 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.
Post Reply