Difference between revisions of "SoC2012 Nephro"

From The Battle for Wesnoth Wiki
(The project)
(The project)
Line 158: Line 158:
 
<h4>Thanks</h4>
 
<h4>Thanks</h4>
 
for your time and attention.
 
for your time and attention.
 +
 +
=Timeline=
 +
 +
 +
 +
<TABLE WIDTH=100% BORDER=1 BORDERCOLOR="#000000" CELLPADDING=4 CELLSPACING=0>
 +
<COL WIDTH=85*>
 +
<COL WIDTH=85*>
 +
<COL WIDTH=85*>
 +
<TR VALIGN=TOP>
 +
<TD WIDTH=33%>
 +
<P>Date</P>
 +
</TD>
 +
<TD WIDTH=33%>
 +
<P>Task</P>
 +
</TD>
 +
<TD WIDTH=33%>
 +
<P>Importance</P>
 +
</TD>
 +
</TR>
 +
<TR VALIGN=TOP>
 +
<TD WIDTH=33%>
 +
<P>Mid April &ndash; mid May</P>
 +
</TD>
 +
<TD WIDTH=33%>
 +
<P>Exam session at University</P>
 +
</TD>
 +
<TD WIDTH=33%>
 +
<P><BR>
 +
</P>
 +
</TD>
 +
</TR>
 +
<TR VALIGN=TOP>
 +
<TD WIDTH=33%>
 +
<P>April 1 - April 8</P>
 +
</TD>
 +
<TD WIDTH=33%>
 +
<P>Fixing minor issues and bugs, discussing the project with the
 +
mentors and potential users. Helping other students get a grip on
 +
the AI system.</P>
 +
</TD>
 +
<TD WIDTH=33%>
 +
<P>High(some bugs cause crashes and make LuaAI unusable)</P>
 +
</TD>
 +
</TR>
 +
<TR VALIGN=TOP>
 +
<TD WIDTH=33%>
 +
<P>April 8 &ndash; April 10</P>
 +
</TD>
 +
<TD WIDTH=33%>
 +
<P>Caching system for LuaAI, to reduce inefficiency while
 +
translating heavy objects from C++ to Lua.</P>
 +
</TD>
 +
<TD WIDTH=33%>
 +
<P>High</P>
 +
</TD>
 +
</TR>
 +
<TR VALIGN=TOP>
 +
<TD WIDTH=33%>
 +
<P>April 10 &ndash; April 11</P>
 +
</TD>
 +
<TD WIDTH=33%>
 +
<P>Exposing the attack vector to LuaAI.</P>
 +
</TD>
 +
<TD WIDTH=33%>
 +
<P>Very High(users of LuaAI demand this crucial feature)</P>
 +
</TD>
 +
</TR>
 +
<TR VALIGN=TOP>
 +
<TD WIDTH=33%>
 +
<P>April 11 &ndash; April 13</P>
 +
</TD>
 +
<TD WIDTH=33%>
 +
<P>Factoring out enemy attack calculation and exposing it to
 +
LuaAI. Might take more or less time, but shouldn't shift the
 +
timeline by more than one day.</P>
 +
</TD>
 +
<TD WIDTH=33%>
 +
<P>High</P>
 +
</TD>
 +
</TR>
 +
<TR VALIGN=TOP>
 +
<TD WIDTH=33%>
 +
<P>April 13 &ndash; April 14</P>
 +
</TD>
 +
<TD WIDTH=33%>
 +
<P>Possible exposure of LuaAI contexts to the global environment,
 +
for debug purposes</P>
 +
</TD>
 +
<TD WIDTH=33%>
 +
<P>Low(this is not yet discussed with the main AI developer)</P>
 +
</TD>
 +
</TR>
 +
<TR VALIGN=TOP>
 +
<TD WIDTH=33%>
 +
<P>Mid April &ndash; Mid June</P>
 +
</TD>
 +
<TD WIDTH=33%>
 +
<P>Exposure of the missing functionality to LuaAI. Will probably
 +
take less time, but I don't want to rush it. I will also have my
 +
exams during this time and will have to travel home in the
 +
beginning of June.</P>
 +
</TD>
 +
<TD WIDTH=33%>
 +
<P>High(since LuaAI is the future of AI development for Wesnoth,
 +
it must have all the power the C++ currently has).</P>
 +
</TD>
 +
</TR>
 +
<TR VALIGN=TOP>
 +
<TD WIDTH=33%>
 +
<P>Mid June &ndash; July 9</P>
 +
</TD>
 +
<TD WIDTH=33%>
 +
<P>By mid June, LuaAI should have all the functionality C++ has(or
 +
at least the very commonly used and irreplaceable tools). Now the
 +
work shifts towards polishing the LuaAI development environment,
 +
finishing up the documentation and finalizing boilerplate code
 +
removal.</P>
 +
</TD>
 +
<TD WIDTH=33%>
 +
<P>Very high(hopefully, after this step, LuaAI will be in very
 +
good shape and, in terms of usability, will be able to compete
 +
with C++).
 +
</P>
 +
</TD>
 +
</TR>
 +
<TR VALIGN=TOP>
 +
<TD WIDTH=33%>
 +
<P>July 9 &ndash; July 25</P>
 +
</TD>
 +
<TD WIDTH=33%>
 +
<P>Work on debugging tools and features.</P>
 +
</TD>
 +
<TD WIDTH=33%>
 +
<P>High(development is quite frustrating with no debugging tools)</P>
 +
</TD>
 +
</TR>
 +
<TR VALIGN=TOP>
 +
<TD WIDTH=33%>
 +
<P>July 25 &ndash; August 13</P>
 +
</TD>
 +
<TD WIDTH=33%>
 +
<P>Work on the &ldquo;concept&rdquo; mechanism, the system that
 +
will provide a simple interface, so that any developer or even
 +
player, can make the AI stronger, by teaching it something new,
 +
using LuaAI scripts.</P>
 +
</TD>
 +
<TD WIDTH=33%>
 +
<P>Medium(not yet properly discussed, but a desired feature)</P>
 +
</TD>
 +
</TR>
 +
<TR VALIGN=TOP>
 +
<TD WIDTH=33%>
 +
<P>August 13 &ndash; September 1</P>
 +
</TD>
 +
<TD WIDTH=33%>
 +
<P>Completion of everything, that didn't get enough attention
 +
during the SoC period. By this time, bugs introduced in summer
 +
should be revealed. Fixing those bugs and polishing documentation.</P>
 +
</TD>
 +
<TD WIDTH=33%>
 +
<P>High(in order to feel satisfied, I want everything to be done
 +
before autumn comes and ruins all my AI improvement plans, with
 +
impossible to bear University workload).</P>
 +
</TD>
 +
</TR>
 +
</TABLE>
  
 
=IRC=
 
=IRC=

Revision as of 00:59, 6 April 2012


This page is related to Summer of Code 2012
See the list of Summer of Code 2012 Ideas



This is a Summer of Code 2012 student page


Description

Dmitry Kovalenko(Nephro) - Further Lua

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

Intro

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.

Importance

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.

Known problems

  • 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)

Goals

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

Before and after

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.

LuaAI element management

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.

Work in progress

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.

The future of Wesnoth artificial intelligence

My vision of the future Wesnoth AI relies on the quality of the LuaAI engine and the general AI improvements. We will have a smart AI that will have a new stage before the RCA_loop, that will analyze the current situation and if it's appropriate, use tricks to gain profit and capitalize on it's advantages. The stage could look like this(very high level pseudocode, illustrates only the situation with the luring concept):

 analysis stage {
  // parts omitted

  for (concept in concepts) do					// concepts is a list of known tricks
		if(concept.analyse_if_possible()) {		// check if we can execute a trick, lure for example
			concept.prepare()			// find the units that can participate 
			concept.setup()				// create the needed candidate actions
		}		   
  end
  
  // parts omitted
}

Now, when the RCA starts its work, there will be candidate actions that will execute the luring, and, hopefully, the AI will kill a couple of warriors, who chased the poor scout in to the shroud.

The "concepts" will be generated from a list of developer approved concepts(e.g. lure, chase, patrol, flee, suicide, scatter, etc, etc, etc). A concept will have to implement an interface(actually, Lua doesn't have interfaces, but lets say it does, so my text looks smarter) consisting of methods "analyse_if_possible", "prepare", "setup". The setup will generate predefined candidate actions and add them to the RCA. This is why I think that polishing and completing the LuaAI is so important. That will allow people to make the AI stronger, not being scared off by the sophisticated C++ coding.

Documentation

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.

Thanks

for your time and attention.

Timeline

<COL WIDTH=85*> <COL WIDTH=85*> <COL WIDTH=85*>

Date

Task

Importance

Mid April – mid May

Exam session at University


April 1 - April 8

Fixing minor issues and bugs, discussing the project with the mentors and potential users. Helping other students get a grip on the AI system.

High(some bugs cause crashes and make LuaAI unusable)

April 8 – April 10

Caching system for LuaAI, to reduce inefficiency while translating heavy objects from C++ to Lua.

High

April 10 – April 11

Exposing the attack vector to LuaAI.

Very High(users of LuaAI demand this crucial feature)

April 11 – April 13

Factoring out enemy attack calculation and exposing it to LuaAI. Might take more or less time, but shouldn't shift the timeline by more than one day.

High

April 13 – April 14

Possible exposure of LuaAI contexts to the global environment, for debug purposes

Low(this is not yet discussed with the main AI developer)

Mid April – Mid June

Exposure of the missing functionality to LuaAI. Will probably take less time, but I don't want to rush it. I will also have my exams during this time and will have to travel home in the beginning of June.

High(since LuaAI is the future of AI development for Wesnoth, it must have all the power the C++ currently has).

Mid June – July 9

By mid June, LuaAI should have all the functionality C++ has(or at least the very commonly used and irreplaceable tools). Now the work shifts towards polishing the LuaAI development environment, finishing up the documentation and finalizing boilerplate code removal.

Very high(hopefully, after this step, LuaAI will be in very good shape and, in terms of usability, will be able to compete with C++).

July 9 – July 25

Work on debugging tools and features.

High(development is quite frustrating with no debugging tools)

July 25 – August 13

Work on the “concept” mechanism, the system that will provide a simple interface, so that any developer or even player, can make the AI stronger, by teaching it something new, using LuaAI scripts.

Medium(not yet properly discussed, but a desired feature)

August 13 – September 1

Completion of everything, that didn't get enough attention during the SoC period. By this time, bugs introduced in summer should be revealed. Fixing those bugs and polishing documentation.

High(in order to feel satisfied, I want everything to be done before autumn comes and ruins all my AI improvement plans, with impossible to bear University workload).

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

1) Basics

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.

2) Experience

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.

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

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

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)

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.