Wesnoth Philosophy II: Where Next?
Moderator: Forum Moderators
- Viliam
- Translator
- Posts: 1341
- Joined: January 30th, 2004, 11:07 am
- Location: Bratislava, Slovakia
- Contact:
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).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?
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).
- Elvish_Pillager
- Posts: 8137
- Joined: May 28th, 2004, 10:21 am
- Location: Everywhere you think, nowhere you can possibly imagine.
- Contact:
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.Viliam wrote: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).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?
-
- Posts: 87
- Joined: January 23rd, 2004, 9:30 pm
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.
Do you think its worth porting Wesnoth to a framework at some point?
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 like to use gettext, too, so I'd like to hear from Ayin.Dave wrote:I would like for gettext to get in, however I refuse to make it a required condition.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.
...
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
Do you think its worth porting Wesnoth to a framework at some point?
How about displaying some nice picture and text (like at the beginning of the campaign) ?Dave wrote: We'd just change the string in the translation file to say something more sensible once campaigns are actually complete.
Milan Babuskov
http://home.gna.org/vodovod
http://home.gna.org/vodovod
Sure, that's what I meant when I mentioned the possibility of displaying a 'dummy scenario' with a storyline sequence only.mbabuskov wrote:How about displaying some nice picture and text (like at the beginning of the campaign) ?Dave wrote: We'd just change the string in the translation file to say something more sensible once campaigns are actually complete.
David
“At Gambling, the deadly sin is to mistake bad play for bad luck.” -- Ian Fleming
-
- Posts: 87
- Joined: January 23rd, 2004, 9:30 pm
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.
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.
-
- Inactive Developer
- Posts: 294
- Joined: March 30th, 2004, 4:45 pm
- Location: Nîmes, France
- Contact:
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 ; ) )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.
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.
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).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.
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?
Here, you hear from me :)I'd like to use gettext, too, so I'd like to hear from Ayin.
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)
Same opinion that Dave on that. If the framework:Do you think its worth porting Wesnoth to a framework at some point?
* Is of good quality
* Provides some significant advantages to Wesnoth
then we'll consider porting the game with interest ; )
-
- Posts: 87
- Joined: January 23rd, 2004, 9:30 pm
1- Unified language.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 ; ) )
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.
Exactly, STL typdefs are all over the place, not centralised and coherrent.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.
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 );
};
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.
Yes! It is a stand-alone library, but can be statically linked to produce a single app binary.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?
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,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)
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
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.
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
David
“At Gambling, the deadly sin is to mistake bad play for bad luck.” -- Ian Fleming
-
- Posts: 87
- Joined: January 23rd, 2004, 9:30 pm
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 personally think the standard C++ containers are generally very well designed.
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?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.
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.
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.
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...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?
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.