-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi everybody!
Last weekend we had a small Wesconf at FOSDEM 2008 in Brussels.
This mail is meant as some kind of short compressive version of what we have
done at FOSDEM.The following Wesnoth Developers and Packagers were at FOSDEM in
the hackers room that we used for our discussions and work:
boucman
cycholka (aka Mist)
ettin
grzywacz
Ivanovic
Mordante (aka SkelletonCrew)
Noyga
Pietro_S
Rhonda
Dave (aka Sirp)
YogiHH
At FOSDEM itself and in the evenings we basically talked about what Wesnoth
already has achieved, what we think which direction Wesnoth will/should take in
the future and what we plan to work on in the foreseeable future, plus things in
our policy that might/should be changed. I will separate the list of topics into
the various areas of the game that we do have, it is not sorted by who took part
in the discussion and when it took place. Keep in mind that many of the plans
listed here are more of "long time plans", that is they might not be completed
for the next stable series to follow 1.4.x, but might take by far more time.
* Translations:
- - How to handle translation and grammar fixes to reduce the amount of work for
translators?
In the current version of Wesnoth many translatable strings are included. We do
often find spelling mistakes and such strings often get invalidated. To reduce
the workload of translators by setting up some automatic system to remove
unneeded fuzzy markers, boucman had the idea to introduce a pseudo translation
('Wesnothian') where we just collect all the spelling and grammar fixes. Those
will eventually be applied and the translation file will be the source of
strings with false fuzzy markers. I already said that I can easily add this
pseudo translation and already talked to Rhonda so that he can have a look at
what Debian already has in regards of tools to do most of the work
automatically. He agreed to have a look at it.
- - Scalability of the translation community
Currently it looks like we basically reached a maximum of work/size for our
translation community. There is currently no translation that is 100% complete
and it is unlikely that one will be complete in the initial 1.4 release. We
discussed what we can do to help the translation teams and to reduce their
workload. This is also related to the addition of new content, since really much
was added post 1.2. Part of the result of this discussion is, that new content
should have been possible to translate for some time already in the form that it
goes into the game (cf the huge refactoring in NR, leading to hundreds of fuzzy
strings in the first month after addition to mainline, some translations already
had it almost complete in wescamp), that is the content should be available in
wescamp for some time already (this should by now be nothing more than setting
the correct marker when uploading content to the add-on server), it should have
been checked, that all strings are already marked translatable (wmllint can do a
lot of it by now) and that the texts are already fine and do not need bigger
changes beside spelling and grammar fixes that can be included in the
"Wesnothian" translation and can be applied.
* Multiplayer
- - simple password/nickname in MP, like in IRC?
We talked about adding some simple nickname registration like it is done in IRC
with the tool named "nickserv". That means that you can basically register a
nickname/password combination for the MP server. This nickname registration is
*only* about the nickname itself, no stats are meant to be saved. This feature
is meant to allow players to be more confident in knowing who they play with,
that is the user named "abcdefghij" will, if he is registered, be the same today
like he is tomorrow, where without such a feature everybody can say that he/she
would be "abcdefghij".
- - simple rooms in MP, like in IRC
We talked about the possible addition of some room system for multiplayer, so
that players could define rooms for multiplayer campaigns, tournament games,
1vs1 only, LANGUAGE only and so on. This is also meant in conjunction with a
possible ability of some kind of "server rotation" to allow a better scalability
if we need serverpower for more users.An example of how such a rotation could be
done can be seen in IRC where many servers do form the network named
"freenode.net". This way the server could scale better even when we have many
more users simply by adding one extra server.
- - change "package format" for network traffic
Currently the mp-server has to decompress all packages, take the information it
needs for itself, and then send the stuff to the other players. By introducing
some fixed header package which includes all information the server itself
really needs, all the rest could be left compressed and thus reduce the amount
of CPU power the server needs.
- - Should we support more "experimental" multiplayer content?
We talked about adding more multiplayer content that does not focus on
competitive tournament like multiplayer, like for example the rumble add-ons and
other things like more RPG like content. In general we came to the conclusion
that this might be a good idea, even knowing that balancing for this content
will not be perfect. We also talked about the addition of other factions. Those
would not be added in the default era, since it would basically be impossible to
balance *everything* with all of them. The discussion was very controversial and
we had no clear decision if we should allow addition of new factions like the
Kalifa or not. There will have to be some further discussions, but the main
direction was that *if* we add some faction, it should play differently compared
to what we currently have and be an interesting alternative (yes, we know that
this is not much and our normal standard...).
- - Work on Multiplayer campaign support, improving it, adding features needed
to
enhance experience with it and eventually including some in mainline
Mordante volunteered to further support the work on multiplayer campaigns by
having a look at the existing bugs (and the ones that will eventually pop up).
We came to the conclusion that there are some problems left that won't be fixed
before 1.4, like for example that start of scenario saves for multiplayer
content are broken. But basically it should be working good enough so that we
can now get some real mp campaign work done and maybe integrate some into
mainline with the next development version series.
- - Multiplayer server on Windows
Since there were some reports on the multiplayer being unstable under Windows,
we tried to stresstest a server compiled and run by cycholka in the local lan.
We managed to crash the server several times. We have no sure way to definitely
crash the server. But there might be problems with heavy WML scenarios and
observers joining them. This problem requires further investigation.
* Memory consumption
- - Reducing memory consumption when using the configure option --enable-lowmem
On Saturday we worked on further reducing memory consumption when compiling with
the option --enable-lowmem. Boucman changed the animation engine, so that when
this option is set, no unit animations are used at all. So when using this
option, we can now even strip all unit images beside the unit base image from
make install. This is not done so far, but could be implemented to save
diskspace on small devices. This change saves several MB (boucman should have
the results from our test written down). Beside removing animations, the facing
of units was changed. Units now do only face in exactly one direction when
lowmem is specified at compile time.
- - config revamp with respect to memory consumption
Some configuration objects (like for example units) should be changed to allow
redcution of memory usage. Boucman, Mordante, YogiHH and Dave were talking
about what could and should be done. This will be a bigger refactoring and a lot
of work.
- - unit WML cache loaded on demand
Currently all WML of the units is loaded when the unit is required. Not all of
it will be needed always. YogiHH wants to have a look at what can be changed to
improve the behavior of the cache.
* Bigger refactoring
- - new GUI system
Mordante plans to refactor the gui system to make it easier themeable and to
reduce the maintance load. Currently the GUI section seems to be a mess which
makes adding new features like tabbed view and changes to dialogs very
difficult. Beside this the dialogs do mainly scale badly with sizes different
much from the "normal" size 1024x768. For example could the attack dialog show
all the stats about ctk, cth, ... without having to click an extra button when
the screen resolution is big enough. Something like this is not possible with
the current engine.
- - odd-on server revamp
Mordante wants to takle some changes for the add-on server to introduce the long
wanted things like "content type" and to allow running tools like wmllint on
severside or on clientside right before uploading to reduce the amount of
problems with add-ons. Many of those changes will require changes to the GUI
system so that they can be displayed in a usable way.
- - new build system
Post 1.4 esr and I will work on switching the build system from autotools to
something "better". At the moment it is not sure which build system will be
used, the basic two alternatives are scons and cmake. There was a talk at FOSDEM
about each of them, videos of these talks will be available at fosdem.org in the
foreseeable future. grzywacz and I attended the talks and our impression was
that the syntax of cmake looks a little uglier than the syntax of scons. But on
the other hand the featureset of cmake seems to be really superior. For example
it directly offers many tests and might make life for packagers easier. It could
be used to easily allow creation of lite packages without much extra work. We
will have to evaluate and testimplement so that we see which of those is better
for Wesnoth.
- - formula AI integration
Dave has been working on allowing some formulas for AIs to be coded in WML. This
is some kind of functional programming inside WML to better control the behavior
of the AI. For example it would be possible to hardcode mapspecific behavior of
the AI in the first turns for some maps. Dave also demonstrated how the current
branch already does work to the developers that were still around when FOSDEM
was almost over. So far it seems to already work nicely and can probably be
merged into trunk after 1.4 is tagged. This AI also requires some additional
dependencies from boost. This is mentioned further below.
- - savegame format revamp
Currently the savegames seem to be a rather big mess. Mordante plans to have a
look at it and reimplement some of the logics. The benefit of this would be that
savegames should look more uniform. At the moment for example start of scenario
saves in MP look different than Turn1 saves. This revamp will also be needed to
cleanly fix some replay and mp-campaign savegame problems.
- - getting stats.wesnoth.org to scale better
Currently stats.wesnoth.org is basically unusable since the svg graphics want to
display every single entry. With several hundred values rendering the images
takes too long so that a timeout on the pages is the result. The data from
stats.wesnoth.org is very valuable for balancing content so we should try to
find a way to create better graphs that maybe not try to show every value but do
some calculations for how we show things. Maybe there are already some nice
libraries available which can do the work for us.
* Smaller Refactoring
- - layering in display code
Mordante wants to work on allowing layering in display code. This should allow
missiles in animations to be drawed on top and items to be drawed below.
- - fire and forget for animations
Boucman wants to implement a way to really have "fure and forget" animations.
- - addition of boost foreach and boost smart_ptr
Dave needs those two dependencies for formula ai and they do make sense to
support c++ coders in their work. The plain header files should be enough to
have it work, so it is not much of a new dependency.
- - prevent UMC namespace collision
Currently it is possible that namespaces of UMC collide. This should be
prevented since it can lead to strange bugs. A nice and good way to do so has to
be found.
- - testing if binary wml is faster than text wml and compare speed with gzip
wml
We talked about the speed benefits binary WML might have compared to normal text
WML and to gzipped WML. At the end of FOSDEM Dave started to implement some
testcases to somehow benchmark the various kinds of ways we can use WML. He
suspects that binary WML might be a whole lot faster for processing and thud
should be used more often.
- - release of 1.3.19 aka 1.4-rc2
On Sunday afternoon I released as planned before.
* Policy and standards
- - updates to coding standards (in the wiki)
The wikipage about coding standards was updated at FOSDEM. Have a look at it to
see the changes. A new coding standard still has to be introduced: remove
implicit conversions of t_strings.
- --- important ---
- - more content in, more content out
We discussed what we can do in regards of content additions. We came to the
conclusion that we should keep with making it rather easy to add content, but
that we should also add a general policy to easily allow removal of content.
Currently we in theory do have this already, but with a better defined policy it
might be easier to handle. Here is what conclusion we had at the end:
* Before content is added it has to meet some requirements to make life easier
for translators (cf "- Scalability of the translation community"). This means
that the content should be available for translators for at least one or two
months via wescamp, so that they can already work on the stuff if they have the
time to do so.
* Content that is added should be evaluated after some time (that is after two
or three releases with the add-on in it, we should decide if we want to keep
it). The reason for this is that translators should know as early as possible if
they should spend their time on it or not (removal)
* If content is in after this time, it is enough if a developer says "I don't
think this content works nicely and should stay in" to have a new evaluation
among us devs.
- - money/ads/hosting discussions
We talked about the possibility of adding ads to wesnoth.org. A possibility
would be to only show the ads to windows users, like we have done for a short
time with the "get firefox"-banner. The reason to have those ads would be to
found a dedicated root server that we do have full access to. Boucman said that
there was some offer in France for rather string 2GHz machines with many GB
harddrive and unlimited bandwidth usage. On such a server we could host the
website including forum and wiki, a mailserver to allow @wesnoth.org email
addys/aliases for devs, the multiplayer and content-servers. Currently there
seem to be some problems with the confirmation mails at the forum registration.
In the last year every now and then we had some problems with the servers, so it
might be a valid idea to change to a server we have full control about. Beside
this the money can be used to eventually found a real Wesconf, where every
developer could get some support for their expends to get there. We could/should
also ask more prominently for donations to be able to found a Wesconf.
To really allow this we should have a look at what is needed in the various
countries to start a non-profit foundation. This would probably allow us not to
be forced to pay too many taxes, as we would normally have to do with ads.
Overall FOSDEM was really great to discuss things. We were able to talk about
many topics, though we have not implemented too much, since it was better to use
this chance for discussing concepts and ideas. If I have forgotten anything in
this list, please post it. If I made any big errors, please correct me.
Of course this is also meant as a base for further discussions, especially with
those who were not able to attend FOSDEM. So feel free to start discussing about
single of the items. Probably it will be better if you discussed the stuff with
new topics for each, since otherwise it will be really difficult to follow what
was the "we had this at FOSDEM" and "following in depth discussions".
What still is to be done, is putting our decisions into the Wiki.
Cheers,
Nils Kneuper aka Ivanovic
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHwv3KfFda9thizwURAso6AJwLap3lFdu2XMFi1CVbQyYJfHZE0gCfeNxl
Iy2t70iegXqJf1iP8s+2sF8=
=cDqg
-----END PGP SIGNATURE-----
_______________________________________________
Wesnoth-dev mailing list
Wesnoth-dev@gna.org
https://mail.gna.org/listinfo/wesnoth-dev
