https://wiki.wesnoth.org/api.php?action=feedcontributions&feedformat=atom&user=GrzywaczThe Battle for Wesnoth Wiki - User contributions [en]2026-04-10T23:52:38ZUser contributionsMediaWiki 1.31.16https://wiki.wesnoth.org/index.php?title=Fosdem2010&diff=33254Fosdem20102009-12-03T22:35:14Z<p>Grzywacz: /* Schedule/Plans */</p>
<hr />
<div>== General information ==<br />
This page is meant to somehow coordinate the small Wesconf taking place at FOSDEM 2009. That is everyone attending should please list him/herself in the list of arrivals and stuff like this. FOSDEM 2010 will take place at the first weekend in Febuary 2009, on Saturday 6th and Sunday 7th.<br />
<br />
* Fosdem - http://fosdem.org/2010/<br />
* [http://www.wesnoth.org/forum/viewtopic.php?p=283311#283311 List with phone numbers] (forum moderators only)<br />
<br />
== Schedule/Plans ==<br />
{| border="1" width="100%"<br />
|-<br />
! (nick)name(s)<br />
! Arrival<br />
! Departure<br />
! Accomodation<br />
|-<br />
| Ivanovic<br />
| Fri, 5th<br />
| Sun, 7th<br />
| unknown<br />
|-<br />
| Crab<br />
| Fri, 5th<br />
| unknown<br />
| unknown<br />
|-<br />
| grzywacz<br />
| Fri, 5th (?)<br />
| Mon, 8th (?)<br />
| unknown<br />
|-<br />
| <br />
| <br />
| <br />
| <br />
|-<br />
| <br />
| <br />
| <br />
| <br />
|-<br />
| <br />
| <br />
| <br />
| <br />
|-<br />
| <br />
| <br />
| <br />
| <br />
|-<br />
| <br />
| <br />
| <br />
| <br />
|-<br />
|}<br />
<br />
For accomodations please keep in mind that parking in the center of Brussels is really problematic. It might make sense to drive to the University where FOSDEM takes place, park there and take the bus into the town center (where some of the hotels/hostels are).<br />
<br />
Possible hostels that we at least contacted over the last years (some of them might already be booked out by now!):<br />
* [http://www.chab.be/ CHAB]<br />
* [http://www.2go4.be/ 2go4] Note: groups bigger 6 are not allowed, so we can (officially) not form a complete Wesnoth group at this hostel, got to meet somewhere in town/at the university...<br />
* [http://www.jeugdherbergen.be/brusselE.htm Bruegel YH]<br />
<br />
On the official FOSDEM page [http://fosdem.org/2010/practical/accomodation some more possible hotels/hostels] are listed.<br />
<br />
== Maps ==<br />
* [http://tinyurl.com/3a65gr Bruegel YH]<br />
* [http://tinyurl.com/35br9c Brussels Central (Train Station) → Bruegel YH]<br />
* [http://tinyurl.com/37d9v4 Bruegel YH → Brussels Central (Train Station) → Novotel Grand Place]<br />
* [http://tinyurl.com/2mzns6 Novotel Grand Place]<br />
* [http://tinyurl.com/3dggg3 CrownePlaza (Europa)]<br />
* [http://tinyurl.com/36epxj FOSDEM]<br />
* [http://tinyurl.com/2w4bms Novotel Grand Place -> FOSDEM]<br />
<br />
== Transportation ==<br />
Information about how to reach the FOSDEM is listed at the [http://fosdem.org/2010/practical/transportation official transportation subpage].<br />
<br />
Short version of how to get there for those that reside in Bruegel YH and Novotel Grand Place (basically town center):<br />
<br />
* Enter Bus 71 (Debrouckere - Central Station ("Gare Centrale") - Delta) somewhere at 'Central Station'<br />
* Leave the bus at "ULB" (crossroads Ave. Adolphe Buyl - Sq. Deveze)<br />
* Walk down Ave. Paul Heger on your right hand.<br />
<br />
== Wesnoth Hacking Room ==<br />
<br />
Wesnoth will not have a room of its own. Instead we will use one of the "general hacking rooms". So far it is not sure which room it will be, if we do it like the last two years, it will be room number 115 in the building AW1. Last year this was the smaller of the two hacking rooms and we had no real problem with conquering (and holding) the first row in this room. There were not too many power outlets, so this year at least Ivanovic will bring one multi-outlet power strip plus some extension cable (5m or something like this). There is no wired network, everything wireless (and sometimes rather/very unstable!). Beside this you should bring laptops since there are no computers available for hacking.<br />
<br />
Short version:<br />
AW1 - Room 115<br />
<br />
== Planned discussion ==<br />
We usually discuss all sorts of things at FOSDEM, this section is here to have a small bullet list of things that we actively want to discuss at FOSDEM.<br />
* GSOC 2010: finding mentors, organizing the submission etc..<br />
* FOSDEM 2011 : trying to get a dev room with other games ?<br />
* [wanted: discussion topics!]<br />
<br />
== FOSDEM 2009 ==<br />
We were already at FOSDEM 2009, here something as reference:<br />
<br />
* [http://www.wesnoth.org/wiki/Fosdem2009 FOSDEM 2009 wiki page]<br />
<br />
== FOSDEM 2008 ==<br />
We were already at FOSDEM 2008, here something as reference:<br />
<br />
* [http://www.wesnoth.org/forum/viewtopic.php?p=283649#p283649 Forum topic (with group photo)]<br />
* [http://www.wesnoth.org/wiki/Fosdem2008 2008 wiki page]<br />
* [https://mail.gna.org/public/wesnoth-dev/2008-02/msg00078.html Summary of FOSDEM 2008 results]<br />
<br />
<br />
[[Category:Development]]<br />
[[Category:Wesconf]]</div>Grzywaczhttps://wiki.wesnoth.org/index.php?title=User:Grzywacz&diff=28895User:Grzywacz2009-03-21T00:23:43Z<p>Grzywacz: </p>
<hr />
<div>Why hello there! This site describes my involvement in the "Battle for Wesnoth" developement so far.<br />
<br />
<br />
== Translation & internationalisation ==<br />
<br />
I was maintaining the Polish translation of "Battle for Wesnoth" for more than 1.5 year, starting spring 2005. In that time, with enormous help of a few people (mentioned in credits), we managed to complete the translation of all the mainline strings for 1.0.2 and 1.2 releases. We've started with basically nothing (barely ~5% completed at the beginning makes me wonder why previous translators even appear in the credits).<br />
<br />
== Developement ==<br />
<br />
I've started my developement with a few patches, mainly bugfixes. Later on, 2 medium-size projects have begun to evolve:<br />
<br />
=== GP2X port ===<br />
<br />
A port of BfW to Gamepark Holding's GP2X handheld console. The project is currently stalled due to lack of interest on my part and broken hardware... The game basically runs, but there still a few problems to solve.<br />
<br />
What's been accomplished involves: <br />
* fixes to the unmaintained tinygui interface, to make the game playable in 320x240 resolution; <br />
* one-time caching without revalidation to greatly improve startup times<br />
* sound-cache limiting to save on memory<br />
* joystick mouse support, to move mouse cursor using GP2X's stick<br />
* fixed image resize script, used to downscale BfW graphics on install (saves memory and cpu cycles)<br />
<br />
What's left:<br />
* memory usage problems which make the game unplayable; <br />
GP2X has only 32 megs of OS-available RAM, about 24MB more can be accessed with paeryn's hardware SDL lib<br />
* drawing speed - using doublebuffering and hardware blitter don't go well with Wesnoth's display model; <br />
maybe the OpenGL branch is a better base for this port?!<br />
* second CPU core usage - GP2X is based on a MMSP2 SoC, which has two ARM cores available; <br />
possibly off-load music decoding or some AI routines to the 940 core?<br />
<br />
=== Sound sources support ===<br />
<br />
"Sound sources" is a general name for a mechanism, which makes it possible for map elements to emit sounds according to some rules, where "map elements" can be specific locations or terrain patches. One has complete control over them with the WML. <br />
<br />
<tt>[sound_source]</tt> - creates a sound source<br />
<br />
''Available parameters:''<br />
<br />
<tt>sounds=list,of,comma,seperated,sounds</tt> - list of sounds associated with this source, played randomly<br />
<br />
<tt>id=string</tt> - internal id used to manipulate this source<br />
<br />
<tt>delay=numerical value</tt> - mininal delay (in ms) between two playbacks of source's sound if the source remains visible on the screen; if one scrolls out and back in, the source will be considered as ready to play<br />
<br />
<tt>chance=numerical value</tt> - a number from [0, 100] range, describing what's the chance of source being <br />
activated every second after the ''delay'' has passed or when the source's location appears on the screen (note that it cannot play more than one file at the same time anyway)<br />
<br />
<tt>check_fogged=boolean value</tt> = true or false; if true the source won't play if its location is fogged/shrouded<br />
<br />
<tt>x=list,of,numerical,values</tt> a list of x coordinates associated with this sound source (must match y list)<br />
<br />
<tt>y=list,of,numerical,values</tt> a list of y coordinates associated with this sound source (must match x list)<br />
<br />
<br />
<tt>[remove_sound_source]</tt> - removes a sound source<br />
<br />
''Available parameters:'' <br />
<br />
<tt>id=string</tt> - id of the sound source to be removed<br />
<br />
<br />
The current state of the volume calculation algorithm looks like:<br />
<br />
:http://kolos.math.uni.lodz.pl/~grzywacz/current.png</div>Grzywaczhttps://wiki.wesnoth.org/index.php?title=User:Grzywacz&diff=28894User:Grzywacz2009-03-21T00:19:34Z<p>Grzywacz: /* Tags implemented in trunk (for testing purposes only): */</p>
<hr />
<div>Why hello there! This site describes my involvement in the "Battle for Wesnoth" developement so far.<br />
<br />
<br />
== Translation & internationalisation ==<br />
<br />
I was maintaining the Polish translation of "Battle for Wesnoth" for more than 1.5 year, starting spring 2005. In that time, with enormous help of a few people (mentioned in credits), we managed to complete the translation of all the mainline strings for 1.0.2 and 1.2 releases. We've started with basically nothing (barely ~5% completed at the beginning makes me wonder why previous translators even appear in the credits).<br />
<br />
== Developement ==<br />
<br />
I've started my developement with a few patches, mainly bugfixes. Later on, 2 medium-size projects have begun to evolve:<br />
<br />
=== GP2X port ===<br />
<br />
A port of BfW to Gamepark Holding's GP2X handheld console. The project is currently stalled due to lack of interest on my part and broken hardware... The game basically runs, but there still a few problems to solve.<br />
<br />
What's been accomplished involves: <br />
* fixes to the unmaintained tinygui interface, to make the game playable in 320x240 resolution; <br />
* one-time caching without revalidation to greatly improve startup times<br />
* sound-cache limiting to save on memory<br />
* joystick mouse support, to move mouse cursor using GP2X's stick<br />
* fixed image resize script, used to downscale BfW graphics on install (saves memory and cpu cycles)<br />
<br />
What's left:<br />
* memory usage problems which make the game unplayable; <br />
GP2X has only 32 megs of OS-available RAM, about 24MB more can be accessed with paeryn's hardware SDL lib<br />
* drawing speed - using doublebuffering and hardware blitter don't go well with Wesnoth's display model; <br />
maybe the OpenGL branch is a better base for this port?!<br />
* second CPU core usage - GP2X is based on a MMSP2 SoC, which has two ARM cores available; <br />
possibly off-load music decoding or some AI routines to the 940 core?<br />
<br />
=== Sound sources support ===<br />
<br />
My pet-project waiting for some free time. 8)<br />
<br />
"Sound sources" is a general name for a mechanism, which makes it possible for map elements to emit sounds according to some rules, where "map elements" can be specific locations or terrain patches. One has complete control over them with the WML. <br />
<br />
<tt>[sound_source]</tt> - creates a sound source<br />
<br />
''Available parameters:''<br />
<br />
<tt>sounds=list,of,comma,seperated,sounds</tt> - list of sounds associated with this source, played randomly<br />
<br />
<tt>id=string</tt> - internal id used to manipulate this source<br />
<br />
<tt>delay=numerical value</tt> - mininal delay (in ms) between two playbacks of source's sound if the source remains visible on the screen; if one scrolls out and back in, the source will be considered as ready to play<br />
<br />
<tt>chance=numerical value</tt> - a number from [0, 100] range, describing what's the chance of source being <br />
activated every second after the ''delay'' has passed or when the source's location appears on the screen (note that it cannot play more than one file at the same time anyway)<br />
<br />
<tt>check_fogged=boolean value</tt> = true or false; if true the source won't play if its location is fogged/shrouded<br />
<br />
<tt>x=list,of,numerical,values</tt> a list of x coordinates associated with this sound source (must match y list)<br />
<br />
<tt>y=list,of,numerical,values</tt> a list of y coordinates associated with this sound source (must match x list)<br />
<br />
<br />
<tt>[remove_sound_source]</tt> - removes a sound source<br />
<br />
''Available parameters:'' <br />
<br />
<tt>id=string</tt> - id of the sound source to be removed</div>Grzywaczhttps://wiki.wesnoth.org/index.php?title=SoC_People_to_bug_on_IRC&diff=28848SoC People to bug on IRC2009-03-19T19:29:58Z<p>Grzywacz: /* Karol Nowak (grzywacz) */</p>
<hr />
<div>== People to bug on IRC ==<br />
We have prepared a list of people with their "area of competence". This is to give you an idea on which areas those people can be of help for you. Of course you should always just ask in the IRC chan, but those are the most likely ones to answer questions in the respective area. And here is the list:<br />
<br />
=== boucman ===<br />
As our "patch monkey" he accustomed to critiquing patches of every kind. Beside this, he knows many areas of the game due to working on applying patches. He is particularly used to answering question from new coders, and doesn't mind explaining trivial stuff. He was the one who started the "two patches, you're in" policy and the ReferenceWML part of the project.<br />
<br />
=== Daniel Franke (dfranke) ===<br />
Daniel is the devteam's most recent addition, and has been primarily concerned with security auditing. Bug him <i>privately</i> if you think you've found a security issue.<br />
<br />
=== Dave alias Sirp ===<br />
Sirp started Wesnoth and is our lead developer. He is currently our C++ expert and is also the one that is working on the new Formula AI. Any questions regarding the formula AI should be directed to him.<br />
<br />
=== Elias Pscherning (elias) ===<br />
He wrote the original version of campgen and as such will know a lot about what is needed to to make such an editor work correctly. The work on a scenario editor might be based upon campgen and as such his knowledge will be really helpful.<br />
<br />
=== Eric S. Raymond (ESR) ===<br />
ESR is our project toolsmith; he has written several tools that semi-automate various aspects of WML maintenance. While most of our developers/designers concentrate on either the C++ core or WML but not both, he has a balanced understanding of both levels and may be helpful in helping students develop a grasp of the overall architecture. Finally, he did the last overhaul of the Wesnoth UI and understands UI design principles; he is well-equipped to guide students working in that area.<br />
<br />
=== ilor ===<br />
2008 GSoC student, worked on and maintains the new map editor in Wesnoth 1.5/1.6. Has some fairly recent experience with getting "in" the Wesnoth codebase.<br />
<br />
=== Karol Nowak (grzywacz) ===<br />
Two years he participated at GSoC as a student, so he will understand the situation of GSoC students. Beside this he is our top expert on Wesnoth for embedded devices as he worked on the gp2x support.<br />
<br />
=== Mordante ===<br />
Many of the possible projects involve the code for which he is an area expert. Also, many of the possible projects currently listed on the ideas page require GUI parts to work. Mordante is currently busy rewriting the old gui engine, he will be our expert there as well as already being our area expert for the terrain engine.<br />
<br />
=== Nils Kneuper (Ivanovic) ===<br />
He is doing nothing special, he just does some "administrative work" like packaging fresh tarballs when it is time for them and works on setting up any kind of deadlines and timetables related to releasing. He has administrative powers in most areas, no matter if website, forum or IRC. Beside this he uploads translation updates, tries to communicate with the translation teams when it is required and translates a little bit himself every now and then. But in general he is not a real expert in anything, just has a look at things that come up and redirects people to the correct contacts.<br />
<br />
=== Noy ===<br />
Noy is an oddity among developers; he's got no coding skills whatsoever and possesses a limited understanding of computers, which is illustrated by his difficulty operating a Mac. Instead, Noy makes his contribution in gameplay and multiplayer design, drawing upon his background in social sciences research, military strategy and playing games online, to understand the effects of development on the playing community behavior. Along with Soliton, Noy is a useful conduit to discuss any issues in this area; just don't ask him about revising the level of randomness in the game.<br />
<br />
=== Noyga ===<br />
Another versatile developer, on the C++ side he doesn't concentrate on a particular area, did some tweaks to improve translations in some languages (like enabling the female forms for names in various place) but know quite well the C++ side of units, abilities and WML. On the WML side he's an expert.<br />
<br />
=== Sapient ===<br />
This developer started working on the GUI and widgets, but recently he focused more on improving the internal mechanics of the WML engine such as variable look-ups and filtering. Sapient is not very active anymore but he does come one IRC in the evenings (U.S.A.). He has touched-up many areas of the code in small ways over time, thus he has a good general knowledge of the C++ code and also has worked a little on some python maintenance scripts. He keeps an eye on the quality of incoming C++... especially if you plan on making any changes to GUI or WML, Sapient will be reviewing it closely and with a critical eye.<br />
<br />
=== Shadow Master/ShikadiLord ===<br />
He joined the development team very recently, but has enough knowledge to help newcomers with trivial questions about the code and/or the C++ language. His primary focuses are the various WML handlers, such as game events code. His knowledge of the WML language itself is also enough to answer most questions and solve most problems, but only if they are not related to multiplayer games. He also has some basic knowledge of the autotools machinery we use to configure Wesnoth for foreign computers.<br />
<br />
=== Soliton ===<br />
He knows our MP server setup best. Beside this he has already done a lot of work on the MP server himself. So he probably has most knowledge about it and, being one of our MP-developers, might provide important help from the perspective of the MP player community and what is needed there.<br />
<br />
=== YogiHH or Piotr Cychowski (cycholka) ===<br />
Since they are the two developers who know most about building under Windows, they will probably be really helpful. Either if the student comes from the Windows side, or to help test resulting work to make sure that it does work on Windows and, for the case that it does not, to show them where problems are.<br />
<br />
=== zookeeper or Mythological or Rhuvaen ===<br />
As our leading WML experts those are to be contacted when it comes to anything related WML problems since they know this stuff best. They do maintain most of the campaigns and improve them whenever they have a good idea for changes.<br />
<br />
=== See also ===<br />
[[SummerOfCodeIdeas|Summer of Code Ideas]] - The root where all information regarding SoC is (or better should be) linked from.<br />
<br />
[[Category:Summer of Code]]</div>Grzywaczhttps://wiki.wesnoth.org/index.php?title=InterfaceActionsWML&diff=23689InterfaceActionsWML2008-03-16T14:00:05Z<p>Grzywacz: Documented fade_range= attribute of [sound_source]</p>
<hr />
<div>{{WML Tags}}<br />
== Interface actions ==<br />
<br />
Interface actions are actions that do not have an effect on gameplay;<br />
instead, they show something to the player. The main interface tags<br />
are '''[message]''' and '''[objectives]''', but several other tags affect<br />
the interface also.<br />
<br />
== [message] ==<br />
The most commonly used interface action is [message], which displays a message to the user in a dialog box. It can also be used to take input from the user.<br />
<br />
The following key/tags are accepted for [message]:<br />
* [[StandardUnitFilter]]: the unit whose profile and name are displayed. If no unit matching this filter is found, the message is not displayed (The unit has probably been killed).<br>'''[message]''' elements should be constructed so that it is either guaranteed that a certain unit is alive, or so that dialog flows smoothly even if the message isn't displayed.<br />
<br />
* '''speaker''': an alternative to standard unit filter. You may specify as the value of the speaker attribute a unit description or any of the following special values:<br />
** '''narrator''': the dialog box is displayed without a caption for the unit speaking or a unit image<br />
** '''unit''': the primary unit for the event is speaking<br />
** '''second_unit''': the secondary unit for the event is speaking<br />
<br />
* '''message''': (translatable) the text to display to the right of the image. ''message'' is sometimes multiple lines; if it is, be sure to use quotes(''' ' ''' or ''' " ''')<br />
* '''side_for''': (default: all sides) comma-separated list of sides for who message is shown.<br />
* '''image''': (default: profile image of speaker) the image to display next to the message.<br />
* '''caption''': (default: name of speaker) the caption to display beside the image. Name to be displayed.<br />
* '''duration''': (default: 10) the minimum number of frames for this message to be displayed. (A frame lasts about 30 milliseconds.) During this time any dialog decisions will be disregarded.<br />
* '''sound''': a sound effect (wav file) to play as the message is displayed. This can be a comma-separated list, from which one will be randomly chosen.<br />
* '''[option]''': zero or more '''[option]''' elements may be present. If '''[option]''' elements are present, then each option will be displayed in a menu for the user to select one option.<br />
** ''message'' (translatable) the text displayed for the option (see [[DescriptionWML]])<br />
** '''[show_if]''': if present then this option will only be displayed if the conditional statement in this tag is passed (see [[InternalActionsWML]])<br />
** '''[command]''': an element containing actions which are executed if the option is selected.<br />
* '''[text_input]''': there can be only one [text_input] tag. this adds a text input field to the message.<br />
** '''variable''': the variable that the user's input will be written to<br />
** '''label''': a text label to the left of the input field<br />
** '''max_chars''': the maximum number of characters that may be typed into the field<br />
** '''text''': text that is written into the field in the beginning<br />
* note that '''[option]''' and '''[text_input]''' can only be used in moveto events in MP, otherwise they cause OOS<br />
<br />
Text formatting options for '''[message]'''. These can also be used in unit names (user_description), objectives, and such.<br />
* A tilde (~) as the first character causes the line to be boldfaced.<br />
* An at symbol (@) as the first character causes the line to be green, as done with victory conditions.<br />
* A pound symbol (#) as the first character causes the line to be red, as done with defeat conditions.<br />
* An asterisk (*) as the first character causes the line to be bigger.<br />
* A backquote (`) as the first character causes the line to be smaller.<br />
* If used, the caption key text is boldfaced.<br />
* An RGB colour code in the beginning causes the line to be the given colour. This can still be preceded by the above characters. Example: ''message=_"<255,0,0>Red!"''<br />
<br />
== [objectives] ==<br />
The other tag used for plot development is '''[objectives]'''.<br />
The '''[objectives]''' tag overwrites any previously set objectives,<br />
and displays text which should describe the objectives of the scenario.<br />
Scenario objectives are displayed on the player's first turn after the tag is used,<br />
or as part of the event if it triggers during that player's turn.<br />
Objectives can also be accessed at any time in a scenario using the<br />
"Scenario Objectives" game menu option, making this tag useful for<br />
scenario-specific information that the player may need to refer to during play.<br />
<br />
This tag renders the ''objectives'' attribute of [scenario] obsolete (see ''objectives'', [[ScenarioWML]]).<br />
Instead of using ''objectives'', use '''[objectives]''' to set scenario objectives inside a prestart event.<br />
It can also be used to overwrite the starting objectives mid-scenario.<br />
<br />
Attributes of '''[objectives]''':<br />
* '''side''': Default '0'. The side to set the objectives for. A value of 0 sets objectives for all sides.<br />
* '''summary''': Displayed first in the objectives text, this should describe the basic objective for the overall scenario. Can be omitted.<br />
* '''note''': Displayed last in the objectives text, this is sometimes used for hints or additional information. Can be omitted.<br />
* '''victory_string''': Default ' _ "Victory:"', this text precedes the victory objectives.<br />
* '''defeat_string''': Default ' _ "Defeat:"', this text precedes the defeat objectives.<br />
* '''silent''': Default: not present. If set to "yes", the objectives are silently changed. Else, they will be shown to the user when appropriate.<br />
<br />
Tags of '''[objectives]''':<br />
* '''[objective]''': describes a win or loss condition. Most scenarios have multiple win or loss conditions, so use a separate [objective] subtag for each line; this helps with translations.<br />
** '''description''': text for the specific win or loss condition.<br />
** '''condition''': The color and placement of the text. Values are 'win'(colored green, placed after ''victory_string'') and 'lose'(colored red, placed after ''defeat_string'')<br />
<br />
=== Macros ===<br />
There are a few predefined macros for Objectives that you can use to shorten the code. '''{SET_OBJECTIVES}''', '''{VICTORY_CONDITION}''' and '''{DEFEAT_CONDITION}'''. There are all used together. For more information look [http://www.wesnoth.org/misc/macro-reference.xhtml here]<br />
<br />
== [set_menu_item] ==<br />
This tag is used to add a custom option in the right-click context menu which can then be used to trigger arbitrary WML commands.<br />
<br />
* '''id''': the unique id for this menu item. If a menu item with this id already exists, it allows you to set specific changes to that item.<br />
* '''description''': the in-game text that will appear for this item in the menu.<br />
* '''image''': the image to display next to this item.<br />
* '''needs_select''': if ''yes'' (default ''no''), then the latest select event (see [[EventWML]]) that triggered before this menu item was chosen will be transmitted over the network before this menu item action will be. This only has any effect in networked multiplayer, and is intended to allow more elaborate menu item behaviour there without causing out of sync errors. If you don't know what this means, just leave it false.<br />
* '''[show_if]''': If present, the menu item will only be available if the conditional statement (see [[InternalActionsWML]]) within evaluates to true. When this is evaluated, the WML variables ''$x1'' and ''$y1'' will point to the location on which the context menu was invoked, so it's possible to for example only enable the option on empty hexes or on a particular unit.<br />
* '''[filter_location]''': contains a location filter similar to the one found inside Single Unit Filters (see [[FilterWML]]). The menu item will only be available on matching locations.<br />
* '''[command]''': contains the WML actions to be executed when the menu item is selected. Again, the WML variables ''$x1'' and ''$y1'' will point to the location on which the context menu was invoked on.<br />
<br />
== Other interface tags ==<br />
<br />
The following tags are also action tags:<br />
* '''[item]''': makes a graphical item appear on a certain hex. Note this only places the graphics for an item. It does not make the item do anything. Use a moveto event to make moving onto the item do something. <tt>''('''Hint:''' There are a number of predefined items that are used in various campaigns that you can make use of. You can find a list of them if you look into the items.cfg file in the wesnoth install directory (under /data/core/macros))''</tt><br />
** '''x''', '''y''': the location to place the item.<br />
** '''image''': the image (in ''images/'' as .png) to place on the hex.<br />
** '''halo''': an image to place centered on the hex. Use this instead of ''image'' if the image is bigger than the hex.<br />
* '''[removeitem]''': removes any graphical items on a given hex<br />
** '''x''', '''y''': the hex to remove items off<br />
* '''[print]''': displays a message across the screen. The message will disappear after a certain time.<br />
** '''text''': (translatable) the text to display.<br />
** '''size''': (default=12) the pointsize of the font to use<br />
** '''duration''': (default=50) the length of time to display the text for. This is measured in the number of 'frames'. A frame in Wesnoth is usually displayed for around 30ms.<br />
** '''red''', '''green''', '''blue''': (default=0,0,0) the color to display the text in. Values vary from 0-255.<br />
* '''[move_unit_fake]''': moves an image of a unit along a certain path on the map. The path does not need to be a continuous list of adjacent hexes, so for example only the start and end points can be given, in which case the straightest line between those points will be calculated and used.<br />
** '''type''': the type of the unit whose image to use<br />
** '''x''': a comma-separated list of x locations to move along<br />
** '''y''': a comma-separated list of y locations to move along (x and y values are matched pairs)<br />
** '''side''': the side of the fake unit, used for team-coloring the fake unit<br />
* '''[hide_unit]''': makes the given unit become invisible. Useful in conjunction with '''[move_unit_fake]''': to move a leader unit into position on-screen. Only one unit may be hidden at a time.<br />
** '''x''', '''y''': location of the unit to be hidden. (NOT a standard unit filter! Just x and y.)<br />
* '''[unhide_unit]''': stops the currently hidden unit from being hidden.<br />
* '''[scroll]''': Scroll a certain number of pixels in a given direction. Useful for earthquake/shaking effects.<br />
** '''x''', '''y''': the number of pixels to scroll along the x and y axis<br />
* '''[scroll_to]''': Scroll to a given hex<br />
** '''x''', '''y''': the hex to scroll to<br />
** '''check_fogged''': whether to scroll even to locations covered in fog or shroud. Possible values ''true'' (don't scroll to fog) and ''false'' (scroll even to fog), with ''false'' as the default.<br />
* '''[scroll_to_unit]''' Scroll to a given unit<br />
** [[StandardUnitFilter]]<br />
** '''check_fogged''': whether to scroll even to locations covered in fog or shroud. Possible values ''true'' (don't scroll to fog) and ''false'' (scroll even to fog), with ''false'' as the default.<br />
* '''[sound]''': Plays a sound<br />
** '''name''': the filename of the sound to play (in ''sounds/'' as .wav or .ogg)<br />
** '''repeat''': repeats the sound for a specified additional number of times (default=0)<br />
* '''[sound_source]''': Creates a sound source. "Sound sources" is a general name for a mechanism which makes possible for map elements to emit sounds according to some rules, where "map elements" can be specific locations or terrain types. For now, only sound sources tied to locations are supported.<br />
** '''id''': a unique identification key of the sound source<br />
** '''sounds''': a list of comma separated, randomly played sounds associated with the sound source<br />
** '''delay''': a numerical value (in milliseconds) of the minimal delay between two playbacks of the source's sound if the source remains visible on the screen; if one scrolls out and back in, the source will be considered as ready to play<br />
** '''chance''': a percentage (a value from 0 to 100) describing the chance of the source being activated every second after the delay has passed or when the source's location appears on the screen (note that it cannot play more than one file at the same time)<br />
** '''check_fogged''': possible values "true" and "false" - if true the source will not play if its locations are fogged/shrouded<br />
** '''loop''': number of times a sound sample should be looped if it stays visible. -1 means infinite (~65000) {{DevFeature}}<br />
** '''full_range''': distance in hexes that determines a "circular" area where source plays with full volume, relative to screen center {{DevFeature}}<br />
** '''fade_range''': distance in hexes that determines a "circular" area around the one specified by '''full_range''' where sound volume fades out linearly; by default equals to '''full_range''' {{DevFeature}}<br />
** '''x,y''': a [[StandardLocationFilter]] for the locations associated with the sound source<br />
* '''[remove_sound_source]''': Removes a previously defined sound source.<br />
** '''id''': the identification key of the sound source to remove<br />
* '''[music]''': Switches to playing different music<br />
** '''name''': the filename of the music to play (in ''music/'' as .ogg)<br />
** see [[MusicListWML]] for the correct syntax<br />
* '''[colour_adjust]''': tints the colour of the screen.<br />
** '''red''', '''green''', '''blue''': values from -255 to 255, the amount to tint by for each colour<br />
* '''[delay]''': pauses the game<br />
** '''time''': the time to pause in milliseconds<br />
* '''[redraw]''': redraws the screen (this normally isn't done during events, although some of the other interface actions cause the screen or parts of it to be redrawn).<br />
** '''side''': if used, recalculates fog and shroud for that side. Useful if you for example spawn friendly units in the middle of an event and want the shroud to update accordingly (otherwise units that spawn inside fog would remain invisible for the duration of the event, since the fog would not automatically get cleared around them).<br />
* '''[unit_overlay]''': sets an image that will be drawn over a particular unit, and follow it around<br />
** '''x''', '''y''': the location of the unit to overlay on<br />
** '''image''': the image to place on the unit<br />
* '''[remove_unit_overlay]''': removes a particular overlayed image from a unit<br />
** '''x''', '''y''': the location of the unit to remove an overlay from<br />
** '''image''': the image to remove from the unit<br />
* '''[animate_unit]''': uses the custom animation of a unit to animate it on screen (if the unit has the corresponding animation)<br />
** '''flag''': the key to find the good custom animation in the unit description see the '''[extra_anim]''' description in [[AnimationWML]] Standar anims can be triggered with the following keywors ''leading recruited standing idling levelin levelout healing healed poisoned movement defend attack death victory pre_teleport post_teleport''<br />
** '''[filter]''': a [[StandardUnitFilter]] see [[FilterWML]] by default, the unit at the event location will be animated. You can use this tag to choose any other unit to animate<br />
** '''[primary_attack]''': if this tag is not present, the filter for animation will be triggered with no attack. If it is here, all attacks from the unit will be filtered, and a matching one will be used to filter the animation<br />
** '''[secondary_attack]''': same for the second attack<br />
** '''hit''': the hit type to filter unit on<br />
** '''text''': a text to hover during the animation<br />
** '''text_color''': r,g,b value for the text color<br />
** '''with_bars''': whether to display the status bars or not.<br />
* '''[label]''' places a label on the map.<br />
** '''x''', '''y''': the location of the label<br />
** '''text''': what the label should say<br />
** '''team_name''': if specified, the label will only be visible to the given team.<br />
* '''[deprecated_message]''' shows a deprecated message in the message area, this feature is only intended to be used to warn about deprecated macros in mainline. The message is not translatable.<br />
** '''message''': the message to show.<br />
* '''[debug_message]''': outputs a message to Wesnoth's console output. Intended for campaign designers to output silent text to the console, without annoying the player; then, that text might contain information useful for later bug-reporting.<br />
** '''message''': the message to show<br />
** '''logger''': the Wesnoth engine output logger that should catch the text; this might be 'err' (the errors log level), 'warn'/'wrn' (the warnings log level) or anything else (the information log level). Not all information will be displayed depending on the log level chosen when starting Wesnoth.<br />
<br />
== Useful Macros ==<br />
There are some predefined macros that you find useful for interface actions. You can find a complete list along with a detailed explanation of how they work [http://www.wesnoth.org/misc/macro-reference.xhtml here].<br />
* '''{FLOATING_TEXT}''' Float some text over a unit similar to the damage numbers.<br />
* '''{HIGHLIGHT_UNIT}''' Highlight a unit on the map. Use this to show important units<br />
* '''{HIGHLIGHT_IMAGE}''' Places and highlights an image on the map. Use this to show important items or locations<br />
* '''{SET_IMAGE}''' Places an image on the map which has no other function.<br />
* '''{TREMOR}''' Creates a tremor like screenshake<br />
* '''{FLASH_WHITE}''' Flash the screen white momentarily. You can also replace WHITE with RED, BLUE or GREEN for a different colour.<br />
<br />
== See Also ==<br />
* [[DirectActionsWML]]<br />
* [[InternalActionsWML]]<br />
* [[EventWML]]<br />
* [[ReferenceWML]]<br />
<br />
<br />
[[Category: WML Reference]]</div>Grzywaczhttps://wiki.wesnoth.org/index.php?title=InterfaceActionsWML&diff=23672InterfaceActionsWML2008-03-16T10:36:10Z<p>Grzywacz: Documented the full_range= attribute of [sound_source]</p>
<hr />
<div>{{WML Tags}}<br />
== Interface actions ==<br />
<br />
Interface actions are actions that do not have an effect on gameplay;<br />
instead, they show something to the player. The main interface tags<br />
are '''[message]''' and '''[objectives]''', but several other tags affect<br />
the interface also.<br />
<br />
== [message] ==<br />
The most commonly used interface action is [message], which displays a message to the user in a dialog box. It can also be used to take input from the user.<br />
<br />
The following key/tags are accepted for [message]:<br />
* [[StandardUnitFilter]]: the unit whose profile and name are displayed. If no unit matching this filter is found, the message is not displayed (The unit has probably been killed).<br>'''[message]''' elements should be constructed so that it is either guaranteed that a certain unit is alive, or so that dialog flows smoothly even if the message isn't displayed.<br />
<br />
* '''speaker''': an alternative to standard unit filter. You may specify as the value of the speaker attribute a unit description or any of the following special values:<br />
** '''narrator''': the dialog box is displayed without a caption for the unit speaking or a unit image<br />
** '''unit''': the primary unit for the event is speaking<br />
** '''second_unit''': the secondary unit for the event is speaking<br />
<br />
* '''message''': (translatable) the text to display to the right of the image. ''message'' is sometimes multiple lines; if it is, be sure to use quotes(''' ' ''' or ''' " ''')<br />
* '''side_for''': (default: all sides) comma-separated list of sides for who message is shown.<br />
* '''image''': (default: profile image of speaker) the image to display next to the message.<br />
* '''caption''': (default: name of speaker) the caption to display beside the image. Name to be displayed.<br />
* '''duration''': (default: 10) the minimum number of frames for this message to be displayed. (A frame lasts about 30 milliseconds.) During this time any dialog decisions will be disregarded.<br />
* '''sound''': a sound effect (wav file) to play as the message is displayed. This can be a comma-separated list, from which one will be randomly chosen.<br />
* '''[option]''': zero or more '''[option]''' elements may be present. If '''[option]''' elements are present, then each option will be displayed in a menu for the user to select one option.<br />
** ''message'' (translatable) the text displayed for the option (see [[DescriptionWML]])<br />
** '''[show_if]''': if present then this option will only be displayed if the conditional statement in this tag is passed (see [[InternalActionsWML]])<br />
** '''[command]''': an element containing actions which are executed if the option is selected.<br />
* '''[text_input]''': there can be only one [text_input] tag. this adds a text input field to the message.<br />
** '''variable''': the variable that the user's input will be written to<br />
** '''label''': a text label to the left of the input field<br />
** '''max_chars''': the maximum number of characters that may be typed into the field<br />
** '''text''': text that is written into the field in the beginning<br />
* note that '''[option]''' and '''[text_input]''' can only be used in moveto events in MP, otherwise they cause OOS<br />
<br />
Text formatting options for '''[message]'''. These can also be used in unit names (user_description), objectives, and such.<br />
* A tilde (~) as the first character causes the line to be boldfaced.<br />
* An at symbol (@) as the first character causes the line to be green, as done with victory conditions.<br />
* A pound symbol (#) as the first character causes the line to be red, as done with defeat conditions.<br />
* An asterisk (*) as the first character causes the line to be bigger.<br />
* A backquote (`) as the first character causes the line to be smaller.<br />
* If used, the caption key text is boldfaced.<br />
* An RGB colour code in the beginning causes the line to be the given colour. This can still be preceded by the above characters. Example: ''message=_"<255,0,0>Red!"''<br />
<br />
== [objectives] ==<br />
The other tag used for plot development is '''[objectives]'''.<br />
The '''[objectives]''' tag overwrites any previously set objectives,<br />
and displays text which should describe the objectives of the scenario.<br />
Scenario objectives are displayed on the player's first turn after the tag is used,<br />
or as part of the event if it triggers during that player's turn.<br />
Objectives can also be accessed at any time in a scenario using the<br />
"Scenario Objectives" game menu option, making this tag useful for<br />
scenario-specific information that the player may need to refer to during play.<br />
<br />
This tag renders the ''objectives'' attribute of [scenario] obsolete (see ''objectives'', [[ScenarioWML]]).<br />
Instead of using ''objectives'', use '''[objectives]''' to set scenario objectives inside a prestart event.<br />
It can also be used to overwrite the starting objectives mid-scenario.<br />
<br />
Attributes of '''[objectives]''':<br />
* '''side''': Default '0'. The side to set the objectives for. A value of 0 sets objectives for all sides.<br />
* '''summary''': Displayed first in the objectives text, this should describe the basic objective for the overall scenario. Can be omitted.<br />
* '''note''': Displayed last in the objectives text, this is sometimes used for hints or additional information. Can be omitted.<br />
* '''victory_string''': Default ' _ "Victory:"', this text precedes the victory objectives.<br />
* '''defeat_string''': Default ' _ "Defeat:"', this text precedes the defeat objectives.<br />
* '''silent''': Default: not present. If set to "yes", the objectives are silently changed. Else, they will be shown to the user when appropriate.<br />
<br />
Tags of '''[objectives]''':<br />
* '''[objective]''': describes a win or loss condition. Most scenarios have multiple win or loss conditions, so use a separate [objective] subtag for each line; this helps with translations.<br />
** '''description''': text for the specific win or loss condition.<br />
** '''condition''': The color and placement of the text. Values are 'win'(colored green, placed after ''victory_string'') and 'lose'(colored red, placed after ''defeat_string'')<br />
<br />
=== Macros ===<br />
There are a few predefined macros for Objectives that you can use to shorten the code. '''{SET_OBJECTIVES}''', '''{VICTORY_CONDITION}''' and '''{DEFEAT_CONDITION}'''. There are all used together. For more information look [http://www.wesnoth.org/misc/macro-reference.xhtml here]<br />
<br />
== [set_menu_item] ==<br />
This tag is used to add a custom option in the right-click context menu which can then be used to trigger arbitrary WML commands.<br />
<br />
* '''id''': the unique id for this menu item. If a menu item with this id already exists, it allows you to set specific changes to that item.<br />
* '''description''': the in-game text that will appear for this item in the menu.<br />
* '''image''': the image to display next to this item.<br />
* '''needs_select''': if ''yes'' (default ''no''), then the latest select event (see [[EventWML]]) that triggered before this menu item was chosen will be transmitted over the network before this menu item action will be. This only has any effect in networked multiplayer, and is intended to allow more elaborate menu item behaviour there without causing out of sync errors. If you don't know what this means, just leave it false.<br />
* '''[show_if]''': If present, the menu item will only be available if the conditional statement (see [[InternalActionsWML]]) within evaluates to true. When this is evaluated, the WML variables ''$x1'' and ''$y1'' will point to the location on which the context menu was invoked, so it's possible to for example only enable the option on empty hexes or on a particular unit.<br />
* '''[filter_location]''': contains a location filter similar to the one found inside Single Unit Filters (see [[FilterWML]]). The menu item will only be available on matching locations.<br />
* '''[command]''': contains the WML actions to be executed when the menu item is selected. Again, the WML variables ''$x1'' and ''$y1'' will point to the location on which the context menu was invoked on.<br />
<br />
== Other interface tags ==<br />
<br />
The following tags are also action tags:<br />
* '''[item]''': makes a graphical item appear on a certain hex. Note this only places the graphics for an item. It does not make the item do anything. Use a moveto event to make moving onto the item do something. <tt>''('''Hint:''' There are a number of predefined items that are used in various campaigns that you can make use of. You can find a list of them if you look into the items.cfg file in the wesnoth install directory (under /data/core/macros))''</tt><br />
** '''x''', '''y''': the location to place the item.<br />
** '''image''': the image (in ''images/'' as .png) to place on the hex.<br />
** '''halo''': an image to place centered on the hex. Use this instead of ''image'' if the image is bigger than the hex.<br />
* '''[removeitem]''': removes any graphical items on a given hex<br />
** '''x''', '''y''': the hex to remove items off<br />
* '''[print]''': displays a message across the screen. The message will disappear after a certain time.<br />
** '''text''': (translatable) the text to display.<br />
** '''size''': (default=12) the pointsize of the font to use<br />
** '''duration''': (default=50) the length of time to display the text for. This is measured in the number of 'frames'. A frame in Wesnoth is usually displayed for around 30ms.<br />
** '''red''', '''green''', '''blue''': (default=0,0,0) the color to display the text in. Values vary from 0-255.<br />
* '''[move_unit_fake]''': moves an image of a unit along a certain path on the map. The path does not need to be a continuous list of adjacent hexes, so for example only the start and end points can be given, in which case the straightest line between those points will be calculated and used.<br />
** '''type''': the type of the unit whose image to use<br />
** '''x''': a comma-separated list of x locations to move along<br />
** '''y''': a comma-separated list of y locations to move along (x and y values are matched pairs)<br />
** '''side''': the side of the fake unit, used for team-coloring the fake unit<br />
* '''[hide_unit]''': makes the given unit become invisible. Useful in conjunction with '''[move_unit_fake]''': to move a leader unit into position on-screen. Only one unit may be hidden at a time.<br />
** '''x''', '''y''': location of the unit to be hidden. (NOT a standard unit filter! Just x and y.)<br />
* '''[unhide_unit]''': stops the currently hidden unit from being hidden.<br />
* '''[scroll]''': Scroll a certain number of pixels in a given direction. Useful for earthquake/shaking effects.<br />
** '''x''', '''y''': the number of pixels to scroll along the x and y axis<br />
* '''[scroll_to]''': Scroll to a given hex<br />
** '''x''', '''y''': the hex to scroll to<br />
** '''check_fogged''': whether to scroll even to locations covered in fog or shroud. Possible values ''true'' (don't scroll to fog) and ''false'' (scroll even to fog), with ''false'' as the default.<br />
* '''[scroll_to_unit]''' Scroll to a given unit<br />
** [[StandardUnitFilter]]<br />
** '''check_fogged''': whether to scroll even to locations covered in fog or shroud. Possible values ''true'' (don't scroll to fog) and ''false'' (scroll even to fog), with ''false'' as the default.<br />
* '''[sound]''': Plays a sound<br />
** '''name''': the filename of the sound to play (in ''sounds/'' as .wav or .ogg)<br />
** '''repeat''': repeats the sound for a specified additional number of times (default=0)<br />
* '''[sound_source]''': Creates a sound source. "Sound sources" is a general name for a mechanism which makes possible for map elements to emit sounds according to some rules, where "map elements" can be specific locations or terrain types. For now, only sound sources tied to locations are supported.<br />
** '''id''': a unique identification key of the sound source<br />
** '''sounds''': a list of comma separated, randomly played sounds associated with the sound source<br />
** '''delay''': a numerical value (in milliseconds) of the minimal delay between two playbacks of the source's sound if the source remains visible on the screen; if one scrolls out and back in, the source will be considered as ready to play<br />
** '''chance''': a percentage (a value from 0 to 100) describing the chance of the source being activated every second after the delay has passed or when the source's location appears on the screen (note that it cannot play more than one file at the same time)<br />
** '''check_fogged''': possible values "true" and "false" - if true the source will not play if its locations are fogged/shrouded<br />
** '''loop''': number of times a sound sample should be looped if it stays visible. -1 means infinite (~65000) {{DevFeature}}<br />
** '''full_range''': distance in hexes that determines the "circular" area where source plays with full volume, relative to screen center {{DevFeature}}<br />
** '''x,y''': a [[StandardLocationFilter]] for the locations associated with the sound source<br />
* '''[remove_sound_source]''': Removes a previously defined sound source.<br />
** '''id''': the identification key of the sound source to remove<br />
* '''[music]''': Switches to playing different music<br />
** '''name''': the filename of the music to play (in ''music/'' as .ogg)<br />
** see [[MusicListWML]] for the correct syntax<br />
* '''[colour_adjust]''': tints the colour of the screen.<br />
** '''red''', '''green''', '''blue''': values from -255 to 255, the amount to tint by for each colour<br />
* '''[delay]''': pauses the game<br />
** '''time''': the time to pause in milliseconds<br />
* '''[redraw]''': redraws the screen (this normally isn't done during events, although some of the other interface actions cause the screen or parts of it to be redrawn).<br />
** '''side''': if used, recalculates fog and shroud for that side. Useful if you for example spawn friendly units in the middle of an event and want the shroud to update accordingly (otherwise units that spawn inside fog would remain invisible for the duration of the event, since the fog would not automatically get cleared around them).<br />
* '''[unit_overlay]''': sets an image that will be drawn over a particular unit, and follow it around<br />
** '''x''', '''y''': the location of the unit to overlay on<br />
** '''image''': the image to place on the unit<br />
* '''[remove_unit_overlay]''': removes a particular overlayed image from a unit<br />
** '''x''', '''y''': the location of the unit to remove an overlay from<br />
** '''image''': the image to remove from the unit<br />
* '''[animate_unit]''': uses the custom animation of a unit to animate it on screen (if the unit has the corresponding animation)<br />
** '''flag''': the key to find the good custom animation in the unit description see the '''[extra_anim]''' description in [[AnimationWML]] Standar anims can be triggered with the following keywors ''leading recruited standing idling levelin levelout healing healed poisoned movement defend attack death victory pre_teleport post_teleport''<br />
** '''[filter]''': a [[StandardUnitFilter]] see [[FilterWML]] by default, the unit at the event location will be animated. You can use this tag to choose any other unit to animate<br />
** '''[primary_attack]''': if this tag is not present, the filter for animation will be triggered with no attack. If it is here, all attacks from the unit will be filtered, and a matching one will be used to filter the animation<br />
** '''[secondary_attack]''': same for the second attack<br />
** '''hit''': the hit type to filter unit on<br />
** '''text''': a text to hover during the animation<br />
** '''text_color''': r,g,b value for the text color<br />
** '''with_bars''': whether to display the status bars or not.<br />
* '''[label]''' places a label on the map.<br />
** '''x''', '''y''': the location of the label<br />
** '''text''': what the label should say<br />
** '''team_name''': if specified, the label will only be visible to the given team.<br />
* '''[deprecated_message]''' shows a deprecated message in the message area, this feature is only intended to be used to warn about deprecated macros in mainline. The message is not translatable.<br />
** '''message''': the message to show.<br />
* '''[debug_message]''': outputs a message to Wesnoth's console output. Intended for campaign designers to output silent text to the console, without annoying the player; then, that text might contain information useful for later bug-reporting.<br />
** '''message''': the message to show<br />
** '''logger''': the Wesnoth engine output logger that should catch the text; this might be 'err' (the errors log level), 'warn'/'wrn' (the warnings log level) or anything else (the information log level). Not all information will be displayed depending on the log level chosen when starting Wesnoth.<br />
<br />
== Useful Macros ==<br />
There are some predefined macros that you find useful for interface actions. You can find a complete list along with a detailed explanation of how they work [http://www.wesnoth.org/misc/macro-reference.xhtml here].<br />
* '''{FLOATING_TEXT}''' Float some text over a unit similar to the damage numbers.<br />
* '''{HIGHLIGHT_UNIT}''' Highlight a unit on the map. Use this to show important units<br />
* '''{HIGHLIGHT_IMAGE}''' Places and highlights an image on the map. Use this to show important items or locations<br />
* '''{SET_IMAGE}''' Places an image on the map which has no other function.<br />
* '''{TREMOR}''' Creates a tremor like screenshake<br />
* '''{FLASH_WHITE}''' Flash the screen white momentarily. You can also replace WHITE with RED, BLUE or GREEN for a different colour.<br />
<br />
== See Also ==<br />
* [[DirectActionsWML]]<br />
* [[InternalActionsWML]]<br />
* [[EventWML]]<br />
* [[ReferenceWML]]<br />
<br />
<br />
[[Category: WML Reference]]</div>Grzywaczhttps://wiki.wesnoth.org/index.php?title=InterfaceActionsWML&diff=23568InterfaceActionsWML2008-03-13T20:01:28Z<p>Grzywacz: Documented the loop property of sound_source</p>
<hr />
<div>{{WML Tags}}<br />
== Interface actions ==<br />
<br />
Interface actions are actions that do not have an effect on gameplay;<br />
instead, they show something to the player. The main interface tags<br />
are '''[message]''' and '''[objectives]''', but several other tags affect<br />
the interface also.<br />
<br />
== [message] ==<br />
The most commonly used interface action is [message], which displays a message to the user in a dialog box. It can also be used to take input from the user.<br />
<br />
The following key/tags are accepted for [message]:<br />
* [[StandardUnitFilter]]: the unit whose profile and name are displayed. If no unit matching this filter is found, the message is not displayed (The unit has probably been killed).<br>'''[message]''' elements should be constructed so that it is either guaranteed that a certain unit is alive, or so that dialog flows smoothly even if the message isn't displayed.<br />
<br />
* '''speaker''': an alternative to standard unit filter. You may specify as the value of the speaker attribute a unit description or any of the following special values:<br />
** '''narrator''': the dialog box is displayed without a caption for the unit speaking or a unit image<br />
** '''unit''': the primary unit for the event is speaking<br />
** '''second_unit''': the secondary unit for the event is speaking<br />
<br />
* '''message''': (translatable) the text to display to the right of the image. ''message'' is sometimes multiple lines; if it is, be sure to use quotes(''' ' ''' or ''' " ''')<br />
* '''side_for''': (default: all sides) comma-separated list of sides for who message is shown.<br />
* '''image''': (default: profile image of speaker) the image to display next to the message.<br />
* '''caption''': (default: name of speaker) the caption to display beside the image. Name to be displayed.<br />
* '''duration''': (default: 10) the minimum number of frames for this message to be displayed. (A frame lasts about 30 milliseconds.) During this time any dialog decisions will be disregarded.<br />
* '''sound''': a sound effect (wav file) to play as the message is displayed. This can be a comma-separated list, from which one will be randomly chosen.<br />
* '''[option]''': zero or more '''[option]''' elements may be present. If '''[option]''' elements are present, then each option will be displayed in a menu for the user to select one option.<br />
** ''message'' (translatable) the text displayed for the option (see [[DescriptionWML]])<br />
** '''[show_if]''': if present then this option will only be displayed if the conditional statement in this tag is passed (see [[InternalActionsWML]])<br />
** '''[command]''': an element containing actions which are executed if the option is selected.<br />
* '''[text_input]''': there can be only one [text_input] tag. this adds a text input field to the message.<br />
** '''variable''': the variable that the user's input will be written to<br />
** '''label''': a text label to the left of the input field<br />
** '''max_chars''': the maximum number of characters that may be typed into the field<br />
** '''text''': text that is written into the field in the beginning<br />
* note that '''[option]''' and '''[text_input]''' can only be used in moveto events in MP, otherwise they cause OOS<br />
<br />
Text formatting options for '''[message]'''. These can also be used in unit names (user_description), objectives, and such.<br />
* A tilde (~) as the first character causes the line to be boldfaced.<br />
* An at symbol (@) as the first character causes the line to be green, as done with victory conditions.<br />
* A pound symbol (#) as the first character causes the line to be red, as done with defeat conditions.<br />
* An asterisk (*) as the first character causes the line to be bigger.<br />
* A backquote (`) as the first character causes the line to be smaller.<br />
* If used, the caption key text is boldfaced.<br />
* An RGB colour code in the beginning causes the line to be the given colour. This can still be preceded by the above characters. Example: ''message=_"<255,0,0>Red!"''<br />
<br />
== [objectives] ==<br />
The other tag used for plot development is '''[objectives]'''.<br />
The '''[objectives]''' tag overwrites any previously set objectives,<br />
and displays text which should describe the objectives of the scenario.<br />
Scenario objectives are displayed on the player's first turn after the tag is used,<br />
or as part of the event if it triggers during that player's turn.<br />
Objectives can also be accessed at any time in a scenario using the<br />
"Scenario Objectives" game menu option, making this tag useful for<br />
scenario-specific information that the player may need to refer to during play.<br />
<br />
This tag renders the ''objectives'' attribute of [scenario] obsolete (see ''objectives'', [[ScenarioWML]]).<br />
Instead of using ''objectives'', use '''[objectives]''' to set scenario objectives inside a prestart event.<br />
It can also be used to overwrite the starting objectives mid-scenario.<br />
<br />
Attributes of '''[objectives]''':<br />
* '''side''': Default '0'. The side to set the objectives for. A value of 0 sets objectives for all sides.<br />
* '''summary''': Displayed first in the objectives text, this should describe the basic objective for the overall scenario. Can be omitted.<br />
* '''note''': Displayed last in the objectives text, this is sometimes used for hints or additional information. Can be omitted.<br />
* '''victory_string''': Default ' _ "Victory:"', this text precedes the victory objectives.<br />
* '''defeat_string''': Default ' _ "Defeat:"', this text precedes the defeat objectives.<br />
* '''silent''': Default: not present. If set to "yes", the objectives are silently changed. Else, they will be shown to the user when appropriate.<br />
<br />
Tags of '''[objectives]''':<br />
* '''[objective]''': describes a win or loss condition. Most scenarios have multiple win or loss conditions, so use a separate [objective] subtag for each line; this helps with translations.<br />
** '''description''': text for the specific win or loss condition.<br />
** '''condition''': The color and placement of the text. Values are 'win'(colored green, placed after ''victory_string'') and 'lose'(colored red, placed after ''defeat_string'')<br />
<br />
=== Macros ===<br />
There are a few predefined macros for Objectives that you can use to shorten the code. '''{SET_OBJECTIVES}''', '''{VICTORY_CONDITION}''' and '''{DEFEAT_CONDITION}'''. There are all used together. For more information look [http://www.wesnoth.org/misc/macro-reference.xhtml here]<br />
<br />
== [set_menu_item] ==<br />
This tag is used to add a custom option in the right-click context menu which can then be used to trigger arbitrary WML commands.<br />
<br />
* '''id''': the unique id for this menu item. If a menu item with this id already exists, it allows you to set specific changes to that item.<br />
* '''description''': the in-game text that will appear for this item in the menu.<br />
* '''image''': the image to display next to this item.<br />
* '''needs_select''': if ''yes'' (default ''no''), then the latest select event (see [[EventWML]]) that triggered before this menu item was chosen will be transmitted over the network before this menu item action will be. This only has any effect in networked multiplayer, and is intended to allow more elaborate menu item behaviour there without causing out of sync errors. If you don't know what this means, just leave it false.<br />
* '''[show_if]''': If present, the menu item will only be available if the conditional statement (see [[InternalActionsWML]]) within evaluates to true. When this is evaluated, the WML variables ''$x1'' and ''$y1'' will point to the location on which the context menu was invoked, so it's possible to for example only enable the option on empty hexes or on a particular unit.<br />
* '''[filter_location]''': contains a location filter similar to the one found inside Single Unit Filters (see [[FilterWML]]). The menu item will only be available on matching locations.<br />
* '''[command]''': contains the WML actions to be executed when the menu item is selected. Again, the WML variables ''$x1'' and ''$y1'' will point to the location on which the context menu was invoked on.<br />
<br />
== Other interface tags ==<br />
<br />
The following tags are also action tags:<br />
* '''[item]''': makes a graphical item appear on a certain hex. Note this only places the graphics for an item. It does not make the item do anything. Use a moveto event to make moving onto the item do something. <tt>''('''Hint:''' There are a number of predefined items that are used in various campaigns that you can make use of. You can find a list of them if you look into the items.cfg file in the wesnoth install directory (under /data/core/macros))''</tt><br />
** '''x''', '''y''': the location to place the item.<br />
** '''image''': the image (in ''images/'' as .png) to place on the hex.<br />
** '''halo''': an image to place centered on the hex. Use this instead of ''image'' if the image is bigger than the hex.<br />
* '''[removeitem]''': removes any graphical items on a given hex<br />
** '''x''', '''y''': the hex to remove items off<br />
* '''[print]''': displays a message across the screen. The message will disappear after a certain time.<br />
** '''text''': (translatable) the text to display.<br />
** '''size''': (default=12) the pointsize of the font to use<br />
** '''duration''': (default=50) the length of time to display the text for. This is measured in the number of 'frames'. A frame in Wesnoth is usually displayed for around 30ms.<br />
** '''red''', '''green''', '''blue''': (default=0,0,0) the color to display the text in. Values vary from 0-255.<br />
* '''[move_unit_fake]''': moves an image of a unit along a certain path on the map. The path does not need to be a continuous list of adjacent hexes, so for example only the start and end points can be given, in which case the straightest line between those points will be calculated and used.<br />
** '''type''': the type of the unit whose image to use<br />
** '''x''': a comma-separated list of x locations to move along<br />
** '''y''': a comma-separated list of y locations to move along (x and y values are matched pairs)<br />
** '''side''': the side of the fake unit, used for team-coloring the fake unit<br />
* '''[hide_unit]''': makes the given unit become invisible. Useful in conjunction with '''[move_unit_fake]''': to move a leader unit into position on-screen. Only one unit may be hidden at a time.<br />
** '''x''', '''y''': location of the unit to be hidden. (NOT a standard unit filter! Just x and y.)<br />
* '''[unhide_unit]''': stops the currently hidden unit from being hidden.<br />
* '''[scroll]''': Scroll a certain number of pixels in a given direction. Useful for earthquake/shaking effects.<br />
** '''x''', '''y''': the number of pixels to scroll along the x and y axis<br />
* '''[scroll_to]''': Scroll to a given hex<br />
** '''x''', '''y''': the hex to scroll to<br />
** '''check_fogged''': whether to scroll even to locations covered in fog or shroud. Possible values ''true'' (don't scroll to fog) and ''false'' (scroll even to fog), with ''false'' as the default.<br />
* '''[scroll_to_unit]''' Scroll to a given unit<br />
** [[StandardUnitFilter]]<br />
** '''check_fogged''': whether to scroll even to locations covered in fog or shroud. Possible values ''true'' (don't scroll to fog) and ''false'' (scroll even to fog), with ''false'' as the default.<br />
* '''[sound]''': Plays a sound<br />
** '''name''': the filename of the sound to play (in ''sounds/'' as .wav or .ogg)<br />
** '''repeat''': repeats the sound for a specified additional number of times (default=0)<br />
* '''[sound_source]''': Creates a sound source. "Sound sources" is a general name for a mechanism which makes possible for map elements to emit sounds according to some rules, where "map elements" can be specific locations or terrain types. For now, only sound sources tied to locations are supported.<br />
** '''id''': a unique identification key of the sound source<br />
** '''sounds''': a list of comma separated, randomly played sounds associated with the sound source<br />
** '''delay''': a numerical value (in milliseconds) of the minimal delay between two playbacks of the source's sound if the source remains visible on the screen; if one scrolls out and back in, the source will be considered as ready to play<br />
** '''chance''': a percentage (a value from 0 to 100) describing the chance of the source being activated every second after the delay has passed or when the source's location appears on the screen (note that it cannot play more than one file at the same time)<br />
** '''check_fogged''': possible values "true" and "false" - if true the source will not play if its locations are fogged/shrouded<br />
** '''loop''': number of times a sound sample should be looped if it stays visible. -1 means infinite (~65000). {{DevFeature}}<br />
** '''x,y''': a [[StandardLocationFilter]] for the locations associated with the sound source<br />
* '''[remove_sound_source]''': Removes a previously defined sound source.<br />
** '''id''': the identification key of the sound source to remove<br />
* '''[music]''': Switches to playing different music<br />
** '''name''': the filename of the music to play (in ''music/'' as .ogg)<br />
** see [[MusicListWML]] for the correct syntax<br />
* '''[colour_adjust]''': tints the colour of the screen.<br />
** '''red''', '''green''', '''blue''': values from -255 to 255, the amount to tint by for each colour<br />
* '''[delay]''': pauses the game<br />
** '''time''': the time to pause in milliseconds<br />
* '''[redraw]''': redraws the screen (this normally isn't done during events, although some of the other interface actions cause the screen or parts of it to be redrawn).<br />
** '''side''': if used, recalculates fog and shroud for that side. Useful if you for example spawn friendly units in the middle of an event and want the shroud to update accordingly (otherwise units that spawn inside fog would remain invisible for the duration of the event, since the fog would not automatically get cleared around them).<br />
* '''[unit_overlay]''': sets an image that will be drawn over a particular unit, and follow it around<br />
** '''x''', '''y''': the location of the unit to overlay on<br />
** '''image''': the image to place on the unit<br />
* '''[remove_unit_overlay]''': removes a particular overlayed image from a unit<br />
** '''x''', '''y''': the location of the unit to remove an overlay from<br />
** '''image''': the image to remove from the unit<br />
* '''[animate_unit]''': uses the custom animation of a unit to animate it on screen (if the unit has the corresponding animation)<br />
** '''flag''': the key to find the good custom animation in the unit description see the '''[extra_anim]''' description in [[AnimationWML]] Standar anims can be triggered with the following keywors ''leading recruited standing idling levelin levelout healing healed poisoned movement defend attack death victory pre_teleport post_teleport''<br />
** '''[filter]''': a [[StandardUnitFilter]] see [[FilterWML]] by default, the unit at the event location will be animated. You can use this tag to choose any other unit to animate<br />
** '''[primary_attack]''': if this tag is not present, the filter for animation will be triggered with no attack. If it is here, all attacks from the unit will be filtered, and a matching one will be used to filter the animation<br />
** '''[secondary_attack]''': same for the second attack<br />
** '''hit''': the hit type to filter unit on<br />
** '''text''': a text to hover during the animation<br />
** '''text_color''': r,g,b value for the text color<br />
** '''with_bars''': whether to display the status bars or not.<br />
* '''[label]''' places a label on the map.<br />
** '''x''', '''y''': the location of the label<br />
** '''text''': what the label should say<br />
** '''team_name''': if specified, the label will only be visible to the given team.<br />
* '''[deprecated_message]''' shows a deprecated message in the message area, this feature is only intended to be used to warn about deprecated macros in mainline. The message is not translatable.<br />
** '''message''': the message to show.<br />
* '''[debug_message]''': outputs a message to Wesnoth's console output. Intended for campaign designers to output silent text to the console, without annoying the player; then, that text might contain information useful for later bug-reporting.<br />
** '''message''': the message to show<br />
** '''logger''': the Wesnoth engine output logger that should catch the text; this might be 'err' (the errors log level), 'warn'/'wrn' (the warnings log level) or anything else (the information log level). Not all information will be displayed depending on the log level chosen when starting Wesnoth.<br />
<br />
== Useful Macros ==<br />
There are some predefined macros that you find useful for interface actions. You can find a complete list along with a detailed explanation of how they work [http://www.wesnoth.org/misc/macro-reference.xhtml here].<br />
* '''{FLOATING_TEXT}''' Float some text over a unit similar to the damage numbers.<br />
* '''{HIGHLIGHT_UNIT}''' Highlight a unit on the map. Use this to show important units<br />
* '''{HIGHLIGHT_IMAGE}''' Places and highlights an image on the map. Use this to show important items or locations<br />
* '''{SET_IMAGE}''' Places an image on the map which has no other function.<br />
* '''{TREMOR}''' Creates a tremor like screenshake<br />
* '''{FLASH_WHITE}''' Flash the screen white momentarily. You can also replace WHITE with RED, BLUE or GREEN for a different colour.<br />
<br />
== See Also ==<br />
* [[DirectActionsWML]]<br />
* [[InternalActionsWML]]<br />
* [[EventWML]]<br />
* [[ReferenceWML]]<br />
<br />
<br />
[[Category: WML Reference]]</div>Grzywaczhttps://wiki.wesnoth.org/index.php?title=SummerOfCodeIdeas&diff=22902SummerOfCodeIdeas2008-02-27T20:57:30Z<p>Grzywacz: Typo fixes</p>
<hr />
<div>== Ideas for Google Summer of Code projects ==<br />
<br />
This is a compilation of ideas from ML. Needs to be refined (more detailed description, deliverables, workload estimation?):<br />
<br />
== List of Ideas for the Project ==<br />
<br />
=== Writing an AI based on the formula AI ===<br />
<br />
Wesnoth has always had a simple C++ based AI. David (our lead developer) has been working on a simple language to write AI in Wesnoth ''link to formula AI page here'' <br />
<br />
The Wesnoth AI is used as an opponent in most campaigns, and as such is an important piece of code for the Wesnoth project. Unfortunately it is also one of the most neglected piece of code and a place where a lot of research and work could be done<br />
<br />
==== General description ====<br />
<br />
The aim of this project is to develop a new AI that would replace the original C++ AI. The main criterias we would want for this new AI are<br />
<br />
* ''Plugability :'' It should be trivial for any content maker to change the behavior of the AI in specific case. The exact cases are still to be defined but should typically include<br />
** hardwiring the first few turns of the AI<br />
** changing the recruitment pattern<br />
** completely controlling a given unit (scenario unit)<br />
** taking control then giving back control of a given unit<br />
* ''tunability :'' It should be easy for a scenario author to specify the general behaviour of the enemy on a given scenario (aggressiveness, intrepidity...)<br />
* ''specific behaviours :'' there are some typical behaviours that are not smart to win the scenario but are needed, such as guarding a given unit, a given position, wandering aimlessly, attacking randomly, always fleeing. The AI should implement such behaviours, and allow easy addition of new behaviours<br />
<br />
==== Required knowledge and talent ====<br />
<br />
* ''A minimal knowledge of C++ is required, a good knowledge of C++ is desired :'' The formula AI framework is a work in progress and chances are high that some changes in the wesnoth code base will be needed. The wesnoth developer community is used to handle people that are familiar with coding but not C++, however the Formula AI framework uses advanced C++ features and a good knowledge of the language would avoid a major hurdle when plugging in new entries or functionalities for the AI<br />
* ''Good social interaction with a large player community :'' A preliminary phase to coding any AI is to know the strategies and game pattern used by human players. This requires huge interaction with the player community. Our Gameplay Developers are open and can give some good starting points, but a big game experience and good interaction with the player community will greatly help in the study of the design<br />
<br />
==== Milestones and deliverables ====<br />
<br />
It is hard to give milestones at this point, but here are some ideas of what could be done<br />
<br />
* ''AI design description, and basic function library :'' This first deliverable aims to conclude the '''study and analysis''' part of the project : becoming familiar with the formula language, study of multiplayer strategies and of the need of scenario writers with regard to AI. We would like to have a description of the code structure of the AI, some basis of the play strategies it would use and how external scenario writers could configure it for the particular behaviour they need<br />
* ''Main AI delivery :'' This milestone's aim is to deliver a working AI implementing the strategies described in the first phase. It would not have to systematically beat the standard C++ AI at this point, but should be able to play the game correctly (recruit, early deployment on villages, grouping units to attack, holding its ground, protecting weak/important units). Moreover most plug-in entries should be available and a test-case for these entries should be provided.<br />
* ''Fine tunning and behaviour library :'' The third phase would validate the actual strategy of the AI. The AI should consistently beat the default C++ AI, and do fairly well against an average human player. At that stage a library of scenario behaviours should also be delivered. The AI does not need to be as efficient with all scenario tweaking, but should act correctly with regard to the particular behaviour desired.<br />
<br />
=== Extending the Multiplayer server ===<br />
<br />
When the development team met at FOSDEM, we had our multiplayer community, though it is strong and healthy, had its growth restrained by the interface of the multiplayer lobby.<br />
<br />
==== General Description ====<br />
The general idea of this project would be<br />
* To study the current lobby,<br />
* To present some ideas of evolutions both in interface and functionalities of our multiplayer interface to allow it to scale to a much larger community<br />
* To present some well constructed thought on our MP community and how that interface would develop it<br />
* Of course to implement those changes :)<br />
<br />
Some ideas that we had (but that are in no way mandatory)<br />
* Having a simple way to register and authenticate nicknames, similar to what IRC offers. The point is not to have cryptographically safe logins, but to have something simple that gets the job done<br />
* Having a simple room system? again inspired on IRC<br />
* Having some way to find the type of games you are interested in.<br />
** game type<br />
** number of free slots/players<br />
** any other criteria you might find interesting<br />
<br />
Other ideas we are not convinced are good, but that are certainly worth studying (especially how the communities based around these concepts are different from ours)<br />
* ranking players<br />
* guilds<br />
* official tournaments<br />
* titles for players<br />
* metaservers<br />
<br />
The scalability of the project, both in term of number of players, and in term of the possibility for players and developers to extend the concept will be a valued criteria<br />
<br />
Administration/moderation problems and techniques should also be studied<br />
<br />
interaction with the Add-On server/forum might be an interesting field to expand to<br />
<br />
==== Required knowledge and talent ====<br />
<br />
* A fair amount of experience on C++ is required. Wesnoth uses some advanced C++ features and is heavily based on BOOST and STL. We can train you in some of the libraries used, but learning all of them would be a big hurdle<br />
* Various experience with multiplayer games, in order to have a good idea of what multiplayer lobbies of other game look like, and (more importantly) a good idea of the social behaviours of multiple MP communities, how teams are formed in games and things like that<br />
<br />
==== Milestones and deliverables ====<br />
<br />
* A first milestone would be a presentation summarizing the different studies, and the proposed interface. preliminary informal stages would probably be desirable, to make sure the proposed idea is already a consensus within devs <br />
** Study of other MP game-matching interfaces and functionalities<br />
** Study of other MP communities<br />
** Study of other MP moderation practices<br />
** Study of the Wesnoth MP community, including needs, various opinons from different developers and players<br />
* A second milestone would be the main code delivery. Code should be functional for it will be delivered in the next Wesnoth development release<br />
<br />
=== Other ideas to be fleshed out ===<br />
* Working on the GUI engine (needs to be defined more precisely)<br />
* Rewrite of the campaign (add-on) server<br />
* The editor can use quite a revamp<br />
* A good scenario editor. We have campgen but it hasn't been updated for a while.<br />
<br />
<br />
== Other info to provide for GSoC ==<br />
==== Describe your organization. ====<br />
<br />
==== Why is your organization applying to participate in GSoC 2008? What do you hope to gain by participating?====<br />
<br />
Most of our developers have interesting areas in which they work. Though they are efficient in their areas, there are areas that are interesting but have a high barrier of entry.<br />
<br />
By having a student dedicated to any of these areas, we could quickly get someone up to date with that particular area, efficient, and responsible of this area.<br />
<br />
Basically, by getting new people in and making them actively responsible for an area of code we hope to kickstart some areas of the project that have lagged behind<br />
<br />
==== Did your organization participate in past GSoCs? If so, please summarize your involvement and the successes and challenges of your participation.====<br />
This is the first time the Wesnoth projects applies to Google SoC<br />
<br />
==== If your organization has not previously participated in GSoC, have you applied in the past? If so, for what year(s)?====<br />
<br />
This is the first time the Wesnoth projects applies to Google SoC<br />
<br />
==== Who will your organization administrator be? Please include Google Account information.====<br />
Nils Kneuper aka Ivanovic<br />
<br />
crazy.ivanovic |ATTT| googlemail.com<br />
<br />
==== What license(s) does your project use?====<br />
Our project is entirely GPL.<br />
<br />
All code is GPL.<br />
<br />
All art is GPL, 99% was made for the project, everything was taken from content that was checked to be GPL.<br />
<br />
==== What is the URL for your ideas page?====<br />
Our main summer of code pages is located at http://www.wesnoth.org/wiki/SummerOfCodeIdeas<br />
<br />
This page contains various coding ideas and the thought the development team has already given them.<br />
<br />
It also contains a list of the developers that are the most active on IRC and their domain of interest.<br />
<br />
==== What is the main development mailing list or forum for your organization?====<br />
Most development work takes place on "wesnoth-dev |ATTT| gna.org". Beside this some work happens at http://www.wesnoth.org/forum/.<br />
<br />
==== What is the main IRC channel for your organization?====<br />
<br />
All our IRC channels are on the ''freenode'' network<br />
<br />
* ''#wesnoth-dev'' is the main development channel, where most discussion takes place<br />
* ''#wesnoth'' is a generic channel for the community<br />
* ''#wesnoth-mp'' is a separate channel for multiplayer games and balancing<br />
<br />
==== Does your organization have an application template you would like to see students use? If so, please provide it now.====<br />
We plan mainly to meet potential students through our IRC channel, but the following questions are wesnoth-specific and are worth pondering for any student, even if we don't need a formal answer<br />
<br />
* What type of gamer are you? What type of games? What type of opponent? Are you more interested in story or gameplay ? <br />
* Are you good at interacting with other players ? Our developer community is quite nice, but the player community can be a bit rough.<br />
* Do you give constructive advices? Do you receive advice well? Are you good at sorting useful criticism from useless ones?<br />
<br />
''''to be completed''''<br />
<br />
==== Who will be your backup organization administrator? Please include Google Account information.====<br />
<br />
Jeremy Rosen alias Boucman<br />
<br />
boucman2@gmail.com<br />
<br />
==== Who will your mentors be? Please include Google Account information.====<br />
<br />
==== What criteria did you use to select these individuals as mentors? Please be as specific as possible.====<br />
<br />
==== What is your plan for dealing with disappearing students?====<br />
<br />
==== What is your plan for dealing with disappearing mentors?====<br />
<br />
==== What steps will you take to encourage students to interact with your project's community before, during and after the program?====<br />
<br />
Wesnoth has a particularly healthy community, both for developers and for players. <br />
<br />
Our general policy regarding new coders has always been "two patch... you're in" In other word, anybody that is able to get two non-trivial patches applied is offered commit right.<br />
<br />
We have a developer responsible for applying patches and guiding new developers into our community. This is a well known and effective process we plan to apply to students, directing them to our [[EasyCoding]] pages (these project are usually a couple of hours long and has been chosen to provide easy access to code)<br />
<br />
Usually, patches go back and forth a couple of time, to make sure that all secondary things are in place (indenting, coding style, modified makefiles etc.) The idea is that coder education should take place before the coder gets commit rights, but that getting new coder in is one of the most important things to maintain our project alive.<br />
<br />
If the student is a little proactive and ready to join IRC, all the developers are usually very welcoming, and good at directing newcomers to quickly give useful results.<br />
<br />
'''to be completed'''<br />
<br />
==== What will you do to ensure that your accepted students stick with the project after GSoC concludes?====<br />
<br />
<br />
<br />
=== People to bug on IRC, possible mentors ===<br />
Everybody feel free to edit/correct his entry!<br />
<br />
==== Dave alias Sirp ====<br />
<br />
Sirp started Wesnoth and is our lead developper. He is currently our C++ expert and is also the one that is working on the new Formula AI. Any questions regarding the formula AI should be directed to him.<br />
<br />
==== Mordante ====<br />
Many of the possible projects do at least partly go into the area of code where he knows most of. Plus many of the possible projects currently listed on the ideas page do require GUI parts to work, too. So if Mordante wants to tackle a rewrite of large parts of this, he will be our expert there as well as he already is our expert for the terrain engine (cf. editor / scenario editor works).<br />
<br />
==== Elias Pscherning (elias) ====<br />
He has written the original version of campgen and as such will know a lot about what is needed to to make such an editor work correctly. The work on a scenario editor might be based upon campgen and as such make his knowledge really helpful.<br />
<br />
==== Karol Nowak (grzywacz) ====<br />
Last year he was participating at GSoC as a student, so he knows at least this side of the medal. Beside this he is our top expert regarding embedded devices support since he is actively working on the gp2x support.<br />
<br />
==== boucman ====<br />
As our "patch monkey" he has valuable knowledge in comments and critics for patches of every kind. Beside this he knows many areas of the game due to working on applying patches. He is particularly used to answer question from new coders, and doesn't mind explaining trivial stuff.<br />
<br />
If you want to have a feeling of the developer spirit, it is recommended to go to our [[EasyCoding]] page.<br />
<br />
==== Soliton ====<br />
He does know our mp server setup best. Beside this he already has done a lot of work on the mp server himself, too. So he probably has most knowledge about it and due to being one of our mp-developers might provide important help from the perspective of mp-community and what is needed there.<br />
<br />
==== zookeeper or Mythological or Rhuaven ====<br />
As our leading WML expert it would be good to have him in the list when it comes to WML specific problems. That is for work on the scenario editor he probably knows best what should be implemented in it and what is a usable way for things.<br />
<br />
==== YogiHH or Piotr Cychowski (cycholka) ====<br />
Since they are the two developers who know most about building under Windows, they will probably be really helpful. Either if the student comes from the Windows side, or to help test resulting work to make sure that it does work on Windows and, for the case that it does not, to show them where problems are.</div>Grzywaczhttps://wiki.wesnoth.org/index.php?title=SummerOfCodeIdeas&diff=22901SummerOfCodeIdeas2008-02-27T20:56:37Z<p>Grzywacz: Typo fixes</p>
<hr />
<div>== Ideas for Google Summer of Code projects ==<br />
<br />
This is a compilation of ideas from ML. Needs to be refined (more detailed description, deliverables, workload estimation?):<br />
<br />
== List of Ideas for the Project ==<br />
<br />
=== Writing an AI based on the formula AI ===<br />
<br />
Wesnoth has always had a simple C++ based AI. David (our lead developer) has been working on a simple language to write AI in wesnoth ''link to formula AI page here'' <br />
<br />
The wesnoth AI is used as an oponent in most campaigns, and as such is an important piece of code for the wesnoth project. Unfortunately it is also one of the most neglected piece of code and a place where a lot of research and work could be done<br />
<br />
==== General description ====<br />
<br />
The aim of this project is to develop a new AI that would replace the original C++ AI. The main criterias we would want for this new AI are<br />
<br />
* ''Plugability :'' It should be trivial for any content maker to change the behavior of the AI in specific case. The exact cases are still to be defined but should typically include<br />
** hardwiring the first few turns of the AI<br />
** changing the recruitment pattern<br />
** completely controlling a given unit (scenario unit)<br />
** taking control then giving back control of a given unit<br />
* ''tunability :'' It should be easy for a scenario author to specify the general behaviour of the enemy on a given scenario (aggressiveness, intrepidity...)<br />
* ''specific behaviours :'' there are some typical behaviours that are not smart to win the scenario but are needed, such as guarding a given unit, a given position, wandering aimlessly, attacking randomly, always fleeing. The AI should implement such behaviours, and allow easy addition of new behaviours<br />
<br />
==== Required knowledge and talent ====<br />
<br />
* ''A minimal knowledge of C++ is required, a good knowledge of C++ is desired :'' The formula AI framework is a work in progress and chances are high that some changes in the wesnoth code base will be needed. The wesnoth developer community is used to handle people that are familiar with coding but not C++, however the Formula AI framework uses advanced C++ features and a good knowledge of the language would avoid a major hurdle when plugging in new entries or functionalities for the AI<br />
* ''Good social interaction with a large player community :'' A preliminary phase to coding any AI is to know the strategies and game pattern used by human players. This requires huge interaction with the player community. Our Gameplay Developers are open and can give some good starting points, but a big game experience and good interaction with the player community will greatly help in the study of the design<br />
<br />
==== Milestones and deliverables ====<br />
<br />
It is hard to give milestones at this point, but here are some ideas of what could be done<br />
<br />
* ''AI design description, and basic function library :'' This first deliverable aims to conclude the '''study and analysis''' part of the project : becoming familiar with the formula language, study of multiplayer strategies and of the need of scenario writers with regard to AI. We would like to have a description of the code structure of the AI, some basis of the play strategies it would use and how external scenario writers could configure it for the particular behaviour they need<br />
* ''Main AI delivery :'' This milestone's aim is to deliver a working AI implementing the strategies described in the first phase. It would not have to systematically beat the standard C++ AI at this point, but should be able to play the game correctly (recruit, early deployment on villages, grouping units to attack, holding its ground, protecting weak/important units). Moreover most plug-in entries should be available and a test-case for these entries should be provided.<br />
* ''Fine tunning and behaviour library :'' The third phase would validate the actual strategy of the AI. The AI should consistently beat the default C++ AI, and do fairly well against an average human player. At that stage a library of scenario behaviours should also be delivered. The AI does not need to be as efficient with all scenario tweaking, but should act correctly with regard to the particular behaviour desired.<br />
<br />
=== Extending the Multiplayer server ===<br />
<br />
When the development team met at FOSDEM, we had our multiplayer community, though it is strong and healthy, had its growth restrained by the interface of the multiplayer lobby.<br />
<br />
==== General Description ====<br />
The general idea of this project would be<br />
* To study the current lobby,<br />
* To present some ideas of evolutions both in interface and functionalities of our multiplayer interface to allow it to scale to a much larger community<br />
* To present some well constructed thought on our MP community and how that interface would develop it<br />
* Of course to implement those changes :)<br />
<br />
Some ideas that we had (but that are in no way mandatory)<br />
* Having a simple way to register and authenticate nicknames, similar to what IRC offers. The point is not to have cryptographically safe logins, but to have something simple that gets the job done<br />
* Having a simple room system? again inspired on IRC<br />
* Having some way to find the type of games you are interested in.<br />
** game type<br />
** number of free slots/players<br />
** any other criteria you might find interesting<br />
<br />
Other ideas we are not convinced are good, but that are certainly worth studying (especially how the communities based around these concepts are different from ours)<br />
* ranking players<br />
* guilds<br />
* official tournaments<br />
* titles for players<br />
* metaservers<br />
<br />
The scalability of the project, both in term of number of players, and in term of the possibility for players and developers to extend the concept will be a valued criteria<br />
<br />
Administration/moderation problems and techniques should also be studied<br />
<br />
interaction with the Add-On server/forum might be an interesting field to expand to<br />
<br />
==== Required knowledge and talent ====<br />
<br />
* A fair amount of experience on C++ is required. Wesnoth uses some advanced C++ features and is heavily based on BOOST and STL. We can train you in some of the libraries used, but learning all of them would be a big hurdle<br />
* Various experience with multiplayer games, in order to have a good idea of what multiplayer lobbies of other game look like, and (more importantly) a good idea of the social behaviours of multiple MP communities, how teams are formed in games and things like that<br />
<br />
==== Milestones and deliverables ====<br />
<br />
* A first milestone would be a presentation summarizing the different studies, and the proposed interface. preliminary informal stages would probably be desirable, to make sure the proposed idea is already a consensus within devs <br />
** Study of other MP game-matching interfaces and functionalities<br />
** Study of other MP communities<br />
** Study of other MP moderation practices<br />
** Study of the Wesnoth MP community, including needs, various opinons from different developers and players<br />
* A second milestone would be the main code delivery. Code should be functional for it will be delivered in the next Wesnoth development release<br />
<br />
=== Other ideas to be fleshed out ===<br />
* Working on the GUI engine (needs to be defined more precisely)<br />
* Rewrite of the campaign (add-on) server<br />
* The editor can use quite a revamp<br />
* A good scenario editor. We have campgen but it hasn't been updated for a while.<br />
<br />
<br />
== Other info to provide for GSoC ==<br />
==== Describe your organization. ====<br />
<br />
==== Why is your organization applying to participate in GSoC 2008? What do you hope to gain by participating?====<br />
<br />
Most of our developers have interesting areas in which they work. Though they are efficient in their areas, there are areas that are interesting but have a high barrier of entry.<br />
<br />
By having a student dedicated to any of these areas, we could quickly get someone up to date with that particular area, efficient, and responsible of this area.<br />
<br />
Basically, by getting new people in and making them actively responsible for an area of code we hope to kickstart some areas of the project that have lagged behind<br />
<br />
==== Did your organization participate in past GSoCs? If so, please summarize your involvement and the successes and challenges of your participation.====<br />
This is the first time the Wesnoth projects applies to Google SoC<br />
<br />
==== If your organization has not previously participated in GSoC, have you applied in the past? If so, for what year(s)?====<br />
<br />
This is the first time the Wesnoth projects applies to Google SoC<br />
<br />
==== Who will your organization administrator be? Please include Google Account information.====<br />
Nils Kneuper aka Ivanovic<br />
<br />
crazy.ivanovic |ATTT| googlemail.com<br />
<br />
==== What license(s) does your project use?====<br />
Our project is entirely GPL.<br />
<br />
All code is GPL.<br />
<br />
All art is GPL, 99% was made for the project, everything was taken from content that was checked to be GPL.<br />
<br />
==== What is the URL for your ideas page?====<br />
Our main summer of code pages is located at http://www.wesnoth.org/wiki/SummerOfCodeIdeas<br />
<br />
This page contains various coding ideas and the thought the development team has already given them.<br />
<br />
It also contains a list of the developers that are the most active on IRC and their domain of interest.<br />
<br />
==== What is the main development mailing list or forum for your organization?====<br />
Most development work takes place on "wesnoth-dev |ATTT| gna.org". Beside this some work happens at http://www.wesnoth.org/forum/.<br />
<br />
==== What is the main IRC channel for your organization?====<br />
<br />
All our IRC channels are on the ''freenode'' network<br />
<br />
* ''#wesnoth-dev'' is the main development channel, where most discussion takes place<br />
* ''#wesnoth'' is a generic channel for the community<br />
* ''#wesnoth-mp'' is a separate channel for multiplayer games and balancing<br />
<br />
==== Does your organization have an application template you would like to see students use? If so, please provide it now.====<br />
We plan mainly to meet potential students through our IRC channel, but the following questions are wesnoth-specific and are worth pondering for any student, even if we don't need a formal answer<br />
<br />
* What type of gamer are you? What type of games? What type of opponent? Are you more interested in story or gameplay ? <br />
* Are you good at interacting with other players ? Our developer community is quite nice, but the player community can be a bit rough.<br />
* Do you give constructive advices? Do you receive advice well? Are you good at sorting useful criticism from useless ones?<br />
<br />
''''to be completed''''<br />
<br />
==== Who will be your backup organization administrator? Please include Google Account information.====<br />
<br />
Jeremy Rosen alias Boucman<br />
<br />
boucman2@gmail.com<br />
<br />
==== Who will your mentors be? Please include Google Account information.====<br />
<br />
==== What criteria did you use to select these individuals as mentors? Please be as specific as possible.====<br />
<br />
==== What is your plan for dealing with disappearing students?====<br />
<br />
==== What is your plan for dealing with disappearing mentors?====<br />
<br />
==== What steps will you take to encourage students to interact with your project's community before, during and after the program?====<br />
<br />
Wesnoth has a particularly healthy community, both for developers and for players. <br />
<br />
Our general policy regarding new coders has always been "two patch... you're in" In other word, anybody that is able to get two non-trivial patches applied is offered commit right.<br />
<br />
We have a developer responsible for applying patches and guiding new developers into our community. This is a well known and effective process we plan to apply to students, directing them to our [[EasyCoding]] pages (these project are usually a couple of hours long and has been chosen to provide easy access to code)<br />
<br />
Usually, patches go back and forth a couple of time, to make sure that all secondary things are in place (indenting, coding style, modified makefiles etc.) The idea is that coder education should take place before the coder gets commit rights, but that getting new coder in is one of the most important things to maintain our project alive.<br />
<br />
If the student is a little proactive and ready to join IRC, all the developers are usually very welcoming, and good at directing newcomers to quickly give useful results.<br />
<br />
'''to be completed'''<br />
<br />
==== What will you do to ensure that your accepted students stick with the project after GSoC concludes?====<br />
<br />
<br />
<br />
=== People to bug on IRC, possible mentors ===<br />
Everybody feel free to edit/correct his entry!<br />
<br />
==== Dave alias Sirp ====<br />
<br />
Sirp started Wesnoth and is our lead developper. He is currently our C++ expert and is also the one that is working on the new Formula AI. Any questions regarding the formula AI should be directed to him.<br />
<br />
==== Mordante ====<br />
Many of the possible projects do at least partly go into the area of code where he knows most of. Plus many of the possible projects currently listed on the ideas page do require GUI parts to work, too. So if Mordante wants to tackle a rewrite of large parts of this, he will be our expert there as well as he already is our expert for the terrain engine (cf. editor / scenario editor works).<br />
<br />
==== Elias Pscherning (elias) ====<br />
He has written the original version of campgen and as such will know a lot about what is needed to to make such an editor work correctly. The work on a scenario editor might be based upon campgen and as such make his knowledge really helpful.<br />
<br />
==== Karol Nowak (grzywacz) ====<br />
Last year he was participating at GSoC as a student, so he knows at least this side of the medal. Beside this he is our top expert regarding embedded devices support since he is actively working on the gp2x support.<br />
<br />
==== boucman ====<br />
As our "patch monkey" he has valuable knowledge in comments and critics for patches of every kind. Beside this he knows many areas of the game due to working on applying patches. He is particularly used to answer question from new coders, and doesn't mind explaining trivial stuff.<br />
<br />
If you want to have a feeling of the developer spirit, it is recommended to go to our [[EasyCoding]] page.<br />
<br />
==== Soliton ====<br />
He does know our mp server setup best. Beside this he already has done a lot of work on the mp server himself, too. So he probably has most knowledge about it and due to being one of our mp-developers might provide important help from the perspective of mp-community and what is needed there.<br />
<br />
==== zookeeper or Mythological or Rhuaven ====<br />
As our leading WML expert it would be good to have him in the list when it comes to WML specific problems. That is for work on the scenario editor he probably knows best what should be implemented in it and what is a usable way for things.<br />
<br />
==== YogiHH or Piotr Cychowski (cycholka) ====<br />
Since they are the two developers who know most about building under Windows, they will probably be really helpful. Either if the student comes from the Windows side, or to help test resulting work to make sure that it does work on Windows and, for the case that it does not, to show them where problems are.</div>Grzywaczhttps://wiki.wesnoth.org/index.php?title=SummerOfCodeIdeas&diff=22900SummerOfCodeIdeas2008-02-27T20:55:34Z<p>Grzywacz: Typo fixes</p>
<hr />
<div>== Ideas for Google Summer of Code projects ==<br />
<br />
This is a compilation of ideas from ML. Needs to be refined (more detailed description, deliverables, workload estimation?):<br />
<br />
== List of Ideas for the Project ==<br />
<br />
=== Writing an AI based on the formula AI ===<br />
<br />
Wesnoth has always had a simple C++ based AI. David (our lead developer) has been working on a simple language to write AI in wesnoth ''link to formula AI page here'' <br />
<br />
The wesnoth AI is used as an oponent in most campaigns, and as such is an important piece of code for the wesnoth project. Unfortunately it is also one of the most neglected piece of code and a place where a lot of research and work could be done<br />
<br />
==== General description ====<br />
<br />
The aim of this project is to develop a new AI that would replace the original C++ AI. The main criterias we would want for this new AI are<br />
<br />
* ''Plugability :'' It should be trivial for any content maker to change the behavior of the AI in specific case. The exact cases are still to be defined but should typically include<br />
** hardwiring the first few turns of the AI<br />
** changing the recruitment pattern<br />
** completely controlling a given unit (sceneario unit)<br />
** taking control then giving back control of a given unit<br />
* ''tunability :'' It should be easy for a scenario author to specify the general behaviour of the ennemy on a given scenario (agressivity, intrepidity...)<br />
* ''specific behaviours :'' there are some typical behaviours that are not smart to win the scenario but are needed, such as guarding a given unit, a given position, wandering aimlessly, attacking randomly, always fleeing. The AI should implement such behaviours, and allow easy addition of new behaviours<br />
<br />
==== Required knowledge and talent ====<br />
<br />
* ''A minimal knowledge of C++ is required, a good knowledge of C++ is desired :'' The formula AI framework is a work in progress and chances are high that some changes in the wesnoth code base will be needed. The wesnoth developer community is used to handle people that are familiar with coding but not C++, however the Formula AI framework uses advanced C++ features and a good knowledge of the language would avoid a major hurdle when plugging in new entries or functionalities for the AI<br />
* ''Good social interaction with a large player community :'' A preliminary phase to coding any AI is to know the strategies and game pattern used by human players. This requires huge interaction with the player community. Our Gameplay Developers are open and can give some good starting points, but a big game experience and good interaction with the player community will greatly help in the study of the design<br />
<br />
==== Milestones and deliverables ====<br />
<br />
It is hard to give milestones at this point, but here are some ideas of what could be done<br />
<br />
* ''AI design description, and basic function library :'' This first deliverable aims to conclude the '''study and analysis''' part of the project : becoming familiar with the formula language, study of multiplayer strategies and of the need of scenario writers with regard to AI. We would like to have a description of the code structure of the AI, some basis of the play strategies it would use and how external scenario writers could configure it for the particular behaviour they need<br />
* ''Main AI delivery :'' This milestone's aim is to deliver a working AI implementing the strategies described in the first phase. It would not have to systematically beat the standard C++ AI at this point, but should be able to play the game correctly (recruit, early deployment on villages, grouping units to attack, holding its ground, protecting weak/important units). Moreover most plug-in entries should be available and a test-case for these entries should be provided.<br />
* ''Fine tunning and behaviour library :'' The third phase would validate the actual strategy of the AI. The AI should consistently beat the default C++ AI, and do fairly well against an average human player. At that stage a library of scenario behaviours should also be delivered. The AI does not need to be as efficient with all scenario tweaking, but should act correctly with regard to the particular behaviour desired.<br />
<br />
=== Extending the Multiplayer server ===<br />
<br />
When the development team met at FOSDEM, we had our multiplayer community, though it is strong and healthy, had its growth restrained by the interface of the multiplayer lobby.<br />
<br />
==== General Description ====<br />
The general idea of this project would be<br />
* To study the current lobby,<br />
* To present some ideas of evolutions both in interface and functionalities of our multiplayer interface to allow it to scale to a much larger community<br />
* To present some well constructed thought on our MP community and how that interface would develop it<br />
* Of course to implement those changes :)<br />
<br />
Some ideas that we had (but that are in no way mandatory)<br />
* Having a simple way to register and authenticate nicknames, similar to what IRC offers. The point is not to have cryptographically safe logins, but to have something simple that gets the job done<br />
* Having a simple room system? again inspired on IRC<br />
* Having some way to find the type of games you are interested in.<br />
** game type<br />
** number of free slots/players<br />
** any other criteria you might find interesting<br />
<br />
Other ideas we are not convinced are good, but that are certainly worth studying (especially how the communities based around these concepts are different from ours)<br />
* ranking players<br />
* guilds<br />
* official tournaments<br />
* titles for players<br />
* metaservers<br />
<br />
The scalability of the project, both in term of number of players, and in term of the possibility for players and developers to extend the concept will be a valued criteria<br />
<br />
Administration/moderation problems and techniques should also be studied<br />
<br />
interaction with the Add-On server/forum might be an interesting field to expand to<br />
<br />
==== Required knowledge and talent ====<br />
<br />
* A fair amount of experience on C++ is required. Wesnoth uses some advanced C++ features and is heavily based on BOOST and STL. We can train you in some of the libraries used, but learning all of them would be a big hurdle<br />
* Various experience with multiplayer games, in order to have a good idea of what multiplayer lobbies of other game look like, and (more importantly) a good idea of the social behaviours of multiple MP communities, how teams are formed in games and things like that<br />
<br />
==== Milestones and deliverables ====<br />
<br />
* A first milestone would be a presentation summarizing the different studies, and the proposed interface. preliminary informal stages would probably be desirable, to make sure the proposed idea is already a consensus within devs <br />
** Study of other MP game-matching interfaces and functionalities<br />
** Study of other MP communities<br />
** Study of other MP moderation practices<br />
** Study of the Wesnoth MP community, including needs, various opinons from different developers and players<br />
* A second milestone would be the main code delivery. Code should be functional for it will be delivered in the next Wesnoth development release<br />
<br />
=== Other ideas to be fleshed out ===<br />
* Working on the GUI engine (needs to be defined more precisely)<br />
* Rewrite of the campaign (add-on) server<br />
* The editor can use quite a revamp<br />
* A good scenario editor. We have campgen but it hasn't been updated for a while.<br />
<br />
<br />
== Other info to provide for GSoC ==<br />
==== Describe your organization. ====<br />
<br />
==== Why is your organization applying to participate in GSoC 2008? What do you hope to gain by participating?====<br />
<br />
Most of our developers have interesting areas in which they work. Though they are efficient in their areas, there are areas that are interesting but have a high barrier of entry.<br />
<br />
By having a student dedicated to any of these areas, we could quickly get someone up to date with that particular area, efficient, and responsible of this area.<br />
<br />
Basically, by getting new people in and making them actively responsible for an area of code we hope to kickstart some areas of the project that have lagged behind<br />
<br />
==== Did your organization participate in past GSoCs? If so, please summarize your involvement and the successes and challenges of your participation.====<br />
This is the first time the Wesnoth projects applies to Google SoC<br />
<br />
==== If your organization has not previously participated in GSoC, have you applied in the past? If so, for what year(s)?====<br />
<br />
This is the first time the Wesnoth projects applies to Google SoC<br />
<br />
==== Who will your organization administrator be? Please include Google Account information.====<br />
Nils Kneuper aka Ivanovic<br />
<br />
crazy.ivanovic |ATTT| googlemail.com<br />
<br />
==== What license(s) does your project use?====<br />
Our project is entirely GPL.<br />
<br />
All code is GPL.<br />
<br />
All art is GPL, 99% was made for the project, everything was taken from content that was checked to be GPL.<br />
<br />
==== What is the URL for your ideas page?====<br />
Our main summer of code pages is located at http://www.wesnoth.org/wiki/SummerOfCodeIdeas<br />
<br />
This page contains various coding ideas and the thought the development team has already given them.<br />
<br />
It also contains a list of the developers that are the most active on IRC and their domain of interest.<br />
<br />
==== What is the main development mailing list or forum for your organization?====<br />
Most development work takes place on "wesnoth-dev |ATTT| gna.org". Beside this some work happens at http://www.wesnoth.org/forum/.<br />
<br />
==== What is the main IRC channel for your organization?====<br />
<br />
All our IRC channels are on the ''freenode'' network<br />
<br />
* ''#wesnoth-dev'' is the main development channel, where most discussion takes place<br />
* ''#wesnoth'' is a generic channel for the community<br />
* ''#wesnoth-mp'' is a separate channel for multiplayer games and balancing<br />
<br />
==== Does your organization have an application template you would like to see students use? If so, please provide it now.====<br />
We plan mainly to meet potential students through our IRC channel, but the following questions are wesnoth-specific and are worth pondering for any student, even if we don't need a formal answer<br />
<br />
* What type of gamer are you? What type of games? What type of opponent? Are you more interested in story or gameplay ? <br />
* Are you good at interacting with other players ? Our developer community is quite nice, but the player community can be a bit rough.<br />
* Do you give constructive advices? Do you receive advice well? Are you good at sorting useful criticism from useless ones?<br />
<br />
''''to be completed''''<br />
<br />
==== Who will be your backup organization administrator? Please include Google Account information.====<br />
<br />
Jeremy Rosen alias Boucman<br />
<br />
boucman2@gmail.com<br />
<br />
==== Who will your mentors be? Please include Google Account information.====<br />
<br />
==== What criteria did you use to select these individuals as mentors? Please be as specific as possible.====<br />
<br />
==== What is your plan for dealing with disappearing students?====<br />
<br />
==== What is your plan for dealing with disappearing mentors?====<br />
<br />
==== What steps will you take to encourage students to interact with your project's community before, during and after the program?====<br />
<br />
Wesnoth has a particularly healthy community, both for developers and for players. <br />
<br />
Our general policy regarding new coders has always been "two patch... you're in" In other word, anybody that is able to get two non-trivial patches applied is offered commit right.<br />
<br />
We have a developer responsible for applying patches and guiding new developers into our community. This is a well known and effective process we plan to apply to students, directing them to our [[EasyCoding]] pages (these project are usually a couple of hours long and has been chosen to provide easy access to code)<br />
<br />
Usually, patches go back and forth a couple of time, to make sure that all secondary things are in place (indenting, coding style, modified makefiles etc.) The idea is that coder education should take place before the coder gets commit rights, but that getting new coder in is one of the most important things to maintain our project alive.<br />
<br />
If the student is a little proactive and ready to join IRC, all the developers are usually very welcoming, and good at directing newcomers to quickly give useful results.<br />
<br />
'''to be completed'''<br />
<br />
==== What will you do to ensure that your accepted students stick with the project after GSoC concludes?====<br />
<br />
<br />
<br />
=== People to bug on IRC, possible mentors ===<br />
Everybody feel free to edit/correct his entry!<br />
<br />
==== Dave alias Sirp ====<br />
<br />
Sirp started Wesnoth and is our lead developper. He is currently our C++ expert and is also the one that is working on the new Formula AI. Any questions regarding the formula AI should be directed to him.<br />
<br />
==== Mordante ====<br />
Many of the possible projects do at least partly go into the area of code where he knows most of. Plus many of the possible projects currently listed on the ideas page do require GUI parts to work, too. So if Mordante wants to tackle a rewrite of large parts of this, he will be our expert there as well as he already is our expert for the terrain engine (cf. editor / scenario editor works).<br />
<br />
==== Elias Pscherning (elias) ====<br />
He has written the original version of campgen and as such will know a lot about what is needed to to make such an editor work correctly. The work on a scenario editor might be based upon campgen and as such make his knowledge really helpful.<br />
<br />
==== Karol Nowak (grzywacz) ====<br />
Last year he was participating at GSoC as a student, so he knows at least this side of the medal. Beside this he is our top expert regarding embedded devices support since he is actively working on the gp2x support.<br />
<br />
==== boucman ====<br />
As our "patch monkey" he has valuable knowledge in comments and critics for patches of every kind. Beside this he knows many areas of the game due to working on applying patches. He is particularly used to answer question from new coders, and doesn't mind explaining trivial stuff.<br />
<br />
If you want to have a feeling of the developer spirit, it is recommended to go to our [[EasyCoding]] page.<br />
<br />
==== Soliton ====<br />
He does know our mp server setup best. Beside this he already has done a lot of work on the mp server himself, too. So he probably has most knowledge about it and due to being one of our mp-developers might provide important help from the perspective of mp-community and what is needed there.<br />
<br />
==== zookeeper or Mythological or Rhuaven ====<br />
As our leading WML expert it would be good to have him in the list when it comes to WML specific problems. That is for work on the scenario editor he probably knows best what should be implemented in it and what is a usable way for things.<br />
<br />
==== YogiHH or Piotr Cychowski (cycholka) ====<br />
Since they are the two developers who know most about building under Windows, they will probably be really helpful. Either if the student comes from the Windows side, or to help test resulting work to make sure that it does work on Windows and, for the case that it does not, to show them where problems are.</div>Grzywaczhttps://wiki.wesnoth.org/index.php?title=SummerOfCodeIdeas&diff=22899SummerOfCodeIdeas2008-02-27T20:55:05Z<p>Grzywacz: Typo fixes</p>
<hr />
<div>== Ideas for Google Summer of Code projects ==<br />
<br />
This is a compilation of ideas from ML. Needs to be refined (more detailed description, deliverables, workload estimation?):<br />
<br />
== List of Ideas for the Project ==<br />
<br />
=== Writing an AI based on the formula AI ===<br />
<br />
Wesnoth has always had a simple C++ based AI. David (our lead developer) has been working on a simple language to write AI in wesnoth ''link to formula AI page here'' <br />
<br />
The wesnoth AI is used as an oponent in most campaigns, and as such is an important piece of code for the wesnoth project. Unfortunately it is also one of the most neglected piece of code and a place where a lot of research and work could be done<br />
<br />
==== General description ====<br />
<br />
The aim of this project is to develop a new AI that would replace the original C++ AI. The main criterias we would want for this new AI are<br />
<br />
* ''Plugability :'' It should be trivial for any content maker to change the behavior of the AI in specific case. The exact cases are still to be defined but should typically include<br />
** hardwiring the first few turns of the AI<br />
** changing the recruitment pattern<br />
** completely controlling a given unit (sceneario unit)<br />
** taking control then giving back control of a given unit<br />
* ''tunability :'' It should be easy for a scenario author to specify the general behaviour of the ennemy on a given scenario (agressivity, intrepidity...)<br />
* ''specific behaviours :'' there are some typical behaviours that are not smart to win the scenario but are needed, such as guarding a given unit, a given position, wandering aimlessly, attacking randomly, always fleeing. The AI should implement such behaviours, and allow easy addition of new behaviours<br />
<br />
==== Required knowledge and talent ====<br />
<br />
* ''A minimal knowledge of C++ is required, a good knowledge of C++ is desired :'' The formula AI framework is a work in progress and chances are high that some changes in the wesnoth code base will be needed. The wesnoth developper community is used to handle people that are familiar with coding but not C++, however the Forumla AI framework uses advanced C++ features and a good knowledge of the language would avoid a major hurdle when plugging in new entries or functionalities for the AI<br />
* ''Good social interaction with a large player community :'' A preliminary phase to coding any AI is to know the strategies and game pattern used by human players. This requires huge interaction with the player community. Our Gameplay Developpers are open and can give some good starting points, but a big game experience and good interaction with the player community will greatly help in the study of the design<br />
<br />
==== Milestones and deliverables ====<br />
<br />
It is hard to give milestones at this point, but here are some ideas of what could be done<br />
<br />
* ''AI design description, and basic function library :'' This first deliverable aims to conclude the '''study and analysis''' part of the project : becoming familiar with the formula language, study of multiplayer strategies and of the need of scenario writers with regard to AI. We would like to have a description of the code structure of the AI, some basis of the play strategies it would use and how external scenario writers could configure it for the particular behaviour they need<br />
* ''Main AI delivery :'' This milestone's aim is to deliver a working AI implementing the strategies described in the first phase. It would not have to systematically beat the standard C++ AI at this point, but should be able to play the game correctly (recruit, early deployment on villages, grouping units to attack, holding its ground, protecting weak/important units). Moreover most plug-in entries should be available and a test-case for these entries should be provided.<br />
* ''Fine tunning and behaviour library :'' The third phase would validate the actual strategy of the AI. The AI should consistently beat the default C++ AI, and do fairly well against an average human player. At that stage a library of scenario behaviours should also be delivered. The AI does not need to be as efficient with all scenario tweaking, but should act correctly with regard to the particular behaviour desired.<br />
<br />
=== Extending the Multiplayer server ===<br />
<br />
When the development team met at FOSDEM, we had our multiplayer community, though it is strong and healthy, had its growth restrained by the interface of the multiplayer lobby.<br />
<br />
==== General Description ====<br />
The general idea of this project would be<br />
* To study the current lobby,<br />
* To present some ideas of evolutions both in interface and functionalities of our multiplayer interface to allow it to scale to a much larger community<br />
* To present some well constructed thought on our MP community and how that interface would develop it<br />
* Of course to implement those changes :)<br />
<br />
Some ideas that we had (but that are in no way mandatory)<br />
* Having a simple way to register and authenticate nicknames, similar to what IRC offers. The point is not to have cryptographically safe logins, but to have something simple that gets the job done<br />
* Having a simple room system? again inspired on IRC<br />
* Having some way to find the type of games you are interested in.<br />
** game type<br />
** number of free slots/players<br />
** any other criteria you might find interesting<br />
<br />
Other ideas we are not convinced are good, but that are certainly worth studying (especially how the communities based around these concepts are different from ours)<br />
* ranking players<br />
* guilds<br />
* official tournaments<br />
* titles for players<br />
* metaservers<br />
<br />
The scalability of the project, both in term of number of players, and in term of the possibility for players and developers to extend the concept will be a valued criteria<br />
<br />
Administration/moderation problems and techniques should also be studied<br />
<br />
interaction with the Add-On server/forum might be an interesting field to expand to<br />
<br />
==== Required knowledge and talent ====<br />
<br />
* A fair amount of experience on C++ is required. Wesnoth uses some advanced C++ features and is heavily based on BOOST and STL. We can train you in some of the libraries used, but learning all of them would be a big hurdle<br />
* Various experience with multiplayer games, in order to have a good idea of what multiplayer lobbies of other game look like, and (more importantly) a good idea of the social behaviours of multiple MP communities, how teams are formed in games and things like that<br />
<br />
==== Milestones and deliverables ====<br />
<br />
* A first milestone would be a presentation summarizing the different studies, and the proposed interface. preliminary informal stages would probably be desirable, to make sure the proposed idea is already a consensus within devs <br />
** Study of other MP game-matching interfaces and functionalities<br />
** Study of other MP communities<br />
** Study of other MP moderation practices<br />
** Study of the Wesnoth MP community, including needs, various opinons from different developers and players<br />
* A second milestone would be the main code delivery. Code should be functional for it will be delivered in the next Wesnoth development release<br />
<br />
=== Other ideas to be fleshed out ===<br />
* Working on the GUI engine (needs to be defined more precisely)<br />
* Rewrite of the campaign (add-on) server<br />
* The editor can use quite a revamp<br />
* A good scenario editor. We have campgen but it hasn't been updated for a while.<br />
<br />
<br />
== Other info to provide for GSoC ==<br />
==== Describe your organization. ====<br />
<br />
==== Why is your organization applying to participate in GSoC 2008? What do you hope to gain by participating?====<br />
<br />
Most of our developers have interesting areas in which they work. Though they are efficient in their areas, there are areas that are interesting but have a high barrier of entry.<br />
<br />
By having a student dedicated to any of these areas, we could quickly get someone up to date with that particular area, efficient, and responsible of this area.<br />
<br />
Basically, by getting new people in and making them actively responsible for an area of code we hope to kickstart some areas of the project that have lagged behind<br />
<br />
==== Did your organization participate in past GSoCs? If so, please summarize your involvement and the successes and challenges of your participation.====<br />
This is the first time the Wesnoth projects applies to Google SoC<br />
<br />
==== If your organization has not previously participated in GSoC, have you applied in the past? If so, for what year(s)?====<br />
<br />
This is the first time the Wesnoth projects applies to Google SoC<br />
<br />
==== Who will your organization administrator be? Please include Google Account information.====<br />
Nils Kneuper aka Ivanovic<br />
<br />
crazy.ivanovic |ATTT| googlemail.com<br />
<br />
==== What license(s) does your project use?====<br />
Our project is entirely GPL.<br />
<br />
All code is GPL.<br />
<br />
All art is GPL, 99% was made for the project, everything was taken from content that was checked to be GPL.<br />
<br />
==== What is the URL for your ideas page?====<br />
Our main summer of code pages is located at http://www.wesnoth.org/wiki/SummerOfCodeIdeas<br />
<br />
This page contains various coding ideas and the thought the development team has already given them.<br />
<br />
It also contains a list of the developers that are the most active on IRC and their domain of interest.<br />
<br />
==== What is the main development mailing list or forum for your organization?====<br />
Most development work takes place on "wesnoth-dev |ATTT| gna.org". Beside this some work happens at http://www.wesnoth.org/forum/.<br />
<br />
==== What is the main IRC channel for your organization?====<br />
<br />
All our IRC channels are on the ''freenode'' network<br />
<br />
* ''#wesnoth-dev'' is the main development channel, where most discussion takes place<br />
* ''#wesnoth'' is a generic channel for the community<br />
* ''#wesnoth-mp'' is a separate channel for multiplayer games and balancing<br />
<br />
==== Does your organization have an application template you would like to see students use? If so, please provide it now.====<br />
We plan mainly to meet potential students through our IRC channel, but the following questions are wesnoth-specific and are worth pondering for any student, even if we don't need a formal answer<br />
<br />
* What type of gamer are you? What type of games? What type of opponent? Are you more interested in story or gameplay ? <br />
* Are you good at interacting with other players ? Our developer community is quite nice, but the player community can be a bit rough.<br />
* Do you give constructive advices? Do you receive advice well? Are you good at sorting useful criticism from useless ones?<br />
<br />
''''to be completed''''<br />
<br />
==== Who will be your backup organization administrator? Please include Google Account information.====<br />
<br />
Jeremy Rosen alias Boucman<br />
<br />
boucman2@gmail.com<br />
<br />
==== Who will your mentors be? Please include Google Account information.====<br />
<br />
==== What criteria did you use to select these individuals as mentors? Please be as specific as possible.====<br />
<br />
==== What is your plan for dealing with disappearing students?====<br />
<br />
==== What is your plan for dealing with disappearing mentors?====<br />
<br />
==== What steps will you take to encourage students to interact with your project's community before, during and after the program?====<br />
<br />
Wesnoth has a particularly healthy community, both for developers and for players. <br />
<br />
Our general policy regarding new coders has always been "two patch... you're in" In other word, anybody that is able to get two non-trivial patches applied is offered commit right.<br />
<br />
We have a developer responsible for applying patches and guiding new developers into our community. This is a well known and effective process we plan to apply to students, directing them to our [[EasyCoding]] pages (these project are usually a couple of hours long and has been chosen to provide easy access to code)<br />
<br />
Usually, patches go back and forth a couple of time, to make sure that all secondary things are in place (indenting, coding style, modified makefiles etc.) The idea is that coder education should take place before the coder gets commit rights, but that getting new coder in is one of the most important things to maintain our project alive.<br />
<br />
If the student is a little proactive and ready to join IRC, all the developers are usually very welcoming, and good at directing newcomers to quickly give useful results.<br />
<br />
'''to be completed'''<br />
<br />
==== What will you do to ensure that your accepted students stick with the project after GSoC concludes?====<br />
<br />
<br />
<br />
=== People to bug on IRC, possible mentors ===<br />
Everybody feel free to edit/correct his entry!<br />
<br />
==== Dave alias Sirp ====<br />
<br />
Sirp started Wesnoth and is our lead developper. He is currently our C++ expert and is also the one that is working on the new Formula AI. Any questions regarding the formula AI should be directed to him.<br />
<br />
==== Mordante ====<br />
Many of the possible projects do at least partly go into the area of code where he knows most of. Plus many of the possible projects currently listed on the ideas page do require GUI parts to work, too. So if Mordante wants to tackle a rewrite of large parts of this, he will be our expert there as well as he already is our expert for the terrain engine (cf. editor / scenario editor works).<br />
<br />
==== Elias Pscherning (elias) ====<br />
He has written the original version of campgen and as such will know a lot about what is needed to to make such an editor work correctly. The work on a scenario editor might be based upon campgen and as such make his knowledge really helpful.<br />
<br />
==== Karol Nowak (grzywacz) ====<br />
Last year he was participating at GSoC as a student, so he knows at least this side of the medal. Beside this he is our top expert regarding embedded devices support since he is actively working on the gp2x support.<br />
<br />
==== boucman ====<br />
As our "patch monkey" he has valuable knowledge in comments and critics for patches of every kind. Beside this he knows many areas of the game due to working on applying patches. He is particularly used to answer question from new coders, and doesn't mind explaining trivial stuff.<br />
<br />
If you want to have a feeling of the developer spirit, it is recommended to go to our [[EasyCoding]] page.<br />
<br />
==== Soliton ====<br />
He does know our mp server setup best. Beside this he already has done a lot of work on the mp server himself, too. So he probably has most knowledge about it and due to being one of our mp-developers might provide important help from the perspective of mp-community and what is needed there.<br />
<br />
==== zookeeper or Mythological or Rhuaven ====<br />
As our leading WML expert it would be good to have him in the list when it comes to WML specific problems. That is for work on the scenario editor he probably knows best what should be implemented in it and what is a usable way for things.<br />
<br />
==== YogiHH or Piotr Cychowski (cycholka) ====<br />
Since they are the two developers who know most about building under Windows, they will probably be really helpful. Either if the student comes from the Windows side, or to help test resulting work to make sure that it does work on Windows and, for the case that it does not, to show them where problems are.</div>Grzywaczhttps://wiki.wesnoth.org/index.php?title=SummerOfCodeIdeas&diff=22898SummerOfCodeIdeas2008-02-27T20:54:32Z<p>Grzywacz: Typo fixes</p>
<hr />
<div>== Ideas for Google Summer of Code projects ==<br />
<br />
This is a compilation of ideas from ML. Needs to be refined (more detailed description, deliverables, workload estimation?):<br />
<br />
== List of Ideas for the Project ==<br />
<br />
=== Writing an AI based on the formula AI ===<br />
<br />
Wesnoth has always had a simple C++ based AI. David (our lead developer) has been working on a simple language to write AI in wesnoth ''link to formula AI page here'' <br />
<br />
The wesnoth AI is used as an oponent in most campaigns, and as such is an important piece of code for the wesnoth project. Unfortunately it is also one of the most neglected piece of code and a place where a lot of research and work could be done<br />
<br />
==== General description ====<br />
<br />
The aim of this project is to develop a new AI that would replace the original C++ AI. The main criterias we would want for this new AI are<br />
<br />
* ''Plugability :'' It should be trivial for any content maker to change the behavior of the AI in specific case. The exact cases are still to be defined but should typically include<br />
** hardwiring the first few turns of the AI<br />
** changing the recruitment pattern<br />
** completely controlling a given unit (sceneario unit)<br />
** taking control then giving back control of a given unit<br />
* ''tunability :'' It should be easy for a scenario author to specify the general behaviour of the ennemy on a given scenario (agressivity, intrepidity...)<br />
* ''specific behaviours :'' there are some typical behaviours that are not smart to win the scenario but are needed, such as guarding a given unit, a given position, wandering aimlessly, attacking randomly, always fleeing. The AI should implement such behaviours, and allow easy addition of new behaviours<br />
<br />
==== Required knowledge and talent ====<br />
<br />
* ''A minimal knowledge of C++ is required, a good knowledge of C++ is desired :'' The formula AI framework is a work in progress and chances are high that some changes in the wesnoth code base will be needed. The wesnoth developper community is used to handle people that are familiar with coding but not C++, however the Forumla AI framework uses advanced C++ features and a good knowledge of the language would avoid a major hurdle when plugging in new entries or functionalities for the AI<br />
* ''Good social interaction with a large player community :'' A preliminary phase to coding any AI is to know the strategies and game pattern used by human players. This requires huge interaction with the player community. Our Gameplay Developpers are open and can give some good starting points, but a big game experience and good interaction with the player community will greatly help in the study of the design<br />
<br />
==== Milestones and deliverables ====<br />
<br />
It is hard to give milestones at this point, but here are some ideas of what could be done<br />
<br />
* ''AI design description, and basic function library :'' This first deliverable aims to conclude the '''study and analysis''' part of the project : becoming familiar with the formula language, study of the Multiplayer strategies and of the need of scenario writers with regard to AI. We would like to have a description of the code structure of the AI, some basis of the play strategies it would use and how external scenario writers could configure it for the particular behaviour they need<br />
* ''Main AI delivery :'' This milestone's aim is to deliver a working AI implementing the strategies described in the first phase. It would not have to systematically beat the standard C++ AI at this point, but should be able to play the game correctly (recruit, early deployment on villages, grouping units to attack, holding its ground, protecting weak/important units). Moreover most plug-in entries should be available and a test-case for these entries should be provided.<br />
* ''Fine tunning and behaviour library :'' The third phase would validate the actual strategy of the AI. The AI should consistently beat the default C++ AI, and do fairly well against an average human player. At that stage a library of scenario behaviours should also be delivered. The AI does not need to be as efficiant with all scenario tweaking, but should act correctly with regard to the particular behaviour desired.<br />
<br />
<br />
=== Extending the Multiplayer server ===<br />
<br />
When the development team met at FOSDEM, we had our multiplayer community, though it is strong and healthy, had its growth restrained by the interface of the multiplayer lobby.<br />
<br />
==== General Description ====<br />
The general idea of this project would be<br />
* To study the current lobby,<br />
* To present some ideas of evolutions both in interface and functionalities of our multiplayer interface to allow it to scale to a much larger community<br />
* To present some well constructed thought on our MP community and how that interface would develop it<br />
* Of course to implement those changes :)<br />
<br />
Some ideas that we had (but that are in no way mandatory)<br />
* Having a simple way to register and authenticate nicknames, similar to what IRC offers. The point is not to have cryptographically safe logins, but to have something simple that gets the job done<br />
* Having a simple room system? again inspired on IRC<br />
* Having some way to find the type of games you are interested in.<br />
** game type<br />
** number of free slots/players<br />
** any other criteria you might find interesting<br />
<br />
Other ideas we are not convinced are good, but that are certainly worth studying (especially how the communities based around these concepts are different from ours)<br />
* ranking players<br />
* guilds<br />
* official tournaments<br />
* titles for players<br />
* metaservers<br />
<br />
The scalability of the project, both in term of number of players, and in term of the possibility for players and developers to extend the concept will be a valued criteria<br />
<br />
Administration/moderation problems and techniques should also be studied<br />
<br />
interaction with the Add-On server/forum might be an interesting field to expand to<br />
<br />
==== Required knowledge and talent ====<br />
<br />
* A fair amount of experience on C++ is required. Wesnoth uses some advanced C++ features and is heavily based on BOOST and STL. We can train you in some of the libraries used, but learning all of them would be a big hurdle<br />
* Various experience with multiplayer games, in order to have a good idea of what multiplayer lobbies of other game look like, and (more importantly) a good idea of the social behaviours of multiple MP communities, how teams are formed in games and things like that<br />
<br />
==== Milestones and deliverables ====<br />
<br />
* A first milestone would be a presentation summarizing the different studies, and the proposed interface. preliminary informal stages would probably be desirable, to make sure the proposed idea is already a consensus within devs <br />
** Study of other MP game-matching interfaces and functionalities<br />
** Study of other MP communities<br />
** Study of other MP moderation practices<br />
** Study of the Wesnoth MP community, including needs, various opinons from different developers and players<br />
* A second milestone would be the main code delivery. Code should be functional for it will be delivered in the next Wesnoth development release<br />
<br />
=== Other ideas to be fleshed out ===<br />
* Working on the GUI engine (needs to be defined more precisely)<br />
* Rewrite of the campaign (add-on) server<br />
* The editor can use quite a revamp<br />
* A good scenario editor. We have campgen but it hasn't been updated for a while.<br />
<br />
<br />
== Other info to provide for GSoC ==<br />
==== Describe your organization. ====<br />
<br />
==== Why is your organization applying to participate in GSoC 2008? What do you hope to gain by participating?====<br />
<br />
Most of our developers have interesting areas in which they work. Though they are efficient in their areas, there are areas that are interesting but have a high barrier of entry.<br />
<br />
By having a student dedicated to any of these areas, we could quickly get someone up to date with that particular area, efficient, and responsible of this area.<br />
<br />
Basically, by getting new people in and making them actively responsible for an area of code we hope to kickstart some areas of the project that have lagged behind<br />
<br />
==== Did your organization participate in past GSoCs? If so, please summarize your involvement and the successes and challenges of your participation.====<br />
This is the first time the Wesnoth projects applies to Google SoC<br />
<br />
==== If your organization has not previously participated in GSoC, have you applied in the past? If so, for what year(s)?====<br />
<br />
This is the first time the Wesnoth projects applies to Google SoC<br />
<br />
==== Who will your organization administrator be? Please include Google Account information.====<br />
Nils Kneuper aka Ivanovic<br />
<br />
crazy.ivanovic |ATTT| googlemail.com<br />
<br />
==== What license(s) does your project use?====<br />
Our project is entirely GPL.<br />
<br />
All code is GPL.<br />
<br />
All art is GPL, 99% was made for the project, everything was taken from content that was checked to be GPL.<br />
<br />
==== What is the URL for your ideas page?====<br />
Our main summer of code pages is located at http://www.wesnoth.org/wiki/SummerOfCodeIdeas<br />
<br />
This page contains various coding ideas and the thought the development team has already given them.<br />
<br />
It also contains a list of the developers that are the most active on IRC and their domain of interest.<br />
<br />
==== What is the main development mailing list or forum for your organization?====<br />
Most development work takes place on "wesnoth-dev |ATTT| gna.org". Beside this some work happens at http://www.wesnoth.org/forum/.<br />
<br />
==== What is the main IRC channel for your organization?====<br />
<br />
All our IRC channels are on the ''freenode'' network<br />
<br />
* ''#wesnoth-dev'' is the main development channel, where most discussion takes place<br />
* ''#wesnoth'' is a generic channel for the community<br />
* ''#wesnoth-mp'' is a separate channel for multiplayer games and balancing<br />
<br />
==== Does your organization have an application template you would like to see students use? If so, please provide it now.====<br />
We plan mainly to meet potential students through our IRC channel, but the following questions are wesnoth-specific and are worth pondering for any student, even if we don't need a formal answer<br />
<br />
* What type of gamer are you? What type of games? What type of opponent? Are you more interested in story or gameplay ? <br />
* Are you good at interacting with other players ? Our developer community is quite nice, but the player community can be a bit rough.<br />
* Do you give constructive advices? Do you receive advice well? Are you good at sorting useful criticism from useless ones?<br />
<br />
''''to be completed''''<br />
<br />
==== Who will be your backup organization administrator? Please include Google Account information.====<br />
<br />
Jeremy Rosen alias Boucman<br />
<br />
boucman2@gmail.com<br />
<br />
==== Who will your mentors be? Please include Google Account information.====<br />
<br />
==== What criteria did you use to select these individuals as mentors? Please be as specific as possible.====<br />
<br />
==== What is your plan for dealing with disappearing students?====<br />
<br />
==== What is your plan for dealing with disappearing mentors?====<br />
<br />
==== What steps will you take to encourage students to interact with your project's community before, during and after the program?====<br />
<br />
Wesnoth has a particularly healthy community, both for developers and for players. <br />
<br />
Our general policy regarding new coders has always been "two patch... you're in" In other word, anybody that is able to get two non-trivial patches applied is offered commit right.<br />
<br />
We have a developer responsible for applying patches and guiding new developers into our community. This is a well known and effective process we plan to apply to students, directing them to our [[EasyCoding]] pages (these project are usually a couple of hours long and has been chosen to provide easy access to code)<br />
<br />
Usually, patches go back and forth a couple of time, to make sure that all secondary things are in place (indenting, coding style, modified makefiles etc.) The idea is that coder education should take place before the coder gets commit rights, but that getting new coder in is one of the most important things to maintain our project alive.<br />
<br />
If the student is a little proactive and ready to join IRC, all the developers are usually very welcoming, and good at directing newcomers to quickly give useful results.<br />
<br />
'''to be completed'''<br />
<br />
==== What will you do to ensure that your accepted students stick with the project after GSoC concludes?====<br />
<br />
<br />
<br />
=== People to bug on IRC, possible mentors ===<br />
Everybody feel free to edit/correct his entry!<br />
<br />
==== Dave alias Sirp ====<br />
<br />
Sirp started Wesnoth and is our lead developper. He is currently our C++ expert and is also the one that is working on the new Formula AI. Any questions regarding the formula AI should be directed to him.<br />
<br />
==== Mordante ====<br />
Many of the possible projects do at least partly go into the area of code where he knows most of. Plus many of the possible projects currently listed on the ideas page do require GUI parts to work, too. So if Mordante wants to tackle a rewrite of large parts of this, he will be our expert there as well as he already is our expert for the terrain engine (cf. editor / scenario editor works).<br />
<br />
==== Elias Pscherning (elias) ====<br />
He has written the original version of campgen and as such will know a lot about what is needed to to make such an editor work correctly. The work on a scenario editor might be based upon campgen and as such make his knowledge really helpful.<br />
<br />
==== Karol Nowak (grzywacz) ====<br />
Last year he was participating at GSoC as a student, so he knows at least this side of the medal. Beside this he is our top expert regarding embedded devices support since he is actively working on the gp2x support.<br />
<br />
==== boucman ====<br />
As our "patch monkey" he has valuable knowledge in comments and critics for patches of every kind. Beside this he knows many areas of the game due to working on applying patches. He is particularly used to answer question from new coders, and doesn't mind explaining trivial stuff.<br />
<br />
If you want to have a feeling of the developer spirit, it is recommended to go to our [[EasyCoding]] page.<br />
<br />
==== Soliton ====<br />
He does know our mp server setup best. Beside this he already has done a lot of work on the mp server himself, too. So he probably has most knowledge about it and due to being one of our mp-developers might provide important help from the perspective of mp-community and what is needed there.<br />
<br />
==== zookeeper or Mythological or Rhuaven ====<br />
As our leading WML expert it would be good to have him in the list when it comes to WML specific problems. That is for work on the scenario editor he probably knows best what should be implemented in it and what is a usable way for things.<br />
<br />
==== YogiHH or Piotr Cychowski (cycholka) ====<br />
Since they are the two developers who know most about building under Windows, they will probably be really helpful. Either if the student comes from the Windows side, or to help test resulting work to make sure that it does work on Windows and, for the case that it does not, to show them where problems are.</div>Grzywaczhttps://wiki.wesnoth.org/index.php?title=SummerOfCodeIdeas&diff=22897SummerOfCodeIdeas2008-02-27T20:53:50Z<p>Grzywacz: Typo fixes</p>
<hr />
<div>== Ideas for Google Summer of Code projects ==<br />
<br />
This is a compilation of ideas from ML. Needs to be refined (more detailed description, deliverables, workload estimation?):<br />
<br />
== List of Ideas for the Project ==<br />
<br />
=== Writing an AI based on the formula AI ===<br />
<br />
Wesnoth has always had a simple C++ based AI. David (our lead developer) has been working on a simple language to write AI in wesnoth ''link to formula AI page here'' <br />
<br />
The wesnoth AI is used as an oponent in most campaigns, and as such is an important piece of code for the wesnoth project. Unfortunately it is also one of the most neglected piece of code and a place where a lot of research and work could be done<br />
<br />
==== General description ====<br />
<br />
The aim of this project is to develop a new AI that would replace the original C++ AI. The main criterias we would want for this new AI are<br />
<br />
* ''Plugability :'' It should be trivial for any content maker to change the behavior of the AI in specific case. The exact cases are still to be defined but should typically include<br />
** hardwiring the first few turns of the AI<br />
** changing the recruitment pattern<br />
** completely controlling a given unit (sceneario unit)<br />
** taking control then giving back control of a given unit<br />
* ''tunability :'' It should be easy for a scenario author to specify the general behaviour of the ennemy on a given scenario (agressivity, intrepidity...)<br />
* ''specific behaviours :'' there are some typical behaviours that are not smart to win the scenario but are needed, such as guarding a given unit, a given position, wandering aimlessly, attacking randomly, always fleeing. The AI should implement such behaviours, and allow easy addition of new behaviours<br />
<br />
==== Required knowledge and talent ====<br />
<br />
* ''A minimal knowledge of C++ is required, a good knowledge of C++ is desired :'' The formula AI framework is a work in progress and chances are high that some changes in the wesnoth code base will be needed. The wesnoth developper community is used to handle people that are familiar with coding but not C++, however the Forumla AI framework uses advanced C++ features and a good knowledge of the language would avoid a major hurdle when plugging in new entries or functionalities for the AI<br />
* ''Good social interaction with a large player community :'' A preliminary phase to coding any AI is to know the strategies and game pattern used by human players. This requires huge interaction with the player community. Our Gameplay Developpers are open and can give some good starting points, but a big game experience and good interaction with the player community will greatly help in the study of the design<br />
<br />
==== Milestones and deliverables ====<br />
<br />
It is hard to give milestones at this point, but here are some ideas of what could be done<br />
<br />
* ''AI design description, and basic function library :'' This first deliverable aims to conclude the '''study and analysis''' part of the project : becoming familiar with the formula language, study of the Multiplayer strategies and of the need of scenario writers with regard to AI. We would like to have a description of the code structure of the AI, some basis of the play strategies it would use and how external scenario writers could configure it for the particular behaviour they need<br />
* ''Main AI delivery :'' This milestone's aim is to deliver a working AI implementing the strategies described in the first phase. It would not have to systematically beat the standard C++ AI at this point, but should be able to play the game correctly (recruit, early deployment on villages, grouping units to attack, holding its ground, protecting weak/important units). Moreover most plug-in entries should be available and a test-case for these entries should be provided.<br />
* ''Fine tunning and behaviour library :'' The third phase would validate the actual strategy of the AI. The AI should consistently beat the default C++ AI, and do fairly well against an average human player. At that stage a library of scenario behaviours should also be delivered. The AI does not need to be as efficiant with all scenario tweaking, but should act correctly with regard to the particular behaviour desired.<br />
<br />
<br />
=== Extending the Multiplayer server ===<br />
<br />
When the developement team met at FOSDEM, we had our multiplayer commuinty, though it is strong and healthy, had its growth restrained by the interface of the multiplayer lobby.<br />
<br />
==== General Description ====<br />
The general idea of this project would be<br />
* To study the current lobby,<br />
* To present some ideas of evolutions both in interface and functionalities of our multiplayer interface to allow it to scale to a much larger community<br />
* To present some well constructed thought on our MP community and how that interface would develop it<br />
* Of course to implement those changes :)<br />
<br />
Some ideas that we had (but that are in no way mandatory)<br />
* Having a simple way to register and authenticate nicknames, similar to what IRC offers. The point is not to have cryptographically safe logins, but to have something simple that gets the job done<br />
* Having a simple room system? again inspired on IRC<br />
* Having some way to find the type of games you are interested in.<br />
** game type<br />
** number of free slots/players<br />
** any other criteria you might find interesting<br />
<br />
Other ideas we are not convinced are good, but that are certainly worth studying (especially how the communities based around these concepts are different from ours)<br />
* ranking players<br />
* guilds<br />
* official tournaments<br />
* titles for players<br />
* metaservers<br />
<br />
The scalability of the project, both in term of number of players, and in term of the possibility for players and developers to extend the concept will be a valued criteria<br />
<br />
Administration/moderation problems and techniques should also be studied<br />
<br />
interaction with the Add-On server/forum might be an interesting field to expand to<br />
<br />
==== Required knowledge and talent ====<br />
<br />
* A fair amount of experience on C++ is required. Wesnoth uses some advanced C++ features and is heavily based on BOOST and STL. We can train you in some of the libraries used, but learning all of them would be a big hurdle<br />
* Various experience with multiplayer games, in order to have a good idea of what multiplayer lobbies of other game look like, and (more importantly) a good idea of the social behaviours of multiple MP communities, how teams are formed in games and things like that<br />
<br />
==== Milestones and deliverables ====<br />
<br />
* A first milestone would be a presentation summarizing the different studies, and the proposed interface. preliminary informal stages would probably be desirable, to make sure the proposed idea is already a consensus within devs <br />
** Study of other MP game-matching interfaces and functionalities<br />
** Study of other MP communities<br />
** Study of other MP moderation practices<br />
** Study of the Wesnoth MP community, including needs, various opinons from different developers and players<br />
* A second milestone would be the main code delivery. Code should be functional for it will be delivered in the next Wesnoth development release<br />
<br />
=== Other ideas to be fleshed out ===<br />
* Working on the GUI engine (needs to be defined more precisely)<br />
* Rewrite of the campaign (add-on) server<br />
* The editor can use quite a revamp<br />
* A good scenario editor. We have campgen but it hasn't been updated for a while.<br />
<br />
<br />
== Other info to provide for GSoC ==<br />
==== Describe your organization. ====<br />
<br />
==== Why is your organization applying to participate in GSoC 2008? What do you hope to gain by participating?====<br />
<br />
Most of our developers have interesting areas in which they work. Though they are efficient in their areas, there are areas that are interesting but have a high barrier of entry.<br />
<br />
By having a student dedicated to any of these areas, we could quickly get someone up to date with that particular area, efficient, and responsible of this area.<br />
<br />
Basically, by getting new people in and making them actively responsible for an area of code we hope to kickstart some areas of the project that have lagged behind<br />
<br />
==== Did your organization participate in past GSoCs? If so, please summarize your involvement and the successes and challenges of your participation.====<br />
This is the first time the Wesnoth projects applies to Google SoC<br />
<br />
==== If your organization has not previously participated in GSoC, have you applied in the past? If so, for what year(s)?====<br />
<br />
This is the first time the Wesnoth projects applies to Google SoC<br />
<br />
==== Who will your organization administrator be? Please include Google Account information.====<br />
Nils Kneuper aka Ivanovic<br />
<br />
crazy.ivanovic |ATTT| googlemail.com<br />
<br />
==== What license(s) does your project use?====<br />
Our project is entirely GPL.<br />
<br />
All code is GPL.<br />
<br />
All art is GPL, 99% was made for the project, everything was taken from content that was checked to be GPL.<br />
<br />
==== What is the URL for your ideas page?====<br />
Our main summer of code pages is located at http://www.wesnoth.org/wiki/SummerOfCodeIdeas<br />
<br />
This page contains various coding ideas and the thought the development team has already given them.<br />
<br />
It also contains a list of the developers that are the most active on IRC and their domain of interest.<br />
<br />
==== What is the main development mailing list or forum for your organization?====<br />
Most development work takes place on "wesnoth-dev |ATTT| gna.org". Beside this some work happens at http://www.wesnoth.org/forum/.<br />
<br />
==== What is the main IRC channel for your organization?====<br />
<br />
All our IRC channels are on the ''freenode'' network<br />
<br />
* ''#wesnoth-dev'' is the main development channel, where most discussion takes place<br />
* ''#wesnoth'' is a generic channel for the community<br />
* ''#wesnoth-mp'' is a separate channel for multiplayer games and balancing<br />
<br />
==== Does your organization have an application template you would like to see students use? If so, please provide it now.====<br />
We plan mainly to meet potential students through our IRC channel, but the following questions are wesnoth-specific and are worth pondering for any student, even if we don't need a formal answer<br />
<br />
* What type of gamer are you? What type of games? What type of opponent? Are you more interested in story or gameplay ? <br />
* Are you good at interacting with other players ? Our developer community is quite nice, but the player community can be a bit rough.<br />
* Do you give constructive advices? Do you receive advice well? Are you good at sorting useful criticism from useless ones?<br />
<br />
''''to be completed''''<br />
<br />
==== Who will be your backup organization administrator? Please include Google Account information.====<br />
<br />
Jeremy Rosen alias Boucman<br />
<br />
boucman2@gmail.com<br />
<br />
==== Who will your mentors be? Please include Google Account information.====<br />
<br />
==== What criteria did you use to select these individuals as mentors? Please be as specific as possible.====<br />
<br />
==== What is your plan for dealing with disappearing students?====<br />
<br />
==== What is your plan for dealing with disappearing mentors?====<br />
<br />
==== What steps will you take to encourage students to interact with your project's community before, during and after the program?====<br />
<br />
Wesnoth has a particularly healthy community, both for developers and for players. <br />
<br />
Our general policy regarding new coders has always been "two patch... you're in" In other word, anybody that is able to get two non-trivial patches applied is offered commit right.<br />
<br />
We have a developer responsible for applying patches and guiding new developers into our community. This is a well known and effective process we plan to apply to students, directing them to our [[EasyCoding]] pages (these project are usually a couple of hours long and has been chosen to provide easy access to code)<br />
<br />
Usually, patches go back and forth a couple of time, to make sure that all secondary things are in place (indenting, coding style, modified makefiles etc.) The idea is that coder education should take place before the coder gets commit rights, but that getting new coder in is one of the most important things to maintain our project alive.<br />
<br />
If the student is a little proactive and ready to join IRC, all the developers are usually very welcoming, and good at directing newcomers to quickly give useful results.<br />
<br />
'''to be completed'''<br />
<br />
==== What will you do to ensure that your accepted students stick with the project after GSoC concludes?====<br />
<br />
<br />
<br />
=== People to bug on IRC, possible mentors ===<br />
Everybody feel free to edit/correct his entry!<br />
<br />
==== Dave alias Sirp ====<br />
<br />
Sirp started Wesnoth and is our lead developper. He is currently our C++ expert and is also the one that is working on the new Formula AI. Any questions regarding the formula AI should be directed to him.<br />
<br />
==== Mordante ====<br />
Many of the possible projects do at least partly go into the area of code where he knows most of. Plus many of the possible projects currently listed on the ideas page do require GUI parts to work, too. So if Mordante wants to tackle a rewrite of large parts of this, he will be our expert there as well as he already is our expert for the terrain engine (cf. editor / scenario editor works).<br />
<br />
==== Elias Pscherning (elias) ====<br />
He has written the original version of campgen and as such will know a lot about what is needed to to make such an editor work correctly. The work on a scenario editor might be based upon campgen and as such make his knowledge really helpful.<br />
<br />
==== Karol Nowak (grzywacz) ====<br />
Last year he was participating at GSoC as a student, so he knows at least this side of the medal. Beside this he is our top expert regarding embedded devices support since he is actively working on the gp2x support.<br />
<br />
==== boucman ====<br />
As our "patch monkey" he has valuable knowledge in comments and critics for patches of every kind. Beside this he knows many areas of the game due to working on applying patches. He is particularly used to answer question from new coders, and doesn't mind explaining trivial stuff.<br />
<br />
If you want to have a feeling of the developer spirit, it is recommended to go to our [[EasyCoding]] page.<br />
<br />
==== Soliton ====<br />
He does know our mp server setup best. Beside this he already has done a lot of work on the mp server himself, too. So he probably has most knowledge about it and due to being one of our mp-developers might provide important help from the perspective of mp-community and what is needed there.<br />
<br />
==== zookeeper or Mythological or Rhuaven ====<br />
As our leading WML expert it would be good to have him in the list when it comes to WML specific problems. That is for work on the scenario editor he probably knows best what should be implemented in it and what is a usable way for things.<br />
<br />
==== YogiHH or Piotr Cychowski (cycholka) ====<br />
Since they are the two developers who know most about building under Windows, they will probably be really helpful. Either if the student comes from the Windows side, or to help test resulting work to make sure that it does work on Windows and, for the case that it does not, to show them where problems are.</div>Grzywaczhttps://wiki.wesnoth.org/index.php?title=SummerOfCodeIdeas&diff=22895SummerOfCodeIdeas2008-02-27T20:49:38Z<p>Grzywacz: Typo fixes</p>
<hr />
<div>== Ideas for Google Summer of Code projects ==<br />
<br />
This is a compilation of ideas from ML. Needs to be refined (more detailed description, deliverables, workload estimation?):<br />
<br />
== List of Ideas for the Project ==<br />
<br />
=== Writing an AI based on the formula AI ===<br />
<br />
Wesnoth has always had a simple C++ based AI. David (our lead developer) has been working on a simple language to write AI in wesnoth ''link to formula AI page here'' <br />
<br />
The wesnoth AI is used as an oponent in most campaigns, and as such is an important piece of code for the wesnoth project. Unfortunately it is also one of the most neglected piece of code and a place where a lot of research and work could be done<br />
<br />
==== General description ====<br />
<br />
The aim of this project is to develop a new AI that would replace the original C++ AI. The main criterias we would want for this new AI are<br />
<br />
* ''Plugability :'' It should be trivial for any content maker to change the behavior of the AI in specific case. The exact cases are still to be defined but should typically include<br />
** hardwiring the first few turns of the AI<br />
** changing the recruitment pattern<br />
** completely controlling a given unit (sceneario unit)<br />
** taking control then giving back control of a given unit<br />
* ''tunability :'' It should be easy for a scenario author to specify the general behaviour of the ennemy on a given scenario (agressivity, intrepidity...)<br />
* ''specific behaviours :'' there are some typical behaviours that are not smart to win the scenario but are needed, such as guarding a given unit, a given position, wandering aimlessly, attacking randomly, always fleeing. The AI should implement such behaviours, and allow easy addition of new behaviours<br />
<br />
==== Required knowledge and talent ====<br />
<br />
* ''A minimal knowledge of C++ is required, a good knowledge of C++ is desired :'' The formula AI framework is a work in progress and chances are high that some changes in the wesnoth code base will be needed. The wesnoth developper community is used to handle people that are familiar with coding but not C++, however the Forumla AI framework uses advanced C++ features and a good knowledge of the language would avoid a major hurdle when plugging in new entries or functionalities for the AI<br />
* ''Good social interaction with a large player community :'' A preliminary phase to coding any AI is to know the strategies and game pattern used by human players. This requires huge interaction with the player community. Our Gameplay Developpers are open and can give some good starting points, but a big game experience and good interaction with the player community will greatly help in the study of the design<br />
<br />
==== Milestones and deliverables ====<br />
<br />
It is hard to give milestones at this point, but here are some ideas of what could be done<br />
<br />
* ''AI design description, and basic function library :'' This first deliverable aims to conclude the '''study and analysis''' part of the project : becoming familiar with the formula language, study of the Multiplayer strategies and of the need of scenario writers with regard to AI. We would like to have a description of the code structure of the AI, some basis of the play strategies it would use and how external scenario writers could configure it for the particular behaviour they need<br />
* ''Main AI delivery :'' This milestone's aim is to deliver a working AI implementing the strategies described in the first phase. It would not have to systematically beat the standard C++ AI at this point, but should be able to play the game correctly (recruit, early deployment on villages, grouping units to attack, holding its ground, protecting weak/important units). Moreover most plug-in entries should be available and a test-case for these entries should be provided.<br />
* ''Fine tunning and behaviour library :'' The third phase would validate the actual strategy of the AI. The AI should consistently beat the default C++ AI, and do fairly well against an average human player. At that stage a library of scenario behaviours should also be delivered. The AI does not need to be as efficiant with all scenario tweaking, but should act correctly with regard to the particular behaviour desired.<br />
<br />
<br />
=== Extending the Multiplayer server ===<br />
<br />
When the developement team met at FOSDEM, we had our multiplayer commuinty, though it is strong and healthy, had its growth restrained by the interface of the multiplayer lobby.<br />
<br />
==== General Description ====<br />
The general idea of this project would be<br />
* To study the current lobby,<br />
* To present some ideas of evolutions both in interface and functionalities of our multiplayer interface to allow it to scale to a much larger community<br />
* To present some well constructed thought on our MP community and how that interface would develop it<br />
* Of course to implement those changes :)<br />
<br />
Some ideas that we had (but that are in no way mandatory)<br />
* Having a simple way to register and authentificate nicknames, similar to what IRC offers. The point is not to have cryptographically safe logins, but to have something simple that gets the job done<br />
* Having a simple room system? again inspired on IRC<br />
* Having some way to find the type of games you are interested in.<br />
** game type<br />
** number of free slots/players<br />
** any other criterias you might find interesting<br />
<br />
Other ideas we are not convinced are good, but that are certainly worth studying (especially how the communities based around these concepts are different from ours)<br />
* ranking players<br />
* guilds<br />
* official tournaments<br />
* titles for players<br />
* metaservers<br />
<br />
The scalablity of the project, both in term of number of players, and in term of the possibility for players and developpers to extend the concept will be a valued criteria<br />
<br />
Administration/moderation problems and techniques should also be studied<br />
<br />
interaction with the Add-On server/forum might be an interseting field to expand to<br />
<br />
==== Required knowledge and talent ====<br />
<br />
* A fair amount of experience on C++ is required. Wesnoth uses some advanced C++ features and is heavily based on BOOST and STL. We can train you in some of the libraries used, but learning all of them would be a big hurdle<br />
* Various experience with multiplayer games, in order to have a good idea of what multiplayer lobbies of other game look like, and (more importantly) a good idea of the social behaviours of multiple MP communities, how teams are formed in games and things like that<br />
<br />
==== Milestones and deliverables ====<br />
<br />
* A first milestone would be a presentation summarizing the different studies, and the proposed interface. preliminary informal stages would probably be desirable, to make sure the proposed idea is already a consensus within devs <br />
** Study of other MP game-matching interfaces and functionalities<br />
** Study of other MP communities<br />
** Study of other MP moderation practices<br />
** Study of the Wesnoth MP community, including needs, various opinons from different developers and players<br />
* A second milestone would be the main code delivery. Code should be functional for it will be delivered in the next Wesnoth development release<br />
<br />
=== Other ideas to be fleshed out ===<br />
* Working on the GUI engine (needs to be defined more precisely)<br />
* Rewrite of the campaign (add-on) server<br />
* The editor can use quite a revamp<br />
* A good scenario editor. We have campgen but it hasn't been updated for a while.<br />
<br />
<br />
== Other info to provide for GSoC ==<br />
==== Describe your organization. ====<br />
<br />
==== Why is your organization applying to participate in GSoC 2008? What do you hope to gain by participating?====<br />
<br />
Most of our developers have interesting areas in which they work. Though they are efficient in their areas, there are areas that are interesting but have a high barrier of entry.<br />
<br />
By having a student dedicated to any of these areas, we could quickly get someone up to date with that particular area, efficient, and responsible of this area.<br />
<br />
Basically, by getting new people in and making them actively responsible for an area of code we hope to kickstart some areas of the project that have lagged behind<br />
<br />
==== Did your organization participate in past GSoCs? If so, please summarize your involvement and the successes and challenges of your participation.====<br />
This is the first time the Wesnoth projects applies to Google SoC<br />
<br />
==== If your organization has not previously participated in GSoC, have you applied in the past? If so, for what year(s)?====<br />
<br />
This is the first time the Wesnoth projects applies to Google SoC<br />
<br />
==== Who will your organization administrator be? Please include Google Account information.====<br />
Nils Kneuper aka Ivanovic<br />
<br />
crazy.ivanovic |ATTT| googlemail.com<br />
<br />
==== What license(s) does your project use?====<br />
Our project is entirely GPL.<br />
<br />
All code is GPL.<br />
<br />
All art is GPL, 99% was made for the project, everything was taken from content that was checked to be GPL.<br />
<br />
==== What is the URL for your ideas page?====<br />
Our main summer of code pages is located at http://www.wesnoth.org/wiki/SummerOfCodeIdeas<br />
<br />
This page contains various coding ideas and the thought the development team has already given them.<br />
<br />
It also contains a list of the developers that are the most active on IRC and their domain of interest.<br />
<br />
==== What is the main development mailing list or forum for your organization?====<br />
Most development work takes place on "wesnoth-dev |ATTT| gna.org". Beside this some work happens at http://www.wesnoth.org/forum/.<br />
<br />
==== What is the main IRC channel for your organization?====<br />
<br />
All our IRC channels are on the ''freenode'' network<br />
<br />
* ''#wesnoth-dev'' is the main development channel, where most discussion takes place<br />
* ''#wesnoth'' is a generic channel for the community<br />
* ''#wesnoth-mp'' is a separate channel for multiplayer games and balancing<br />
<br />
==== Does your organization have an application template you would like to see students use? If so, please provide it now.====<br />
We plan mainly to meet potential students through our IRC channel, but the following questions are wesnoth-specific and are worth pondering for any student, even if we don't need a formal answer<br />
<br />
* What type of gamer are you? What type of games? What type of opponent? Are you more interested in story or gameplay ? <br />
* Are you good at interacting with other players ? Our developer community is quite nice, but the player community can be a bit rough.<br />
* Do you give constructive advices? Do you receive advice well? Are you good at sorting useful criticism from useless ones?<br />
<br />
''''to be completed''''<br />
<br />
==== Who will be your backup organization administrator? Please include Google Account information.====<br />
<br />
Jeremy Rosen alias Boucman<br />
<br />
boucman2@gmail.com<br />
<br />
==== Who will your mentors be? Please include Google Account information.====<br />
<br />
==== What criteria did you use to select these individuals as mentors? Please be as specific as possible.====<br />
<br />
==== What is your plan for dealing with disappearing students?====<br />
<br />
==== What is your plan for dealing with disappearing mentors?====<br />
<br />
==== What steps will you take to encourage students to interact with your project's community before, during and after the program?====<br />
<br />
Wesnoth has a particularly healthy community, both for developers and for players. <br />
<br />
Our general policy regarding new coders has always been "two patch... you're in" In other word, anybody that is able to get two non-trivial patches applied is offered commit right.<br />
<br />
We have a developer responsible for applying patches and guiding new developers into our community. This is a well known and effective process we plan to apply to students, directing them to our [[EasyCoding]] pages (these project are usually a couple of hours long and has been chosen to provide easy access to code)<br />
<br />
Usually, patches go back and forth a couple of time, to make sure that all secondary things are in place (indenting, coding style, modified makefiles etc.) The idea is that coder education should take place before the coder gets commit rights, but that getting new coder in is one of the most important things to maintain our project alive.<br />
<br />
If the student is a little proactive and ready to join IRC, all the developers are usually very welcoming, and good at directing newcomers to quickly give useful results.<br />
<br />
'''to be completed'''<br />
<br />
==== What will you do to ensure that your accepted students stick with the project after GSoC concludes?====<br />
<br />
<br />
<br />
=== People to bug on IRC, possible mentors ===<br />
Everybody feel free to edit/correct his entry!<br />
<br />
==== Dave alias Sirp ====<br />
<br />
Sirp started Wesnoth and is our lead developper. He is currently our C++ expert and is also the one that is working on the new Formula AI. Any questions regarding the formula AI should be directed to him.<br />
<br />
==== Mordante ====<br />
Many of the possible projects do at least partly go into the area of code where he knows most of. Plus many of the possible projects currently listed on the ideas page do require GUI parts to work, too. So if Mordante wants to tackle a rewrite of large parts of this, he will be our expert there as well as he already is our expert for the terrain engine (cf. editor / scenario editor works).<br />
<br />
==== Elias Pscherning (elias) ====<br />
He has written the original version of campgen and as such will know a lot about what is needed to to make such an editor work correctly. The work on a scenario editor might be based upon campgen and as such make his knowledge really helpful.<br />
<br />
==== Karol Nowak (grzywacz) ====<br />
Last year he was participating at GSoC as a student, so he knows at least this side of the medal. Beside this he is our top expert regarding embedded devices support since he is actively working on the gp2x support.<br />
<br />
==== boucman ====<br />
As our "patch monkey" he has valuable knowledge in comments and critics for patches of every kind. Beside this he knows many areas of the game due to working on applying patches. He is particularly used to answer question from new coders, and doesn't mind explaining trivial stuff.<br />
<br />
If you want to have a feeling of the developer spirit, it is recommended to go to our [[EasyCoding]] page.<br />
<br />
==== Soliton ====<br />
He does know our mp server setup best. Beside this he already has done a lot of work on the mp server himself, too. So he probably has most knowledge about it and due to being one of our mp-developers might provide important help from the perspective of mp-community and what is needed there.<br />
<br />
==== zookeeper or Mythological or Rhuaven ====<br />
As our leading WML expert it would be good to have him in the list when it comes to WML specific problems. That is for work on the scenario editor he probably knows best what should be implemented in it and what is a usable way for things.<br />
<br />
==== YogiHH or Piotr Cychowski (cycholka) ====<br />
Since they are the two developers who know most about building under Windows, they will probably be really helpful. Either if the student comes from the Windows side, or to help test resulting work to make sure that it does work on Windows and, for the case that it does not, to show them where problems are.</div>Grzywaczhttps://wiki.wesnoth.org/index.php?title=SummerOfCodeIdeas&diff=22894SummerOfCodeIdeas2008-02-27T20:48:25Z<p>Grzywacz: Typo fixes</p>
<hr />
<div>== Ideas for Google Summer of Code projects ==<br />
<br />
This is a compilation of ideas from ML. Needs to be refined (more detailed description, deliverables, workload estimation?):<br />
<br />
== List of Ideas for the Project ==<br />
<br />
=== Writing an AI based on the formula AI ===<br />
<br />
Wesnoth has always had a simple C++ based AI. David (our lead developer) has been working on a simple language to write AI in wesnoth ''link to formula AI page here'' <br />
<br />
The wesnoth AI is used as an oponent in most campaigns, and as such is an important piece of code for the wesnoth project. Unfortunately it is also one of the most neglected piece of code and a place where a lot of research and work could be done<br />
<br />
==== General description ====<br />
<br />
The aim of this project is to develop a new AI that would replace the original C++ AI. The main criterias we would want for this new AI are<br />
<br />
* ''Plugability :'' It should be trivial for any content maker to change the behavior of the AI in specific case. The exact cases are still to be defined but should typically include<br />
** hardwiring the first few turns of the AI<br />
** changing the recruitment pattern<br />
** completely controlling a given unit (sceneario unit)<br />
** taking control then giving back control of a given unit<br />
* ''tunability :'' It should be easy for a scenario author to specify the general behaviour of the ennemy on a given scenario (agressivity, intrepidity...)<br />
* ''specific behaviours :'' there are some typical behaviours that are not smart to win the scenario but are needed, such as guarding a given unit, a given position, wandering aimlessly, attacking randomly, always fleeing. The AI should implement such behaviours, and allow easy addition of new behaviours<br />
<br />
==== Required knowledge and talent ====<br />
<br />
* ''A minimal knowledge of C++ is required, a good knowledge of C++ is desired :'' The formula AI framework is a work in progress and chances are high that some changes in the wesnoth code base will be needed. The wesnoth developper community is used to handle people that are familiar with coding but not C++, however the Forumla AI framework uses advanced C++ features and a good knowledge of the language would avoid a major hurdle when plugging in new entries or functionalities for the AI<br />
* ''Good social interaction with a large player community :'' A preliminary phase to coding any AI is to know the strategies and game pattern used by human players. This requires huge interaction with the player community. Our Gameplay Developpers are open and can give some good starting points, but a big game experience and good interaction with the player community will greatly help in the study of the design<br />
<br />
==== Milestones and deliverables ====<br />
<br />
It is hard to give milestones at this point, but here are some ideas of what could be done<br />
<br />
* ''AI design description, and basic function library :'' This first deliverable aims to conclude the '''study and analysis''' part of the project : becoming familiar with the formula language, study of the Multiplayer strategies and of the need of scenario writers with regard to AI. We would like to have a description of the code structure of the AI, some basis of the play strategies it would use and how external scenario writers could configure it for the particular behaviour they need<br />
* ''Main AI delivery :'' This milestone's aim is to deliver a working AI implementing the strategies described in the first phase. It would not have to systematically beat the standard C++ AI at this point, but should be able to play the game correctly (recruit, early deployment on villages, grouping units to attack, holding its ground, protecting weak/important units). Moreover most plug-in entries should be available and a test-case for these entries should be provided.<br />
* ''Fine tunning and behaviour library :'' The third phase would validate the actual strategy of the AI. The AI should consistently beat the default C++ AI, and do fairly well against an average human player. At that stage a library of scenario behaviours should also be delivered. The AI does not need to be as efficiant with all scenario tweaking, but should act correctly with regard to the particular behaviour desired.<br />
<br />
<br />
=== Extending the Multiplayer server ===<br />
<br />
When the developement team met at FOSDEM, we had our multiplayer commuinty, though it is strong and healthy, had its growth restrained by the interface of the multiplayer lobby.<br />
<br />
==== General Description ====<br />
The general idea of this project would be<br />
* To study the current lobby,<br />
* To present some ideas of evolutions both in interface and functionalities of our multiplayer interface to allow it to scale to a much larger community<br />
* To present some well constructed thought on our MP community and how that interface would develop it<br />
* Of course to implement those changes :)<br />
<br />
Some ideas that we had (but that are in no way mandatory)<br />
* Having a simple way to register and authentificate nicknames, similar to what IRC offers. The point is not to have cryptographically safe logins, but to have something simple that gets the job done<br />
* Having a simple room system? again inspired on IRC<br />
* Having some way to find the type of games you are interested in.<br />
** game type<br />
** number of free slots/players<br />
** any other criterias you might find interesting<br />
<br />
Other ideas we are not convinced are good, but that are certainly worth studying (especially how the communities based around these concepts are different from ours)<br />
* ranking players<br />
* guilds<br />
* official tournaments<br />
* titles for players<br />
* metaservers<br />
<br />
The scalablity of the project, both in term of number of players, and in term of the possibility for players and developpers to extend the concept will be a valued criteria<br />
<br />
Administration/moderation problems and techniques should also be studied<br />
<br />
interaction with the Add-On server/forum might be an interseting field to expand to<br />
<br />
==== Required knowledge and talent ====<br />
<br />
* A fair amount of experience on C++ is required. Wesnoth uses some advanced C++ features and is heavily based on BOOST and STL. We can train you in some of the libraries used, but learning all of them would be a big hurdle<br />
* Various experience with multiplayer games, in order to have a good idea of what multiplayer lobbies of other game look like, and (more importantly) a good idea of the social behaviours of multiple MP communities, how teams are formed in games and things like that<br />
<br />
==== Milestones and deliverables ====<br />
<br />
* A first milestone would be a presentation summarizing the different studies, and the proposed interface. preliminary unformal stages would probably be desirable, to make sure the proposed idea is already a consensus within devs <br />
** Study of other MP game-matching interfaces and functionalities<br />
** Study of other MP communities<br />
** Study of other MP moderation practices<br />
** Study of the Wesnoth MP community, including needs, various opinons from different developers and players<br />
* A second milestone would be the main code delivery. Code should be functional for it will be delivered in the next Wesnoth developement release<br />
<br />
<br />
=== Other ideas to be fleshed out ===<br />
* Working on the GUI engine (needs to be defined more precisely)<br />
* Rewrite of the campaign (add-on) server<br />
* The editor can use quite a revamp<br />
* A good scenario editor. We have campgen but it hasn't been updated for a while.<br />
<br />
<br />
== Other info to provide for GSoC ==<br />
==== Describe your organization. ====<br />
<br />
==== Why is your organization applying to participate in GSoC 2008? What do you hope to gain by participating?====<br />
<br />
Most of our developers have interesting areas in which they work. Though they are efficient in their areas, there are areas that are interesting but have a high barrier of entry.<br />
<br />
By having a student dedicated to any of these areas, we could quickly get someone up to date with that particular area, efficient, and responsible of this area.<br />
<br />
Basically, by getting new people in and making them actively responsible for an area of code we hope to kickstart some areas of the project that have lagged behind<br />
<br />
==== Did your organization participate in past GSoCs? If so, please summarize your involvement and the successes and challenges of your participation.====<br />
This is the first time the Wesnoth projects applies to Google SoC<br />
<br />
==== If your organization has not previously participated in GSoC, have you applied in the past? If so, for what year(s)?====<br />
<br />
This is the first time the Wesnoth projects applies to Google SoC<br />
<br />
==== Who will your organization administrator be? Please include Google Account information.====<br />
Nils Kneuper aka Ivanovic<br />
<br />
crazy.ivanovic |ATTT| googlemail.com<br />
<br />
==== What license(s) does your project use?====<br />
Our project is entirely GPL.<br />
<br />
All code is GPL.<br />
<br />
All art is GPL, 99% was made for the project, everything was taken from content that was checked to be GPL.<br />
<br />
==== What is the URL for your ideas page?====<br />
Our main summer of code pages is located at http://www.wesnoth.org/wiki/SummerOfCodeIdeas<br />
<br />
This page contains various coding ideas and the thought the development team has already given them.<br />
<br />
It also contains a list of the developers that are the most active on IRC and their domain of interest.<br />
<br />
==== What is the main development mailing list or forum for your organization?====<br />
Most development work takes place on "wesnoth-dev |ATTT| gna.org". Beside this some work happens at http://www.wesnoth.org/forum/.<br />
<br />
==== What is the main IRC channel for your organization?====<br />
<br />
All our IRC channels are on the ''freenode'' network<br />
<br />
* ''#wesnoth-dev'' is the main development channel, where most discussion takes place<br />
* ''#wesnoth'' is a generic channel for the community<br />
* ''#wesnoth-mp'' is a separate channel for multiplayer games and balancing<br />
<br />
==== Does your organization have an application template you would like to see students use? If so, please provide it now.====<br />
We plan mainly to meet potential students through our IRC channel, but the following questions are wesnoth-specific and are worth pondering for any student, even if we don't need a formal answer<br />
<br />
* What type of gamer are you? What type of games? What type of opponent? Are you more interested in story or gameplay ? <br />
* Are you good at interacting with other players ? Our developer community is quite nice, but the player community can be a bit rough.<br />
* Do you give constructive advices? Do you receive advice well? Are you good at sorting useful criticism from useless ones?<br />
<br />
''''to be completed''''<br />
<br />
==== Who will be your backup organization administrator? Please include Google Account information.====<br />
<br />
Jeremy Rosen alias Boucman<br />
<br />
boucman2@gmail.com<br />
<br />
==== Who will your mentors be? Please include Google Account information.====<br />
<br />
==== What criteria did you use to select these individuals as mentors? Please be as specific as possible.====<br />
<br />
==== What is your plan for dealing with disappearing students?====<br />
<br />
==== What is your plan for dealing with disappearing mentors?====<br />
<br />
==== What steps will you take to encourage students to interact with your project's community before, during and after the program?====<br />
<br />
Wesnoth has a particularly healthy community, both for developers and for players. <br />
<br />
Our general policy regarding new coders has always been "two patch... you're in" In other word, anybody that is able to get two non-trivial patches applied is offered commit right.<br />
<br />
We have a developer responsible for applying patches and guiding new developers into our community. This is a well known and effective process we plan to apply to students, directing them to our [[EasyCoding]] pages (these project are usually a couple of hours long and has been chosen to provide easy access to code)<br />
<br />
Usually, patches go back and forth a couple of time, to make sure that all secondary things are in place (indenting, coding style, modified makefiles etc.) The idea is that coder education should take place before the coder gets commit rights, but that getting new coder in is one of the most important things to maintain our project alive.<br />
<br />
If the student is a little proactive and ready to join IRC, all the developers are usually very welcoming, and good at directing newcomers to quickly give useful results.<br />
<br />
'''to be completed'''<br />
<br />
==== What will you do to ensure that your accepted students stick with the project after GSoC concludes?====<br />
<br />
<br />
<br />
=== People to bug on IRC, possible mentors ===<br />
Everybody feel free to edit/correct his entry!<br />
<br />
==== Dave alias Sirp ====<br />
<br />
Sirp started Wesnoth and is our lead developper. He is currently our C++ expert and is also the one that is working on the new Formula AI. Any questions regarding the formula AI should be directed to him.<br />
<br />
==== Mordante ====<br />
Many of the possible projects do at least partly go into the area of code where he knows most of. Plus many of the possible projects currently listed on the ideas page do require GUI parts to work, too. So if Mordante wants to tackle a rewrite of large parts of this, he will be our expert there as well as he already is our expert for the terrain engine (cf. editor / scenario editor works).<br />
<br />
==== Elias Pscherning (elias) ====<br />
He has written the original version of campgen and as such will know a lot about what is needed to to make such an editor work correctly. The work on a scenario editor might be based upon campgen and as such make his knowledge really helpful.<br />
<br />
==== Karol Nowak (grzywacz) ====<br />
Last year he was participating at GSoC as a student, so he knows at least this side of the medal. Beside this he is our top expert regarding embedded devices support since he is actively working on the gp2x support.<br />
<br />
==== boucman ====<br />
As our "patch monkey" he has valuable knowledge in comments and critics for patches of every kind. Beside this he knows many areas of the game due to working on applying patches. He is particularly used to answer question from new coders, and doesn't mind explaining trivial stuff.<br />
<br />
If you want to have a feeling of the developer spirit, it is recommended to go to our [[EasyCoding]] page.<br />
<br />
==== Soliton ====<br />
He does know our mp server setup best. Beside this he already has done a lot of work on the mp server himself, too. So he probably has most knowledge about it and due to being one of our mp-developers might provide important help from the perspective of mp-community and what is needed there.<br />
<br />
==== zookeeper or Mythological or Rhuaven ====<br />
As our leading WML expert it would be good to have him in the list when it comes to WML specific problems. That is for work on the scenario editor he probably knows best what should be implemented in it and what is a usable way for things.<br />
<br />
==== YogiHH or Piotr Cychowski (cycholka) ====<br />
Since they are the two developers who know most about building under Windows, they will probably be really helpful. Either if the student comes from the Windows side, or to help test resulting work to make sure that it does work on Windows and, for the case that it does not, to show them where problems are.</div>Grzywaczhttps://wiki.wesnoth.org/index.php?title=SummerOfCodeIdeas&diff=22893SummerOfCodeIdeas2008-02-27T20:46:44Z<p>Grzywacz: Typo fixes</p>
<hr />
<div>== Ideas for Google Summer of Code projects ==<br />
<br />
This is a compilation of ideas from ML. Needs to be refined (more detailed description, deliverables, workload estimation?):<br />
<br />
== List of Ideas for the Project ==<br />
<br />
=== Writing an AI based on the formula AI ===<br />
<br />
Wesnoth has always had a simple C++ based AI. David (our lead developer) has been working on a simple language to write AI in wesnoth ''link to formula AI page here'' <br />
<br />
The wesnoth AI is used as an oponent in most campaigns, and as such is an important piece of code for the wesnoth project. Unfortunately it is also one of the most neglected piece of code and a place where a lot of research and work could be done<br />
<br />
==== General description ====<br />
<br />
The aim of this project is to develop a new AI that would replace the original C++ AI. The main criterias we would want for this new AI are<br />
<br />
* ''Plugability :'' It should be trivial for any content maker to change the behavior of the AI in specific case. The exact cases are still to be defined but should typically include<br />
** hardwiring the first few turns of the AI<br />
** changing the recruitment pattern<br />
** completely controlling a given unit (sceneario unit)<br />
** taking control then giving back control of a given unit<br />
* ''tunability :'' It should be easy for a scenario author to specify the general behaviour of the ennemy on a given scenario (agressivity, intrepidity...)<br />
* ''specific behaviours :'' there are some typical behaviours that are not smart to win the scenario but are needed, such as guarding a given unit, a given position, wandering aimlessly, attacking randomly, always fleeing. The AI should implement such behaviours, and allow easy addition of new behaviours<br />
<br />
==== Required knowledge and talent ====<br />
<br />
* ''A minimal knowledge of C++ is required, a good knowledge of C++ is desired :'' The formula AI framework is a work in progress and chances are high that some changes in the wesnoth code base will be needed. The wesnoth developper community is used to handle people that are familiar with coding but not C++, however the Forumla AI framework uses advanced C++ features and a good knowledge of the language would avoid a major hurdle when plugging in new entries or functionalities for the AI<br />
* ''Good social interaction with a large player community :'' A preliminary phase to coding any AI is to know the strategies and game pattern used by human players. This requires huge interaction with the player community. Our Gameplay Developpers are open and can give some good starting points, but a big game experience and good interaction with the player community will greatly help in the study of the design<br />
<br />
==== Milestones and deliverables ====<br />
<br />
It is hard to give milestones at this point, but here are some ideas of what could be done<br />
<br />
* ''AI design description, and basic function library :'' This first deliverable aims to conclude the '''study and analysis''' part of the project : becoming familiar with the formula language, study of the Multiplayer strategies and of the need of scenario writers with regard to AI. We would like to have a description of the code structure of the AI, some basis of the play strategies it would use and how external scenario writers could configure it for the particular behaviour they need<br />
* ''Main AI delivery :'' This milestone's aim is to deliver a working AI implementing the strategies described in the first phase. It would not have to systematically beat the standard C++ AI at this point, but should be able to play the game correctly (recruit, early deployment on villages, grouping units to attack, holding its ground, protecting weak/important units). Moreover most plug-in entries should be available and a test-case for these entries should be provided.<br />
* ''Fine tunning and behaviour library :'' The third phase would validate the actual strategy of the AI. The AI should consistently beat the default C++ AI, and do fairly well against an average human player. At that stage a library of scenario behaviours should also be delivered. The AI does not need to be as efficiant with all scenario tweaking, but should act correctly with regard to the particular behaviour desired.<br />
<br />
<br />
=== Extending the Multiplayer server ===<br />
<br />
When the developement team met at FOSDEM, we had our multiplayer commuinty, though it is strong and healthy, had its growth restrained by the interface of the multiplayer lobby.<br />
<br />
==== General Description ====<br />
The general idea of this project would be<br />
* To study the current lobby,<br />
* To present some ideas of evolutions both in interface and functionalities of our multiplayer interface to allow it to scale to a much larger community<br />
* To present some well constructed thought on our MP community and how that interface would develop it<br />
* Of course to implement those changes :)<br />
<br />
Some ideas that we had (but that are in no way mandatory)<br />
* Having a simple way to register and authentificate nicknames, similar to what IRC offers. The point is not to have cryptographically safe logins, but to have something simple that gets the job done<br />
* Having a simple room system? again inspired on IRC<br />
* Having some way to find the type of games you are interested in.<br />
** game type<br />
** number of free slots/players<br />
** any other criterias you might find interesting<br />
<br />
Other ideas we are not convinced are good, but that are certainly worth studying (especially how the communities based around these concepts are different from ours)<br />
* ranking players<br />
* guilds<br />
* official tournaments<br />
* titles for players<br />
* metaservers<br />
<br />
The scalablity of the project, both in term of number of players, and in term of the possibility for players and developpers to extend the concept will be a valued criteria<br />
<br />
Administration/moderation problems and techniques should also be studied<br />
<br />
interaction with the Add-On server/forum might be an interseting field to expand to<br />
<br />
==== Required knowledge and talent ====<br />
<br />
* A fair amount of experience on C++ is required. Wesnoth uses some advanced C++ features and is heavily based on BOOST and STL. We can train you in some of the libraries used, but learning all of them would be a big hurdle<br />
* Various experience with multiplayer games, in order to have a good idea of what multiplayer lobbies of other game look like, and (more importantly) a good idea of the social behaviours of multiple MP communities, how teams are formed in games and things like that<br />
<br />
==== Milestones and deliverables ====<br />
<br />
* A first milestone would be a presentation summarizing the different studies, and the proposed interface. preliminary unformal stages would probably be desirable, to make sure the proposed idea is already a consensus within devs <br />
** Study of other MP game-matching interfaces and functionalities<br />
** Study of other MP communities<br />
** Study of other MP moderation practices<br />
** Study of the Wesnoth MP community, including needs, various opinons from different developers and players<br />
* A second milestone would be the main code delivery. Code should be functional for it will be delivered in the next Wesnoth developement release<br />
<br />
<br />
=== Other ideas to be fleshed out ===<br />
* Working on the GUI engine (needs to be defined more precisely)<br />
* Rewrite of the campaign (add-on) server<br />
* The editor can use quite a revamp<br />
* A good scenario editor. We have campgen but it hasn't been updated for a while.<br />
<br />
<br />
== Other info to provide for GSoC ==<br />
==== Describe your organization. ====<br />
<br />
==== Why is your organization applying to participate in GSoC 2008? What do you hope to gain by participating?====<br />
<br />
Most of our developpers have interesting areas in which they work. Though they are efficiant in their areas, there are areas that are interesting but have a high barrier of entry.<br />
<br />
By having a student dedicated to any of these areas, we could quickly get someone upto date with that particualr area, efficiant, and responsible of this area.<br />
<br />
Basically, by getting new people in and making them actively responsible for an area of code we hope to kickstart some areas of the project that have lagged behind<br />
<br />
==== Did your organization participate in past GSoCs? If so, please summarize your involvement and the successes and challenges of your participation.====<br />
This is the first time the Wesnoth projects applies to Google SoC<br />
<br />
==== If your organization has not previously participated in GSoC, have you applied in the past? If so, for what year(s)?====<br />
<br />
This is the first time the Wesnoth projects applies to Google SoC<br />
<br />
==== Who will your organization administrator be? Please include Google Account information.====<br />
Nils Kneuper aka Ivanovic<br />
<br />
crazy.ivanovic |ATTT| googlemail.com<br />
<br />
==== What license(s) does your project use?====<br />
Our project is entirely GPL.<br />
<br />
All code is GPL.<br />
<br />
All art is GPL, 99% was made for the project, everything was taken from content that was checked to be GPL.<br />
<br />
==== What is the URL for your ideas page?====<br />
Our main summer of code pages is located at http://www.wesnoth.org/wiki/SummerOfCodeIdeas<br />
<br />
This page contains various coding ideas and the thought the development team has already given them.<br />
<br />
It also contains a list of the developers that are the most active on IRC and their domain of interest.<br />
<br />
==== What is the main development mailing list or forum for your organization?====<br />
Most development work takes place on "wesnoth-dev |ATTT| gna.org". Beside this some work happens at http://www.wesnoth.org/forum/.<br />
<br />
==== What is the main IRC channel for your organization?====<br />
<br />
All our IRC channels are on the ''freenode'' network<br />
<br />
* ''#wesnoth-dev'' is the main development channel, where most discussion takes place<br />
* ''#wesnoth'' is a generic channel for the community<br />
* ''#wesnoth-mp'' is a separate channel for multiplayer games and balancing<br />
<br />
==== Does your organization have an application template you would like to see students use? If so, please provide it now.====<br />
We plan mainly to meet potential students through our IRC channel, but the following questions are wesnoth-specific and are worth pondering for any student, even if we don't need a formal answer<br />
<br />
* What type of gamer are you? What type of games? What type of opponent? Are you more interested in story or gameplay ? <br />
* Are you good at interacting with other players ? Our developer community is quite nice, but the player community can be a bit rough.<br />
* Do you give constructive advices? Do you receive advice well? Are you good at sorting useful criticism from useless ones?<br />
<br />
''''to be completed''''<br />
<br />
==== Who will be your backup organization administrator? Please include Google Account information.====<br />
<br />
Jeremy Rosen alias Boucman<br />
<br />
boucman2@gmail.com<br />
<br />
==== Who will your mentors be? Please include Google Account information.====<br />
<br />
==== What criteria did you use to select these individuals as mentors? Please be as specific as possible.====<br />
<br />
==== What is your plan for dealing with disappearing students?====<br />
<br />
==== What is your plan for dealing with disappearing mentors?====<br />
<br />
==== What steps will you take to encourage students to interact with your project's community before, during and after the program?====<br />
<br />
Wesnoth has a particularly healthy community, both for developers and for players. <br />
<br />
Our general policy regarding new coders has always been "two patch... you're in" In other word, anybody that is able to get two non-trivial patches applied is offered commit right.<br />
<br />
We have a developer responsible for applying patches and guiding new developers into our community. This is a well known and effective process we plan to apply to students, directing them to our [[EasyCoding]] pages (these project are usually a couple of hours long and has been chosen to provide easy access to code)<br />
<br />
Usually, patches go back and forth a couple of time, to make sure that all secondary things are in place (indenting, coding style, modified makefiles etc.) The idea is that coder education should take place before the coder gets commit rights, but that getting new coder in is one of the most important things to maintain our project alive.<br />
<br />
If the student is a little proactive and ready to join IRC, all the developers are usually very welcoming, and good at directing newcomers to quickly give useful results.<br />
<br />
'''to be completed'''<br />
<br />
==== What will you do to ensure that your accepted students stick with the project after GSoC concludes?====<br />
<br />
<br />
<br />
=== People to bug on IRC, possible mentors ===<br />
Everybody feel free to edit/correct his entry!<br />
<br />
==== Dave alias Sirp ====<br />
<br />
Sirp started Wesnoth and is our lead developper. He is currently our C++ expert and is also the one that is working on the new Formula AI. Any questions regarding the formula AI should be directed to him.<br />
<br />
==== Mordante ====<br />
Many of the possible projects do at least partly go into the area of code where he knows most of. Plus many of the possible projects currently listed on the ideas page do require GUI parts to work, too. So if Mordante wants to tackle a rewrite of large parts of this, he will be our expert there as well as he already is our expert for the terrain engine (cf. editor / scenario editor works).<br />
<br />
==== Elias Pscherning (elias) ====<br />
He has written the original version of campgen and as such will know a lot about what is needed to to make such an editor work correctly. The work on a scenario editor might be based upon campgen and as such make his knowledge really helpful.<br />
<br />
==== Karol Nowak (grzywacz) ====<br />
Last year he was participating at GSoC as a student, so he knows at least this side of the medal. Beside this he is our top expert regarding embedded devices support since he is actively working on the gp2x support.<br />
<br />
==== boucman ====<br />
As our "patch monkey" he has valuable knowledge in comments and critics for patches of every kind. Beside this he knows many areas of the game due to working on applying patches. He is particularly used to answer question from new coders, and doesn't mind explaining trivial stuff.<br />
<br />
If you want to have a feeling of the developer spirit, it is recommended to go to our [[EasyCoding]] page.<br />
<br />
==== Soliton ====<br />
He does know our mp server setup best. Beside this he already has done a lot of work on the mp server himself, too. So he probably has most knowledge about it and due to being one of our mp-developers might provide important help from the perspective of mp-community and what is needed there.<br />
<br />
==== zookeeper or Mythological or Rhuaven ====<br />
As our leading WML expert it would be good to have him in the list when it comes to WML specific problems. That is for work on the scenario editor he probably knows best what should be implemented in it and what is a usable way for things.<br />
<br />
==== YogiHH or Piotr Cychowski (cycholka) ====<br />
Since they are the two developers who know most about building under Windows, they will probably be really helpful. Either if the student comes from the Windows side, or to help test resulting work to make sure that it does work on Windows and, for the case that it does not, to show them where problems are.</div>Grzywaczhttps://wiki.wesnoth.org/index.php?title=SummerOfCodeIdeas&diff=22892SummerOfCodeIdeas2008-02-27T20:45:47Z<p>Grzywacz: Typo fix</p>
<hr />
<div>== Ideas for Google Summer of Code projects ==<br />
<br />
This is a compilation of ideas from ML. Needs to be refined (more detailed description, deliverables, workload estimation?):<br />
<br />
== List of Ideas for the Project ==<br />
<br />
=== Writing an AI based on the formula AI ===<br />
<br />
Wesnoth has always had a simple C++ based AI. David (our lead developer) has been working on a simple language to write AI in wesnoth ''link to formula AI page here'' <br />
<br />
The wesnoth AI is used as an oponent in most campaigns, and as such is an important piece of code for the wesnoth project. Unfortunately it is also one of the most neglected piece of code and a place where a lot of research and work could be done<br />
<br />
==== General description ====<br />
<br />
The aim of this project is to develop a new AI that would replace the original C++ AI. The main criterias we would want for this new AI are<br />
<br />
* ''Plugability :'' It should be trivial for any content maker to change the behavior of the AI in specific case. The exact cases are still to be defined but should typically include<br />
** hardwiring the first few turns of the AI<br />
** changing the recruitment pattern<br />
** completely controlling a given unit (sceneario unit)<br />
** taking control then giving back control of a given unit<br />
* ''tunability :'' It should be easy for a scenario author to specify the general behaviour of the ennemy on a given scenario (agressivity, intrepidity...)<br />
* ''specific behaviours :'' there are some typical behaviours that are not smart to win the scenario but are needed, such as guarding a given unit, a given position, wandering aimlessly, attacking randomly, always fleeing. The AI should implement such behaviours, and allow easy addition of new behaviours<br />
<br />
==== Required knowledge and talent ====<br />
<br />
* ''A minimal knowledge of C++ is required, a good knowledge of C++ is desired :'' The formula AI framework is a work in progress and chances are high that some changes in the wesnoth code base will be needed. The wesnoth developper community is used to handle people that are familiar with coding but not C++, however the Forumla AI framework uses advanced C++ features and a good knowledge of the language would avoid a major hurdle when plugging in new entries or functionalities for the AI<br />
* ''Good social interaction with a large player community :'' A preliminary phase to coding any AI is to know the strategies and game pattern used by human players. This requires huge interaction with the player community. Our Gameplay Developpers are open and can give some good starting points, but a big game experience and good interaction with the player community will greatly help in the study of the design<br />
<br />
==== Milestones and deliverables ====<br />
<br />
It is hard to give milestones at this point, but here are some ideas of what could be done<br />
<br />
* ''AI design description, and basic function library :'' This first deliverable aims to conclude the '''study and analysis''' part of the project : becoming familiar with the formula language, study of the Multiplayer strategies and of the need of scenario writers with regard to AI. We would like to have a description of the code structure of the AI, some basis of the play strategies it would use and how external scenario writers could configure it for the particular behaviour they need<br />
* ''Main AI delivery :'' This milestone's aim is to deliver a working AI implementing the strategies described in the first phase. It would not have to systematically beat the standard C++ AI at this point, but should be able to play the game correctly (recruit, early deployment on villages, grouping units to attack, holding its ground, protecting weak/important units). Moreover most plug-in entries should be available and a test-case for these entries should be provided.<br />
* ''Fine tunning and behaviour library :'' The third phase would validate the actual strategy of the AI. The AI should consistently beat the default C++ AI, and do fairly well against an average human player. At that stage a library of scenario behaviours should also be delivered. The AI does not need to be as efficiant with all scenario tweaking, but should act correctly with regard to the particular behaviour desired.<br />
<br />
<br />
=== Extending the Multiplayer server ===<br />
<br />
When the developement team met at FOSDEM, we had our multiplayer commuinty, though it is strong and healthy, had its growth restrained by the interface of the multiplayer lobby.<br />
<br />
==== General Description ====<br />
The general idea of this project would be<br />
* To study the current lobby,<br />
* To present some ideas of evolutions both in interface and functionalities of our multiplayer interface to allow it to scale to a much larger community<br />
* To present some well constructed thought on our MP community and how that interface would develop it<br />
* Of course to implement those changes :)<br />
<br />
Some ideas that we had (but that are in no way mandatory)<br />
* Having a simple way to register and authentificate nicknames, similar to what IRC offers. The point is not to have cryptographically safe logins, but to have something simple that gets the job done<br />
* Having a simple room system? again inspired on IRC<br />
* Having some way to find the type of games you are interested in.<br />
** game type<br />
** number of free slots/players<br />
** any other criterias you might find interesting<br />
<br />
Other ideas we are not convinced are good, but that are certainly worth studying (especially how the communities based around these concepts are different from ours)<br />
* ranking players<br />
* guilds<br />
* official tournaments<br />
* titles for players<br />
* metaservers<br />
<br />
The scalablity of the project, both in term of number of players, and in term of the possibility for players and developpers to extend the concept will be a valued criteria<br />
<br />
Administration/moderation problems and techniques should also be studied<br />
<br />
interaction with the Add-On server/forum might be an interseting field to expand to<br />
<br />
==== Required knowledge and talent ====<br />
<br />
* A fair amount of experience on C++ is required. Wesnoth uses some advanced C++ features and is heavily based on BOOST and STL. We can train you in some of the libraries used, but learning all of them would be a big hurdle<br />
* Various experience with multiplayer games, in order to have a good idea of what multiplayer lobbies of other game look like, and (more importantly) a good idea of the social behaviours of multiple MP communities, how teams are formed in games and things like that<br />
<br />
==== Milestones and deliverables ====<br />
<br />
* A first milestone would be a presentation summarizing the different studies, and the proposed interface. preliminary unformal stages would probably be desirable, to make sure the proposed idea is already a consensus within devs <br />
** Study of other MP game-matching interfaces and functionalities<br />
** Study of other MP communities<br />
** Study of other MP moderation practices<br />
** Study of the Wesnoth MP community, including needs, various opinons from different developers and players<br />
* A second milestone would be the main code delivery. Code should be functional for it will be delivered in the next Wesnoth developement release<br />
<br />
<br />
=== Other ideas to be fleshed out ===<br />
* Working on the GUI engine (needs to be defined more precisely)<br />
* Rewrite of the campaign (add-on) server<br />
* The editor can use quite a revamp<br />
* A good scenario editor. We have campgen but it hasn't been updated for a while.<br />
<br />
<br />
== Other info to provide for GSoC ==<br />
==== Describe your organization. ====<br />
<br />
==== Why is your organization applying to participate in GSoC 2008? What do you hope to gain by participating?====<br />
<br />
Most of our developpers have interesting areas in which they work. Though they are efficiant in their areas, there are areas that are interesting but have a high barrier of entry.<br />
<br />
By having a student dedicated to any of these areas, we could quickly get someone upto date with that particualr area, efficiant, and responsible of this area.<br />
<br />
Basically, by getting new people in and making them actively responsible for an area of code we hope to kickstart some areas of the project that have lagged behind<br />
<br />
==== Did your organization participate in past GSoCs? If so, please summarize your involvement and the successes and challenges of your participation.====<br />
This is the first time the Wesnoth projects applies to Google SoC<br />
<br />
==== If your organization has not previously participated in GSoC, have you applied in the past? If so, for what year(s)?====<br />
<br />
This is the first time the Wesnoth projects applies to Google SoC<br />
<br />
==== Who will your organization administrator be? Please include Google Account information.====<br />
Nils Kneuper aka Ivanovic<br />
<br />
crazy.ivanovic |ATTT| googlemail.com<br />
<br />
==== What license(s) does your project use?====<br />
Our project is entirely GPL.<br />
<br />
All code is GPL.<br />
<br />
All art is GPL, 99% was made for the project, everything was taken from content that was checked to be GPL.<br />
<br />
==== What is the URL for your ideas page?====<br />
Our main summer of code pages is located at http://www.wesnoth.org/wiki/SummerOfCodeIdeas<br />
<br />
This page contains various coding ideas and the thought the developement team has already given them.<br />
<br />
It also contains a list of the developers that are the most active on IRC and their domain of interes<br />
<br />
==== What is the main development mailing list or forum for your organization?====<br />
Most development work takes place on "wesnoth-dev |ATTT| gna.org". Beside this some work happens at http://www.wesnoth.org/forum/.<br />
<br />
==== What is the main IRC channel for your organization?====<br />
<br />
All our IRC channels are on the ''freenode'' network<br />
<br />
* ''#wesnoth-dev'' is the main development channel, where most discussion takes place<br />
* ''#wesnoth'' is a generic channel for the community<br />
* ''#wesnoth-mp'' is a separate channel for multiplayer games and balancing<br />
<br />
==== Does your organization have an application template you would like to see students use? If so, please provide it now.====<br />
We plan mainly to meet potential students through our IRC channel, but the following questions are wesnoth-specific and are worth pondering for any student, even if we don't need a formal answer<br />
<br />
* What type of gamer are you? What type of games? What type of opponent? Are you more interested in story or gameplay ? <br />
* Are you good at interacting with other players ? Our developer community is quite nice, but the player community can be a bit rough.<br />
* Do you give constructive advices? Do you receive advice well? Are you good at sorting useful criticism from useless ones?<br />
<br />
''''to be completed''''<br />
<br />
==== Who will be your backup organization administrator? Please include Google Account information.====<br />
<br />
Jeremy Rosen alias Boucman<br />
<br />
boucman2@gmail.com<br />
<br />
==== Who will your mentors be? Please include Google Account information.====<br />
<br />
==== What criteria did you use to select these individuals as mentors? Please be as specific as possible.====<br />
<br />
==== What is your plan for dealing with disappearing students?====<br />
<br />
==== What is your plan for dealing with disappearing mentors?====<br />
<br />
==== What steps will you take to encourage students to interact with your project's community before, during and after the program?====<br />
<br />
Wesnoth has a particularly healthy community, both for developers and for players. <br />
<br />
Our general policy regarding new coders has always been "two patch... you're in" In other word, anybody that is able to get two non-trivial patches applied is offered commit right.<br />
<br />
We have a developer responsible for applying patches and guiding new developers into our community. This is a well known and effective process we plan to apply to students, directing them to our [[EasyCoding]] pages (these project are usually a couple of hours long and has been chosen to provide easy access to code)<br />
<br />
Usually, patches go back and forth a couple of time, to make sure that all secondary things are in place (indenting, coding style, modified makefiles etc.) The idea is that coder education should take place before the coder gets commit rights, but that getting new coder in is one of the most important things to maintain our project alive.<br />
<br />
If the student is a little proactive and ready to join IRC, all the developers are usually very welcoming, and good at directing newcomers to quickly give useful results.<br />
<br />
'''to be completed'''<br />
<br />
==== What will you do to ensure that your accepted students stick with the project after GSoC concludes?====<br />
<br />
<br />
<br />
=== People to bug on IRC, possible mentors ===<br />
Everybody feel free to edit/correct his entry!<br />
<br />
==== Dave alias Sirp ====<br />
<br />
Sirp started Wesnoth and is our lead developper. He is currently our C++ expert and is also the one that is working on the new Formula AI. Any questions regarding the formula AI should be directed to him.<br />
<br />
==== Mordante ====<br />
Many of the possible projects do at least partly go into the area of code where he knows most of. Plus many of the possible projects currently listed on the ideas page do require GUI parts to work, too. So if Mordante wants to tackle a rewrite of large parts of this, he will be our expert there as well as he already is our expert for the terrain engine (cf. editor / scenario editor works).<br />
<br />
==== Elias Pscherning (elias) ====<br />
He has written the original version of campgen and as such will know a lot about what is needed to to make such an editor work correctly. The work on a scenario editor might be based upon campgen and as such make his knowledge really helpful.<br />
<br />
==== Karol Nowak (grzywacz) ====<br />
Last year he was participating at GSoC as a student, so he knows at least this side of the medal. Beside this he is our top expert regarding embedded devices support since he is actively working on the gp2x support.<br />
<br />
==== boucman ====<br />
As our "patch monkey" he has valuable knowledge in comments and critics for patches of every kind. Beside this he knows many areas of the game due to working on applying patches. He is particularly used to answer question from new coders, and doesn't mind explaining trivial stuff.<br />
<br />
If you want to have a feeling of the developer spirit, it is recommended to go to our [[EasyCoding]] page.<br />
<br />
==== Soliton ====<br />
He does know our mp server setup best. Beside this he already has done a lot of work on the mp server himself, too. So he probably has most knowledge about it and due to being one of our mp-developers might provide important help from the perspective of mp-community and what is needed there.<br />
<br />
==== zookeeper or Mythological or Rhuaven ====<br />
As our leading WML expert it would be good to have him in the list when it comes to WML specific problems. That is for work on the scenario editor he probably knows best what should be implemented in it and what is a usable way for things.<br />
<br />
==== YogiHH or Piotr Cychowski (cycholka) ====<br />
Since they are the two developers who know most about building under Windows, they will probably be really helpful. Either if the student comes from the Windows side, or to help test resulting work to make sure that it does work on Windows and, for the case that it does not, to show them where problems are.</div>Grzywaczhttps://wiki.wesnoth.org/index.php?title=SummerOfCodeIdeas&diff=22891SummerOfCodeIdeas2008-02-27T20:45:28Z<p>Grzywacz: Typo fixes</p>
<hr />
<div>== Ideas for Google Summer of Code projects ==<br />
<br />
This is a compilation of ideas from ML. Needs to be refined (more detailed description, deliverables, workload estimation?):<br />
<br />
== List of Ideas for the Project ==<br />
<br />
=== Writing an AI based on the formula AI ===<br />
<br />
Wesnoth has always had a simple C++ based AI. David (our lead developer) has been working on a simple language to write AI in wesnoth ''link to formula AI page here'' <br />
<br />
The wesnoth AI is used as an oponent in most campaigns, and as such is an important piece of code for the wesnoth project. Unfortunately it is also one of the most neglected piece of code and a place where a lot of research and work could be done<br />
<br />
==== General description ====<br />
<br />
The aim of this project is to develop a new AI that would replace the original C++ AI. The main criterias we would want for this new AI are<br />
<br />
* ''Plugability :'' It should be trivial for any content maker to change the behavior of the AI in specific case. The exact cases are still to be defined but should typically include<br />
** hardwiring the first few turns of the AI<br />
** changing the recruitment pattern<br />
** completely controlling a given unit (sceneario unit)<br />
** taking control then giving back control of a given unit<br />
* ''tunability :'' It should be easy for a scenario author to specify the general behaviour of the ennemy on a given scenario (agressivity, intrepidity...)<br />
* ''specific behaviours :'' there are some typical behaviours that are not smart to win the scenario but are needed, such as guarding a given unit, a given position, wandering aimlessly, attacking randomly, always fleeing. The AI should implement such behaviours, and allow easy addition of new behaviours<br />
<br />
==== Required knowledge and talent ====<br />
<br />
* ''A minimal knowledge of C++ is required, a good knowledge of C++ is desired :'' The formula AI framework is a work in progress and chances are high that some changes in the wesnoth code base will be needed. The wesnoth developper community is used to handle people that are familiar with coding but not C++, however the Forumla AI framework uses advanced C++ features and a good knowledge of the language would avoid a major hurdle when plugging in new entries or functionalities for the AI<br />
* ''Good social interaction with a large player community :'' A preliminary phase to coding any AI is to know the strategies and game pattern used by human players. This requires huge interaction with the player community. Our Gameplay Developpers are open and can give some good starting points, but a big game experience and good interaction with the player community will greatly help in the study of the design<br />
<br />
==== Milestones and deliverables ====<br />
<br />
It is hard to give milestones at this point, but here are some ideas of what could be done<br />
<br />
* ''AI design description, and basic function library :'' This first deliverable aims to conclude the '''study and analysis''' part of the project : becoming familiar with the formula language, study of the Multiplayer strategies and of the need of scenario writers with regard to AI. We would like to have a description of the code structure of the AI, some basis of the play strategies it would use and how external scenario writers could configure it for the particular behaviour they need<br />
* ''Main AI delivery :'' This milestone's aim is to deliver a working AI implementing the strategies described in the first phase. It would not have to systematically beat the standard C++ AI at this point, but should be able to play the game correctly (recruit, early deployment on villages, grouping units to attack, holding its ground, protecting weak/important units). Moreover most plug-in entries should be available and a test-case for these entries should be provided.<br />
* ''Fine tunning and behaviour library :'' The third phase would validate the actual strategy of the AI. The AI should consistently beat the default C++ AI, and do fairly well against an average human player. At that stage a library of scenario behaviours should also be delivered. The AI does not need to be as efficiant with all scenario tweaking, but should act correctly with regard to the particular behaviour desired.<br />
<br />
<br />
=== Extending the Multiplayer server ===<br />
<br />
When the developement team met at FOSDEM, we had our multiplayer commuinty, though it is strong and healthy, had its growth restrained by the interface of the multiplayer lobby.<br />
<br />
==== General Description ====<br />
The general idea of this project would be<br />
* To study the current lobby,<br />
* To present some ideas of evolutions both in interface and functionalities of our multiplayer interface to allow it to scale to a much larger community<br />
* To present some well constructed thought on our MP community and how that interface would develop it<br />
* Of course to implement those changes :)<br />
<br />
Some ideas that we had (but that are in no way mandatory)<br />
* Having a simple way to register and authentificate nicknames, similar to what IRC offers. The point is not to have cryptographically safe logins, but to have something simple that gets the job done<br />
* Having a simple room system? again inspired on IRC<br />
* Having some way to find the type of games you are interested in.<br />
** game type<br />
** number of free slots/players<br />
** any other criterias you might find interesting<br />
<br />
Other ideas we are not convinced are good, but that are certainly worth studying (especially how the communities based around these concepts are different from ours)<br />
* ranking players<br />
* guilds<br />
* official tournaments<br />
* titles for players<br />
* metaservers<br />
<br />
The scalablity of the project, both in term of number of players, and in term of the possibility for players and developpers to extend the concept will be a valued criteria<br />
<br />
Administration/moderation problems and techniques should also be studied<br />
<br />
interaction with the Add-On server/forum might be an interseting field to expand to<br />
<br />
==== Required knowledge and talent ====<br />
<br />
* A fair amount of experience on C++ is required. Wesnoth uses some advanced C++ features and is heavily based on BOOST and STL. We can train you in some of the libraries used, but learning all of them would be a big hurdle<br />
* Various experience with multiplayer games, in order to have a good idea of what multiplayer lobbies of other game look like, and (more importantly) a good idea of the social behaviours of multiple MP communities, how teams are formed in games and things like that<br />
<br />
==== Milestones and deliverables ====<br />
<br />
* A first milestone would be a presentation summarizing the different studies, and the proposed interface. preliminary unformal stages would probably be desirable, to make sure the proposed idea is already a consensus within devs <br />
** Study of other MP game-matching interfaces and functionalities<br />
** Study of other MP communities<br />
** Study of other MP moderation practices<br />
** Study of the Wesnoth MP community, including needs, various opinons from different developers and players<br />
* A second milestone would be the main code delivery. Code should be functional for it will be delivered in the next Wesnoth developement release<br />
<br />
<br />
=== Other ideas to be fleshed out ===<br />
* Working on the GUI engine (needs to be defined more precisely)<br />
* Rewrite of the campaign (add-on) server<br />
* The editor can use quite a revamp<br />
* A good scenario editor. We have campgen but it hasn't been updated for a while.<br />
<br />
<br />
== Other info to provide for GSoC ==<br />
==== Describe your organization. ====<br />
<br />
==== Why is your organization applying to participate in GSoC 2008? What do you hope to gain by participating?====<br />
<br />
Most of our developpers have interesting areas in which they work. Though they are efficiant in their areas, there are areas that are interesting but have a high barrier of entry.<br />
<br />
By having a student dedicated to any of these areas, we could quickly get someone upto date with that particualr area, efficiant, and responsible of this area.<br />
<br />
Basically, by getting new people in and making them actively responsible for an area of code we hope to kickstart some areas of the project that have lagged behind<br />
<br />
==== Did your organization participate in past GSoCs? If so, please summarize your involvement and the successes and challenges of your participation.====<br />
This is the first time the Wesnoth projects applies to Google SoC<br />
<br />
==== If your organization has not previously participated in GSoC, have you applied in the past? If so, for what year(s)?====<br />
<br />
This is the first time the Wesnoth projects applies to Google SoC<br />
<br />
==== Who will your organization administrator be? Please include Google Account information.====<br />
Nils Kneuper aka Ivanovic<br />
<br />
crazy.ivanovic |ATTT| googlemail.com<br />
<br />
==== What license(s) does your project use?====<br />
Our project is entirely GPL.<br />
<br />
All code is GPL.<br />
<br />
All art is GPL, 99% was made for the project, everything was taken from content that was checked to be GPL.<br />
<br />
==== What is the URL for your ideas page?====<br />
Our main summer of code pages is located at http://www.wesnoth.org/wiki/SummerOfCodeIdeas<br />
<br />
This page contains various coding ideas and the thought the developement team has already given them.<br />
<br />
It also contains a list of the developers that are the most active on IRC and their domain of interes<br />
<br />
==== What is the main development mailing list or forum for your organization?====<br />
Most development work takes place on "wesnoth-dev |ATTT| gna.org". Beside this some work happens at http://www.wesnoth.org/forum/.<br />
<br />
==== What is the main IRC channel for your organization?====<br />
<br />
All our IRC channels are on the ''freenode'' network<br />
<br />
* ''#wesnoth-dev'' is the main developement channel, where most discussion takes place<br />
* ''#wesnoth'' is a generic channel for the community<br />
* ''#wesnoth-mp'' is a separate channel for multiplayer games and balancing<br />
<br />
==== Does your organization have an application template you would like to see students use? If so, please provide it now.====<br />
We plan mainly to meet potential students through our IRC channel, but the following questions are wesnoth-specific and are worth pondering for any student, even if we don't need a formal answer<br />
<br />
* What type of gamer are you? What type of games? What type of opponent? Are you more interested in story or gameplay ? <br />
* Are you good at interacting with other players ? Our developer community is quite nice, but the player community can be a bit rough.<br />
* Do you give constructive advices? Do you receive advice well? Are you good at sorting useful criticism from useless ones?<br />
<br />
''''to be completed''''<br />
<br />
==== Who will be your backup organization administrator? Please include Google Account information.====<br />
<br />
Jeremy Rosen alias Boucman<br />
<br />
boucman2@gmail.com<br />
<br />
==== Who will your mentors be? Please include Google Account information.====<br />
<br />
==== What criteria did you use to select these individuals as mentors? Please be as specific as possible.====<br />
<br />
==== What is your plan for dealing with disappearing students?====<br />
<br />
==== What is your plan for dealing with disappearing mentors?====<br />
<br />
==== What steps will you take to encourage students to interact with your project's community before, during and after the program?====<br />
<br />
Wesnoth has a particularly healthy community, both for developers and for players. <br />
<br />
Our general policy regarding new coders has always been "two patch... you're in" In other word, anybody that is able to get two non-trivial patches applied is offered commit right.<br />
<br />
We have a developer responsible for applying patches and guiding new developers into our community. This is a well known and effective process we plan to apply to students, directing them to our [[EasyCoding]] pages (these project are usually a couple of hours long and has been chosen to provide easy access to code)<br />
<br />
Usually, patches go back and forth a couple of time, to make sure that all secondary things are in place (indenting, coding style, modified makefiles etc.) The idea is that coder education should take place before the coder gets commit rights, but that getting new coder in is one of the most important things to maintain our project alive.<br />
<br />
If the student is a little proactive and ready to join IRC, all the developers are usually very welcoming, and good at directing newcomers to quickly give useful results.<br />
<br />
'''to be completed'''<br />
<br />
==== What will you do to ensure that your accepted students stick with the project after GSoC concludes?====<br />
<br />
<br />
<br />
=== People to bug on IRC, possible mentors ===<br />
Everybody feel free to edit/correct his entry!<br />
<br />
==== Dave alias Sirp ====<br />
<br />
Sirp started Wesnoth and is our lead developper. He is currently our C++ expert and is also the one that is working on the new Formula AI. Any questions regarding the formula AI should be directed to him.<br />
<br />
==== Mordante ====<br />
Many of the possible projects do at least partly go into the area of code where he knows most of. Plus many of the possible projects currently listed on the ideas page do require GUI parts to work, too. So if Mordante wants to tackle a rewrite of large parts of this, he will be our expert there as well as he already is our expert for the terrain engine (cf. editor / scenario editor works).<br />
<br />
==== Elias Pscherning (elias) ====<br />
He has written the original version of campgen and as such will know a lot about what is needed to to make such an editor work correctly. The work on a scenario editor might be based upon campgen and as such make his knowledge really helpful.<br />
<br />
==== Karol Nowak (grzywacz) ====<br />
Last year he was participating at GSoC as a student, so he knows at least this side of the medal. Beside this he is our top expert regarding embedded devices support since he is actively working on the gp2x support.<br />
<br />
==== boucman ====<br />
As our "patch monkey" he has valuable knowledge in comments and critics for patches of every kind. Beside this he knows many areas of the game due to working on applying patches. He is particularly used to answer question from new coders, and doesn't mind explaining trivial stuff.<br />
<br />
If you want to have a feeling of the developer spirit, it is recommended to go to our [[EasyCoding]] page.<br />
<br />
==== Soliton ====<br />
He does know our mp server setup best. Beside this he already has done a lot of work on the mp server himself, too. So he probably has most knowledge about it and due to being one of our mp-developers might provide important help from the perspective of mp-community and what is needed there.<br />
<br />
==== zookeeper or Mythological or Rhuaven ====<br />
As our leading WML expert it would be good to have him in the list when it comes to WML specific problems. That is for work on the scenario editor he probably knows best what should be implemented in it and what is a usable way for things.<br />
<br />
==== YogiHH or Piotr Cychowski (cycholka) ====<br />
Since they are the two developers who know most about building under Windows, they will probably be really helpful. Either if the student comes from the Windows side, or to help test resulting work to make sure that it does work on Windows and, for the case that it does not, to show them where problems are.</div>Grzywaczhttps://wiki.wesnoth.org/index.php?title=SummerOfCodeIdeas&diff=22890SummerOfCodeIdeas2008-02-27T20:40:36Z<p>Grzywacz: Typo fixes</p>
<hr />
<div>== Ideas for Google Summer of Code projects ==<br />
<br />
This is a compilation of ideas from ML. Needs to be refined (more detailed description, deliverables, workload estimation?):<br />
<br />
== List of Ideas for the Project ==<br />
<br />
=== Writing an AI based on the formula AI ===<br />
<br />
Wesnoth has always had a simple C++ based AI. David (our lead developer) has been working on a simple language to write AI in wesnoth ''link to formula AI page here'' <br />
<br />
The wesnoth AI is used as an oponent in most campaigns, and as such is an important piece of code for the wesnoth project. Unfortunately it is also one of the most neglected piece of code and a place where a lot of research and work could be done<br />
<br />
==== General description ====<br />
<br />
The aim of this project is to develop a new AI that would replace the original C++ AI. The main criterias we would want for this new AI are<br />
<br />
* ''Plugability :'' It should be trivial for any content maker to change the behavior of the AI in specific case. The exact cases are still to be defined but should typically include<br />
** hardwiring the first few turns of the AI<br />
** changing the recruitment pattern<br />
** completely controlling a given unit (sceneario unit)<br />
** taking control then giving back control of a given unit<br />
* ''tunability :'' It should be easy for a scenario author to specify the general behaviour of the ennemy on a given scenario (agressivity, intrepidity...)<br />
* ''specific behaviours :'' there are some typical behaviours that are not smart to win the scenario but are needed, such as guarding a given unit, a given position, wandering aimlessly, attacking randomly, always fleeing. The AI should implement such behaviours, and allow easy addition of new behaviours<br />
<br />
==== Required knowledge and talent ====<br />
<br />
* ''A minimal knowledge of C++ is required, a good knowledge of C++ is desired :'' The formula AI framework is a work in progress and chances are high that some changes in the wesnoth code base will be needed. The wesnoth developper community is used to handle people that are familiar with coding but not C++, however the Forumla AI framework uses advanced C++ features and a good knowledge of the language would avoid a major hurdle when plugging in new entries or functionalities for the AI<br />
* ''Good social interaction with a large player community :'' A preliminary phase to coding any AI is to know the strategies and game pattern used by human players. This requires huge interaction with the player community. Our Gameplay Developpers are open and can give some good starting points, but a big game experience and good interaction with the player community will greatly help in the study of the design<br />
<br />
==== Milestones and deliverables ====<br />
<br />
It is hard to give milestones at this point, but here are some ideas of what could be done<br />
<br />
* ''AI design description, and basic function library :'' This first deliverable aims to conclude the '''study and analysis''' part of the project : becoming familiar with the formula language, study of the Multiplayer strategies and of the need of scenario writers with regard to AI. We would like to have a description of the code structure of the AI, some basis of the play strategies it would use and how external scenario writers could configure it for the particular behaviour they need<br />
* ''Main AI delivery :'' This milestone's aim is to deliver a working AI implementing the strategies described in the first phase. It would not have to systematically beat the standard C++ AI at this point, but should be able to play the game correctly (recruit, early deployment on villages, grouping units to attack, holding its ground, protecting weak/important units). Moreover most plug-in entries should be available and a test-case for these entries should be provided.<br />
* ''Fine tunning and behaviour library :'' The third phase would validate the actual strategy of the AI. The AI should consistently beat the default C++ AI, and do fairly well against an average human player. At that stage a library of scenario behaviours should also be delivered. The AI does not need to be as efficiant with all scenario tweaking, but should act correctly with regard to the particular behaviour desired.<br />
<br />
<br />
=== Extending the Multiplayer server ===<br />
<br />
When the developement team met at FOSDEM, we had our multiplayer commuinty, though it is strong and healthy, had its growth restrained by the interface of the multiplayer lobby.<br />
<br />
==== General Description ====<br />
The general idea of this project would be<br />
* To study the current lobby,<br />
* To present some ideas of evolutions both in interface and functionalities of our multiplayer interface to allow it to scale to a much larger community<br />
* To present some well constructed thought on our MP community and how that interface would develop it<br />
* Of course to implement those changes :)<br />
<br />
Some ideas that we had (but that are in no way mandatory)<br />
* Having a simple way to register and authentificate nicknames, similar to what IRC offers. The point is not to have cryptographically safe logins, but to have something simple that gets the job done<br />
* Having a simple room system? again inspired on IRC<br />
* Having some way to find the type of games you are interested in.<br />
** game type<br />
** number of free slots/players<br />
** any other criterias you might find interesting<br />
<br />
Other ideas we are not convinced are good, but that are certainly worth studying (especially how the communities based around these concepts are different from ours)<br />
* ranking players<br />
* guilds<br />
* official tournaments<br />
* titles for players<br />
* metaservers<br />
<br />
The scalablity of the project, both in term of number of players, and in term of the possibility for players and developpers to extend the concept will be a valued criteria<br />
<br />
Administration/moderation problems and techniques should also be studied<br />
<br />
interaction with the Add-On server/forum might be an interseting field to expand to<br />
<br />
==== Required knowledge and talent ====<br />
<br />
* A fair amount of experience on C++ is required. Wesnoth uses some advanced C++ features and is heavily based on BOOST and STL. We can train you in some of the libraries used, but learning all of them would be a big hurdle<br />
* Various experience with multiplayer games, in order to have a good idea of what multiplayer lobbies of other game look like, and (more importantly) a good idea of the social behaviours of multiple MP communities, how teams are formed in games and things like that<br />
<br />
==== Milestones and deliverables ====<br />
<br />
* A first milestone would be a presentation summarizing the different studies, and the proposed interface. preliminary unformal stages would probably be desirable, to make sure the proposed idea is already a consensus within devs <br />
** Study of other MP game-matching interfaces and functionalities<br />
** Study of other MP communities<br />
** Study of other MP moderation practices<br />
** Study of the Wesnoth MP community, including needs, various opinons from different developers and players<br />
* A second milestone would be the main code delivery. Code should be functional for it will be delivered in the next Wesnoth developement release<br />
<br />
<br />
=== Other ideas to be fleshed out ===<br />
* Working on the GUI engine (needs to be defined more precisely)<br />
* Rewrite of the campaign (add-on) server<br />
* The editor can use quite a revamp<br />
* A good scenario editor. We have campgen but it hasn't been updated for a while.<br />
<br />
<br />
== Other info to provide for GSoC ==<br />
==== Describe your organization. ====<br />
<br />
==== Why is your organization applying to participate in GSoC 2008? What do you hope to gain by participating?====<br />
<br />
Most of our developpers have interesting areas in which they work. Though they are efficiant in their areas, there are areas that are interesting but have a high barrier of entry.<br />
<br />
By having a student dedicated to any of these areas, we could quickly get someone upto date with that particualr area, efficiant, and responsible of this area.<br />
<br />
Basically, by getting new people in and making them actively responsible for an area of code we hope to kickstart some areas of the project that have lagged behind<br />
<br />
==== Did your organization participate in past GSoCs? If so, please summarize your involvement and the successes and challenges of your participation.====<br />
This is the first time the Wesnoth projects applies to Google SoC<br />
<br />
==== If your organization has not previously participated in GSoC, have you applied in the past? If so, for what year(s)?====<br />
<br />
This is the first time the Wesnoth projects applies to Google SoC<br />
<br />
==== Who will your organization administrator be? Please include Google Account information.====<br />
Nils Kneuper aka Ivanovic<br />
<br />
crazy.ivanovic |ATTT| googlemail.com<br />
<br />
==== What license(s) does your project use?====<br />
Our project is entirely GPL.<br />
<br />
All code is GPL.<br />
<br />
All art is GPL, 99% was made for the project, everything was taken from content that was checked to be GPL.<br />
<br />
==== What is the URL for your ideas page?====<br />
Our main summer of code pages is located at http://www.wesnoth.org/wiki/SummerOfCodeIdeas<br />
<br />
This page contains various coding ideas and the thought the developement team has already given them.<br />
<br />
It also contains a list of the developers that are the most active on IRC and their domain of interes<br />
<br />
==== What is the main development mailing list or forum for your organization?====<br />
Most development work takes place on "wesnoth-dev |ATTT| gna.org". Beside this some work happens at http://www.wesnoth.org/forum/.<br />
<br />
==== What is the main IRC channel for your organization?====<br />
<br />
All our IRC channels are on the ''freenode'' network<br />
<br />
* ''#wesnoth-dev'' is the main developement channel, where most discussion takes place<br />
* ''#wesnoth'' is a generic channel for the community<br />
* ''#wesnoth-mp'' is a separate channel for multiplayer games and balancing<br />
<br />
==== Does your organization have an application template you would like to see students use? If so, please provide it now.====<br />
We plan mainly to meet potential students through our IRC channel, but the following questions are wesnothspecific and are worth pondering for any student, even if we don't need a formal answer<br />
<br />
* What type of gamer are you ? What type of games ? what type of oponents ? are you more interested in story or gameplay ? <br />
* Are you good at interacting with other players ? Our developer community is quite nice, but the player community can be a bit rough.<br />
* Do you give constructive advices ? Do you receive advice well ? are you good at sorting usefull criticism from useless ones ?<br />
<br />
''''to be completed''''<br />
<br />
==== Who will be your backup organization administrator? Please include Google Account information.====<br />
<br />
Jeremy Rosen alias Boucman<br />
<br />
boucman2@gmail.com<br />
<br />
==== Who will your mentors be? Please include Google Account information.====<br />
<br />
==== What criteria did you use to select these individuals as mentors? Please be as specific as possible.====<br />
<br />
==== What is your plan for dealing with disappearing students?====<br />
<br />
==== What is your plan for dealing with disappearing mentors?====<br />
<br />
==== What steps will you take to encourage students to interact with your project's community before, during and after the program?====<br />
<br />
Wesnoth has a particularly healthy community, both for developers and for players. <br />
<br />
Our general policy regarding new coders has always been "two patch... you're in" In other word, anybody that is able to get two non-trivial patches applied is offered commit right.<br />
<br />
We have a developer responsible for applying patches and guiding new developers into our community. This is a well known and effective process we plan to apply to students, directing them to our [[EasyCoding]] pages (these project are usually a couple of hours long and has been chosen to provide easy access to code)<br />
<br />
Usually, patches go back and forth a couple of time, to make sure that all secondary things are in place (indenting, coding style, modified makefiles etc.) The idea is that coder education should take place before the coder gets commit rights, but that getting new coder in is one of the most important things to maintain our project alive.<br />
<br />
If the student is a little proactive and ready to join IRC, all the developers are usually very welcoming, and good at directing newcomers to quickly give useful results.<br />
<br />
'''to be completed'''<br />
<br />
==== What will you do to ensure that your accepted students stick with the project after GSoC concludes?====<br />
<br />
<br />
<br />
=== People to bug on IRC, possible mentors ===<br />
Everybody feel free to edit/correct his entry!<br />
<br />
==== Dave alias Sirp ====<br />
<br />
Sirp started Wesnoth and is our lead developper. He is currently our C++ expert and is also the one that is working on the new Formula AI. Any questions regarding the formula AI should be directed to him.<br />
<br />
==== Mordante ====<br />
Many of the possible projects do at least partly go into the area of code where he knows most of. Plus many of the possible projects currently listed on the ideas page do require GUI parts to work, too. So if Mordante wants to tackle a rewrite of large parts of this, he will be our expert there as well as he already is our expert for the terrain engine (cf. editor / scenario editor works).<br />
<br />
==== Elias Pscherning (elias) ====<br />
He has written the original version of campgen and as such will know a lot about what is needed to to make such an editor work correctly. The work on a scenario editor might be based upon campgen and as such make his knowledge really helpful.<br />
<br />
==== Karol Nowak (grzywacz) ====<br />
Last year he was participating at GSoC as a student, so he knows at least this side of the medal. Beside this he is our top expert regarding embedded devices support since he is actively working on the gp2x support.<br />
<br />
==== boucman ====<br />
As our "patch monkey" he has valuable knowledge in comments and critics for patches of every kind. Beside this he knows many areas of the game due to working on applying patches. He is particularly used to answer question from new coders, and doesn't mind explaining trivial stuff.<br />
<br />
If you want to have a feeling of the developer spirit, it is recommended to go to our [[EasyCoding]] page.<br />
<br />
==== Soliton ====<br />
He does know our mp server setup best. Beside this he already has done a lot of work on the mp server himself, too. So he probably has most knowledge about it and due to being one of our mp-developers might provide important help from the perspective of mp-community and what is needed there.<br />
<br />
==== zookeeper or Mythological or Rhuaven ====<br />
As our leading WML expert it would be good to have him in the list when it comes to WML specific problems. That is for work on the scenario editor he probably knows best what should be implemented in it and what is a usable way for things.<br />
<br />
==== YogiHH or Piotr Cychowski (cycholka) ====<br />
Since they are the two developers who know most about building under Windows, they will probably be really helpful. Either if the student comes from the Windows side, or to help test resulting work to make sure that it does work on Windows and, for the case that it does not, to show them where problems are.</div>Grzywaczhttps://wiki.wesnoth.org/index.php?title=SummerOfCodeIdeas&diff=22889SummerOfCodeIdeas2008-02-27T20:38:06Z<p>Grzywacz: Typo fix</p>
<hr />
<div>== Ideas for Google Summer of Code projects ==<br />
<br />
This is a compilation of ideas from ML. Needs to be refined (more detailed description, deliverables, workload estimation?):<br />
<br />
== List of Ideas for the Project ==<br />
<br />
=== Writing an AI based on the formula AI ===<br />
<br />
Wesnoth has always had a simple C++ based AI. David (our lead developer) has been working on a simple language to write AI in wesnoth ''link to formula AI page here'' <br />
<br />
The wesnoth AI is used as an oponent in most campaigns, and as such is an important piece of code for the wesnoth project. Unfortunately it is also one of the most neglected piece of code and a place where a lot of research and work could be done<br />
<br />
==== General description ====<br />
<br />
The aim of this project is to develop a new AI that would replace the original C++ AI. The main criterias we would want for this new AI are<br />
<br />
* ''Plugability :'' It should be trivial for any content maker to change the behavior of the AI in specific case. The exact cases are still to be defined but should typically include<br />
** hardwiring the first few turns of the AI<br />
** changing the recruitment pattern<br />
** completely controlling a given unit (sceneario unit)<br />
** taking control then giving back control of a given unit<br />
* ''tunability :'' It should be easy for a scenario author to specify the general behaviour of the ennemy on a given scenario (agressivity, intrepidity...)<br />
* ''specific behaviours :'' there are some typical behaviours that are not smart to win the scenario but are needed, such as guarding a given unit, a given position, wandering aimlessly, attacking randomly, always fleeing. The AI should implement such behaviours, and allow easy addition of new behaviours<br />
<br />
==== Required knowledge and talent ====<br />
<br />
* ''A minimal knowledge of C++ is required, a good knowledge of C++ is desired :'' The formula AI framework is a work in progress and chances are high that some changes in the wesnoth code base will be needed. The wesnoth developper community is used to handle people that are familiar with coding but not C++, however the Forumla AI framework uses advanced C++ features and a good knowledge of the language would avoid a major hurdle when plugging in new entries or functionalities for the AI<br />
* ''Good social interaction with a large player community :'' A preliminary phase to coding any AI is to know the strategies and game pattern used by human players. This requires huge interaction with the player community. Our Gameplay Developpers are open and can give some good starting points, but a big game experience and good interaction with the player community will greatly help in the study of the design<br />
<br />
==== Milestones and deliverables ====<br />
<br />
It is hard to give milestones at this point, but here are some ideas of what could be done<br />
<br />
* ''AI design description, and basic function library :'' This first deliverable aims to conclude the '''study and analysis''' part of the project : becoming familiar with the formula language, study of the Multiplayer strategies and of the need of scenario writers with regard to AI. We would like to have a description of the code structure of the AI, some basis of the play strategies it would use and how external scenario writers could configure it for the particular behaviour they need<br />
* ''Main AI delivery :'' This milestone's aim is to deliver a working AI implementing the strategies described in the first phase. It would not have to systematically beat the standard C++ AI at this point, but should be able to play the game correctly (recruit, early deployment on villages, grouping units to attack, holding its ground, protecting weak/important units). Moreover most plug-in entries should be available and a test-case for these entries should be provided.<br />
* ''Fine tunning and behaviour library :'' The third phase would validate the actual strategy of the AI. The AI should consistently beat the default C++ AI, and do fairly well against an average human player. At that stage a library of scenario behaviours should also be delivered. The AI does not need to be as efficiant with all scenario tweaking, but should act correctly with regard to the particular behaviour desired.<br />
<br />
<br />
=== Extending the Multiplayer server ===<br />
<br />
When the developement team met at FOSDEM, we had our multiplayer commuinty, though it is strong and healthy, had its growth restrained by the interface of the multiplayer lobby.<br />
<br />
==== General Description ====<br />
The general idea of this project would be<br />
* To study the current lobby,<br />
* To present some ideas of evolutions both in interface and functionalities of our multiplayer interface to allow it to scale to a much larger community<br />
* To present some well constructed thought on our MP community and how that interface would develop it<br />
* Of course to implement those changes :)<br />
<br />
Some ideas that we had (but that are in no way mandatory)<br />
* Having a simple way to register and authentificate nicknames, similar to what IRC offers. The point is not to have cryptographically safe logins, but to have something simple that gets the job done<br />
* Having a simple room system? again inspired on IRC<br />
* Having some way to find the type of games you are interested in.<br />
** game type<br />
** number of free slots/players<br />
** any other criterias you might find interesting<br />
<br />
Other ideas we are not convinced are good, but that are certainly worth studying (especially how the communities based around these concepts are different from ours)<br />
* ranking players<br />
* guilds<br />
* official tournaments<br />
* titles for players<br />
* metaservers<br />
<br />
The scalablity of the project, both in term of number of players, and in term of the possibility for players and developpers to extend the concept will be a valued criteria<br />
<br />
Administration/moderation problems and techniques should also be studied<br />
<br />
interaction with the Add-On server/forum might be an interseting field to expand to<br />
<br />
==== Required knowledge and talent ====<br />
<br />
* A fair amount of experience on C++ is required. Wesnoth uses some advanced C++ features and is heavily based on BOOST and STL. We can train you in some of the libraries used, but learning all of them would be a big hurdle<br />
* Various experience with multiplayer games, in order to have a good idea of what multiplayer lobbies of other game look like, and (more importantly) a good idea of the social behaviours of multiple MP communities, how teams are formed in games and things like that<br />
<br />
==== Milestones and deliverables ====<br />
<br />
* A first milestone would be a presentation summarizing the different studies, and the proposed interface. preliminary unformal stages would probably be desirable, to make sure the proposed idea is already a consensus within devs <br />
** Study of other MP game-matching interfaces and functionalities<br />
** Study of other MP communities<br />
** Study of other MP moderation practices<br />
** Study of the Wesnoth MP community, including needs, various opinons from different developers and players<br />
* A second milestone would be the main code delivery. Code should be functional for it will be delivered in the next Wesnoth developement release<br />
<br />
<br />
=== Other ideas to be fleshed out ===<br />
* Working on the GUI engine (needs to be defined more precisely)<br />
* Rewrite of the campaign (add-on) server<br />
* The editor can use quite a revamp<br />
* A good scenario editor. We have campgen but it hasn't been updated for a while.<br />
<br />
<br />
== Other info to provide for GSoC ==<br />
==== Describe your organization. ====<br />
<br />
==== Why is your organization applying to participate in GSoC 2008? What do you hope to gain by participating?====<br />
<br />
Most of our developpers have interesting areas in which they work. Though they are efficiant in their areas, there are areas that are interesting but have a high barrier of entry.<br />
<br />
By having a student dedicated to any of these areas, we could quickly get someone upto date with that particualr area, efficiant, and responsible of this area.<br />
<br />
Basically, by getting new people in and making them actively responsible for an area of code we hope to kickstart some areas of the project that have lagged behind<br />
<br />
==== Did your organization participate in past GSoCs? If so, please summarize your involvement and the successes and challenges of your participation.====<br />
This is the first time the Wesnoth projects applies to Google SoC<br />
<br />
==== If your organization has not previously participated in GSoC, have you applied in the past? If so, for what year(s)?====<br />
<br />
This is the first time the Wesnoth projects applies to Google SoC<br />
<br />
==== Who will your organization administrator be? Please include Google Account information.====<br />
Nils Kneuper aka Ivanovic<br />
<br />
crazy.ivanovic |ATTT| googlemail.com<br />
<br />
==== What license(s) does your project use?====<br />
Our project is entirely GPL.<br />
<br />
All code is GPL.<br />
<br />
All art is GPL, 99% was made for the project, everything was taken from content that was checked to be GPL.<br />
<br />
==== What is the URL for your ideas page?====<br />
Our main summer of code pages is located at http://www.wesnoth.org/wiki/SummerOfCodeIdeas<br />
<br />
This page contains various coding ideas and the thought the developement team has already given them.<br />
<br />
It also contains a list of the developers that are the most active on IRC and their domain of interes<br />
<br />
==== What is the main development mailing list or forum for your organization?====<br />
Most development work takes place on "wesnoth-dev |ATTT| gna.org". Beside this some work happens at http://www.wesnoth.org/forum/.<br />
<br />
==== What is the main IRC channel for your organization?====<br />
<br />
All our IRC channels are on the ''freenode'' network<br />
<br />
* ''#wesnoth-dev'' is the main developement channel, where most discussion takes place<br />
* ''#wesnoth'' is a generic channel for the community<br />
* ''#wesnoth-mp'' is a separate channel for multiplayer games and balancing<br />
<br />
==== Does your organization have an application template you would like to see students use? If so, please provide it now.====<br />
We plan mainly to meet potential students through our IRC channel, but the following questions are wesnothspecific and are worth pondering for any student, even if we don't need a formal answer<br />
<br />
* What type of gamer are you ? What type of games ? what type of oponents ? are you more interested in story or gameplay ? <br />
* Are you good at interacting with other players ? Our developer community is quite nice, but the player community can be a bit rough.<br />
* Do you give constructive advices ? Do you receive advice well ? are you good at sorting usefull criticism from useless ones ?<br />
<br />
''''to be completed''''<br />
<br />
==== Who will be your backup organization administrator? Please include Google Account information.====<br />
<br />
Jeremy Rosen alias Boucman<br />
<br />
boucman2@gmail.com<br />
<br />
==== Who will your mentors be? Please include Google Account information.====<br />
<br />
==== What criteria did you use to select these individuals as mentors? Please be as specific as possible.====<br />
<br />
==== What is your plan for dealing with disappearing students?====<br />
<br />
==== What is your plan for dealing with disappearing mentors?====<br />
<br />
==== What steps will you take to encourage students to interact with your project's community before, during and after the program?====<br />
<br />
Wesnoth has a particularly healthy commutnity, both for developers and for players. <br />
<br />
Our general policy regarding new coders has always been "two patch... you're in" In other word, anybody that is able to get two non-trivial patches applied is offered commit right.<br />
<br />
We have a developer responsible for applying patches and guiding new developpers into our community. This is a well known and effective process we plan to apply to students, directing them to our [[EasyCoding]] pages (these project are usually a couple of hours long and has been chosen to provide easy access to code)<br />
<br />
Usually, patches goback and fortha couple of time, to make sure that all secondary things are in place (indenting, coding style, modified makefiles etc.) The idea is that coder education should take place before thecoder has commit rights, but that getting new coder in is one of the most important things to maintain our project alive.<br />
<br />
If the student is a little proactive and ready to join IRC, all the developers are usually very welcoming, and good at directing newcomers to quickly give usefull results.<br />
<br />
'''to be completed'''<br />
<br />
==== What will you do to ensure that your accepted students stick with the project after GSoC concludes?====<br />
<br />
<br />
<br />
=== People to bug on IRC, possible mentors ===<br />
Everybody feel free to edit/correct his entry!<br />
<br />
==== Dave alias Sirp ====<br />
<br />
Sirp started Wesnoth and is our lead developper. He is currently our C++ expert and is also the one that is working on the new Formula AI. Any questions regarding the formula AI should be directed to him.<br />
<br />
==== Mordante ====<br />
Many of the possible projects do at least partly go into the area of code where he knows most of. Plus many of the possible projects currently listed on the ideas page do require GUI parts to work, too. So if Mordante wants to tackle a rewrite of large parts of this, he will be our expert there as well as he already is our expert for the terrain engine (cf. editor / scenario editor works).<br />
<br />
==== Elias Pscherning (elias) ====<br />
He has written the original version of campgen and as such will know a lot about what is needed to to make such an editor work correctly. The work on a scenario editor might be based upon campgen and as such make his knowledge really helpful.<br />
<br />
==== Karol Nowak (grzywacz) ====<br />
Last year he was participating at GSoC as a student, so he knows at least this side of the medal. Beside this he is our top expert regarding embedded devices support since he is actively working on the gp2x support.<br />
<br />
==== boucman ====<br />
As our "patch monkey" he has valuable knowledge in comments and critics for patches of every kind. Beside this he knows many areas of the game due to working on applying patches. He is particularly used to answer question from new coders, and doesn't mind explaining trivial stuff.<br />
<br />
If you want to have a feeling of the developer spirit, it is recommended to go to our [[EasyCoding]] page.<br />
<br />
==== Soliton ====<br />
He does know our mp server setup best. Beside this he already has done a lot of work on the mp server himself, too. So he probably has most knowledge about it and due to being one of our mp-developers might provide important help from the perspective of mp-community and what is needed there.<br />
<br />
==== zookeeper or Mythological or Rhuaven ====<br />
As our leading WML expert it would be good to have him in the list when it comes to WML specific problems. That is for work on the scenario editor he probably knows best what should be implemented in it and what is a usable way for things.<br />
<br />
==== YogiHH or Piotr Cychowski (cycholka) ====<br />
Since they are the two developers who know most about building under Windows, they will probably be really helpful. Either if the student comes from the Windows side, or to help test resulting work to make sure that it does work on Windows and, for the case that it does not, to show them where problems are.</div>Grzywaczhttps://wiki.wesnoth.org/index.php?title=SummerOfCodeIdeas&diff=22888SummerOfCodeIdeas2008-02-27T20:27:09Z<p>Grzywacz: Added elias' real name</p>
<hr />
<div>== Ideas for Google Summer of Code projects ==<br />
<br />
This is a compilation of ideas from ML. Needs to be refined (more detailed description, deliverables, workload estimation?):<br />
<br />
== List of Ideas for the Project ==<br />
<br />
=== Writing an AI based on the formula AI ===<br />
<br />
Wesnoth has always had a simple C++ based AI. David (our lead developer) has been working on a simple language to write AI in wesnoth ''link to formula AI page here'' <br />
<br />
The wesnoth AI is used as an oponent in most campaigns, and as such is an important piece of code for the wesnoth project. Unfortunately it is also one of the most neglected piece of code and a place where a lot of research and work could be done<br />
<br />
==== General description ====<br />
<br />
The aim of this project is to develop a new AI that would replace the original C++ AI. The main criterias we would want for this new AI are<br />
<br />
* ''Plugability :'' It should be trivial for any content maker to change the behavior of the AI in specific case. The exact cases are still to be defined but should typically include<br />
** hardwiring the first few turns of the AI<br />
** changing the recruitment pattern<br />
** completely controlling a given unit (sceneario unit)<br />
** taking control then giving back control of a given unit<br />
* ''tunability :'' It should be easy for a scenario author to specify the general behaviour of the ennemy on a given scenario (agressivity, intrepidity...)<br />
* ''specific behaviours :'' there are some typical behaviours that are not smart to win the scenario but are needed, such as guarding a given unit, a given position, wandering aimlessly, attacking randomly, always fleeing. The AI should implement such behaviours, and allow easy addition of new behaviours<br />
<br />
==== Required knowledge and talent ====<br />
<br />
* ''A minimal knowledge of C++ is required, a good knowledge of C++ is desired :'' The formula AI framework is a work in progress and chances are high that some changes in the wesnoth code base will be needed. The wesnoth developper community is used to handle people that are familiar with coding but not C++, however the Forumla AI framework uses advanced C++ features and a good knowledge of the language would avoid a major hurdle when plugging in new entries or functionalities for the AI<br />
* ''Good social interaction with a large player community :'' A preliminary phase to coding any AI is to know the strategies and game pattern used by human players. This requires huge interaction with the player community. Our Gameplay Developpers are open and can give some good starting points, but a big game experience and good interaction with the player community will greatly help in the study of the design<br />
<br />
==== Milestones and deliverables ====<br />
<br />
It is hard to give milestones at this point, but here are some ideas of what could be done<br />
<br />
* ''AI design description, and basic function library :'' This first deliverable aims to conclude the '''study and analysis''' part of the project : becoming familiar with the formula language, study of the Multiplayer strategies and of the need of scenario writers with regard to AI. We would like to have a description of the code structure of the AI, some basis of the play strategies it would use and how external scenario writers could configure it for the particular behaviour they need<br />
* ''Main AI delivery :'' This milestone's aim is to deliver a working AI implementing the strategies described in the first phase. It would not have to systematically beat the standard C++ AI at this point, but should be able to play the game correctly (recruit, early deployment on villages, grouping units to attack, holding its ground, protecting weak/important units). Moreover most plug-in entries should be available and a test-case for these entries should be provided.<br />
* ''Fine tunning and behaviour library :'' The third phase would validate the actual strategy of the AI. The AI should consistently beat the default C++ AI, and do fairly well against an average human player. At that stage a library of scenario behaviours should also be delivered. The AI does not need to be as efficiant with all scenario tweaking, but should act correctly with regard to the particular behaviour desired.<br />
<br />
<br />
=== Extending the Multiplayer server ===<br />
<br />
When the developement team met at FOSDEM, we had our multiplayer commuinty, though it is strong and healthy, had its growth restrained by the interface of the multiplayer lobby.<br />
<br />
==== General Description ====<br />
The general idea of this project would be<br />
* To study the current lobby,<br />
* To present some ideas of evolutions both in interface and functionalities of our multiplayer interface to allow it to scale to a much larger community<br />
* To present some well constructed thought on our MP community and how that interface would develop it<br />
* Of course to implement those changes :)<br />
<br />
Some ideas that we had (but that are in no way mandatory)<br />
* Having a simple way to register and authentificate nicknames, similar to what IRC offers. The point is not to have cryptographically safe logins, but to have something simple that gets the job done<br />
* Having a simple room system? again inspired on IRC<br />
* Having some way to find the type of games you are interested in.<br />
** game type<br />
** number of free slots/players<br />
** any other criterias you might find interesting<br />
<br />
Other ideas we are not convinced are good, but that are certainly worth studying (especially how the communities based around these concepts are different from ours)<br />
* ranking players<br />
* guilds<br />
* official tournaments<br />
* titles for players<br />
* metaservers<br />
<br />
The scalablity of the project, both in term of number of players, and in term of the possibility for players and developpers to extend the concept will be a valued criteria<br />
<br />
Administration/moderation problems and techniques should also be studied<br />
<br />
interaction with the Add-On server/forum might be an interseting field to expand to<br />
<br />
==== Required knowledge and talent ====<br />
<br />
* A fair amount of experience on C++ is required. Wesnoth uses some advanced C++ features and is heavily based on BOOST and STL. We can train you in some of the libraries used, but learning all of them would be a big hurdle<br />
* Various experience with multiplayer games, in order to have a good idea of what multiplayer lobbies of other game look like, and (more importantly) a good idea of the social behaviours of multiple MP communities, how teams are formed in games and things like that<br />
<br />
==== Milestones and deliverables ====<br />
<br />
* A first milestone would be a presentation summarizing the different studies, and the proposed interface. preliminary unformal stages would probably be desirable, to make sure the proposed idea is already a consensus within devs <br />
** Study of other MP game-matching interfaces and functionalities<br />
** Study of other MP communities<br />
** Study of other MP moderation practices<br />
** Study of the Wesnoth MP community, including needs, various opinons from different developers and players<br />
* A second milestone would be the main code delivery. Code should be functional for it will be delivered in the next Wesnoth developement release<br />
<br />
<br />
=== Other ideas to be fleshed out ===<br />
* Working on the GUI engine (needs to be defined more precisely)<br />
* Rewrite of the campaign (add-on) server<br />
* The editor can use quite a revamp<br />
* A good scenario editor. We have campgen but it hasn't been updated for a while.<br />
<br />
<br />
== Other info to provide for GSoC ==<br />
==== Describe your organization. ====<br />
<br />
==== Why is your organization applying to participate in GSoC 2008? What do you hope to gain by participating?====<br />
<br />
Most of our developpers have interesting areas in which they work. Though they are efficiant in their areas, there are areas that are interesting but have a high barrier of entry.<br />
<br />
By having a student dedicated to any of these areas, we could quickly get someone upto date with that particualr area, efficiant, and responsible of this area.<br />
<br />
Basically, by getting new people in and making them actively responsible for an area of code we hope to kickstart some areas of the project that have lagged behind<br />
<br />
==== Did your organization participate in past GSoCs? If so, please summarize your involvement and the successes and challenges of your participation.====<br />
This is the first time the Wesnoth projects applies to Google SoC<br />
<br />
==== If your organization has not previously participated in GSoC, have you applied in the past? If so, for what year(s)?====<br />
<br />
This is the first time the Wesnoth projects applies to Google SoC<br />
<br />
==== Who will your organization administrator be? Please include Google Account information.====<br />
Nils Kneuper aka Ivanovic<br />
<br />
crazy.ivanovic |ATTT| googlemail.com<br />
<br />
==== What license(s) does your project use?====<br />
Our project is entirely GPL.<br />
<br />
All code is GPL.<br />
<br />
All art is GPL, 99% was made for the project, everything was taken from content that was checked to be GPL.<br />
<br />
==== What is the URL for your ideas page?====<br />
Our main summer of code pages is located at http://www.wesnoth.org/wiki/SummerOfCodeIdeas<br />
<br />
This page contains various coding ideas and the thought the developement team has already given them.<br />
<br />
It also contains a list of the developers that are the most active on IRC and their domain of interes<br />
<br />
==== What is the main development mailing list or forum for your organization?====<br />
Most development work takes place on "wesnoth-dev |ATTT| gna.org". Beside this some work happens at http://www.wesnoth.org/forum/.<br />
<br />
==== What is the main IRC channel for your organization?====<br />
<br />
All our IRC channels are on the ''freenode'' network<br />
<br />
* ''#wesnoth-dev'' is the main developement channel, where most discussion takes place<br />
* ''#wesnoth'' is a generic channel for the community<br />
* ''#wesnoth-mp'' is a separate channel for multiplayer games and balancing<br />
<br />
==== Does your organization have an application template you would like to see students use? If so, please provide it now.====<br />
We plan mainly to meet potential students through our IRC channel, but the following questions are wesnothspecific and are worth pondering for any student, even if we don't need a formal answer<br />
<br />
* What type of gamer are you ? What type of games ? what type of oponents ? are you more interested in story or gameplay ? <br />
* Are you good at interacting with other players ? Our developer community is quite nice, but the player community can be a bit rough.<br />
* Do you give constructive advices ? Do you receive advice well ? are you good at sorting usefull criticism from useless ones ?<br />
<br />
''''to be completed''''<br />
<br />
==== Who will be your backup organization administrator? Please include Google Account information.====<br />
<br />
Jeremy Rosen alias Boucman<br />
<br />
boucman2@gmail.com<br />
<br />
==== Who will your mentors be? Please include Google Account information.====<br />
<br />
==== What criteria did you use to select these individuals as mentors? Please be as specific as possible.====<br />
<br />
==== What is your plan for dealing with disappearing students?====<br />
<br />
==== What is your plan for dealing with disappearing mentors?====<br />
<br />
==== What steps will you take to encourage students to interact with your project's community before, during and after the program?====<br />
<br />
Wesnoth has a particularly healthy commutnity, both for developers and for players. <br />
<br />
Our general policy regarding new coders has always been "two patch... you're in" In other word, anybody that is able to get two non-trivial patches applied is offered commit right.<br />
<br />
We have a developer responsible for applying patches and guiding new developpers into our community. This is a well known and effective process we plan to apply to students, directing them to our [[EasyCoding]] pages (these project are usually a couple of hours long and has been chosen to provide easy access to code)<br />
<br />
Usually, patches goback and fortha couple of time, to make sure that all secondary things are in place (indenting, coding style, modified makefiles etc.) The idea is that coder education should take place before thecoder has commit rights, but that getting new coder in is one of the most important things to maintain our project alive.<br />
<br />
If the student is a little proactive and ready to join IRC, all the developers are usually very welcoming, and good at directing newcomers to quickly give usefull results.<br />
<br />
'''to be completed'''<br />
<br />
==== What will you do to ensure that your accepted students stick with the project after GSoC concludes?====<br />
<br />
<br />
<br />
=== People to bug on IRC, possible mentors ===<br />
Everybody feel free to edit/correct his entry!<br />
<br />
==== Dave alias Sirp ====<br />
<br />
Sirp started Wesnoth and is our lead developper. He is currently our C++ expert and is also the one that is working on the new Formula AI. Any questions regarding the formula AI should be directed to him.<br />
<br />
==== Mordante ====<br />
Many of the possible projects do at least partly go into the area of code where he knows most of. Plus many of the possible projects currently listed on the ideas page do require GUI parts to work, too. So if Mordante wants to tackle a rewrite of large parts of this, he will be our expert there as well as he already is our expert for the terrain engine (cf. editor / scenario editor works).<br />
<br />
==== Elias Pscherning (elias) ====<br />
He has written the original version of campgen and as such will know a lot about what is needed to to make such an editor work correctly. The work on a scenario editor might be based upon campgen and as such make his knowledge really helpful.<br />
<br />
==== Karol Nowak (grzywacz) ====<br />
Last year he was participating at GSoC as a student, so he knows at least this side of the medal. Beside this he is our top expert regarding embedded devices support since he is actively working on the gp2x support.<br />
<br />
==== boucman ====<br />
As our "patch monkey" he has valuable knowledge in comments and critics for patches of every kind. Beside this he knows many areas of the game due to working on applying patches. He is particularly used to answer question from new coders, and doesn't mind explaining trivial stuff.<br />
<br />
If you want to have a feeling of the developer spirit, it is recommended to go to our [[EasyCoding]] page.<br />
<br />
==== Soliton ====<br />
He does know our mp server setup best. Beside this he already has done a lot of work on the mp server himself, too. So he probably has most knowledge about it and due to being one of our mp-devlopers might provide important help from the perspective of mp-community and what is needed there.<br />
<br />
==== zookeeper or Mythological or Rhuaven ====<br />
As our leading WML expert it would be good to have him in the list when it comes to WML specific problems. That is for work on the scenario editor he probably knows best what should be implemented in it and what is a usable way for things.<br />
<br />
==== YogiHH or Piotr Cychowski (cycholka) ====<br />
Since they are the two developers who know most about building under Windows, they will probably be really helpful. Either if the student comes from the Windows side, or to help test resulting work to make sure that it does work on Windows and, for the case that it does not, to show them where problems are.</div>Grzywaczhttps://wiki.wesnoth.org/index.php?title=SummerOfCodeIdeas&diff=22887SummerOfCodeIdeas2008-02-27T20:26:14Z<p>Grzywacz: Added cycholka's real name</p>
<hr />
<div>== Ideas for Google Summer of Code projects ==<br />
<br />
This is a compilation of ideas from ML. Needs to be refined (more detailed description, deliverables, workload estimation?):<br />
<br />
== List of Ideas for the Project ==<br />
<br />
=== Writing an AI based on the formula AI ===<br />
<br />
Wesnoth has always had a simple C++ based AI. David (our lead developer) has been working on a simple language to write AI in wesnoth ''link to formula AI page here'' <br />
<br />
The wesnoth AI is used as an oponent in most campaigns, and as such is an important piece of code for the wesnoth project. Unfortunately it is also one of the most neglected piece of code and a place where a lot of research and work could be done<br />
<br />
==== General description ====<br />
<br />
The aim of this project is to develop a new AI that would replace the original C++ AI. The main criterias we would want for this new AI are<br />
<br />
* ''Plugability :'' It should be trivial for any content maker to change the behavior of the AI in specific case. The exact cases are still to be defined but should typically include<br />
** hardwiring the first few turns of the AI<br />
** changing the recruitment pattern<br />
** completely controlling a given unit (sceneario unit)<br />
** taking control then giving back control of a given unit<br />
* ''tunability :'' It should be easy for a scenario author to specify the general behaviour of the ennemy on a given scenario (agressivity, intrepidity...)<br />
* ''specific behaviours :'' there are some typical behaviours that are not smart to win the scenario but are needed, such as guarding a given unit, a given position, wandering aimlessly, attacking randomly, always fleeing. The AI should implement such behaviours, and allow easy addition of new behaviours<br />
<br />
==== Required knowledge and talent ====<br />
<br />
* ''A minimal knowledge of C++ is required, a good knowledge of C++ is desired :'' The formula AI framework is a work in progress and chances are high that some changes in the wesnoth code base will be needed. The wesnoth developper community is used to handle people that are familiar with coding but not C++, however the Forumla AI framework uses advanced C++ features and a good knowledge of the language would avoid a major hurdle when plugging in new entries or functionalities for the AI<br />
* ''Good social interaction with a large player community :'' A preliminary phase to coding any AI is to know the strategies and game pattern used by human players. This requires huge interaction with the player community. Our Gameplay Developpers are open and can give some good starting points, but a big game experience and good interaction with the player community will greatly help in the study of the design<br />
<br />
==== Milestones and deliverables ====<br />
<br />
It is hard to give milestones at this point, but here are some ideas of what could be done<br />
<br />
* ''AI design description, and basic function library :'' This first deliverable aims to conclude the '''study and analysis''' part of the project : becoming familiar with the formula language, study of the Multiplayer strategies and of the need of scenario writers with regard to AI. We would like to have a description of the code structure of the AI, some basis of the play strategies it would use and how external scenario writers could configure it for the particular behaviour they need<br />
* ''Main AI delivery :'' This milestone's aim is to deliver a working AI implementing the strategies described in the first phase. It would not have to systematically beat the standard C++ AI at this point, but should be able to play the game correctly (recruit, early deployment on villages, grouping units to attack, holding its ground, protecting weak/important units). Moreover most plug-in entries should be available and a test-case for these entries should be provided.<br />
* ''Fine tunning and behaviour library :'' The third phase would validate the actual strategy of the AI. The AI should consistently beat the default C++ AI, and do fairly well against an average human player. At that stage a library of scenario behaviours should also be delivered. The AI does not need to be as efficiant with all scenario tweaking, but should act correctly with regard to the particular behaviour desired.<br />
<br />
<br />
=== Extending the Multiplayer server ===<br />
<br />
When the developement team met at FOSDEM, we had our multiplayer commuinty, though it is strong and healthy, had its growth restrained by the interface of the multiplayer lobby.<br />
<br />
==== General Description ====<br />
The general idea of this project would be<br />
* To study the current lobby,<br />
* To present some ideas of evolutions both in interface and functionalities of our multiplayer interface to allow it to scale to a much larger community<br />
* To present some well constructed thought on our MP community and how that interface would develop it<br />
* Of course to implement those changes :)<br />
<br />
Some ideas that we had (but that are in no way mandatory)<br />
* Having a simple way to register and authentificate nicknames, similar to what IRC offers. The point is not to have cryptographically safe logins, but to have something simple that gets the job done<br />
* Having a simple room system? again inspired on IRC<br />
* Having some way to find the type of games you are interested in.<br />
** game type<br />
** number of free slots/players<br />
** any other criterias you might find interesting<br />
<br />
Other ideas we are not convinced are good, but that are certainly worth studying (especially how the communities based around these concepts are different from ours)<br />
* ranking players<br />
* guilds<br />
* official tournaments<br />
* titles for players<br />
* metaservers<br />
<br />
The scalablity of the project, both in term of number of players, and in term of the possibility for players and developpers to extend the concept will be a valued criteria<br />
<br />
Administration/moderation problems and techniques should also be studied<br />
<br />
interaction with the Add-On server/forum might be an interseting field to expand to<br />
<br />
==== Required knowledge and talent ====<br />
<br />
* A fair amount of experience on C++ is required. Wesnoth uses some advanced C++ features and is heavily based on BOOST and STL. We can train you in some of the libraries used, but learning all of them would be a big hurdle<br />
* Various experience with multiplayer games, in order to have a good idea of what multiplayer lobbies of other game look like, and (more importantly) a good idea of the social behaviours of multiple MP communities, how teams are formed in games and things like that<br />
<br />
==== Milestones and deliverables ====<br />
<br />
* A first milestone would be a presentation summarizing the different studies, and the proposed interface. preliminary unformal stages would probably be desirable, to make sure the proposed idea is already a consensus within devs <br />
** Study of other MP game-matching interfaces and functionalities<br />
** Study of other MP communities<br />
** Study of other MP moderation practices<br />
** Study of the Wesnoth MP community, including needs, various opinons from different developers and players<br />
* A second milestone would be the main code delivery. Code should be functional for it will be delivered in the next Wesnoth developement release<br />
<br />
<br />
=== Other ideas to be fleshed out ===<br />
* Working on the GUI engine (needs to be defined more precisely)<br />
* Rewrite of the campaign (add-on) server<br />
* The editor can use quite a revamp<br />
* A good scenario editor. We have campgen but it hasn't been updated for a while.<br />
<br />
<br />
== Other info to provide for GSoC ==<br />
==== Describe your organization. ====<br />
<br />
==== Why is your organization applying to participate in GSoC 2008? What do you hope to gain by participating?====<br />
<br />
Most of our developpers have interesting areas in which they work. Though they are efficiant in their areas, there are areas that are interesting but have a high barrier of entry.<br />
<br />
By having a student dedicated to any of these areas, we could quickly get someone upto date with that particualr area, efficiant, and responsible of this area.<br />
<br />
Basically, by getting new people in and making them actively responsible for an area of code we hope to kickstart some areas of the project that have lagged behind<br />
<br />
==== Did your organization participate in past GSoCs? If so, please summarize your involvement and the successes and challenges of your participation.====<br />
This is the first time the Wesnoth projects applies to Google SoC<br />
<br />
==== If your organization has not previously participated in GSoC, have you applied in the past? If so, for what year(s)?====<br />
<br />
This is the first time the Wesnoth projects applies to Google SoC<br />
<br />
==== Who will your organization administrator be? Please include Google Account information.====<br />
Nils Kneuper aka Ivanovic<br />
<br />
crazy.ivanovic |ATTT| googlemail.com<br />
<br />
==== What license(s) does your project use?====<br />
Our project is entirely GPL.<br />
<br />
All code is GPL.<br />
<br />
All art is GPL, 99% was made for the project, everything was taken from content that was checked to be GPL.<br />
<br />
==== What is the URL for your ideas page?====<br />
Our main summer of code pages is located at http://www.wesnoth.org/wiki/SummerOfCodeIdeas<br />
<br />
This page contains various coding ideas and the thought the developement team has already given them.<br />
<br />
It also contains a list of the developers that are the most active on IRC and their domain of interes<br />
<br />
==== What is the main development mailing list or forum for your organization?====<br />
Most development work takes place on "wesnoth-dev |ATTT| gna.org". Beside this some work happens at http://www.wesnoth.org/forum/.<br />
<br />
==== What is the main IRC channel for your organization?====<br />
<br />
All our IRC channels are on the ''freenode'' network<br />
<br />
* ''#wesnoth-dev'' is the main developement channel, where most discussion takes place<br />
* ''#wesnoth'' is a generic channel for the community<br />
* ''#wesnoth-mp'' is a separate channel for multiplayer games and balancing<br />
<br />
==== Does your organization have an application template you would like to see students use? If so, please provide it now.====<br />
We plan mainly to meet potential students through our IRC channel, but the following questions are wesnothspecific and are worth pondering for any student, even if we don't need a formal answer<br />
<br />
* What type of gamer are you ? What type of games ? what type of oponents ? are you more interested in story or gameplay ? <br />
* Are you good at interacting with other players ? Our developer community is quite nice, but the player community can be a bit rough.<br />
* Do you give constructive advices ? Do you receive advice well ? are you good at sorting usefull criticism from useless ones ?<br />
<br />
''''to be completed''''<br />
<br />
==== Who will be your backup organization administrator? Please include Google Account information.====<br />
<br />
Jeremy Rosen alias Boucman<br />
<br />
boucman2@gmail.com<br />
<br />
==== Who will your mentors be? Please include Google Account information.====<br />
<br />
==== What criteria did you use to select these individuals as mentors? Please be as specific as possible.====<br />
<br />
==== What is your plan for dealing with disappearing students?====<br />
<br />
==== What is your plan for dealing with disappearing mentors?====<br />
<br />
==== What steps will you take to encourage students to interact with your project's community before, during and after the program?====<br />
<br />
Wesnoth has a particularly healthy commutnity, both for developers and for players. <br />
<br />
Our general policy regarding new coders has always been "two patch... you're in" In other word, anybody that is able to get two non-trivial patches applied is offered commit right.<br />
<br />
We have a developer responsible for applying patches and guiding new developpers into our community. This is a well known and effective process we plan to apply to students, directing them to our [[EasyCoding]] pages (these project are usually a couple of hours long and has been chosen to provide easy access to code)<br />
<br />
Usually, patches goback and fortha couple of time, to make sure that all secondary things are in place (indenting, coding style, modified makefiles etc.) The idea is that coder education should take place before thecoder has commit rights, but that getting new coder in is one of the most important things to maintain our project alive.<br />
<br />
If the student is a little proactive and ready to join IRC, all the developers are usually very welcoming, and good at directing newcomers to quickly give usefull results.<br />
<br />
'''to be completed'''<br />
<br />
==== What will you do to ensure that your accepted students stick with the project after GSoC concludes?====<br />
<br />
<br />
<br />
=== People to bug on IRC, possible mentors ===<br />
Everybody feel free to edit/correct his entry!<br />
<br />
==== Dave alias Sirp ====<br />
<br />
Sirp started Wesnoth and is our lead developper. He is currently our C++ expert and is also the one that is working on the new Formula AI. Any questions regarding the formula AI should be directed to him.<br />
<br />
==== Mordante ====<br />
Many of the possible projects do at least partly go into the area of code where he knows most of. Plus many of the possible projects currently listed on the ideas page do require GUI parts to work, too. So if Mordante wants to tackle a rewrite of large parts of this, he will be our expert there as well as he already is our expert for the terrain engine (cf. editor / scenario editor works).<br />
<br />
==== elias ====<br />
He has written the original version of campgen and as such will know a lot about what is needed to to make such an editor work correctly. The work on a scenario editor might be based upon campgen and as such make his knowledge really helpful.<br />
<br />
==== Karol Nowak (grzywacz) ====<br />
Last year he was participating at GSoC as a student, so he knows at least this side of the medal. Beside this he is our top expert regarding embedded devices support since he is actively working on the gp2x support.<br />
<br />
==== boucman ====<br />
As our "patch monkey" he has valuable knowledge in comments and critics for patches of every kind. Beside this he knows many areas of the game due to working on applying patches. He is particularly used to answer question from new coders, and doesn't mind explaining trivial stuff.<br />
<br />
If you want to have a feeling of the developer spirit, it is recommended to go to our [[EasyCoding]] page.<br />
<br />
==== Soliton ====<br />
He does know our mp server setup best. Beside this he already has done a lot of work on the mp server himself, too. So he probably has most knowledge about it and due to being one of our mp-devlopers might provide important help from the perspective of mp-community and what is needed there.<br />
<br />
==== zookeeper or Mythological or Rhuaven ====<br />
As our leading WML expert it would be good to have him in the list when it comes to WML specific problems. That is for work on the scenario editor he probably knows best what should be implemented in it and what is a usable way for things.<br />
<br />
==== YogiHH or Piotr Cychowski (cycholka) ====<br />
Since they are the two developers who know most about building under Windows, they will probably be really helpful. Either if the student comes from the Windows side, or to help test resulting work to make sure that it does work on Windows and, for the case that it does not, to show them where problems are.</div>Grzywaczhttps://wiki.wesnoth.org/index.php?title=SummerOfCodeIdeas&diff=22886SummerOfCodeIdeas2008-02-27T20:25:27Z<p>Grzywacz: Added my real name</p>
<hr />
<div>== Ideas for Google Summer of Code projects ==<br />
<br />
This is a compilation of ideas from ML. Needs to be refined (more detailed description, deliverables, workload estimation?):<br />
<br />
== List of Ideas for the Project ==<br />
<br />
=== Writing an AI based on the formula AI ===<br />
<br />
Wesnoth has always had a simple C++ based AI. David (our lead developer) has been working on a simple language to write AI in wesnoth ''link to formula AI page here'' <br />
<br />
The wesnoth AI is used as an oponent in most campaigns, and as such is an important piece of code for the wesnoth project. Unfortunately it is also one of the most neglected piece of code and a place where a lot of research and work could be done<br />
<br />
==== General description ====<br />
<br />
The aim of this project is to develop a new AI that would replace the original C++ AI. The main criterias we would want for this new AI are<br />
<br />
* ''Plugability :'' It should be trivial for any content maker to change the behavior of the AI in specific case. The exact cases are still to be defined but should typically include<br />
** hardwiring the first few turns of the AI<br />
** changing the recruitment pattern<br />
** completely controlling a given unit (sceneario unit)<br />
** taking control then giving back control of a given unit<br />
* ''tunability :'' It should be easy for a scenario author to specify the general behaviour of the ennemy on a given scenario (agressivity, intrepidity...)<br />
* ''specific behaviours :'' there are some typical behaviours that are not smart to win the scenario but are needed, such as guarding a given unit, a given position, wandering aimlessly, attacking randomly, always fleeing. The AI should implement such behaviours, and allow easy addition of new behaviours<br />
<br />
==== Required knowledge and talent ====<br />
<br />
* ''A minimal knowledge of C++ is required, a good knowledge of C++ is desired :'' The formula AI framework is a work in progress and chances are high that some changes in the wesnoth code base will be needed. The wesnoth developper community is used to handle people that are familiar with coding but not C++, however the Forumla AI framework uses advanced C++ features and a good knowledge of the language would avoid a major hurdle when plugging in new entries or functionalities for the AI<br />
* ''Good social interaction with a large player community :'' A preliminary phase to coding any AI is to know the strategies and game pattern used by human players. This requires huge interaction with the player community. Our Gameplay Developpers are open and can give some good starting points, but a big game experience and good interaction with the player community will greatly help in the study of the design<br />
<br />
==== Milestones and deliverables ====<br />
<br />
It is hard to give milestones at this point, but here are some ideas of what could be done<br />
<br />
* ''AI design description, and basic function library :'' This first deliverable aims to conclude the '''study and analysis''' part of the project : becoming familiar with the formula language, study of the Multiplayer strategies and of the need of scenario writers with regard to AI. We would like to have a description of the code structure of the AI, some basis of the play strategies it would use and how external scenario writers could configure it for the particular behaviour they need<br />
* ''Main AI delivery :'' This milestone's aim is to deliver a working AI implementing the strategies described in the first phase. It would not have to systematically beat the standard C++ AI at this point, but should be able to play the game correctly (recruit, early deployment on villages, grouping units to attack, holding its ground, protecting weak/important units). Moreover most plug-in entries should be available and a test-case for these entries should be provided.<br />
* ''Fine tunning and behaviour library :'' The third phase would validate the actual strategy of the AI. The AI should consistently beat the default C++ AI, and do fairly well against an average human player. At that stage a library of scenario behaviours should also be delivered. The AI does not need to be as efficiant with all scenario tweaking, but should act correctly with regard to the particular behaviour desired.<br />
<br />
<br />
=== Extending the Multiplayer server ===<br />
<br />
When the developement team met at FOSDEM, we had our multiplayer commuinty, though it is strong and healthy, had its growth restrained by the interface of the multiplayer lobby.<br />
<br />
==== General Description ====<br />
The general idea of this project would be<br />
* To study the current lobby,<br />
* To present some ideas of evolutions both in interface and functionalities of our multiplayer interface to allow it to scale to a much larger community<br />
* To present some well constructed thought on our MP community and how that interface would develop it<br />
* Of course to implement those changes :)<br />
<br />
Some ideas that we had (but that are in no way mandatory)<br />
* Having a simple way to register and authentificate nicknames, similar to what IRC offers. The point is not to have cryptographically safe logins, but to have something simple that gets the job done<br />
* Having a simple room system? again inspired on IRC<br />
* Having some way to find the type of games you are interested in.<br />
** game type<br />
** number of free slots/players<br />
** any other criterias you might find interesting<br />
<br />
Other ideas we are not convinced are good, but that are certainly worth studying (especially how the communities based around these concepts are different from ours)<br />
* ranking players<br />
* guilds<br />
* official tournaments<br />
* titles for players<br />
* metaservers<br />
<br />
The scalablity of the project, both in term of number of players, and in term of the possibility for players and developpers to extend the concept will be a valued criteria<br />
<br />
Administration/moderation problems and techniques should also be studied<br />
<br />
interaction with the Add-On server/forum might be an interseting field to expand to<br />
<br />
==== Required knowledge and talent ====<br />
<br />
* A fair amount of experience on C++ is required. Wesnoth uses some advanced C++ features and is heavily based on BOOST and STL. We can train you in some of the libraries used, but learning all of them would be a big hurdle<br />
* Various experience with multiplayer games, in order to have a good idea of what multiplayer lobbies of other game look like, and (more importantly) a good idea of the social behaviours of multiple MP communities, how teams are formed in games and things like that<br />
<br />
==== Milestones and deliverables ====<br />
<br />
* A first milestone would be a presentation summarizing the different studies, and the proposed interface. preliminary unformal stages would probably be desirable, to make sure the proposed idea is already a consensus within devs <br />
** Study of other MP game-matching interfaces and functionalities<br />
** Study of other MP communities<br />
** Study of other MP moderation practices<br />
** Study of the Wesnoth MP community, including needs, various opinons from different developers and players<br />
* A second milestone would be the main code delivery. Code should be functional for it will be delivered in the next Wesnoth developement release<br />
<br />
<br />
=== Other ideas to be fleshed out ===<br />
* Working on the GUI engine (needs to be defined more precisely)<br />
* Rewrite of the campaign (add-on) server<br />
* The editor can use quite a revamp<br />
* A good scenario editor. We have campgen but it hasn't been updated for a while.<br />
<br />
<br />
== Other info to provide for GSoC ==<br />
==== Describe your organization. ====<br />
<br />
==== Why is your organization applying to participate in GSoC 2008? What do you hope to gain by participating?====<br />
<br />
Most of our developpers have interesting areas in which they work. Though they are efficiant in their areas, there are areas that are interesting but have a high barrier of entry.<br />
<br />
By having a student dedicated to any of these areas, we could quickly get someone upto date with that particualr area, efficiant, and responsible of this area.<br />
<br />
Basically, by getting new people in and making them actively responsible for an area of code we hope to kickstart some areas of the project that have lagged behind<br />
<br />
==== Did your organization participate in past GSoCs? If so, please summarize your involvement and the successes and challenges of your participation.====<br />
This is the first time the Wesnoth projects applies to Google SoC<br />
<br />
==== If your organization has not previously participated in GSoC, have you applied in the past? If so, for what year(s)?====<br />
<br />
This is the first time the Wesnoth projects applies to Google SoC<br />
<br />
==== Who will your organization administrator be? Please include Google Account information.====<br />
Nils Kneuper aka Ivanovic<br />
<br />
crazy.ivanovic |ATTT| googlemail.com<br />
<br />
==== What license(s) does your project use?====<br />
Our project is entirely GPL.<br />
<br />
All code is GPL.<br />
<br />
All art is GPL, 99% was made for the project, everything was taken from content that was checked to be GPL.<br />
<br />
==== What is the URL for your ideas page?====<br />
Our main summer of code pages is located at http://www.wesnoth.org/wiki/SummerOfCodeIdeas<br />
<br />
This page contains various coding ideas and the thought the developement team has already given them.<br />
<br />
It also contains a list of the developers that are the most active on IRC and their domain of interes<br />
<br />
==== What is the main development mailing list or forum for your organization?====<br />
Most development work takes place on "wesnoth-dev |ATTT| gna.org". Beside this some work happens at http://www.wesnoth.org/forum/.<br />
<br />
==== What is the main IRC channel for your organization?====<br />
<br />
All our IRC channels are on the ''freenode'' network<br />
<br />
* ''#wesnoth-dev'' is the main developement channel, where most discussion takes place<br />
* ''#wesnoth'' is a generic channel for the community<br />
* ''#wesnoth-mp'' is a separate channel for multiplayer games and balancing<br />
<br />
==== Does your organization have an application template you would like to see students use? If so, please provide it now.====<br />
We plan mainly to meet potential students through our IRC channel, but the following questions are wesnothspecific and are worth pondering for any student, even if we don't need a formal answer<br />
<br />
* What type of gamer are you ? What type of games ? what type of oponents ? are you more interested in story or gameplay ? <br />
* Are you good at interacting with other players ? Our developer community is quite nice, but the player community can be a bit rough.<br />
* Do you give constructive advices ? Do you receive advice well ? are you good at sorting usefull criticism from useless ones ?<br />
<br />
''''to be completed''''<br />
<br />
==== Who will be your backup organization administrator? Please include Google Account information.====<br />
<br />
Jeremy Rosen alias Boucman<br />
<br />
boucman2@gmail.com<br />
<br />
==== Who will your mentors be? Please include Google Account information.====<br />
<br />
==== What criteria did you use to select these individuals as mentors? Please be as specific as possible.====<br />
<br />
==== What is your plan for dealing with disappearing students?====<br />
<br />
==== What is your plan for dealing with disappearing mentors?====<br />
<br />
==== What steps will you take to encourage students to interact with your project's community before, during and after the program?====<br />
<br />
Wesnoth has a particularly healthy commutnity, both for developers and for players. <br />
<br />
Our general policy regarding new coders has always been "two patch... you're in" In other word, anybody that is able to get two non-trivial patches applied is offered commit right.<br />
<br />
We have a developer responsible for applying patches and guiding new developpers into our community. This is a well known and effective process we plan to apply to students, directing them to our [[EasyCoding]] pages (these project are usually a couple of hours long and has been chosen to provide easy access to code)<br />
<br />
Usually, patches goback and fortha couple of time, to make sure that all secondary things are in place (indenting, coding style, modified makefiles etc.) The idea is that coder education should take place before thecoder has commit rights, but that getting new coder in is one of the most important things to maintain our project alive.<br />
<br />
If the student is a little proactive and ready to join IRC, all the developers are usually very welcoming, and good at directing newcomers to quickly give usefull results.<br />
<br />
'''to be completed'''<br />
<br />
==== What will you do to ensure that your accepted students stick with the project after GSoC concludes?====<br />
<br />
<br />
<br />
=== People to bug on IRC, possible mentors ===<br />
Everybody feel free to edit/correct his entry!<br />
<br />
==== Dave alias Sirp ====<br />
<br />
Sirp started Wesnoth and is our lead developper. He is currently our C++ expert and is also the one that is working on the new Formula AI. Any questions regarding the formula AI should be directed to him.<br />
<br />
==== Mordante ====<br />
Many of the possible projects do at least partly go into the area of code where he knows most of. Plus many of the possible projects currently listed on the ideas page do require GUI parts to work, too. So if Mordante wants to tackle a rewrite of large parts of this, he will be our expert there as well as he already is our expert for the terrain engine (cf. editor / scenario editor works).<br />
<br />
==== elias ====<br />
He has written the original version of campgen and as such will know a lot about what is needed to to make such an editor work correctly. The work on a scenario editor might be based upon campgen and as such make his knowledge really helpful.<br />
<br />
==== Karol Nowak (grzywacz) ====<br />
Last year he was participating at GSoC as a student, so he knows at least this side of the medal. Beside this he is our top expert regarding embedded devices support since he is actively working on the gp2x support.<br />
<br />
==== boucman ====<br />
As our "patch monkey" he has valuable knowledge in comments and critics for patches of every kind. Beside this he knows many areas of the game due to working on applying patches. He is particularly used to answer question from new coders, and doesn't mind explaining trivial stuff.<br />
<br />
If you want to have a feeling of the developer spirit, it is recommended to go to our [[EasyCoding]] page.<br />
<br />
==== Soliton ====<br />
He does know our mp server setup best. Beside this he already has done a lot of work on the mp server himself, too. So he probably has most knowledge about it and due to being one of our mp-devlopers might provide important help from the perspective of mp-community and what is needed there.<br />
<br />
==== zookeeper or Mythological or Rhuaven ====<br />
As our leading WML expert it would be good to have him in the list when it comes to WML specific problems. That is for work on the scenario editor he probably knows best what should be implemented in it and what is a usable way for things.<br />
<br />
==== YogiHH or cycholka ====<br />
Since they are the two developers who know most about building under Windows, they will probably be really helpful. Either if the student comes from the Windows side, or to help test resulting work to make sure that it does work on Windows and, for the case that it does not, to show them where problems are.</div>Grzywaczhttps://wiki.wesnoth.org/index.php?title=SummerOfCodeIdeas&diff=22810SummerOfCodeIdeas2008-02-26T22:12:29Z<p>Grzywacz: Initial version</p>
<hr />
<div>== Ideas for Google Summer of Code projects ==<br />
<br />
This is a compilation of ideas from ML. Needs to be refined (more detailed description, deliverables, workload estimation?):<br />
<br />
* Writing an AI based on the formula AI<br />
* Working on the GUI engine (needs to be defined more precisely)<br />
* Extend the multiplayer server to provide accounts and room<br />
* Rewrite of the campaign (add-on) server<br />
* The editor can use quite a revamp<br />
* A good scenario editor. We have campgen but it hasn't been updated for a while.</div>Grzywaczhttps://wiki.wesnoth.org/index.php?title=Fosdem2008&diff=20331Fosdem20082007-12-27T18:03:38Z<p>Grzywacz: /* Schedule/Plans */</p>
<hr />
<div>== General information ==<br />
* Fosdem - http://fosdem.org/2008/<br />
* Dave's talk (not scheduled yet) - http://fosdem.org/2008/schedule/events/240<br />
<br />
== Schedule/Plans ==<br />
<br />
{| border="1" width="100%"<br />
|-<br />
! <br />
! Arrival<br />
! Departure<br />
! Accomodation<br />
|-<br />
| grzywacz<br />
| 22, 20:35 (CHA)<br />
| 24, 20:50 (CHA)<br />
| Bruegel YH<br />
|-<br />
| ettin<br />
| 22, 9:15 (BRU)<br />
| 24, 15:25 (BRU)<br />
| Bruegel YH or CHAB<br />
|-<br />
| Ivanovic<br />
| 22, lunchtime<br />
| 25, lunchtime<br />
| CHAB or *whatever*<br />
|-<br />
| David & Lisa<br />
| 18, morning<br />
| 25, morning<br />
| Novotel Grand Place<br />
|-<br />
| Mist <br />
| 22, lunchtime<br />
| 25, lunchtime<br />
| CrownePlaza (Europa)<br />
|-<br />
| Noyga (or maybe the 24)<br />
| 23, morning<br />
| 23, evening<br />
| At home, near Paris ;)<br />
|-<br />
|}</div>Grzywaczhttps://wiki.wesnoth.org/index.php?title=Fosdem2008&diff=20330Fosdem20082007-12-27T17:41:10Z<p>Grzywacz: /* Schedule/Plans */</p>
<hr />
<div>== General information ==<br />
* Fosdem - http://fosdem.org/2008/<br />
* Dave's talk (not scheduled yet) - http://fosdem.org/2008/schedule/events/240<br />
<br />
== Schedule/Plans ==<br />
<br />
{| border="1" width="100%"<br />
|-<br />
! <br />
! Arrival<br />
! Departure<br />
! Accomodation<br />
|-<br />
| grzywacz<br />
| 22, 20:35 (CHA)<br />
| 24, not yet determined (CHA)<br />
| Bruegel YH<br />
|-<br />
| ettin<br />
| 22, 9:15 (BRU)<br />
| 24, 15:25 (BRU)<br />
| Bruegel YH or CHAB<br />
|-<br />
| Ivanovic<br />
| 22, lunchtime<br />
| 25, lunchtime<br />
| CHAB or *whatever*<br />
|-<br />
| David & Lisa<br />
| 18, morning<br />
| 25, morning<br />
| Novotel Grand Place<br />
|-<br />
| Mist <br />
| 22, lunchtime<br />
| 25, lunchtime<br />
| CrownePlaza (Europa)<br />
|-<br />
| Noyga (or maybe the 24)<br />
| 23, morning<br />
| 23, evening<br />
| At home, near Paris ;)<br />
|-<br />
|}</div>Grzywaczhttps://wiki.wesnoth.org/index.php?title=User:Grzywacz&diff=14385User:Grzywacz2007-03-20T16:31:43Z<p>Grzywacz: /* Tags implemented in trunk (for testing purposes only): */</p>
<hr />
<div>Why hello there! This site describes my involvement in the "Battle for Wesnoth" developement so far.<br />
<br />
<br />
== Translation & internationalisation ==<br />
<br />
I was maintaining the Polish translation of "Battle for Wesnoth" for more than 1.5 year, starting spring 2005. In that time, with enormous help of a few people (mentioned in credits), we managed to complete the translation of all the mainline strings for 1.0.2 and 1.2 releases. We've started with basically nothing (barely ~5% completed at the beginning makes me wonder why previous translators even appear in the credits).<br />
<br />
== Developement ==<br />
<br />
I've started my developement with a few patches, mainly bugfixes. Later on, 2 medium-size projects have begun to evolve:<br />
<br />
=== GP2X port ===<br />
<br />
A port of BfW to Gamepark Holding's GP2X handheld console. The project is currently stalled due to lack of interest on my part and broken hardware... The game basically runs, but there still a few problems to solve.<br />
<br />
What's been accomplished involves: <br />
* fixes to the unmaintained tinygui interface, to make the game playable in 320x240 resolution; <br />
* one-time caching without revalidation to greatly improve startup times<br />
* sound-cache limiting to save on memory<br />
* joystick mouse support, to move mouse cursor using GP2X's stick<br />
* fixed image resize script, used to downscale BfW graphics on install (saves memory and cpu cycles)<br />
<br />
What's left:<br />
* memory usage problems which make the game unplayable; <br />
GP2X has only 32 megs of OS-available RAM, about 24MB more can be accessed with paeryn's hardware SDL lib<br />
* drawing speed - using doublebuffering and hardware blitter don't go well with Wesnoth's display model; <br />
maybe the OpenGL branch is a better base for this port?!<br />
* second CPU core usage - GP2X is based on a MMSP2 SoC, which has two ARM cores available; <br />
possibly off-load music decoding or some AI routines to the 940 core?<br />
<br />
=== Sound sources support ===<br />
<br />
My pet-project waiting for some free time. 8)<br />
<br />
"Sound sources" is a general name for a mechanism, which makes it possible for map elements to emit sounds according to some rules, where "map elements" can be specific locations or terrain patches. One has complete control over them with the WML. <br />
<br />
===== Tags implemented in trunk (for testing purposes only): =====<br />
<br />
<tt>[sound_source]</tt> - creates a sound source<br />
<br />
''Available parameters:''<br />
<br />
<tt>sounds=list,of,comma,seperated,sounds</tt> - list of sounds associated with this source, played randomly<br />
<br />
<tt>id=string</tt> - internal id used to manipulate this source<br />
<br />
<tt>delay=numerical value</tt> - mininal delay (in ms) between two playbacks of source's sound if the source remains visible on the screen; if one scrolls out and back in, the source will be considered as ready to play<br />
<br />
<tt>chance=numerical value</tt> - a number from [0, 100] range, describing what's the chance of source being <br />
activated every second after the ''delay'' has passed or when the source's location appears on the screen (note that it cannot play more than one file at the same time anyway)<br />
<br />
<tt>check_fogged=boolean value</tt> = true or false; if true the source won't play if its location is fogged/shrouded<br />
<br />
<tt>x=list,of,numerical,values</tt> a list of x coordinates associated with this sound source (must match y list)<br />
<br />
<tt>y=list,of,numerical,values</tt> a list of y coordinates associated with this sound source (must match x list)<br />
<br />
<br />
<tt>[remove_sound_source]</tt> - removes a sound source<br />
<br />
''Available parameters:'' <br />
<br />
<tt>id=string</tt> - id of the sound source to be removed</div>Grzywaczhttps://wiki.wesnoth.org/index.php?title=User:Grzywacz&diff=14384User:Grzywacz2007-03-20T16:31:14Z<p>Grzywacz: /* Tags implemented in trunk (for testing purposes only): */</p>
<hr />
<div>Why hello there! This site describes my involvement in the "Battle for Wesnoth" developement so far.<br />
<br />
<br />
== Translation & internationalisation ==<br />
<br />
I was maintaining the Polish translation of "Battle for Wesnoth" for more than 1.5 year, starting spring 2005. In that time, with enormous help of a few people (mentioned in credits), we managed to complete the translation of all the mainline strings for 1.0.2 and 1.2 releases. We've started with basically nothing (barely ~5% completed at the beginning makes me wonder why previous translators even appear in the credits).<br />
<br />
== Developement ==<br />
<br />
I've started my developement with a few patches, mainly bugfixes. Later on, 2 medium-size projects have begun to evolve:<br />
<br />
=== GP2X port ===<br />
<br />
A port of BfW to Gamepark Holding's GP2X handheld console. The project is currently stalled due to lack of interest on my part and broken hardware... The game basically runs, but there still a few problems to solve.<br />
<br />
What's been accomplished involves: <br />
* fixes to the unmaintained tinygui interface, to make the game playable in 320x240 resolution; <br />
* one-time caching without revalidation to greatly improve startup times<br />
* sound-cache limiting to save on memory<br />
* joystick mouse support, to move mouse cursor using GP2X's stick<br />
* fixed image resize script, used to downscale BfW graphics on install (saves memory and cpu cycles)<br />
<br />
What's left:<br />
* memory usage problems which make the game unplayable; <br />
GP2X has only 32 megs of OS-available RAM, about 24MB more can be accessed with paeryn's hardware SDL lib<br />
* drawing speed - using doublebuffering and hardware blitter don't go well with Wesnoth's display model; <br />
maybe the OpenGL branch is a better base for this port?!<br />
* second CPU core usage - GP2X is based on a MMSP2 SoC, which has two ARM cores available; <br />
possibly off-load music decoding or some AI routines to the 940 core?<br />
<br />
=== Sound sources support ===<br />
<br />
My pet-project waiting for some free time. 8)<br />
<br />
"Sound sources" is a general name for a mechanism, which makes it possible for map elements to emit sounds according to some rules, where "map elements" can be specific locations or terrain patches. One has complete control over them with the WML. <br />
<br />
===== Tags implemented in trunk (for testing purposes only): =====<br />
<br />
<tt>[sound_source]</tt> - creates a sound source<br />
<br />
''Available parameters:''<br />
<br />
<tt>sounds=list,of,comma,seperated,sounds</tt> - list of sounds associated with this source, played randomly<br />
<br />
<tt>id=string</tt> - internal id used to manipulate this source<br />
<br />
<tt>delay=numerical value</tt> - mininal delay (in ms) between two playbacks of source's sound if the source remains visible on the screen; if one scrolls out and back in, the source will be considered as ready to play<br />
<br />
<tt>chance=numerical value</tt> - a number from [0, 100] range, describing what's the chance of source being <br />
activated every second after the ''delay'' has passed or when the source's location appears on the screen (note that it cannot play more than one file at the same time anyway)<br />
<br />
<tt>check_fogged=boolean value</tt> = true or false; if true the source won't play if its location is fogged/shrouded<br />
<br />
<tt>x=list,of,numerical,values</tt> a list of x coordinates associated with this sound source (must match y list)<br />
<br />
<tt>y=list,of,numerical,values</tt> a list of y coordinates associated with this sound source (must match x list)<br />
<br />
<br />
<tt>[sound_source]</tt> - removes a sound source<br />
<br />
''Available parameters:'' <br />
<br />
<tt>id=string</tt> - id of the sound source to be removed</div>Grzywaczhttps://wiki.wesnoth.org/index.php?title=User:Grzywacz&diff=14383User:Grzywacz2007-03-20T16:29:18Z<p>Grzywacz: /* Tags implemented in trunk (for testing purposes only): */</p>
<hr />
<div>Why hello there! This site describes my involvement in the "Battle for Wesnoth" developement so far.<br />
<br />
<br />
== Translation & internationalisation ==<br />
<br />
I was maintaining the Polish translation of "Battle for Wesnoth" for more than 1.5 year, starting spring 2005. In that time, with enormous help of a few people (mentioned in credits), we managed to complete the translation of all the mainline strings for 1.0.2 and 1.2 releases. We've started with basically nothing (barely ~5% completed at the beginning makes me wonder why previous translators even appear in the credits).<br />
<br />
== Developement ==<br />
<br />
I've started my developement with a few patches, mainly bugfixes. Later on, 2 medium-size projects have begun to evolve:<br />
<br />
=== GP2X port ===<br />
<br />
A port of BfW to Gamepark Holding's GP2X handheld console. The project is currently stalled due to lack of interest on my part and broken hardware... The game basically runs, but there still a few problems to solve.<br />
<br />
What's been accomplished involves: <br />
* fixes to the unmaintained tinygui interface, to make the game playable in 320x240 resolution; <br />
* one-time caching without revalidation to greatly improve startup times<br />
* sound-cache limiting to save on memory<br />
* joystick mouse support, to move mouse cursor using GP2X's stick<br />
* fixed image resize script, used to downscale BfW graphics on install (saves memory and cpu cycles)<br />
<br />
What's left:<br />
* memory usage problems which make the game unplayable; <br />
GP2X has only 32 megs of OS-available RAM, about 24MB more can be accessed with paeryn's hardware SDL lib<br />
* drawing speed - using doublebuffering and hardware blitter don't go well with Wesnoth's display model; <br />
maybe the OpenGL branch is a better base for this port?!<br />
* second CPU core usage - GP2X is based on a MMSP2 SoC, which has two ARM cores available; <br />
possibly off-load music decoding or some AI routines to the 940 core?<br />
<br />
=== Sound sources support ===<br />
<br />
My pet-project waiting for some free time. 8)<br />
<br />
"Sound sources" is a general name for a mechanism, which makes it possible for map elements to emit sounds according to some rules, where "map elements" can be specific locations or terrain patches. One has complete control over them with the WML. <br />
<br />
===== Tags implemented in trunk (for testing purposes only): =====<br />
<br />
<tt>[sound_source]</tt> - creates a sound source<br />
<br />
''Available parameters:''<br />
<br />
<tt>sounds=list,of,comma,seperated,sounds</tt> - list of sounds associated with this source, played randomly<br />
<br />
<tt>id=numerical value</tt> - internal id used to manipulate this source<br />
<br />
<tt>delay=numerical value</tt> - mininal delay (in ms) between two playbacks of source's sound if the source remains visible on the screen; if one scrolls out and back in, the source will be considered as ready to play<br />
<br />
<tt>chance=numerical value</tt> - a number from [0, 100] range, describing what's the chance of source being <br />
activated every second after the ''delay'' has passed or when the source's location appears on the screen (note that it cannot play more than one file at the same time anyway)<br />
<br />
<tt>check_fogged=boolean value</tt> = true or false; if true the source won't play if its location is fogged/shrouded<br />
<br />
<tt>x=list,of,numerical,values</tt> a list of x coordinates associated with this sound source (must match y list)<br />
<br />
<tt>y=list,of,numerical,values</tt> a list of y coordinates associated with this sound source (must match x list)<br />
<br />
<br />
<tt>[sound_source]</tt> - removes a sound source<br />
<br />
''Available parameters:'' <br />
<br />
<tt>id=numerical value</tt> - id of the sound source to be removed</div>Grzywaczhttps://wiki.wesnoth.org/index.php?title=Description&diff=14079Description2007-02-26T17:23:35Z<p>Grzywacz: Update screenshots from 0.8...</p>
<hr />
<div>== What is Battle for Wesnoth? ==<br />
<br />
The Battle for Wesnoth is a turn-based strategy game with a fantasy theme.<br />
<br />
<div class="thumb tright"><div><br />
[http://www.wesnoth.org/images/sshots/wesnoth-1.2-b.jpg http://www.wesnoth.org/images/sshots/wesnoth-1.2-b-175.jpg]<br />
<div class="thumbcaption">A magical lightning strikes</div></div><br />
</div><br />
<br />
Build up a great army, gradually turning raw recruits into hardened veterans. In later games, recall your toughest warriors and form a deadly host against whom none can stand! Choose units from a large pool of specialists, and hand-pick a force with the right strengths to fight well on different terrains against all manner of opposition.<br />
<br />
Wesnoth has many different sagas waiting to be played out. Fight to regain the throne of Wesnoth, of which you are the legitimate heir... step into the boots of a young officer sent to guard a not-so-sleepy frontier outpost... vanquish a horde of undead warriors unleashed by a foul necromancer, who also happens to have taken your brother hostage... guide a band of elvish survivors in an epic quest to find a new home.<br />
<br />
200+ unit types. 16 races. 6 major factions. Hundreds of years of history. The world of Wesnoth is absolutely huge and limited only by your creativity - make your own custom units, compose your own maps, and write your own scenarios or even full-blown campaigns. You can also challenge up to 8 friends - or strangers - and fight in epic ''multi-player'' fantasy battles.<br />
<br />
== Features ==<br />
<br />
<div class="thumb tright"><div><br />
[http://www.wesnoth.org/images/sshots/wesnoth-1.2-e.jpg http://www.wesnoth.org/images/sshots/wesnoth-1.2-e-175.jpg]<br />
<div class="thumbcaption">Heir to The Throne</div></div><br />
</div><br />
<br />
* Build up a formidable fighting force, starting from a single leader and a small amount of gold.<br />
* Over 200 unit types in six major factions, all with distinctive abilities, weapons and spells.<br />
* Experienced units gain powerful new abilities as they advance.<br />
* Several multi-player options available, including internet play.<br />
* Scores of different custom-designed maps, and unlimited random maps.<br />
* Hundreds of campaign scenarios available for download via a simple in-game procedure.<br />
* 'Fog of war' feature available for a true test of generalship.<br />
* Sophisticated mark-up language lets advanced users make their own maps, factions or campaigns.<br />
* Excellent language support &ndash; 35 different languages currently available.<br />
* GNU/Linux, Windows, MacOSX, BeOS, Solaris, FreeBSD, OpenBSD, NetBSD, AmigaOS4, OS/2 & eComStation compatible.<br />
<br />
<br />
{{Play}}</div>Grzywaczhttps://wiki.wesnoth.org/index.php?title=Description&diff=14077Description2007-02-26T17:04:14Z<p>Grzywacz: Update screenshot for great justice!</p>
<hr />
<div>== What is Battle for Wesnoth? ==<br />
<br />
The Battle for Wesnoth is a turn-based strategy game with a fantasy theme.<br />
<br />
<div class="thumb tright"><div><br />
[http://www.wesnoth.org/images/sshots/wesnoth-1.2-b.jpg http://www.wesnoth.org/images/sshots/wesnoth-1.2-b-175.jpg]<br />
<div class="thumbcaption">A magical lightning strikes</div></div><br />
</div><br />
<br />
Build up a great army, gradually turning raw recruits into hardened veterans. In later games, recall your toughest warriors and form a deadly host against whom none can stand! Choose units from a large pool of specialists, and hand-pick a force with the right strengths to fight well on different terrains against all manner of opposition.<br />
<br />
Wesnoth has many different sagas waiting to be played out. Fight to regain the throne of Wesnoth, of which you are the legitimate heir... step into the boots of a young officer sent to guard a not-so-sleepy frontier outpost... vanquish a horde of undead warriors unleashed by a foul necromancer, who also happens to have taken your brother hostage... guide a band of elvish survivors in an epic quest to find a new home.<br />
<br />
200+ unit types. 16 races. 6 major factions. Hundreds of years of history. The world of Wesnoth is absolutely huge and limited only by your creativity - make your own custom units, compose your own maps, and write your own scenarios or even full-blown campaigns. You can also challenge up to 8 friends - or strangers - and fight in epic ''multi-player'' fantasy battles.<br />
<br />
== Features ==<br />
<br />
<div class="thumb tright"><div><br />
[http://www.wesnoth.org/images/sshots/wesnoth-0.8.4-burningsuns.png http://www.wesnoth.org/images/sshots/wesnoth-0.8.4-burningsuns-175.jpg]<br />
<div class="thumbcaption">Under the Burning Suns</div></div><br />
</div><br />
<br />
* Build up a formidable fighting force, starting from a single leader and a small amount of gold.<br />
* Over 200 unit types in six major factions, all with distinctive abilities, weapons and spells.<br />
* Experienced units gain powerful new abilities as they advance.<br />
* Several multi-player options available, including internet play.<br />
* Scores of different custom-designed maps, and unlimited random maps.<br />
* Hundreds of campaign scenarios available for download via a simple in-game procedure.<br />
* 'Fog of war' feature available for a true test of generalship.<br />
* Sophisticated mark-up language lets advanced users make their own maps, factions or campaigns.<br />
* Excellent language support &ndash; 35 different languages currently available.<br />
* GNU/Linux, Windows, MacOSX, BeOS, Solaris, FreeBSD, OpenBSD, NetBSD, AmigaOS4, OS/2 & eComStation compatible.<br />
<br />
<br />
{{Play}}</div>Grzywaczhttps://wiki.wesnoth.org/index.php?title=User:Grzywacz&diff=13880User:Grzywacz2007-02-16T21:35:00Z<p>Grzywacz: /* GP2X port */</p>
<hr />
<div>Why hello there! This site describes my involvement in the "Battle for Wesnoth" developement so far.<br />
<br />
<br />
== Translation & internationalisation ==<br />
<br />
I was maintaining the Polish translation of "Battle for Wesnoth" for more than 1.5 year, starting spring 2005. In that time, with enormous help of a few people (mentioned in credits), we managed to complete the translation of all the mainline strings for 1.0.2 and 1.2 releases. We've started with basically nothing (barely ~5% completed at the beginning makes me wonder why previous translators even appear in the credits).<br />
<br />
== Developement ==<br />
<br />
I've started my developement with a few patches, mainly bugfixes. Later on, 2 medium-size projects have begun to evolve:<br />
<br />
=== GP2X port ===<br />
<br />
A port of BfW to Gamepark Holding's GP2X handheld console. The project is currently stalled due to lack of interest on my part and broken hardware... The game basically runs, but there still a few problems to solve.<br />
<br />
What's been accomplished involves: <br />
* fixes to the unmaintained tinygui interface, to make the game playable in 320x240 resolution; <br />
* one-time caching without revalidation to greatly improve startup times<br />
* sound-cache limiting to save on memory<br />
* joystick mouse support, to move mouse cursor using GP2X's stick<br />
* fixed image resize script, used to downscale BfW graphics on install (saves memory and cpu cycles)<br />
<br />
What's left:<br />
* memory usage problems which make the game unplayable; <br />
GP2X has only 32 megs of OS-available RAM, about 24MB more can be accessed with paeryn's hardware SDL lib<br />
* drawing speed - using doublebuffering and hardware blitter don't go well with Wesnoth's display model; <br />
maybe the OpenGL branch is a better base for this port?!<br />
* second CPU core usage - GP2X is based on a MMSP2 SoC, which has two ARM cores available; <br />
possibly off-load music decoding or some AI routines to the 940 core?<br />
<br />
=== Sound sources support ===<br />
<br />
My pet-project waiting for some free time. 8)<br />
<br />
"Sound sources" is a general name for a mechanism, which makes it possible for map elements to emit sounds according to some rules, where "map elements" can be specific locations or terrain patches. One has complete control over them with the WML. <br />
<br />
===== Tags implemented in trunk (for testing purposes only): =====<br />
<br />
<tt>[sound_source]</tt><br />
<br />
''Available parameters:''<br />
<br />
<tt>sounds=list,of,comma,seperated,sounds</tt> - list of sounds associated with this source, played randomly<br />
<br />
<tt>id=numerical value</tt> - internal id used to manipulate this source<br />
<br />
<tt>delay=numerical value</tt> - mininal delay (in ms) between two playbacks of source's sound if the source remains visible on the screen; if one scrolls out and back in, the source will be considered as ready to play<br />
<br />
<tt>chance=numerical value</tt> - a number from [0, 100] range, describing what's the chance of source being <br />
activated every second after the ''delay'' has passed or when the source's location appears on the screen (note that it cannot play more than one file at the same time anyway)<br />
<br />
<tt>check_fogged=boolean value</tt> = true or false; if true the source won't play if its location is fogged/shrouded<br />
<br />
<tt>x=list,of,numerical,values</tt> a list of x coordinates associated with this sound source (must match y list)<br />
<br />
<tt>y=list,of,numerical,values</tt> a list of y coordinates associated with this sound source (must match x list)<br />
<br />
<br />
As for now, these are usable only for testing purposes. A richer implementation as discussed with zookeper is on the way.</div>Grzywaczhttps://wiki.wesnoth.org/index.php?title=User:Grzywacz&diff=13879User:Grzywacz2007-02-16T21:32:27Z<p>Grzywacz: /* GP2X port */</p>
<hr />
<div>Why hello there! This site describes my involvement in the "Battle for Wesnoth" developement so far.<br />
<br />
<br />
== Translation & internationalisation ==<br />
<br />
I was maintaining the Polish translation of "Battle for Wesnoth" for more than 1.5 year, starting spring 2005. In that time, with enormous help of a few people (mentioned in credits), we managed to complete the translation of all the mainline strings for 1.0.2 and 1.2 releases. We've started with basically nothing (barely ~5% completed at the beginning makes me wonder why previous translators even appear in the credits).<br />
<br />
== Developement ==<br />
<br />
I've started my developement with a few patches, mainly bugfixes. Later on, 2 medium-size projects have begun to evolve:<br />
<br />
=== GP2X port ===<br />
<br />
A port of BfW to Gamepark Holding's GP2X handheld console. The project is currently stalled due to lack of interest on my part and broken hardware... The game basically runs, but there still a few problems to solve.<br />
<br />
What's been accomplished involves: <br />
* fixes to unmaintained tinygui interface, to make the game playable in 320x240 resolution; <br />
* one-time caching without revalidation to greatly improve startup times<br />
* sound-cache limiting to save on memory<br />
* joystick mouse support, to move mouse cursor using GP2X's stick<br />
* fixed image resize script, used to downscale BfW graphics on install (saves memory and cpu cycles)<br />
<br />
What's left:<br />
* memory usage problems which make the game unplayable; <br />
GP2X has only 32 megs of OS-available RAM, about 24MB can be accessed with paeryn's hardware SDL lib<br />
* drawing speed - using doublebuffering and hardware blitter don't go well with Wesnoth's display model; <br />
maybe the OpenGL branch is a better base for this port?!<br />
* second CPU core usage - GP2X is based on a MMSP2 SoC, which has two ARM cores available; <br />
possibly off-load music decoding or some AI routines to the 940 core?<br />
<br />
=== Sound sources support ===<br />
<br />
My pet-project waiting for some free time. 8)<br />
<br />
"Sound sources" is a general name for a mechanism, which makes it possible for map elements to emit sounds according to some rules, where "map elements" can be specific locations or terrain patches. One has complete control over them with the WML. <br />
<br />
===== Tags implemented in trunk (for testing purposes only): =====<br />
<br />
<tt>[sound_source]</tt><br />
<br />
''Available parameters:''<br />
<br />
<tt>sounds=list,of,comma,seperated,sounds</tt> - list of sounds associated with this source, played randomly<br />
<br />
<tt>id=numerical value</tt> - internal id used to manipulate this source<br />
<br />
<tt>delay=numerical value</tt> - mininal delay (in ms) between two playbacks of source's sound if the source remains visible on the screen; if one scrolls out and back in, the source will be considered as ready to play<br />
<br />
<tt>chance=numerical value</tt> - a number from [0, 100] range, describing what's the chance of source being <br />
activated every second after the ''delay'' has passed or when the source's location appears on the screen (note that it cannot play more than one file at the same time anyway)<br />
<br />
<tt>check_fogged=boolean value</tt> = true or false; if true the source won't play if its location is fogged/shrouded<br />
<br />
<tt>x=list,of,numerical,values</tt> a list of x coordinates associated with this sound source (must match y list)<br />
<br />
<tt>y=list,of,numerical,values</tt> a list of y coordinates associated with this sound source (must match x list)<br />
<br />
<br />
As for now, these are usable only for testing purposes. A richer implementation as discussed with zookeper is on the way.</div>Grzywaczhttps://wiki.wesnoth.org/index.php?title=User:Grzywacz&diff=13878User:Grzywacz2007-02-16T21:26:14Z<p>Grzywacz: /* Tags implemented in trunk (for testing purposes only): */</p>
<hr />
<div>Why hello there! This site describes my involvement in the "Battle for Wesnoth" developement so far.<br />
<br />
<br />
== Translation & internationalisation ==<br />
<br />
I was maintaining the Polish translation of "Battle for Wesnoth" for more than 1.5 year, starting spring 2005. In that time, with enormous help of a few people (mentioned in credits), we managed to complete the translation of all the mainline strings for 1.0.2 and 1.2 releases. We've started with basically nothing (barely ~5% completed at the beginning makes me wonder why previous translators even appear in the credits).<br />
<br />
== Developement ==<br />
<br />
I've started my developement with a few patches, mainly bugfixes. Later on, 2 medium-size projects have begun to evolve:<br />
<br />
=== GP2X port ===<br />
<br />
A port of BfW to Gamepark Holding's GP2X handheld console. The project is currently stalled due to lack of interest on my part and broken hardware... The game basically runs, but there still a few problems to solve.<br />
<br />
What's been accomplished involves: <br />
* fixes to unmaintained tinygui interface, to make the game playable in 320x240 resolution; <br />
* one-time caching without revalidation to greatly improve startup times<br />
* sound-cache limiting to save on memory<br />
* joystick mouse support, to move mouse cursor using GP2X's stick<br />
* fixed image resize script, used to downscale BfW graphics on install (saves memory and cpu cycles)<br />
<br />
What's left:<br />
* memory usage problems which make the game unplayable; <br />
GP2X has only 32 megs of OS-available RAM, about 24MB can be accessed with paeryn's hardware SDL lib<br />
* drawing speed - using doublebuffering and hardware blitter don't go well with Wesnoth's display model; <br />
maybe the OpenGL branch is a better base for this port?!<br />
* second CPU core usage - GP2X is based on MMSP2 SoC, which has two ARM cores available; <br />
possibly off-load music decoding or some AI routines to the 940 core?<br />
<br />
=== Sound sources support ===<br />
<br />
My pet-project waiting for some free time. 8)<br />
<br />
"Sound sources" is a general name for a mechanism, which makes it possible for map elements to emit sounds according to some rules, where "map elements" can be specific locations or terrain patches. One has complete control over them with the WML. <br />
<br />
===== Tags implemented in trunk (for testing purposes only): =====<br />
<br />
<tt>[sound_source]</tt><br />
<br />
''Available parameters:''<br />
<br />
<tt>sounds=list,of,comma,seperated,sounds</tt> - list of sounds associated with this source, played randomly<br />
<br />
<tt>id=numerical value</tt> - internal id used to manipulate this source<br />
<br />
<tt>delay=numerical value</tt> - mininal delay (in ms) between two playbacks of source's sound if the source remains visible on the screen; if one scrolls out and back in, the source will be considered as ready to play<br />
<br />
<tt>chance=numerical value</tt> - a number from [0, 100] range, describing what's the chance of source being <br />
activated every second after the ''delay'' has passed or when the source's location appears on the screen (note that it cannot play more than one file at the same time anyway)<br />
<br />
<tt>check_fogged=boolean value</tt> = true or false; if true the source won't play if its location is fogged/shrouded<br />
<br />
<tt>x=list,of,numerical,values</tt> a list of x coordinates associated with this sound source (must match y list)<br />
<br />
<tt>y=list,of,numerical,values</tt> a list of y coordinates associated with this sound source (must match x list)<br />
<br />
<br />
As for now, these are usable only for testing purposes. A richer implementation as discussed with zookeper is on the way.</div>Grzywaczhttps://wiki.wesnoth.org/index.php?title=User:Grzywacz&diff=13877User:Grzywacz2007-02-16T21:23:40Z<p>Grzywacz: /* GP2X port */</p>
<hr />
<div>Why hello there! This site describes my involvement in the "Battle for Wesnoth" developement so far.<br />
<br />
<br />
== Translation & internationalisation ==<br />
<br />
I was maintaining the Polish translation of "Battle for Wesnoth" for more than 1.5 year, starting spring 2005. In that time, with enormous help of a few people (mentioned in credits), we managed to complete the translation of all the mainline strings for 1.0.2 and 1.2 releases. We've started with basically nothing (barely ~5% completed at the beginning makes me wonder why previous translators even appear in the credits).<br />
<br />
== Developement ==<br />
<br />
I've started my developement with a few patches, mainly bugfixes. Later on, 2 medium-size projects have begun to evolve:<br />
<br />
=== GP2X port ===<br />
<br />
A port of BfW to Gamepark Holding's GP2X handheld console. The project is currently stalled due to lack of interest on my part and broken hardware... The game basically runs, but there still a few problems to solve.<br />
<br />
What's been accomplished involves: <br />
* fixes to unmaintained tinygui interface, to make the game playable in 320x240 resolution; <br />
* one-time caching without revalidation to greatly improve startup times<br />
* sound-cache limiting to save on memory<br />
* joystick mouse support, to move mouse cursor using GP2X's stick<br />
* fixed image resize script, used to downscale BfW graphics on install (saves memory and cpu cycles)<br />
<br />
What's left:<br />
* memory usage problems which make the game unplayable; <br />
GP2X has only 32 megs of OS-available RAM, about 24MB can be accessed with paeryn's hardware SDL lib<br />
* drawing speed - using doublebuffering and hardware blitter don't go well with Wesnoth's display model; <br />
maybe the OpenGL branch is a better base for this port?!<br />
* second CPU core usage - GP2X is based on MMSP2 SoC, which has two ARM cores available; <br />
possibly off-load music decoding or some AI routines to the 940 core?<br />
<br />
=== Sound sources support ===<br />
<br />
My pet-project waiting for some free time. 8)<br />
<br />
"Sound sources" is a general name for a mechanism, which makes it possible for map elements to emit sounds according to some rules, where "map elements" can be specific locations or terrain patches. One has complete control over them with the WML. <br />
<br />
===== Tags implemented in trunk (for testing purposes only): =====<br />
<br />
<tt>[sound_source]</tt><br />
<br />
''Available parameters:''<br />
<br />
<tt>sounds=list,of,comma,seperated,sounds</tt> - list of sounds associated with this source, played randomly<br />
<br />
<tt>id=numerical value</tt> - internal id used to manipulate this source<br />
<br />
<tt>delay=numerical value</tt> - mininal delay (in ms) between two playbacks of source's sound<br />
<br />
<tt>chance=numerical value</tt> - a number from [0, 100] range, describing what's the chance of source being <br />
acticvated every second (note that it cannot play more than once at the same time anyway)<br />
<br />
<tt>check_fogged=boolean value</tt> = true or false; if true the source won't play if its location is fogged/shrouded<br />
<br />
<tt>x=list,of,numerical,values</tt> a list of x coordinates associated with this sound source (must match y list)<br />
<br />
<tt>y=list,of,numerical,values</tt> a list of y coordinates associated with this sound source (must match x list)<br />
<br />
<br />
As for now, these are usable only for testing purposes. A richer implementation as discussed with zookeper is on the way.</div>Grzywaczhttps://wiki.wesnoth.org/index.php?title=User:Grzywacz&diff=13629User:Grzywacz2007-02-02T21:21:46Z<p>Grzywacz: /* Developement */</p>
<hr />
<div>Why hello there! This site describes my involvement in the "Battle for Wesnoth" developement so far.<br />
<br />
<br />
== Translation & internationalisation ==<br />
<br />
I was maintaining the Polish translation of "Battle for Wesnoth" for more than 1.5 year, starting spring 2005. In that time, with enormous help of a few people (mentioned in credits), we managed to complete the translation of all the mainline strings for 1.0.2 and 1.2 releases. We've started with basically nothing (barely ~5% completed at the beginning makes me wonder why previous translators even appear in the credits).<br />
<br />
== Developement ==<br />
<br />
I've started my developement with a few patches, mainly bugfixes. Later on, 2 medium-size projects have begun to evolve:<br />
<br />
=== GP2X port ===<br />
<br />
A port of BfW to Gamepark Holding's GP2X handheld console. The project is currently stalled due to lack of interest on my part... The game basically runs, but there still a few problems to solve.<br />
<br />
What's been accomplished involves: <br />
* fixes to unmaintained tinygui interface, to make the game playable in 320x240 resolution; <br />
* one-time caching without revalidation to greatly improve startup times<br />
* sound-cache limiting to save on memory<br />
* joystick mouse support, to move mouse cursor using GP2X's stick<br />
* fixed image resize script, used to downscale BfW graphics on install (saves memory and cpu cycles)<br />
<br />
What's left:<br />
* memory usage problems which make the game unplayable; <br />
GP2X has only 32 megs of OS-available RAM, about 24MB can be accessed with paeryn's hardware SDL lib<br />
* drawing speed - using doublebuffering and hardware blitter don't go well with Wesnoth's display model; <br />
maybe the OpenGL branch is a better base for this port?!<br />
* second CPU core usage - GP2X is based on MMSP2 SoC, which has two ARM cores available; <br />
possibly off-load music decoding or some AI routines to the 940 core?<br />
<br />
=== Sound sources support ===<br />
<br />
My pet-project waiting for some free time. 8)<br />
<br />
"Sound sources" is a general name for a mechanism, which makes it possible for map elements to emit sounds according to some rules, where "map elements" can be specific locations or terrain patches. One has complete control over them with the WML. <br />
<br />
===== Tags implemented in trunk (for testing purposes only): =====<br />
<br />
<tt>[sound_source]</tt><br />
<br />
''Available parameters:''<br />
<br />
<tt>sounds=list,of,comma,seperated,sounds</tt> - list of sounds associated with this source, played randomly<br />
<br />
<tt>id=numerical value</tt> - internal id used to manipulate this source<br />
<br />
<tt>delay=numerical value</tt> - mininal delay (in ms) between two playbacks of source's sound<br />
<br />
<tt>chance=numerical value</tt> - a number from [0, 100] range, describing what's the chance of source being <br />
acticvated every second (note that it cannot play more than once at the same time anyway)<br />
<br />
<tt>check_fogged=boolean value</tt> = true or false; if true the source won't play if its location is fogged/shrouded<br />
<br />
<tt>x=list,of,numerical,values</tt> a list of x coordinates associated with this sound source (must match y list)<br />
<br />
<tt>y=list,of,numerical,values</tt> a list of y coordinates associated with this sound source (must match x list)<br />
<br />
<br />
As for now, these are usable only for testing purposes. A richer implementation as discussed with zookeper is on the way.</div>Grzywaczhttps://wiki.wesnoth.org/index.php?title=User:Grzywacz&diff=13628User:Grzywacz2007-02-02T21:21:12Z<p>Grzywacz: /* Translation & internationalisation */</p>
<hr />
<div>Why hello there! This site describes my involvement in the "Battle for Wesnoth" developement so far.<br />
<br />
<br />
== Translation & internationalisation ==<br />
<br />
I was maintaining the Polish translation of "Battle for Wesnoth" for more than 1.5 year, starting spring 2005. In that time, with enormous help of a few people (mentioned in credits), we managed to complete the translation of all the mainline strings for 1.0.2 and 1.2 releases. We've started with basically nothing (barely ~5% completed at the beginning makes me wonder why previous translators even appear in the credits).<br />
<br />
== Developement ==<br />
<br />
I've started my developement with a few patches, mainly bugfixes. Later on, 2 medium-size projects began to evolve:<br />
<br />
=== GP2X port ===<br />
<br />
A port of BfW to Gamepark Holding's GP2X handheld console. The project is currently stalled due to lack of interest on my part... The game basically runs, but there still a few problems to solve.<br />
<br />
What's been accomplished involves: <br />
* fixes to unmaintained tinygui interface, to make the game playable in 320x240 resolution; <br />
* one-time caching without revalidation to greatly improve startup times<br />
* sound-cache limiting to save on memory<br />
* joystick mouse support, to move mouse cursor using GP2X's stick<br />
* fixed image resize script, used to downscale BfW graphics on install (saves memory and cpu cycles)<br />
<br />
What's left:<br />
* memory usage problems which make the game unplayable; <br />
GP2X has only 32 megs of OS-available RAM, about 24MB can be accessed with paeryn's hardware SDL lib<br />
* drawing speed - using doublebuffering and hardware blitter don't go well with Wesnoth's display model; <br />
maybe the OpenGL branch is a better base for this port?!<br />
* second CPU core usage - GP2X is based on MMSP2 SoC, which has two ARM cores available; <br />
possibly off-load music decoding or some AI routines to the 940 core?<br />
<br />
=== Sound sources support ===<br />
<br />
My pet-project waiting for some free time. 8)<br />
<br />
"Sound sources" is a general name for a mechanism, which makes it possible for map elements to emit sounds according to some rules, where "map elements" can be specific locations or terrain patches. One has complete control over them with the WML. <br />
<br />
===== Tags implemented in trunk (for testing purposes only): =====<br />
<br />
<tt>[sound_source]</tt><br />
<br />
''Available parameters:''<br />
<br />
<tt>sounds=list,of,comma,seperated,sounds</tt> - list of sounds associated with this source, played randomly<br />
<br />
<tt>id=numerical value</tt> - internal id used to manipulate this source<br />
<br />
<tt>delay=numerical value</tt> - mininal delay (in ms) between two playbacks of source's sound<br />
<br />
<tt>chance=numerical value</tt> - a number from [0, 100] range, describing what's the chance of source being <br />
acticvated every second (note that it cannot play more than once at the same time anyway)<br />
<br />
<tt>check_fogged=boolean value</tt> = true or false; if true the source won't play if its location is fogged/shrouded<br />
<br />
<tt>x=list,of,numerical,values</tt> a list of x coordinates associated with this sound source (must match y list)<br />
<br />
<tt>y=list,of,numerical,values</tt> a list of y coordinates associated with this sound source (must match x list)<br />
<br />
<br />
As for now, these are usable only for testing purposes. A richer implementation as discussed with zookeper is on the way.</div>Grzywaczhttps://wiki.wesnoth.org/index.php?title=User:Grzywacz&diff=13627User:Grzywacz2007-02-02T21:20:21Z<p>Grzywacz: </p>
<hr />
<div>Why hello there! This site describes my involvement in the "Battle for Wesnoth" developement so far.<br />
<br />
<br />
== Translation & internationalisation ==<br />
<br />
I've been maintaining the Polish translation of "Battle for Wesnoth" for more than 1.5 year, starting spring 2005. In that time, with enormous help of a few people (mentioned in credits), we managed to complete the translation of all the mainline strings for 1.0.2 and 1.2 releases. We've started with basically nothing (barely ~5% completed at the beginning makes me wonder why previous translators even appear in the credits).<br />
<br />
<br />
== Developement ==<br />
<br />
I've started my developement with a few patches, mainly bugfixes. Later on, 2 medium-size projects began to evolve:<br />
<br />
=== GP2X port ===<br />
<br />
A port of BfW to Gamepark Holding's GP2X handheld console. The project is currently stalled due to lack of interest on my part... The game basically runs, but there still a few problems to solve.<br />
<br />
What's been accomplished involves: <br />
* fixes to unmaintained tinygui interface, to make the game playable in 320x240 resolution; <br />
* one-time caching without revalidation to greatly improve startup times<br />
* sound-cache limiting to save on memory<br />
* joystick mouse support, to move mouse cursor using GP2X's stick<br />
* fixed image resize script, used to downscale BfW graphics on install (saves memory and cpu cycles)<br />
<br />
What's left:<br />
* memory usage problems which make the game unplayable; <br />
GP2X has only 32 megs of OS-available RAM, about 24MB can be accessed with paeryn's hardware SDL lib<br />
* drawing speed - using doublebuffering and hardware blitter don't go well with Wesnoth's display model; <br />
maybe the OpenGL branch is a better base for this port?!<br />
* second CPU core usage - GP2X is based on MMSP2 SoC, which has two ARM cores available; <br />
possibly off-load music decoding or some AI routines to the 940 core?<br />
<br />
=== Sound sources support ===<br />
<br />
My pet-project waiting for some free time. 8)<br />
<br />
"Sound sources" is a general name for a mechanism, which makes it possible for map elements to emit sounds according to some rules, where "map elements" can be specific locations or terrain patches. One has complete control over them with the WML. <br />
<br />
===== Tags implemented in trunk (for testing purposes only): =====<br />
<br />
<tt>[sound_source]</tt><br />
<br />
''Available parameters:''<br />
<br />
<tt>sounds=list,of,comma,seperated,sounds</tt> - list of sounds associated with this source, played randomly<br />
<br />
<tt>id=numerical value</tt> - internal id used to manipulate this source<br />
<br />
<tt>delay=numerical value</tt> - mininal delay (in ms) between two playbacks of source's sound<br />
<br />
<tt>chance=numerical value</tt> - a number from [0, 100] range, describing what's the chance of source being <br />
acticvated every second (note that it cannot play more than once at the same time anyway)<br />
<br />
<tt>check_fogged=boolean value</tt> = true or false; if true the source won't play if its location is fogged/shrouded<br />
<br />
<tt>x=list,of,numerical,values</tt> a list of x coordinates associated with this sound source (must match y list)<br />
<br />
<tt>y=list,of,numerical,values</tt> a list of y coordinates associated with this sound source (must match x list)<br />
<br />
<br />
As for now, these are usable only for testing purposes. A richer implementation as discussed with zookeper is on the way.</div>Grzywaczhttps://wiki.wesnoth.org/index.php?title=User:Grzywacz&diff=13626User:Grzywacz2007-02-02T21:18:15Z<p>Grzywacz: </p>
<hr />
<div>Why hello there! This site describes my involvement in the "Battle for Wesnoth" developement so far.<br />
<br />
<br />
== Translation & internationalisation ==<br />
<br />
I've been maintaining the Polish translation of "Battle for Wesnoth" for more than 1.5 year, starting spring 2005. In that time, with enormous help of a few people (mentioned in credits), we managed to complete the translation of all the mainline strings for 1.0.2 and 1.2 releases. We've started with basically nothing (barely ~5% completed at the beginning makes me wonder why previous translators even appear in the credits).<br />
<br />
<br />
== Developement ==<br />
<br />
I've started my developement with a few patches, mainly bugfixes. Later on, 2 medium-size projects began to evolve:<br />
<br />
=== GP2X port ===<br />
<br />
A port of BfW to Gamepark Holding's GP2X handheld console. The project is currently stalled due to lack of interest on my part... The game basically runs, but there still a few problems to solve.<br />
<br />
What's been accomplished involves: <br />
* fixes to unmaintained tinygui interface, to make the game playable in 320x240 resolution; <br />
* one-time caching without revalidation to greatly improve startup times<br />
* sound-cache limiting to save on memory<br />
* joystick mouse support, to move mouse cursor using GP2X's stick<br />
* fixed image resize script, used to downscale BfW graphics on install (saves memory and cpu cycles)<br />
<br />
What's left:<br />
* memory usage problems which make the game unplayable; <br />
GP2X has only 32 megs of OS-available RAM, about 24MB can be accessed with paeryn's hardware SDL lib<br />
* drawing speed - using doublebuffering and hardware blitter don't go well with Wesnoth's display model; <br />
maybe the OpenGL branch is a better base for this port?!<br />
* second CPU core usage - GP2X is based on MMSP2 SoC, which has two ARM cores available; <br />
possibly off-load music decoding or some AI routines to the 940 core?<br />
<br />
=== Sound sources support ===<br />
<br />
My pet-project waiting for some free time. 8)<br />
<br />
"Sound sources" is a general name for a mechanism, which makes it possible for map elements to emit sounds according to some rules, where "map elements" can be specific locations or terrain patches. One has complete control over them with the WML. <br />
<br />
Tags implemented in trunk (for testing purposes only):<br />
<br />
<tt>[sound_source]</tt><br />
<br />
Available parameters:<br />
<br />
<tt>sounds=list,of,comma,seperated,sounds</tt> - list of sounds associated with this source, played randomly<br />
<br />
<tt>id=numerical value</tt> - internal id used to manipulate this source<br />
<br />
<tt>delay=numerical value</tt> - mininal delay (in ms) between two playbacks of source's sound<br />
<br />
<tt>chance=numerical value</tt> - a number from [0, 100] range, describing what's the chance of source being <br />
acticvated every second (note that it cannot play more than once at the same time anyway)<br />
<br />
<tt>check_fogged=boolean value</tt> = true or false; if true the source won't play if its location is fogged/shrouded<br />
<br />
<tt>x=list,of,numerical,values</tt> a list of x coordinates associated with this sound source (must match y list)<br />
<br />
<tt>y=list,of,numerical,values</tt> a list of y coordinates associated with this sound source (must match x list)<br />
<br />
<br />
As for now, these are usable only for testing purposes. A richer implementation as discussed with zookeper is on the way.</div>Grzywaczhttps://wiki.wesnoth.org/index.php?title=User:Grzywacz&diff=13625User:Grzywacz2007-02-02T21:06:28Z<p>Grzywacz: </p>
<hr />
<div>Why hello there! This site describes my involvement in the "Battle for Wesnoth" developement so far.<br />
<br />
<br />
== Translation & internationalisation ==<br />
<br />
I've been maintaining the Polish translation of "Battle for Wesnoth" for more than 1.5 year, starting spring 2005. In that time, with enormous help of a few people (mentioned in credits), we managed to complete the translation of all the mainline strings for 1.0.2 and 1.2 releases. We've started with basically nothing (barely ~5% completed at the beginning makes me wonder why previous translators even appear in the credits).<br />
<br />
<br />
== Developement ==<br />
<br />
I've started my developement with a few patches, mainly bugfixes. Later on, 2 medium-size projects began to evolve:<br />
<br />
=== GP2X port ===<br />
<br />
A port of BfW to Gamepark Holding's GP2X handheld console. The project is currently stalled due to lack of interest on my part... The game basically runs, but there still a few problems to solve.<br />
<br />
What's been accomplished involves: <br />
* fixes to unmaintained tinygui interface, to make the game playable in 320x240 resolution; <br />
* one-time caching without revalidation to greatly improve startup times<br />
* sound-cache limiting to save on memory<br />
* joystick mouse support, to move mouse cursor using GP2X's stick<br />
* fixed image resize script, used to downscale BfW graphics on install (saves memory and cpu cycles)<br />
<br />
What's left:<br />
* memory usage problems which make the game unplayable; <br />
GP2X has only 32 megs of OS-available RAM, about 24MB can be accessed with paeryn's hardware SDL lib<br />
* drawing speed - using doublebuffering and hardware blitter don't go well with Wesnoth's display model; <br />
maybe the OpenGL branch is a better base for this port?!<br />
* second CPU core usage - GP2X is based on MMSP2 SoC, which has two ARM cores available; <br />
possibly off-load music decoding or some AI routines to the 940 core?<br />
<br />
=== Sound sources support ===<br />
<br />
My pet-project waiting for some free time. 8)<br />
<br />
"Sound sources" is a general name for a mechanism, which makes it possible for map elements to emit sounds according to some rules, where "map elements" can be specific locations or terrain patches. One has complete control over them with the WML. <br />
<br />
Currently implemented tags (for testing purposes only):</div>Grzywaczhttps://wiki.wesnoth.org/index.php?title=User:Grzywacz&diff=13624User:Grzywacz2007-02-02T21:03:00Z<p>Grzywacz: /* GP2X port */</p>
<hr />
<div>Why hello there! This site describes my involvement in Wesnoth developement so far.<br />
<br />
<br />
== Translation & internationalisation ==<br />
<br />
I've been maintaining the Polish translation of "Battle for Wesnoth" for more than 1.5 year, starting spring 2005. In that time, with enormous help of a few people (mentioned in credits), we managed to complete the translation of all the mainline strings for 1.0.2 and 1.2 releases. We've started with basically nothing (barely ~5% completed at the beginning makes me wonder why previous translators even appear in the credits).<br />
<br />
<br />
== Developement ==<br />
<br />
I've started my developement with a few patches, mainly bugfixes. Later on, 2 medium-size projects began to evolve:<br />
<br />
=== GP2X port ===<br />
<br />
A port of BfW to Gamepark Holding's GP2X handheld console. The project is currently stalled due to lack of interest on my part... The game basically runs, but there still a few problems to solve.<br />
<br />
What's been accomplished involves: <br />
* fixes to unmaintained tinygui interface, to make the game playable in 320x240 resolution; <br />
* one-time caching without revalidation to greatly improve startup times<br />
* sound-cache limiting to save on memory<br />
* joystick mouse support, to move mouse cursor using GP2X's stick<br />
* fixed image resize script, used to downscale BfW graphics on install (saves memory and cpu cycles)<br />
<br />
What's left:<br />
* memory usage problems which make the game unplayable; <br />
GP2X has only 32 megs of OS-available RAM, about 24MB can be accessed with paeryn's hardware SDL lib<br />
* drawing speed - using doublebuffering and hardware blitter don't go well with Wesnoth's display model; <br />
maybe the OpenGL branch is a better base for this port?!<br />
* second CPU core usage - GP2X is based on MMSP2 SoC, which has two ARM cores available; <br />
possibly off-load music decoding or some AI routines to the 940 core?<br />
<br />
=== Sound sources support ===<br />
<br />
Lorem...</div>Grzywaczhttps://wiki.wesnoth.org/index.php?title=User:Grzywacz&diff=13623User:Grzywacz2007-02-02T21:02:33Z<p>Grzywacz: /* GP2X port */</p>
<hr />
<div>Why hello there! This site describes my involvement in Wesnoth developement so far.<br />
<br />
<br />
== Translation & internationalisation ==<br />
<br />
I've been maintaining the Polish translation of "Battle for Wesnoth" for more than 1.5 year, starting spring 2005. In that time, with enormous help of a few people (mentioned in credits), we managed to complete the translation of all the mainline strings for 1.0.2 and 1.2 releases. We've started with basically nothing (barely ~5% completed at the beginning makes me wonder why previous translators even appear in the credits).<br />
<br />
<br />
== Developement ==<br />
<br />
I've started my developement with a few patches, mainly bugfixes. Later on, 2 medium-size projects began to evolve:<br />
<br />
=== GP2X port ===<br />
<br />
A port of BfW to Gamepark Holding's GP2X handheld console. The project is currently stalled due to lack of interest on my part... The game basically runs, but there still a few problems to solve.<br />
<br />
What's been accomplished involves: <br />
* fixes to unmaintained tinygui interface, to make the game playable in 320x240 resolution; <br />
* one-time caching without revalidation to greatly improve startup times<br />
* sound-cache limiting to save on memory<br />
* joystick mouse support, to move mouse cursor using GP2X's stick<br />
* fixed image resize script, used to downscale BfW graphics on install (saves memory and cpu cycles)<br />
<br />
What's left:<br />
* memory usage problems which make the game unplayable; GP2X has only 32 megs of OS-available RAM. About 24MB can be accessed with paeryn's hardware SDL lib<br />
* drawing speed - using doublebuffering and hardware blitter don't go well with Wesnoth's display model; maybe the OpenGL branch is a better base for this port?!<br />
* second CPU core usage - GP2X is based on MMSP2 SoC, which has two ARM cores available; <br />
possibly off-load music decoding or some AI routines to the 940 core?<br />
<br />
=== Sound sources support ===<br />
<br />
Lorem...</div>Grzywaczhttps://wiki.wesnoth.org/index.php?title=User:Grzywacz&diff=13622User:Grzywacz2007-02-02T21:01:46Z<p>Grzywacz: </p>
<hr />
<div>Why hello there! This site describes my involvement in Wesnoth developement so far.<br />
<br />
<br />
== Translation & internationalisation ==<br />
<br />
I've been maintaining the Polish translation of "Battle for Wesnoth" for more than 1.5 year, starting spring 2005. In that time, with enormous help of a few people (mentioned in credits), we managed to complete the translation of all the mainline strings for 1.0.2 and 1.2 releases. We've started with basically nothing (barely ~5% completed at the beginning makes me wonder why previous translators even appear in the credits).<br />
<br />
<br />
== Developement ==<br />
<br />
I've started my developement with a few patches, mainly bugfixes. Later on, 2 medium-size projects began to evolve:<br />
<br />
=== GP2X port ===<br />
<br />
A port of BfW to Gamepark Holding's GP2X handheld console. The project is currently stalled due to lack of interest on my part... The game basically runs, but there still a few problems to solve.<br />
<br />
What's been accomplished involves: <br />
* fixes to unmaintained tinygui interface, to make the game playable in 320x240 resolution; <br />
* one-time caching without revalidation to greatly improve startup times<br />
* sound-cache limiting to save on memory<br />
* joystick mouse support, to move mouse cursor using GP2X's stick<br />
* fixed image resize script, used to downscale BfW graphics on install (saves memory and cpu cycles)<br />
<br />
What's left:<br />
* memory usage problems which make the game unplayable; GP2X has only 32 megs of OS-available RAM. About 24MB can be accessed with paeryn's hardware SDL lib<br />
* drawing speed - using doublebuffering and hardware blitter don't go well with Wesnoth's display model; maybe the OpenGL branch is a better base for this port?!<br />
* second CPU core usage - GP2X is based on MMSP2 SoC, which has two ARM cores available; possibly off-load music decoding or some AI routines to the 940 core?<br />
<br />
=== Sound sources support ===<br />
<br />
Lorem...</div>Grzywaczhttps://wiki.wesnoth.org/index.php?title=PolishTranslation&diff=12256PolishTranslation2006-10-31T16:47:44Z<p>Grzywacz: /* Polish Translation */</p>
<hr />
<div>== Polish Translation ==<br />
<br />
'' '''Aktualnie działający tłumacze / Currently active translators:''' ''<br />
<br />
* maintainer: None<br />
<br />
<br />
'' ''' Główny wkład w tłumaczenie wnieśli ponadto / Main contributors: ''' ''<br />
* Arkadiusz "szopen" Danilecki - [mailto:adanileckiATcsDOTputDOTpoznanDOTpl]<br />
* Bartek "Dragonking" Waresiak - mailto:dragonkingATo2DOTpl<br />
* Karol "grzywacz" Nowak - [mailto:grzywaczATsulDOTuniD0TlodzDOTpl]<br />
* Michał "Artanis" Jedynak - [mailto:artanisATpocztaDOTfm]<br />
* Michał "misiorysio" Ligowski<br />
* pozostali wymienieni są [[About|tutaj]]<br />
<br />
Jeżeli używasz Wesnoth pod Windows, i masz problem z polskimi znakami, zajrzyj do<br />
http://www.wesnoth.org/forum/viewtopic.php?t=4136<br />
<br />
Postęp prac można zobaczyć [http://gettext.wesnoth.org tutaj].<br />
<br />
== Tłumaczenie polskie ==<br />
<br />
Komentarze dotyczące tłumaczenia prosimy umieszczać na odpowiednim forum ("Translation and Internationalization", wątek "Polish translation"). Można też przesyłać je emailem do koordynatora tłumaczenia (adres powyżej).<br />
<br />
W sieci FreeNode istnieje polski kanał o Wesnoth: #wesnoth-pl, na którym siedzą Polacy bliżej związani z rozwojem tłumaczenia, czy gry w ogóle. Zapraszamy! Tam też można przekazywać swoje uwagi lub zgłaszać się do pomocy w tłumaczeniu.</div>Grzywaczhttps://wiki.wesnoth.org/index.php?title=WesnothTranslations&diff=12255WesnothTranslations2006-10-31T16:46:17Z<p>Grzywacz: /* Translations */</p>
<hr />
<div>== Translations ==<br />
<br />
Wesnoth is currently being translated into the following languages. Instructions on how to contribute are found here:<br />
[[WesnothTranslationsHowTo]].<br />
* [[AfrikaansTranslation|Afrikaans]] - maintainer: Nico Oliver - [mailto:wesnothafATgmailDOTcom]<br />
* [[BasqueTranslation|Basque]] - maintainer: Alfredo Beaumont (ziberpunk) - [mailto:alfredo.beaumontATgmailDOTcom]<br />
* [[BulgarianTranslation|Bulgarian]] maintainer: Georgi Dimitrov (oblak) - [mailto:oblakATgbgDOTbg]<br />
* [[CatalanTranslation|Catalan]] - maintainer: Jordà Polo (ettin) - [mailto:jordaATettinDOTorg]<br />
* [[ChineseTranslation|Chinese]] - maintainer: Firen, [mailto:qhy@hotmail.co.uk] (email address not working)<br />
* [[CzechTranslation|Czech]] - maintainer: Oto Buchta (tapik) - [mailto:tapikATbuchtoviDOTcz]<br />
* [[DanishTranslation|Danish]] maintainer: Anders K. Madsen (madsen) - [mailto:madsenATlillesvinDOTnet]<br />
* [[DutchTranslation|Dutch]] - maintainer: Maarten Albrecht (bloom) - [mailto:maartenalbrechtATgmailDOTcom]<br />
* [[EnglishTranslation|English (US)]] ''(this is the default)'' - maintainer: Sirp - [mailto:davidnwhiteATcomcastDOTnet]<br />
* [[EnglishGBTranslation|English (GB)]] - maintainer: pjr - [mailto:wesnoth@pjr.britishlibrary.net]<br />
* [[EstonianTranslation|Estonian]] - maintainer: Mart Tõnso (rinjin) - [mailto:tmATrinjinDOTpriDOTee]<br />
* [[FilipinoTranslation|Filipino]] - maintainer: Joset Zamora (sophie^) - [mailto:sophieUNDERSCOREgeekATyahooDOTca]<br />
* [[FinnishTranslation|Finnish]] - maintainer: Jussi Rautio (jgrr) - [mailto:jussiDOTrautioAThutDOTfi]<br />
* [[FrenchTranslation|French]] - maintainer: Guillaume Massart (Piou2fois) - [mailto:massartDOTguillaumeATwanadooDOTfr]<br />
* [[GalicianTranslation|Galician]] - maintainer: Jacobo Fernandez (Xacobe) - [mailto:xacobe_gzAThotmailDOTcom] (email address not working)<br />
* [[GermanTranslation|German]] - maintainer: Christoph Berg (chrber) - [mailto:ChristophDOTBergATkpm-sportDOTde]<br />
* [[GreekTranslation|Greek]] - maintainer: Nobody, currently<br />
* [[HebrewTranslation|Hebrew]] maintainer: Oron Peled - [mailto:oronATactcomDOTcoDOTil]<br />
* [[HungarianTranslation|Hungarian]] - maintainer: Széll Tamás (TomJoad) - [mailto:tomiATdigiflexDOThu]<br />
* [[ItalianTranslation|Italian]] - maintainer: Americo Iacovizzi (DarkAmex) - [mailto:americo_iacovizziATliberoDOTit]<br />
* [[JapaneseTranslation|Japanese]] - maintainer: Nobuhito Okada - [mailto:okyadaATgmailDOTcom]<br />
* [[KoreanTranslation|Korean]] - maintainer: Kim Woong - [mailto:jojowarezAThotmailDOTcom] (email address not working)<br />
* [[LatinTranslation|Latin]] - maintainer: Marc Polo ([http://www.wesnoth.org/forum/privmsg.php?mode=post&u=571 mpolo]) - No mail address specified<br />
* [[NorwegianTranslation|Norwegian]] - maintainer: Gaute Jao (Gauteamus) - [mailto:gauteamusATgmailDOTcom]<br />
* [[OccitanTranslation|Occitan]] - maintainer: Nobody, currently<br />
* [[PolishTranslation|Polish]] - maintainer: none<br />
* [[PortugueseTranslation|Portuguese Brazilian]] - maintainer: Claus Aranha (caranha) - [mailto:caranhaATgmailDOTcom]<br />
* [[RussianTranslation|Russian]] - maintainer: Azamat H. Hackimov [mailto:azamatDOThackimovATgmailDOTcom]<!--Alexandr Menovchicov - [mailto:vamATkypiDOTru]--><br />
* [[SerbianTranslation|Serbian]] - maintainer: Srecko Toroman (freecraft)- [mailto:freecraftATgmailDOTcom]<br />
* [[(sk) Preklad|Slovak]] - maintainer: Viliam Bur - [mailto:viliamATburDOTsk]; wiki: [[(sk) Návod]]<br />
* [[SlovenianTranslation|Slovenian]] - maintainer: Jaka Kranjc (lynx) - [mailto:lynxlupodianAThotmailDOTcom]<br />
* [[SpanishTranslation|Spanish]] - maintainer: David Martinez (ender/Jo-Con-El) - [mailto:enderATdebianDOTorg]<br />
* [[SwedishTranslation|Swedish]] - maintainer: Stefan Bergström (tephlon) - [mailto:stefanDOTbergstromATgmailDOTcom]<br />
* [[TurkishTranslation|Turkish]] - currently Unmaintained<br />
* [[ValencianTranslation|Valencian]] - maintainer: Mario (Mavorte) - [mailto:mavorte1ATyahooDOTes]; wiki: [[MavorteValencia]]<br />
* [[VietnameseTranslation|Vietnamese]] - maintainer: Do Hong Minh - [mailto:minhdhAThutticDOTcom]<br />
<br />
<br />
<br />
Other ideas (remember, these are just ideas):<br />
* Translations into Asian languages <br />
** Asian languages are already supported. See [[WesnothAsianLanguages]].<br />
<br />
== See also ==<br />
<br />
* [[WesnothTranslationsHowTo]]<br />
* [[GetText]]<br />
* [http://gettext.wesnoth.org Translations statistics (svn)]<br />
* [[WesCamp| Translating User made Campaigns (featuring WesCamp-i18n)]]</div>Grzywaczhttps://wiki.wesnoth.org/index.php?title=PolishTranslation&diff=11112PolishTranslation2006-08-09T20:36:14Z<p>Grzywacz: /* Polish Translation */</p>
<hr />
<div>== Polish Translation ==<br />
<br />
'' '''Aktualnie działający tłumacze / Currently active translators:''' ''<br />
<br />
* maintainer: Karol "grzywacz" Nowak - [mailto:grzywaczATsulDOTuniD0TlodzDOTpl]<br />
<br />
<br />
'' ''' Główny wkład w tłumaczenie wnieśli ponadto / Main contributors: ''' ''<br />
* Arkadiusz "szopen" Danilecki - [mailto:adanileckiATcsDOTputDOTpoznanDOTpl]<br />
* Bartek "Dragonking" Waresiak - mailto:dragonkingATo2DOTpl<br />
* Michał "Artanis" Jedynak - [mailto:artanisATpocztaDOTfm]<br />
* Michał "misiorysio" Ligowski<br />
* pozostali wymienieni są [[About|tutaj]]<br />
<br />
Jeżeli używasz Wesnoth pod Windows, i masz problem z polskimi znakami, zajrzyj do<br />
http://www.wesnoth.org/forum/viewtopic.php?t=4136<br />
<br />
Postęp prac można zobaczyć [http://gettext.wesnoth.org tutaj].<br />
<br />
== Tłumaczenie polskie ==<br />
<br />
Komentarze dotyczące tłumaczenia prosimy umieszczać na odpowiednim forum ("Translation and Internationalization", wątek "Polish translation"). Można też przesyłać je emailem do koordynatora tłumaczenia (adres powyżej).<br />
<br />
W sieci FreeNode istnieje polski kanał o Wesnoth: #wesnoth-pl, na którym siedzą Polacy bliżej związani z rozwojem tłumaczenia, czy gry w ogóle. Zapraszamy! Tam też można przekazywać swoje uwagi lub zgłaszać się do pomocy w tłumaczeniu.</div>Grzywaczhttps://wiki.wesnoth.org/index.php?title=PolishTranslation&diff=11111PolishTranslation2006-08-09T20:34:55Z<p>Grzywacz: /* Polish Translation */</p>
<hr />
<div>== Polish Translation ==<br />
<br />
'' '''Aktualnie działający tłumacze / Currently active translators:''' ''<br />
<br />
* maintainer: Karol "grzywacz" Nowak - [mailto:REMOV[[EgrzywaczATsulDOTuniD]]0TlodzDOTpl]<br />
<br />
<br />
'' ''' Główny wkład w tłumaczenie wnieśli ponadto / Main contributors: ''' ''<br />
* Arkadiusz "szopen" Danilecki - [mailto:adanileckiATcsDOTputDOTpoznanDOTpl]<br />
* Bartek "Dragonking" Waresiak - mailto:dragonkingATo2DOTpl<br />
* Michał "Artanis" Jedynak - [mailto:artanisATpocztaDOTfm]<br />
* Michał "misiorysio" Ligowski<br />
* pozostali wymienieni są [[About|tutaj]]<br />
<br />
Jeżeli używasz Wesnoth pod Windows, i masz problem z polskimi znakami, zajrzyj do<br />
http://www.wesnoth.org/forum/viewtopic.php?t=4136<br />
<br />
Postęp prac można zobaczyć [http://gettext.wesnoth.org tutaj].<br />
<br />
== Tłumaczenie polskie ==<br />
<br />
Komentarze dotyczące tłumaczenia prosimy umieszczać na odpowiednim forum ("Translation and Internationalization", wątek "Polish translation"). Można też przesyłać je emailem do koordynatora tłumaczenia (adres powyżej).<br />
<br />
W sieci FreeNode istnieje polski kanał o Wesnoth: #wesnoth-pl, na którym siedzą Polacy bliżej związani z rozwojem tłumaczenia, czy gry w ogóle. Zapraszamy! Tam też można przekazywać swoje uwagi lub zgłaszać się do pomocy w tłumaczeniu.</div>Grzywaczhttps://wiki.wesnoth.org/index.php?title=Credits&diff=11018Credits2006-08-03T16:11:39Z<p>Grzywacz: /* Translators */</p>
<hr />
<div>{| style="float:right"<br />
|<br />
__TOC__<br />
|}<br />
In July 2003, '''David White''' released the first version of Wesnoth. Since then, many people have joined the project, contributing in very different ways.<br />
<br />
== Developers ==<br />
====Coders, (minor and major)====<br />
* Alfredo Beaumont (ziberpunk) - autotools<br />
* András Salamon ([[User:Ott|ott]]) - QA, bug fixing, subediting, game mechanics<br />
* Benoît Timbert (Noyga) - coder<br />
* Bram Ridder (Morloth) - editor improvements<br />
* [[User:bruno|Bruno Wolff III]] - Campaign web interface, [[MainlineScenarios#The_Dark_Hordes|The Dark Hordes]] maintainer, bug fixing, minor coder<br />
* Cédric Duval - coder, internationalization manager<br />
* David Philippi (Torangan) - internationalization manager, wescamp<br />
* [mailto:davidnwhite_AT_verizon.net David White] (Sirp) - founder, lead developer, scenario designer<br />
* Dominic Bolin (Xan) - programmer<br />
* Guillaume Melquiond (silene) - coding, bug fixes<br />
* Jérémy Rosen (Boucman) - coder<br />
* Jörg Hinrichs (Yogi Bear/YogiHH) - coder<br />
* Jon Daniel (forcemstr) - coder, bug fixes<br />
* [mailto:mcnabb_AT_gravity.psu.edu J.W.C. McNabb] (Darth Fool) - coder, graphics<br />
* Justin Zaun (jzaun) - coder, scenario designer<br />
* [mailto:erl_AT_erl.se Kristoffer Erlandsson] (erl) - help system, editor<br />
* Nicolas Weeger (ryo) - Python API<br />
* [mailto:patrick_x99(AT).hotmail.com Patrick Parker] ([[User:Sapient|Sapient]]) - misc. gui changes, orphaned-idea adopter<br />
* [mailto:philippe.plantier_AT_naema.org Philippe Plantier] ([[User:Ayin|Ayin]]) - several parts of the code, notably terrain graphics code<br />
* [mailto:ydirson_AT_altern.org Yann Dirson] - gettext support, tinygui<br />
<br />
====Miscellaneous====<br />
* Benjamin Drieu (benj) - campaign writer (wrote "Son of the Black Eye")<br />
* [mailto:dragonking_AT_o2.pl Bartek Waresiak] (Dragonking) - multiplayer balancing<br />
* Crossbow/Miyo - administrator, release manager<br />
* Francisco Muñoz (fmunoz) - artwork manager, many images, scenario designer (also listed below)<br />
* Hogne Håskjold (frame) - terrain designer (also listed below)<br />
* [mailto:isaac_AT_sindominio.net Isaac Clerencia] - administrator, release manager<br />
* James Spencer (Shade) - campaign writer (wrote "The Rise of Wesnoth")<br />
* Joseph Simmons (Turin) - campaign writer, some graphics (wrote "The Eastern Invasion," and others)<br />
* Mark Michelsen (skovbaer) - internationalization manager<br />
* Mike Quiñones (Doc Paterson) - multiplayer balancing, multiplayer maps<br />
* [mailto:Crazy-Ivanovic_AT_gmx.net Nils Kneuper] (Ivanovic) - internationalization manager, campaign maintainer (Two Brothers)<br />
* Richard Kettering (Jetryl) - artwork manager, many images (also listed below)<br />
* Richard S. (Noy) - multiplayer balancing<br />
* Scott Klempner - campaign maintainer (Heir to the Throne, The Rise of Wesnoth)<br />
* Soliton - multiplayer balancing<br />
* Susanna Björverud (sanna) - internationalization manager<br />
<br />
====Unclassified====<br />
* Jan Zvánovec (jaz)<br />
* John B. Messerly (jbm)<br />
* [mailto:jorda_AT_ettin.org Jordà Polo] (ettin)<br />
* J.R. Blain (Cowboy)<br />
* Maksim Orlovich (SadEagle)<br />
* Zas<br />
<br />
== Artists ==<br />
==== Major Contributors ====<br />
* Francisco Muñoz (fmunoz) - Founding Artist and former lead artist, worked consistently on all aspects till around v0.7-0.9.<br />
* Richard Kettering (Jetryl) - Current art director/slave, major focus on sprites, portraits, buildings, and icons<br />
* Hogne Håskjold (frame/freim) - Current director of terrain art, made much of the current terrains (esp. mountains)<br />
* J.W. Bjerk [http://www.wesnoth.org/wiki/User:Eleazar (Eleazar)] - terrain (esp Chasm, Cave, Water), sprite animations, many general graphics tasks<br />
* James Woo (Pickslide) - portraits (major focus on orcs and campaigns)<br />
* Jason Lutes - portraits (major focus on humans, some campaign portraits)<br />
* ?? (Neoriceisgood) - sprite creator and animator (major focus on drakes, dwarves, saurians)<br />
* Peter Geinitz (Shadow/Wayfarer) - sprite creator and animator<br />
<br />
==== Moderate Contributors ====<br />
* Alex Jarocha-Ernst (Jormungandr) - portraits<br />
* Eli Dupree (Elvish Pillager) - sprites and animations<br />
* Pekka Aikio (pekka) - tiles, esp. castles, and attack icons<br />
* Michael Gil de Muro (grp21) - portraits (for the campaign "The Rise of Wesnoth")<br />
* Robert Bolin (Zebulon) - tiles, sprite editing and animations<br />
* Christophe Anjard (Christophe33) - made many of the old (c. v0.6) terrains, and some sprites for the dwarves<br />
* Johann de Venecia (Johann) - drew the new campaign story art for HttT<br />
<br />
==== Minor Contributors ====<br />
* Gerald Clears (Smok'em Jags) - sprite animator<br />
* Jesse Holland (Kestenvarn) - map illustrator, designed the current map for HttT<br />
* Mark Goodenough (Ranger M) - Sprite animator<br />
* ?? (Zhukov) - Sprite animator<br />
* Mikko Kraft (Deserter) - Sprite animator<br />
* Michael Mielewczik (Mille) - Sprite animator<br />
* Stephen Stone (Disto) - Sprite animator<br />
* Andrew James Patterson (Kamahawk) - sprites<br />
* Diego Brea (Cobretti) - sprite creator/animator<br />
* ?? (antwerpz) - sprite creator/animator for old saurian units<br />
* Moritz Göbelbecker (mog) - improved encampment<br />
* Gareth Miller (Gafgarion) - made some early sprites/tiles<br />
* James Barton (Sangel) - sprites<br />
* John Muccigrosso (Eponymous Archon) - made some early sprites, such as the human bowmen<br />
* ?? (Slainte) - made sprites for c. v0.6 mages, also made many of the old attack icons<br />
* ?? (Svetac) - made many of the old attack icons<br />
* Johanna Manninen (lohari) - edited tiles, ported freeciv tiles used in very early versions of wesnoth<br />
<br />
==== Very Minor Contributors ====<br />
* Gideon Chia (Deonjo) - new "units" icon for general status bar<br />
* John-Robert Funck (XJaPaN) - sprite animator<br />
* Jonatan Alamà (tin) - made red logo used until before v1.0<br />
* Jimmy Olsson (Azlan) - made old icons for windows version<br />
* Randall Walls (slightcrazed) - sprite animator<br />
* Jason Frailey (Valdroni) - made scorpion portrait<br />
* Nicholas Kerpan (Thrawn) - made human theif portrait<br />
* ?? (Highhole) - revised storm trident<br />
* Irwin Ismail (Swordy) - original projectile/attack icon for chakram<br />
* Evan Crook (Flametrooper) - Sprite animator (TC conversion)<br />
<br />
== Musicians ==<br />
* Aleksi Aubry-Carlson (Aleksi) - music coordinator/composer<br />
* Joseph Toscano (zhaymusic.com) - music<br />
* Pau Congost - music<br />
* Fredrik Lindroth - music<br />
* Timothy Pinkham (TimothyP)<br />
<br />
== Translators ==<br />
* adson - hungarian translation<br />
* İhsan Akın - turkish translation<br />
* Agata Chmiel - polish translation<br />
* Aleksej Korgenkov (Grimpanto) - esperanto translation<br />
* Alessio D'Ascanio (otaku) - italian translation<br />
* Alexander Alexiou (Santi) - greek translation<br />
* Alexander Kjäll (capitol) - swedish translation<br />
* Alexandr Menovchicov - russian translation<br />
* Alfredo Beaumont (ziberpunk) - basque translation<br />
* Ambra Viviani Loos - brazilian portuguese translation<br />
* Americo Iacovizzi (DarkAmex) - italian translation<br />
* Anders K. Madsen (madsen) - danish translation<br />
* András Salamon ([[User:Ott|ott]]) - afrikaans, english and hungarian translation<br />
* Andre Schmidt (schmidta) - german translation<br />
* Anežka Bubeníčková (Bubu) - czech translation<br />
* Ankka - finnish translation<br />
* Anton Tsigularov (Atilla) - bulgarian translation<br />
* Arkadiusz Danilecki (szopen) - polish translation<br />
* Arnaud Garoux (La vie en wose) - french translation<br />
* Arne Deprez - dutch translation<br />
* Artur R. Czechowski - polish translation<br />
* Åse Petersson (tintin) - swedish translation<br />
* Aurélien Brevers (Breversa) - french translation<br />
* Azamat Hackimov - russian translation<br />
* Bartek Waresiak (Dragonking) - polish translation<br />
* Beer (Eddi) - hungarian translation<br />
* Benoit Astruc - french translation<br />
* Benoît Timbert (Noyga) - french translation<br />
* Bjarke Sørensen (basher) - danish translation<br />
* BlueStar - japanese translation<br />
* Boris Stumm (quijote_) - german translation<br />
* BOrsuk - polish translation<br />
* Cédric Duval - french translation<br />
* Carles Company (brrr) - catalan translation<br />
* Celso Goya - brazilian portuguese translation<br />
* Christoph Berg (chrber) - german translation<br />
* [mailto:cbterra_AT_gmail.com Claudio Terra] - brazilian portuguese translation<br />
* Claus Aranha - brazilian portuguese translation<br />
* crys0000 - italian translation<br />
* Dan Rosàs Garcia (focks) - catalan translation<br />
* Daniel López (Azazelo) - catalan translation<br />
* DaringTremayne - french translation<br />
* David Martínez Moreno - spanish translation<br />
* David Nečas (Yeti) - czech translation<br />
* dentro - hungarian translation<br />
* Enes Akın (yekialem) - turkish translation<br />
* Erik J. Mesoy (Circon) - norwegian translation<br />
* Eugenio Favalli (ElvenProgrammer) - italian translation<br />
* Federico Tomassetti - italian translation<br />
* Flamma - spanish translation<br />
* Franciso Muñoz (fmunoz) - spanish translation<br />
* François Orieux - french translation<br />
* Gabriel Rodríguez (Chewie) - spanish translation<br />
* Gaute Jao (Bombadil) - norwegian translation<br />
* Georgi Dimitrov (oblak)- bulgarian translation<br />
* Gerfried Fuchs (Alfie) - german translation<br />
* Gilluin - hungarian translation<br />
* Guillaume Duwelz-Rebert - french translation<br />
* [mailto:massart.guillaume_AT_wanadoo.fr Guillaume Massart (Piou2fois)] - french translation<br />
* Guillaume Melquiond (silene) - french translation<br />
* Hallvard Norheim Bø (Lysander) - norwegian translation<br />
* Håvard Korsvoll - norwegian translation<br />
* Huang huan (unicon) - chinese translation<br />
* Hugo Gerlach (Entrimo) - swedish translation<br />
* Ilya Kaznacheev - russian translation<br />
* Ivan Kovacs - slovak translation<br />
* isazi - italian translation<br />
* Iván Herrero (navitux) - spanish translator<br />
* Jaka Kranjc (lynx) - slovenian translation<br />
* Jan Greve (Jan) - german translation<br />
* Jan-Heiner Laberenz (jan-heiner) - german translation<br />
* Jean Privat (Tout) - french translation<br />
* Jean-Luc Richard (Le Gnome) - french translation<br />
* Jehan Hysseo (Jey) - french translation<br />
* Jérémy Rosen (Boucman) - french translation<br />
* Jesper Fuglsang Wolff (ulven) - danish translation<br />
* Joan Queralt - catalan translation<br />
* Joeri Melis - dutch translation<br />
* Jonatan Alamà (tin) - catalan translation<br />
* [mailto:jorda_AT_ettin.org Jordà Polo] (ettin) - catalan translation coordinator<br />
* Jose Gordillo (kilder) - spanish and catalan translation<br />
* Jose Manuel Gomez (joseg) - spanish translation<br />
* Joset Anthony Zamora (sophie^) - filipino translation<br />
* Julien Moncel - french translation<br />
* Julien Tailleur - french translation<br />
* Julen Landa (genars) - basque translation<br />
* Jussi Rautio (jgrr) - finnish translation<br />
* Kai Ensenbach (Pingu) - german translation<br />
* Kékkői László (BlackEvil) - hungarian translation<br />
* Karol Nowak (grzywacz) - polish translation<br />
* Katerina Sykioti - greek translation<br />
* Kertész Csaba - hungarian translation<br />
* Khiraly - hungarian translation<br />
* Kim Woong (Kazya) - korean translation<br />
* kko - finnish translation<br />
* Konstantinos Karasavvas - greek translation<br />
* Kosif - turkish translation<br />
* Kovács Dániel - hungarian translation<br />
* krix - hungarian translation<br />
* Lala - dutch translation<br />
* Leo Danielson (Lugo Moll) - swedish translation<br />
* Luciano Montanaro (Luciano) - italian translation<br />
* Lukáš Faltýnek - czech translation<br />
* Ľubo Fajth - esperanto translation<br />
* Maarten Albrecht - dutch and esperanto translation<br />
* Mark Michelsen (skovbaer) - danish translation<br />
* Mark Polo (mpolo) - latin translation<br />
* Mark Recasens - catalan translation<br />
* Marko Vasic - serbian translation<br />
* Mart Tõnso - estonian translation<br />
* Martin Dzbor - slovak translation<br />
* Martin Šín - czech translation<br />
* Mathias Bundgaard Svensson (freaken) - danish translation<br />
* Matias Parmala - finnish translation<br />
* methinks - polish translation<br />
* Michał Jedynak (Artanis) - polish translation<br />
* Michał Ligowski (misiorysio) - polish translation<br />
* Michel Loos - brazilian portuguese translation<br />
* Mikel Olasagasti (Hey_neken) - basque translation<br />
* Mikko Kraft (deserter) - finnish translation<br />
* Mintaka - czech translation<br />
* Naoki Iimura (amatubu) いいむらなおき - japanese translation<br />
* Nico Oliver - afrikaans translation<br />
* Nicolas Boudin (Blurgk) - french translation<br />
* [mailto:Crazy-Ivanovic_AT_gmx.net Nils Kneuper] (Ivanovic) - german translation<br />
* [mailto:okyada_AT_gmail.com Nobuhito Okada] 岡田信人 - japanese translation<br />
* [mailto:tapik_AT_buchtovi.cz Oto Buchta] ([[User:Tapik|tapik]]) - czech translation<br />
* Pau Rul·lan Ferragut - catalan translation<br />
* Paweł Stradomski - polish translation<br />
* Paweł Tomak - polish translation<br />
* paxed - finnish translation<br />
* Petr Kopač (Ferda) - czech translation<br />
* Petr Kovár (Juans) - czech translation<br />
* [mailto:philippe.plantier_AT_naema.org Philippe Plantier] ([[User:Ayin|Ayin]]) - french translation<br />
* Pieter Vermeylen (Onne) - dutch translation<br />
* P&#305;nar Yanarda&#287; (moonquelle) - turkish translation<br />
* Q - japanese translation<br />
* Rastislav Šarišský (Asto) - esperanto translation<br />
* Renato Cunha - brazilian portuguese translation<br />
* Ricardo Sodré Andrade - brazilian portuguese translation<br />
* Roel Thijs (Roel) - dutch translation<br />
* RokStar - italian translation<br />
* Roman Tuchin (Sankt) - russian translation<br />
* Rudolf Orság - czech translation<br />
* Ruben Philipp Wickenhäuser (The Very Uhu) - german translation<br />
* Sébastien Raynaud (Galactic turkey) - french translation<br />
* Sérgio de Miranda Costa - brazilian portuguese translation<br />
* Selim Farsakoğlu - turkish translation<br />
* Sofronius - czech translation<br />
* Spiros, Giorgis - greek translation<br />
* Srecko Toroman (FreeCraft) - serbian translation<br />
* Stefan Bergström (tephlon) - swedish translation<br />
* Stephan Grochtmann (Schattenstephan) - german translation<br />
* [mailto:susanna.bjorverud_AT_telia.com Susanna Björverud] (sanna) - swedish translation<br />
* Susanne Mesoy (Rarlgland) - norwegian translation<br />
* Széll Tamás (TomJoad) - hungarian translation<br />
* Tiago Souza (Salvador) - brazilian portuguese translation<br />
* Tobe Deprez - dutch translation<br />
* Vít Komárek - czech translation<br />
* Vít Krčál - czech translation<br />
* [http://www.viliam.bur.sk/ Viliam Búr] - slovak translation<br />
* Vladimír Slávik - czech translation<br />
* vonHalenbach - german translation<br />
* William Dupré<br />
* wint3r - swedish translation<br />
* [mailto:ydirson_AT_altern.org Yann Dirson] - french translation<br />
* Yuji Matsumoto - japanese translation<br />
* Zas - french translation<br />
<br />
== Other Contributions ==<br />
* ?? (lwa) - Mac OS X packager<br />
* Ben Anderman (crimson_penguin) - unit list<br />
* Dacyn - scenario designer<br />
* Cyril Bouthors (CyrilB) - debian packager, patron<br />
* Darryl Dixon - packager<br />
* edge - packager<br />
* Francesco Gigli (Jaramir) - wiki, wesnoth.slack.it<br />
* Frédéric Wagner<br />
* Jay Hopping - packager<br />
* Jeff Breidenbach (Jab) - Bilinear interpolation<br />
* Joshua Northey (Becephalus) - multiplayer maps<br />
* Marcin Konicki (ahwayakchih) - BeOS packager<br />
* Marcus Phillips (Sithrandel) - Mac OS X packager (for v1.0 and before)<br />
* Mark Michelsen (skovbaer) - slackware packager<br />
* Peter Groen (pg) - multiplayer maps<br />
* Ruben Philipp Wickenhäuser (The Very Uhu) - multiplayer maps<br />
* Tom Chance (telex4) - multiplayer maps, scenario balancing<br />
* Sam Phillips (dark172) - creation of campains and multiplayer maps<br />
<br />
{{Home}}</div>Grzywaczhttps://wiki.wesnoth.org/index.php?title=Credits&diff=10063Credits2006-06-15T08:15:30Z<p>Grzywacz: Added a new polish translator</p>
<hr />
<div>{| style="float:right"<br />
|<br />
__TOC__<br />
|}<br />
In July 2003, '''David White''' released the first version of Wesnoth. Since then, many people have joined the project, contributing in very different ways.<br />
<br />
== Developers ==<br />
====Coders, (minor and major)====<br />
* Alfredo Beaumont (ziberpunk) - autotools<br />
* András Salamon ([[User:Ott|ott]]) - QA, bug fixing, subediting, game mechanics<br />
* Benoît Timbert (Noyga) - coder<br />
* Bram Ridder (Morloth) - editor improvements<br />
* [[User:bruno|Bruno Wolff III]] - Campaign web interface, [[MainlineScenarios#The_Dark_Hordes|The Dark Hordes]] maintainer, bug fixing, minor coder<br />
* Cédric Duval - coder, internationalization manager<br />
* David Philippi (Torangan) - internationalization manager, wescamp<br />
* [mailto:davidnwhite_AT_verizon.net David White] (Sirp) - founder, lead developer, scenario designer<br />
* Dominic Bolin (Xan) - programmer<br />
* Guillaume Melquiond (silene) - coding, bug fixes<br />
* Jérémy Rosen (Boucman) - coder<br />
* Jörg Hinrichs (Yogi Bear/YogiHH) - coder<br />
* Jon Daniel (forcemstr) - coder, bug fixes<br />
* [mailto:mcnabb_AT_gravity.psu.edu J.W.C. McNabb] (Darth Fool) - coder, graphics<br />
* Justin Zaun (jzaun) - coder, scenario designer<br />
* [mailto:erl_AT_erl.se Kristoffer Erlandsson] (erl) - help system, editor<br />
* Nicolas Weeger (ryo) - Python API<br />
* [mailto:philippe.plantier_AT_naema.org Philippe Plantier] ([[User:Ayin|Ayin]]) - several parts of the code, notably terrain graphics code<br />
* [mailto:ydirson_AT_altern.org Yann Dirson] - gettext support, tinygui<br />
<br />
====Miscellaneous====<br />
* Benjamin Drieu (benj) - campaign writer (wrote "Son of the Black Eye")<br />
* [mailto:dragonking_AT_o2.pl Bartek Waresiak] (Dragonking) - multiplayer balancing<br />
* Crossbow/Miyo - administrator, release manager<br />
* Francisco Muñoz (fmunoz) - artwork manager, many images, scenario designer (also listed below)<br />
* Hogne Håskjold (frame) - terrain designer (also listed below)<br />
* [mailto:isaac_AT_sindominio.net Isaac Clerencia] - administrator, release manager<br />
* James Spencer (Shade) - campaign writer (wrote "The Rise of Wesnoth")<br />
* Joseph Simmons (Turin) - campaign writer, some graphics (wrote "The Eastern Invasion," and others)<br />
* Mark Michelsen (skovbaer) - internationalization manager<br />
* Mike Quiñones (Doc Paterson) - multiplayer balancing, multiplayer maps<br />
* [mailto:Crazy-Ivanovic_AT_gmx.net Nils Kneuper] (Ivanovic) - internationalization manager, campaign maintainer (Two Brothers)<br />
* Richard Kettering (Jetryl) - artwork manager, many images (also listed below)<br />
* Richard S. (Noy) - multiplayer balancing<br />
* Scott Klempner - campaign maintainer (Heir to the Throne, The Rise of Wesnoth)<br />
* Soliton - multiplayer balancing<br />
* Susanna Björverud (sanna) - internationalization manager<br />
<br />
====Unclassified====<br />
* Jan Zvánovec (jaz)<br />
* John B. Messerly (jbm)<br />
* [mailto:jorda_AT_ettin.org Jordà Polo] (ettin)<br />
* J.R. Blain (Cowboy)<br />
* Maksim Orlovich (SadEagle)<br />
* Zas<br />
<br />
== Artists ==<br />
==== Major Contributors ====<br />
* Francisco Muñoz (fmunoz) - Founding Artist and former lead artist, worked consistently on all aspects till around v0.7-0.9.<br />
* Richard Kettering (Jetryl) - Current art director/slave, major focus on sprites, portraits, buildings, and icons<br />
* Hogne Håskjold (frame/freim) - Current director of terrain art, made much of the current terrains (esp. mountains)<br />
* J.W. Bjerk [http://www.wesnoth.org/wiki/User:Eleazar (Eleazar)] - terrain (esp Chasm, Cave, Water), sprite animations, many general graphics tasks<br />
* James Woo (Pickslide) - portraits (major focus on orcs and campaigns)<br />
* Jason Lutes - portraits (major focus on humans, some campaign portraits)<br />
* ?? (Neoriceisgood) - sprite creator and animator (major focus on drakes, dwarves, saurians)<br />
* Peter Geinitz (Shadow/Wayfarer) - sprite creator and animator<br />
<br />
==== Moderate Contributors ====<br />
* Alex Jarocha-Ernst (Jormungandr) - portraits<br />
* Eli Dupree (Elvish Pillager) - sprites and animations<br />
* Pekka Aikio (pekka) - tiles, esp. castles, and attack icons<br />
* Michael Gil de Muro (grp21) - portraits (for the campaign "The Rise of Wesnoth")<br />
* Robert Bolin (Zebulon) - tiles, sprite editing and animations<br />
* Christophe Anjard (Christophe33) - made many of the old (c. v0.6) terrains, and some sprites for the dwarves<br />
* Johann de Venecia (Johann) - drew the new campaign story art for HttT<br />
<br />
==== Minor Contributors ====<br />
* Gerald Clears (Smok'em Jags) - sprite animator<br />
* Jesse Holland (Kestenvarn) - map illustrator, designed the current map for HttT<br />
* Mark Goodenough (Ranger M) - Sprite animator<br />
* Murray Cook (Zhukov) - Sprite animator<br />
* Stephen Stone (Disto) - Sprite animator<br />
* Andrew James Patterson (Kamahawk) - sprites<br />
* Diego Brea (Cobretti) - sprite creator/animator<br />
* ?? (antwerpz) - sprite creator/animator for old saurian units<br />
* Moritz Göbelbecker (mog) - improved encampment<br />
* Gareth Miller (Gafgarion) - made some early sprites/tiles<br />
* James Barton (Sangel) - sprites<br />
* John Muccigrosso (Eponymous Archon) - made some early sprites, such as the human bowmen<br />
* ?? (Slainte) - made sprites for c. v0.6 mages, also made many of the old attack icons<br />
* ?? (Svetac) - made many of the old attack icons<br />
* Johanna Manninen (lohari) - edited tiles, ported freeciv tiles used in very early versions of wesnoth<br />
<br />
==== Very Minor Contributors ====<br />
* Gideon Chia (Deonjo) - new "units" icon for general status bar<br />
* John-Robert Funck (XJaPaN) - sprite animator<br />
* Jonatan Alamà (tin) - made red logo used until before v1.0<br />
* Jimmy Olsson (Azlan) - made old icons for windows version<br />
* Randall Walls (slightcrazed) - sprite animator<br />
* Jason Frailey (Valdroni) - made scorpion portrait<br />
* Nicholas Kerpan (Thrawn) - made human theif portrait<br />
* ?? (Highhole) - revised storm trident<br />
* Irwin Ismail (Swordy) - original projectile/attack icon for chakram<br />
<br />
== Musicians ==<br />
* Aleksi Aubry-Carlson (Aleksi) - music coordinator/composer<br />
* Joseph Toscano (zhaymusic.com) - music<br />
* Pau Congost - music<br />
* Fredrik Lindroth - music<br />
* Timothy Pinkham (TimothyP)<br />
<br />
== Translators ==<br />
* adson - hungarian translation<br />
* İhsan Akın - turkish translation<br />
* Agata Chmiel - polish translation<br />
* Alessio D'Ascanio (otaku) - italian translation<br />
* Alexander Alexiou (Santi) - greek translation<br />
* Alexander Kjäll (capitol) - swedish translation<br />
* Alexandr Menovchicov - russian translation<br />
* Alfredo Beaumont (ziberpunk) - basque translation<br />
* Ambra Viviani Loos - brazilian portuguese translation<br />
* Americo Iacovizzi (DarkAmex) - italian translation<br />
* Anders K. Madsen (madsen) - danish translation<br />
* András Salamon ([[User:Ott|ott]]) - afrikaans, english and hungarian translation<br />
* Andre Schmidt (schmidta) - german translation<br />
* Anežka Bubeníčková (Bubu) - czech translation<br />
* Ankka - finnish translation<br />
* Anton Tsigularov (Atilla) - bulgarian translation<br />
* Arkadiusz Danilecki (szopen) - polish translation<br />
* Arne Deprez - dutch translation<br />
* Artur R. Czechowski - polish translation<br />
* Aurélien Brevers (Breversa) - french translation<br />
* Azamat Hackimov - russian translation<br />
* Bartek Waresiak (Dragonking) - polish translation<br />
* Beer (Eddi) - hungarian translation<br />
* Benoit Astruc - french translation<br />
* Benoît Timbert (Noyga) - french translation<br />
* Bjarke Sørensen (basher) - danish translation<br />
* Boris Stumm (quijote_) - german translation<br />
* BOrsuk - polish translation<br />
* Cédric Duval - french translation<br />
* Carles Company (brrr) - catalan translation<br />
* Celso Goya - brazilian portuguese translation<br />
* Christoph Berg (chrber) - german translation<br />
* Claudio Terra - brazilian portuguese translation<br />
* Claus Aranha - brazilian portuguese translation<br />
* crys0000 - italian translation<br />
* Dan Rosàs Garcia (focks) - catalan translation<br />
* Daniel López (Azazelo) - catalan translation<br />
* DaringTremayne - french translation<br />
* David Martínez Moreno - spanish translation<br />
* David Nečas (Yeti) - czech translation<br />
* dentro - hungarian translation<br />
* Enes Akın (yekialem) - turkish translation<br />
* Erik J. Mesoy (Circon) - norwegian translation<br />
* Eugenio Favalli (ElvenProgrammer) - italian translation<br />
* Federico Tomassetti - italian translation<br />
* Flamma - spanish translation<br />
* Franciso Muñoz (fmunoz) - spanish translation<br />
* François Orieux - french translation<br />
* Gabriel Rodríguez (Chewie) - spanish translation<br />
* Gaute Jao (Bombadil) - norwegian translation<br />
* Georgi Dimitrov (oblak)- bulgarian translation<br />
* Gerfried Fuchs (Alfie) - german translation<br />
* Gilluin - hungarian translation<br />
* Guillaume Duwelz-Rebert - french translation<br />
* [mailto:massart.guillaume_AT_wanadoo.fr Guillaume Massart (Piou2fois)] - french translation<br />
* Guillaume Melquiond (silene) - french translation<br />
* Hallvard Norheim Bø (Lysander) - norwegian translation<br />
* Håvard Korsvoll - norwegian translation<br />
* Huang huan (unicon) - chinese translation<br />
* Ilya Kaznacheev - russian translation<br />
* isazi - italian translation<br />
* Iván Herrero (navitux) - spanish translator<br />
* Jaka Kranjc (lynx) - slovenian translation<br />
* Jan Greve (Jan) - german translation<br />
* Jan-Heiner Laberenz (jan-heiner) - german translation<br />
* Jean Privat (Tout) - french translation<br />
* Jean-Luc Richard (Le Gnome) - french translation<br />
* Jérémy Rosen (Boucman) - french translation<br />
* Jesper Fuglsang Wolff (ulven) - danish translation<br />
* Jonatan Alamà (tin) - catalan translation<br />
* [mailto:jorda_AT_ettin.org Jordà Polo] (ettin) - catalan translation coordinator<br />
* Jose Gordillo (kilder) - spanish and catalan translation<br />
* Jose Manuel Gomez (joseg) - spanish translation<br />
* Joset Anthony Zamora (sophie^) - filipino translation<br />
* Julien Moncel - french translation<br />
* Julien Tailleur - french translation<br />
* Julen Landa (genars) - basque translation<br />
* Jussi Rautio (jgrr) - finnish translation<br />
* Kai Ensenbach (Pingu) - german translation<br />
* Kékkői László (BlackEvil) - hungarian translation<br />
* Karol Nowak (grzywacz) - polish translation<br />
* Katerina Sykioti - greek translation<br />
* Kertész Csaba - hungarian translation<br />
* Khiraly - hungarian translation<br />
* Kim Woong (Kazya) - korean translation<br />
* kko - finnish translation<br />
* Konstantinos Karasavvas - greek translation<br />
* Kosif - turkish translation<br />
* Kovács Dániel - hungarian translation<br />
* krix - hungarian translation<br />
* Lala - dutch translation<br />
* Leo Danielson (Lugo Moll) - swedish translation<br />
* Lim Choon Kiat - 林俊杰 - chinese translation<br />
* Luciano Montanaro (Luciano) - italian translation<br />
* Lukáš Faltýnek - czech translation<br />
* Maarten Albrecht - dutch translation<br />
* Mark Michelsen (skovbaer) - danish translation<br />
* Mark Polo (mpolo) - latin translation<br />
* Mark Recasens - catalan translation<br />
* Mart Tõnso - estonian translation<br />
* Martin Šín - czech translation<br />
* Mathias Bundgaard Svensson (freaken) - danish translation<br />
* Matias Parmala - finnish translation<br />
* methinks - polish translation<br />
* Michał Jedynak (Artanis) - polish translation<br />
* Michel Loos - brazilian portuguese translation<br />
* Mikel Olasagasti (Hey_neken) - basque translation<br />
* Mintaka - czech translation<br />
* Naoki Iimura - japanese translation<br />
* Nico Oliver - afrikaans translation<br />
* Nicolas Boudin (Blurgk) - french translation<br />
* [mailto:Crazy-Ivanovic_AT_gmx.net Nils Kneuper] (Ivanovic) - german translation<br />
* Nobuhito Okada - japanese translation<br />
* [mailto:tapik_AT_buchtovi.cz Oto Buchta] ([[User:Tapik|tapik]]) - czech translation<br />
* Pau Rul·lan Ferragut - catalan translation<br />
* Paweł Stradomski - polish translation<br />
* Paweł Tomak - polish translation<br />
* paxed - finnish translation<br />
* Petr Kopač (Ferda) - czech translation<br />
* Petr Kovár (Juans) - czech translation<br />
* [mailto:philippe.plantier_AT_naema.org Philippe Plantier] ([[User:Ayin|Ayin]]) - french translation<br />
* Pieter Vermeylen (Onne) - dutch translation<br />
* P&#305;nar Yanarda&#287; (moonquelle) - turkish translation<br />
* Renato Cunha - brazilian portuguese translation<br />
* Roel Thijs (Roel) - dutch translation<br />
* RokStar - italian translation<br />
* Roman Tuchin (Sankt) - russian translation<br />
* Rudolf Orság - czech translation<br />
* Ruben Philipp Wickenhäuser (The Very Uhu) - german translation<br />
* Sérgio de Miranda Costa - brazilian portuguese translation<br />
* Selim Farsakoğlu - turkish translation<br />
* Sofronius - czech translation<br />
* Spiros, Giorgis - greek translation<br />
* Srecko Toroman (FreeCraft) - serbian translation<br />
* Stefan Bergström (tephlon) - swedish translation<br />
* Stephan Grochtmann (Schattenstephan) - german translation<br />
* [mailto:susanna.bjorverud_AT_telia.com Susanna Björverud] (sanna) - swedish translation<br />
* Susanne Mesoy (Rarlgland) - norwegian translation<br />
* Széll Tamás (TomJoad) - hungarian translation<br />
* Tiago Souza (Salvador) - brazilian portuguese translation<br />
* Tobe Deprez - dutch translation<br />
* Vít Komárek - czech translation<br />
* Vít Krčál - czech translation<br />
* Viliam Bur - slovak translation<br />
* wint3r - swedish translation<br />
* [mailto:ydirson_AT_altern.org Yann Dirson] - french translation<br />
* Yuji Matsumoto - japanese translation<br />
* Zas - french translation<br />
<br />
== Other Contributions ==<br />
* Ben Anderman (crimson_penguin) - unit list<br />
* Dacyn - scenario designer<br />
* Cyril Bouthors (CyrilB) - debian packager, patron<br />
* Darryl Dixon - packager<br />
* edge - packager<br />
* Francesco Gigli (Jaramir) - wiki, wesnoth.slack.it<br />
* Frédéric Wagner<br />
* Jay Hopping - packager<br />
* Jeff Breidenbach (Jab) - Bilinear interpolation<br />
* Joshua Northey (Becephalus) - multiplayer maps<br />
* Marcin Konicki (ahwayakchih) - BeOS packager<br />
* Marcus Phillips (Sithrandel) - Mac OS X packager<br />
* Mark Michelsen (skovbaer) - slackware packager<br />
* Peter Groen (pg) - multiplayer maps<br />
* Ruben Philipp Wickenhäuser (The Very Uhu) - multiplayer maps<br />
* Tom Chance (telex4) - multiplayer maps, scenario balancing<br />
* Sam Phillips (dark172) - creation of campains and multiplayer maps<br />
<br />
{{Home}}</div>Grzywaczhttps://wiki.wesnoth.org/index.php?title=PolishTranslation&diff=7377PolishTranslation2006-02-17T01:07:55Z<p>Grzywacz: /* Polish Translation */</p>
<hr />
<div>== Polish Translation ==<br />
<br />
'' '''Aktualnie działający tłumacze / Currently active translators:''' ''<br />
<br />
* maintainer: Karol "grzywacz" Nowak - [mailto:REMOV[[EgrzywaczATsulDOTuniD]]0TlodzDOTpl]<br />
<br />
<br />
'' ''' Główny wkład w tłumaczenie wnieśli ponadto / Main contributors: ''' ''<br />
* Arkadiusz "szopen" Danilecki - [mailto:adanileckiATcsDOTputDOTpoznanDOTpl]<br />
* Bartek "Dragonking" Waresiak - mailto:dragonkingATo2DOTpl<br />
* Michał "Artanis" Jedynak - [mailto:artanisATpocztaDOTfm]<br />
* pozostali wymienieni są [[About|tutaj]]<br />
<br />
Jeżeli używasz Wesnoth pod Windows, i masz problem z polskimi znakami, zajrzyj do<br />
http://www.wesnoth.org/forum/viewtopic.php?t=4136<br />
<br />
Postęp prac można zobaczyć [http://gettext.wesnoth.org tutaj].<br />
<br />
== Tłumaczenie polskie ==<br />
<br />
Komentarze dotyczące tłumaczenia prosimy umieszczać na odpowiednim forum ("Translation and Internationalization", wątek "Polish translation"). Można też przesyłać je emailem do koordynatora tłumaczenia (adres powyżej).<br />
<br />
W sieci FreeNode istnieje polski kanał o Wesnoth: #wesnoth-pl, na którym siedzą Polacy bliżej związani z rozwojem tłumaczenia, czy gry w ogóle. Zapraszamy! Tam też można przekazywać swoje uwagi lub zgłaszać się do pomocy w tłumaczeniu.</div>Grzywacz