The Battle for Wesnoth Wiki - User contributions [en]

SavefileWML

2012-08-17T10:00:55Z

Ayne: /* the format for Wesnoth savegames */

{{WML Tags}}
== The format for Wesnoth savegames ==

A Wesnoth savegame is a file stored in '''~saves/''' (See "user data directory", [[PreprocessorRef]]).
n order to view or modify these files, the option Compressed Saves (Advanced Preferences) must be set to "No". Also, since they are not config(.cfg) files the normal coloring will not be generated. To generate coloring, simply save the file as .cfg, then open it again.

{{DevFeature1.11}} There are 3 types of savegames: Start-of-scenario, replay and in-game (including autosave and out-of-sync save). The information included in a save depends on its type.

{|
|-
| || Start-of-scenario || Replay || In-game
|-
| General info and statistics || Yes || Yes || Yes
|-
| [snapshot] || No || No || Yes
|-
| [replay] || No || Yes || Yes
|-
| [replay_start] || No || Yes || Yes
|-
| [carryover_sides] || No || Yes || Yes
|-
| [carryover_sides_start] || Yes || Yes || Yes
|}

'''General info and statistics'''

Contains general information about the scenario, campaign and version of Battle for Wesnoth the savegame is from. This information is included in all savegames.
Not all tags of this section are explained here.

* '''version''': The version of Wesnoth this game was saved by. If the savegame is from a different version of Wesnoth than the one currently running, the message "This save is from a different version of the game. Do you want to try to load it?" is displayed
* '''campaign_type''': Whether the scenario is a scenario or multiplayer.
* '''campaign_define''': When this replay is loaded, the symbol campaign_define will be stored. See also "#ifdef", [[PreprocessorRef]]
* '''difficulty''': The difficulty level of the savegame. Normal values are "EASY", "NORMAL", and "HARD".
* '''label''': heading of the save
* '''next_scenario''': Name of the next scenario in a campaign
* '''scenario''': Name of the current scenario
* '''[multiplayer]''': If the game is a multiplayer game, multiplayer information is inculded here
* '''[statistics]''': Describes previous scenarios
** '''mid_scenario''': If "false", the scenario will be reloaded and any modifications will be played with.
** '''[scenario]''': Describes basic statistics of a previous scenario. See [[StatisticalScenarioWML]] for a description of [scenario]

'''[snapshot]'''

The [snapshot] describes the current state of the game in an in-game save. It has the same format as the rest of the savefile and holds the map of the scenario. The snapshot is loaded when “Show replay” is not selected.

* '''playing_team''': the number of the team whose turn it is, starting with 0
* '''turn_at''': The number of the current turn
* '''map_data''': The data for the map. The mini-map generated by this data is displayed to the right

'''[replay_start]'''

[replay_start] is a full snapshot of the start of the first turn of a scenario. It describes the position the player was in when the game started and is used as starting point for replays.

'''[replay]'''

The [replay] contains everything that happened in the scenario since it started.

* '''[command]''': Describes one action. Syntax for [command] is described in [[ReplayWML]]

'''[carryover_sides_start]'''

[carryover_sides_start] contains the carryover data from the previous scenario, like retained gold and units. It is also used to store in-game data required in the next level, such as variables, the random seed and menu items. [carryover_sides_start] retains the data throughout the scenario.

* '''random_calls''' and '''random_seed''': Used to determine and synchronize random events in the game
* '''[side]''': Player information, retained gold, recruits and recalls for all sides in the game
* '''[end_level_data]''': Contains the information how the carryover data should be used.*
* '''[variables]''': a list of the current values of all variables. The attribute variable//=//value// means that the variable variable has the value value. The tag [array//]describes a unit stored in the array array (see [[SingleUnitWML]]). See also [[VariablesWML]]
* '''[menu_item]''': Custom WML menu items

'''[carryover_sides]'''

[carryover_sides] is a copy of the data in [carryover_sides_start]. Anything to be used in the new scenario is removed from [carryover_sides]. At the end of the scenario the carryover for the next scenario is added to what is left in [carryover_sides].

== See Also ==
* [[ReferenceWML]]

[[Category: WML Reference]]

SoC2012 Ayne Multiplayer Engine Refactoring

2012-04-10T00:22:39Z

Ayne:

{{SoC2012Student}}
[[Category:SoC Ideas Multiplayer Engine Refactoring 2012]]

=Description=
<h4>Anja Keicher - Improve wesnoth's engine to allow better transitions between scenarios</h4>
The idea is to clean up playcampaign.cpp and make loading/saving multiplayer campaigns more stable and less error prone. The code that handles transitions between scenarios should also be improved to make transfer of gold, units and recall lists easier for campaign designers. Other functionality, such as changes to difficulty between scenarios and interaction with GUI2 dialogs could also be added.

= Additional =
While improving the loading of savegames I will have to make sure that compatibility with old savegames remains. The same applies to the scenario transitions: current workarounds have to be supported as much as possible.

=IRC=
Ayne
=SoC Application=
Submitted to google

=Questionnaire=

1) Basics

1.1) Write a small introduction to yourself.

1) Basics

1.1) Write a small introduction to yourself.

My name is Anja Keicher. I'm a 21 year old student from Germany currently studying in the UK. I spent the first two years of my Bachelor degree at Hochschule Osnabrueck in Germany studying European Media Computer Science, then went to Edinburgh Napier University in Scotland to finish the degree in Games Development.

1.2) State your preferred email address.

I will put it in the GSoC application.

1.3) If you have chosen a nick for IRC and Wesnoth forums, what is it?

Ayne

1.4) Why do you want to participate in summer of code?

It sounds like an excellent opportunity to do what I enjoy doing, work on a large community project, and collect a lot of valuable experience. It would also allow me to earn money to help fund my studies through working on something relevant to my studies.

1.5) What are you studying, subject, level and school?

That's a bit complicated. The short version is: Games Development as part of a Bachelor degree in Media Computer Science. I'm in the last semester of my Bachelor degree. The Games Development part is at Edinburgh Napier University in the UK, the Media Computer Science part at Hochschule Osnabrueck (University of Applied Sciences Osnabrueck) in Germany.

1.6) What country are you from, at what time are you most likely to be able to join IRC?

I currently live in the UK and would most likely be on IRC between 11am and 12am GMT.

1.7) Do you have other commitments for the summer period ? Do you plan to take any vacations ? If yes, when.

I plan to take a vacation from the 3rd to 7th July. Other than that there will be one weekend in June and a few separate days in August where I will be unavailable (dates to be confirmed).

2) Experience

2.1) What programs/software have you worked on before?

University projects covering a wide range of subjects, including games using ActionScript3, XNA, Groovy and for Android devices, stock and database managing software, and websites.

2.2) Have you developed software in a team environment before? (As opposed to hacking on something on your own)

The practical side of my studies in Germany was almost exclusively in teams. The teams I have worked in so far were generally 2 to 5 people.

2.3) Have you participated to the Google Summer of Code before? As a mentor or a student? In what project? Were you successful? If not, why?

This is my first time participating in GsoC.

2.4) Are you already involved with any open source development projects? If yes, please describe the project and the scope of your involvement.

This is the first time I'm involved in an open source project.

2.5) Gaming experience - Are you a gamer?

Definitely. Gaming is what got me interested in developing software rather than just using it in the first place.

2.5.1) What type of gamer are you?

Generally casual, though when I find a game I like I'll try to spend any time I can spare playing it. I'm a quality player rather than quantity, a game has to catch my attention, but if I like it I will play it thoroughly and several times to explore different aspects of the game.

2.5.2) What type of games?

Mostly single-player RPGs such as the Elder Scrolls series, Fallout, Dragon Age, Mass Effect etc; though I do enjoy puzzle games like Portal and strategy games like Age of Empires (or Wesnoth) as well.

2.5.3) What type of opponents do you prefer?

AI opponents. It allows me to play the way I want, and I actually stand a chance ;)

2.5.4) Are you more interested in story or gameplay?

I'm very story driven, but if I just wanted the story I'd read a book or watch a movie. The gameplay definitely is an important aspect as well, and has to be right, otherwise I can't enjoy the story. Not all games are the same though, with some the story is more important and with others the story is just an excuse the enjoy the gameplay.

2.5.5) Have you played Wesnoth? If so, tell us roughly for how long and whether you lean towards single player or multiplayer.

I've started playing Wesnoth when I first saw it on the list of GsoC projects and have been playing it a bit every day since to get a feeling for it. I haven't really tried multiplayer yet, but usually I prefer playing single-player or multiplayer with the human players rather than against them.

2.6) If you have contributed any patches to Wesnoth, please list them below. You can also list patches that have been submitted but not committed yet and patches that have not been specifically written for GSoC. If you have gained commit access to our SVN (during the evaluation period or earlier) please state so.

https://gna.org/patch/?3235

3) Communication skills

3.1) Though most of our developers are not native English speakers, English is the project's working language. Describe your fluency level in written English.

I spent some time living in New Zealand and I currently live and study in Scotland. I haven't had problems communicating with anyone in many years. It's not perfect, but speaking or writing in English is definitely not a problem.

3.2) What spoken languages are you fluent in?

English, German

3.3) Are you good at interacting with other players? Our developer community is friendly, but the player community can be a bit rough.

I haven't interacted with the Wesnoth player community yet, but I generally don't have problems getting along with people, or staying calm and polite during conflicts.

3.4) Do you give constructive advice?

I try to give either constructive advice or none at all. If I can help someone or give them advice then I'm happy to do so.

3.5) Do you receive advice well?

As long as it's constructive I'm always grateful for pointers on how to improve my work.

3.6) Are you good at sorting useful criticisms from useless ones?

Generally, yes.

3.7) How autonomous are you when developing ? Would you rather discuss intensively changes and not start coding until you know what you want to do or would you rather code a proof of concept to "see how it turn out", taking the risk of having it thrown away if it doesn't match what the project want

I'm perfectly capable of making decisions myself, but if it's a major change I prefer to discuss it with other people first, especially if I'm new to a project. In my experience that's more efficient in the long run.

4) Project

4.1) Did you select a project from our list? If that is the case, what project did you select? What do you want to especially concentrate on?

I chose the project “Improve wesnoth's engine to allow better transitions between scenarios”. My first priority would be to clean up the code and add comments while I play the game some more to get a better idea of what could and what should be added to the transitions.

4.2) If you have invented your own project, please describe the project and the scope.

-

4.3) Why did you choose this project?

It looks like a nice mix of solid software engineering and games development that represents my studies and experience so far quite well. I think it would be a good introduction into the world of big community projects and open source development for me.

4.4) Include an estimated timeline for your work on the project. Don't forget to mention special things like "I booked holidays between A and B" and "I got an exam at ABC and won't be doing much then".

Before start of GSoC:
I have my last exam on the 3rd May. In the 3 weeks between then and the beginning of GSoC I will have no lectures or other projects, so I will have time to focus on familiarizing myself with Wesnoth in general and especially the code I will work with, and to learn how creating multiplayer campaigns currently works so I can understand the problems from a campaign designer's point of view.

{| border="1"
| 21st May - 15th June || Rewrite the transitions between multiplayer campaign scenarios so that gold, units and recall lists etc. can be transferred properly and without the workarounds currently necessary.
|-
| 16th June - 10th July || Fix saving of multiplayer games so that savegames will no longer be corrupt.
|-
| 03rd July - 07th July || I will most likely be on holidays during this time.
|-
| 11th July - 01st August || Allow loading of old savegames as well as the new savegames by converting old savegames on load.
|-
| 02nd August - 20th August0 || Test, write documentation, fix any remaining issues with the code that has been created so far, add optional features if time allows.
|}

Optional:

Allow changing of difficulty between scenarios (custom lua support)

GUI2 interaction

Apart from one weekend in June, the 5 days in early July, and a few days in August (never more than two at a time) I should be available to work weekdays and weekends as I will finish uni in early May.

4.5) Include as much technical detail about your implementation as you can

I will have to move code to create a cleaner separation between code that handles things in a scenario and code that handles things outside of scenarios.
For the scenario transitions I will have to determine exactly how the code is supposed to work, then recreate that with cleaner code. However, it will also be vital not to break support for the current workarounds or every multiplayer campaign ever written will become unusable.
Code related to saving games will have to be moved and improved to stop savegames to be corrupted under certain conditions.
Code related to loading games will have to be extended to allow loading of savegames from older versions of Battle of Wesnoth as well as savegames created by the new code. This will most likely require some kind of conversion or parsing of the old savegames.

4.6) What do you expect to gain from this project?

More programming experience, especially with large projects.

4.7) What would make you stay in the Wesnoth community after the conclusion of SOC?

A friendly developing community and the feeling that I can continue to contribute to the project.

5) Practical considerations

5.1) Are you familiar with any of the following tools or languages?

Subversion (used for all commits)
I have used Subclipse (Subversion plugin for Eclipse)

C++ (language used for all the normal source code)
We mostly used C and C++ during my first 3 semesters at university. I'm a bit rusty, but it shouldn't take me long to remember all the things I learned.

STL, Boost, Sdl (C++ libraries used by Wesnoth)
None

Python (optional, mainly used for tools)
None

build environments (eg cmake/scons)
Used cmake once, have written a few make files by hand

WML (the wesnoth specific scenario language)
None

Lua (used in combination with WML to create scenarios)
None

5.2) Which tools do you normally use for development? Why do you use them?

My preferred IDE is Eclipse, mostly because I had to use it for most of my modules at university and have gotten used to its features, keyboard shortcuts and GUI.

5.3) What programming languages are you fluent in?

Java, C++, C, C#
I haven't used C and C++ much over the last year, but I think it wouldn't take me long to get the hang of it again.

5.4) Would you mind talking with your mentor on telephone / internet phone? We would like to have a backup way for communications for the case that somehow emails and IRC do fail. If you are willing to do so, please do list a phone number (including international code) so that we are able to contact you. You should probably *only* add this number in the application for you submit to google since the info in the wiki is available in public. We will *not* make any use of your number unless some case of "there is no way to contact you" does arise!

I don't mind talking on the phone. I will add my phone number to the google application, and I can also provide my Skype details if necessary.

SoC2012 Ayne Multiplayer Engine Refactoring

2012-04-05T00:12:28Z

Ayne:

{{SoC2012Student}}
[[Category:SoC Ideas Multiplayer Engine Refactoring 2012]]

=Description=
<h4>Anja Keicher - Improve wesnoth's engine to allow better transitions between scenarios</h4>
The idea is to clean up playcampaign.cpp and make loading/saving multiplayer campaigns more stable and less error prone. The code that handles transitions between scenarios should also be improved to make transfer of gold, units and recall lists easier for campaign designers. Other functionality, such as changes to difficulty between scenarios and interaction with GUI2 dialogs could also be added.

= Additional =
While improving the loading of savegames I will have to make sure that compatibility with old savegames remains. The same applies to the scenario transitions: current workarounds have to be supported as much as possible.

=IRC=
Ayne
=SoC Application=
Submitted to google

=Questionnaire=

1) Basics

1.1) Write a small introduction to yourself.

1) Basics

1.1) Write a small introduction to yourself.

My name is Anja Keicher. I'm a 21 year old student from Germany currently studying in the UK. I spent the first two years of my Bachelor degree at Hochschule Osnabrueck in Germany studying European Media Computer Science, then went to Edinburgh Napier University in Scotland to finish the degree in Games Development.

1.2) State your preferred email address.

I will put it in the GSoC application.

1.3) If you have chosen a nick for IRC and Wesnoth forums, what is it?

Ayne

1.4) Why do you want to participate in summer of code?

It sounds like an excellent opportunity to do what I enjoy doing, work on a large community project, and collect a lot of valuable experience. It would also allow me to earn money to help fund my studies through working on something relevant to my studies.

1.5) What are you studying, subject, level and school?

That's a bit complicated. The short version is: Games Development as part of a Bachelor degree in Media Computer Science. I'm in the last semester of my Bachelor degree. The Games Development part is at Edinburgh Napier University in the UK, the Media Computer Science part at Hochschule Osnabrueck (University of Applied Sciences Osnabrueck) in Germany.

1.6) What country are you from, at what time are you most likely to be able to join IRC?

I currently live in the UK and would most likely be on IRC between 11am and 12am GMT.

1.7) Do you have other commitments for the summer period ? Do you plan to take any vacations ? If yes, when.

I plan to take a vacation from the 3rd to 7th July. Other than that there will be one weekend in June and a few separate days in August where I will be unavailable (dates to be confirmed).

2) Experience

2.1) What programs/software have you worked on before?

University projects covering a wide range of subjects, including games using ActionScript3, XNA, Groovy and for Android devices, stock and database managing software, and websites.

2.2) Have you developed software in a team environment before? (As opposed to hacking on something on your own)

The practical side of my studies in Germany was almost exclusively in teams. The teams I have worked in so far were generally 2 to 5 people.

2.3) Have you participated to the Google Summer of Code before? As a mentor or a student? In what project? Were you successful? If not, why?

This is my first time participating in GsoC.

2.4) Are you already involved with any open source development projects? If yes, please describe the project and the scope of your involvement.

This is the first time I'm involved in an open source project.

2.5) Gaming experience - Are you a gamer?

Definitely. Gaming is what got me interested in developing software rather than just using it in the first place.

2.5.1) What type of gamer are you?

Generally casual, though when I find a game I like I'll try to spend any time I can spare playing it. I'm a quality player rather than quantity, a game has to catch my attention, but if I like it I will play it thoroughly and several times to explore different aspects of the game.

2.5.2) What type of games?

Mostly single-player RPGs such as the Elder Scrolls series, Fallout, Dragon Age, Mass Effect etc; though I do enjoy puzzle games like Portal and strategy games like Age of Empires (or Wesnoth) as well.

2.5.3) What type of opponents do you prefer?

AI opponents. It allows me to play the way I want, and I actually stand a chance ;)

2.5.4) Are you more interested in story or gameplay?

I'm very story driven, but if I just wanted the story I'd read a book or watch a movie. The gameplay definitely is an important aspect as well, and has to be right, otherwise I can't enjoy the story. Not all games are the same though, with some the story is more important and with others the story is just an excuse the enjoy the gameplay.

2.5.5) Have you played Wesnoth? If so, tell us roughly for how long and whether you lean towards single player or multiplayer.

I've started playing Wesnoth when I first saw it on the list of GsoC projects and have been playing it a bit every day since to get a feeling for it. I haven't really tried multiplayer yet, but usually I prefer playing single-player or multiplayer with the human players rather than against them.

2.6) If you have contributed any patches to Wesnoth, please list them below. You can also list patches that have been submitted but not committed yet and patches that have not been specifically written for GSoC. If you have gained commit access to our SVN (during the evaluation period or earlier) please state so.

https://gna.org/patch/?3235

3) Communication skills

3.1) Though most of our developers are not native English speakers, English is the project's working language. Describe your fluency level in written English.

I spent some time living in New Zealand and I currently live and study in Scotland. I haven't had problems communicating with anyone in many years. It's not perfect, but speaking or writing in English is definitely not a problem.

3.2) What spoken languages are you fluent in?

English, German

3.3) Are you good at interacting with other players? Our developer community is friendly, but the player community can be a bit rough.

I haven't interacted with the Wesnoth player community yet, but I generally don't have problems getting along with people, or staying calm and polite during conflicts.

3.4) Do you give constructive advice?

I try to give either constructive advice or none at all. If I can help someone or give them advice then I'm happy to do so.

3.5) Do you receive advice well?

As long as it's constructive I'm always grateful for pointers on how to improve my work.

3.6) Are you good at sorting useful criticisms from useless ones?

Generally, yes.

3.7) How autonomous are you when developing ? Would you rather discuss intensively changes and not start coding until you know what you want to do or would you rather code a proof of concept to "see how it turn out", taking the risk of having it thrown away if it doesn't match what the project want

I'm perfectly capable of making decisions myself, but if it's a major change I prefer to discuss it with other people first, especially if I'm new to a project. In my experience that's more efficient in the long run.

4) Project

4.1) Did you select a project from our list? If that is the case, what project did you select? What do you want to especially concentrate on?

I chose the project “Improve wesnoth's engine to allow better transitions between scenarios”. My first priority would be to clean up the code and add comments while I play the game some more to get a better idea of what could and what should be added to the transitions.

4.2) If you have invented your own project, please describe the project and the scope.

-

4.3) Why did you choose this project?

It looks like a nice mix of solid software engineering and games development that represents my studies and experience so far quite well. I think it would be a good introduction into the world of big community projects and open source development for me.

4.4) Include an estimated timeline for your work on the project. Don't forget to mention special things like "I booked holidays between A and B" and "I got an exam at ABC and won't be doing much then".

Before start of GSoC:
I have my last exam on the 3rd May. In the 3 weeks between then and the beginning of GSoC I will have no lectures or other projects, so I will have time to focus on familiarizing myself with Wesnoth in general and especially the code I will work with, and to learn how creating multiplayer campaigns currently works so I can understand the problems from a campaign designer's point of view.

Start of GSoC until mid/late June:
Rewrite the transitions between multiplayer campaign scenarios so that gold, units and recall lists etc. can be transferred properly and without the workarounds currently necessary.
Mid/late June until early/mid July:
Fix saving of multiplayer games so that savegames will no longer be corrupt.
Early/mid July until early/mid August:
Allow loading of old savegames as well as the new savegames by converting old savegames on load.
Early/mid August until end of GSoC:
Write documentation, fix any remaining issues with the code that has been created so far.

Optional:
Allow changing of difficulty between scenarios (custom lua support)
GUI2 interaction

Apart from one weekend in June, the 5 days in early July, and a few days in August (never more than two at a time) I should be available to work weekdays and weekends as I will finish uni in early May.

4.5) Include as much technical detail about your implementation as you can

I will have to move code to create a cleaner separation between code that handles things in a scenario and code that handles things outside of scenarios.
For the scenario transitions I will have to determine exactly how the code is supposed to work, then recreate that with cleaner code. However, it will also be vital not to break support for the current workarounds or every multiplayer campaign ever written will become unusable.
Code related to saving games will have to be moved and improved to stop savegames to be corrupted under certain conditions.
Code related to loading games will have to be extended to allow loading of savegames from older versions of Battle of Wesnoth as well as savegames created by the new code. This will most likely require some kind of conversion or parsing of the old savegames.

4.6) What do you expect to gain from this project?

More programming experience, especially with large projects.

4.7) What would make you stay in the Wesnoth community after the conclusion of SOC?

A friendly developing community and the feeling that I can continue to contribute to the project.

5) Practical considerations

5.1) Are you familiar with any of the following tools or languages?

Subversion (used for all commits)
I have used Subclipse (Subversion plugin for Eclipse)

C++ (language used for all the normal source code)
We mostly used C and C++ during my first 3 semesters at university. I'm a bit rusty, but it shouldn't take me long to remember all the things I learned.

STL, Boost, Sdl (C++ libraries used by Wesnoth)
None

Python (optional, mainly used for tools)
None

build environments (eg cmake/scons)
Used cmake once, have written a few make files by hand

WML (the wesnoth specific scenario language)
None

Lua (used in combination with WML to create scenarios)
None

5.2) Which tools do you normally use for development? Why do you use them?

My preferred IDE is Eclipse, mostly because I had to use it for most of my modules at university and have gotten used to its features, keyboard shortcuts and GUI.

5.3) What programming languages are you fluent in?

Java, C++, C, C#
I haven't used C and C++ much over the last year, but I think it wouldn't take me long to get the hang of it again.

5.4) Would you mind talking with your mentor on telephone / internet phone? We would like to have a backup way for communications for the case that somehow emails and IRC do fail. If you are willing to do so, please do list a phone number (including international code) so that we are able to contact you. You should probably *only* add this number in the application for you submit to google since the info in the wiki is available in public. We will *not* make any use of your number unless some case of "there is no way to contact you" does arise!

I don't mind talking on the phone. I will add my phone number to the google application, and I can also provide my Skype details if necessary.

SingleUnitWML

2012-04-04T13:11:17Z

Ayne:

{{WML Tags}}
== How to describe a single unit ==

This tag, '''[unit]''', describes a single unit on the map, for example Konrad.
It is different from the [unit_type] in [units], which describes a class of units. However it takes many of the same keys and thus can generally override the inherited properties from the associated [unit_type].

[unit] can be used inside [side] ([[SideWML]]) for units present at start of the scenario, or as [[DirectActionsWML]] for units created during the game. (It is also used in save-files.)

The following keys are recognized:
* '''type''': the ID of the unit's unit type. See [[UnitTypeWML]].

* '''side''': the side that the unit is on. It has to be an existing side, even if the unit is created in a variable.

* '''gender''': can be set to male or female to designate the gender of the unit. Default is male, but if the unit has only a female variant it will be female.

* '''x''', '''y''': the location of the unit. By default ( see '''placement''') if a location isn't provided and the side the unit will belong to has a recall list, the unit will be created on the recall list.

* '''placement''': How the unit should be placed: can be one value or a comma-separated list of values. Default value is 'map,leader' for a leader given directly in [side], "" otherwise. By default, 'map,recall' is implicitly appended to the end of the list.
** '''map''': If x,y are explicitly given and point to a valid on-map location - try to place the unit at the nearest free location to there, never overwriting existing units. Successful if x,y are given and a valid on-map vacant location near it can be found.
** '''leader''': Try to place unit near the leader, if leader is not present or is in recall list - try to place unit near the start location for this side. Successful if a valid on-map vacant location can be found near leader or near start location.
** '''recall''': Place unit on recall list. Always successful.
** '''map_overwrite''': If x,y are explicitly given and point to a valid on-map location - try to place unit at this location, if there was a unit there - overwriting it, without firing events. note: This value does currently (1.9.12) not work since it apparently wasn't implemented; see also http://gna.org/bugs/?15113
** '''map_passable''': If x,y are explicitly given and point to a valid on-map location - try to place unit at this location; if the hex is of an impassable terrain for the unit being placed, or is already occupied by another unit, the new unit will be placed in the nearest vacant hex.

* '''to_variable''': creates the unit into the given variable instead of placing it on the map.

* '''id''': a unique identifier for the unit. This is (usually) not displayed to the player, but is to be used only for identifying and filtering for units. If not specified or when a unit is normally recruited, a random one will be generated for the unit to ensure that each unit has a unique ''id'' attribute. In older versions, the '''description''' attribute specified a unique ID. (The one instance when an id is displayed to the player is when the leader's id is used as the default for a [[SideWML|side]]'s '''current_player''' attribute.)

* '''name''': the user-visible name of the unit. Note that the player may use the "rename unit" action to change this.

* '''generate_name''': (default=yes) will generate a new name if there isn't one specifed for the unit, as if the unit were a freshly-recruited one

* '''unrenamable''': if 'yes', the user-visible name of the unit cannot be changed by the player (which is only possible when the unit is on the player's side anyway).

* '''traits_description''': the description of the unit's traits which is displayed. However if it is not specified explicitly, the unit's actual traits' names will be used instead, so it is normally not necessary to set this.

* '''random_traits''': "no" will prevent random trait generation for units. You should only need to set this for placed nonleaders in multiplayer games or if you want to give a unit less traits than it would normally get for its unit type. When generating traits for a unit, first traits the unit has already been given are excluded. Then "musthave" traits (undead, mechanical) for the unit type are given. Then for leaders ('''canrecruit=yes''') traits that are not available to "any" (currently that's all of them to avoid a multiplayer OOS issue, but later will be restricted based on multiplayer play balance issues) are removed from consideration. Then traits are added randomly until the maximum allowed for the unit type is reached or there are no more available traits. Random traits can now be used in MP games but only when spawned in an event, so not for leaders and other units in the [side] definition.

* '''random_gender''': "yes" will cause the gender of the unit with male and female variations to be male 50% of the time, female 50% of the time. If the unit has only one gender variant it will always be given the correct one.

* '''canrecruit''': a special key for leaders.
** '''no''': default. Unit cannot recruit.
** '''yes''': unit can recruit.
: Normally when a team controls no units with '''canrecruit=yes''', that team loses. However, even if your team has lost you continue to play with whatever units you still have until the scenario is over. Usually scenarios end when only one team is left with a leader that can recruit, but special victory conditions can be set up in campaigns. Normally you want to set the leader of a side with '''canrecruit=yes'''. If you don't want the leader to recruit, it is usually better to just not give him any unit types to recruit, than to make a special victory condition. Units with '''canrecruit=yes''' are exempt from upkeep costs. So that leaders do not need to be given the ''loyal'' trait.
: More than one unit with '''canrecruit=yes''' for the same side (see [[SideWML]]) are allowed in single player, if the side is human-controlled.

* '''extra_recruit''': a list of unit types which this unit can recruit in addition to the ones given by its [side]recruit=, only working for units with '''canrecruit=yes'''.

* '''variation''': the variation of itself the unit should be created as.

* '''upkeep''': the amount of upkeep the unit costs.
** '''loyal''': no upkeep cost. Can be changed by the effect 'loyal' (see [[EffectWML]])
** '''free''': synonymous with "loyal".
** '''full''': unit costs ''level'' upkeep (see [[UnitTypeWML]]).
** An integer can be used to set the upkeep cost to that number.
** The default is "full".
** Leaders (units with '''canrecruit=yes''') never pay upkeep no matter what upkeep is set to.
** Normally you don't want to muck with this value. If you want to give a side units without upkeep costs, give those units the 'loyal' trait.

* '''overlays''': a list of images that are overlayed on the unit.

* '''goto_x''':, '''goto_y''': UI settings that control courses. Default is 0,0 i.e. the unit is not on a course.

* '''hitpoints''': the HP of the unit. Default is the max HP for ''type''.

* '''experience''': the XP of the unit. Default is 0.

* '''moves''': number of movement points the unit has left. Default is the movement for its unit type.

* '''resting''': whether the unit has not moved yet this turn. Used to decide whether to give a unit rest healing.

* '''role''': used in standard unit filter ([[FilterWML]]). Can be set using [role] (see [[InternalActionsWML]]).

* '''ai_special''': causes the unit to act differently
** "guardian" the unit will not move, except to attack something in the turn it moves (so, it only can move if an enemy unit gets within range of it). {{DevFeature1.11}} Does the same as '''[status] guardian = 'yes''''.

* '''facing''': which way the unit is facing (this only affects how the unit is displayed).
** Possible values are '''se''', '''s''', '''sw''', '''nw''', '''n''', '''ne'''. Using '''sw''' is preferred for a "reversed" facing (looking to the left) and '''se''' for a normal (looking to the right) facing.

* '''profile''': sets a portrait image for this unit. If the unit type already has a portrait set, this is used instead for this unit. When the unit advances, if the value of profile is different from the unit-type portrait, that value is preserved. If the profile field is empty or the same as the unit-type portrait, the level-advance changes the unit portrait to the default for the new level and type. See [[UnitTypeWML]] for the rules used for locating files.
** "unit_image" if given instead of a filename, uses the unit's base image as the portrait (in the same manner that unit types without portraits do by default).

* '''small_profile''': sets a small portrait image for this unit. See the '''profile''' attribute above for advancement and special values. As with [[UnitTypeWML]], the location heuristic of the '''profile''' attribute is disabled when the '''small_profile''' attribute is provided.

* '''animate''': if ''yes'', fades the unit in like when it's recruited/recalled.

* '''[status]''' the status of the unit. This affects different features of the unit, for example whether the unit loses health each turn. Default for all keys is 'no', but this can be changed by the scenario or by special abilities (see [[AbilitiesWML]]). The Status Table displays the status of each unit using the three images '''misc/poisoned.png''', '''misc/slowed.png''' and '''misc/petrified.png'''; other keys do not appear in the Status Table.
** '''poisoned''': if 'yes', the unit loses 8 HP each turn. See also ''heals'', ''cures'', [[AbilitiesWML]].
** '''slowed''': if 'yes', the unit has 50% of its normal movement and does half damage. When the controller of the unit's turn is over, ''slowed'' is set to 'off'
** '''petrified''': if 'yes', the unit cannot move, attack, or be attacked.
** '''uncovered''': if 'yes', the unit has performed an action (e.g. attacking) that causes it to no longer be hidden until the next turn.
** '''guardian''': if 'yes', the unit will not move, except to attack something in the turn it moves (so, it only can move if an enemy unit gets within range of it). {{DevFeature1.11}} Does the same as '''ai_special = "guardian"'''.
** '''unhealable''': if set to 'yes', the unit cannot be healed.
** One can add other keys to [status], but they must have boolean values. For example, a scenario can set unit.status.''my_custom_key'' to 'yes' or 'no'.

* '''[variables]''' a set of variables that will be stored when this unit is stored (See [store_unit], [[InternalActionsWML]]). The attribute '''variable'''='''value''' means that when the unit is stored in the array ''unit'', the variable '''unit'''.variables.''variable'' will have the value ''value'' (See [[VariablesWML]]).

* '''[modifications]''' changes that have been made to the unit.
** '''[trait]''' a trait the unit has. Same format as [trait], [[UnitsWML]].
** '''[object]''' an object the unit has. Same format as [object], [[DirectActionsWML]].

* '''[filter_recall]''' A leader can only recall those units which pass the SUF.
**'''[[StandardUnitFilter]]''' tags and keys

* '''unit_description''': overrides the unit type description for this unit. You will probably want to set up a ''post_advance'' [[EventWML|event]] to override the default description after promotions. Or better, use an object with a profile [[EffectWML|effect(s)]] to filter on unit type and change the unit description and/or portrait.

* '''[event]''' The event is copied from this unit's wml description into the scenario. The event is carried along with the unit (it can advance etc) and inserted into every scenario where this unit is first created. A [unit][event] is required a non-empty id= attribute.

== See Also ==

* [[UnitTypeWML]]
* [[ReferenceWML]]

[[Category:WML Reference]]

SingleUnitWML

2012-04-04T11:54:31Z

Ayne:

{{WML Tags}}
== How to describe a single unit ==

This tag, '''[unit]''', describes a single unit on the map, for example Konrad.
It is different from the [unit_type] in [units], which describes a class of units. However it takes many of the same keys and thus can generally override the inherited properties from the associated [unit_type].

[unit] can be used inside [side] ([[SideWML]]) for units present at start of the scenario, or as [[DirectActionsWML]] for units created during the game. (It is also used in save-files.)

The following keys are recognized:
* '''type''': the ID of the unit's unit type. See [[UnitTypeWML]].

* '''side''': the side that the unit is on. It has to be an existing side, even if the unit is created in a variable.

* '''gender''': can be set to male or female to designate the gender of the unit. Default is male, but if the unit has only a female variant it will be female.

* '''x''', '''y''': the location of the unit. By default ( see '''placement''') if a location isn't provided and the side the unit will belong to has a recall list, the unit will be created on the recall list.

* '''placement''': How the unit should be placed: can be one value or a comma-separated list of values. Default value is 'map,leader' for a leader given directly in [side], "" otherwise. By default, 'map,recall' is implicitly appended to the end of the list.
** '''map''': If x,y are explicitly given and point to a valid on-map location - try to place the unit at the nearest free location to there, never overwriting existing units. Successful if x,y are given and a valid on-map vacant location near it can be found.
** '''leader''': Try to place unit near the leader, if leader is not present or is in recall list - try to place unit near the start location for this side. Successful if a valid on-map vacant location can be found near leader or near start location.
** '''recall''': Place unit on recall list. Always successful.
** '''map_overwrite''': If x,y are explicitly given and point to a valid on-map location - try to place unit at this location, if there was a unit there - overwriting it, without firing events. note: This value does currently (1.9.12) not work since it apparently wasn't implemented; see also http://gna.org/bugs/?15113
** '''map_passable''': If x,y are explicitly given and point to a valid on-map location - try to place unit at this location; if the hex is of an impassable terrain for the unit being placed, or is already occupied by another unit, the new unit will be placed in the nearest vacant hex.

* '''to_variable''': creates the unit into the given variable instead of placing it on the map.

* '''id''': a unique identifier for the unit. This is (usually) not displayed to the player, but is to be used only for identifying and filtering for units. If not specified or when a unit is normally recruited, a random one will be generated for the unit to ensure that each unit has a unique ''id'' attribute. In older versions, the '''description''' attribute specified a unique ID. (The one instance when an id is displayed to the player is when the leader's id is used as the default for a [[SideWML|side]]'s '''current_player''' attribute.)

* '''name''': the user-visible name of the unit. Note that the player may use the "rename unit" action to change this.

* '''generate_name''': (default=yes) will generate a new name if there isn't one specifed for the unit, as if the unit were a freshly-recruited one

* '''unrenamable''': if 'yes', the user-visible name of the unit cannot be changed by the player (which is only possible when the unit is on the player's side anyway).

* '''traits_description''': the description of the unit's traits which is displayed. However if it is not specified explicitly, the unit's actual traits' names will be used instead, so it is normally not necessary to set this.

* '''random_traits''': "no" will prevent random trait generation for units. You should only need to set this for placed nonleaders in multiplayer games or if you want to give a unit less traits than it would normally get for its unit type. When generating traits for a unit, first traits the unit has already been given are excluded. Then "musthave" traits (undead, mechanical) for the unit type are given. Then for leaders ('''canrecruit=yes''') traits that are not available to "any" (currently that's all of them to avoid a multiplayer OOS issue, but later will be restricted based on multiplayer play balance issues) are removed from consideration. Then traits are added randomly until the maximum allowed for the unit type is reached or there are no more available traits. Random traits can now be used in MP games but only when spawned in an event, so not for leaders and other units in the [side] definition.

* '''random_gender''': "yes" will cause the gender of the unit with male and female variations to be male 50% of the time, female 50% of the time. If the unit has only one gender variant it will always be given the correct one.

* '''canrecruit''': a special key for leaders.
** '''no''': default. Unit cannot recruit.
** '''yes''': unit can recruit.
: Normally when a team controls no units with '''canrecruit=yes''', that team loses. However, even if your team has lost you continue to play with whatever units you still have until the scenario is over. Usually scenarios end when only one team is left with a leader that can recruit, but special victory conditions can be set up in campaigns. Normally you want to set the leader of a side with '''canrecruit=yes'''. If you don't want the leader to recruit, it is usually better to just not give him any unit types to recruit, than to make a special victory condition. Units with '''canrecruit=yes''' are exempt from upkeep costs. So that leaders do not need to be given the ''loyal'' trait.
: More than one unit with '''canrecruit=yes''' for the same side (see [[SideWML]]) are allowed in single player, if the side is human-controlled.

* '''extra_recruit''': a list of unit types which this unit can recruit in addition to the ones given by its [side]recruit=, only working for units with '''canrecruit=yes'''.

* '''variation''': the variation of itself the unit should be created as.

* '''upkeep''': the amount of upkeep the unit costs.
** '''loyal''': no upkeep cost. Can be changed by the effect 'loyal' (see [[EffectWML]])
** '''free''': synonymous with "loyal".
** '''full''': unit costs ''level'' upkeep (see [[UnitTypeWML]]).
** An integer can be used to set the upkeep cost to that number.
** The default is "full".
** Leaders (units with '''canrecruit=yes''') never pay upkeep no matter what upkeep is set to.
** Normally you don't want to muck with this value. If you want to give a side units without upkeep costs, give those units the 'loyal' trait.

* '''overlays''': a list of images that are overlayed on the unit.

* '''goto_x''':, '''goto_y''': UI settings that control courses. Default is 0,0 i.e. the unit is not on a course.

* '''hitpoints''': the HP of the unit. Default is the max HP for ''type''.

* '''experience''': the XP of the unit. Default is 0.

* '''moves''': number of movement points the unit has left. Default is the movement for its unit type.

* '''resting''': whether the unit has not moved yet this turn. Used to decide whether to give a unit rest healing.

* '''role''': used in standard unit filter ([[FilterWML]]). Can be set using [role] (see [[InternalActionsWML]]).

* '''ai_special''': causes the unit to act differently (see '''[status] guardian''').
** {{DevFeature1.11}} "ai_special" removed, use '''[status] guardian''' instead.

* '''facing''': which way the unit is facing (this only affects how the unit is displayed).
** Possible values are '''se''', '''s''', '''sw''', '''nw''', '''n''', '''ne'''. Using '''sw''' is preferred for a "reversed" facing (looking to the left) and '''se''' for a normal (looking to the right) facing.

* '''profile''': sets a portrait image for this unit. If the unit type already has a portrait set, this is used instead for this unit. When the unit advances, if the value of profile is different from the unit-type portrait, that value is preserved. If the profile field is empty or the same as the unit-type portrait, the level-advance changes the unit portrait to the default for the new level and type. See [[UnitTypeWML]] for the rules used for locating files.
** "unit_image" if given instead of a filename, uses the unit's base image as the portrait (in the same manner that unit types without portraits do by default).

* '''small_profile''': sets a small portrait image for this unit. See the '''profile''' attribute above for advancement and special values. As with [[UnitTypeWML]], the location heuristic of the '''profile''' attribute is disabled when the '''small_profile''' attribute is provided.

* '''animate''': if ''yes'', fades the unit in like when it's recruited/recalled.

* '''[status]''' the status of the unit. This affects different features of the unit, for example whether the unit loses health each turn. Default for all keys is 'no', but this can be changed by the scenario or by special abilities (see [[AbilitiesWML]]). The Status Table displays the status of each unit using the three images '''misc/poisoned.png''', '''misc/slowed.png''' and '''misc/petrified.png'''; other keys do not appear in the Status Table.
** '''poisoned''': if 'yes', the unit loses 8 HP each turn. See also ''heals'', ''cures'', [[AbilitiesWML]].
** '''slowed''': if 'yes', the unit has 50% of its normal movement and does half damage. When the controller of the unit's turn is over, ''slowed'' is set to 'off'
** '''petrified''': if 'yes', the unit cannot move, attack, or be attacked.
** '''uncovered''': if 'yes', the unit has performed an action (e.g. attacking) that causes it to no longer be hidden until the next turn.
** '''guardian''': if 'yes', the unit will not move, except to attack something in the turn it moves (so, it only can move if an enemy unit gets within range of it).
** '''unhealable''': if set to 'yes', the unit cannot be healed.
** One can add other keys to [status], but they must have boolean values. For example, a scenario can set unit.status.''my_custom_key'' to 'yes' or 'no'.

* '''[variables]''' a set of variables that will be stored when this unit is stored (See [store_unit], [[InternalActionsWML]]). The attribute '''variable'''='''value''' means that when the unit is stored in the array ''unit'', the variable '''unit'''.variables.''variable'' will have the value ''value'' (See [[VariablesWML]]).

* '''[modifications]''' changes that have been made to the unit.
** '''[trait]''' a trait the unit has. Same format as [trait], [[UnitsWML]].
** '''[object]''' an object the unit has. Same format as [object], [[DirectActionsWML]].

* '''[filter_recall]''' A leader can only recall those units which pass the SUF.
**'''[[StandardUnitFilter]]''' tags and keys

* '''unit_description''': overrides the unit type description for this unit. You will probably want to set up a ''post_advance'' [[EventWML|event]] to override the default description after promotions. Or better, use an object with a profile [[EffectWML|effect(s)]] to filter on unit type and change the unit description and/or portrait.

* '''[event]''' The event is copied from this unit's wml description into the scenario. The event is carried along with the unit (it can advance etc) and inserted into every scenario where this unit is first created. A [unit][event] is required a non-empty id= attribute.

== See Also ==

* [[UnitTypeWML]]
* [[ReferenceWML]]

[[Category:WML Reference]]

SingleUnitWML

2012-04-04T11:52:48Z

Ayne:

{{WML Tags}}
== How to describe a single unit ==

This tag, '''[unit]''', describes a single unit on the map, for example Konrad.
It is different from the [unit_type] in [units], which describes a class of units. However it takes many of the same keys and thus can generally override the inherited properties from the associated [unit_type].

[unit] can be used inside [side] ([[SideWML]]) for units present at start of the scenario, or as [[DirectActionsWML]] for units created during the game. (It is also used in save-files.)

The following keys are recognized:
* '''type''': the ID of the unit's unit type. See [[UnitTypeWML]].

* '''side''': the side that the unit is on. It has to be an existing side, even if the unit is created in a variable.

* '''gender''': can be set to male or female to designate the gender of the unit. Default is male, but if the unit has only a female variant it will be female.

* '''x''', '''y''': the location of the unit. By default ( see '''placement''') if a location isn't provided and the side the unit will belong to has a recall list, the unit will be created on the recall list.

* '''placement''': How the unit should be placed: can be one value or a comma-separated list of values. Default value is 'map,leader' for a leader given directly in [side], "" otherwise. By default, 'map,recall' is implicitly appended to the end of the list.
** '''map''': If x,y are explicitly given and point to a valid on-map location - try to place the unit at the nearest free location to there, never overwriting existing units. Successful if x,y are given and a valid on-map vacant location near it can be found.
** '''leader''': Try to place unit near the leader, if leader is not present or is in recall list - try to place unit near the start location for this side. Successful if a valid on-map vacant location can be found near leader or near start location.
** '''recall''': Place unit on recall list. Always successful.
** '''map_overwrite''': If x,y are explicitly given and point to a valid on-map location - try to place unit at this location, if there was a unit there - overwriting it, without firing events. note: This value does currently (1.9.12) not work since it apparently wasn't implemented; see also http://gna.org/bugs/?15113
** '''map_passable''': If x,y are explicitly given and point to a valid on-map location - try to place unit at this location; if the hex is of an impassable terrain for the unit being placed, or is already occupied by another unit, the new unit will be placed in the nearest vacant hex.

* '''to_variable''': creates the unit into the given variable instead of placing it on the map.

* '''id''': a unique identifier for the unit. This is (usually) not displayed to the player, but is to be used only for identifying and filtering for units. If not specified or when a unit is normally recruited, a random one will be generated for the unit to ensure that each unit has a unique ''id'' attribute. In older versions, the '''description''' attribute specified a unique ID. (The one instance when an id is displayed to the player is when the leader's id is used as the default for a [[SideWML|side]]'s '''current_player''' attribute.)

* '''name''': the user-visible name of the unit. Note that the player may use the "rename unit" action to change this.

* '''generate_name''': (default=yes) will generate a new name if there isn't one specifed for the unit, as if the unit were a freshly-recruited one

* '''unrenamable''': if 'yes', the user-visible name of the unit cannot be changed by the player (which is only possible when the unit is on the player's side anyway).

* '''traits_description''': the description of the unit's traits which is displayed. However if it is not specified explicitly, the unit's actual traits' names will be used instead, so it is normally not necessary to set this.

* '''random_traits''': "no" will prevent random trait generation for units. You should only need to set this for placed nonleaders in multiplayer games or if you want to give a unit less traits than it would normally get for its unit type. When generating traits for a unit, first traits the unit has already been given are excluded. Then "musthave" traits (undead, mechanical) for the unit type are given. Then for leaders ('''canrecruit=yes''') traits that are not available to "any" (currently that's all of them to avoid a multiplayer OOS issue, but later will be restricted based on multiplayer play balance issues) are removed from consideration. Then traits are added randomly until the maximum allowed for the unit type is reached or there are no more available traits. Random traits can now be used in MP games but only when spawned in an event, so not for leaders and other units in the [side] definition.

* '''random_gender''': "yes" will cause the gender of the unit with male and female variations to be male 50% of the time, female 50% of the time. If the unit has only one gender variant it will always be given the correct one.

* '''canrecruit''': a special key for leaders.
** '''no''': default. Unit cannot recruit.
** '''yes''': unit can recruit.
: Normally when a team controls no units with '''canrecruit=yes''', that team loses. However, even if your team has lost you continue to play with whatever units you still have until the scenario is over. Usually scenarios end when only one team is left with a leader that can recruit, but special victory conditions can be set up in campaigns. Normally you want to set the leader of a side with '''canrecruit=yes'''. If you don't want the leader to recruit, it is usually better to just not give him any unit types to recruit, than to make a special victory condition. Units with '''canrecruit=yes''' are exempt from upkeep costs. So that leaders do not need to be given the ''loyal'' trait.
: More than one unit with '''canrecruit=yes''' for the same side (see [[SideWML]]) are allowed in single player, if the side is human-controlled.

* '''extra_recruit''': a list of unit types which this unit can recruit in addition to the ones given by its [side]recruit=, only working for units with '''canrecruit=yes'''.

* '''variation''': the variation of itself the unit should be created as.

* '''upkeep''': the amount of upkeep the unit costs.
** '''loyal''': no upkeep cost. Can be changed by the effect 'loyal' (see [[EffectWML]])
** '''free''': synonymous with "loyal".
** '''full''': unit costs ''level'' upkeep (see [[UnitTypeWML]]).
** An integer can be used to set the upkeep cost to that number.
** The default is "full".
** Leaders (units with '''canrecruit=yes''') never pay upkeep no matter what upkeep is set to.
** Normally you don't want to muck with this value. If you want to give a side units without upkeep costs, give those units the 'loyal' trait.

* '''overlays''': a list of images that are overlayed on the unit.

* '''goto_x''':, '''goto_y''': UI settings that control courses. Default is 0,0 i.e. the unit is not on a course.

* '''hitpoints''': the HP of the unit. Default is the max HP for ''type''.

* '''experience''': the XP of the unit. Default is 0.

* '''moves''': number of movement points the unit has left. Default is the movement for its unit type.

* '''resting''': whether the unit has not moved yet this turn. Used to decide whether to give a unit rest healing.

* '''role''': used in standard unit filter ([[FilterWML]]). Can be set using [role] (see [[InternalActionsWML]]).

* '''ai_special''': causes the unit to act differently (see [status] guardian).
** {{DevFeature1.11}} "ai_special" removed, use [status] guardian instead.

* '''facing''': which way the unit is facing (this only affects how the unit is displayed).
** Possible values are '''se''', '''s''', '''sw''', '''nw''', '''n''', '''ne'''. Using '''sw''' is preferred for a "reversed" facing (looking to the left) and '''se''' for a normal (looking to the right) facing.

* '''profile''': sets a portrait image for this unit. If the unit type already has a portrait set, this is used instead for this unit. When the unit advances, if the value of profile is different from the unit-type portrait, that value is preserved. If the profile field is empty or the same as the unit-type portrait, the level-advance changes the unit portrait to the default for the new level and type. See [[UnitTypeWML]] for the rules used for locating files.
** "unit_image" if given instead of a filename, uses the unit's base image as the portrait (in the same manner that unit types without portraits do by default).

* '''small_profile''': sets a small portrait image for this unit. See the '''profile''' attribute above for advancement and special values. As with [[UnitTypeWML]], the location heuristic of the '''profile''' attribute is disabled when the '''small_profile''' attribute is provided.

* '''animate''': if ''yes'', fades the unit in like when it's recruited/recalled.

* '''[status]''' the status of the unit. This affects different features of the unit, for example whether the unit loses health each turn. Default for all keys is 'no', but this can be changed by the scenario or by special abilities (see [[AbilitiesWML]]). The Status Table displays the status of each unit using the three images '''misc/poisoned.png''', '''misc/slowed.png''' and '''misc/petrified.png'''; other keys do not appear in the Status Table.
** '''poisoned''': if 'yes', the unit loses 8 HP each turn. See also ''heals'', ''cures'', [[AbilitiesWML]].
** '''slowed''': if 'yes', the unit has 50% of its normal movement and does half damage. When the controller of the unit's turn is over, ''slowed'' is set to 'off'
** '''petrified''': if 'yes', the unit cannot move, attack, or be attacked.
** '''uncovered''': if 'yes', the unit has performed an action (e.g. attacking) that causes it to no longer be hidden until the next turn.
** '''guardian''': if 'yes', the unit will not move, except to attack something in the turn it moves (so, it only can move if an enemy unit gets within range of it).
** '''unhealable''': if set to 'yes', the unit cannot be healed.
** One can add other keys to [status], but they must have boolean values. For example, a scenario can set unit.status.''my_custom_key'' to 'yes' or 'no'.

* '''[variables]''' a set of variables that will be stored when this unit is stored (See [store_unit], [[InternalActionsWML]]). The attribute '''variable'''='''value''' means that when the unit is stored in the array ''unit'', the variable '''unit'''.variables.''variable'' will have the value ''value'' (See [[VariablesWML]]).

* '''[modifications]''' changes that have been made to the unit.
** '''[trait]''' a trait the unit has. Same format as [trait], [[UnitsWML]].
** '''[object]''' an object the unit has. Same format as [object], [[DirectActionsWML]].

* '''[filter_recall]''' A leader can only recall those units which pass the SUF.
**'''[[StandardUnitFilter]]''' tags and keys

* '''unit_description''': overrides the unit type description for this unit. You will probably want to set up a ''post_advance'' [[EventWML|event]] to override the default description after promotions. Or better, use an object with a profile [[EffectWML|effect(s)]] to filter on unit type and change the unit description and/or portrait.

* '''[event]''' The event is copied from this unit's wml description into the scenario. The event is carried along with the unit (it can advance etc) and inserted into every scenario where this unit is first created. A [unit][event] is required a non-empty id= attribute.

== See Also ==

* [[UnitTypeWML]]
* [[ReferenceWML]]

[[Category:WML Reference]]

SoC2012 Ayne Multiplayer Engine Refactoring

2012-04-03T15:30:01Z

Ayne:

{{SoC2012Student}}
[[Category:SoC Ideas Multiplayer Engine Refactoring 2012]]

=Description=
<h4>Anja Keicher - Improve wesnoth's engine to allow better transitions between scenarios</h4>
The idea is to refactor the code that links scenarios and adding comments to make future changes easier and add the possibilty to change settings between scenarios in new and improved ways, as well as interaction with GUI2 dialogues.

= Additional =
I would start by refactoring the current code and adding comments, to make it easier for myself and other developers to change it later.
Until the start of the project and while I'm refactoring I would play the game more thoroughly and talk to people to determine what exactly the “fun things” to be added to the functionality are.

=IRC=
Ayne
=SoC Application=
Submitted to google

=Questionnaire=

1) Basics

1.1) Write a small introduction to yourself.

1) Basics

1.1) Write a small introduction to yourself.

My name is Anja Keicher. I'm a 21 year old student from Germany currently studying in the UK. I spent the first two years of my Bachelor degree at Hochschule Osnabrueck in Germany studying European Media Computer Science, then went to Edinburgh Napier University in Scotland to finish the degree in Games Development.

1.2) State your preferred email address.

I will put it in the GSoC application.

1.3) If you have chosen a nick for IRC and Wesnoth forums, what is it?

Ayne

1.4) Why do you want to participate in summer of code?

It sounds like an excellent opportunity to do what I enjoy doing, work on a large community project, and collect a lot of valuable experience. It would also allow me to earn money to help fund my studies through working on something relevant to my studies.

1.5) What are you studying, subject, level and school?

That's a bit complicated. The short version is: Games Development as part of a Bachelor degree in Media Computer Science. I'm in the last semester of my Bachelor degree. The Games Development part is at Edinburgh Napier University in the UK, the Media Computer Science part at Hochschule Osnabrueck (University of Applied Sciences Osnabrueck) in Germany.

1.6) What country are you from, at what time are you most likely to be able to join IRC?

I currently live in the UK and would most likely be on IRC between 11am and 12am GMT.

1.7) Do you have other commitments for the summer period ? Do you plan to take any vacations ? If yes, when.

I plan to take a vacation from the 3rd to 7th July. Other than that there will be one weekend in June and a few separate days in August where I will be unavailable (dates to be confirmed).

2) Experience

2.1) What programs/software have you worked on before?

University projects covering a wide range of subjects, including games using ActionScript3, XNA, Groovy and for Android devices, stock and database managing software, and websites.

2.2) Have you developed software in a team environment before? (As opposed to hacking on something on your own)

The practical side of my studies in Germany was almost exclusively in teams. The teams I have worked in so far were generally 2 to 5 people.

2.3) Have you participated to the Google Summer of Code before? As a mentor or a student? In what project? Were you successful? If not, why?

This is my first time participating in GsoC.

2.4) Are you already involved with any open source development projects? If yes, please describe the project and the scope of your involvement.

This is the first time I'm involved in an open source project.

2.5) Gaming experience - Are you a gamer?

Definitely. Gaming is what got me interested in developing software rather than just using it in the first place.

2.5.1) What type of gamer are you?

Generally casual, though when I find a game I like I'll try to spend any time I can spare playing it. I'm a quality player rather than quantity, a game has to catch my attention, but if I like it I will play it thoroughly and several times to explore different aspects of the game.

2.5.2) What type of games?

Mostly single-player RPGs such as the Elder Scrolls series, Fallout, Dragon Age, Mass Effect etc; though I do enjoy puzzle games like Portal and strategy games like Age of Empires (or Wesnoth) as well.

2.5.3) What type of opponents do you prefer?

AI opponents. It allows me to play the way I want, and I actually stand a chance ;)

2.5.4) Are you more interested in story or gameplay?

I'm very story driven, but if I just wanted the story I'd read a book or watch a movie. The gameplay definitely is an important aspect as well, and has to be right, otherwise I can't enjoy the story. Not all games are the same though, with some the story is more important and with others the story is just an excuse the enjoy the gameplay.

2.5.5) Have you played Wesnoth? If so, tell us roughly for how long and whether you lean towards single player or multiplayer.

I've started playing Wesnoth when I first saw it on the list of GsoC projects and have been playing it a bit every day since to get a feeling for it. I haven't really tried multiplayer yet, but usually I prefer playing single-player or multiplayer with the human players rather than against them.

2.6) If you have contributed any patches to Wesnoth, please list them below. You can also list patches that have been submitted but not committed yet and patches that have not been specifically written for GSoC. If you have gained commit access to our SVN (during the evaluation period or earlier) please state so.

https://gna.org/patch/?3235

3) Communication skills

3.1) Though most of our developers are not native English speakers, English is the project's working language. Describe your fluency level in written English.

I spent some time living in New Zealand and I currently live and study in Scotland. I haven't had problems communicating with anyone in many years. It's not perfect, but speaking or writing in English is definitely not a problem.

3.2) What spoken languages are you fluent in?

English, German

3.3) Are you good at interacting with other players? Our developer community is friendly, but the player community can be a bit rough.

I haven't interacted with the Wesnoth player community yet, but I generally don't have problems getting along with people, or staying calm and polite during conflicts.

3.4) Do you give constructive advice?

I try to give either constructive advice or none at all. If I can help someone or give them advice then I'm happy to do so.

3.5) Do you receive advice well?

As long as it's constructive I'm always grateful for pointers on how to improve my work.

3.6) Are you good at sorting useful criticisms from useless ones?

Generally, yes.

3.7) How autonomous are you when developing ? Would you rather discuss intensively changes and not start coding until you know what you want to do or would you rather code a proof of concept to "see how it turn out", taking the risk of having it thrown away if it doesn't match what the project want

I'm perfectly capable of making decisions myself, but if it's a major change I prefer to discuss it with other people first, especially if I'm new to a project. In my experience that's more efficient in the long run.

4) Project

4.1) Did you select a project from our list? If that is the case, what project did you select? What do you want to especially concentrate on?

I chose the project “Improve wesnoth's engine to allow better transitions between scenarios”. My first priority would be to clean up the code and add comments while I play the game some more to get a better idea of what could and what should be added to the transitions.

4.2) If you have invented your own project, please describe the project and the scope.

-

4.3) Why did you choose this project?

It looks like a nice mix of solid software engineering and games development that represents my studies and experience so far quite well. I think it would be a good introduction into the world of big community projects and open source development for me.

4.4) Include an estimated timeline for your work on the project. Don't forget to mention special things like "I booked holidays between A and B" and "I got an exam at ABC and won't be doing much then".

Now until start of coding:
Familiarizing myself with the game, the code and the community as much as I can while focusing my courseworks and exams. If I get accepted, start talking to people to get an idea of what needs doing and what might be a nice addition.
Start of coding until early June:
Refactor the existing code.
Early June until end of mid August
Continue refactoring if I haven't finished yet. Start implementing the “should be added” list. After that start on the “could be added” list
Late July until mid August
Write documentation

Apart from one weekend in June, the 5 days in early July, and a few days in August (never more than two at a time) I should be available to work weekdays and weekends as I will finish uni in early May.

4.5) Include as much technical detail about your implementation as you can

I'm not familiar enough with the Wesnoth code yet to give technical detail.

4.6) What do you expect to gain from this project?

More programming experience, especially with large projects.

4.7) What would make you stay in the Wesnoth community after the conclusion of SOC?

A friendly developing community and the feeling that I can continue to contribute to the project.

5) Practical considerations

5.1) Are you familiar with any of the following tools or languages?

Subversion (used for all commits)
I have used Subclipse (Subversion plugin for Eclipse)

C++ (language used for all the normal source code)
We mostly used C and C++ during my first 3 semesters at university. I'm a bit rusty, but it shouldn't take me long to remember all the things I learned.

STL, Boost, Sdl (C++ libraries used by Wesnoth)
None

Python (optional, mainly used for tools)
None

build environments (eg cmake/scons)
Used cmake once, have written a few make files by hand

WML (the wesnoth specific scenario language)
None

Lua (used in combination with WML to create scenarios)
None

5.2) Which tools do you normally use for development? Why do you use them?

My preferred IDE is Eclipse, mostly because I had to use it for most of my modules at university and have gotten used to its features, keyboard shortcuts and GUI.

5.3) What programming languages are you fluent in?

Java, C++, C, C#
I haven't used C and C++ much over the last year, but I think it wouldn't take me long to get the hang of it again.

5.4) Would you mind talking with your mentor on telephone / internet phone? We would like to have a backup way for communications for the case that somehow emails and IRC do fail. If you are willing to do so, please do list a phone number (including international code) so that we are able to contact you. You should probably *only* add this number in the application for you submit to google since the info in the wiki is available in public. We will *not* make any use of your number unless some case of "there is no way to contact you" does arise!

I don't mind talking on the phone. I will add my phone number to the google application, and I can also provide my Skype details if necessary.

SoC2012 Ayne Multiplayer Engine Refactoring

2012-03-24T23:49:12Z

Ayne:

{{SoC2012Student}}
[[Category:SoC Ideas Multiplayer Engine Refactoring 2012]]

=Description=
<h4>Anja Keicher - Improve wesnoth's engine to allow better transitions between scenarios</h4>
The idea is to refactor the code that links scenarios and adding comments to make future changes easier and add the possibilty to change settings between scenarios in new and improved ways, as well as interaction with GUI2 dialogues.

= Additional =
I would start by refactoring the current code and adding comments, to make it easier for myself and other developers to change it later.
Until the start of the project and while I'm refactoring I would play the game more thoroughly and talk to people to determine what exactly the “fun things” to be added to the functionality are.

=IRC=
Ayne

=Questionnaire=

1) Basics

1.1) Write a small introduction to yourself.

1) Basics

1.1) Write a small introduction to yourself.

My name is Anja Keicher. I'm a 21 year old student from Germany currently studying in the UK. I spent the first two years of my Bachelor degree at Hochschule Osnabrueck in Germany studying European Media Computer Science, then went to Edinburgh Napier University in Scotland to finish the degree in Games Development.

1.2) State your preferred email address.

I will put it in the GSoC application.

1.3) If you have chosen a nick for IRC and Wesnoth forums, what is it?

Ayne

1.4) Why do you want to participate in summer of code?

It sounds like an excellent opportunity to do what I enjoy doing, work on a large community project, and collect a lot of valuable experience. It would also allow me to earn money to help fund my studies through working on something relevant to my studies.

1.5) What are you studying, subject, level and school?

That's a bit complicated. The short version is: Games Development as part of a Bachelor degree in Media Computer Science. I'm in the last semester of my Bachelor degree. The Games Development part is at Edinburgh Napier University in the UK, the Media Computer Science part at Hochschule Osnabrueck (University of Applied Sciences Osnabrueck) in Germany.

1.6) What country are you from, at what time are you most likely to be able to join IRC?

I currently live in the UK and would most likely be on IRC between 11am and 12am GMT.

1.7) Do you have other commitments for the summer period ? Do you plan to take any vacations ? If yes, when.

I plan to take a vacation from the 3rd to 7th July. Other than that there will be one weekend in June and a few separate days in August where I will be unavailable (dates to be confirmed).

2) Experience

2.1) What programs/software have you worked on before?

University projects covering a wide range of subjects, including games using ActionScript3, XNA, Groovy and for Android devices, stock and database managing software, and websites.

2.2) Have you developed software in a team environment before? (As opposed to hacking on something on your own)

The practical side of my studies in Germany was almost exclusively in teams. The teams I have worked in so far were generally 2 to 5 people.

2.3) Have you participated to the Google Summer of Code before? As a mentor or a student? In what project? Were you successful? If not, why?

This is my first time participating in GsoC.

2.4) Are you already involved with any open source development projects? If yes, please describe the project and the scope of your involvement.

This is the first time I'm involved in an open source project.

2.5) Gaming experience - Are you a gamer?

Definitely. Gaming is what got me interested in developing software rather than just using it in the first place.

2.5.1) What type of gamer are you?

Generally casual, though when I find a game I like I'll try to spend any time I can spare playing it. I'm a quality player rather than quantity, a game has to catch my attention, but if I like it I will play it thoroughly and several times to explore different aspects of the game.

2.5.2) What type of games?

Mostly single-player RPGs such as the Elder Scrolls series, Fallout, Dragon Age, Mass Effect etc; though I do enjoy puzzle games like Portal and strategy games like Age of Empires (or Wesnoth) as well.

2.5.3) What type of opponents do you prefer?

AI opponents. It allows me to play the way I want, and I actually stand a chance ;)

2.5.4) Are you more interested in story or gameplay?

I'm very story driven, but if I just wanted the story I'd read a book or watch a movie. The gameplay definitely is an important aspect as well, and has to be right, otherwise I can't enjoy the story. Not all games are the same though, with some the story is more important and with others the story is just an excuse the enjoy the gameplay.

2.5.5) Have you played Wesnoth? If so, tell us roughly for how long and whether you lean towards single player or multiplayer.

I've started playing Wesnoth when I first saw it on the list of GsoC projects and have been playing it a bit every day since to get a feeling for it. I haven't really tried multiplayer yet, but usually I prefer playing single-player or multiplayer with the human players rather than against them.

2.6) If you have contributed any patches to Wesnoth, please list them below. You can also list patches that have been submitted but not committed yet and patches that have not been specifically written for GSoC. If you have gained commit access to our SVN (during the evaluation period or earlier) please state so.

None so far.

3) Communication skills

3.1) Though most of our developers are not native English speakers, English is the project's working language. Describe your fluency level in written English.

I spent some time living in New Zealand and I currently live and study in Scotland. I haven't had problems communicating with anyone in many years. It's not perfect, but speaking or writing in English is definitely not a problem.

3.2) What spoken languages are you fluent in?

English, German

3.3) Are you good at interacting with other players? Our developer community is friendly, but the player community can be a bit rough.

I haven't interacted with the Wesnoth player community yet, but I generally don't have problems getting along with people, or staying calm and polite during conflicts.

3.4) Do you give constructive advice?

I try to give either constructive advice or none at all. If I can help someone or give them advice then I'm happy to do so.

3.5) Do you receive advice well?

As long as it's constructive I'm always grateful for pointers on how to improve my work.

3.6) Are you good at sorting useful criticisms from useless ones?

Generally, yes.

3.7) How autonomous are you when developing ? Would you rather discuss intensively changes and not start coding until you know what you want to do or would you rather code a proof of concept to "see how it turn out", taking the risk of having it thrown away if it doesn't match what the project want

I'm perfectly capable of making decisions myself, but if it's a major change I prefer to discuss it with other people first, especially if I'm new to a project. In my experience that's more efficient in the long run.

4) Project

4.1) Did you select a project from our list? If that is the case, what project did you select? What do you want to especially concentrate on?

I chose the project “Improve wesnoth's engine to allow better transitions between scenarios”. My first priority would be to clean up the code and add comments while I play the game some more to get a better idea of what could and what should be added to the transitions.

4.2) If you have invented your own project, please describe the project and the scope.

-

4.3) Why did you choose this project?

It looks like a nice mix of solid software engineering and games development that represents my studies and experience so far quite well. I think it would be a good introduction into the world of big community projects and open source development for me.

4.4) Include an estimated timeline for your work on the project. Don't forget to mention special things like "I booked holidays between A and B" and "I got an exam at ABC and won't be doing much then".

Now until start of coding:
Familiarizing myself with the game, the code and the community as much as I can while focusing my courseworks and exams. If I get accepted, start talking to people to get an idea of what needs doing and what might be a nice addition.
Start of coding until early June:
Refactor the existing code.
Early June until end of mid August
Continue refactoring if I haven't finished yet. Start implementing the “should be added” list. After that start on the “could be added” list
Late July until mid August
Write documentation

Apart from one weekend in June, the 5 days in early July, and a few days in August (never more than two at a time) I should be available to work weekdays and weekends as I will finish uni in early May.

4.5) Include as much technical detail about your implementation as you can

I'm not familiar enough with the Wesnoth code yet to give technical detail.

4.6) What do you expect to gain from this project?

More programming experience, especially with large projects.

4.7) What would make you stay in the Wesnoth community after the conclusion of SOC?

A friendly developing community and the feeling that I can continue to contribute to the project.

5) Practical considerations

5.1) Are you familiar with any of the following tools or languages?

Subversion (used for all commits)
I have used Subclipse (Subversion plugin for Eclipse)

C++ (language used for all the normal source code)
We mostly used C and C++ during my first 3 semesters at university. I'm a bit rusty, but it shouldn't take me long to remember all the things I learned.

STL, Boost, Sdl (C++ libraries used by Wesnoth)
None

Python (optional, mainly used for tools)
None

build environments (eg cmake/scons)
Used cmake once, have written a few make files by hand

WML (the wesnoth specific scenario language)
None

Lua (used in combination with WML to create scenarios)
None

5.2) Which tools do you normally use for development? Why do you use them?

My preferred IDE is Eclipse, mostly because I had to use it for most of my modules at university and have gotten used to its features, keyboard shortcuts and GUI.

5.3) What programming languages are you fluent in?

Java, C++, C, C#
I haven't used C and C++ much over the last year, but I think it wouldn't take me long to get the hang of it again.

5.4) Would you mind talking with your mentor on telephone / internet phone? We would like to have a backup way for communications for the case that somehow emails and IRC do fail. If you are willing to do so, please do list a phone number (including international code) so that we are able to contact you. You should probably *only* add this number in the application for you submit to google since the info in the wiki is available in public. We will *not* make any use of your number unless some case of "there is no way to contact you" does arise!

I don't mind talking on the phone. I will add my phone number to the google application, and I can also provide my Skype details if necessary.

SoC2012 Ayne Multiplayer Engine Refactoring

2012-03-24T23:46:25Z

Ayne: Created page with '{{SoC2012Student}} Category:SoC Ideas Multiplayer Engine Refactoring 2012 =Description= <h4>Anja Keicher - Improve wesnoth's engine to allow better transitions between scena…'

{{SoC2012Student}}
[[Category:SoC Ideas Multiplayer Engine Refactoring 2012]]

=Description=
<h4>Anja Keicher - Improve wesnoth's engine to allow better transitions between scenarios</h4>
The idea is to refactor the code that links scenarios and adding comments to make future changes easier and add the possibilty to change settings between scenarios in new and improved ways, as well as interaction with GUI2 dialogues.

= Additional =
I would start by refactoring the current code and adding comments, to make it easier for myself and other developers to change it later.
Until the start of the project and while I'm refactoring I would play the game more thoroughly and talk to people to determine what exactly the “fun things” to be added to the functionality are.

=IRC=
Ayne

=Questionnaire=

1) Basics

1.1) Write a small introduction to yourself.

1) Basics

1.1) Write a small introduction to yourself.
My name is Anja Keicher. I'm a 21 year old student from Germany currently studying in the UK. I spent the first two years of my Bachelor degree at Hochschule Osnabrueck in Germany studying European Media Computer Science, then went to Edinburgh Napier University in Scotland to finish the degree in Games Development.

1.2) State your preferred email address.
I will put it in the GSoC application.

1.3) If you have chosen a nick for IRC and Wesnoth forums, what is it?
Ayne

1.4) Why do you want to participate in summer of code?
It sounds like an excellent opportunity to do what I enjoy doing, work on a large community project, and collect a lot of valuable experience. It would also allow me to earn money to help fund my studies through working on something relevant to my studies.

1.5) What are you studying, subject, level and school?
That's a bit complicated. The short version is: Games Development as part of a Bachelor degree in Media Computer Science. I'm in the last semester of my Bachelor degree. The Games Development part is at Edinburgh Napier University in the UK, the Media Computer Science part at Hochschule Osnabrueck (University of Applied Sciences Osnabrueck) in Germany.

1.6) What country are you from, at what time are you most likely to be able to join IRC?
I currently live in the UK and would most likely be on IRC between 11am and 12am GMT.

1.7) Do you have other commitments for the summer period ? Do you plan to take any vacations ? If yes, when.
I plan to take a vacation from the 3rd to 7th July. Other than that there will be one weekend in June and a few separate days in August where I will be unavailable (dates to be confirmed).

2) Experience

2.1) What programs/software have you worked on before?
University projects covering a wide range of subjects, including games using ActionScript3, XNA, Groovy and for Android devices, stock and database managing software, and websites.

2.2) Have you developed software in a team environment before? (As opposed to hacking on something on your own)
The practical side of my studies in Germany was almost exclusively in teams. The teams I have worked in so far were generally 2 to 5 people.

2.3) Have you participated to the Google Summer of Code before? As a mentor or a student? In what project? Were you successful? If not, why?
This is my first time participating in GsoC.

2.4) Are you already involved with any open source development projects? If yes, please describe the project and the scope of your involvement.
This is the first time I'm involved in an open source project.

2.5) Gaming experience - Are you a gamer?
Definitely. Gaming is what got me interested in developing software rather than just using it in the first place.

2.5.1) What type of gamer are you?
Generally casual, though when I find a game I like I'll try to spend any time I can spare playing it. I'm a quality player rather than quantity, a game has to catch my attention, but if I like it I will play it thoroughly and several times to explore different aspects of the game.

2.5.2) What type of games?
Mostly single-player RPGs such as the Elder Scrolls series, Fallout, Dragon Age, Mass Effect etc; though I do enjoy puzzle games like Portal and strategy games like Age of Empires (or Wesnoth) as well.

2.5.3) What type of opponents do you prefer?
AI opponents. It allows me to play the way I want, and I actually stand a chance ;)

2.5.4) Are you more interested in story or gameplay?
I'm very story driven, but if I just wanted the story I'd read a book or watch a movie. The gameplay definitely is an important aspect as well, and has to be right, otherwise I can't enjoy the story. Not all games are the same though, with some the story is more important and with others the story is just an excuse the enjoy the gameplay.

2.5.5) Have you played Wesnoth? If so, tell us roughly for how long and whether you lean towards single player or multiplayer.
I've started playing Wesnoth when I first saw it on the list of GsoC projects and have been playing it a bit every day since to get a feeling for it. I haven't really tried multiplayer yet, but usually I prefer playing single-player or multiplayer with the human players rather than against them.

2.6) If you have contributed any patches to Wesnoth, please list them below. You can also list patches that have been submitted but not committed yet and patches that have not been specifically written for GSoC. If you have gained commit access to our SVN (during the evaluation period or earlier) please state so.
None so far.

3) Communication skills

3.1) Though most of our developers are not native English speakers, English is the project's working language. Describe your fluency level in written English.
I spent some time living in New Zealand and I currently live and study in Scotland. I haven't had problems communicating with anyone in many years. It's not perfect, but speaking or writing in English is definitely not a problem.

3.2) What spoken languages are you fluent in?
English, German

3.3) Are you good at interacting with other players? Our developer community is friendly, but the player community can be a bit rough.
I haven't interacted with the Wesnoth player community yet, but I generally don't have problems getting along with people, or staying calm and polite during conflicts.

3.4) Do you give constructive advice?
I try to give either constructive advice or none at all. If I can help someone or give them advice then I'm happy to do so.

3.5) Do you receive advice well?
As long as it's constructive I'm always grateful for pointers on how to improve my work.

3.6) Are you good at sorting useful criticisms from useless ones?
Generally, yes.

3.7) How autonomous are you when developing ? Would you rather discuss intensively changes and not start coding until you know what you want to do or would you rather code a proof of concept to "see how it turn out", taking the risk of having it thrown away if it doesn't match what the project want
I'm perfectly capable of making decisions myself, but if it's a major change I prefer to discuss it with other people first, especially if I'm new to a project. In my experience that's more efficient in the long run.

4) Project

4.1) Did you select a project from our list? If that is the case, what project did you select? What do you want to especially concentrate on?
I chose the project “Improve wesnoth's engine to allow better transitions between scenarios”. My first priority would be to clean up the code and add comments while I play the game some more to get a better idea of what could and what should be added to the transitions.

4.2) If you have invented your own project, please describe the project and the scope.
-

4.3) Why did you choose this project?
It looks like a nice mix of solid software engineering and games development that represents my studies and experience so far quite well. I think it would be a good introduction into the world of big community projects and open source development for me.

4.4) Include an estimated timeline for your work on the project. Don't forget to mention special things like "I booked holidays between A and B" and "I got an exam at ABC and won't be doing much then".
Now until start of coding:
Familiarizing myself with the game, the code and the community as much as I can while focusing my courseworks and exams. If I get accepted, start talking to people to get an idea of what needs doing and what might be a nice addition.
Start of coding until early June:
Refactor the existing code.
Early June until end of mid August
Continue refactoring if I haven't finished yet. Start implementing the “should be added” list. After that start on the “could be added” list
Late July until mid August
Write documentation

Apart from one weekend in June, the 5 days in early July, and a few days in August (never more than two at a time) I should be available to work weekdays and weekends as I will finish uni in early May.

4.5) Include as much technical detail about your implementation as you can
I'm not familiar enough with the Wesnoth code yet to give technical detail.

4.6) What do you expect to gain from this project?
More programming experience, especially with large projects.

4.7) What would make you stay in the Wesnoth community after the conclusion of SOC?
A friendly developing community and the feeling that I can continue to contribute to the project.

5) Practical considerations

5.1) Are you familiar with any of the following tools or languages?
Subversion (used for all commits)
I have used Subclipse (Subversion plugin for Eclipse)

C++ (language used for all the normal source code)
We mostly used C and C++ during my first 3 semesters at university. I'm a bit rusty, but it shouldn't take me long to remember all the things I learned.

STL, Boost, Sdl (C++ libraries used by Wesnoth)
None

Python (optional, mainly used for tools)
None

build environments (eg cmake/scons)
Used cmake once, have written a few make files by hand

WML (the wesnoth specific scenario language)
None

Lua (used in combination with WML to create scenarios)
None

5.2) Which tools do you normally use for development? Why do you use them?
My preferred IDE is Eclipse, mostly because I had to use it for most of my modules at university and have gotten used to its features, keyboard shortcuts and GUI.

5.3) What programming languages are you fluent in?
Java, C++, C, C#
I haven't used C and C++ much over the last year, but I think it wouldn't take me long to get the hang of it again.

5.4) Would you mind talking with your mentor on telephone / internet phone? We would like to have a backup way for communications for the case that somehow emails and IRC do fail. If you are willing to do so, please do list a phone number (including international code) so that we are able to contact you. You should probably *only* add this number in the application for you submit to google since the info in the wiki is available in public. We will *not* make any use of your number unless some case of "there is no way to contact you" does arise!

I don't mind talking on the phone. I will add my phone number to the google application, and I can also provide my Skype details if necessary.