This is a page containing information on configuring the AI using Lua. In addition to the technical information on this page, a tutorial-style guide is also available at [[Lua AI Howto]].

NB: previous contents of the page moved to http://wiki.wesnoth.org/LuaAI(old)

== Aspects ==
Patch r49721 enabled users to write aspects using Lua. This simplifies the definition of aspects that are meant to change depending on the game state. A good example could be aggression, which changes depending on the time of the day(since ToD affects the actual battle performance of your forces). 
Static aggression:
[aspect]
id="aggression"
engine="lua"
value="0.3"
[/aspect]
Dynamic aggression:
[aspect]
id=aggression
engine=lua

code=<<
wesnoth.fire("store_time_of_day")
local value = 0
tod = tostring(wesnoth.get_variable('time_of_day').name)
if (tod == 'Morning') then
value = 0.2
else
value = 1
end

wesnoth.fire("clear_variable", {name = "time_of_day"})
return value
>>
[/aspect]

Note: the way of getting the ToD is hacky here, but I will create a more elegant method soon(Nephro). 
Also note the difference between 'code' and 'value' attributes, this is important. 
At the moment, it is possible to create the following aspects using Lua(the list will be constantly updated):
aggression // double
attack_depth // int
avoid // exposed as map_location[], where map_location is a table of form {x, y}
caution // double
grouping // string
leader_aggression // double
leader_goal // exposed as a config
leader_value // double
number_of_possible_recruits_to_force_recruit // double
passive_leader // bool
passive_leader_shares_keep // bool
recruitment_ignore_bad_combat // bool
recruitment_ignore_bad_movement // bool
recruitment_pattern // string[]
scout_village_targeting // double
simple_targeting // bool
support_villages // bool
village_value // double
villages_per_scout // int

Note: simple numeric, bool and string aspect creation can be enabled just by adding a specific factory to registry.cpp, this will also soon be done.

To get the value of a specific aspect in Lua we have to use the
ai.get_<aspect_name>()
function. E.g.
local aggression = ai.get_aggression()

== Preload event ==

It is a good idea to have such a preload event in your scenario if you are intending to use Lua for AI programming or customizing. The code of this event will most probably be moved out to a macro(except for the line that requires patrol.lua, since it is not necessary).

[event]
name=preload
first_time_only=no
[lua]
code = <<
H = wesnoth.require "lua/helper.lua"
W = H.set_wml_action_metatable {}
_ = wesnoth.textdomain "my-campaign"
ai = {}
ca_counter = 0

H.set_wml_var_metatable(_G)

wesnoth.require("ai/lua/patrol.lua")

>>
[/lua]
[/event]

The code attribute can be further expanded by any Lua code needed. For example, we can set up some global variables there or include additional code libraries("wesnoth.require("ai/lua/patrol.lua")" - includes code that handles patrolling of units).

== Engine code ==

In the engine tag you should define functions that will handle evaluation and execution of your custom candidate actions and stages. You can also run some code that is intended to be run once in the beginning. 
The definition of the [engine] tag should be place inside the [ai] tag.

[engine]
name="lua"
code= <<
-- your engine code here
>>
[/engine]

== Stages ==
Once the engine has been set up, we can start adding stages to the configuration of our AI. 
To add a stage we just use the [stage] tag.
[stage]
engine=lua
code=<<
-- Code for stage execution here
-- It is better to call predefined functions for the [engine] code,
-- than to define the functions here, to keep the structure of the stages clear
>>
[/stage]

== Candidate actions ==
This is an example from the current version of the lua_ai arena. The stage with an id "ca_loop" is the RCA AI loop stage, as we can see from its name. Currently it has two candidate actions, both Lua backed.

[stage]
name=testing_ai_default::candidate_action_evaluation_loop
id=ca_loop
[candidate_action]
engine=lua
name=first
id=firstca
evaluation="return (...):candidate_action_evaluation_hello()"
execution="local ai, cfg = ...; ai:candidate_action_execution_hello(cfg)"
[/candidate_action]
[candidate_action]
engine=lua
name=second
evaluation="return (...):candidate_action_evaluation_hello2()"
execution="(...):candidate_action_execution_hello2()"
[/candidate_action]
[/stage]
Basically, we need to have an engine attribute, an evaluation and execution functions. The syntax (...):foo() means "call eng.foo(eng) where eng is whatever the engine code returns". We can also add, remove, modify candidate actions on the fly, using wesnoth.wml_actions.modify_ai() functionality. Behavior(sticky) candidate actions use this approach.

== Behavior(sticky) candidate actions ==
Sometimes we need a specific unit to do a specific action in our scenario, e.g. we want a scout unit to patrol between 3 places on the map, to provide us with visibility needed. In this case we can create a sticky candidate action that will tie itself to the unit, and remove itself when the unit has died. The syntax for defining a sticky candidate action is the following:
[event]
name=side 2 turn 1
first_time_only=yes
[add_ai_behavior]
side=2
[filter]
name="Rark"
[/filter]
sticky=yes
loop_id=ca_loop
evaluation="return patrol_eval_rark()"
execution="patrol_rark()"
[/add_ai_behavior]
[/event]
Here the behavior CA is added to the configuration of the AI when the event triggers. Obviously this will happen when side 2 gets its first turn, but the event can be whatever needed. The definition is very similar to a simple candidate action, but here we also filter out a unit and state that we want the behavior to be sticky. If we don't, the action will not try to remove itself, when the unit gets killed, and this could cause errors. 
Such CA`s can also be added from inside other CA or stage code using wesnoth.wml_actions.add_ai_behavior(cfg) function.

== Behavior function library ==
Behaviors are defined using generators. A behavior generator receives arguments(unit info, configuration, etc) and returns a pair of functions: evaluator and executor. These functions are to be passed to the add_ai_behavior tag, or directly to the function.
=== Patrolling ===
The only behavior defined at the moment is the patrol behavior. After calling patrol_gen(name, locations), we receive a pair of functions to use for creation of candidate actions 
Inclusion of the patrolling code:
wesnoth.require("ai/lua/patrol.lua")
Usage:
local patrol_rark = patrol_gen("Rark", {{x=14, y=7}, {x=15, y=7}, {x=15, y=8}, {x=14, y=8}})
-- patrol_rark.exec -- execution function
-- patrol_rark.eval -- evaluation function
As you can see, the first argument is the name of the unit, the second is a table of coordinates of arbitrary length.

==Goals and targets==

When deciding what move to do next, the AI uses targets(markers on the map, pointing to villages, units, locations, etc). Targets are produced by goal objects. There are multiple predefined goal objects of different types in the C++ implementation, but now it is possible to define goal objects in Lua.

[goal]
name=lua_goal
value=6
engine=lua
code = <<
local t = {
t[1] = {value=2.3, type=3, loc={x=5, y=6} }
t[2] = {value=2.4, type=4, loc={x=4, y=16} }
}
return t
>>
[/goal]

As you can see, the return value must be a table containing 0 or more targets. Each target must contain the three fields: "loc", "type", "value". This code will then be parsed by the Lua engine and the targets will be available to use to any engine desired. To get the targets inside Lua, a simple
local tg = ai.get_targets()
must be called. tg will contain a table of the same format, as one described in the goal definition code upper.

== Persistence ==

If you need to store some data between save/load routines, you probably need a place to store the data. For this purpose, a field named "data" is automatically added to the return value of your engine code. The save routine will find this field, convert it to a config and store its content in readable format. When the scenario gets loaded back, the engine code will inject the data back in the AI context. All other data will be lost. Note that all content of "data" needs to be in WML table format, otherwise it will not be saved.

== Debug access to the AI tree ==

wesnoth.debug_ai(side)
-- has been added. The function only works in debug mode and returns a table containing the component tree of the active AI for a side, the engine functions and the accessor to the ai.* table of the LuaAI Also allows the user to execute stages and evaluate/execute candidate actions(eval and exec can be run independently).

Structure of the table(example):

{
stage_hello = function: 0x6dc24c0,
get_ai = function: 0x6dc25d0,
data = {
},
do_moves = function: 0x6dc2590,
candidate_action_evaluation_hello = function: 0x6dc2560,
candidate_action_evaluation_hello2 = function: 0x6dc2640,
components = {
id = "",
stage = {
another_stage = {
name = "another_stage",
id = "",
exec = function: 0x17cd3bb,
engine = "lua",
stg_ptr = "userdata: 0x7c5a8d0"
},
testing_ai_default::candidate_action_evaluation_loop = {
name = "testing_ai_default::candidate_action_evaluation_loop",
candidate_action = {
external = {
name = "external",
id = "",
exec = function: 0x17cd2f3,
engine = "lua",
ca_ptr = "userdata: 0x6fb3600"
},
second = {
name = "second",
id = "",
exec = function: 0x17cd2f3,
engine = "lua",
ca_ptr = "userdata: 0x6fb2f50"
}
},
id = "ca_loop",
exec = function: 0x17cd3bb,
engine = "",
stg_ptr = "userdata: 0x6fb2728"
}
},
engine = "",
name = ""
},
candidate_action_execution_hello2 = function: 0x6dc2670,
candidate_action_execution_hello = function: 0x6dc2530
}

The fields described as " name = function: 0xXXXXXXXX" are functions and can be called to using the usual function call syntax of Lua.
wesnoth.debug_ai(2).get_ai() -- will return the AI table of the Lua AI context.

wesnoth.debug_ai(2).stage[another_stage].exec() -- will execute the stage.

wesnoth.debug_ai(2).get_ai().get_aggression() -- will the return the current value of the aggression aspect of the AI

Therefore, we have up-to-date access to the whole AI, including the data segment.

NB!: the back-end of this function will be refactored quite drastically and that may involve usage syntax changes. This shouldn't be a big problem, since this function is only used for debugging and won't work in non-debug mode. If something suddenly stops working for you, come back to this page and watch the updates.

2012-04-04T16:05:55Z

Nephro: /* The project */

{{SoC2012Student}}
[[Category:SoC_Ideas_AI_Lua_AI_Usage_2012]]

=Description=
<h4>Dmitry Kovalenko(Nephro) - Further Lua</h4>
Simplify LuaAI 
Right now, the LuaAI system is in a state, where it can be used for artificial intelligence system development for Battle for Wesnoth campaigns, but it's usage is quite complicated and requires effort to get the system off the ground and make it run. To simply to launch a campaign with an empty LuaAI(by empty, I mean, not doing anything) a UMC developer is required to write a couple dozens of lines of code(not even mentioning the bugs that he will encounter on the way). While it seems, that we could simply hide the boilerplate code in a template or behind a macro, the situation is a bit more sophisticated(Later I will describe that in more detail). Instead of running away from this problem, I will work towards an elegant solution, creating an effective back-end system, and a clean user development environment.
=The project=
<h4>Intro</h4>
As I already stated in the short description, the LuaAI system is not very easy to use, at this stage. We can say the same about the C++ part of the AI, if a person wants a new candidate action, for example, he will have to dig in the C++ code, understand, how it works, code in C++, compile, debug. That is the way of C++, but shouldn't be the way of LuaAI. 
LuaAI was designed to simplify AI development, to provide a way of trying out their ideas for non-programmers. If we design a usable and simple LuaAI environment, even the further development of the current mainline AI would be simplified. Stages and candidate actions could just be written and tried out in Lua, and if a developer is satisfied with its work, he can either leave the AI element in the Lua form and add it to the main RCA loop, or translate it to C++ and compile once. The translation must be trivial, considering that LuaAI was properly prepared. LuaAI should provide all the power that C++ has. 
<h4>Importance</h4>
I see the LuaAI as a very important part of future AI development for Wesnoth. It will help expand the current AI and teach it new tricks very easily. While improving the current AI in general will surely make it stronger, small LuaAI snippets will allow it to become more clever and use all kinds of trickery, where it's appropriate.

This is a small chat excerpt of a conversation I had earlier today(April 4th). It might provide more insight on my vision and ideas.
<e7th04sh> zookeeper: ok, another idea then. Is scenario designer able to force certain ratios or fixed numbers and kinds of unit to achieve certain goals? Simplest example - force always using at least 50% of blue force move toward red keep, leaving only at most 50% to attack green keep? More complex - player side takes part in a battle, where entire sections of friendlies and enemies have fixed behavior on general scope, but specific mo
<zookeeper> cut off at "but specific mov"
<e7th04sh> ...es are and attackes are determined by default ai.
<e7th04sh> Example of handle - set travel point for all red units in certain area1 to area2 at priority level medium - makes the ai favor moves that cause affected units to move toward area2
<Nephro> e7th04sh, if I understand you correctly, then yes, there is a way to do that
<e7th04sh> Nephro how does that work at the moment?
<zookeeper> e7th04sh, i'm not really an AI expert, but i don't think so. i think you can make the AI units execute certain moves if the specified conditions are true, but i don't think you can (easily) make it work like you described.
<e7th04sh> zookeeper, and that would be helpful for scenario designers wouldn't it?
<Nephro> well, you write a candidate action for that, and make it very high priority(higher than the standard movement candidate action). Since the task is not too common, you will probably want to write such a candidate action in Lua and add it to the rca_loop on the fly. You can also place the candidate action in the Lua library(not yet defined, but soon will be), therefore other people will be able to reuse it
<zookeeper> e7th04sh, but better ask crab or someone who really knows what they're talking about
<e7th04sh> i just bother you guys because crab is not here, and I try to use the little time i have before filing application best way possible
<zookeeper> e7th04sh, it'd depend on how exactly it'd work and if it'd be easy to use
<e7th04sh> well it would require to pass orders to ai code
<e7th04sh> so that would be only usable with compatible ai
<e7th04sh> ok, i have to go again. i'll try to describe it better when i'm back
<Nephro> as for the example with " force certain ratios or fixed numbers and kinds of unit to achieve certain goals"... You make a stage before the rca_loop that will analyze and split your units into groups, then the appropriate CA's do the job
<Nephro> very simple
<Nephro> LuaAI has an object for static data, so CA's can communicate
<Nephro> I don't think C++ can do that
<e7th04sh> Nephro but do you see a general reusable solution here, or rather you see that doing this on a case by case basis is easy?
<e7th04sh> I'm not sure how easy or hard is what you describe. I want to reach out to more people, so they can make better campaigns with simpler tools.
<zookeeper> the thing is that AI customization tends to get really difficult really fast
<Nephro> e7th04sh, once you do something, you store it in the library, so it's reusable. You can't generally define one way for the AI to be able to do different things
<Nephro> e7th04sh, what you are suggesting is the "idea concept"... You have to teach the AI the idea at least once, before it can reuse it infinitely
<Nephro> the framework for that is already functioning, it only needs polishing
<zookeeper> ...therefore, the #1 most useful thing would usually be to just make the AI play better ;) after the AI learns to play better, the scenario designer can affect its behaviour by giving it different units, for instance
<Nephro> e.g. I have implemented a patrolling concept for the units. Right now, you can make any unit you want, to patrol the map on certain waypoints.
<Nephro> I even think this function is used in one of the mainline campaigns
<Nephro> zookeeper, as I see this problem: the campaign games usually fully depend on customization, while single games(where the player just plays against an AI on a symmetric map with the same starting set), don't need any customization at all.
<Nephro> zookeeper, if we make the current AI play better, and maybe even play smart, I think some campaigns will become impossible to complete, then we would have to restrict the skills of the AI
<zookeeper> Nephro, well, the way i see it is that if we had an AI that could play really well, then we wouldn't need much more than to be able to give it _objectives_. the rest would be up to the units, gold etc that the scenario designer gives it. sure some customization like patrolling is nice, but generally i think most customization is a reaction to the AI playing poorly without them.
<Nephro> zookeeper, well, I agree with that. But imagine a scenario where we need to clear a map from all kinds of evil things. We start out with a small force, but the whole map is infested with monsters. A smart AI would instantly send everything to kill you and would succeed. The story concept requires the AI to behave in very certain ways
<Nephro> zookeeper, also, the human mind is capable of generating tricky stuff, like luring, for example. I see absolutely no way of making the AI so good, that it would decide to lure someone. But we can certainly teach it, that in certain situations, we can activate the custom lure concept, and try to pull it off
<zookeeper> Nephro, well, improving the AI wouldn't change such a clear-the-map scenario
<Nephro> zookeeper, no, I meant, a smart non-customized AI wouldn't stand and wait if you don't tell it to.
<zookeeper> Nephro, sure. customization for scenarios like that has and always will be needed
<Nephro> zookeeper, also, the AIs of strategic will always have a brick wall in front of it in the means of complexity
<Nephro> strategic games*
<Nephro> zookeeper, I also think, that both, improving the AI in general and improving the ability to customize should be run in parallel. The customizers can create a variety of scripts that can be used as weapons by the ai, and the general ai should know, when and how to use these weapons
<Nephro> I think that's the way to go
Generally, I think it's important to improve both sides: general AI and customization abilities. In combination, the AI will not only be able to play smart in general, but will have the ability to use tricks that humans invent, bringing the AI player closer to an actual human player, making the game more fun, more challenging and less predictable.
<h4>Known problems</h4>
* LuaAI lacks a lot of tools C++ has(e.g. the attacks and enemy_attacks vectors)
* Some heavyweight objects are currently being inefficiently handled by the LuaAI(e.g. the translation of move maps and any container type objects, that are getting passed to LuaAI)
* Users of LuaAI have discovered bugs in the current implementation(some of them already fixed by me, some fixes are planned)
* Boilerplate code in the scenarios(discussed lower in the "Boilerplate code" section)
* Lack of error handling and debugging tools(e.g. if you make an error in your LuaAI engine code, the game will just crash)
* Lack of documentation(the lack of documentation will partially resolve, once LuaAI will be cleaned from the boilerplate code, there will simply be less things to document)
<h4>Goals</h4>
* The main goal of the project is to make the LuaAI a fully functional, safe, stable and most importantly simple to use AI development environment. I don't even need to mention, that it shouldn't have any bugs at all, the known ones must be fixed as soon as possible, the unknown ones must be discovered.
* The secondary goal, but not less important, is to provide some kind of a debugging interface, for the LuaAI devs. I am not quite sure, how much time will I have for this, but certain in-game GUI overlays, displaying the workflow and results of the LuaAI engine code, ca's and stages are, most certainly, top priority.
<h4>Before and after</h4>
Before:
[engine]
name="lua"
code= <<
local ai = ...
local ai_stdlib = wesnoth.require('ai/lua/stdlib.lua');
ai_stdlib.init(ai)
my_ai = {}
!-- set up functions of my_ai here
return my_ai
>>
[/engine]
This is the absolute minimum at the moment. There is even more code to be written to actually make LuaAI able to do something useful. For example, you won't be able to use lots of tools and features of the current LuaAI system if you don't add this preload event:
[event]
name=preload
first_time_only=no
[lua]
code = <<
H = wesnoth.require "lua/helper.lua"
W = H.set_wml_action_metatable {}
_ = wesnoth.textdomain "my-campaign"
ai = {}
ca_counter = 0

H.set_wml_var_metatable(_G)
>>
[/lua]
[/event]
There's even more to do, if you want to set up your own candidate actions and stages. That is obviously too many things to do, each time you start creating a scenario or just a LuaAI player. Also, the code in the preload template exposes variables that shouldn't be modified by the user(also these variables may cause bugs in the way they are right now, eg ca_counter shouldn't always be 0, that is a error I introduced to the code and I will fix it).
What I will be working towards, should look like this:
[engine]
name="lua"
code= <<
>>
[/engine]
We can shorten this even more, with macros, for example, or make the C++ side add this section for us, if we omit it. The need to define the preload event should be completely removed, this is something the machine can and should do instead of us.
<h4>LuaAI element management</h4>
Right now, the management of the AI elements is completely manual, which isn't good in my opinion. If we let our computers do that for us, we can't make mistakes while doing that. 
Lets create a small candidate action:
function my_ai:candidate_action_evaluation()
local score = long_complicated_formula()

return score
end

function my_ai:candidate_action_execution()
wesnoth.message("LuaAI", "I win!")
end
(note: this code goes into the engine attribute of the LuaAI definition)
To make this trivial candidate action work, our steps would be:

[stage]
name=testing_ai_default::candidate_action_evaluation_loop
id=ca_loop
[candidate_action]
engine=lua
name=candidate_action
evaluation="return (...):candidate_action_evaluation()"
execution="(...):candidate_action_execution()"
[/candidate_action]
[/stage]

Again, this is too much to do, to set up a small candidate action. I have two ideas here: (1) we force the developer to name his functions in a certain format(e.g. <name>_eval and <name>_exec) and analyze the code to extract these pairs and add them automatically; (2) we leave markers in the Lua code, that will be gathered by the preprocessor and then do the automation. 
There are several ways of doing this task, but the most important part is the automation framework. Once it is done, we can choose different paths or even implement more than one way.
<h4>Work in progress</h4>
Right now I am working on a caching system for LuaAI. It will be very simple, yet powerful. All of the getters(get_attacks, get_dstsrc, etc) will not call C++ directly. Instead, these functions will make a call to a proxy function, which will keep a cache table and will request object retranslation only in the cases, when the objects kept in the cache get invalidated. This really needs to be done, because some CA's in the loop might get evaluated and executed more than once in one turn, that leads to multiple expensive C++ to Lua conversions of the very same object. And what if we have 10 CA's in a loop and the object doesn't change? We are talking about hundreds, maybe even a thousand conversion instead of one. The cache system will be able to take care of that.
<h4>Documentation</h4>
As far as I know, documentation of code is not part of the GSoC program, but I decided, that I will spend at least one hour every day in the evenings, to create documentation for the whole AI system(except if I run short on time again, then I am going to focus on my project more). From my experience last year, I know, how much a UML diagram would've helped, when dealing with the composite AI system, that combines several design patterns and is not easy to comprehend at first, due to its size.
Of course, each peace of code produced by myself, will also be documented properly, no matter what. I also got pointed out, that I left some of my previous code undocumented, so that will be handled asap too.

=IRC=
Nephro, neph
=SoC Application=
Submitted to google

=Questionnaire=
Off topic: I did this questionnaire last year, but I don't remember what I wrote in it. I won't look on purpose, until I complete this one, and try to see, whether I've changed at all...

<h2>1) Basics</h2>

1.1) Write a small introduction to yourself. 
Hi, my name is Dmitry Kovalenko and I am aspiring software developer. I've been interested in sciences and engineering since about 5th grade, about that time, I got my first PC without and, without any internet, started to hack around it. It was old and semi-broken, but I got it to run Windows 95 and was very proud of myself. I played a lot of games on it, despite the fact that my games were 10 years older than the games of my classmates, and one day, I decided to write my own game, which would combine the brilliance of my favorite games, lacking their flaws. I failed, of course, at the very first steps, but those were also the first steps towards the career I am pursuing now, 5 years later.

1.2) State your preferred email address. 
nephro dot wes at gmail dot com

1.3) If you have chosen a nick for IRC and Wesnoth forums, what is it? 
Nephro on irc.freenode.com and Nephro in the forums

1.4) Why do you want to participate in summer of code? 
Last year, it was all about proving to myself that I can get accepted and make it through. This year it's exactly the same, only to add the word "again" to the previous sentence.
To be honest, I was very disappointed in my performance last year. I was slow, inefficient, imprecise(left a fair amount of bugs after myself) and a bit unorganized. This year I want it to be good, like it should be. 
I can't even compare the experience gained working on this project with a mentor to anything else. The large sophisticated codebase, working with other people directly, designing for long term, milestones(which I like to consider deadlines), it all allows to immerse in gamedev, while not applying too much pressure, like corporate development. 

1.5) What are you studying, subject, level and school? 
Computing Science, year 2 
University of Glasgow, Glasgow, Scotland, UK

1.6) What country are you from, at what time are you most likely to be able to join IRC? 
Right now I reside in Scotland, but will, most probably, live in Latvia during the summer.
I am usually online during the working day time in Europe and most of the evenings. 

1.7) Do you have other commitments for the summer period ? Do you plan to take any vacations ? If yes, when. 
I have no commitments during this summer, except for maybe rare sports matches, but they usually take place on the weekends, so will not affect my workflow.

<h2>2) Experience</h2>

2.1) What programs/software have you worked on before? 
I participated in lots of programming contests before going to University. Therefore, I have experiences in writing "one algorithm programs"(contest program that solves a particular mathematical or algorithmic problem), high speed development(in contests, where we had to write up an app in a matter of hours) and some tricky stuff(for contests that tested skills in creating systems from several unrelated parts, not only programming). I've also spent two summers working in a small company, once expanding the functionality of a social network and once developing a server side for a browser based game. 
2.2) Have you developed software in a team environment before? (As opposed to hacking on something on your own) 
I have been working in a team environment for two summers, in the company I told in (2.1). Also, several contests were also team-based, I was working with very gifted people and together we managed to win a couple of trophies. I also consider my last summer project for GSoC with Wesnoth a teamwork experience, since I wasn't developing quite what I wanted, but rather, what we discussed to presumably be good beforehand.
 
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? 
I have participated in GSoC 2011 for Wesnoth as a student. The project was about expanding the functionality of LuaAI and improving the AI system in general. Although I've seemed to have passed all the milestones for Google and was successful in a program, I am not quite happy about myself. I had a good idea that the organizers liked too, but before I could tackle the implementation of it, I needed to complete a compulsory part. It took me much longer than it should have, I kept constantly stumbling on weird errors, bugs, sometimes I implemented the wrong designs and had to redo. In the end, I didn't even touch my own idea, because the summer ended faster than I expected. 
I think the big mistake there, was overestimating my own abilities. I also didn't evaluate the amount of compulsory work correctly, thinking it's mostly straightforward and I won't encounter any problems along the way.
 
2.4) Are you already involved with any open source development projects? If yes, please describe the project and the scope of your involvement. 
I am currently a developer for Battle for Wesnoth. I tried to engage in other OSS projects, but University workload didn't give me a chance to do that.
 
2.5) Gaming experience - Are you a gamer? 
Wouldn't call myself a gamer, I don't like that word. But I really like playing qualitative games, but recently I had no time to play a lot myself, so I became more of a spectator, watching professional players play on the global competitive scene. 
2.5.1) What type of gamer are you? 
I started out like most of us, playing classic games on an old pc. When I first got a good and powerful PC, I met people, who involved me in our regional competitive scene. From that point I played less and less single player and moved to competitive multiplayer. At this point, I don't play single player games at all, they just don't give me the challenge, that I need, anymore. 
2.5.2) What type of games? 
I am a big fan of the MOBA(Multiplayer online battle arena) genre, it is getting very popular in the world, even starting to push the grands like Counter-Strike and Starcraft aside. I also enjoy watching a good match of Starcraft 2 once in a while and really respect the talented players of that game.
 
2.5.3) What type of opponents do you prefer? 
Lately, the criteria for both, teammates and opponents, are skill level, mental capabilities and age. It's not that I don't like young people, they just more often don't care about the game. On a typical day, I would usually not care about games too, but if I find time to sit down and play, I want to gain maximum experience during that time and I need the people playing with and against me taking it all seriously.
 
2.5.4) Are you more interested in story or gameplay? 
When I play a game, I always analyze the interesting parts of it. A great game must find the perfect balance between both, but my mind is usually oriented on the engineering aspects, such as game dynamics, gameplay mechanics and the flexibility of the game engine. This gives me a way of comparing different games and finding the most enjoyable one.
 
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 have played wesnoth during school years. I lived 50 km from my school and traveled 2 hours by train everyday. It wasn't so tough, because I had my laptop and some good games on it, one of which was Wesnoth. We played it both, SP and MP on the same machine. I also played a lot of wesnoth last year, when I lived in a flat with no internet, that was probably the time when I have completed most of the scenarios.
 
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. 
I am developer of Wesnoth and have quite a few commits listed on my name. The latest ones are only small bugfixes. Right now I am working on a bigger and more interesting, so I'll probably link to it when it's done.
 

<h2>3) Communication skills</h2>

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 study in the UK, so English isn't a problem for me. I received a band of 7.5 in the IELTS test, which is considered very good.
 
3.2) What spoken languages are you fluent in? 
I am a native Russian speaker, but was born in Latvia. These are the two languages besides English, that I use almost on a daily basis(not too much Latvians here in Scotland, but there are a couple). 

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 had absolutely no interaction with the player community last year, and I doubt that I will encounter such a need this year, due to the specifics of my project, but I can assure you, that I am used to dealing with all kinds of behavior, and am pretty good at settling things down, if the situation becomes less friendly than it is needed.
 

3.4) Do you give constructive advice? 
Can't judge myself, but I try to always back my words up by constructive arguments.
 
3.5) Do you receive advice well? 
Yes, as long as the person, who gives the advice, clearly explains the reasoning. If I hear phrases like "Just do it that way, because it's the right way", I won't immediately ignore that, but will try to find reasoning elsewhere, if the author isn't too constructive about it.
 
3.6) Are you good at sorting useful criticisms from useless ones? 
I think I am. I developed these skills thanks to one of my hobbies: music production. I like to have a go in my digital audio workstation once in a while, just for fun, and I sometimes post things on forums. I usually hear a lot there, but only 10% usually makes sense to me. I've never actually encountered inappropriate criticisms while working on wesnoth. People always have a point, when they ping me out in IRC and ask to fix something I screwed up.
 
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 used the "see how it turns out" method when I was younger, it got clear to me pretty fast, that I won't get far this way. In the pre-GSoC period last year, I didn't discuss my changes to the code enough, and ended up redoing a very big block of code almost from scratch. Since then I've explored the current design more deeply, and my ideas now seem to be closer to the ideas of the senior devs, but I usually still ask questions about the design, before starting, to save the time of myself and the person I am asking.
 

<h2>4) Project</h2>

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 "AI: Make lua AI development and usage easier". The choice is described in more detail in the Project section of this wiki page. 
4.2) If you have invented your own project, please describe the project and the scope. 
- 
4.3) Why did you choose this project? 
The choice is described in more detail in the Project section of this wiki page. 
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". 
The timeline will be provided in the Timeline section of this wiki page.
4.5) Include as much technical detail about your implementation as you can 
The project is described in more detail in the Project section of this wiki page. 
4.6) What do you expect to gain from this project? 
Experience, implementation skills and most importantly - confidence. 
4.7) What would make you stay in the Wesnoth community after the conclusion of SOC? 
Wesnoth community is great as it is. I don't see a single change needed to be done. I became inactive for almost a year, only due to the University workload, which caught me off guard this year. The people are all friendly, helpful and very competent. While I was here, I got help on so many things besides the game itself: design patterns, C++ help, Lua help, overall game development process and so much more. This community is a very great place, where people can learn in a fun way, not investing a penny.
 

<h2>5) Practical considerations</h2>

5.1) Are you familiar with any of the following tools or languages? 
* Subversion (used for all commits)
* C++ (language used for all the normal source code)
* STL, Boost, Sdl (C++ libraries used by Wesnoth)
I have been using the three technologies listed above quite extensively for Wesnoth development during last summer.
* Python (optional, mainly used for tools)
Python is the language used in our University during first year computing courses, so I am quite agile with it.
* build environments (eg cmake/scons)
I use cmake for my wesnoth builds and try not to forget add new files to other build system config files.
* WML (the wesnoth specific scenario language)
* Lua (used in combination with WML to create scenarios)
Used both WML and Lua during my project last summer. 
5.2) Which tools do you normally use for development? Why do you use them? 
While working on Wesnoth, I usually use KDevelop and Subversion(cli). KDevelop provides me with a neat and comfortable development environment, it has decent autocompletion, code checking and never causes problems for me. Also, wesnoth has a project file for this IDE, so I don't have to worry about more technical, not related to my actual tasks, things. 
Subversion is, of course, the version control system that wesnoth generally uses, it also suits my needs, and I am not even considering switching to something else at the moment. 
For university work, we are forced to use Eclipse for most of the development, some other custom IDEs for processor/chip programming and IDLE for Python scripts.

5.3) What programming languages are you fluent in? 
Languages relevant to BfW: C/C++/Lua, + basic WML I might require during testing, documentation and demonstration of features I'm working on. 
Experiences irrelevant to the project: 
PHP/MySql - moderate level, used it once for professional development
Java/Python - Languages I use for university and take courses in
C#/Monodevelop - used once for professional development and a couple of times for contest programming
Pascal - used quite a lot for contest programming and algorithm studies, when I was younger.

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! 

No problems with talking on the phone. I will provide my telephone number and my skype ID later.

SoC2012 Nephro

SoC2012 Nephro

2012-04-03T03:50:54Z

Nephro:

{{SoC2012Student}}
[[Category:SoC_Ideas_AI_Lua_AI_Usage_2012]]

=Description=
<h4>Dmitry Kovalenko(Nephro) - Further Lua</h4>
==Simplify LuaAI==
Right now, the LuaAI system is in a state, where it can be used for artificial intelligence system development for Battle for Wesnoth campaigns, but it's usage is quite complicated and requires effort to get the system off the ground and make it run. To simply to launch a campaign with an empty LuaAI(by empty, I mean, not doing anything) a UMC developer is required to write a couple dozens of lines of code. While it seems, that we could simply hide the boilerplate code in a template or behind a macro, the situation is a bit more sophisticated(Later I will describe that in more detail). Instead of running away from this problem, I will work towards an elegant solution, creating an effective back-end system, and a clean user development environment.

=IRC=
Nephro, neph

=Questionnaire=
1) Basics

1.1) Write a small introduction to yourself.

1.2) State your preferred email address.

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

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

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

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

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

2) Experience

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

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

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?

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

2.5) Gaming experience - Are you a gamer?

2.5.1) What type of gamer are you?

2.5.2) What type of games?

2.5.3) What type of opponents do you prefer?

2.5.4) Are you more interested in story or 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.

We do not plan to favor Wesnoth players as such, but some particular projects require a good feeling for the game which is hard to get without having played intensively.

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.

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.

3.2) What spoken languages are you fluent in?

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

3.4) Do you give constructive advice?

3.5) Do you receive advice well?

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

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

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?

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

4.3) Why did you choose this project?

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".

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

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

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

5) Practical considerations

5.1) Are you familiar with any of the following tools or languages?
* Subversion (used for all commits)
* C++ (language used for all the normal source code)
* STL, Boost, Sdl (C++ libraries used by Wesnoth)
* Python (optional, mainly used for tools)
* build environments (eg cmake/scons)
* WML (the wesnoth specific scenario language)
* Lua (used in combination with WML to create scenarios)

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

5.3) What programming languages are you fluent in?

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!

In general, students should be as verbose as possible in their answers and feel free to elaborate.

SoC2012 Nephro

2012-04-03T03:49:52Z

Nephro:

{{SoC2012Student}}
[[Category:SoC_Ideas_AI_Lua_AI_Usage_2012]]

=Description=
<h4>Dmitry Kovalenko(Nephro) - Further Lua</h4>
<h3>Simplify LuaAI</h3>
Right now, the LuaAI system is in a state, where it can be used for artificial intelligence system development for Battle for Wesnoth campaigns, but it's usage is quite complicated and requires effort to get the system off the ground and make it run. To simply to launch a campaign with an empty LuaAI(by empty, I mean, not doing anything) a UMC developer is required to write a couple dozens of lines of code. While it seems, that we could simply hide the boilerplate code in a template or behind a macro, the situation is a bit more sophisticated(Later I will describe that in more detail). Instead of running away from this problem, I will work towards an elegant solution, creating an effective back-end system, and a clean user development environment.

=IRC=
Nephro, neph

=Questionnaire=
1) Basics

1.1) Write a small introduction to yourself.

1.2) State your preferred email address.

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

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

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

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

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

2) Experience

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

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

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?

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

2.5) Gaming experience - Are you a gamer?

2.5.1) What type of gamer are you?

2.5.2) What type of games?

2.5.3) What type of opponents do you prefer?

2.5.4) Are you more interested in story or 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.

We do not plan to favor Wesnoth players as such, but some particular projects require a good feeling for the game which is hard to get without having played intensively.

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.

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.

3.2) What spoken languages are you fluent in?

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

3.4) Do you give constructive advice?

3.5) Do you receive advice well?

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

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

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?

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

4.3) Why did you choose this project?

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".

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

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

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

5) Practical considerations

5.1) Are you familiar with any of the following tools or languages?
* Subversion (used for all commits)
* C++ (language used for all the normal source code)
* STL, Boost, Sdl (C++ libraries used by Wesnoth)
* Python (optional, mainly used for tools)
* build environments (eg cmake/scons)
* WML (the wesnoth specific scenario language)
* Lua (used in combination with WML to create scenarios)

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

5.3) What programming languages are you fluent in?

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!

In general, students should be as verbose as possible in their answers and feel free to elaborate.

SoC2012 Nephro

2012-04-03T03:47:05Z

Nephro:

{{SoC2012Student}}
[[Category:SoC_Ideas_AI_Lua_AI_Usage_2012]]

=Description=
<h4>Dmitry Kovalenko(Nephro) - Further Lua</h4>
<h5>Simplify LuaAI</h5>
Right now, the LuaAI system is in a state, where it can be used for artificial intelligence system development for Battle for Wesnoth campaigns, but it's usage is quite complicated and requires effort to get the system off the ground and make it run. To simply to launch a campaign with an empty LuaAI(by empty, I mean, not doing anything) a UMC developer is required to write a couple dozens of lines of code. While it seems, that we could simply hide the boilerplate code in a template or behind a macro, the situation is a bit more sophisticated(Later I will describe that in more detail). Instead of running away from this problem, I will work towards an elegant solution, creating an effective back-end system, and a clean user development environment.

<h5></h5>

=IRC=
Nephro, neph

=Questionnaire=
1) Basics

1.1) Write a small introduction to yourself.

1.2) State your preferred email address.

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

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

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

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

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

2) Experience

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

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

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?

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

2.5) Gaming experience - Are you a gamer?

2.5.1) What type of gamer are you?

2.5.2) What type of games?

2.5.3) What type of opponents do you prefer?

2.5.4) Are you more interested in story or 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.

We do not plan to favor Wesnoth players as such, but some particular projects require a good feeling for the game which is hard to get without having played intensively.

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.

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.

3.2) What spoken languages are you fluent in?

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

3.4) Do you give constructive advice?

3.5) Do you receive advice well?

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

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

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?

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

4.3) Why did you choose this project?

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".

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

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

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

5) Practical considerations

5.1) Are you familiar with any of the following tools or languages?
* Subversion (used for all commits)
* C++ (language used for all the normal source code)
* STL, Boost, Sdl (C++ libraries used by Wesnoth)
* Python (optional, mainly used for tools)
* build environments (eg cmake/scons)
* WML (the wesnoth specific scenario language)
* Lua (used in combination with WML to create scenarios)

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

5.3) What programming languages are you fluent in?

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!

In general, students should be as verbose as possible in their answers and feel free to elaborate.

SoC2012 Nephro

2012-04-03T03:46:22Z

Nephro:

{{SoC2012Student}}
[[Category:SoC_Ideas_AI_Lua_AI_Usage_2012]]

=Description=
<h4>Dmitry Kovalenko(Nephro) - Further Lua</h4>
<h3>Simplify LuaAI</h3>
Right now, the LuaAI system is in a state, where it can be used for artificial intelligence system development for Battle for Wesnoth campaigns, but it's usage is quite complicated and requires effort to get the system off the ground and make it run. To simply to launch a campaign with an empty LuaAI(by empty, I mean, not doing anything) a UMC developer is required to write a couple dozens of lines of code. While it seems, that we could simply hide the boilerplate code in a template or behind a macro, the situation is a bit more sophisticated(Later I will describe that in more detail). Instead of running away from this problem, I will work towards an elegant solution, creating an effective back-end system, and a clean user development environment.

<h3></h3>

=IRC=
Nephro, neph

=Questionnaire=
1) Basics

1.1) Write a small introduction to yourself.

1.2) State your preferred email address.

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

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

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

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

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

2) Experience

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

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

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?

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

2.5) Gaming experience - Are you a gamer?

2.5.1) What type of gamer are you?

2.5.2) What type of games?

2.5.3) What type of opponents do you prefer?

2.5.4) Are you more interested in story or 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.

We do not plan to favor Wesnoth players as such, but some particular projects require a good feeling for the game which is hard to get without having played intensively.

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.

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.

3.2) What spoken languages are you fluent in?

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

3.4) Do you give constructive advice?

3.5) Do you receive advice well?

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

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

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?

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

4.3) Why did you choose this project?

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".

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

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

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

5) Practical considerations

5.1) Are you familiar with any of the following tools or languages?
* Subversion (used for all commits)
* C++ (language used for all the normal source code)
* STL, Boost, Sdl (C++ libraries used by Wesnoth)
* Python (optional, mainly used for tools)
* build environments (eg cmake/scons)
* WML (the wesnoth specific scenario language)
* Lua (used in combination with WML to create scenarios)

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

5.3) What programming languages are you fluent in?

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!

In general, students should be as verbose as possible in their answers and feel free to elaborate.