https://wiki.wesnoth.org/api.php?action=feedcontributions&user=Ejls&feedformat=atomThe Battle for Wesnoth Wiki - User contributions [en]2024-03-28T09:28:48ZUser contributionsMediaWiki 1.31.16https://wiki.wesnoth.org/index.php?title=GSoC_Akihara_Proposal&diff=46502GSoC Akihara Proposal2012-04-20T13:36:23Z<p>Ejls: SummerOfCodeIdeas-fication (you should put only your name in the IRC section)</p>
<hr />
<div>{{SoC2012Student}}<br />
[[Category:SoC_Ideas_AI_Recruitment_2012]]<br />
<br />
= Description =<br />
==== Aline Riss Recruitment Proposal ====<br />
<br />
For the moment, AI recognize only one leader even if he has more. Moreover, the recruitment algorithm is very basic. So we can set the list of possible amelioration below:<br />
* support recruiting with multiple leaders<br />
* support per-leader recruit/recall lists.<br />
* support easy limiting of recruitable units.<br />
* analyze map terrain better<br />
* recruit units that are more useful<br />
* improve counter-recruiting strategies.<br />
* improve recruiting for AI-playable campaigns where AI has to not spend all the gold.<br />
<br />
In order to treat these problematic, I have highlight two points which will be my principals axes for this project and will be treat separately :<br />
* '''The placement of leaders'''<br />
* '''The recruitment algorithm'''<br />
Each point are, at begin, independent for each other.<br />
<br />
First, I will treat the recruitment algorithm which is the principal problem of this project. It's only in a second part that I will treat the placement problem.<br />
<br />
= About me =<br />
<br />
I'm a 22 french student girl. I'm currently studying computer science and I would like to specialize myself in development. I'm fond of open source things but never took part of an project. So GSoC is, for me, a first step in this world. <br />
I'm studying computer science in the University of Technology of Belfort Monbéliard (France). I'm a 3-year student. For the moment, I'm studying very various things (dev, network, ...) but I clearly want to be a dev.<br />
You can join me at aline.riss[at]gmail.com and also on IRC with the nickname Akihara. Moreover, I have an irssi server running without interruption so I will always be connected. So, I'm more joinable and, even if i'm not in front of my screen, I will see messages and things like that. I'm generally here at 9am (France - GMT + 2).<br />
<br />
My holidays begins end June. But I won't forget Wesnoth and work as much as possible for it :)<br />
<br />
== IRC ==<br />
Akihara<br />
<br />
= Experience =<br />
<br />
None. It's the first time I will be working on a "real" project. All I have done is school projects for the moment. For example, I developed a graphic interface in order to learn graph theory in a team environment. We were 6.<br />
<br />
It's the first time I want to participate to the Google Summer of Code. As I said before, I never took part in any open source projects.<br />
<br />
= Gaming = <br />
<br />
I'm a real gamer. I'm between a mid-core and hardcore gamer :) I can play video game without interruption but I limit myself. I play very various games. I really like RPGs in which I can discover a new world but also FPS, very relaxig for me (strange, isn't it?), and also Strategy game for reflexion and the joy of aiming the goal. <br />
Generally, I prefer play against AI. But mostly, they are too weak too fast. On the other hand, playing against people is very fun when they are not yelling around.<br />
<br />
The reason I can stop myself is the discovering of the environment and also the story. I can difficulty stop myself playing until I know the end. Because of that, I'm attracted to RPG and other game with an unknown world. But I must admit that a good gameplay is very important. Without it, a game isn't a game anymore. <br />
<br />
I played Wesnoth some years ago (4? 5?) so didn't remember lot of things but I always played as a single player. But, in order to know the environment, I will play a little until the beginning of the GSoc.<br />
<br />
= My contribution to Wesnoth =<br />
== Patches ==<br />
<br />
{| class="wikitable centre" width="80%"<br />
|+<br />
|-<br />
! scope=col | Patch #<br />
! scope=col | Description<br />
! scope=col | Link<br />
|-<br />
| width="10%" |<br />
3237<br />
| width="34%" |<br />
'''''TRANSFORM_UNIT needs a variable renamed'''''<br />
| width="10%" |<br />
[http://gna.org/patch/?3237 Link]<br />
|-<br />
| width="10%" |<br />
3238<br />
| width="34%" |<br />
'''''"maximum auto saves" setting seems ignored'''''<br />
| width="10%" |<br />
[http://gna.org/patch/?3238 Link]<br />
|}<br />
<br />
I'm currently working on an AI problem: in fact, it seems that a unit prefer to repoison an poisoned unit instead of poison other unit.<br />
<br />
= Communication skills =<br />
<br />
I'm daily reading English so I have a good reading comprehension. In written english, I will do my best. I can do some mistakes but nobody didn't understand me.<br />
<br />
I think that the player community can be a bit rough as in mostly communities. I have no problem speaking with them. I'm a player too so I can understand what they say and how they feel. I won't be distracted by some rough players.<br />
<br />
In the dev community, If I can give some advice, I will. I'm not a specialist but I'm always here to help. If I have an idea, why not submit it? And the reciprocal is right too, even if I'm not agree this it. In this case, we can confront both idea. If I am right, the other person will learn something and reciprocally. I think that it is the magic of team work. Of course, part of them can be useful and others useless. I'm the type of person who will think about it again and again. Finally, I will be able to take the good part of them.<br />
<br />
Concerning my behavior when developing, I will say that generally, I need to know the environment (here the game). If I have an idea, I will first search how I can implement it. Parallel, I really like to talk with someone interested in my work in order explain and, why not, improve it.<br />
<br />
If I have no idea, I look sources at the beginning.<br />
<br />
Then, I will "see how it turn out" so I can have a better idea of what I am doing. I prefer doing it this way before losing time on something which will no work.<br />
<br />
= Project =<br />
== Why ==<br />
I choose a project from the list: "Refactor recruitment algorithm". I'm very interrested in AI algorihtm and how make them more intelligent. It's really interresting. I think that recruitment, in a game like this, is the beginning of everything. And it's also a question i'm asking to myself when I'm playing.<br />
<br />
I hope gain some experience from this project , and a view of how dev a game works. I'm very curious about this. And if I'm well integrated, I will stay and continue developing it.<br />
<br />
== Timeline ==<br />
<br />
{| border="1"<br />
| width ="8%" | +<br />
| width ="17%" | 21 May - 23 May <br />
|Familiarize myself with the current Wesnoth AI -> recruitment process, unit control ....<br />
|-<br />
| + <br />
|23 may - 28 May<br />
|Working on some patches in order to continue to explore and understand the current AI<br />
|-<br />
| +<br />
| 29 May - 31 May<br />
| AI recognition of multiple leader. The goal is for the AI to use several leaders in a very basic way -> recruit unit with only gold and unoccupied place on keep limits. <br />
|-<br />
| +<br />
| 1 June - 3 June<br />
| Work on an AI vs AI environment in order to watch a battle between the current and the new AIs.<br />
|-<br />
| +<br />
| 3 June - 12 June<br />
| Implementation of the algorithm<br />
|-<br />
| +<br />
| 13 June - 1 July<br />
| Determination of the formula - The formula must score correctly a unit according to the current situation.<br />
<br />
|-<br />
| +<br />
| 1 July - 7 July<br />
| Repartition of the recruitment list to each leaders<br />
|-<br />
| +<br />
| 8 July - 15 July<br />
| Working on leaders limitation - AI must understand herself if he can recruit certain unit according to his limits.<br />
|-<br />
| +<br />
| 16 July - 13 August<br />
| Placement of leaders. AI must know how to place his leaders according to number of keep, number of leaders and leaders' race.<br />
|-<br />
| +<br />
| 13 August<br />
| Take a week to scrub code, write tests, improve documentation, etc.<br />
|}<br />
<br />
== Goals ==<br />
<br />
{| border="1"<br />
! #<br />
! PRIORITY<br />
! SUBPROJECT<br />
! TODO<br />
! STATUS<br />
|-<br />
| align="center" width ="5%" | 0<br />
| align="center" width ="10%" style="color:red" | MUST<br />
| align="center" | Recognition of leaders<br />
| AI must recognize all leaders he have<br />
| align="center" | To do<br />
|-<br />
| align="center" width ="5%" | 1<br />
| align="center" width ="10%" style="color:red" | MUST<br />
| align="center" | Placement of leaders<br />
| AI must find unoccupied keep and place leader on them<br />
| align="center" | To do<br />
|-<br />
| align="center" width ="5%" | 2<br />
| align="center" width ="10%" style="color:red" | MUST<br />
| align="center" | Placement of leaders<br />
| If the targeted keep became occupied by the enemy, AI should move him back and search an other keep to move him.<br />
| align="center" | To do<br />
|-<br />
| align="center" width ="5%" | 3<br />
| align="center" width ="10%" style="color:orange" | SHOULD<br />
| align="center" | Placement of leaders<br />
| Find a way to determine which leader should be on a particular keep. <br />
''The current objective is to find the fastest <leader, keep> couple in order to occupied keeps as quickly as possible''.<br />
| align="center" | To do<br />
|-<br />
| align="center" width ="5%" | 4<br />
| align="center" width ="10%" style="color:orange" | SHOULD<br />
| align="center" | Placement of leaders<br />
| If there is several leaders on a single keep, they should be moving in order to have a mix of recruited unit.<br />
| align="center" | To do<br />
|-<br />
| align="center" width ="5%" | 5<br />
| align="center" width ="10%" style="color:orange" | SHOULD<br />
| align="center" | Placement of leaders<br />
| If there is more leaders than keeps, AI must find a good leader/keep attribution<br />
''The current objective is to give the player the occasion to play against a maximum of unit type/race. Having a mix of race on a keep could be a good beginning.''<br />
| align="center" | To do<br />
|-<br />
| align="center" width ="5%" | 6<br />
| align="center" width ="10%" style="color:red" | MUST<br />
| align="center" | Placement of leaders<br />
| Testing a case where there is n leaders and m keeps, n >> m.<br />
| align="center" | To do<br />
|-<br />
| align="center" width ="5%" | -<br />
| align="center" width ="10%" style="color:blue" | MILESTONE<br />
| align="center" | -<br />
| Formula - The AI should be capable of place his leaders in a intelligent way.<br />
| align="center" | Not yet<br />
|-<br />
| align="center" width ="5%" | 7<br />
| align="center" width ="10%" style="color:red" | MUST<br />
| align="center" | Recruitment<br />
| Creating of an AI vs AI environment.<br />
| align="center" | To do<br />
|-<br />
| align="center" width ="5%" | 8<br />
| align="center" width ="10%" style="color:red" | MUST<br />
| align="center" | Recruitment<br />
| Finding a way to limit each leaders according to the scenario<br />
| align="center" | To do<br />
|-<br />
| align="center" width ="5%" | 9<br />
| align="center" width ="10%" style="color:red" | MUST<br />
| align="center" | Recruitment<br />
| Implement the minmax algorithm with a basic formula.<br />
| align="center" | To do<br />
|-<br />
| align="center" width ="5%" | 10<br />
| align="center" width ="10%" style="color:red" | MUST<br />
| align="center" | Recruitment<br />
| Formula - Determine a good scoring concerning '''the analyse of the requested unit type'''<br />
| align="center" | To do<br />
|-<br />
| align="center" width ="5%" | 11<br />
| align="center" width ="10%" style="color:red" | MUST<br />
| align="center" | Recruitment<br />
| Formula - Determine a good scoring concerning '''the analyse of the number of requested unit'''<br />
| align="center" | To do<br />
|-<br />
| align="center" width ="5%" | 12<br />
| align="center" width ="10%" style="color:red" | MUST<br />
| align="center" | Recruitment<br />
| Formula - Determine a good scoring concerning '''the analyse of the number of requested unit'''<br />
| align="center" | To do<br />
|-<br />
| align="center" width ="5%" | 13<br />
| align="center" width ="10%" style="color:red" | MUST<br />
| align="center" | Recruitment<br />
| Formula - Determine a good scoring concerning '''the analyse of limits we know'''<br />
| align="center" | To do<br />
|-<br />
| align="center" width ="5%" | 14<br />
| align="center" width ="10%" style="color:red" | MUST<br />
| align="center" | Recruitment<br />
| Formula - Determine a good scoring concerning '''the analyse of the terrain'''<br />
| align="center" | To do<br />
|-<br />
| align="center" width ="5%" | 15<br />
| align="center" width ="10%" style="color:red" | MUST<br />
| align="center" | Recruitment<br />
| Formula - Determine a good scoring concerning '''the analyse of the number of requested unit'''<br />
| align="center" | To do<br />
|-<br />
| align="center" width ="5%" | 16<br />
| align="center" width ="10%" style="color:red" | MUST<br />
| align="center" | Recruitment<br />
| Formula - Determine a good scoring concerning '''the analyse of the enemy's unit level'''<br />
| align="center" | To do<br />
|-<br />
| align="center" width ="5%" | -<br />
| align="center" width ="10%" style="color:blue" | MILESTONE<br />
| align="center" | Recruitment<br />
| AI should be able to determine his unit need<br />
| align="center" | Not yet<br />
|-<br />
| align="center" width ="5%" | 17<br />
| align="center" width ="10%" style="color:orange" | SHOULD<br />
| align="center" | Recruitment<br />
| AI should analyse the situation and determine which leader should recruit a specific unit.<br />
| align="center" | To do<br />
|-<br />
| align="center" width ="5%" | -<br />
| align="center" width ="10%" style="color:blue" | MILESTONE<br />
| align="center" | Recruitment<br />
| AI should be capable of determined which leader is the more useful to recruit a specific type of unit.<br />
| align="center" | To do<br />
|}<br />
<br />
== My idea ==<br />
<br />
I will certainly use existing code and file in order to ameliorate the recruitment algorithm.<br />
* <code>ai_default_recruitment_stage</code> (ai/default/ai.*)<br />
* <code>recruitment_phase</code> (ai/testing/ca.*)<br />
* <code>testing_recruitment_phase</code> (ai/testing/ca_testing_recruitment.*)<br />
<br />
=== General idea ===<br />
The general idea of the project is to use several leaders to recruit useful unit. To do so, we have a few steps to follow:<br />
* '''Place intelligently the leaders''' -> the placement of leaders will determine firsts limits of recruitment like the number of unused placement per keep. We will also know which leader can recruit<br />
* '''Determine the recruitment list for each leader'''<br />
* '''Recruit unit'''<br />
<br />
These steps are the general algorithm the AI should follow at the end. According to it, we can highlight two main points:<br />
* '''Leaders' placement'''<br />
** Recognize all leaders<br />
** Find a good leader distribution on keeps<br />
** Move them on keep<br />
* '''Recruitment algorithm'''<br />
** Determine points and limit in order to have a good choice of unit<br />
** Implement the algorithm<br />
** Test and ameliorate the algorithm<br />
<br />
=== Support multiple leaders ===<br />
<br />
''Current situation: For the moment, AI only use the first leader to recruit even if a 2nd leader is on keep an can recruit. Other point, if leaders are not on keep, AI must figure out a good leep for each leader, and move them to keeps.''<br />
<br />
==== Recognize all leaders ====<br />
All units (whatever their side) are currently stored into a <code>unit_map</code> which associate unit with their location. <br />
<br />
To get leaders associated to a specific side, we have the <code>unit_map::unit_iterator unit_map::find_leader(int side)</code> function which will return the first leader belonging to the right side.<br />
<br />
unit_map::unit_iterator unit_map::find_leader(int side) {<br />
unit_map::iterator i = begin(), i_end = end();<br />
for (; i != i_end; ++i) {<br />
if (static_cast<int>(i->side()) == side && i->can_recruit())<br />
return i;<br />
}<br />
return i_end;<br />
}<br />
<br />
So, in the case we have several leaders, the others will not be recognize. In order to recognize them, we simply need to chance this function in order to returning a list of leaders<br />
<br />
std::vector<unit_map::unit_iterator> unit_map::find_leader(int side) {<br />
std:vector<unit_map::unit_iterator> leaders;<br />
unit_map::iterator i = begin(), i_end = end();<br />
for (; i != i_end; ++i) {<br />
if (static_cast<int>(i->side()) == side && i->can_recruit())<br />
leaders.push_back(i);<br />
}<br />
return leaders;<br />
}<br />
<br />
==== Recruit with all leaders ====<br />
The current function recognize only one leader (according to the <code>find_leader()</code>) and return BAD_SCORE if:<br />
* there is no leader available<br />
* the leader is not on keep<br />
* if there is no available place on keep<br />
<br />
double testing_recruitment_phase::evaluate()<br />
{<br />
const unit_map::const_iterator leader = resources::units->find_leader(get_side());<br />
if(leader == resources::units->end()) {<br />
return BAD_SCORE;<br />
}<br />
<br />
if (!resources::game_map->is_keep(leader->get_location())) {<br />
return BAD_SCORE;<br />
} <br />
std::set<map_location> checked_hexes;<br />
checked_hexes.insert(leader->get_location());<br />
if (count_free_hexes_in_castle(leader->get_location(), checked_hexes)==0) {<br />
return BAD_SCORE;<br />
}<br />
return get_score();<br />
}<br />
<br />
At least, this function must consider the state of each leader.<br />
<br />
double testing_recruitment_phase::evaluate()<br />
{<br />
const std::vector<unit_map::const_iterator> leaders = resources::units->find_leader(get_side());<br />
<br />
for (unit_map::const_iterator i, leaders) {<br />
if(i == resources::units->end()) {<br />
return BAD_SCORE;<br />
}<br />
<br />
if (resources::game_map->is_keep(leader->get_location())) {<br />
std::set<map_location> checked_hexes;<br />
checked_hexes.insert(leader->get_location());<br />
if (count_free_hexes_in_castle(leader->get_location(), checked_hexes)!= 0) {<br />
return get_score;<br />
} <br />
}<br />
<br />
return BAD_SCORE;<br />
}<br />
<br />
==== Placement ====<br />
We can have several cases with different number of leaders and different number of keeps. We will look as each separately.<br />
These paragraph treat one case and introduce the behavior leader will should have in a particular situation.<br />
<br />
===== Case 1.1: several leaders (same type) - one keep =====<br />
If we have two, for example, leaders of the same type on a unique keep, we need to know which one will stay on the keep. We know that two different leaders can have different characteristics, so if one of them can be better in battle, he will leave and let the other on the keep.<br />
<br />
But the second leader mustn't go alone. He need to be surrounded. If he can, he will ''capture'' the enemy's keep (see case 2).<br />
<br />
In this case, we have:<br />
* ''a single list of recruitment''<br />
<br />
===== Case 1.2: several leaders (different type) - one keep =====<br />
In this case, we have at least two leaders of different types with only one keep. Let's name them A for the first (on the keep) and B the other one. The problem here is to use the two of them. The choose of the unit will be explain in the recruitment part (see '''recruitment'''). <br />
<br />
In this case, we have:<br />
* ''two recruitment_list''<br />
<br />
So, we have several cases:<br />
* If we only have unit A can recruit in the recruitment list, A will stay. B can go fight but not really far. He also can recruit on the next turn.<br />
* If we only have unit B can recruit in the recruitment list, A will go away and can fight. B will go on the keep in order to recruit.<br />
* If we have unit of both type, we will recruit the A list and then the B list.<br />
<br />
===== Case 2: several leaders - several keep =====<br />
<br />
Moving leaders on the right keep is the first problem. In fact, leaders can have different characteristic like moving faster for example. In this case, we must know the better way to reach the nearest keep as soon as possible. Of course, we can have a "basic" behavior which will assign the fastest leader to the nearest keep. A good things to do will be to calculate the best couple <leader, keep> for having all keeps reached as quickly as possible.<br />
It can be also useful to create a ''new class'' for having this couple in memory. If so, we aren't obliged to recalculate each path a second time. But we must calculate the state of keeps each time. I explain:<br />
Each turn, the enemy can put one of his leader on a keep the AI was watching. In this case, the leader must go back and find an other keep if there is any.<br />
<br />
In this case, we have<br />
* two recruitment list<br />
<br />
===== Case 3: m leaders - n keeps (m > n) =====<br />
If we have a number of leader superior than the number of keeps (and > 2), we will do:<br />
* choose leaders which will stay on keep. If leaders are from different types, we will chosen one of each to be on a keep. It will give to the player an good opportunity to play against various unit.<br />
* the other leaders will go to the front keep. If we can make a mix of type on front keep, we will do so. Otherwise, leaders will fight. <br />
<br />
In that case, we have:<br />
* between n and m recruitment list<br />
<br />
===== General behavior =====<br />
According to these different cases, we can highlight the steps AI must follow in order to place leaders correctly on map<br />
* Count the number of races we have (number R)<br />
* Count the number of keep unoccupied (number K)<br />
* If K >= R then<br />
** We will try to use of the possible keeps -> Determine <keep, leader> couple in order to occupied all keeps as quickly as possible<br />
* If R > K<br />
** Determine the quickest leader of each race<br />
** Determine <keep, leader> couple in order to occupied all keeps as quickly as possible<br />
** For the rest of them:<br />
*** Place them on keep for having a maximum of races mix on each keep<br />
* Move them on keep<br />
<br />
=== Support per-leader recruit/recall list ===<br />
<br />
==== How to tell limits to AI ====<br />
Leader's limitation is one feature I want to refactor.<br />
<br />
[ai]<br />
[recruit]<br />
unit_max="10"<br />
unit_min="2"<br />
[unit]<br />
name="Scout"<br />
[/unit]<br />
[type]<br />
name="fighters"<br />
unit_max="3"<br />
level="2"<br />
[/type]<br />
[race]<br />
name="Troll"<br />
[/race]<br />
[level]<br />
level="2"<br />
unit_max="3"<br />
[/level]<br />
[/recruit]<br />
[/ai]<br />
<br />
===== Looking at WML structure =====<br />
When we will change AI recruitment behavior or impose limits, each rules will be in a <code>recruit</code> tag. We can see different type of rules:<br />
* <code>unit</code> : can specify rules applied to a specific unit (i.e ''up to 2 scout'')<br />
* <code>type</code> : can specify rules applied to a specific type of unit (i.e. ''up to 3 fighters'' )<br />
* <code>race</code> : can specify rules applied to a specific race (i.e. ''up to 3 Trolls'')<br />
* <code>level</code> : can specify rules applied to units' level. (i.e. ''up to 3 units of levels 2+'')<br />
<br />
With these structures, AI will easily recognize what type of limit he had to follow.<br />
<br />
Key list we can also use:<br />
* '''name''' : name of a unit or a unit type. ''Cannot be use on <code>level</code>tag''.<br />
* '''level''' : specify a min level.<br />
* '''max''' : specify a maximum number of unit we can have.<br />
<br />
With only these keys, AI will choose himself which unit to recruit. Moreover, it doesn't ensure a mix of unit.<br />
If we want to change AI behavior, we can add some other key:<br />
* '''min''' : specify a minimum number of unit we should have. '''Force AI to have a certain mix of unit'''. AI will at first check if the minimum number of unit required is reached. <br />
* '''turn''' : specify on which turn AI can recruit this sort of unit. <br />
<br />
<br />
<br />
'''CONCERNING RECRUIT TAG'''<br />
<br />
As you can see in the example, ''max'' is used in the <code>recruit</code>. '''If a such a key is used in the <code>recruit</code> tag, he will be applied to all children tag.''' If, in the children tag, the key is redefined, the value will be replaced.<br />
If we look at the example, we will have a maximum of 10 scouts (and a minimum of 2) but between 3 and 2 fighters. <br />
Keys which can be used in the <code>recruit</code> must be usable in ALL children tag.<br />
<br />
'''Others key might be appearing according to scenario designers wishes'''<br />
<br />
<code>void ai_default_recruitment_stage::on_create()</code> read and memorize limits. We also need to fix it in order to have the right limits.<br />
<br />
==== Memorize limits ====<br />
In the case we can found different leader with different limitation, we will need a new attribute to the <code>unit</code> class.<br />
<br />
For saving there limitation, we can use a mapping I will explain. We know that we have different type of limitation: per level, per unit and per type. We could have three mapping for each rules, but it complicate the code for nothing. In fact, I propose a mapping like this:<br />
<br />
'''key''' {TYPE}_{NAME} - '''value''' {LIST} with the different limit name (unit_max, etc..)<br />
'''key''' {TYPE}_{NAME}_{LIMIT} - '''value''' : {INT} value of limitation<br />
<br />
If we take the previous example, we will have:<br />
'''key''' UNIT_SCOUT - '''value''' [MAX, MIN]<br />
'''key''' UNIT_SCOUT_UNIT_MAX - '''value''' 10<br />
'''key''' UNIT_SCOUT_UNIT_MIN - '''value''' 2<br />
<br />
'''key''' TYPE_FIGHTERS - '''value''' [MAX, MIN, LEVEL]<br />
'''key''' TYPE_FIGHTERS_MAX - '''value''' 3<br />
'''key''' TYPE_FIGHTERS_MIN - '''value''' 2<br />
'''key''' TYPE_FIGHTERS_LEVEL - '''value''' 2<br />
<br />
'''key''' LEVEL - '''value''' [MAX, MIN, LEVEL]<br />
'''key''' LEVEL_MAX - '''value''' 3<br />
'''key''' LEVEL_MIN - '''value''' 2<br />
'''key''' LEVEL_LEVEL - '''value''' 2<br />
<br />
This way, we can find, for each unit, each type and each level his limitation.<br />
<br />
''In the case we recruit a fighter'' (i.e), we will decrease the value of <code> '''key''' TYPE_FIGHTERS_MAX - '''value''' 3 </code> and <code>'''key''' TYPE_FIGHTERS_MIN - '''value''' 2 </code> so the AI will always know if he can recruit a specific unit.<br />
<br />
=== Recruitment strategie ===<br />
<br />
==== Choose useful unit ====<br />
In order to choose useful unit, we need to know a several things:<br />
* gold available and other limits<br />
* list of enemy's unit types<br />
<br />
These three points are the main axes on which I will work on for choosing the best unit. The idea is to have a final list of available unit mapped with a score.<br />
<br />
'''Gold available'''<br />
The gold available will give us a first list of unit we can recruit. We will it <code>UNIT_LIST</code>.<br />
<br />
'''Others limits'''<br />
According to limits scenario designers have specified, some unit will be recruited. so we don't need to analyze them.<br />
<br />
'''List of enemy's unit types'''<br />
When I am talking about a good unit, I'm talking about a unit which is efficient with the maximum of enemy unit. In order to do that, we need the complete list of enemy's unit type.<br />
Then, for each unit we can recruit, we will ''score''' them.<br />
We will create three constant: ''BAD_TYPE'', ''MEDIUM_TYPE'' and ''GOOD_TYPE''.<br />
<br />
'''And we have a list!'''<br />
The final step in to sort the list according to scores in order to have a clean list of unit we can recruit.<br />
<br />
All the algorithm need to be done once in order to have the final list. When we decide to recruit a unit, the only thing to do is to cancel unit we cannot recruit anymore according to gold.<br />
<br />
===== Scoots and village =====<br />
Scoots are very special unit. They are usually used to take villages around . The problem here is "How many scoot should be recruit?".<br />
<br />
First, we need to analyze villages. In fact, we can choose a number of scoots according to the number of villages, but it's seems not be a good solution. Some unit can take villages if they are on there way.<br />
<br />
http://ar.chroot-me.in/random/wesnoth/scheme.png<br />
<br />
Let's take the situation above. The blue zone represent the fastest way between the two castles. We can make the supposition that it's the way unit will take to attack the enemy. So it might be useless to create one or more scoots to capture villages in this zone while units on it can capture them without losing to much time.<br />
<br />
At least, we will have two zones to explore: zone A and B. The two of them will be explored in the same way.<br />
<br />
We will seek to create a graph on which each vertex will be a village. To simplify the algorithm, and also make more sense, we won't consider ALL villages. In fact, nobody could take all villages before the opponent. It makes same to consider the 60% of them regarding to our castle.<br />
To find edges, we will calculate the shortest path between each village. Finally, we will have N shortest path according to the number of final vertices in the graph.<br />
The distance between villages can be the factor to determine edges.<br />
<br />
The number of scoots necessary will be N.<br />
<br />
<br />
'''How to determine the blue zone'''<br />
The blue zone represent the straight line between two castle with a width we will fix. With the location of the two castle, it would be easy the determine the straight line formula.<br />
<br />
==== MinMax ====<br />
In order to make an effective counter-recruiting, an idea will to implement an 2-depth minmax algorithm.<br />
<br />
In order to make it, AI needs to cheat a little (all AI cheat... no?) in order to know what the player can recruit.<br />
<br />
This algorithm works very well, but has some negative points:<br />
* he can be a little slow... but it will be ok for a 2-depth algorithm.<br />
* depends on the formula. If the formula is precise, the algorithm will have better result.<br />
<br />
For the formula, according to my experience (I implemented it last year), it's the game experience which will give it. In fact, it can be precise if we don't play. The main question we need to answer is ''When I am in a good situation or in a bad situation?''.<br />
<br />
If it works well, it can also solve few problem of recruitment:<br />
* Knowing how much unit type recruit according to a situation<br />
* Not spend all gold for nothing<br />
* Not overestimating the value of high-level recruits<br />
* Recruit more suitable unit for the terrain<br />
<br />
===== Formula =====<br />
In order to choose the recruitment list, we need to know a few things:<br />
* '''number of specific enemy unit type''' and '''number of unit we already have''' <br />
In order to know how much unit AI must recruit, we must calculate a good number of unit which are enough to attack the enemy.<br />
For the moment, we will try to take the same number of unit as the player. So we can image a basic formula like<br />
<br />
number of enemy - number of ally<br />
if >0 '''recruit!'''<br />
else '''not recruit'''<br />
<br />
* '''the level of enemy's unit''' and '''number of these unit'''<br />
In fact, if we have a 3 level enemy unit, one 1 level unit isn't enough to face it. So the level is an important point to considerate.<br />
In fact, a level 3 unit is stronger than a level 1, but 3 level 1 unit have probably a better lifetime than a level 3. So we need to link both facts.<br />
<br />
* '''Terrain''' <br />
Unit are more or less better according to the terrain. But, before that, we need to know "Which terrain should I analyze?".<br />
An idea which sounds good is to analyze terrain which is between two keeps. In fact, the battle will be there.<br />
For that, we will need to know keep's location (A way to do this is to search leaders -> if they can recruit, they are on keep). Then, calculate an average estimation of the location between the two keeps and then, choose a value x and y for having a zone to analyze.<br />
In order to analyze it, we can do a mapping <terrain, percentage> so we can have an idea of the terrain.<br />
Here again, we will attribute to the current unit score values according to terrain. We can also use the previous constant: ''BAD_TYPE'', ''MEDIUM_TYPE'' and ''GOOD_TYPE''.<br />
<br />
==== Working on several recruitment list ====<br />
===== General idea =====<br />
Before speaking about the general idea, we should highlight the problem here.<br />
<br />
We have a list of unit associated to a score which represent their utility for the current situation. But now, we need to know two things: ''Which unit recruit?'' and ''Which leader should recruit it?''. In order to do that, we will looking at the current situation for EACH leader and for EACH unit.<br />
<br />
In fact, depending on the leader, the unit utility can change. So we will work on each unit separately and attribute it directly to the best leader. <br />
<br />
When we choose to recruit one unit, we must not forget to taken it into account for the next one. Otherwise, AI will choose the same unit indefinitely.<br />
<br />
==== Current Code? ====<br />
<br />
= Practical considerations =<br />
<br />
When using a PPO language, I like using an application like Eclipse. It's very usefull and I can be faster with it. Otherwise, I simply use vim in a shell.<br />
I really like PPO language like JAVA. JAVA is obviously the language I have more experience with.<br />
Moreover, I coded in c, c++, python, prolog and I think it's all.<br />
<br />
* Subversion - I have my own svn.<br />
* C++ - I developed in c++ some years ago but I will remember since the start of GSoC<br />
* STL, Boost, Sdl - never used.<br />
* Python - I know it, used some times.<br />
* build environments - I know cmake but not scons<br />
* WML - no :(<br />
* Lua - neither.</div>Ejlshttps://wiki.wesnoth.org/index.php?title=Soc2012_Talbot_Pierre_Refactor_Recruitment_Algorithm&diff=46480Soc2012 Talbot Pierre Refactor Recruitment Algorithm2012-04-16T02:57:33Z<p>Ejls: SummerOfCodeIdeas-fication</p>
<hr />
<div>{{SoC2012Student}}<br />
[[Category:SoC_Ideas_AI_Recruitment_2012]]<br />
<br />
=Latest Edit=<br />
<br />
Edit 07/04: <br />
* WML recruiting parameterisation update. Add examples and explanations.<br />
* Update of the "multiple leaders" section.<br />
<br />
Edit 09/04:<br />
* Add a paragraph in "Recruiting better units" following a [http://forum.wesnoth.org/viewtopic.php?f=8&t=36571&p=525919#p525846 discussion on the forum].<br />
* Change few specifications in the "WML recruiting parameterisation" section.<br />
<br />
Edit 11/04:<br />
* Add a section "further improvements".<br />
* Modify the introduction of the question 4.5.<br />
<br />
Edit 13/04:<br />
* Add leader classes (example).<br />
<br />
Edit 14/04:<br />
* Add a section in "Recruiting better units": Group analysis.<br />
<br />
Edit 15/04:<br />
* Add a section in "Recruiting better units": Village analysis.<br />
<br />
=Description=<br />
<h4>Talbot Pierre - Refactor Recruitment Algorithm</h4><br />
<br />
The current recruitment algorithm is based on a WML recruitment pattern which specify the recruitable units. Apart for scout, no real strategy is established because most of the units are chosen randomly from this pattern list.<br />
<br />
I'll dedicate my summer around three axes:<br />
<br />
* Multiple leaders: We must manage a list of leaders and free keeps, to affect each leader to a keep and change it if needed (because it's too far from the battle...). AI should choose where an unit (on which castle) will be recruited to be more efficient, taking into account the number of enemy units and their weaknesses.<br />
<br />
* Recruiting better units: The units must be chosen for a specific purpose such as getting a village, fighting a specific unit, protecting another... AI should be able to keep in mind the original purpose of an unit to take further decisions. By the way, this design should be discuss with the community and the other GSoC participants because it has a large impact on the entire AI.<br />
<br />
* WML parameterisation: The recruitment pattern will be improved to allow scenario editors to be more specific on which units should be recruited.<br />
<br />
=IRC=<br />
trademark<br />
=SoC Application=<br />
Submitted to google<br />
<br />
=Questionnaire=<br />
===1) Basics===<br />
<br />
====1.1) Write a small introduction to yourself.====<br />
<br />
My name is Pierre Talbot, I'm 20 year old. I didn't discovered the programming when I was young, such we often see. Before I dive into this beautiful world I played a lot. I made the most important step in my life 3 years ago when I began my studies.<br />
<br />
====1.2) State your preferred email address.====<br />
<br />
ptalbot [at] mopong (dot) net<br />
<br />
====1.3) If you have chosen a nick for IRC and Wesnoth forums, what is it?====<br />
<br />
trademark<br />
<br />
====1.4) Why do you want to participate in summer of code?====<br />
<br />
It's for two main reasons, the first is the money. The second is to move forward my dream to become<br />
a game programmer specialised in artificial intelligence.<br />
It's also to meet new people and to discuss around a common passion. It would be the first time I code<br />
for a project of this size, I think it's a necessary step to go beyond the programmer amateur and be ready for the real world.<br />
<br />
====1.5) What are you studying, subject, level and school?====<br />
<br />
I'm finishing this year my B.Sc. in Computer Science at the University of Claude Bernard Lyon 1.<br />
<br />
====1.6) What country are you from, at what time are you most likely to be able to join IRC?====<br />
<br />
I'm from France, so I'll be able to join IRC between 3 am UTC and 6 pm UTC. I'll be the most responsive during in the morning.<br />
<br />
====1.7) Do you have other commitments for the summer period ? Do you plan to take any vacations ? If yes, when.====<br />
<br />
I have an internship during the summer, from may to august. I discussed about it with Crab_ on IRC, I asked him if it was feasible and he helps me to do a long term planning. <br />
<br />
I'll get up early, around 4-5 am UTC+2 and I will work for Wesnoth until 9 am UTC+2. Without any distraction and with my fresh and rested head. My internship will begin at 10 am UTC+2 and finish at 6 pm UTC+2. I'll go to sleep around 8 pm UTC+2.<br />
<br />
The week will be dedicated to code functionalities and the week-end will be reserved to rest myself up and to think about the code design of the next week. <br />
<br />
I'm used to work a lot and all the day, my motivation can defeat the rules of time.<br />
<br />
===2) Experience===<br />
<br />
====2.1) What programs/software have you worked on before?====<br />
<br />
I mainly developed short programs for school purpose such as a chess-game in C++, a pong and a naval battle in C, an adaptation of the well-known board game "Jungle Speed" in Java. I also code few data structures module such as Hash map, Tree, List,... but also the skip-list, Red-black tree in C. I'm used to work with graph and graph algorithm in C++.<br />
<br />
I often code short and efficient programs because I like participate in programming contest. I'm participating for the second year in Prologin, which is an algorithmic French contest. The final is a 36 hours contest where the finalists must code an artificial intelligence of a given subject. I also prepare myself for the regional ACM-ICPC contest in 2012.<br />
<br />
====2.2) Have you developed software in a team environment before? (As opposed to hacking on something on your own)====<br />
<br />
Most of the projects I spoke before were in team of 2 or 3 peoples and we used version control software.<br />
<br />
====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?====<br />
<br />
Yes, I participated as a student in 2011. It was my first real experience. I was accepted in the Boost C++ Library organisation to design and code a check digit verification and computation library oriented "human-error". For example, your credit card number or the ISBN in the back of a book have a check digit. It's not for transmission error control purpose, these checksums are designed to control the human encoding errors.<br />
<br />
I successfully finished the summer and continued to develop and work on it during the year studying permitting. My contribution to this organisation is not done yet and I will continue to prepare my library for a Boost review.<br />
<br />
I gain a lot of experience in C++ and mostly with some Boost library such as MPL, Test, Iterator, Phoenix, Preprocessor, Range, and all the others I've forgotten that made the programmer life easier. I studied these libraries to be sure to do the most generic library as I can. I also learned to use the Boost chain-tools to document and test.<br />
<br />
My mentor was Paul Bristow and we regularly keep in touch since the beginning of GSoC, feel free to contact him here : pbristow [at] hetp.u-net (dot) com.<br />
<br />
====2.4) Are you already involved with any open source development projects? If yes, please describe the project and the scope of your involvement.====<br />
<br />
No.<br />
<br />
====2.5) Gaming experience - Are you a gamer?====<br />
<br />
I was what we called a "real" gamer few years ago. I play a lot less now as my interests has slipped into the programming. Anyway I love games and this passion will never pass away.<br />
<br />
=====2.5.1) What type of gamer are you?=====<br />
<br />
I'm a gamer who hasn't played a lot of different games. I prefer plays online because I love the competition and progress with my rank.<br />
<br />
=====2.5.2) What type of games?=====<br />
<br />
* Strategy : 400 hours in Warcraft III, rank 647 in Free For All and rank 630 in Arranged team 3vs3.<br />
* CCORPG : 3600 hours in Guild Wars over 4 years. Best rank 497 in 1vs1 (PvP, mode Hero vs Hero).<br />
* FPS : Call of duty 4.<br />
* Race : 100 hours in Trackmania.<br />
<br />
There are my prefered games. Currently, when I really need a break, I like to play COD4.<br />
I also played few others games I didn't mention because I didn't play these much.<br />
<br />
=====2.5.3) What type of opponents do you prefer?=====<br />
<br />
In my good days, I like the opponent who defeats me, so I can learn from my losses and improved my technical skills.<br />
<br />
In my bad days, I don't like to lose and I just want to win. Contradictorily, I don't win a lot these days.<br />
<br />
=====2.5.4) Are you more interested in story or gameplay?=====<br />
<br />
When I don't play online, I think the story is important and I like to enjoy the mainline story.<br />
''A contrario'', when I play online, I prefer a balance gameplay which allow you to create new strategy.<br />
<br />
=====2.5.5) Have you played Wesnoth? If so, tell us roughly for how long and whether you lean towards single player or multiplayer.=====<br />
<br />
I started the campaign and I finished few scenarios. I played about 5 hours. I also played online in a custom game. I'm not good enough to play online as I don't know the units and the strategy used (I've started to watch game replay of experienced gamers).<br />
<br />
====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.====<br />
<br />
A bug: [https://gna.org/bugs/?19538 Bug #19538].<br />
<br />
While I read the code I improved a function and did a patch: [https://gna.org/patch/?3236 Patch #3236].<br />
<br />
===3) Communication skills===<br />
<br />
====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.====<br />
<br />
I only write my program in English (even if there are unimportant) and I document them in English as well. I haven't problem to discuss in English.<br />
<br />
====3.2) What spoken languages are you fluent in?====<br />
<br />
French.<br />
<br />
====3.3) Are you good at interacting with other players? Our developer community is friendly, but the player community can be a bit rough.====<br />
<br />
I know how the gamers can be, and mostly when they are experimented. I'll try to do my best to be, as soon as possible, an experienced gamer. I treated guys of noob and be treated as well, I've been on the both side so I know what is good to say or not.<br />
<br />
====3.4) Do you give constructive advice?====<br />
<br />
I'm member of a French forum "Developpez.com" where I give advices and help people. I'm not always good but I try to respond with precision and completeness, I want to show them all the possible tracks I know.<br />
<br />
====3.5) Do you receive advice well?====<br />
<br />
I have difficulties to receive advices from guys of the same level as me, I'm reluctant to follow their ideas if I don't see what's the aimed or the improvement. <br />
<br />
From my mentor or an experienced coder, I follow the ideas more easily because I trust them. Anyway, whatever the advices is it, I try to keep my critical. For example, I change my coding style the last year for Boost, I indent with 2-spaces instead of a tab now.<br />
<br />
====3.6) Are you good at sorting useful criticisms from useless ones?====<br />
<br />
I think so, because, as explain above, I only fully consider criticisms I understand well.<br />
<br />
====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====<br />
<br />
I like to lay down on paper my ideas to be clear. If I'm really not sure about something, I'll ask for help on IRC, forum,... Otherwise, I code it. I have difficulties to thrown away my code, but I have the feeling that is a better way to take a decision. It's a debate in my head and I'll try to code sooner to "see how it turn out".<br />
<br />
===4) Project===<br />
<br />
====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?====<br />
<br />
I'll answer to be general and than specific. Firstly, I choose this organisation because I'd to be a game programmer and I love strategy game. I choose to do my proposal on the AI part. I'm interested by a project in your list: "AI: Refactor Recruitment Algorithm".<br />
<br />
====4.2) If you have invented your own project, please describe the project and the scope.====<br />
<br />
I just create an amateur-project with a friend. It started as a school project, the idea was a Pong with N players where the game board is a geometric form with N sides. We haven't finished it yet, we started it in C with SDL (school limit). We want to code it in C++ with oriented-object paradigm, we need to rethink the application and draw the class diagram, we're currently analysing it with the knowledge of our previous implementation.<br />
<br />
====4.3) Why did you choose this project?====<br />
<br />
I choose it because the recruitment is the basis of every strategies and everything remains to be in the current implementation. I think it's such a playground where I can implement all the theory I learn, for example, to practice the data structure and graph theory.<br />
<br />
====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".====<br />
<br />
As I would like to work on this project even if it's not in a GSoC context, the timeline is not exclusively limited to the GSoC period. Anyway the deadlines of GSoC are taking into account.<br />
<br />
{| style="border:1px dashed #AAA;border-collapse:collapse;"<br />
|-<br />
!style="border:1px dotted #AAA;padding:5px;"|Date<br />
!style="border:1px dotted #AAA;padding:5px;"|Description<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|April<br />
|style="border:1px dotted #AAA;padding:5px;"|Discover the code, design on paper the current implementation and understand most of the relation between classes... Play a lot and get confident to speak with experienced players.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|01/05 to 20/05<br />
|style="border:1px dotted #AAA;padding:5px;"|Implement the first improvement: "Multiple leaders management", test it with the AI arena and understand the code more in depth.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|21/05 to 11/06<br />
|style="border:1px dotted #AAA;padding:5px;"|Start the coding period. Code the recruitment of units more useful and adapted to the environment. Adapt the code to avoid counter-recruiting, and manage the gold to not necessarily spend it all.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|12/06 to 09/07<br />
|style="border:1px dotted #AAA;padding:5px;"|Support new WML markup, getting closer the scenario editors and the community to understand what should be configurable. What are they thinking it's the most useful ?<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|10/07 to 01/08<br />
|style="border:1px dotted #AAA;padding:5px;"|Code and design new members for units to allow them to have a specific goal. A unit should be recruited with a hint of his goal for the other AI part. This should be done in collaboration with the other GSoC student and the community.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|02/08 to 24/08<br />
|style="border:1px dotted #AAA;padding:5px;"|Fully test and document what is not done yet. Discuss with experienced gamers and community about the future improvement and taking into account their advices for the current (and new) recruiting algorithm.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|24/08 to ...<br />
|style="border:1px dotted #AAA;padding:5px;"|Continue to improve and implement new functionalities. I'll continue to work on it studying permitting.<br />
|}<br />
<br />
====4.5) Include as much technical detail about your implementation as you can====<br />
<br />
There are few points to refactor. I'll use piece of codes from the current recruitment algorithms:<br />
<br />
* <tt>ai_default_recruitment_stage</tt> (ai/default/ai.*) ;<br />
* <tt>recruitment_phase</tt> (ai/testing/ca.*) ;<br />
* <tt>testing_recruitment_phase</tt> (ai/testing/ca_testing_recruitment.*).<br />
<br />
As suggested by Crab_ on IRC, I'll work with the class <tt>testing_recruitment_phase</tt>, the entry in register.cpp is already done.<br />
<br />
During this summer, I'll concentrate my coding around three axes:<br />
<br />
* Recruiting with multiple leaders;<br />
* Recruiting better units according to the environment (enemy units, terrain, gold, villages, counter-recruiting,...);<br />
* Allow WML parameterisation for the recruitment, mainly for scenario editors.<br />
<br />
A distinction between the internal algorithm and the WML parameterisation must be made. The default choices made by the AI is specified with the two first points. The WML is elaborated with the scenario editors, and will interfere with the internal algorithm. An objective will be to distinct both, and document what the WML user can change. The birth of the new interactions with the current algorithm will be made in collaboration with the WML users on forum or IRC.<br />
<br />
<br />
=====Recruiting with multiple leaders=====<br />
<br />
During the evaluation phase, BAD_SCORE is returned if the first leader is not on keep, if the castle is full or if there is no leader available.<br />
During the execution phase, only one leader location is considered.<br />
<br />
This is rudimentary, it should at least consider multiple leader. For the moment, if a leader is on the keep BUT is not the first in the internal list, the AI can't recruit this turn.<br />
<br />
See the current code:<br />
<br />
<tt><br />
double recruitment_phase::evaluate()<br />
{<br />
const unit_map::const_iterator leader = resources::units->find_leader(get_side());<br />
if(leader == resources::units->end()) {<br />
return BAD_SCORE;<br />
}<br />
if (!resources::game_map->is_keep(leader->get_location())) {<br />
return BAD_SCORE;<br />
}<br />
std::set<map_location> checked_hexes;<br />
checked_hexes.insert(leader->get_location());<br />
if (count_free_hexes_in_castle(leader->get_location(), checked_hexes)==0) {<br />
return BAD_SCORE;<br />
}<br />
return get_score();<br />
}<br />
</tt><br />
<br />
Could be easily transform to something like:<br />
<br />
<tt><br />
double recruitment_phase::evaluate()<br />
{<br />
std::vector<unit_iterator> leaders = resources::units->find_leaders(get_side());<br />
<br />
foreach(const unit_iterator& unit_it, leaders) <br />
{<br />
// If the current leader is on the keep.<br />
if(resources::game_map->is_keep(unit_it->get_location()))<br />
{<br />
std::set<map_location> checked_hexes;<br />
checked_hexes.insert(unit_it->get_location());<br />
// If there is enough space on the castle.<br />
if (count_free_hexes_in_castle(unit_it->get_location(), checked_hexes) != 0)<br />
return get_score();<br />
}<br />
}<br />
return BAD_SCORE;<br />
}<br />
</tt><br />
<br />
Furthermore, we create a class dedicate to the management of multiple leaders.<br />
<br />
<tt><br />
class leaders<br />
{<br />
// Units to recruit sorted by importance.<br />
std::priority_queue<recruit_unit> recruit_list;<br />
<br />
// The leaders who are on the keep.<br />
std::vector<leader> leaders_on_keep;<br />
<br />
// The different recruit lists of all leaders are merged into a single one.<br />
// Each recruit_unit have an unique map_location (on the keep) and are sorted by importance.<br />
void merge_recruit_list();<br />
<br />
void find_leaders_on_keep();<br />
<br />
public:<br />
<br />
leaders();<br />
<br />
// Functions to access the recruits.<br />
// ...<br />
};<br />
</tt><br />
<br />
Each leader are treated separately and have their own recruit list. The class <tt>leaders</tt> is used to merge <br />
the different lists.<br />
<br />
<tt><br />
class leader<br />
{<br />
// The recruit list sorted by importance.<br />
std:priority_queue<recruit_unit> recruit_list;<br />
<br />
// The location of the leader.<br />
map_location where;<br />
<br />
// Build the recruit list.<br />
build_recruit_list();<br />
<br />
public:<br />
// pre: loc must be a keep.<br />
leader(map_location &loc);<br />
<br />
// Functions to access the recruits.<br />
// ...<br />
};<br />
</tt><br />
<br />
We use a POD struct to describe a unit to recruit.<br />
<br />
<tt><br />
struct recruit_unit<br />
{<br />
// Where the unit will be recruited. (Must be on a castle).<br />
map_location where;<br />
<br />
// The name of the unit to recruit.<br />
std::string unit;<br />
<br />
// The importance of this recruitment.<br />
int importance;<br />
<br />
// The objective of this unit. It should be interesting for the other AI (why did we recruit this unit ?).<br />
std::string objective;<br />
};<br />
</tt><br />
<br />
The objective and importance lead us to the second point of this proposal: "Recruiting better units".<br />
<br />
=====Recruiting better units=====<br />
<br />
The recruitment is the basic of every strategies and so we must first analyse the unit, the terrain, the villages on the map to take the best decisions.<br />
<br />
======Groups analysis======<br />
<br />
If we are able to see the groups of enemy and ally, we are able to recruit a suitable unit to fight well against the group, or at least, the most number of units in this group. The detection of the different group on the map is not easy because we must defined a "group". I propose a definition which could change over the time and the results:<br />
<br />
"A group contains a designate father, the father is the unit who has the most units around him within his own range. If a unit cannot protect the father because it's too far, it is excluded from the group, and even if the father can protect this unit. A group could contain only one unit, who is its own father. A unit cannot belong to more than one group."<br />
<br />
Concretely, the groups are represented as a disjoint set and the union-find algorithm naturally represent the situation. The class below represents the groups, it's only a prototype and so will probably be modified later.<br />
<br />
<tt><br />
class groups<br />
{<br />
int side;<br />
<br />
// Each unit have a unique id.<br />
std::map<int, map_location> units_id;<br />
<br />
// disjoint_set[i] = j where i the unit_id and j the father.<br />
std::vector<int> disjoint_set;<br />
<br />
// The id of the fathers. (Useful for iterate over the groups).<br />
std::set<int> fathers;<br />
<br />
// For each unit in the side "side", a id is affected and registered in units_id.<br />
void assign_unique_id();<br />
<br />
// Initialize the fathers, all units are their own father.<br />
void init_fathers();<br />
<br />
// returns: The number of unit around loc. (With the father rules).<br />
int count_unit(map_location &loc);<br />
<br />
// Assign the real father of each units.<br />
// It uses a priority queue with all the units inside and sorted with the count_unit function.<br />
// While it's not empty: if the unit extracted is not a member of a group (use find operation),<br />
// it's a father and all units considered like it are now member of the group (union operation).<br />
void process_fathers();<br />
<br />
void union(int i, int j);<br />
void find(int i);<br />
<br />
public:<br />
<br />
// The group structure is built for the side "side".<br />
groups(int side);<br />
<br />
// Iterators: We can iterate over the groups and over the unit of a group.<br />
class group_iterator<br />
{<br />
// Examples:<br />
groups::unit_iterator operator*(group_iterator& iter);<br />
void operator++();<br />
// ...<br />
};<br />
<br />
class unit_iterator<br />
{<br />
map_location operator*(unit_iterator& iter);<br />
// ...<br />
};<br />
<br />
group_iterator begin();<br />
group_iterator end();<br />
<br />
// We can provide operator [] to access a group.<br />
unit_iterator operator[] (size_t index);<br />
};<br />
</tt><br />
<br />
The goals of the groups are:<br />
<br />
* Recruit units to reinforce a ally group who is weaker than the enemy group it's facing.<br />
* Recruit units to form a group fighting against a specific enemy group.<br />
* With the groups, the AI should be able to elaborate elegant strategies.<br />
<br />
We must analyse the group and which group is fighting against another. We'll use a class <tt>group_analysis</tt> which contains all the groups of all sides and link the group fighting against the other to build a ''graph'' of all the groups. The edges contains the distance so we'll have a better overview of the battleground.<br />
<br />
======Villages analysis======<br />
<br />
Without villages, none of any strategies can't be set up. I propose an analyse of the village which try to recruit the best units to capture villages. I try that this analyse is not only effective in the beginning of the game.<br />
<br />
In a first time, we divide the map into three zones:<br />
<br />
with i the village, j our castle and k the enemy castles.<br />
<br />
* Ally: The distance between i and j is shortest than between i and k.<br />
* Neutral: The distance between i and j is equals than between i and k.<br />
* Enemy: The distance between i and j is longer than between i and k.<br />
<br />
We calculate paths which maximize the number of villages that scouts can reach in the minimum turns. The paths don't contain a same village.<br />
<br />
From each vacant tiles on the castle, a path is calculated and goes by all the villages on the map. It's an optimisation problem: the travelling salesman. We don't want a village in more than one path and we apply the following algorithm:<br />
<br />
# We initialise a graph G containing only the castle's tiles node. <br />
# In a priority queue V, we sort all the villages by the distance (the distance sum from each available castle's tiles).<br />
# While V is not empty: we connect the village extracted to the closest node in G.<br />
# G contains all the paths from each castle's tiles.<br />
<br />
Furthermore, the villages which are already ours are removed from V. And the distance to go to the villages which belong to the enemy or in a enemy zone are doubled only if enemies are around those villages.<br />
<br />
The maximum edge on a path indicate us the unit to recruit, we are not forced to recruit a unit who is a scout if it's more useful and can do the job of the scout and fighting well.<br />
<br />
A problem could appear. It's not our responsibility to move the unit and to follow the path indicated. So even if we recruit units for a specific objective, we cannot be sure that other AI will understand it this way... We need a way to communicate, and it's bring us to the next improvement: "Unit's objectives".<br />
<br />
======Unit's objectives======<br />
<br />
Each units should have a goal, for example, getting a village, kill a specific category of units, block others (these ideas join other proposals so we'll need to work and discuss together about these parts). It will be implemented such a "hint" member filled during the recruitment process and modify if needed during the next phases and by the other AI. With this hint, an unit is never without goals and further decisions are easier to take. It's a good way to have more than one turn ahead.<br />
<br />
For example, we can recruit a unit for:<br />
<br />
* Help a specific group at the location x.<br />
* Capture villages following the path y.<br />
* Protect a unit.<br />
* ...<br />
<br />
=====WML recruiting parameterisation=====<br />
<br />
The scenario editors would like to control more easily the recruitment phase. WML markup can be implement and the recruitment pattern modify.<br />
<br />
I opened [http://forum.wesnoth.org/viewtopic.php?f=8&t=36571 a post] on the forum to discuss with the scenario editors my ideas.<br />
<br />
I'll start with some examples before diving into the specification details.<br />
<br />
Firstly, if you want to recruit two scouts in the first turn and two in the second turn, you currently must "play" with the tag <tt>modify_ai</tt> in an event tag and add a "delete action" when the second turn is over. If you want to recruit again during the fifth and sixth turns, you must open a <tt>modify_ai</tt> tag and write an "add action". Let's now watch the first simple example:<br />
<br />
[ai]<br />
[aspect]<br />
id=recruitment<br />
[facet]<br />
[recruit]<br />
id=scout_first<br />
type=scout<br />
number=2<br />
turns=1,2<br />
[/recruit]<br />
[/facet]<br />
[/aspect]<br />
[/ai]<br />
<br />
It's naturally simple and we can read it: "Recruit 2 scouts during the turn 1 and 2".<br />
<br />
Now, we would like to recruit scouts such as above with 3 fighters during the start of the battle with the constraint that we want to recruit the scouts first and if possible the fighters next.<br />
<br />
[ai]<br />
[aspect]<br />
id=recruitment<br />
[facet]<br />
[recruit]<br />
id=scout_start<br />
type=scout<br />
number=2<br />
importance=2<br />
turns=START<br />
[/recruit]<br />
[recruit]<br />
id=fighter_start<br />
type=fighter<br />
number=3<br />
importance=1<br />
turns=START<br />
[/recruit]<br />
[/facet]<br />
[/aspect]<br />
[/ai]<br />
<br />
During the first turn, the AI will firstly recruit the two scouts because the key <tt>importance</tt> is set on 2 whereas the <tt>importance</tt> of the fighters is set on 1. So if AI have enough gold and there is enough free space on the castle, it will recruit the fighters until one of these two conditions failed or that we have three fighters. Note that these conditions are also valid for the scouts. You could have noticed the new keyword <tt>START</tt> saying the we want to recruit only in the start of the battle.<br />
<br />
I can introduce an interesting application of all we said. Assuming that we want to develop a survival mode and the AI generates the wave of enemies. We'll say that the AI have unlimited gold:<br />
<br />
[ai] <br />
[aspect]<br />
id=recruitment<br />
[facet]<br />
[recruit]<br />
id=scouts_recruit<br />
type=scout<br />
number=2<br />
[/recruit]<br />
[recruit]<br />
id=fighters_recruit<br />
type=fighter<br />
number=1<br />
increment=1<br />
turns=2-END<br />
[/recruit]<br />
[/facet]<br />
[/aspect]<br />
[/ai]<br />
<br />
<br />
In the first wave, there are only two scouts recruited.<br />
In the second wave, two scouts plus one fighter are recruited.<br />
In the n wave, two scouts plus (n-1) fighters are recruited.<br />
<br />
The importance is not specified as we already know that the AI have unlimited gold (so the AI won't have to choose between potential recruits).<br />
We didn't specify the turn either, so it takes the default value "" which means "for all turns".<br />
The tag "increment" is equal to 1, for each turn, an additional unit will be recruited. In the example above, a fighter will be recruiting at the turn 2, but at the turn 3, 2 fighters will be recruited and etcetera.<br />
<br />
After this first possibilities draft, I'll describe the functionalities.<br />
<br />
======Inside a recruitment facet======<br />
<br />
Each recruiting options are specified into a <tt>[recruit]</tt> tag.<br />
Inside this tag the following key can be used:<br />
<br />
* id: Important if you need to access it later to modify it.<br />
* type="": (string) This key takes a comma separated list containing the usage or the type of the units that can be recruited. Common usages are: 'scout', 'fighter', 'archer', 'healer' and 'mixed fighter'. If both type and usage are specified, the usage will be considered first, if the type is a subset of an usage, it will be ignored. Otherwise, both are considered. An empty string tells the AI to recruit units according to the internal recruitment algorithm. A <tt>random</tt> value means to recruit randomly all type of units.<br />
* number=1: (integer) A number greater than 0 will tell the AI to recruit <tt>numbers</tt> units of type <tt>type</tt> for each of the turns specified in <tt>turns</tt>. The <tt>INF</tt> token can be specify to recruit as much units as we can. If there are other <tt>recruit</tt> tags with lower importance, there will never be executed.<br />
* increment=0: (integer) <tt>number</tt> is incremented by <tt>increment</tt> for each turns specified in <tt>turns</tt>. If increments=3, number=1 and turns=1, 2 than one unit will be recruited during the first turn and four (1 + 3) during the second turn.<br />
* turns="": (string) This key takes a comma separated list containing number specifying the turns. If an unit should be recruited during the turn 1, 2 and 3, the string should be "1, 2, 3". The macro <tt>START</tt>, <tt>MIDDLE</tt> and <tt>END</tt> can be used, <tt>START</tt> tell the AI to recruit during the first "1/10" of the total turns, and <tt>END</tt> during the last "1/10". <tt>MIDDLE</tt> recruits units after <tt>START</tt> and before <tt>END</tt>. A range is specify with the token '-' between two values, for example: 1-3 means "recruit during the turns 1, 2 and 3". It can be used with <tt>START</tt> and <tt>END</tt>, but <tt>START</tt> must be the left value and <tt>END</tt> the right value.<br />
* importance=0: (integer) The importance of a recruitment tells the AI to firstly recruit units with the highest importance. If gold is lacking or the castle is full, only the most important units will be recruited, the other will be dropped. The increment key will not be applied if the AI cannot recruit all the units specified by <tt>number</tt>. If two units are equally important, the AI will choose one according to his internal recruitment algorithm.<br />
<br />
======Tips======<br />
<br />
* Fill castle if it's not full: The default behaviour is recruiting only the units pattern specify in the <tt>recruit</tt> tag. You should want to fill the vacant tiles of the castle with random units and with the gold remaining. You can easily do this with:<br />
<br />
[ai]<br />
[aspect]<br />
id=recruitment<br />
[facet]<br />
[recruit]<br />
id=fill_random<br />
type=random<br />
number=INF<br />
[/recruit]<br />
[/facet]<br />
[/aspect]<br />
[/ai]<br />
<br />
======Further improvements======<br />
<br />
If the time doesn't fly away too fast during this summer, I would like to add a <tt>objective</tt> key to specify the goal of a unit. Some values could be <tt>get_village</tt>, <tt>defend</tt>, <tt>attack</tt>, etc. It could eventually takes more than one value if an objective is completed. A unit would be "tagged" with this objective during all its life time.<br />
<br />
<br />
<br />
I've no experience in editing campaign or using the WML markup language, so I'll actively work with the community to do something nice and easy to use. For my part, I'll continue to read the WML documentation and I hope, develop my own AI with these new tags.<br />
<br />
====4.6) What do you expect to gain from this project?====<br />
<br />
Some new skills to work on a large project with dozens of developers. To move forward my dream to develop AI in game programming and to improve my C++ code and design.<br />
<br />
====4.7) What would make you stay in the Wesnoth community after the conclusion of SOC?====<br />
<br />
If you permit it, I'd like to say what would make me leave after GSoC. If the developer community is not friendly or dead, I won't be able to continue to work on this project, but as I've seen this week, it's not happening. Secondly, if I a personal event occurs so I can't maintain my part of code.<br />
<br />
I'm ready to continue and develop again for Wesnoth after the Summer period. As I mention before, I'd like to develop even if it's not in a GSoC context.<br />
<br />
===5) Practical considerations===<br />
<br />
====5.1) Are you familiar with any of the following tools or languages?====<br />
<br />
* Subversion: Yes, I used it during my previous GSoC. For my personal projects, I'm using git.<br />
* C++: My level is correct, I can easily debug and understand the concept and features of this language.<br />
* STL, Boost, Sdl: I know a large part of the STL and some libraries from Boost (MPL, Phoenix, Range,...). I used very few the SDL during a C project.<br />
* Python (optional, mainly used for tools): I wrote one project with it: a SAT solver.<br />
* build environments (eg cmake/scons): I recently used these to compile Wesnoth, but I need to learn deeply how they work (add file,...).<br />
* WML (the wesnoth specific scenario language): I read the manual and some files' campaign.<br />
* Lua (used in combination with WML to create scenarios): No.<br />
<br />
====5.2) Which tools do you normally use for development? Why do you use them?====<br />
<br />
I'm using VIM and g++, because they are open-source, light and everything is in the terminal, so I rarely quit my keyboard to use the mouse. I'm using git because there are local commit and branches.<br />
<br />
However I also programmed under Visual Studio the last year.<br />
<br />
====5.3) What programming languages are you fluent in?====<br />
<br />
C++ mostly but also C and Java.<br />
<br />
====5.4) Would you mind talking with your mentor on telephone / internet phone?====<br />
<br />
I'll let you my number in the official form but I'm not very confident in my comprehension and speaking. However, if you speak clearly, it should be alright.</div>Ejlshttps://wiki.wesnoth.org/index.php?title=User:Ejls/GSoC_2012/Whiteboard_Backend_Refactoring&diff=46377User:Ejls/GSoC 2012/Whiteboard Backend Refactoring2012-04-10T02:41:39Z<p>Ejls: typo</p>
<hr />
<div><!--<br />
Excuse the heavy wikitext, I tried to make it as readable as possible and I put a lot of comments.<br />
-->__NOTOC__<!--<br />
-->__NOEDITSECTION__<!--<br />
-->{{SoC2012Student}}<!--<br />
-->[[Category:SoC_Ideas_Whiteboard_Backend_Refactoring_2012]]<!--<br />
-->'''''Note: This proposal is in continuous construction, if you have any remark, please drop me a line on IRC or on the [[{{TALKPAGENAME}}|talk page]].'''''<br /><br /><br />
<br />
<!--***********************************************************************<br />
* * Table of Content * *<br />
* ******************** *<br />
* *<br />
* WARNING: don't forget to add a TOC entry when adding a new section. *<br />
***********************************************************************--><br />
{|style="background:#FAF3E9;margin:none;padding:5px;border:3px double #AAA;-moz-border-radius:20px 5px 20px 5px;-webkit-border-radius:20px 5px 20px 5px;border-radius:20px 5px 20px 5px;"<br />
|-<br />
| style="text-align: center; padding: 0px 10px 5px 10px;"|'''Content'''<hr /><br />
|-<br />
| style="text-align: left; padding:0px 10px 10px 10px;"|<br />
[[#Description|Description]]<br /><br />
[[#SoC Application|SoC Application]]<br /><br />
[[#Contact|Contact]]<br /><br />
[[#Questionnaire|Questionnaire]]<br /><br />
:[[#1) Basics|1 - Basics]]<br /><br />
:[[#2) Experience|2 - Experience]]<br /><br />
:[[#3) Communication skills|3 - Communication skills]]<br /><br />
:[[#4) Project|4 - Project]]<br /><br />
:[[#5) Practical considerations|5 - Practical considerations]]<br /><br />
[[#Proposal|Proposal]]<br /><br />
:[[#The problems|The problems]]<br /><br />
:[[#side_actions|<tt>side_actions</tt> refactoring]]<br /><br />
::[[#side_actions.situation|The current situation]]<br /><br />
::[[#side_actions.idea|The idea]]<br /><br />
::[[#side_actions.implementation|Implementation details]]<br /><br />
:::[[#side_actions.containers|Choice of the containers]]<br /><br />
:::[[#side_actions.example|Example]]<br /><br />
:::[[#side_actions.reconsideration|Reconsideration of Boost.MultiIndex]]<br /><br />
:[[#visitorhier|Visitor hierarchy refactoring]]<br /><br />
::[[#visitorhier.situation|The current situation]]<br /><br />
::[[#visitorhier.idea|The idea]]<br /><br />
::[[#visitorhier.implementation|Implementation details]]<br /><br />
:::[[#visitorhier.example|Example]]<br /><br />
:[[#actioncore|Transfer of the action and validation logic into the core]]<br /><br />
::[[#actioncore.situation|The current situation]]<br /><br />
::[[#actioncore.idea|The idea]]<br /><br />
::[[#actioncore.implementation|Implementation details]]<br /><br />
:::[[#actioncore.whiteboard|Changes in the Whiteboard]]<br /><br />
:::[[#actioncore.example|Example]]<br /><br />
:::[[#actioncore.deserialization|Deserialization]]<br /><br />
:[[#polishing|Polishing]]<br /><br />
::[[#polishing.mapbuilder|<tt>mapbuilder</tt>]]<br /><br />
::[[#polishing.swap_check|Validation of action swapping]]<br /><br />
::[[#polishing.manager_pimpl|Usage of a PIMPL in <tt>manager</tt>]]<br /><br />
:[[#designdoc|Design document]]<br /><br />
:[[#Openings|Openings]]<br /><br />
:[[#Timeline|Timeline]]<br /><br />
|}<br />
<br />
<!--***********************************************************************<br />
* * Description * *<br />
* *************** *<br />
* *<br />
* This section is inserted in the SummerOfCodeIdeas page. It contains *<br />
* only a header of level 4 and a small paragraph summing up the *<br />
* proposal. *<br />
***********************************************************************--><br />
==Description==<br />
====Étienne Simon - Whiteboard backend polishing====<br />
My project is to make the Whiteboard code cleaner and to redesign small parts of it to speed it up. The global design of the Whiteboard won't be changed a lot, each part will be reviewed individually. I'm not only planning to improve the Whiteboard backend, but also to document the overall design and each part of it as well as to write a wide variety of test to improve its stability. Moreover, I'll factorise action handling outside of the Whiteboard so that the same code will be usable in all Wesnoth.<!--<br />
--><br />
<!--***********************************************************************<br />
* * SoC Application * *<br />
* ******************* *<br />
* *<br />
* This section affect the SummerOfCodeIdeas page, if it contains the *<br />
* text "Submitted to google", the application will appear in the *<br />
* "Student proposals submitted both to wiki and google" section, *<br />
* otherwise it'll appear in the "Student proposals not submitted to *<br />
* google" section. *<br />
***********************************************************************--><br />
==SoC Application==<br />
Submitted to google<!--<br />
--><br />
<!--***********************************************************************<br />
* * Contact * *<br />
* *********** *<br />
* *<br />
* The IRC subsection is inserted in the SummerOfCodeIdeas page. It *<br />
* must only contain the IRC nick identifying the author. *<br />
***********************************************************************--><br />
==Contact==<br />
{|<br />
|-<br />
|<br />
=====IRC=====<br />
<span style="color:#3F475E;">ejls </span><br />
=====Email=====<br />
Address at gmail dot com: etienne.jl.simon<br />
| style="width:10em;" |<br />
|<br />
=====Forum=====<br />
ejls<br />
=====Gna=====<br />
ejls<br />
|}<br />
<br />
<!--***********************************************************************<br />
* * Questionnaire * *<br />
* ***************** *<br />
* *<br />
* Although I'm submitting only one application (and so only one *<br />
* questionnaire), I thought it was more elegant to make the *<br />
* questionnaire page reusable. Which explain why it's a template. *<br />
* Like I wrote in the Questionnaire subpage, the argument to this *<br />
* template are the answer to the proposal-specific questions. I order *<br />
* to make the sources more comprehensible, I wrote the corresponding *<br />
* question in comments at the beginning of each parameter. *<br />
***********************************************************************--><br />
{{User:Ejls/GSoC 2012/Questionnaire<br />
|<!-- 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? --><br />
''This is a summary, more details can be found [http://wiki.wesnoth.org/User:Ejls/GSoC%202012/Whiteboard%20Backend%20Refactoring#Proposal here].''<br />
<br />
I originally chose [[SoC Ideas Whiteboard Backend Refactoring 2012]], however it evolved a lot thanks to Gabba and Crab. This project is the only one not adding any feature for the user, the main goal is to refactor code, write test and documentation. It follows [http://wiki.wesnoth.org/GSoC-WesnothWhiteboard_Gabba Gabba's project] and [http://wiki.wesnoth.org/User:Tschmitz tschmitz's project] on the Whiteboard. Although it doesn't add any feature for the user in itself, I hope it'll help future development of the Whiteboard.<!--<br />
-->|<!-- 4.2) If you have invented your own project, please describe the project and the scope. --><br />
I chose a project from the list, namely [[SoC Ideas Whiteboard Backend Refactoring 2012]]. C.f. above answer.<!--<br />
-->|<!-- 4.3) Why did you choose this project? --><br />
I liked the idea behind the Whiteboard, I think it might be a big plus to Wesnoth. Furthermore, I liked how C++ is used in its code (especially the heavy use of SBRM). However it looks like the Whiteboard is not widely used, and I would like to help changing that! :)<!--<br />
-->|<!-- 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". --><br />
''This is a summary, more details can be found [http://wiki.wesnoth.org/User:Ejls/GSoC%202012/Whiteboard%20Backend%20Refactoring#Timeline here].''<br />
<br />
I separated my summer in five phases:<br />
*Phase 0: Approach (4 weeks)<br />
::→ Start working on the design document. Start the ''polishing''.<br />
*Phase 1: <code>side_actions</code> refactoring (3 weeks)<br />
*Phase 2: Validator hierarchy refactoring (3 weeks)<br />
*Phase 3: Transfer of the action and validation logic into the core (3 weeks)<br />
*Phase 4: Finalisation (3 weeks)<br />
::→ Finish the design document. Finish the ''polishing''. Test. Test. Test.<!--<br />
-->|<!-- 4.5) Include as much technical detail about your implementation as you can --><br />
''This is a summary, more details can be found [http://wiki.wesnoth.org/User:Ejls/GSoC%202012/Whiteboard%20Backend%20Refactoring#Proposal here].''<br />
<br />
I separated my project in five tasks:<br />
;<code>side_actions</code> refactoring<br />
:Change of the underlying container, creation of new look up functions.<br />
;Visitor hierarchy refactoring<br />
:Replacement of the <code>enable_visit_all</code> by a new interface over all of the <code>side_actions</code> objects.<br />
;Transfer of the action and validation logic into the core<br />
:Refactoring of <code>wb::action</code> in a Whiteboard-independent hierarchy.<br />
;Polishing<br />
:Code uniformisation, small improvements.<br />
;Design document<br />
:Documentation of the global Whiteboard design.<!--<br />
-->|<!-- 4.6) What do you expect to gain from this project? --><br />
I hope it'll help me to join the open source developer community. Actually, the preparation of this proposal already helped me a lot, for example my first patch got committed, it wasn't a big patch, but it was my first step of a (I hope) long path. :) So, I hope to continue learning to walk with the wesnoth community (sorry for the silly metaphor.)<!--<br />
-->|<!-- 4.7) What would make you stay in the Wesnoth community after the conclusion of SOC? --><br />
If my work is appreciated, I would rather ask: what would make me leave the Wesnoth community?.<!--<br />
-->}}<br />
<br />
<!--***********************************************************************<br />
* * Proposal * *<br />
* ************ *<br />
* *<br />
* Finally, my proposal. ;) *<br />
***********************************************************************--><br />
==Proposal==<br />
===The problems===<br />
In the [[SoC_Ideas_Whiteboard_Backend_Refactoring_2012|Whiteboard Backend Refactoring idea page]], several problems are listed, here is how I'm planning to fix them:<br />
{| style="border:1px dashed #AAA;border-collapse:collapse;"<br />
|-<br />
!style="border:1px dotted #AAA;padding:5px;"|Problem<br />
!style="border:1px dotted #AAA;padding:5px;"|Solution<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|<code>side_actions</code> complexity<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#side_actions|<code>side_actions</code> refactoring]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|Redundancy between <code>mapbuilder</code> and <code>validate_visitor</code><br />
|style="border:1px dotted #AAA;padding:5px;"|[[#visitorhier|Visitor hierarchy refactoring]], [[#actioncore|Transfer of the action and validation logic into the core]] and [[#Polishing|Polishing]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|Highlighter slowness<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#side_actions|<code>side_actions</code> refactoring]] and [[#visitorhier|Visitor hierarchy refactoring]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|Action handling decentralization<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#actioncore|Transfer of the action and validation logic into the core]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|Friend classes vs everything in the action classes<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#visitorhier|Visitor hierarchy refactoring]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|Unit pointer recovery uniformisation<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#polishing|Polishing]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|<code>boost::dynamic_pointer_cast</code> vs simple numeric id<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#polishing|Polishing]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|Documentation<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#designdoc|Design document]]<br />
|}<br />
<br />
===<span id="side_actions"><code>side_actions</code> refactoring</span>===<br />
====<span id="side_actions.situation">The current situation</span>====<br />
The current implementation of <code>side_actions</code> use a <code>std::deque&lt;std::deque&lt;action_ptr&gt;&gt;</code>.<br />
In order to use it, iterators have been defined over it (<code>side_actions::iterator</code> and the three const and reverse variants).<br />
These “flattening” iterators let users of <code>side_actions</code> iterate over all the planned actions, they are performing the ''zip'' operation on the fly.<br />
<br />
Furthermore, some queries like <code>side_actions::find_first_action_of</code> are linear in the number of action.<br />
<br />
====<span id="side_actions.idea">The idea</span>====<br />
To simplify the code, I propose to keep the action set zipped. The container's iterators will then be usable directly. In order to delimit turns, a second container will have to keep a sequence of iterators pointing to the first action of each turn.<br />
<br />
For example, let's say eight actions are planned: five for this turn, two for the next turn and one for the turn after. Three iterators will be kept to delimit turns. Here is a proof that I can't use gimp which also show the idea:<br />
http://epsilon012.free.fr/GSoC%202012/side_actions%20idea.png<br />
<br />
Of course another problem emerge: the sequence of iterator has to be kept in sync with the sequence of action.<br />
<br />
Finally, the current implementation gives access to the <code>action_ptr</code> only in sequence, in order to speed up different way of querying action (e.g. by hex, by unit's id), I propose to build several indexes on the action set.<br />
<br />
====<span id="side_actions.implementation">Implementation details</span>====<br />
Let's name these containers <code>actions_</code> and <code>turn_beginnings_</code>.<br />
<br />
The Whiteboard have the following invariant: an empty turn (a turn without planned action) can't be followed by a non-empty turn (with at least one planned action). It means that <code>distance(turn_beginnings_[i], turn_beginnings_[i+1])&gt;0</code>, and so we can unambiguously determine the turn number of each action.<br />
<br />
Also, note that except when <code>actions_.empty()</code> : <code>turn_beginnings_.front()==actions_.begin()</code>.<br />
<br />
=====<span id="side_actions.containers">Choice of the containers</span>=====<br />
<code>std::deque</code> seems to be the perfect container for <code>turn_beginnings_</code>. It'll allow random access and we need to add/remove new turns only at the extremities.<br />
<br />
On the other hand, <code>actions_</code> need three proprieties:<br />
*Allow fast chronological iteration<br />
*Stable iterators<br />
*Allow fast lookup on different indexes<br />
I propose to use a <code>boost::multi_index_container</code>, this container is part of the library [http://www.boost.org/doc/libs/1_49_0/libs/multi_index Boost.MultiIndex] which is in Boost since version 1.32. It allows the construction of several indexes on the same set of object.<br />
<br />
There is however one problem linked to the use of the <code>boost::multi_index::random_access</code> index: insertion and deletion are in linear time when their are not done at the extremities.<br />
<br />
So, the new members should be:<br />
<!-- Original:<br />
namespace bmi = boost::multi_index;<br />
typedef bmi::multi_index_container<<br />
action_ptr,<br />
bmi::indexed_by<<br />
bmi::random_access<bmi::tag<chronological> >,<br />
bmi::hashed_non_unique<bmi::tag<by_unit>, bmi::const_mem_fun<action,size_t,&action::get_unit_id> >,<br />
bmi::hashed_non_unique<bmi::tag<by_hex>, bmi::const_mem_fun<action,map_location,&action::get_hex> ><br />
><br />
> action_set;<br />
typedef action_set::iterator iterator;<br />
<br />
action_set actions_;<br />
std::deque<iterator> turn_beginnings_;<br />
Formated: --><code><div style="border: 1px dashed #AAA;background:#FAF3E9;padding:7px;"><span style="color:#000000; font-weight:bold">namespace</span> bmi <span style="color:#000000">=</span> boost<span style="color:#000000">::</span>multi_index<span style="color:#000000">;</span><br /><span style="color:#000000; font-weight:bold">typedef</span> bmi<span style="color:#000000">::</span>multi_index_container<span style="color:#000000">&lt;</span><br />&nbsp; &nbsp; action_ptr<span style="color:#000000">,</span><br />&nbsp; &nbsp; bmi<span style="color:#000000">::</span>indexed_by<span style="color:#000000">&lt;</span><br />&nbsp; &nbsp; &nbsp; &nbsp; bmi<span style="color:#000000">::</span>random_access<span style="color:#000000">&lt;</span>bmi<span style="color:#000000">::</span>tag<span style="color:#000000">&lt;</span>chronological<span style="color:#000000">&gt; &gt;,</span><br />&nbsp; &nbsp; &nbsp; &nbsp; bmi<span style="color:#000000">::</span>hashed_non_unique<span style="color:#000000">&lt;</span>bmi<span style="color:#000000">::</span>tag<span style="color:#000000">&lt;</span>by_unit<span style="color:#000000">&gt;,</span> bmi<span style="color:#000000">::</span>const_mem_fun<span style="color:#000000">&lt;</span>action<span style="color:#000000">,</span><span style="color:#0057ae">size_t</span><span style="color:#000000">,&amp;</span>action<span style="color:#000000">::</span>get_unit_id<span style="color:#000000">&gt; &gt;,</span><br />&nbsp; &nbsp; &nbsp; &nbsp; bmi<span style="color:#000000">::</span>hashed_non_unique<span style="color:#000000">&lt;</span>bmi<span style="color:#000000">::</span>tag<span style="color:#000000">&lt;</span>by_hex<span style="color:#000000">&gt;,</span> bmi<span style="color:#000000">::</span>const_mem_fun<span style="color:#000000">&lt;</span>action<span style="color:#000000">,</span><span style="color:#000000">map_location</span><span style="color:#000000">,&amp;</span>action<span style="color:#000000">::</span>get_hex<span style="color:#000000">&gt; &gt;</span><br />&nbsp; &nbsp; &nbsp; &nbsp; <span style="color:#000000">&gt;</span><br />&nbsp; &nbsp; <span style="color:#000000">&gt;</span> action_set<span style="color:#000000">;</span><br /><span style="color:#000000; font-weight:bold">typedef</span> action_set<span style="color:#000000">::</span>iterator iterator<span style="color:#000000">;</span><br /><br />action_set actions_<span style="color:#000000">;</span><br />std<span style="color:#000000">::</span>deque<span style="color:#000000">&lt;</span>iterator<span style="color:#000000">&gt;</span> turn_beginnings_<span style="color:#000000">;</span><br /></div></code><br /><br />
<br />
This suppose two new pure virtual functions in <code>action</code>: <code>get_unit_id</code> and <code>get_hex</code>.<br />
<br />
Using action's attribute as key brings another drawback: we must notify the <code>multi_index_container</code> when we modify a key.<br />
However, the two used keys here (the unit's id and the hex) are never modified in the <code>action</code> hierarchy.<br />
<br />
This definition is here to give an idea, in practice other indexes will have to be built (e.g. an index on ''secondary hex'' which could be the source hex in <code>move</code>.)<br />
Note that this doesn't necessarily means a new pure virtual function in <code>action</code>, a key extractor can be defined to let <code>action</code> as it is and use ''RTTI'' instead (this might not be clever though.)<br />
<br />
=====<span id="side_actions.example">Example</span>=====<br />
Here are three functions rewritten with this new design. Note that <code>side_actions::iterator</code> is the one defined above.<br />
<br />
<!-- Original:<br />
side_actions::iterator side_actions::end_turn(size_t turn_num){<br />
if(turn_num+1 >= turn_beginnings_.size())<br />
return actions_.end();<br />
else<br />
return turn_beginnings_[turn_num+1];<br />
}<br />
Formated: --><code><div style="border: 1px dashed #AAA;background:#FAF3E9;padding:7px;">side_actions<span style="color:#000000">::</span>iterator side_actions<span style="color:#000000">::</span><span style="color:#010181">end_turn</span><span style="color:#000000">(</span><span style="color:#0057ae">size_t</span> turn_num<span style="color:#000000">){</span><br />&nbsp; &nbsp; <span style="color:#000000; font-weight:bold">if</span><span style="color:#000000">(</span>turn_num<span style="color:#000000">+</span><span style="color:#b07e00">1</span> <span style="color:#000000">&gt;=</span> turn_beginnings_<span style="color:#000000">.</span><span style="color:#010181">size</span><span style="color:#000000">())</span><br />&nbsp; &nbsp; &nbsp; &nbsp; <span style="color:#000000; font-weight:bold">return</span> actions_<span style="color:#000000">.</span><span style="color:#010181">end</span><span style="color:#000000">();</span><br />&nbsp; &nbsp; <span style="color:#000000; font-weight:bold">else</span><br />&nbsp; &nbsp; &nbsp; &nbsp; <span style="color:#000000; font-weight:bold">return</span> turn_beginnings_<span style="color:#000000">[</span>turn_num<span style="color:#000000">+</span><span style="color:#b07e00">1</span><span style="color:#000000">];</span><br /><span style="color:#000000">}</span><br /></div></code><br /><br />
<br />
<!-- Original:<br />
side_actions::iterator side_actions::raw_enqueue(size_t turn_num, action_ptr act){<br />
assert(turn_num <= turn_beginnings_.size());<br />
<br />
iterator new_action = actions_.insert(end_turn(turn_num), act).first;<br />
<br />
if(turn_num >= turn_beginnings_.size())<br />
turn_beginnings_.push_back(new_action);<br />
<br />
return new_action;<br />
}<br />
Formated: --><code><div style="border: 1px dashed #AAA;background:#FAF3E9;padding:7px;">side_actions<span style="color:#000000">::</span>iterator side_actions<span style="color:#000000">::</span><span style="color:#010181">raw_enqueue</span><span style="color:#000000">(</span><span style="color:#0057ae">size_t</span> turn_num<span style="color:#000000">,</span> action_ptr act<span style="color:#000000">){</span><br />&nbsp; &nbsp; <span style="color:#000000; font-weight:bold">assert</span><span style="color:#000000">(</span>turn_num <span style="color:#000000">&lt;=</span> turn_beginnings_<span style="color:#000000">.</span><span style="color:#010181">size</span><span style="color:#000000">());</span><br /><br />&nbsp; &nbsp; iterator new_action <span style="color:#000000">=</span> actions_<span style="color:#000000">.</span><span style="color:#010181">insert</span><span style="color:#000000">(</span><span style="color:#010181">end_turn</span><span style="color:#000000">(</span>turn_num<span style="color:#000000">),</span> act<span style="color:#000000">).</span>first<span style="color:#000000">;</span><br /><br />&nbsp; &nbsp; <span style="color:#000000; font-weight:bold">if</span><span style="color:#000000">(</span>turn_num <span style="color:#000000">&gt;=</span> turn_beginnings_<span style="color:#000000">.</span><span style="color:#010181">size</span><span style="color:#000000">())</span><br />&nbsp; &nbsp; &nbsp; &nbsp; turn_beginnings_<span style="color:#000000">.</span><span style="color:#010181">push_back</span><span style="color:#000000">(</span>new_action<span style="color:#000000">);</span><br /><br />&nbsp; &nbsp; <span style="color:#000000; font-weight:bold">return</span> new_action<span style="color:#000000">;</span><br /><span style="color:#000000">}</span><br /></div></code><br /><br />
<br />
<!-- Original:<br />
side_actions::find_first_action_of(unit const* unit, side_actions::iterator start_position){<br />
// First we get all the action of this unit<br />
typedef action_set::index<by_unit>::type::iterator unit_iterator;<br />
std::pair<unit_iterator, unit_iterator> act = actions_.get<by_unit>().equal_range(unit->underlying_id());<br />
<br />
// Then we find the first of them (chronologically) after start_position<br />
iterator first = actions_.end();<br />
for(unit_iterator it = act.first; it != act.second; ++it){<br />
iterator chrono_it = actions_.project<chronological>(it);<br />
if(chrono_it < first && chrono_it > start_position)<br />
first = chrono_it;<br />
}<br />
return first;<br />
}<br />
Formated: --><code><div style="border: 1px dashed #AAA;background:#FAF3E9;padding:7px;">side_actions<span style="color:#000000">::</span><span style="color:#010181">find_first_action_of</span><span style="color:#000000">(</span>unit <span style="color:#0057ae">const</span><span style="color:#000000">*</span> unit<span style="color:#000000">,</span> side_actions<span style="color:#000000">::</span>iterator start_position<span style="color:#000000">){</span><br />&nbsp; &nbsp; <span style="color:#838183; font-style:italic">// First we get all the action of this unit</span><br />&nbsp; &nbsp; <span style="color:#000000; font-weight:bold">typedef</span> action_set<span style="color:#000000">::</span>index<span style="color:#000000">&lt;</span>by_unit<span style="color:#000000">&gt;::</span>type<span style="color:#000000">::</span>iterator unit_iterator<span style="color:#000000">;</span><br />&nbsp; &nbsp; std<span style="color:#000000">::</span>pair<span style="color:#000000">&lt;</span>unit_iterator<span style="color:#000000">,</span> unit_iterator<span style="color:#000000">&gt;</span> act <span style="color:#000000">=</span> actions_<span style="color:#000000">.</span>get<span style="color:#000000">&lt;</span>by_unit<span style="color:#000000">&gt;().</span><span style="color:#010181">equal_range</span><span style="color:#000000">(</span>unit<span style="color:#000000">-&gt;</span><span style="color:#010181">underlying_id</span><span style="color:#000000">());</span><br /><br />&nbsp; &nbsp; <span style="color:#838183; font-style:italic">// Then we find the first of them (chronologically) after start_position</span><br />&nbsp; &nbsp; iterator first <span style="color:#000000">=</span> actions_<span style="color:#000000">.</span><span style="color:#010181">end</span><span style="color:#000000">();</span><br />&nbsp; &nbsp; <span style="color:#000000; font-weight:bold">for</span><span style="color:#000000">(</span>unit_iterator it <span style="color:#000000">=</span> act<span style="color:#000000">.</span>first<span style="color:#000000">;</span> it <span style="color:#000000">!=</span> act<span style="color:#000000">.</span>second<span style="color:#000000">; ++</span>it<span style="color:#000000">){</span><br />&nbsp; &nbsp; &nbsp; &nbsp; iterator chrono_it <span style="color:#000000">=</span> actions_<span style="color:#000000">.</span>project<span style="color:#000000">&lt;</span>chronological<span style="color:#000000">&gt;(</span>it<span style="color:#000000">);</span><br />&nbsp; &nbsp; &nbsp; &nbsp; <span style="color:#000000; font-weight:bold">if</span><span style="color:#000000">(</span>chrono_it <span style="color:#000000">&lt;</span> first <span style="color:#000000">&amp;&amp;</span> chrono_it <span style="color:#000000">&gt;</span> start_position<span style="color:#000000">)</span><br />&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; first <span style="color:#000000">=</span> chrono_it<span style="color:#000000">;</span><br />&nbsp; &nbsp; <span style="color:#000000">}</span><br />&nbsp; &nbsp; <span style="color:#000000; font-weight:bold">return</span> first<span style="color:#000000">;</span><br /><span style="color:#000000">}</span><br /></div></code><br />
<br />
=====<span id="side_actions.reconsideration">Reconsideration of Boost.MultiIndex</span>=====<br />
As Gabba noted ([http://www.wesnoth.org/irclogs/2012/03/%23wesnoth-dev.2012-03-31.log #wesnoth-dev 2012/03/31 7h18]), Boost.MultiIndex might be hard to debug and hard to use.<br />
This section try to reconsider the use of Boost.MultiIndex.<br />
<br />
The major problem we would run into while considering to write a replacement for Boost.MultiIndex is how to allow the usage of the standard algorithms. Indeed, they will be usable only on the underlying container and not on its ''view''. To overcome this, a simple solution have been used in Boost: they rewrote all the iterators. The problem is that, even if it now evolved in something bigger, the first goal with <code>side_actions</code> refactoring was to remove the iterator's definitions.<br />
<br />
While, indeed Boost.MultiIndex will make debugging harder and increase compilation time compared to an homemade solution.<br />
It offer numerous advantages:<br />
*It's generic, adding a new key will be as easy as adding a new template parameter in the definition.<br />
*It don't have to be rewritten. :)<br />
*It's already used in Wesnoth (thanks Mordante for noting it.)<br />
*It offers some advantages over the standard containers (e.g. a random-access container with stable iterators and strong exception guaranty.)<br />
<br />
===<span id="visitorhier">Visitor hierarchy refactoring</span>===<br />
====<span id="visitorhier.situation">The current situation</span>====<br />
The important classes and class templates of this hierarchy are:<br />
*'''<code>visitor</code>''', the base class of the visitor hierarchy, it dispatches the calls to the derived classes.<br />
*'''<code>enable_visit_all</code>''', which is actually an interface to the <code>action_ptr</code> objects of every single team.<br />
*'''<code>action</code>''', the root class of the visitable hierarchy.<br />
<br />
Currently, when the visitor hierarchy needs to visit the visitable hierarchy, all the actions of every sides of every turn are visited using the function <code>enable_visit_all::visit_all_helper</code> (e.g. this function is called by <code>highlight_visitor::find_main_highlight</code> to find the action to highlight.)<br />
<br />
====<span id="visitorhier.idea">The idea</span>====<br />
I'm favorable to the maintain of the Visitor pattern, it segregates the different components nicely.<br />
I think the problem come from <code>enable_visit_all</code> and I would like to replace it with a class offering a more fine-grained access to the actions.<br />
For example, a look up by hex could be defined in this new structure and then used by <code>highlight_visitor</code>.<br />
Actually, most of the work of this new class will have to do is to redirect the calls to the <code>side_actions</code> (to one in particular or to all depending on the function).<br />
<br />
====<span id="visitorhier.implementation">Implementation details</span>====<br />
Let's name this new class <code>action_set</code>.<br />
<br />
The sole problem faced is to place <code>action_set</code>, since it is mainly a proxy to a global resource (the <code>side_actions</code> of each team), it makes sense to place it directly in the <code>wb</code> namespace.<br />
<br />
Note that the access to the <code>action</code> hierarchy will no more be done through inheritance.<br />
<br />
=====<span id="visitorhier.example">Example</span>=====<br />
Here is an example function that would speed up <code>highlight_visitor</code>.<br />
<!-- Original:<br />
action_ptr action_set::action_at(map_location const &hex){<br />
side_actions::iterator result;<br />
foreach(team& side, *resources::teams){<br />
side_actions actions = side.get_side_actions();<br />
if((result = actions.find_action_at(hex)) != actions.end())<br />
return *result;<br />
}<br />
return action_ptr();<br />
}<br />
Formated: --><code><div style="border: 1px dashed #AAA;background:#FAF3E9;padding:7px;">action_ptr action_set<span style="color:#000000">::</span><span style="color:#010181">action_at</span><span style="color:#000000">(</span>map_location <span style="color:#0057ae">const</span> <span style="color:#000000">&amp;</span>hex<span style="color:#000000">){</span><br />&nbsp; &nbsp; side_actions<span style="color:#000000">::</span>iterator result<span style="color:#000000">;</span><br />&nbsp; &nbsp; <span style="color:#010181">foreach</span><span style="color:#000000">(</span>team<span style="color:#000000">&amp;</span> side<span style="color:#000000">, *</span>resources<span style="color:#000000">::</span>teams<span style="color:#000000">){</span><br />&nbsp; &nbsp; &nbsp; &nbsp; side_actions actions <span style="color:#000000">=</span> side<span style="color:#000000">.</span><span style="color:#010181">get_side_actions</span><span style="color:#000000">();</span><br />&nbsp; &nbsp; &nbsp; &nbsp; <span style="color:#000000; font-weight:bold">if</span><span style="color:#000000">((</span>result <span style="color:#000000">=</span> actions<span style="color:#000000">.</span><span style="color:#010181">find_action_at</span><span style="color:#000000">(</span>hex<span style="color:#000000">)) !=</span> actions<span style="color:#000000">.</span><span style="color:#010181">end</span><span style="color:#000000">())</span><br />&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; <span style="color:#000000; font-weight:bold">return</span> <span style="color:#000000">*</span>result<span style="color:#000000">;</span><br />&nbsp; &nbsp; <span style="color:#000000">}</span><br />&nbsp; &nbsp; <span style="color:#000000; font-weight:bold">return</span> <span style="color:#010181">action_ptr</span><span style="color:#000000">();</span><br /><span style="color:#000000">}</span><br /></div></code><br /><br />
<br />
Note: the implementation of <code>side_actions::find_action_at</code> is similar to the one of <code>side_actions::find_first_action_of</code>.<br />
<br />
===<span id="actioncore">Transfer of the action and validation logic into the core</span>===<br />
This is a (great) idea of Crab ([http://www.wesnoth.org/irclogs/2012/04/%23wesnoth-dev.2012-04-02.log #wesnoth-dev 2012/04/02 16h11]).<br />
<br />
====<span id="actioncore.situation">The current situation</span>====<br />
Currently, the code related to action execution and checking is duplicated in several places.<br />
For example, <code>ai::recall_result::do_check_before()</code>, <code>wb::validate_visitor::visit(recall_ptr)</code> and <code>do_replay_handle()</code> are doing the same thing: checking whether a recall is valid.<br />
Furthermore, the latter is also executing the recall, as is <code>wb::recall::execute()</code> and <code>ai::recall_result::do_execute()</code>.<br />
<br />
====<span id="actioncore.idea">The idea</span>====<br />
The idea is simple: factor the code.<br />
<br />
However, we must be careful not to include too many functionalities in this new hierarchy, it must be extensible as much as possible without having to modify it.<br />
<br />
The good thing with the current code duplication is that I'll be able to look at different code doing the same thing before choosing the best implementation. ;)<br />
<br />
====<span id="actioncore.implementation">Implementation details</span>====<br />
A nice point of <code>wb::action</code> is that Gabba used the visitor pattern, which is exactly what we need here.<br />
Indeed, some functions are strictly related to a module (for example the Whiteboard's highlighter), the visitor pattern will allow virtual functions to be defined outside of the visited hierarchy (the action hierarchy here), moreover the visited hierarchy doesn't need to be recompiled when a new visitor is added.<br />
<br />
The overhead of the visitor is really small: an additional (non-virtual) function call.<br />
<br />
Since the validation of an action is needed by all the game, it can be included as a member function <code>virtual bool valid() const =0;</code> in the action hierarchy.<br />
<br />
=====<span id="actioncore.whiteboard">Changes in the Whiteboard</span>=====<br />
It's a good idea to read this part even if you're not interested in the Whiteboard, indeed this gives you an idea on to extends this new action hierarchy.<br />
<br />
Currently, there is a Whiteboard-specific action: <code>suppose_dead</code>.<br />
Even if it's disabled for now, the new design need to consider it.<br />
Actually, the changes to do are pretty straightforward:<br />
*A new class <code>suppose_dead</code> is derived from <code>action</code><br />
*A new class <code>whiteboard_action_visitor</code> is derived from <code>action_visitor</code> and add a virtual function <code>visit(suppose_dead&amp;)</code><br />
That's all. :)<br />
Now, the sole Whiteboard visitor (<code>highlight_visitor</code>) can derive from <code>whiteboard_action_visitor</code> and override <code>visit(suppose_dead&amp;)</code>.<br />
<br />
What is important here is that we can still extends the <code>action</code> hierarchy which is in core, without modifying it.<br />
<br />
Of course, I'm planing to write <s>the same</s> a better explanation in the documentation. ;)<br />
<br />
=====<span id="actioncore.example">Example</span>=====<br />
Highlighting a recruit action in the Whiteboard:<br />
<!-- Original:<br />
recruit recruit_action(the_team, the_unit, the_hex);<br />
highlighter_->visit(recruit_action);<br />
Formated: --><code><div style="border: 1px dashed #AAA;background:#FAF3E9;padding:7px;">recruit <span style="color:#010181">recruit_action</span><span style="color:#000000">(</span>the_team<span style="color:#000000">,</span> the_unit<span style="color:#000000">,</span> the_hex<span style="color:#000000">);</span><br />highlighter_<span style="color:#000000">-&gt;</span><span style="color:#010181">visit</span><span style="color:#000000">(</span>recruit_action<span style="color:#000000">);</span><br /></div></code><br /><br />
<br />
Here is the code skeleton for <code>wb::suppose_dead</code>:<br />
<!-- Original:<br />
class suppose_dead: public action {<br />
public:<br />
void accept(whiteboard_action_visitor &vis){ vis.visit(*this); }<br />
/* the code… */<br />
};<br />
<br />
class whiteboard_action_visitor: public action_visitor {<br />
public:<br />
virtual void visit(suppose_dead&) =0;<br />
};<br />
<br />
class highlight_visitor: public whiteboard_action_visitor {<br />
public:<br />
void visit(recruit &rec){<br />
/* Display some nice sign */<br />
}<br />
void visit(suppose_dead &dead){<br />
/* Display some scary sign */<br />
}<br />
/* … */<br />
};<br />
Formated: --><code><div style="border: 1px dashed #AAA;background:#FAF3E9;padding:7px;"><span style="color:#000000; font-weight:bold">class</span> suppose_dead<span style="color:#000000">:</span> <span style="color:#000000; font-weight:bold">public</span> action <span style="color:#000000">{</span><br /><span style="color:#000000; font-weight:bold">public</span><span style="color:#000000">:</span><br />&nbsp; &nbsp; <span style="color:#0057ae">void</span> <span style="color:#010181">accept</span><span style="color:#000000">(</span>whiteboard_action_visitor <span style="color:#000000">&amp;</span>vis<span style="color:#000000">){</span> vis<span style="color:#000000">.</span><span style="color:#010181">visit</span><span style="color:#000000">(*</span><span style="color:#000000; font-weight:bold">this</span><span style="color:#000000">); }</span><br />&nbsp; &nbsp; <span style="color:#838183; font-style:italic">/* the code… */</span><br /><span style="color:#000000">};</span><br /><br /><span style="color:#000000; font-weight:bold">class</span> whiteboard_action_visitor<span style="color:#000000">:</span> <span style="color:#000000; font-weight:bold">public</span> action_visitor <span style="color:#000000">{</span><br /><span style="color:#000000; font-weight:bold">public</span><span style="color:#000000">:</span><br />&nbsp; &nbsp; <span style="color:#000000; font-weight:bold">virtual</span> <span style="color:#0057ae">void</span> <span style="color:#010181">visit</span><span style="color:#000000">(</span>suppose_dead<span style="color:#000000">&amp;) =</span><span style="color:#b07e00">0</span><span style="color:#000000">;</span><br /><span style="color:#000000">};</span><br /><br /><span style="color:#000000; font-weight:bold">class</span> highlight_visitor<span style="color:#000000">:</span> <span style="color:#000000; font-weight:bold">public</span> whiteboard_action_visitor <span style="color:#000000">{</span><br /><span style="color:#000000; font-weight:bold">public</span><span style="color:#000000">:</span><br />&nbsp; &nbsp; <span style="color:#0057ae">void</span> <span style="color:#010181">visit</span><span style="color:#000000">(</span>recruit <span style="color:#000000">&amp;</span>rec<span style="color:#000000">){</span><br />&nbsp; &nbsp; &nbsp; &nbsp; <span style="color:#838183; font-style:italic">/* Display some nice sign */</span><br />&nbsp; &nbsp; <span style="color:#000000">}</span><br />&nbsp; &nbsp; <span style="color:#0057ae">void</span> <span style="color:#010181">visit</span><span style="color:#000000">(</span>suppose_dead <span style="color:#000000">&amp;</span>dead<span style="color:#000000">){</span><br />&nbsp; &nbsp; &nbsp; &nbsp; <span style="color:#838183; font-style:italic">/* Display some scary sign */</span><br />&nbsp; &nbsp; <span style="color:#000000">}</span><br />&nbsp; &nbsp; <span style="color:#838183; font-style:italic">/* … */</span><br /><span style="color:#000000">};</span><br /></div></code><br /><br />
<br />
=====<span id="actioncore.deserialization">Deserialization</span>=====<br />
Currently, each class deriving from <code>action</code> has a constructor taking a <code>config</code> object, this sounds good, however these constructors are called by <code>action::from_config</code> after doing an if on each possible type.<br />
This approach creates a dependency bottleneck: it collects in a single function knowledge about all classes deriving from <code>action</code>.<br />
<br />
A more sensible approach would be to use ''object factories''.<br />
The implementation is not very long nor difficult and the resulting code will be more elegant.<br />
<br />
The above extension of the <code>action</code> hierarchy with <code>suppose_dead</code>, will only need an additional line to register itself.<br />
<br />
===<span id="polishing">Polishing</span>===<br />
Some inconsistencies are present in the code (e.g. the way units are referenced). Some other parts needs clean up or/and optimisation (e.g. usage of <code>boost::dynamic_pointer_cast</code>).<br />
<br />
The goal of this task is to find this kind of small problem and fix them.<br />
These two ones have been spotted by Gabba, but I'm planning to add other small problems to this list as I found them.<br />
<br />
Also, they can be a good introduction to the code that's why I'm planning to start working on them before the GSoC start date.<br />
<br />
====<span id="polishing.mapbuilder"><code>mapbuilder</code></span>====<br />
Although, the <code>mapbuilder</code> refactoring was one of the main task, I'm putting it here since it'll mainly be refactored as part of the [[#visitorhier|visitor hierarchy refactoring]] and as part of the [[#actioncore|transfer of the action and validation logic into the core]].<br />
Indeed, the <code>mapbuilder</code> isn't badly designed, all the problems are coming from the API it has to use.<br />
<br />
Gabba, mentioned the possibility of an “incremental mapbuilding”, with the new <code>action_set</code> class, this will be really easy to do.<br />
Currently <code>apply_temp_modifier</code> is called by the function <code>mapbuilder::process</code> which is itself called on every action by <code>enable_visit_all</code>.<br />
However, the task [[#visitorhier|visitor hierarchy refactoring]] will replace <code>enable_visit_all</code> with a class allowing a more fine grained access to the <code>side_actions</code> objects, for example an access by turn (on all <code>side_actions</code> objects) can easily be implemented.<br />
<br />
====<span id="polishing.swap_check">Validation of action swapping</span>====<br />
This problem is more difficult than it looks like, indeed it needs a double dispatch (AKA multimethod).<br />
The current implementation use what Alexandrescu call a ''double switch-on-type'', a more elegant approach would be to use a static or logarithmic dispatcher.<br />
But do we really need it?<br />
I don't think so, indeed, currently one of the argument is always a <code>move</code>, so we can instead use a unique <code>dynamic_pointer_cast</code> (to check if the action is a <code>move</code> or derives from it) and then rely on a visitor doing the check for each <code>action</code> type.<br />
<br />
So we would end-up with:<br />
<!-- Original:<br />
class swapable_with_move: public visitor {<br />
public:<br />
swapable_with_move(move_ptr first): first_(first), valid_(false) {}<br />
bool valid() const { return valid_; }<br />
<br />
// If we don't define visit for an action, the swap is necessarily valid.<br />
void visit(action&){<br />
valid_ = true;<br />
}<br />
<br />
void visit(move &second){<br />
valid_ = first_->get_dest_hex() != second.get_source_hex();<br />
}<br />
<br />
// etc…<br />
<br />
private:<br />
move_ptr first_;<br />
bool valid_;<br />
};<br />
Formated: --><code><div style="border: 1px dashed #AAA;background:#FAF3E9;padding:7px;"><span style="color:#000000; font-weight:bold">class</span> swapable_with_move<span style="color:#000000">:</span> <span style="color:#000000; font-weight:bold">public</span> visitor <span style="color:#000000">{</span><br /><span style="color:#000000; font-weight:bold">public</span><span style="color:#000000">:</span><br />&nbsp; &nbsp; <span style="color:#010181">swapable_with_move</span><span style="color:#000000">(</span>move_ptr first<span style="color:#000000">):</span> <span style="color:#010181">first_</span><span style="color:#000000">(</span>first<span style="color:#000000">),</span> <span style="color:#010181">valid_</span><span style="color:#000000">(</span><span style="color:#000000; font-weight:bold">false</span><span style="color:#000000">) {}</span><br />&nbsp; &nbsp; <span style="color:#0057ae">bool</span> <span style="color:#010181">valid</span><span style="color:#000000">()</span> <span style="color:#0057ae">const</span> <span style="color:#000000">{</span> <span style="color:#000000; font-weight:bold">return</span> valid_<span style="color:#000000">; }</span><br />&nbsp; &nbsp; <br />&nbsp; &nbsp; <span style="color:#838183; font-style:italic">// If we don't define visit for an action, the swap is necessarily valid.</span><br />&nbsp; &nbsp; <span style="color:#0057ae">void</span> <span style="color:#010181">visit</span><span style="color:#000000">(</span>action<span style="color:#000000">&amp;){</span><br />&nbsp; &nbsp; &nbsp; &nbsp; valid_ <span style="color:#000000">=</span> <span style="color:#000000; font-weight:bold">true</span><span style="color:#000000">;</span><br />&nbsp; &nbsp; <span style="color:#000000">}</span><br />&nbsp; &nbsp; <br />&nbsp; &nbsp; <span style="color:#0057ae">void</span> <span style="color:#010181">visit</span><span style="color:#000000">(</span>move <span style="color:#000000">&amp;</span>second<span style="color:#000000">){</span><br /> &nbsp; &nbsp; &nbsp; &nbsp; valid_ <span style="color:#000000">=</span> first_<span style="color:#000000">-&gt;</span><span style="color:#010181">get_dest_hex</span><span style="color:#000000">() !=</span> second<span style="color:#000000">.</span><span style="color:#010181">get_source_hex</span><span style="color:#000000">();</span><br />&nbsp; &nbsp; <span style="color:#000000">}</span><br /><br />&nbsp; &nbsp; <span style="color:#838183; font-style:italic">// etc…</span><br /><br /><span style="color:#000000; font-weight:bold">private</span><span style="color:#000000">:</span><br />&nbsp; &nbsp; move_ptr first_<span style="color:#000000">;</span><br />&nbsp; &nbsp; <span style="color:#0057ae">bool</span> valid_<span style="color:#000000">;</span><br /><span style="color:#000000">};</span><br /></div></code><br /><br />
<br />
Then, we can use it like this:<br />
<!-- Original:<br />
// Check if we can swap the two actions<br />
if (move_ptr bump_earlier = dynamic_pointer_cast<move>(*position)) {<br />
swapable_with_move swap_check(bump_earlier);<br />
(*previous)->accept(swap_check);<br />
if(!swap_check.valid())<br />
return end();<br />
}<br />
Formated: --><code><div style="border: 1px dashed #AAA;background:#FAF3E9;padding:7px;"><span style="color:#838183; font-style:italic">// Check if we can swap the two actions</span><br /><span style="color:#000000; font-weight:bold">if</span> <span style="color:#000000">(</span>move_ptr bump_earlier <span style="color:#000000">=</span> dynamic_pointer_cast<span style="color:#000000">&lt;</span>move<span style="color:#000000">&gt;(*</span>position<span style="color:#000000">)) {</span><br />&nbsp; &nbsp; swapable_with_move <span style="color:#010181">swap_check</span><span style="color:#000000">(</span>bump_earlier<span style="color:#000000">);</span><br />&nbsp; &nbsp; <span style="color:#000000">(*</span>previous<span style="color:#000000">)-&gt;</span><span style="color:#010181">accept</span><span style="color:#000000">(</span>swap_check<span style="color:#000000">);</span><br />&nbsp; &nbsp; <span style="color:#000000; font-weight:bold">if</span><span style="color:#000000">(!</span>swap_check<span style="color:#000000">.</span><span style="color:#010181">valid</span><span style="color:#000000">())</span><br />&nbsp; &nbsp; &nbsp; &nbsp; <span style="color:#000000; font-weight:bold">return</span> <span style="color:#010181">end</span><span style="color:#000000">();</span><br /><span style="color:#000000">}</span><br /></div></code><br />
<br />
====<span id="polishing.manager_pimpl">Usage of a PIMPL in <code>manager</code></span>====<br />
Here is the list of file recompiled when <tt>whiteboard/manager.hpp</tt> is modified:<br />
{|<br />
|-<br />
|<ul><br />
<li><tt>actions.cpp</tt></li><br />
<li><tt>game_display.cpp</tt></li><br />
<li><tt>game_events.cpp</tt></li><br />
<li><tt>menu_events.cpp</tt></li><br />
<li><tt>mouse_events.cpp</tt></li><br />
<li><tt>play_controller.cpp</tt></li><br />
<li><tt>playmp_controller.cpp</tt></li><br />
</ul><br />
|<ul><br />
<li><tt>playsingle_controller.cpp</tt></li><br />
<li><tt>playturn.cpp</tt></li><br />
<li><tt>replay.cpp</tt></li><br />
<li><tt>reports.cpp</tt></li><br />
<li><tt>whiteboard/highlight_visitor.cpp</tt></li><br />
<li><tt>whiteboard/manager.cpp</tt></li><br />
<li><tt>whiteboard/move.cpp</tt></li><br />
</ul><br />
|<ul><br />
<li><tt>whiteboard/recall.cpp</tt></li><br />
<li><tt>whiteboard/recruit.cpp</tt></li><br />
<li><tt>whiteboard/side_actions.cpp</tt></li><br />
<li><tt>whiteboard/suppose_dead.cpp</tt></li><br />
<li><tt>whiteboard/utility.cpp</tt></li><br />
<li><tt>whiteboard/validate_visitor.cpp</tt></li><br />
</ul><br />
|}<br />
<br />
That is, 20 files (as an order of comparison, there is currently 462 <tt>.cpp</tt> files in src).<br />
Although, this number might increase, I'm not sure whether the PIMPL is really necessary.<br />
For now, I'm putting it on my TODO list with a low priority.<br />
<br />
===<span id="designdoc">Design document</span>===<br />
This idea is inspired by the GUI2 design document present in the SVN.<br />
<br />
Doxygen documents the code at a function or class level.<br />
The goal is to write a documentation at the module level. That is a document describing the Whiteboard design globally and not function-by-function.<br />
Actually it shouldn't duplicate what is in doxygen but complement it.<br />
This document could also include informations on how to extend the Whiteboard to help future contributors.<br />
<br />
This design document will be written as a doxygen page, this will leave the documentation next to the code.<br />
<br />
However, I'll begin to put some drafts on the wiki before committing it. Indeed, that will make reviewing easier.<br />
<br />
===Openings===<br />
Here are some possible openings to transform this Google summer of code into a Google year of code:<br />
*Use the new action hierarchy wherever it's needed<br />
*As suggested by Gabba, replace the current <code>wb::manager::on_gamestate_change</code> by something more generic (maybe something like <code>ai::gamestate_observer</code>)<br />
<br />
===Timeline===<br />
Two of my five tasks are actually best done continuously: the design document and the polishing.<br />
Although I haven't clearly placed a week for them, I set two dates at which they should have been completed.<br />
<br />
Of course, the plan is not to have any delay and to finish each task early, however I have reserved two weeks (actually one week and a half) for unexpected delay.<br />
I named them "movable weeks", because they can move in my timeline if anything goes wrong. :)<br />
<br />
On the other hand, I have some [[#Openings|openings]] planned.<br /><br /><br />
<br />
<!-- Wikitext hell 101 --><br />
{| style="border:1px dashed #AAA;border-collapse:collapse;"<br />
|-<br />
!style="border:1px dotted #AAA;padding:5px;"|Date<br />
!style="border:1px dotted #AAA;padding:5px;"|Week<br />
!style="border:1px dotted #AAA;padding:5px;"|Description<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''17/03 - 20/04''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''-11..-5''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Student application evaluation''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|17/03 - 20/04<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|-11..-5<br />
|style="border:1px dotted #AAA;padding:5px;"|Refine the proposal.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''23/04 - 20/05''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''-4..-1''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Community Bonding Period (4 weeks)''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|'''23/04 - 20/05'''<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|'''-4..-1'''<br />
|style="border:1px dotted #AAA;padding:5px;"|'''Phase 0: Approach'''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|23/04 - 20/05<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|-4..-1<br />
|style="border:1px dotted #AAA;padding:5px;"|Familiarise myself with the Whiteboard, in the process start a draft of the design document.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|23/04 - 20/05<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|-4..-1<br />
|style="border:1px dotted #AAA;padding:5px;"|Start working on the ''polishing''.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''21/05''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''0''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Start of GSoC''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|21/05 - 12/08<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|0..11<br />
|style="border:1px dotted #AAA;padding:5px;"|Continuously work on the design document and on the code polishing.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''21/05 - 15/07''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''0..7''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''First half term (8 weeks)''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|'''21/05 - 10/06'''<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|'''0..2'''<br />
|style="border:1px dotted #AAA;padding:5px;"|'''Phase 1: <code>side_actions</code> refactoring'''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|21/05 - 27/05<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|0<br />
|style="border:1px dotted #AAA;padding:5px;"|Prepare <code>side_actions</code> for the change. Add debug informations to the logs. Add the new member <code>turn_beginnings_</code>.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|28/05 - 03/06<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|1<br />
|style="border:1px dotted #AAA;padding:5px;"|Change the type of <code>actions_</code> and rewrite the associated functions. Delete the custom iterators.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|04/06 - 10/06<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|2<br />
|style="border:1px dotted #AAA;padding:5px;"|Debug, write unit test and documentation.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|'''11/06 - 01/07'''<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|'''3..5'''<br />
|style="border:1px dotted #AAA;padding:5px;"|'''Phase 2: Validator hierarchy refactoring'''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|11/06 - 17/06<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|3<br />
|style="border:1px dotted #AAA;padding:5px;"|Write the class <code>action_set</code>.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|18/06 - 24/06<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|4<br />
|style="border:1px dotted #AAA;padding:5px;"|Replace the uses of <code>enable_visit_all</code> with the new interface. Then delete <code>enable_visit_all</code>.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|25/06 - 01/07<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|5<br />
|style="border:1px dotted #AAA;padding:5px;"|Debug, write unit test and documentation.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|'''02/07 - 22/07'''<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|'''6..8'''<br />
|style="border:1px dotted #AAA;padding:5px;"|'''Phase 3: Transfer of the action and validation logic into the core'''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|02/07 - 08/07<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|6<br />
|style="border:1px dotted #AAA;padding:5px;"|Separation of the Whiteboard specific-code from the actions. Transfer of the actions in the core.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|09/07 - 15/07<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|7<br />
|style="border:1px dotted #AAA;padding:5px;"|Use this new API in other places, including the <code>mapbuilder</code>.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''13/07''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''7''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Mid-term evaluation''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''16/07 - 26/08''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''8..13''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Second half term (6 weeks)''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|16/07 - 22/07<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|8<br />
|style="border:1px dotted #AAA;padding:5px;"|Document the new action hierarchy. Mark @deprecated copies of it.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|'''22/07 - 12/08'''<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|'''9..11'''<br />
|style="border:1px dotted #AAA;padding:5px;"|'''Phase 4: Finalisation'''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|22/07 - 29/07<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|9<br />
|style="border:1px dotted #AAA;padding:5px;"|Heavy testing week.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|30/07 - 05/08<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|10<br />
|style="border:1px dotted #AAA;padding:5px;"|Test, debug. Finish the ''polishing''.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|06/08 - 12/08<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|11<br />
|style="border:1px dotted #AAA;padding:5px;"|Test, debug. Finish the design document.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|13/08 - 19/08<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|12<br />
|style="border:1px dotted #AAA;padding:5px;"|Movable week.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|20/08 - 26/08<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|13<br />
|style="border:1px dotted #AAA;padding:5px;"|Movable week.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''24/08''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''13''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Final evaluation''<br />
|}</div>Ejlshttps://wiki.wesnoth.org/index.php?title=User:Ejls/GSoC_2012/Questionnaire&diff=46376User:Ejls/GSoC 2012/Questionnaire2012-04-10T02:38:45Z<p>Ejls: Formating</p>
<hr />
<div>__NOTOC__<!--<br />
-->__NOEDITSECTION__<!--<br />
--><noinclude>'''Note: This is a template to be included in a proposal page by transclusion. All question are not answered here, you should refer to a proposal page.'''</noinclude><!--<br />
This template has seven parameters: the seven answers to the proposal-specific questions of section 4. --><br />
{|style="background:#FAF3E9;margin:none;border:3px double #AAA;-moz-border-radius:20px 5px 20px 5px;-webkit-border-radius:20px 5px 20px 5px;border-radius:20px 5px 20px 5px;"<br />
|-<br />
| style="text-align: left; padding: 0px 10px 5px 10px"|<br />
==Questionnaire==<br />
|-<br />
| style="text-align: center; padding:0px 10px 10px 10px;"|[[#1) Basics|Basics]] - [[#2) Experience|Experience]] - [[#3) Communication skills|Communication skills]] - [[#4) Project|Project]] - [[#5) Practical considerations|Practical considerations]]<br />
|}<br />
===1) Basics===<br />
====1.1) Write a small introduction to yourself.====<br />
My name is Étienne Simon (forename: Étienne), I'm 20 years old and I live in Paris, France. I really enjoy programming, particularly in C++ and I would like to use my programming skills on a big project like Wesnoth. Also, this year I'll participate in [http://www.prologin.org Prologin] for the third time. It's the French national programming contest, which I have been 6th and two times finalist.<br />
<br />
====1.2) State your preferred email address.====<br />
Address (at gmail dot com): etienne.jl.simon<br />
<br />
====1.3) If you have chosen a nick for IRC and Wesnoth forums, what is it?====<br />
ejls<br />
<br />
====1.4) Why do you want to participate in summer of code?====<br />
First of all, I can say I have only theoretical knowledge so far and I believe thanks to a SoC on Wesnoth, I can gain lot of experience since I'll work work on a real project. In addition to that, like I said, I like programming, being paid to do what you like doing is quite cool. Besides, I'm using open source softwares a lot, so it would be nice if my first work could be for the open source community. And of course, for the T-Shirt.<br />
<br />
====1.5) What are you studying, subject, level and school?====<br />
I'm in third and last year of a bachelor's degree (licence) in computer science at Pierre et Marie Curie, Sorbonne Université ([http://www.upmc.fr UPMC], Paris VI), I mainly took courses related to algorithm and artificial intelligence. Next year, I'll start a master's degree in artificial intelligence and decision.<br />
<br />
====1.6) What country are you from, at what time are you most likely to be able to join IRC?====<br />
I'm from France, CEST (UTC+2 during summer). I always have an irssi running on a server, but I'm more likely to answer during the afternoon and evening. However before the end of the Spring term (4th of June), I'll be able to connect at these times only the weekend and on Friday, I wont be available before 6p.m. UTC for the rest of the week.<br />
<br />
====1.7) Do you have other commitments for the summer period ? Do you plan to take any vacations ? If yes, when.====<br />
My term (including exams) ends the 4th of June, otherwise I'm considering the GSoC as a full-time job (with more fun and week-end included), therefore I don't have any plans for this summer.<br />
<br />
===2) Experience===<br />
====2.1) What programs/software have you worked on before?====<br />
Only school projects:<br />
<br />
Two years ago (during my first year), we had to code a go/othelo-like game in C. I wrote the game with some extra: a curse interface, a simple AI (alpha-beta) and an AI using unsupervised learning, for this last part, I used NEAT <span style="color: #888; font-size: 0.85em;">[NeuroEvolution of Augmenting Topologies]</span> (a genetical algorithm evolving neural networks), it didn't beat the minimax though :(. Total: 5000 SLOC <span style="color: #888; font-size: 0.85em;">[Source Lines Of Code]</span>.<br />
<br />
Last year, we wrote a BASIC compiler in C (again). I improved the BASIC language a bit: support for array, UDT, function overload and operator overload, the support of references was buggy (poorly designed). Total: 7000 ugly, messy SLOC.<br />
<br />
This year, we had to wrote an image manipulation program in C++ (finally!). I used Gtkmm (a C++ wrapper of Gtk+). The result was pretty good, documented with Doxygen and compilable with CMake or with a basic Makefile. Overall, It allowed me to get familiar with C++11 since before this project I've always used gcc 4.2. Total: 5000 SLOC (doxygen documentation (including code) available [http://epsilon012.free.fr/egami online]).<br />
<br />
====2.2) Have you developed software in a team environment before? (As opposed to hacking on something on your own)====<br />
The group projects that I worked in were about web development and database administration so I can't really say yes, but that's one of the main reasons why I want to participate in GSoC.<br />
<br />
====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?====<br />
No, not yet. :)<br />
<br />
====2.4) Are you already involved with any open source development projects? If yes, please describe the project and the scope of your involvement.====<br />
No.<br />
<br />
====2.5) Gaming experience - Are you a gamer?====<br />
Yes, everyone like to play. ;)<br />
<br />
=====2.5.1) What type of gamer are you?=====<br />
Hum… I suppose the answers in this subsection can give you an idea about my type. If I'm playing a game it's to have fun, so I'm a "for the lulz gamer", but I suppose it's the same for most people.<br />
<br />
=====2.5.2) What type of games?=====<br />
Turn-based games like Nethack, Freeciv and of course Wesnoth. I enjoy both strategy and role-playing games, but I like to have time to take a decision.<br />
<br />
I also enjoy programming games like jousting, golfing (with Vim) and programming in esoteric languages. For example, I have completed the three first questions of the French national programming contest's qualification in brainfuck, befunge and whitespace (code [http://epsilon012.free.fr/Prologin2012 here], including a 5289 instructions brainfuck program).<br />
<br />
=====2.5.3) What type of opponents do you prefer?=====<br />
Players using original and unexpected strategy. The HODOR players were really funny, but well…<br />
<br />
=====2.5.4) Are you more interested in story or gameplay?=====<br />
I tend to select a game on his gameplay, but when it misses a good story I'm less likely to play it.<br />
<br />
=====2.5.5) Have you played Wesnoth? If so, tell us roughly for how long and whether you lean towards single player or multiplayer.=====<br />
Not that much, actually I discovered Wesnoth 1.6 two years ago and I can't really say I've played it a lot since then. I prefer to play usually as single player, after completing most of the mainline campaigns (of which I really liked DiD), I played online, but now I'm mostly playing add-ons campaigns. As an indicator: I'm still unable to list drakes units.<br />
<br />
====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.====<br />
I have been lurking the code for a good time now, in January 2011, I reported 3 bugs with 1-line patch attached:<br />
*Two compilation errors: [https://gna.org/bugs/?17584 Bug #17584] and [https://gna.org/bugs/?17585 Bug #17585].<br />
*A minimap bug: [https://gna.org/bugs/?17676 Bug #17676].<br />
I have also written longer patches:<br />
*'''(AI)''' [https://gna.org/patch/?3185 Patch #3185] <code>power_projection</code> improvement, it now takes in account future ToD and time areas, I also cleaned the code a bit (task from the [[EasyCoding]] page.)<br />
*'''(WB)''' [https://gna.org/patch/?3201 Patch #3201] Make leader unable to move when invalidating a planned recall (fixes [https://gna.org/bugs/?19581 Bug #19581] that I found reading the whiteboard code.)<br />
I have gained commit access the 02/04/2012.<br />
<br />
===3) Communication skills===<br />
====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.====<br />
I have studied one term in London last winter, so, my level is good enough to understand and to be understood, don't expect an error-free essay from me though. :)<br />
<br />
====3.2) What spoken languages are you fluent in?====<br />
French and English.<br />
<br />
====3.3) Are you good at interacting with other players? Our developer community is friendly, but the player community can be a bit rough.====<br />
I'm a really calm person, I always take my time to answer messages. Otherwise, I'm ignoring flamers, I think it's the best to do.<br />
<br />
====3.4) Do you give constructive advice?====<br />
I try to.<br />
<br />
====3.5) Do you receive advice well?====<br />
Well, I enjoy receiving advices and learning, otherwise I wouldn't be here. :)<br />
<br />
====3.6) Are you good at sorting useful criticisms from useless ones?====<br />
I think most criticisms are useful, I'm used to the Internet though, troll don't ambush me.<br />
<br />
====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====<br />
It depends of what have to be done, the bigger the work is the more it has to be discussed. However if my proposal is retained, I might be a bit more scared of doing something bad in the beginning, so I might discuss a solution more than usual. :)<br />
<br />
===4) Project===<br />
====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?====<br />
<noinclude>'''Note: this page is a template, the answer to this question is a parameter. Please, refer to a proposal page.'''</noinclude>{{{1|}}}<br />
<br />
====4.2) If you have invented your own project, please describe the project and the scope.====<br />
<noinclude>'''Note: this page is a template, the answer to this question is a parameter. Please, refer to a proposal page.'''</noinclude>{{{2|}}}<br />
<br />
====4.3) Why did you choose this project?====<br />
<noinclude>'''Note: this page is a template, the answer to this question is a parameter. Please, refer to a proposal page.'''</noinclude>{{{3|}}}<br />
<br />
====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".====<br />
<noinclude>'''Note: this page is a template, the answer to this question is a parameter. Please, refer to a proposal page.'''</noinclude>{{{4|}}}<br />
<br />
====4.5) Include as much technical detail about your implementation as you can====<br />
<noinclude>'''Note: this page is a template, the answer to this question is a parameter. Please, refer to a proposal page.'''</noinclude>{{{5|}}}<br />
<br />
====4.6) What do you expect to gain from this project?====<br />
<noinclude>'''Note: this page is a template, the answer to this question is a parameter. Please, refer to a proposal page.'''</noinclude>{{{6|}}}<br />
<br />
====4.7) What would make you stay in the Wesnoth community after the conclusion of SOC?====<br />
<noinclude>'''Note: this page is a template, the answer to this question is a parameter. Please, refer to a proposal page.'''</noinclude>{{{7|}}}<br />
<br />
===5) Practical considerations===<br />
====5.1) Are you familiar with any of the following tools or languages?====<br />
*Subversion<br />
:I've already used it, but I've opted for git instead.<br />
*C++ (language used for all the normal source code)<br />
:I'm a big fan. I follow the WG21 publications and I often read comp.std.c++ and comp.lang.c++.moderated.<br />
*STL, Boost, Sdl (C++ libraries used by Wesnoth)<br />
:I'm of course used to the stdlib (not to all addition of C++11 though). I'm not familiar with all Boost (I don't have enough brain for this). But I have often used the parts of Boost that's are now (more or less) in the C++11 stdlib and the MPL. I also used a bit Asio, Filesystem and Phoenix (for being the most WTF library), and some other small libraries like Program Option and Range. I never worked on a project using the SDL, I'm not a big GUI user.<br />
*Python (optional, mainly used for tools)<br />
:Not really, no, really basic.<br />
*build environments (eg cmake/scons)<br />
:I've already wrote some CMakeList.txt, but I never worked with nor used scons.<br />
*WML (the wesnoth specific scenario language)<br />
:I wrote a [[User:Ejls/Vim|Vim syntax]] file for it, so I'm already a bit familiar with it. I'm missing practice though.<br />
*Lua (used in combination with WML to create scenarios)<br />
:I'm familiar with it, not as much as C++ but I already used it as a scripting language for an (annoying) IRC bot I wrote. I'm not familiar with its integration in Wesnoth though.<br />
<br />
====5.2) Which tools do you normally use for development? Why do you use them?====<br />
Vim and Unix tools, Perl for big stuff. They are the most productive tools for me, I'm used to them. I'm coding with a laptop under OpenBSD (with gcc 4.2). I also compile Wesnoth on a Debian server (with gcc 4.6), but the X over ssh is a bit slow sometimes. Finally, I temporally have a laptop with FreeBSD 9.0.<br />
<br />
====5.3) What programming languages are you fluent in?====<br />
I'm good in C++, C, Lua, Perl and VimScript. I've a lack of practice in Java, Caml, Scheme, NetLogo, CLIPS and AiML (all of them learnt during my studies). On a different note, I like brainfuck, befunge, whitespace and golfscript.<br />
<br />
====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!====<br />
If you can't join me by email or on IRC, I'm probably dead but sometimes it's easier to speak than to write so I'll include my phone number in my application.</div>Ejlshttps://wiki.wesnoth.org/index.php?title=User:Ejls/GSoC_2012/Whiteboard_Backend_Refactoring&diff=46375User:Ejls/GSoC 2012/Whiteboard Backend Refactoring2012-04-10T02:38:09Z<p>Ejls: Formating</p>
<hr />
<div><!--<br />
Excuse the heavy wikitext, I tried to make it as readable as possible and I put a lot of comments.<br />
-->__NOTOC__<!--<br />
-->__NOEDITSECTION__<!--<br />
-->{{SoC2012Student}}<!--<br />
-->[[Category:SoC_Ideas_Whiteboard_Backend_Refactoring_2012]]<!--<br />
-->'''''Note: This proposal is in continuous construction, if you have any remark, please drop me a line on IRC or on the [[{{TALKPAGENAME}}|talk page]].'''''<br /><br /><br />
<br />
<!--***********************************************************************<br />
* * Table of Content * *<br />
* ******************** *<br />
* *<br />
* WARNING: don't forget to add a TOC entry when adding a new section. *<br />
***********************************************************************--><br />
{|style="background:#FAF3E9;margin:none;padding:5px;border:3px double #AAA;-moz-border-radius:20px 5px 20px 5px;-webkit-border-radius:20px 5px 20px 5px;border-radius:20px 5px 20px 5px;"<br />
|-<br />
| style="text-align: center; padding: 0px 10px 5px 10px;"|'''Content'''<hr /><br />
|-<br />
| style="text-align: left; padding:0px 10px 10px 10px;"|<br />
[[#Description|Description]]<br /><br />
[[#SoC Application|SoC Application]]<br /><br />
[[#Contact|Contact]]<br /><br />
[[#Questionnaire|Questionnaire]]<br /><br />
:[[#1) Basics|1 - Basics]]<br /><br />
:[[#2) Experience|2 - Experience]]<br /><br />
:[[#3) Communication skills|3 - Communication skills]]<br /><br />
:[[#4) Project|4 - Project]]<br /><br />
:[[#5) Practical considerations|5 - Practical considerations]]<br /><br />
[[#Proposal|Proposal]]<br /><br />
:[[#The problems|The problems]]<br /><br />
:[[#side_actions|<tt>side_actions</tt> refactoring]]<br /><br />
::[[#side_actions.situation|The current situation]]<br /><br />
::[[#side_actions.idea|The idea]]<br /><br />
::[[#side_actions.implementation|Implementation details]]<br /><br />
:::[[#side_actions.containers|Choice of the containers]]<br /><br />
:::[[#side_actions.example|Example]]<br /><br />
:::[[#side_actions.reconsideration|Reconsideration of Boost.MultiIndex]]<br /><br />
:[[#visitorhier|Visitor hierarchy refactoring]]<br /><br />
::[[#visitorhier.situation|The current situation]]<br /><br />
::[[#visitorhier.idea|The idea]]<br /><br />
::[[#visitorhier.implementation|Implementation details]]<br /><br />
:::[[#visitorhier.example|Example]]<br /><br />
:[[#actioncore|Transfer of the action and validation logic into the core]]<br /><br />
::[[#actioncore.situation|The current situation]]<br /><br />
::[[#actioncore.idea|The idea]]<br /><br />
::[[#actioncore.implementation|Implementation details]]<br /><br />
:::[[#actioncore.whiteboard|Changes in the Whiteboard]]<br /><br />
:::[[#actioncore.example|Example]]<br /><br />
:::[[#actioncore.deserialization|Deserialization]]<br /><br />
:[[#polishing|Polishing]]<br /><br />
::[[#polishing.mapbuilder|<tt>mapbuilder</tt>]]<br /><br />
::[[#polishing.swap_check|Validation of action swapping]]<br /><br />
::[[#polishing.manager_pimpl|Usage of a PIMPL in <tt>manager</tt>]]<br /><br />
:[[#designdoc|Design document]]<br /><br />
:[[#Openings|Openings]]<br /><br />
:[[#Timeline|Timeline]]<br /><br />
|}<br />
<br />
<!--***********************************************************************<br />
* * Description * *<br />
* *************** *<br />
* *<br />
* This section is inserted in the SummerOfCodeIdeas page. It contains *<br />
* only a header of level 4 and a small paragraph summing up the *<br />
* proposal. *<br />
***********************************************************************--><br />
==Description==<br />
====Étienne Simon - Whiteboard backend polishing====<br />
My project is to make the Whiteboard code cleaner and to redesign small parts of it to speed it up. The global design of the Whiteboard won't be changed a lot, each part will be reviewed individually. I'm not only planning to improve the Whiteboard backend, but also to document the overall design and each part of it as well as to write a wide variety of test to improve its stability. Moreover, I'll factorise action handling outside of the Whiteboard so that the same code will be usable in all Wesnoth.<!--<br />
--><br />
<!--***********************************************************************<br />
* * SoC Application * *<br />
* ******************* *<br />
* *<br />
* This section affect the SummerOfCodeIdeas page, if it contains the *<br />
* text "Submitted to google", the application will appear in the *<br />
* "Student proposals submitted both to wiki and google" section, *<br />
* otherwise it'll appear in the "Student proposals not submitted to *<br />
* google" section. *<br />
***********************************************************************--><br />
==SoC Application==<br />
Submitted to google<!--<br />
--><br />
<!--***********************************************************************<br />
* * Contact * *<br />
* *********** *<br />
* *<br />
* The IRC subsection is inserted in the SummerOfCodeIdeas page. It *<br />
* must only contain the IRC nick identifying the author. *<br />
***********************************************************************--><br />
==Contact==<br />
{|<br />
|-<br />
|<br />
=====IRC=====<br />
<span style="color:#3F475E;">ejls </span><br />
=====Email=====<br />
Address at gmail dot com: etienne.jl.simon<br />
| style="width:10em;" |<br />
|<br />
=====Forum=====<br />
ejls<br />
=====Gna=====<br />
ejls<br />
|}<br />
<br />
<!--***********************************************************************<br />
* * Questionnaire * *<br />
* ***************** *<br />
* *<br />
* Although I'm submitting only one application (and so only one *<br />
* questionnaire), I thought it was more elegant to make the *<br />
* questionnaire page reusable. Which explain why it's a template. *<br />
* Like I wrote in the Questionnaire subpage, the argument to this *<br />
* template are the answer to the proposal-specific questions. I order *<br />
* to make the sources more comprehensible, I wrote the corresponding *<br />
* question in comments at the beginning of each parameter. *<br />
***********************************************************************--><br />
{{User:Ejls/GSoC 2012/Questionnaire<br />
|<!-- 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? --><br />
''This is a summary, more details can be found [http://wiki.wesnoth.org/User:Ejls/GSoC%202012/Whiteboard%20Backend%20Refactoring#Proposal here].''<br />
<br />
I originally chose [[SoC Ideas Whiteboard Backend Refactoring 2012]], however it evolved a lot thanks to Gabba and Crab. This project is the only one not adding any feature for the user, the main goal is to refactor code, write test and documentation. It follows [http://wiki.wesnoth.org/GSoC-WesnothWhiteboard_Gabba Gabba's project] and [http://wiki.wesnoth.org/User:Tschmitz tschmitz's project] on the Whiteboard. Although it doesn't add any feature for the user in itself, I hope it'll help future development of the Whiteboard.<!--<br />
-->|<!-- 4.2) If you have invented your own project, please describe the project and the scope. --><br />
I chose a project from the list, namely [[SoC Ideas Whiteboard Backend Refactoring 2012]]. C.f. above answer.<!--<br />
-->|<!-- 4.3) Why did you choose this project? --><br />
I liked the idea behind the Whiteboard, I think it might be a big plus to Wesnoth. Furthermore, I liked how C++ is used in its code (especially the heavy use of SBRM). However it looks like the Whiteboard is not widely used, and I would like to help changing that! :)<!--<br />
-->|<!-- 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". --><br />
''This is a summary, more details can be found [http://wiki.wesnoth.org/User:Ejls/GSoC%202012/Whiteboard%20Backend%20Refactoring#Timeline here].''<br />
<br />
I separated my summer in five phases:<br />
*Phase 0: Approach (4 weeks)<br />
::→ Start working on the design document. Start the ''polishing''.<br />
*Phase 1: <code>side_actions</code> refactoring (3 weeks)<br />
*Phase 2: Validator hierarchy refactoring (3 weeks)<br />
*Phase 3: Transfer of the action and validation logic into the core (3 weeks)<br />
*Phase 4: Finalisation (3 weeks)<br />
::→ Finish the design document. Finish the ''polishing''. Test. Test. Test.<!--<br />
-->|<!-- 4.5) Include as much technical detail about your implementation as you can --><br />
''This is a summary, more details can be found [http://wiki.wesnoth.org/User:Ejls/GSoC%202012/Whiteboard%20Backend%20Refactoring#Proposal here].''<br />
<br />
I separated my project in five tasks:<br />
;<code>side_actions</code> refactoring<br />
:Change of the underlying container, creation of new look up functions.<br />
;Visitor hierarchy refactoring<br />
:Replacement of the <code>enable_visit_all</code> by a new interface over all of the <code>side_actions</code> objects.<br />
;Transfer of the action and validation logic into the core<br />
:Refactoring of <code>wb::action</code> in a Whiteboard-independent hierarchy.<br />
;Polishing<br />
:Code uniformisation, small improvements.<br />
;Design document<br />
:Documentation of the global Whiteboard design.<!--<br />
-->|<!-- 4.6) What do you expect to gain from this project? --><br />
I hope it'll help me to join the open source developer community. Actually, the preparation of this proposal already helped me a lot, for example my first patch got committed, it wasn't a big patch, but it was my first step of a (I hope) long path. :) So, I hope to continue learning to walk with the wesnoth community (sorry for the silly metaphor.)<!--<br />
-->|<!-- 4.7) What would make you stay in the Wesnoth community after the conclusion of SOC? --><br />
If my work is appreciated, I would rather ask: what would make me leave the Wesnoth community?.<!--<br />
-->}}<br />
<br />
<!--***********************************************************************<br />
* * Proposal * *<br />
* ************ *<br />
* *<br />
* Finally, my proposal. ;) *<br />
***********************************************************************--><br />
==Proposal==<br />
===The problems===<br />
In the [[SoC_Ideas_Whiteboard_Backend_Refactoring_2012|Whiteboard Backend Refactoring idea page]], several problems are listed, here is how I'm planning to fix them:<br />
{| style="border:1px dashed #AAA;border-collapse:collapse;"<br />
|-<br />
!style="border:1px dotted #AAA;padding:5px;"|Problem<br />
!style="border:1px dotted #AAA;padding:5px;"|Solution<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|<code>side_actions</code> complexity<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#side_actions|<code>side_actions</code> refactoring]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|Redundancy between <code>mapbuilder</code> and <code>validate_visitor</code><br />
|style="border:1px dotted #AAA;padding:5px;"|[[#visitorhier|Visitor hierarchy refactoring]], [[#actioncore|Transfer of the action and validation logic into the core]] and [[#Polishing|Polishing]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|Highlighter slowness<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#side_actions|<code>side_actions</code> refactoring]] and [[#visitorhier|Visitor hierarchy refactoring]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|Action handling decentralization<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#actioncore|Transfer of the action and validation logic into the core]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|Friend classes vs everything in the action classes<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#visitorhier|Visitor hierarchy refactoring]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|Unit pointer recovery uniformisation<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#polishing|Polishing]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|<code>boost::dynamic_pointer_cast</code> vs simple numeric id<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#polishing|Polishing]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|Documentation<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#designdoc|Design document]]<br />
|}<br />
<br />
===<span id="side_actions"><code>side_actions</code> refactoring</span>===<br />
====<span id="side_actions.situation">The current situation</span>====<br />
The current implementation of <code>side_actions</code> use a <code>std::deque&lt;std::deque&lt;action_ptr&gt;&gt;</code>.<br />
In order to use it, iterators have been defined over it (<code>side_actions::iterator</code> and the three const and reverse variants).<br />
These “flattening” iterators let users of <code>side_actions</code> iterate over all the planned actions, they are performing the ''zip'' operation on the fly.<br />
<br />
Furthermore, some queries like <code>side_actions::find_first_action_of</code> are linear in the number of action.<br />
<br />
====<span id="side_actions.idea">The idea</span>====<br />
To simplify the code, I propose to keep the action set zipped. The container's iterators will then be usable directly. In order to delimit turns, a second container will have to keep a sequence of iterators pointing to the first action of each turn.<br />
<br />
For example, let's say eight actions are planned: five for this turn, two for the next turn and one for the turn after. Three iterators will be kept to delimit turns. Here is a proof that I can't use gimp which also show the idea:<br />
http://epsilon012.free.fr/GSoC%202012/side_actions%20idea.png<br />
<br />
Of course another problem emerge: the sequence of iterator has to be kept in sync with the sequence of action.<br />
<br />
Finally, the current implementation gives access to the <code>action_ptr</code> only in sequence, in order to speed up different way of querying action (e.g. by hex, by unit's id), I propose to build several indexes on the action set.<br />
<br />
====<span id="side_actions.implementation">Implementation details</span>====<br />
Let's name these containers <code>actions_</code> and <code>turn_beginnings_</code>.<br />
<br />
The Whiteboard have the following invariant: an empty turn (a turn without planned action) can't be followed by a non-empty turn (with at least one planned action). It means that <code>distance(turn_beginnings_[i], turn_beginnings_[i+1])&gt;0</code>, and so we can unambiguously determine the turn number of each action.<br />
<br />
Also, note that except when <code>actions_.empty()</code> : <code>turn_beginnings_.front()==actions_.begin()</code>.<br />
<br />
=====<span id="side_actions.containers">Choice of the containers</span>=====<br />
<code>std::deque</code> seems to be the perfect container for <code>turn_beginnings_</code>. It'll allow random access and we need to add/remove new turns only at the extremities.<br />
<br />
On the other hand, <code>actions_</code> need three proprieties:<br />
*Allow fast chronological iteration<br />
*Stable iterators<br />
*Allow fast lookup on different indexes<br />
I propose to use a <code>boost::multi_index_container</code>, this container is part of the library [http://www.boost.org/doc/libs/1_49_0/libs/multi_index Boost.MultiIndex] which is in Boost since version 1.32. It allows the construction of several indexes on the same set of object.<br />
<br />
There is however one problem linked to the use of the <code>boost::multi_index::random_access</code> index: insertion and deletion are in linear time when their are not done at the extremities.<br />
<br />
So, the new members should be:<br />
<!-- Original:<br />
namespace bmi = boost::multi_index;<br />
typedef bmi::multi_index_container<<br />
action_ptr,<br />
bmi::indexed_by<<br />
bmi::random_access<bmi::tag<chronological> >,<br />
bmi::hashed_non_unique<bmi::tag<by_unit>, bmi::const_mem_fun<action,size_t,&action::get_unit_id> >,<br />
bmi::hashed_non_unique<bmi::tag<by_hex>, bmi::const_mem_fun<action,map_location,&action::get_hex> ><br />
><br />
> action_set;<br />
typedef action_set::iterator iterator;<br />
<br />
action_set actions_;<br />
std::deque<iterator> turn_beginnings_;<br />
Formated: --><code><div style="border: 1px dashed #AAA;background:#FAF3E9;padding:7px;"><span style="color:#000000; font-weight:bold">namespace</span> bmi <span style="color:#000000">=</span> boost<span style="color:#000000">::</span>multi_index<span style="color:#000000">;</span><br /><span style="color:#000000; font-weight:bold">typedef</span> bmi<span style="color:#000000">::</span>multi_index_container<span style="color:#000000">&lt;</span><br />&nbsp; &nbsp; action_ptr<span style="color:#000000">,</span><br />&nbsp; &nbsp; bmi<span style="color:#000000">::</span>indexed_by<span style="color:#000000">&lt;</span><br />&nbsp; &nbsp; &nbsp; &nbsp; bmi<span style="color:#000000">::</span>random_access<span style="color:#000000">&lt;</span>bmi<span style="color:#000000">::</span>tag<span style="color:#000000">&lt;</span>chronological<span style="color:#000000">&gt; &gt;,</span><br />&nbsp; &nbsp; &nbsp; &nbsp; bmi<span style="color:#000000">::</span>hashed_non_unique<span style="color:#000000">&lt;</span>bmi<span style="color:#000000">::</span>tag<span style="color:#000000">&lt;</span>by_unit<span style="color:#000000">&gt;,</span> bmi<span style="color:#000000">::</span>const_mem_fun<span style="color:#000000">&lt;</span>action<span style="color:#000000">,</span><span style="color:#0057ae">size_t</span><span style="color:#000000">,&amp;</span>action<span style="color:#000000">::</span>get_unit_id<span style="color:#000000">&gt; &gt;,</span><br />&nbsp; &nbsp; &nbsp; &nbsp; bmi<span style="color:#000000">::</span>hashed_non_unique<span style="color:#000000">&lt;</span>bmi<span style="color:#000000">::</span>tag<span style="color:#000000">&lt;</span>by_hex<span style="color:#000000">&gt;,</span> bmi<span style="color:#000000">::</span>const_mem_fun<span style="color:#000000">&lt;</span>action<span style="color:#000000">,</span><span style="color:#000000">map_location</span><span style="color:#000000">,&amp;</span>action<span style="color:#000000">::</span>get_hex<span style="color:#000000">&gt; &gt;</span><br />&nbsp; &nbsp; &nbsp; &nbsp; <span style="color:#000000">&gt;</span><br />&nbsp; &nbsp; <span style="color:#000000">&gt;</span> action_set<span style="color:#000000">;</span><br /><span style="color:#000000; font-weight:bold">typedef</span> action_set<span style="color:#000000">::</span>iterator iterator<span style="color:#000000">;</span><br /><br />action_set actions_<span style="color:#000000">;</span><br />std<span style="color:#000000">::</span>deque<span style="color:#000000">&lt;</span>iterator<span style="color:#000000">&gt;</span> turn_beginnings_<span style="color:#000000">;</span><br /></div></code><br /><br />
<br />
This suppose two new pure virtual functions in <code>action</code>: <code>get_unit_id</code> and <code>get_hex</code>.<br />
<br />
Using action's attribute as key brings another drawback: we must notify the <code>multi_index_container</code> when we modify a key.<br />
However, the two used keys here (the unit's id and the hex) are never modified in the <code>action</code> hierarchy.<br />
<br />
This definition is here to give an idea, in practice other indexes will have to be built (e.g. an index on ''secondary hex'' which could be the source hex in <code>move</code>.)<br />
Note that this doesn't necessarily means a new pure virtual function in <code>action</code>, a key extractor can be defined to let <code>action</code> as it is and use ''RTTI'' instead (this might not be clever though.)<br />
<br />
=====<span id="side_actions.example">Example</span>=====<br />
Here are three functions rewritten with this new design. Note that <code>side_actions::iterator</code> is the one defined above.<br />
<br />
<!-- Original:<br />
side_actions::iterator side_actions::end_turn(size_t turn_num){<br />
if(turn_num+1 >= turn_beginnings_.size())<br />
return actions_.end();<br />
else<br />
return turn_beginnings_[turn_num+1];<br />
}<br />
Formated: --><code><div style="border: 1px dashed #AAA;background:#FAF3E9;padding:7px;">side_actions<span style="color:#000000">::</span>iterator side_actions<span style="color:#000000">::</span><span style="color:#010181">end_turn</span><span style="color:#000000">(</span><span style="color:#0057ae">size_t</span> turn_num<span style="color:#000000">){</span><br />&nbsp; &nbsp; <span style="color:#000000; font-weight:bold">if</span><span style="color:#000000">(</span>turn_num<span style="color:#000000">+</span><span style="color:#b07e00">1</span> <span style="color:#000000">&gt;=</span> turn_beginnings_<span style="color:#000000">.</span><span style="color:#010181">size</span><span style="color:#000000">())</span><br />&nbsp; &nbsp; &nbsp; &nbsp; <span style="color:#000000; font-weight:bold">return</span> actions_<span style="color:#000000">.</span><span style="color:#010181">end</span><span style="color:#000000">();</span><br />&nbsp; &nbsp; <span style="color:#000000; font-weight:bold">else</span><br />&nbsp; &nbsp; &nbsp; &nbsp; <span style="color:#000000; font-weight:bold">return</span> turn_beginnings_<span style="color:#000000">[</span>turn_num<span style="color:#000000">+</span><span style="color:#b07e00">1</span><span style="color:#000000">];</span><br /><span style="color:#000000">}</span><br /></div></code><br /><br />
<br />
<!-- Original:<br />
side_actions::iterator side_actions::raw_enqueue(size_t turn_num, action_ptr act){<br />
assert(turn_num <= turn_beginnings_.size());<br />
<br />
iterator new_action = actions_.insert(end_turn(turn_num), act).first;<br />
<br />
if(turn_num >= turn_beginnings_.size())<br />
turn_beginnings_.push_back(new_action);<br />
<br />
return new_action;<br />
}<br />
Formated: --><code><div style="border: 1px dashed #AAA;background:#FAF3E9;padding:7px;">side_actions<span style="color:#000000">::</span>iterator side_actions<span style="color:#000000">::</span><span style="color:#010181">raw_enqueue</span><span style="color:#000000">(</span><span style="color:#0057ae">size_t</span> turn_num<span style="color:#000000">,</span> action_ptr act<span style="color:#000000">){</span><br />&nbsp; &nbsp; <span style="color:#000000; font-weight:bold">assert</span><span style="color:#000000">(</span>turn_num <span style="color:#000000">&lt;=</span> turn_beginnings_<span style="color:#000000">.</span><span style="color:#010181">size</span><span style="color:#000000">());</span><br /><br />&nbsp; &nbsp; iterator new_action <span style="color:#000000">=</span> actions_<span style="color:#000000">.</span><span style="color:#010181">insert</span><span style="color:#000000">(</span><span style="color:#010181">end_turn</span><span style="color:#000000">(</span>turn_num<span style="color:#000000">),</span> act<span style="color:#000000">).</span>first<span style="color:#000000">;</span><br /><br />&nbsp; &nbsp; <span style="color:#000000; font-weight:bold">if</span><span style="color:#000000">(</span>turn_num <span style="color:#000000">&gt;=</span> turn_beginnings_<span style="color:#000000">.</span><span style="color:#010181">size</span><span style="color:#000000">())</span><br />&nbsp; &nbsp; &nbsp; &nbsp; turn_beginnings_<span style="color:#000000">.</span><span style="color:#010181">push_back</span><span style="color:#000000">(</span>new_action<span style="color:#000000">);</span><br /><br />&nbsp; &nbsp; <span style="color:#000000; font-weight:bold">return</span> new_action<span style="color:#000000">;</span><br /><span style="color:#000000">}</span><br /></div></code><br /><br />
<br />
<!-- Original:<br />
side_actions::find_first_action_of(unit const* unit, side_actions::iterator start_position){<br />
// First we get all the action of this unit<br />
typedef action_set::index<by_unit>::type::iterator unit_iterator;<br />
std::pair<unit_iterator, unit_iterator> act = actions_.get<by_unit>().equal_range(unit->underlying_id());<br />
<br />
// Then we find the first of them (chronologically) after start_position<br />
iterator first = actions_.end();<br />
for(unit_iterator it = act.first; it != act.second; ++it){<br />
iterator chrono_it = actions_.project<chronological>(it);<br />
if(chrono_it < first && chrono_it > start_position)<br />
first = chrono_it;<br />
}<br />
return first;<br />
}<br />
Formated: --><code><div style="border: 1px dashed #AAA;background:#FAF3E9;padding:7px;">side_actions<span style="color:#000000">::</span><span style="color:#010181">find_first_action_of</span><span style="color:#000000">(</span>unit <span style="color:#0057ae">const</span><span style="color:#000000">*</span> unit<span style="color:#000000">,</span> side_actions<span style="color:#000000">::</span>iterator start_position<span style="color:#000000">){</span><br />&nbsp; &nbsp; <span style="color:#838183; font-style:italic">// First we get all the action of this unit</span><br />&nbsp; &nbsp; <span style="color:#000000; font-weight:bold">typedef</span> action_set<span style="color:#000000">::</span>index<span style="color:#000000">&lt;</span>by_unit<span style="color:#000000">&gt;::</span>type<span style="color:#000000">::</span>iterator unit_iterator<span style="color:#000000">;</span><br />&nbsp; &nbsp; std<span style="color:#000000">::</span>pair<span style="color:#000000">&lt;</span>unit_iterator<span style="color:#000000">,</span> unit_iterator<span style="color:#000000">&gt;</span> act <span style="color:#000000">=</span> actions_<span style="color:#000000">.</span>get<span style="color:#000000">&lt;</span>by_unit<span style="color:#000000">&gt;().</span><span style="color:#010181">equal_range</span><span style="color:#000000">(</span>unit<span style="color:#000000">-&gt;</span><span style="color:#010181">underlying_id</span><span style="color:#000000">());</span><br /><br />&nbsp; &nbsp; <span style="color:#838183; font-style:italic">// Then we find the first of them (chronologically) after start_position</span><br />&nbsp; &nbsp; iterator first <span style="color:#000000">=</span> actions_<span style="color:#000000">.</span><span style="color:#010181">end</span><span style="color:#000000">();</span><br />&nbsp; &nbsp; <span style="color:#000000; font-weight:bold">for</span><span style="color:#000000">(</span>unit_iterator it <span style="color:#000000">=</span> act<span style="color:#000000">.</span>first<span style="color:#000000">;</span> it <span style="color:#000000">!=</span> act<span style="color:#000000">.</span>second<span style="color:#000000">; ++</span>it<span style="color:#000000">){</span><br />&nbsp; &nbsp; &nbsp; &nbsp; iterator chrono_it <span style="color:#000000">=</span> actions_<span style="color:#000000">.</span>project<span style="color:#000000">&lt;</span>chronological<span style="color:#000000">&gt;(</span>it<span style="color:#000000">);</span><br />&nbsp; &nbsp; &nbsp; &nbsp; <span style="color:#000000; font-weight:bold">if</span><span style="color:#000000">(</span>chrono_it <span style="color:#000000">&lt;</span> first <span style="color:#000000">&amp;&amp;</span> chrono_it <span style="color:#000000">&gt;</span> start_position<span style="color:#000000">)</span><br />&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; first <span style="color:#000000">=</span> chrono_it<span style="color:#000000">;</span><br />&nbsp; &nbsp; <span style="color:#000000">}</span><br />&nbsp; &nbsp; <span style="color:#000000; font-weight:bold">return</span> first<span style="color:#000000">;</span><br /><span style="color:#000000">}</span><br /></div></code><br />
<br />
=====<span id="side_actions.reconsideration">Reconsideration of Boost.MultiIndex</span>=====<br />
As Gabba noted ([http://www.wesnoth.org/irclogs/2012/03/%23wesnoth-dev.2012-03-31.log #wesnoth-dev 2012/03/31 7h18]), Boost.MultiIndex might be hard to debug and hard to use.<br />
This section try to reconsider the use of Boost.MultiIndex.<br />
<br />
The major problem we would run into while considering to write a replacement for Boost.MultiIndex is how to allow the usage of the standard algorithms. Indeed, they will be usable only on the underlying container and not on its ''view''. To overcome this, a simple solution have been used in Boost: they rewrote all the iterators. The problem is that, even if it now evolved in something bigger, the first goal with <code>side_actions</code> refactoring was to remove the iterator's definitions.<br />
<br />
While, indeed Boost.MultiIndex will make debugging harder and increase compilation time compared to an homemade solution.<br />
It offer numerous advantages:<br />
*It's generic, adding a new key will be as easy as adding a new template parameter in the definition.<br />
*It don't have to be rewritten. :)<br />
*It's already used in Wesnoth (thanks Mordante for noting it.)<br />
*It offers some advantages over the standard containers (e.g. a random-access container with stable iterators and strong exception guaranty.)<br />
<br />
===<span id="visitorhier">Visitor hierarchy refactoring</span>===<br />
====<span id="visitorhier.situation">The current situation</span>====<br />
The important classes and class templates of this hierarchy are:<br />
*'''<code>visitor</code>''', the base class of the visitor hierarchy, it dispatches the calls to the derived classes.<br />
*'''<code>enable_visit_all</code>''', which is actually an interface to the <code>action_ptr</code> objects of every single team.<br />
*'''<code>action</code>''', the root class of the visitable hierarchy.<br />
<br />
Currently, when the visitor hierarchy needs to visit the visitable hierarchy, all the actions of every sides of every turn are visited using the function <code>enable_visit_all::visit_all_helper</code> (e.g. this function is called by <code>highlight_visitor::find_main_highlight</code> to find the action to highlight.)<br />
<br />
====<span id="visitorhier.idea">The idea</span>====<br />
I'm favorable to the maintain of the Visitor pattern, it segregates the different components nicely.<br />
I think the problem come from <code>enable_visit_all</code> and I would like to replace it with a class offering a more fine-grained access to the actions.<br />
For example, a look up by hex could be defined in this new structure and then used by <code>highlight_visitor</code>.<br />
Actually, most of the work of this new class will have to do is to redirect the calls to the <code>side_actions</code> (to one in particular or to all depending on the function).<br />
<br />
====<span id="visitorhier.implementation">Implementation details</span>====<br />
Let's name this new class <code>action_set</code>.<br />
<br />
The sole problem faced is to place <code>action_set</code>, since it is mainly a proxy to a global resource (the <code>side_actions</code> of each team), it makes sense to place it directly in the <code>wb</code> namespace.<br />
<br />
Note that the access to the <code>action</code> hierarchy will no more be done through inheritance.<br />
<br />
=====<span id="visitorhier.example">Example</span>=====<br />
Here is an example function that would speed up <code>highlight_visitor</code>.<br />
<!-- Original:<br />
action_ptr action_set::action_at(map_location const &hex){<br />
side_actions::iterator result;<br />
foreach(team& side, *resources::teams){<br />
side_actions actions = side.get_side_actions();<br />
if((result = actions.find_action_at(hex)) != actions.end())<br />
return *result;<br />
}<br />
return action_ptr();<br />
}<br />
Formated: --><code><div style="border: 1px dashed #AAA;background:#FAF3E9;padding:7px;">action_ptr action_set<span style="color:#000000">::</span><span style="color:#010181">action_at</span><span style="color:#000000">(</span>map_location <span style="color:#0057ae">const</span> <span style="color:#000000">&amp;</span>hex<span style="color:#000000">){</span><br />&nbsp; &nbsp; side_actions<span style="color:#000000">::</span>iterator result<span style="color:#000000">;</span><br />&nbsp; &nbsp; <span style="color:#010181">foreach</span><span style="color:#000000">(</span>team<span style="color:#000000">&amp;</span> side<span style="color:#000000">, *</span>resources<span style="color:#000000">::</span>teams<span style="color:#000000">){</span><br />&nbsp; &nbsp; &nbsp; &nbsp; side_actions actions <span style="color:#000000">=</span> side<span style="color:#000000">.</span><span style="color:#010181">get_side_actions</span><span style="color:#000000">();</span><br />&nbsp; &nbsp; &nbsp; &nbsp; <span style="color:#000000; font-weight:bold">if</span><span style="color:#000000">((</span>result <span style="color:#000000">=</span> actions<span style="color:#000000">.</span><span style="color:#010181">find_action_at</span><span style="color:#000000">(</span>hex<span style="color:#000000">)) !=</span> actions<span style="color:#000000">.</span><span style="color:#010181">end</span><span style="color:#000000">())</span><br />&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; <span style="color:#000000; font-weight:bold">return</span> <span style="color:#000000">*</span>result<span style="color:#000000">;</span><br />&nbsp; &nbsp; <span style="color:#000000">}</span><br />&nbsp; &nbsp; <span style="color:#000000; font-weight:bold">return</span> <span style="color:#010181">action_ptr</span><span style="color:#000000">();</span><br /><span style="color:#000000">}</span><br /></div></code><br /><br />
<br />
Note: the implementation of <code>side_actions::find_action_at</code> is similar to the one of <code>side_actions::find_first_action_of</code>.<br />
<br />
===<span id="actioncore">Transfer of the action and validation logic into the core</span>===<br />
This is a (great) idea of Crab ([http://www.wesnoth.org/irclogs/2012/04/%23wesnoth-dev.2012-04-02.log #wesnoth-dev 2012/04/02 16h11]).<br />
<br />
====<span id="actioncore.situation">The current situation</span>====<br />
Currently, the code related to action execution and checking is duplicated in several places.<br />
For example, <code>ai::recall_result::do_check_before()</code>, <code>wb::validate_visitor::visit(recall_ptr)</code> and <code>do_replay_handle()</code> are doing the same thing: checking whether a recall is valid.<br />
Furthermore, the latter is also executing the recall, as is <code>wb::recall::execute()</code> and <code>ai::recall_result::do_execute()</code>.<br />
<br />
====<span id="actioncore.idea">The idea</span>====<br />
The idea is simple: factor the code.<br />
<br />
However, we must be careful not to include too many functionalities in this new hierarchy, it must be extensible as much as possible without having to modify it.<br />
<br />
The good thing with the current code duplication is that I'll be able to look at different code doing the same thing before choosing the best implementation. ;)<br />
<br />
====<span id="actioncore.implementation">Implementation details</span>====<br />
A nice point of <code>wb::action</code> is that Gabba used the visitor pattern, which is exactly what we need here.<br />
Indeed, some functions are strictly related to a module (for example the Whiteboard's highlighter), the visitor pattern will allow virtual functions to be defined outside of the visited hierarchy (the action hierarchy here), moreover the visited hierarchy doesn't need to be recompiled when a new visitor is added.<br />
<br />
The overhead of the visitor is really small: an additional (non-virtual) function call.<br />
<br />
Since the validation of an action is needed by all the game, it can be included as a member function <code>virtual bool valid() const =0;</code> in the action hierarchy.<br />
<br />
=====<span id="actioncore.whiteboard">Changes in the Whiteboard</span>=====<br />
It's a good idea to read this part even if you're not interested in the Whiteboard, indeed this gives you an idea on to extends this new action hierarchy.<br />
<br />
Currently, there is a Whiteboard-specific action: <code>suppose_dead</code>.<br />
Even if it's disabled for now, the new design need to consider it.<br />
Actually, the changes to do are pretty straightforward:<br />
*A new class <code>suppose_dead</code> is derived from <code>action</code><br />
*A new class <code>whiteboard_action_visitor</code> is derived from <code>action_visitor</code> and add a virtual function <code>visit(suppose_dead&amp;)</code><br />
That's all. :)<br />
Now, the sole Whiteboard visitor (<code>highlight_visitor</code>) can derive from <code>whiteboard_action_visitor</code> and override <code>visit(suppose_dead&amp;)</code>.<br />
<br />
What is important here is that we can still extends the <code>action</code> hierarchy which is in core, without modifying it.<br />
<br />
Of course, I'm planing to write <s>the same</s> a better explanation in the documentation. ;)<br />
<br />
=====<span id="actioncore.example">Example</span>=====<br />
Highlighting a recruit action in the Whiteboard:<br />
<!-- Original:<br />
recruit recruit_action(the_team, the_unit, the_hex);<br />
highlighter_->visit(recruit_action);<br />
Formated: --><code><div style="border: 1px dashed #AAA;background:#FAF3E9;padding:7px;">recruit <span style="color:#010181">recruit_action</span><span style="color:#000000">(</span>the_team<span style="color:#000000">,</span> the_unit<span style="color:#000000">,</span> the_hex<span style="color:#000000">);</span><br />highlighter_<span style="color:#000000">-&gt;</span><span style="color:#010181">visit</span><span style="color:#000000">(</span>recruit_action<span style="color:#000000">);</span><br /></div></code><br /><br />
<br />
Here is the code skeleton for <code>wb::suppose_dead</code>:<br />
<!-- Original:<br />
class suppose_dead: public action {<br />
public:<br />
void accept(whiteboard_action_visitor &vis){ vis.visit(*this); }<br />
/* the code… */<br />
};<br />
<br />
class whiteboard_action_visitor: public action_visitor {<br />
public:<br />
virtual void visit(suppose_dead&) =0;<br />
};<br />
<br />
class highlight_visitor: public whiteboard_action_visitor {<br />
public:<br />
void visit(recruit &rec){<br />
/* Display some nice sign */<br />
}<br />
void visit(suppose_dead &dead){<br />
/* Display some scary sign */<br />
}<br />
/* … */<br />
};<br />
Formated: --><code><div style="border: 1px dashed #AAA;background:#FAF3E9;padding:7px;"><span style="color:#000000; font-weight:bold">class</span> suppose_dead<span style="color:#000000">:</span> <span style="color:#000000; font-weight:bold">public</span> action <span style="color:#000000">{</span><br /><span style="color:#000000; font-weight:bold">public</span><span style="color:#000000">:</span><br />&nbsp; &nbsp; <span style="color:#0057ae">void</span> <span style="color:#010181">accept</span><span style="color:#000000">(</span>whiteboard_action_visitor <span style="color:#000000">&amp;</span>vis<span style="color:#000000">){</span> vis<span style="color:#000000">.</span><span style="color:#010181">visit</span><span style="color:#000000">(*</span><span style="color:#000000; font-weight:bold">this</span><span style="color:#000000">); }</span><br />&nbsp; &nbsp; <span style="color:#838183; font-style:italic">/* the code… */</span><br /><span style="color:#000000">};</span><br /><br /><span style="color:#000000; font-weight:bold">class</span> whiteboard_action_visitor<span style="color:#000000">:</span> <span style="color:#000000; font-weight:bold">public</span> action_visitor <span style="color:#000000">{</span><br /><span style="color:#000000; font-weight:bold">public</span><span style="color:#000000">:</span><br />&nbsp; &nbsp; <span style="color:#000000; font-weight:bold">virtual</span> <span style="color:#0057ae">void</span> <span style="color:#010181">visit</span><span style="color:#000000">(</span>suppose_dead<span style="color:#000000">&amp;) =</span><span style="color:#b07e00">0</span><span style="color:#000000">;</span><br /><span style="color:#000000">};</span><br /><br /><span style="color:#000000; font-weight:bold">class</span> highlight_visitor<span style="color:#000000">:</span> <span style="color:#000000; font-weight:bold">public</span> whiteboard_action_visitor <span style="color:#000000">{</span><br /><span style="color:#000000; font-weight:bold">public</span><span style="color:#000000">:</span><br />&nbsp; &nbsp; <span style="color:#0057ae">void</span> <span style="color:#010181">visit</span><span style="color:#000000">(</span>recruit <span style="color:#000000">&amp;</span>rec<span style="color:#000000">){</span><br />&nbsp; &nbsp; &nbsp; &nbsp; <span style="color:#838183; font-style:italic">/* Display some nice sign */</span><br />&nbsp; &nbsp; <span style="color:#000000">}</span><br />&nbsp; &nbsp; <span style="color:#0057ae">void</span> <span style="color:#010181">visit</span><span style="color:#000000">(</span>suppose_dead <span style="color:#000000">&amp;</span>dead<span style="color:#000000">){</span><br />&nbsp; &nbsp; &nbsp; &nbsp; <span style="color:#838183; font-style:italic">/* Display some scary sign */</span><br />&nbsp; &nbsp; <span style="color:#000000">}</span><br />&nbsp; &nbsp; <span style="color:#838183; font-style:italic">/* … */</span><br /><span style="color:#000000">};</span><br /></div></code><br /><br />
<br />
=====<span id="actioncore.deserialization">Deserialization</span>=====<br />
Currently, each class deriving from <code>action</code> has a constructor taking a <code>config</code> object, this sounds good, however these constructors are called by <code>action::from_config</code> after doing an if on each possible type.<br />
This approach creates a dependency bottleneck: it collects in a single function knowledge about all classes deriving from <code>action</code>.<br />
<br />
A more sensible approach would be to use an ''object factory''.<br />
The implementation is not very long nor difficult and the resulting code will be more elegant.<br />
<br />
The above extension of the <code>action</code> hierarchy with <code>suppose_dead</code>, will only need an additional line to register itself.<br />
<br />
===<span id="polishing">Polishing</span>===<br />
Some inconsistencies are present in the code (e.g. the way units are referenced). Some other parts needs clean up or/and optimisation (e.g. usage of <code>boost::dynamic_pointer_cast</code>).<br />
<br />
The goal of this task is to find this kind of small problem and fix them.<br />
These two ones have been spotted by Gabba, but I'm planning to add other small problems to this list as I found them.<br />
<br />
Also, they can be a good introduction to the code that's why I'm planning to start working on them before the GSoC start date.<br />
<br />
====<span id="polishing.mapbuilder"><code>mapbuilder</code></span>====<br />
Although, the <code>mapbuilder</code> refactoring was one of the main task, I'm putting it here since it'll mainly be refactored as part of the [[#visitorhier|visitor hierarchy refactoring]] and as part of the [[#actioncore|transfer of the action and validation logic into the core]].<br />
Indeed, the <code>mapbuilder</code> isn't badly designed, all the problems are coming from the API it has to use.<br />
<br />
Gabba, mentioned the possibility of an “incremental mapbuilding”, with the new <code>action_set</code> class, this will be really easy to do.<br />
Currently <code>apply_temp_modifier</code> is called by the function <code>mapbuilder::process</code> which is itself called on every action by <code>enable_visit_all</code>.<br />
However, the task [[#visitorhier|visitor hierarchy refactoring]] will replace <code>enable_visit_all</code> with a class allowing a more fine grained access to the <code>side_actions</code> objects, for example an access by turn (on all <code>side_actions</code> objects) can easily be implemented.<br />
<br />
====<span id="polishing.swap_check">Validation of action swapping</span>====<br />
This problem is more difficult than it looks like, indeed it needs a double dispatch (AKA multimethod).<br />
The current implementation use what Alexandrescu call a ''double switch-on-type'', a more elegant approach would be to use a static or logarithmic dispatcher.<br />
But do we really need it?<br />
I don't think so, indeed, currently one of the argument is always a <code>move</code>, so we can instead use a unique <code>dynamic_pointer_cast</code> (to check if the action is a <code>move</code> or derives from it) and then rely on a visitor doing the check for each <code>action</code> type.<br />
<br />
So we would end-up with:<br />
<!-- Original:<br />
class swapable_with_move: public visitor {<br />
public:<br />
swapable_with_move(move_ptr first): first_(first), valid_(false) {}<br />
bool valid() const { return valid_; }<br />
<br />
// If we don't define visit for an action, the swap is necessarily valid.<br />
void visit(action&){<br />
valid_ = true;<br />
}<br />
<br />
void visit(move &second){<br />
valid_ = first_->get_dest_hex() != second.get_source_hex();<br />
}<br />
<br />
// etc…<br />
<br />
private:<br />
move_ptr first_;<br />
bool valid_;<br />
};<br />
Formated: --><code><div style="border: 1px dashed #AAA;background:#FAF3E9;padding:7px;"><span style="color:#000000; font-weight:bold">class</span> swapable_with_move<span style="color:#000000">:</span> <span style="color:#000000; font-weight:bold">public</span> visitor <span style="color:#000000">{</span><br /><span style="color:#000000; font-weight:bold">public</span><span style="color:#000000">:</span><br />&nbsp; &nbsp; <span style="color:#010181">swapable_with_move</span><span style="color:#000000">(</span>move_ptr first<span style="color:#000000">):</span> <span style="color:#010181">first_</span><span style="color:#000000">(</span>first<span style="color:#000000">),</span> <span style="color:#010181">valid_</span><span style="color:#000000">(</span><span style="color:#000000; font-weight:bold">false</span><span style="color:#000000">) {}</span><br />&nbsp; &nbsp; <span style="color:#0057ae">bool</span> <span style="color:#010181">valid</span><span style="color:#000000">()</span> <span style="color:#0057ae">const</span> <span style="color:#000000">{</span> <span style="color:#000000; font-weight:bold">return</span> valid_<span style="color:#000000">; }</span><br />&nbsp; &nbsp; <br />&nbsp; &nbsp; <span style="color:#838183; font-style:italic">// If we don't define visit for an action, the swap is necessarily valid.</span><br />&nbsp; &nbsp; <span style="color:#0057ae">void</span> <span style="color:#010181">visit</span><span style="color:#000000">(</span>action<span style="color:#000000">&amp;){</span><br />&nbsp; &nbsp; &nbsp; &nbsp; valid_ <span style="color:#000000">=</span> <span style="color:#000000; font-weight:bold">true</span><span style="color:#000000">;</span><br />&nbsp; &nbsp; <span style="color:#000000">}</span><br />&nbsp; &nbsp; <br />&nbsp; &nbsp; <span style="color:#0057ae">void</span> <span style="color:#010181">visit</span><span style="color:#000000">(</span>move <span style="color:#000000">&amp;</span>second<span style="color:#000000">){</span><br /> &nbsp; &nbsp; &nbsp; &nbsp; valid_ <span style="color:#000000">=</span> first_<span style="color:#000000">-&gt;</span><span style="color:#010181">get_dest_hex</span><span style="color:#000000">() !=</span> second<span style="color:#000000">.</span><span style="color:#010181">get_source_hex</span><span style="color:#000000">();</span><br />&nbsp; &nbsp; <span style="color:#000000">}</span><br /><br />&nbsp; &nbsp; <span style="color:#838183; font-style:italic">// etc…</span><br /><br /><span style="color:#000000; font-weight:bold">private</span><span style="color:#000000">:</span><br />&nbsp; &nbsp; move_ptr first_<span style="color:#000000">;</span><br />&nbsp; &nbsp; <span style="color:#0057ae">bool</span> valid_<span style="color:#000000">;</span><br /><span style="color:#000000">};</span><br /></div></code><br /><br />
<br />
Then, we can use it like this:<br />
<!-- Original:<br />
// Check if we can swap the two actions<br />
if (move_ptr bump_earlier = dynamic_pointer_cast<move>(*position)) {<br />
swapable_with_move swap_check(bump_earlier);<br />
(*previous)->accept(swap_check);<br />
if(!swap_check.valid())<br />
return end();<br />
}<br />
Formated: --><code><div style="border: 1px dashed #AAA;background:#FAF3E9;padding:7px;"><span style="color:#838183; font-style:italic">// Check if we can swap the two actions</span><br /><span style="color:#000000; font-weight:bold">if</span> <span style="color:#000000">(</span>move_ptr bump_earlier <span style="color:#000000">=</span> dynamic_pointer_cast<span style="color:#000000">&lt;</span>move<span style="color:#000000">&gt;(*</span>position<span style="color:#000000">)) {</span><br />&nbsp; &nbsp; swapable_with_move <span style="color:#010181">swap_check</span><span style="color:#000000">(</span>bump_earlier<span style="color:#000000">);</span><br />&nbsp; &nbsp; <span style="color:#000000">(*</span>previous<span style="color:#000000">)-&gt;</span><span style="color:#010181">accept</span><span style="color:#000000">(</span>swap_check<span style="color:#000000">);</span><br />&nbsp; &nbsp; <span style="color:#000000; font-weight:bold">if</span><span style="color:#000000">(!</span>swap_check<span style="color:#000000">.</span><span style="color:#010181">valid</span><span style="color:#000000">())</span><br />&nbsp; &nbsp; &nbsp; &nbsp; <span style="color:#000000; font-weight:bold">return</span> <span style="color:#010181">end</span><span style="color:#000000">();</span><br /><span style="color:#000000">}</span><br /></div></code><br />
<br />
====<span id="polishing.manager_pimpl">Usage of a PIMPL in <code>manager</code></span>====<br />
Here is the list of file recompiled when <tt>whiteboard/manager.hpp</tt> is modified:<br />
{|<br />
|-<br />
|<ul><br />
<li><tt>actions.cpp</tt></li><br />
<li><tt>game_display.cpp</tt></li><br />
<li><tt>game_events.cpp</tt></li><br />
<li><tt>menu_events.cpp</tt></li><br />
<li><tt>mouse_events.cpp</tt></li><br />
<li><tt>play_controller.cpp</tt></li><br />
<li><tt>playmp_controller.cpp</tt></li><br />
</ul><br />
|<ul><br />
<li><tt>playsingle_controller.cpp</tt></li><br />
<li><tt>playturn.cpp</tt></li><br />
<li><tt>replay.cpp</tt></li><br />
<li><tt>reports.cpp</tt></li><br />
<li><tt>whiteboard/highlight_visitor.cpp</tt></li><br />
<li><tt>whiteboard/manager.cpp</tt></li><br />
<li><tt>whiteboard/move.cpp</tt></li><br />
</ul><br />
|<ul><br />
<li><tt>whiteboard/recall.cpp</tt></li><br />
<li><tt>whiteboard/recruit.cpp</tt></li><br />
<li><tt>whiteboard/side_actions.cpp</tt></li><br />
<li><tt>whiteboard/suppose_dead.cpp</tt></li><br />
<li><tt>whiteboard/utility.cpp</tt></li><br />
<li><tt>whiteboard/validate_visitor.cpp</tt></li><br />
</ul><br />
|}<br />
<br />
That is, 20 files (as an order of comparison, there is currently 462 <tt>.cpp</tt> files in src).<br />
Although, this number might increase, I'm not sure whether the PIMPL is really necessary.<br />
For now, I'm putting it on my TODO list with a low priority.<br />
<br />
===<span id="designdoc">Design document</span>===<br />
This idea is inspired by the GUI2 design document present in the SVN.<br />
<br />
Doxygen documents the code at a function or class level.<br />
The goal is to write a documentation at the module level. That is a document describing the Whiteboard design globally and not function-by-function.<br />
Actually it shouldn't duplicate what is in doxygen but complement it.<br />
This document could also include informations on how to extend the Whiteboard to help future contributors.<br />
<br />
This design document will be written as a doxygen page, this will leave the documentation next to the code.<br />
<br />
However, I'll begin to put some drafts on the wiki before committing it. Indeed, that will make reviewing easier.<br />
<br />
===Openings===<br />
Here are some possible openings to transform this Google summer of code into a Google year of code:<br />
*Use the new action hierarchy wherever it's needed<br />
*As suggested by Gabba, replace the current <code>wb::manager::on_gamestate_change</code> by something more generic (maybe something like <code>ai::gamestate_observer</code>)<br />
<br />
===Timeline===<br />
Two of my five tasks are actually best done continuously: the design document and the polishing.<br />
Although I haven't clearly placed a week for them, I set two dates at which they should have been completed.<br />
<br />
Of course, the plan is not to have any delay and to finish each task early, however I have reserved two weeks (actually one week and a half) for unexpected delay.<br />
I named them "movable weeks", because they can move in my timeline if anything goes wrong. :)<br />
<br />
On the other hand, I have some [[#Openings|openings]] planned.<br /><br /><br />
<br />
<!-- Wikitext hell 101 --><br />
{| style="border:1px dashed #AAA;border-collapse:collapse;"<br />
|-<br />
!style="border:1px dotted #AAA;padding:5px;"|Date<br />
!style="border:1px dotted #AAA;padding:5px;"|Week<br />
!style="border:1px dotted #AAA;padding:5px;"|Description<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''17/03 - 20/04''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''-11..-5''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Student application evaluation''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|17/03 - 20/04<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|-11..-5<br />
|style="border:1px dotted #AAA;padding:5px;"|Refine the proposal.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''23/04 - 20/05''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''-4..-1''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Community Bonding Period (4 weeks)''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|'''23/04 - 20/05'''<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|'''-4..-1'''<br />
|style="border:1px dotted #AAA;padding:5px;"|'''Phase 0: Approach'''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|23/04 - 20/05<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|-4..-1<br />
|style="border:1px dotted #AAA;padding:5px;"|Familiarise myself with the Whiteboard, in the process start a draft of the design document.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|23/04 - 20/05<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|-4..-1<br />
|style="border:1px dotted #AAA;padding:5px;"|Start working on the ''polishing''.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''21/05''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''0''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Start of GSoC''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|21/05 - 12/08<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|0..11<br />
|style="border:1px dotted #AAA;padding:5px;"|Continuously work on the design document and on the code polishing.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''21/05 - 15/07''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''0..7''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''First half term (8 weeks)''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|'''21/05 - 10/06'''<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|'''0..2'''<br />
|style="border:1px dotted #AAA;padding:5px;"|'''Phase 1: <code>side_actions</code> refactoring'''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|21/05 - 27/05<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|0<br />
|style="border:1px dotted #AAA;padding:5px;"|Prepare <code>side_actions</code> for the change. Add debug informations to the logs. Add the new member <code>turn_beginnings_</code>.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|28/05 - 03/06<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|1<br />
|style="border:1px dotted #AAA;padding:5px;"|Change the type of <code>actions_</code> and rewrite the associated functions. Delete the custom iterators.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|04/06 - 10/06<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|2<br />
|style="border:1px dotted #AAA;padding:5px;"|Debug, write unit test and documentation.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|'''11/06 - 01/07'''<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|'''3..5'''<br />
|style="border:1px dotted #AAA;padding:5px;"|'''Phase 2: Validator hierarchy refactoring'''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|11/06 - 17/06<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|3<br />
|style="border:1px dotted #AAA;padding:5px;"|Write the class <code>action_set</code>.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|18/06 - 24/06<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|4<br />
|style="border:1px dotted #AAA;padding:5px;"|Replace the uses of <code>enable_visit_all</code> with the new interface. Then delete <code>enable_visit_all</code>.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|25/06 - 01/07<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|5<br />
|style="border:1px dotted #AAA;padding:5px;"|Debug, write unit test and documentation.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|'''02/07 - 22/07'''<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|'''6..8'''<br />
|style="border:1px dotted #AAA;padding:5px;"|'''Phase 3: Transfer of the action and validation logic into the core'''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|02/07 - 08/07<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|6<br />
|style="border:1px dotted #AAA;padding:5px;"|Separation of the Whiteboard specific-code from the actions. Transfer of the actions in the core.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|09/07 - 15/07<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|7<br />
|style="border:1px dotted #AAA;padding:5px;"|Use this new API in other places, including the <code>mapbuilder</code>.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''13/07''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''7''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Mid-term evaluation''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''16/07 - 26/08''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''8..13''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Second half term (6 weeks)''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|16/07 - 22/07<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|8<br />
|style="border:1px dotted #AAA;padding:5px;"|Document the new action hierarchy. Mark @deprecated copies of it.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|'''22/07 - 12/08'''<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|'''9..11'''<br />
|style="border:1px dotted #AAA;padding:5px;"|'''Phase 4: Finalisation'''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|22/07 - 29/07<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|9<br />
|style="border:1px dotted #AAA;padding:5px;"|Heavy testing week.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|30/07 - 05/08<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|10<br />
|style="border:1px dotted #AAA;padding:5px;"|Test, debug. Finish the ''polishing''.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|06/08 - 12/08<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|11<br />
|style="border:1px dotted #AAA;padding:5px;"|Test, debug. Finish the design document.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|13/08 - 19/08<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|12<br />
|style="border:1px dotted #AAA;padding:5px;"|Movable week.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|20/08 - 26/08<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|13<br />
|style="border:1px dotted #AAA;padding:5px;"|Movable week.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''24/08''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''13''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Final evaluation''<br />
|}</div>Ejlshttps://wiki.wesnoth.org/index.php?title=User:Ejls/GSoC_2012/Whiteboard_Backend_Refactoring&diff=46374User:Ejls/GSoC 2012/Whiteboard Backend Refactoring2012-04-10T02:03:36Z<p>Ejls: update</p>
<hr />
<div><!--<br />
Excuse the heavy wikitext, I tried to make it as readable as possible and I put a lot of comments.<br />
-->__NOTOC__<!--<br />
-->__NOEDITSECTION__<!--<br />
-->{{SoC2012Student}}<!--<br />
-->[[Category:SoC_Ideas_Whiteboard_Backend_Refactoring_2012]]<!--<br />
-->'''''Note: This proposal is in continuous construction, if you have any remark, please drop me a line on IRC or on the [[{{TALKPAGENAME}}|talk page]].'''''<br /><br /><br />
<br />
<!--***********************************************************************<br />
* * Table of Content * *<br />
* ******************** *<br />
* *<br />
* WARNING: don't forget to add a TOC entry when adding a new section. *<br />
***********************************************************************--><br />
{|style="background:#FAF3E9;margin:none;padding:5px;border:3px double #AAA;-moz-border-radius:20px 5px 20px 5px;-webkit-border-radius:20px 5px 20px 5px;border-radius:20px 5px 20px 5px;"<br />
|-<br />
| style="text-align: center; padding: 0px 10px 5px 10px;"|'''Content'''<hr /><br />
|-<br />
| style="text-align: left; padding:0px 10px 10px 10px;"|<br />
[[#Description|Description]]<br /><br />
[[#SoC Application|SoC Application]]<br /><br />
[[#Contact|Contact]]<br /><br />
[[#Questionnaire|Questionnaire]]<br /><br />
:[[#1) Basics|1 - Basics]]<br /><br />
:[[#2) Experience|2 - Experience]]<br /><br />
:[[#3) Communication skills|3 - Communication skills]]<br /><br />
:[[#4) Project|4 - Project]]<br /><br />
:[[#5) Practical considerations|5 - Practical considerations]]<br /><br />
[[#Proposal|Proposal]]<br /><br />
:[[#The problems|The problems]]<br /><br />
:[[#side_actions|<tt>side_actions</tt> refactoring]]<br /><br />
::[[#side_actions.situation|The current situation]]<br /><br />
::[[#side_actions.idea|The idea]]<br /><br />
::[[#side_actions.implementation|Implementation details]]<br /><br />
:::[[#side_actions.containers|Choice of the containers]]<br /><br />
:::[[#side_actions.example|Example]]<br /><br />
:::[[#side_actions.reconsideration|Reconsideration of Boost.MultiIndex]]<br /><br />
:[[#visitorhier|Visitor hierarchy refactoring]]<br /><br />
::[[#visitorhier.situation|The current situation]]<br /><br />
::[[#visitorhier.idea|The idea]]<br /><br />
::[[#visitorhier.implementation|Implementation details]]<br /><br />
:::[[#visitorhier.example|Example]]<br /><br />
:[[#actioncore|Transfer of the action and validation logic into the core]]<br /><br />
::[[#actioncore.situation|The current situation]]<br /><br />
::[[#actioncore.idea|The idea]]<br /><br />
::[[#actioncore.implementation|Implementation details]]<br /><br />
:::[[#actioncore.whiteboard|Changes in the Whiteboard]]<br /><br />
:::[[#actioncore.example|Example]]<br /><br />
:::[[#actioncore.deserialization|Deserialization]]<br /><br />
:[[#polishing|Polishing]]<br /><br />
::[[#polishing.mapbuilder|<tt>mapbuilder</tt>]]<br /><br />
::[[#polishing.swap_check|Validation of action swapping]]<br /><br />
::[[#polishing.manager_pimpl|Usage of a PIMPL in <tt>manager</tt>]]<br /><br />
:[[#designdoc|Design document]]<br /><br />
:[[#Openings|Openings]]<br /><br />
:[[#Timeline|Timeline]]<br /><br />
|}<br />
<br />
<!--***********************************************************************<br />
* * Description * *<br />
* *************** *<br />
* *<br />
* This section is inserted in the SummerOfCodeIdeas page. It contains *<br />
* only a header of level 4 and a small paragraph summing up the *<br />
* proposal. *<br />
***********************************************************************--><br />
==Description==<br />
====Étienne Simon - Whiteboard backend polishing====<br />
My project is to make the Whiteboard code cleaner and to redesign small parts of it to speed it up. The global design of the Whiteboard won't be changed a lot, each part will be reviewed individually. I'm not only planning to improve the Whiteboard backend, but also to document the overall design and each part of it as well as to write a wide variety of test to improve its stability. Moreover, I'll factorise action handling outside of the Whiteboard so that the same code will be usable in all Wesnoth.<!--<br />
--><br />
<!--***********************************************************************<br />
* * SoC Application * *<br />
* ******************* *<br />
* *<br />
* This section affect the SummerOfCodeIdeas page, if it contains the *<br />
* text "Submitted to google", the application will appear in the *<br />
* "Student proposals submitted both to wiki and google" section, *<br />
* otherwise it'll appear in the "Student proposals not submitted to *<br />
* google" section. *<br />
***********************************************************************--><br />
==SoC Application==<br />
Submitted to google<!--<br />
--><br />
<!--***********************************************************************<br />
* * Contact * *<br />
* *********** *<br />
* *<br />
* The IRC subsection is inserted in the SummerOfCodeIdeas page. It *<br />
* must only contain the IRC nick identifying the author. *<br />
***********************************************************************--><br />
==Contact==<br />
{|<br />
|-<br />
|<br />
=====IRC=====<br />
<span style="color:#3F475E;">ejls </span><br />
=====Email=====<br />
Address at gmail dot com: etienne.jl.simon<br />
| style="width:10em;" |<br />
|<br />
=====Forum=====<br />
ejls<br />
=====Gna=====<br />
ejls<br />
|}<br />
<br />
<!--***********************************************************************<br />
* * Questionnaire * *<br />
* ***************** *<br />
* *<br />
* Although I'm submitting only one application (and so only one *<br />
* questionnaire), I thought it was more elegant to make the *<br />
* questionnaire page reusable. Which explain why it's a template. *<br />
* Like I wrote in the Questionnaire subpage, the argument to this *<br />
* template are the answer to the proposal-specific questions. I order *<br />
* to make the sources more comprehensible, I wrote the corresponding *<br />
* question in comments at the beginning of each parameter. *<br />
***********************************************************************--><br />
{{User:Ejls/GSoC 2012/Questionnaire<br />
|<!-- 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? --><br />
''This is a summary, more details can be found [http://wiki.wesnoth.org/User:Ejls/GSoC%202012/Whiteboard%20Backend%20Refactoring#Proposal here].''<br />
<br />
I originally chose [[SoC Ideas Whiteboard Backend Refactoring 2012]], however it evolved a lot thanks to Gabba and Crab. This project is the only one not adding any feature for the user, the main goal is to refactor code, write test and documentation. It follows [http://wiki.wesnoth.org/GSoC-WesnothWhiteboard_Gabba Gabba's project] and [http://wiki.wesnoth.org/User:Tschmitz tschmitz's project] on the Whiteboard. Although it doesn't add any feature for the user in itself, I hope it'll help future development of the Whiteboard.<!--<br />
-->|<!-- 4.2) If you have invented your own project, please describe the project and the scope. --><br />
I chose a project from the list, namely [[SoC Ideas Whiteboard Backend Refactoring 2012]]. C.f. above answer.<!--<br />
-->|<!-- 4.3) Why did you choose this project? --><br />
I liked the idea behind the Whiteboard, I think it might be a big plus to Wesnoth. Furthermore, I liked how C++ is used in its code (especially the heavy use of SBRM). However it looks like the Whiteboard is not widely used, and I would like to help changing that! :)<!--<br />
-->|<!-- 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". --><br />
''This is a summary, more details can be found [http://wiki.wesnoth.org/User:Ejls/GSoC%202012/Whiteboard%20Backend%20Refactoring#Timeline here].''<br />
<br />
I separated my summer in five phases:<br />
*Phase 0: Approach (4 weeks)<br />
::→ Start working on the design document. Start the ''polishing''.<br />
*Phase 1: <code>side_actions</code> refactoring (3 weeks)<br />
*Phase 2: Validator hierarchy refactoring (3 weeks)<br />
*Phase 3: Transfer of the action and validation logic into the core (3 weeks)<br />
*Phase 4: Finalisation (3 weeks)<br />
::→ Finish the design document. Finish the ''polishing''. Test. Test. Test.<!--<br />
-->|<!-- 4.5) Include as much technical detail about your implementation as you can --><br />
''This is a summary, more details can be found [http://wiki.wesnoth.org/User:Ejls/GSoC%202012/Whiteboard%20Backend%20Refactoring#Proposal here].''<br />
<br />
I separated my project in five tasks:<br />
;<code>side_actions</code> refactoring<br />
:Change of the underlying container, creation of new look up functions.<br />
;Visitor hierarchy refactoring<br />
:Replacement of the <code>enable_visit_all</code> by a new interface over all of the <code>side_actions</code> objects.<br />
;Transfer of the action and validation logic into the core<br />
:Refactoring of <code>wb::action</code> in a Whiteboard-independent hierarchy.<br />
;Polishing<br />
:Code uniformisation, small improvements.<br />
;Design document<br />
:Documentation of the global Whiteboard design.<!--<br />
-->|<!-- 4.6) What do you expect to gain from this project? --><br />
I hope it'll help me to join the open source developer community. Actually, the preparation of this proposal already helped me a lot, for example my first patch got committed, it wasn't a big patch, but it was my first step of a (I hope) long path. :) So, I hope to continue learning to walk with the wesnoth community (sorry for the silly metaphor.)<!--<br />
-->|<!-- 4.7) What would make you stay in the Wesnoth community after the conclusion of SOC? --><br />
If my work is appreciated, I would rather ask: what would make me leave the Wesnoth community?.<!--<br />
-->}}<br />
<br />
<!--***********************************************************************<br />
* * Proposal * *<br />
* ************ *<br />
* *<br />
* Finally, my proposal. ;) *<br />
***********************************************************************--><br />
==Proposal==<br />
===The problems===<br />
In the [[SoC_Ideas_Whiteboard_Backend_Refactoring_2012|Whiteboard Backend Refactoring idea page]], several problems are listed, here is how I'm planning to fix them:<br />
{| style="border:1px dashed #AAA;border-collapse:collapse;"<br />
|-<br />
!style="border:1px dotted #AAA;padding:5px;"|Problem<br />
!style="border:1px dotted #AAA;padding:5px;"|Solution<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|<code>side_actions</code> complexity<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#side_actions|<tt>side_actions</tt> refactoring]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|Redundancy between <code>mapbuilder</code> and <code>validate_visitor</code><br />
|style="border:1px dotted #AAA;padding:5px;"|[[#visitorhier|Visitor hierarchy refactoring]], [[#actioncore|Transfer of the action and validation logic into the core]] and [[#Polishing|Polishing]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|Highlighter slowness<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#side_actions|<tt>side_actions</tt> refactoring]] and [[#visitorhier|Visitor hierarchy refactoring]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|Action handling decentralization<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#actioncore|Transfer of the action and validation logic into the core]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|Friend classes vs everything in the action classes<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#visitorhier|Visitor hierarchy refactoring]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|Unit pointer recovery uniformisation<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#polishing|Polishing]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|<code>boost::dynamic_pointer_cast</code> vs simple numeric id<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#polishing|Polishing]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|Documentation<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#designdoc|Design document]]<br />
|}<br />
<br />
===<span id="side_actions"><code>side_actions</code> refactoring</span>===<br />
====<span id="side_actions.situation">The current situation</span>====<br />
The current implementation of <code>side_actions</code> use a <code>std::deque&lt;std::deque&lt;action_ptr&gt;&gt;</code>.<br />
In order to use it, iterators have been defined over it (<code>side_actions::iterator</code> and the three const and reverse variants).<br />
These “flattening” iterators let users of <code>side_actions</code> iterate over all the planned actions, they are performing the ''zip'' operation on the fly.<br />
<br />
Furthermore, some queries like <code>side_actions::find_first_action_of</code> are linear in the number of action.<br />
<br />
====<span id="side_actions.idea">The idea</span>====<br />
To simplify the code, I propose to keep the action set zipped. The container's iterators will then be usable directly. In order to delimit turns, a second container will have to keep a sequence of iterators pointing to the first action of each turn.<br />
<br />
For example, let's say eight actions are planned: five for this turn, two for the next turn and one for the turn after. Three iterators will be kept to delimit turns. Here is a proof that I can't use gimp which also show the idea:<br />
http://epsilon012.free.fr/GSoC%202012/side_actions%20idea.png<br />
<br />
Of course another problem emerge: the sequence of iterator has to be kept in sync with the sequence of action.<br />
<br />
Finally, the current implementation gives access to the <code>action_ptr</code> only in sequence, in order to speed up different way of querying action (e.g. by hex, by unit's id), I propose to build several indexes on the action set.<br />
<br />
====<span id="side_actions.implementation">Implementation details</span>====<br />
Let's name these containers <code>actions_</code> and <code>turn_beginnings_</code>.<br />
<br />
The Whiteboard have the following invariant: an empty turn (a turn without planned action) can't be followed by a non-empty turn (with at least one planned action). It means that <code>distance(turn_beginnings_[i], turn_beginnings_[i+1])&gt;0</code>, and so we can unambiguously determine the turn number of each action.<br />
<br />
Also, note that except when <code>actions_.empty()</code> : <code>turn_beginnings_.front()==actions_.begin()</code>.<br />
<br />
=====<span id="side_actions.containers">Choice of the containers</span>=====<br />
<code>std::deque</code> seems to be the perfect container for <code>turn_beginnings_</code>. It'll allow random access and we need to add/remove new turns only at the extremities.<br />
<br />
On the other hand, <code>actions_</code> need three proprieties:<br />
*Allow fast chronological iteration<br />
*Stable iterators<br />
*Allow fast lookup on different indexes<br />
I propose to use a <code>boost::multi_index_container</code>, this container is part of the library [http://www.boost.org/doc/libs/1_49_0/libs/multi_index Boost.MultiIndex] which is in Boost since version 1.32. It allows the construction of several indexes on the same set of object.<br />
<br />
There is however one problem linked to the use of the <code>boost::multi_index::random_access</code> index: insertion and deletion are in linear time when their are not done at the extremities.<br />
<br />
So, the new members should be:<br />
<!-- Original:<br />
namespace bmi = boost::multi_index;<br />
typedef bmi::multi_index_container<<br />
action_ptr,<br />
bmi::indexed_by<<br />
bmi::random_access<bmi::tag<chronological> >,<br />
bmi::hashed_non_unique<bmi::tag<by_unit>, bmi::const_mem_fun<action,size_t,&action::get_unit_id> >,<br />
bmi::hashed_non_unique<bmi::tag<by_hex>, bmi::const_mem_fun<action,map_location,&action::get_hex> ><br />
><br />
> action_set;<br />
typedef action_set::iterator iterator;<br />
<br />
action_set actions_;<br />
std::deque<iterator> turn_beginnings_;<br />
Formated: --><code><div style="border: 1px dashed #AAA;background:#FAF3E9;padding:7px;"><span style="color:#000000; font-weight:bold">namespace</span> bmi <span style="color:#000000">=</span> boost<span style="color:#000000">::</span>multi_index<span style="color:#000000">;</span><br /><span style="color:#000000; font-weight:bold">typedef</span> bmi<span style="color:#000000">::</span>multi_index_container<span style="color:#000000">&lt;</span><br />&nbsp; &nbsp; action_ptr<span style="color:#000000">,</span><br />&nbsp; &nbsp; bmi<span style="color:#000000">::</span>indexed_by<span style="color:#000000">&lt;</span><br />&nbsp; &nbsp; &nbsp; &nbsp; bmi<span style="color:#000000">::</span>random_access<span style="color:#000000">&lt;</span>bmi<span style="color:#000000">::</span>tag<span style="color:#000000">&lt;</span>chronological<span style="color:#000000">&gt; &gt;,</span><br />&nbsp; &nbsp; &nbsp; &nbsp; bmi<span style="color:#000000">::</span>hashed_non_unique<span style="color:#000000">&lt;</span>bmi<span style="color:#000000">::</span>tag<span style="color:#000000">&lt;</span>by_unit<span style="color:#000000">&gt;,</span> bmi<span style="color:#000000">::</span>const_mem_fun<span style="color:#000000">&lt;</span>action<span style="color:#000000">,</span><span style="color:#0057ae">size_t</span><span style="color:#000000">,&amp;</span>action<span style="color:#000000">::</span>get_unit_id<span style="color:#000000">&gt; &gt;,</span><br />&nbsp; &nbsp; &nbsp; &nbsp; bmi<span style="color:#000000">::</span>hashed_non_unique<span style="color:#000000">&lt;</span>bmi<span style="color:#000000">::</span>tag<span style="color:#000000">&lt;</span>by_hex<span style="color:#000000">&gt;,</span> bmi<span style="color:#000000">::</span>const_mem_fun<span style="color:#000000">&lt;</span>action<span style="color:#000000">,</span><span style="color:#000000">map_location</span><span style="color:#000000">,&amp;</span>action<span style="color:#000000">::</span>get_hex<span style="color:#000000">&gt; &gt;</span><br />&nbsp; &nbsp; &nbsp; &nbsp; <span style="color:#000000">&gt;</span><br />&nbsp; &nbsp; <span style="color:#000000">&gt;</span> action_set<span style="color:#000000">;</span><br /><span style="color:#000000; font-weight:bold">typedef</span> action_set<span style="color:#000000">::</span>iterator iterator<span style="color:#000000">;</span><br /><br />action_set actions_<span style="color:#000000">;</span><br />std<span style="color:#000000">::</span>deque<span style="color:#000000">&lt;</span>iterator<span style="color:#000000">&gt;</span> turn_beginnings_<span style="color:#000000">;</span><br /></div></code><br /><br />
<br />
This suppose two new pure virtual functions in <code>action</code>: <code>get_unit_id</code> and <code>get_hex</code>.<br />
<br />
Using action's attribute as key brings another drawback: we must notify the <code>multi_index_container</code> when we modify a key.<br />
However, the two used keys here (the unit's id and the hex) are never modified in the <code>action</code> hierarchy.<br />
<br />
This definition is here to give an idea, in practice other indexes will have to be built (e.g. an index on ''secondary hex'' which could be the source hex in <code>move</code>.)<br />
Note that this doesn't necessarily means a new pure virtual function in <code>action</code>, a key extractor can be defined to let <code>action</code> as it is and use ''RTTI'' instead (this might not be clever though.)<br />
<br />
=====<span id="side_actions.example">Example</span>=====<br />
Here are three functions rewritten with this new design. Note that <code>side_actions::iterator</code> is the one defined above.<br />
<br />
<!-- Original:<br />
side_actions::iterator side_actions::end_turn(size_t turn_num){<br />
if(turn_num+1 >= turn_beginnings_.size())<br />
return actions_.end();<br />
else<br />
return turn_beginnings_[turn_num+1];<br />
}<br />
Formated: --><code><div style="border: 1px dashed #AAA;background:#FAF3E9;padding:7px;">side_actions<span style="color:#000000">::</span>iterator side_actions<span style="color:#000000">::</span><span style="color:#010181">end_turn</span><span style="color:#000000">(</span><span style="color:#0057ae">size_t</span> turn_num<span style="color:#000000">){</span><br />&nbsp; &nbsp; <span style="color:#000000; font-weight:bold">if</span><span style="color:#000000">(</span>turn_num<span style="color:#000000">+</span><span style="color:#b07e00">1</span> <span style="color:#000000">&gt;=</span> turn_beginnings_<span style="color:#000000">.</span><span style="color:#010181">size</span><span style="color:#000000">())</span><br />&nbsp; &nbsp; &nbsp; &nbsp; <span style="color:#000000; font-weight:bold">return</span> actions_<span style="color:#000000">.</span><span style="color:#010181">end</span><span style="color:#000000">();</span><br />&nbsp; &nbsp; <span style="color:#000000; font-weight:bold">else</span><br />&nbsp; &nbsp; &nbsp; &nbsp; <span style="color:#000000; font-weight:bold">return</span> turn_beginnings_<span style="color:#000000">[</span>turn_num<span style="color:#000000">+</span><span style="color:#b07e00">1</span><span style="color:#000000">];</span><br /><span style="color:#000000">}</span><br /></div></code><br /><br />
<br />
<!-- Original:<br />
side_actions::iterator side_actions::raw_enqueue(size_t turn_num, action_ptr act){<br />
assert(turn_num <= turn_beginnings_.size());<br />
<br />
iterator new_action = actions_.insert(end_turn(turn_num), act).first;<br />
<br />
if(turn_num >= turn_beginnings_.size())<br />
turn_beginnings_.push_back(new_action);<br />
<br />
return new_action;<br />
}<br />
Formated: --><code><div style="border: 1px dashed #AAA;background:#FAF3E9;padding:7px;">side_actions<span style="color:#000000">::</span>iterator side_actions<span style="color:#000000">::</span><span style="color:#010181">raw_enqueue</span><span style="color:#000000">(</span><span style="color:#0057ae">size_t</span> turn_num<span style="color:#000000">,</span> action_ptr act<span style="color:#000000">){</span><br />&nbsp; &nbsp; <span style="color:#000000; font-weight:bold">assert</span><span style="color:#000000">(</span>turn_num <span style="color:#000000">&lt;=</span> turn_beginnings_<span style="color:#000000">.</span><span style="color:#010181">size</span><span style="color:#000000">());</span><br /><br />&nbsp; &nbsp; iterator new_action <span style="color:#000000">=</span> actions_<span style="color:#000000">.</span><span style="color:#010181">insert</span><span style="color:#000000">(</span><span style="color:#010181">end_turn</span><span style="color:#000000">(</span>turn_num<span style="color:#000000">),</span> act<span style="color:#000000">).</span>first<span style="color:#000000">;</span><br /><br />&nbsp; &nbsp; <span style="color:#000000; font-weight:bold">if</span><span style="color:#000000">(</span>turn_num <span style="color:#000000">&gt;=</span> turn_beginnings_<span style="color:#000000">.</span><span style="color:#010181">size</span><span style="color:#000000">())</span><br />&nbsp; &nbsp; &nbsp; &nbsp; turn_beginnings_<span style="color:#000000">.</span><span style="color:#010181">push_back</span><span style="color:#000000">(</span>new_action<span style="color:#000000">);</span><br /><br />&nbsp; &nbsp; <span style="color:#000000; font-weight:bold">return</span> new_action<span style="color:#000000">;</span><br /><span style="color:#000000">}</span><br /></div></code><br /><br />
<br />
<!-- Original:<br />
side_actions::find_first_action_of(unit const* unit, side_actions::iterator start_position){<br />
// First we get all the action of this unit<br />
typedef action_set::index<by_unit>::type::iterator unit_iterator;<br />
std::pair<unit_iterator, unit_iterator> act = actions_.get<by_unit>().equal_range(unit->underlying_id());<br />
<br />
// Then we find the first of them (chronologically) after start_position<br />
iterator first = actions_.end();<br />
for(unit_iterator it = act.first; it != act.second; ++it){<br />
iterator chrono_it = actions_.project<chronological>(it);<br />
if(chrono_it < first && chrono_it > start_position)<br />
first = chrono_it;<br />
}<br />
return first;<br />
}<br />
Formated: --><code><div style="border: 1px dashed #AAA;background:#FAF3E9;padding:7px;">side_actions<span style="color:#000000">::</span><span style="color:#010181">find_first_action_of</span><span style="color:#000000">(</span>unit <span style="color:#0057ae">const</span><span style="color:#000000">*</span> unit<span style="color:#000000">,</span> side_actions<span style="color:#000000">::</span>iterator start_position<span style="color:#000000">){</span><br />&nbsp; &nbsp; <span style="color:#838183; font-style:italic">// First we get all the action of this unit</span><br />&nbsp; &nbsp; <span style="color:#000000; font-weight:bold">typedef</span> action_set<span style="color:#000000">::</span>index<span style="color:#000000">&lt;</span>by_unit<span style="color:#000000">&gt;::</span>type<span style="color:#000000">::</span>iterator unit_iterator<span style="color:#000000">;</span><br />&nbsp; &nbsp; std<span style="color:#000000">::</span>pair<span style="color:#000000">&lt;</span>unit_iterator<span style="color:#000000">,</span> unit_iterator<span style="color:#000000">&gt;</span> act <span style="color:#000000">=</span> actions_<span style="color:#000000">.</span>get<span style="color:#000000">&lt;</span>by_unit<span style="color:#000000">&gt;().</span><span style="color:#010181">equal_range</span><span style="color:#000000">(</span>unit<span style="color:#000000">-&gt;</span><span style="color:#010181">underlying_id</span><span style="color:#000000">());</span><br /><br />&nbsp; &nbsp; <span style="color:#838183; font-style:italic">// Then we find the first of them (chronologically) after start_position</span><br />&nbsp; &nbsp; iterator first <span style="color:#000000">=</span> actions_<span style="color:#000000">.</span><span style="color:#010181">end</span><span style="color:#000000">();</span><br />&nbsp; &nbsp; <span style="color:#000000; font-weight:bold">for</span><span style="color:#000000">(</span>unit_iterator it <span style="color:#000000">=</span> act<span style="color:#000000">.</span>first<span style="color:#000000">;</span> it <span style="color:#000000">!=</span> act<span style="color:#000000">.</span>second<span style="color:#000000">; ++</span>it<span style="color:#000000">){</span><br />&nbsp; &nbsp; &nbsp; &nbsp; iterator chrono_it <span style="color:#000000">=</span> actions_<span style="color:#000000">.</span>project<span style="color:#000000">&lt;</span>chronological<span style="color:#000000">&gt;(</span>it<span style="color:#000000">);</span><br />&nbsp; &nbsp; &nbsp; &nbsp; <span style="color:#000000; font-weight:bold">if</span><span style="color:#000000">(</span>chrono_it <span style="color:#000000">&lt;</span> first <span style="color:#000000">&amp;&amp;</span> chrono_it <span style="color:#000000">&gt;</span> start_position<span style="color:#000000">)</span><br />&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; first <span style="color:#000000">=</span> chrono_it<span style="color:#000000">;</span><br />&nbsp; &nbsp; <span style="color:#000000">}</span><br />&nbsp; &nbsp; <span style="color:#000000; font-weight:bold">return</span> first<span style="color:#000000">;</span><br /><span style="color:#000000">}</span><br /></div></code><br />
<br />
=====<span id="side_actions.reconsideration">Reconsideration of Boost.MultiIndex</span>=====<br />
As Gabba noted ([http://www.wesnoth.org/irclogs/2012/03/%23wesnoth-dev.2012-03-31.log #wesnoth-dev 2012/03/31 7h18]), Boost.MultiIndex might be hard to debug and hard to use.<br />
This section try to reconsider the use of Boost.MultiIndex.<br />
<br />
The major problem we would run into while considering to write a replacement for Boost.MultiIndex is how to allow the usage of the standard algorithms. Indeed, they will be usable only on the underlying container and not on its ''view''. To overcome this, a simple solution have been used in Boost: they rewrote all the iterators. The problem is that, even if it now evolved in something bigger, the first goal with <code>side_actions</code> refactoring was to remove the iterator's definitions.<br />
<br />
While, indeed Boost.MultiIndex will make debugging harder and increase compilation time compared to an homemade solution.<br />
It offer numerous advantages:<br />
*It's generic, adding a new key will be as easy as adding a new template parameter in the definition.<br />
*It don't have to be rewritten. :)<br />
*It's already used in Wesnoth (thanks Mordante for noting it.)<br />
*It offers some advantages over the standard containers (e.g. a random-access container with stable iterators and strong exception guaranty.)<br />
<br />
===<span id="visitorhier">Visitor hierarchy refactoring</span>===<br />
====<span id="visitorhier.situation">The current situation</span>====<br />
The important classes and class templates of this hierarchy are:<br />
*'''<code>visitor</code>''', the base class of the visitor hierarchy, it dispatches the calls to the derived classes.<br />
*'''<code>enable_visit_all</code>''', which is actually an interface to the <code>action_ptr</code> objects of every single team.<br />
*'''<code>action</code>''', the root class of the visitable hierarchy.<br />
<br />
Currently, when the visitor hierarchy needs to visit the visitable hierarchy, all the actions of every sides of every turn are visited using the function <code>enable_visit_all::visit_all_helper</code> (e.g. this function is called by <code>highlight_visitor::find_main_highlight</code> to find the action to highlight.)<br />
<br />
====<span id="visitorhier.idea">The idea</span>====<br />
I'm favorable to the maintain of the Visitor pattern, it segregates the different components nicely.<br />
I think the problem come from <code>enable_visit_all</code> and I would like to replace it with a class offering a more fine-grained access to the actions.<br />
For example, a look up by hex could be defined in this new structure and then used by <code>highlight_visitor</code>.<br />
Actually, most of the work of this new class will have to do is to redirect the calls to the <code>side_actions</code> (to one in particular or to all depending on the function).<br />
<br />
====<span id="visitorhier.implementation">Implementation details</span>====<br />
Let's name this new class <code>action_set</code>.<br />
<br />
The sole problem faced is to place <code>action_set</code>, since it is mainly a proxy to a global resource (the <code>side_actions</code> of each team), it makes sense to place it directly in the <code>wb</code> namespace.<br />
<br />
Note that the access to the <code>action</code> hierarchy will no more be done through inheritance.<br />
<br />
=====<span id="visitorhier.example">Example</span>=====<br />
Here is an example function that would speed up <code>highlight_visitor</code>.<br />
<!-- Original:<br />
action_ptr action_set::action_at(map_location const &hex){<br />
side_actions::iterator result;<br />
foreach(team& side, *resources::teams){<br />
side_actions actions = side.get_side_actions();<br />
if((result = actions.find_action_at(hex)) != actions.end())<br />
return *result;<br />
}<br />
return action_ptr();<br />
}<br />
Formated: --><code><div style="border: 1px dashed #AAA;background:#FAF3E9;padding:7px;">action_ptr action_set<span style="color:#000000">::</span><span style="color:#010181">action_at</span><span style="color:#000000">(</span>map_location <span style="color:#0057ae">const</span> <span style="color:#000000">&amp;</span>hex<span style="color:#000000">){</span><br />&nbsp; &nbsp; side_actions<span style="color:#000000">::</span>iterator result<span style="color:#000000">;</span><br />&nbsp; &nbsp; <span style="color:#010181">foreach</span><span style="color:#000000">(</span>team<span style="color:#000000">&amp;</span> side<span style="color:#000000">, *</span>resources<span style="color:#000000">::</span>teams<span style="color:#000000">){</span><br />&nbsp; &nbsp; &nbsp; &nbsp; side_actions actions <span style="color:#000000">=</span> side<span style="color:#000000">.</span><span style="color:#010181">get_side_actions</span><span style="color:#000000">();</span><br />&nbsp; &nbsp; &nbsp; &nbsp; <span style="color:#000000; font-weight:bold">if</span><span style="color:#000000">((</span>result <span style="color:#000000">=</span> actions<span style="color:#000000">.</span><span style="color:#010181">find_action_at</span><span style="color:#000000">(</span>hex<span style="color:#000000">)) !=</span> actions<span style="color:#000000">.</span><span style="color:#010181">end</span><span style="color:#000000">())</span><br />&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; <span style="color:#000000; font-weight:bold">return</span> <span style="color:#000000">*</span>result<span style="color:#000000">;</span><br />&nbsp; &nbsp; <span style="color:#000000">}</span><br />&nbsp; &nbsp; <span style="color:#000000; font-weight:bold">return</span> <span style="color:#010181">action_ptr</span><span style="color:#000000">();</span><br /><span style="color:#000000">}</span><br /></div></code><br /><br />
<br />
Note: the implementation of <code>side_actions::find_action_at</code> is similar to the one of <code>side_actions::find_first_action_of</code>.<br />
<br />
===<span id="actioncore">Transfer of the action and validation logic into the core</span>===<br />
This is a (great) idea of Crab ([http://www.wesnoth.org/irclogs/2012/04/%23wesnoth-dev.2012-04-02.log #wesnoth-dev 2012/04/02 16h11]).<br />
<br />
====<span id="actioncore.situation">The current situation</span>====<br />
Currently, the code related to action execution and checking is duplicated in several places.<br />
For example, <code>ai::recall_result::do_check_before()</code>, <code>wb::validate_visitor::visit(recall_ptr)</code> and <code>do_replay_handle()</code> are doing the same thing: checking whether a recall is valid.<br />
Furthermore, the latter is also executing the recall, as is <code>wb::recall::execute()</code> and <code>ai::recall_result::do_execute()</code>.<br />
<br />
====<span id="actioncore.idea">The idea</span>====<br />
The idea is simple: factor the code.<br />
<br />
However, we must be careful not to include too many functionalities in this new hierarchy, it must be extensible as much as possible without having to modify it.<br />
<br />
The good thing with the current code duplication is that I'll be able to look at different code doing the same thing before choosing the best implementation. ;)<br />
<br />
====<span id="actioncore.implementation">Implementation details</span>====<br />
A nice point of <code>wb::action</code> is that Gabba used the visitor pattern, which is exactly what we need here.<br />
Indeed, some functions are strictly related to a module (for example the Whiteboard's highlighter), the visitor pattern will allow virtual functions to be defined outside of the visited hierarchy (the action hierarchy here), moreover the visited hierarchy doesn't need to be recompiled when a new visitor is added.<br />
<br />
The overhead of the visitor is really small: an additional (non-virtual) function call.<br />
<br />
Since the validation of an action is needed by all the game, it can be included as a member function <code>virtual bool valid() const =0;</code> in the action hierarchy.<br />
<br />
=====<span id="actioncore.whiteboard">Changes in the Whiteboard</span>=====<br />
It's a good idea to read this part even if you're not interested in the Whiteboard, indeed this gives you an idea on to extends this new action hierarchy.<br />
<br />
Currently, there is a Whiteboard-specific action: <code>suppose_dead</code>.<br />
Even if it's disabled for now, the new design need to consider it.<br />
Actually, the changes to do are pretty straightforward:<br />
*A new class <code>suppose_dead</code> is derived from <code>action</code><br />
*A new class <code>whiteboard_action_visitor</code> is derived from <code>action_visitor</code> and add a virtual function <code>visit(suppose_dead&amp;)</code><br />
That's all. :)<br />
Now, the sole Whiteboard visitor (<code>highlight_visitor</code>) can derive from <code>whiteboard_action_visitor</code> and override <code>visit(suppose_dead&amp;)</code>.<br />
<br />
What is important here is that we can still extends the <code>action</code> hierarchy which is in core, without modifying it.<br />
<br />
Of course, I'm planing to write <s>the same</s> a better explanation in the documentation. ;)<br />
<br />
=====<span id="actioncore.example">Example</span>=====<br />
Highlighting a recruit action in the Whiteboard:<br />
<!-- Original:<br />
recruit recruit_action(the_team, the_unit, the_hex);<br />
highlighter_->visit(recruit_action);<br />
Formated: --><code><div style="border: 1px dashed #AAA;background:#FAF3E9;padding:7px;">recruit <span style="color:#010181">recruit_action</span><span style="color:#000000">(</span>the_team<span style="color:#000000">,</span> the_unit<span style="color:#000000">,</span> the_hex<span style="color:#000000">);</span><br />highlighter_<span style="color:#000000">-&gt;</span><span style="color:#010181">visit</span><span style="color:#000000">(</span>recruit_action<span style="color:#000000">);</span><br /></div></code><br /><br />
<br />
Here is the code skeleton for <code>wb::suppose_dead</code>:<br />
<!-- Original:<br />
class suppose_dead: public action {<br />
public:<br />
void accept(whiteboard_action_visitor &vis){ vis.visit(*this); }<br />
/* the code… */<br />
};<br />
<br />
class whiteboard_action_visitor: public action_visitor {<br />
public:<br />
virtual void visit(suppose_dead&) =0;<br />
};<br />
<br />
class highlight_visitor: public whiteboard_action_visitor {<br />
public:<br />
void visit(recruit &rec){<br />
/* Display some nice sign */<br />
}<br />
void visit(suppose_dead &dead){<br />
/* Display some scary sign */<br />
}<br />
/* … */<br />
};<br />
Formated: --><code><div style="border: 1px dashed #AAA;background:#FAF3E9;padding:7px;"><span style="color:#000000; font-weight:bold">class</span> suppose_dead<span style="color:#000000">:</span> <span style="color:#000000; font-weight:bold">public</span> action <span style="color:#000000">{</span><br /><span style="color:#000000; font-weight:bold">public</span><span style="color:#000000">:</span><br />&nbsp; &nbsp; <span style="color:#0057ae">void</span> <span style="color:#010181">accept</span><span style="color:#000000">(</span>whiteboard_action_visitor <span style="color:#000000">&amp;</span>vis<span style="color:#000000">){</span> vis<span style="color:#000000">.</span><span style="color:#010181">visit</span><span style="color:#000000">(*</span><span style="color:#000000; font-weight:bold">this</span><span style="color:#000000">); }</span><br />&nbsp; &nbsp; <span style="color:#838183; font-style:italic">/* the code… */</span><br /><span style="color:#000000">};</span><br /><br /><span style="color:#000000; font-weight:bold">class</span> whiteboard_action_visitor<span style="color:#000000">:</span> <span style="color:#000000; font-weight:bold">public</span> action_visitor <span style="color:#000000">{</span><br /><span style="color:#000000; font-weight:bold">public</span><span style="color:#000000">:</span><br />&nbsp; &nbsp; <span style="color:#000000; font-weight:bold">virtual</span> <span style="color:#0057ae">void</span> <span style="color:#010181">visit</span><span style="color:#000000">(</span>suppose_dead<span style="color:#000000">&amp;) =</span><span style="color:#b07e00">0</span><span style="color:#000000">;</span><br /><span style="color:#000000">};</span><br /><br /><span style="color:#000000; font-weight:bold">class</span> highlight_visitor<span style="color:#000000">:</span> <span style="color:#000000; font-weight:bold">public</span> whiteboard_action_visitor <span style="color:#000000">{</span><br /><span style="color:#000000; font-weight:bold">public</span><span style="color:#000000">:</span><br />&nbsp; &nbsp; <span style="color:#0057ae">void</span> <span style="color:#010181">visit</span><span style="color:#000000">(</span>recruit <span style="color:#000000">&amp;</span>rec<span style="color:#000000">){</span><br />&nbsp; &nbsp; &nbsp; &nbsp; <span style="color:#838183; font-style:italic">/* Display some nice sign */</span><br />&nbsp; &nbsp; <span style="color:#000000">}</span><br />&nbsp; &nbsp; <span style="color:#0057ae">void</span> <span style="color:#010181">visit</span><span style="color:#000000">(</span>suppose_dead <span style="color:#000000">&amp;</span>dead<span style="color:#000000">){</span><br />&nbsp; &nbsp; &nbsp; &nbsp; <span style="color:#838183; font-style:italic">/* Display some scary sign */</span><br />&nbsp; &nbsp; <span style="color:#000000">}</span><br />&nbsp; &nbsp; <span style="color:#838183; font-style:italic">/* … */</span><br /><span style="color:#000000">};</span><br /></div></code><br /><br />
<br />
=====<span id="actioncore.deserialization">Deserialization</span>=====<br />
Currently, each class deriving from <code>action</code> has a constructor taking a <code>config</code> object, this sounds good, however these constructors are called by <code>action::from_config</code> after doing an if on each possible type.<br />
This approach creates a dependency bottleneck: it collects in a single function knowledge about all classes deriving from <code>action</code>.<br />
<br />
A more sensible approach would be to use an ''object factory''.<br />
The implementation is not very long nor difficult and the resulting code will be more elegant.<br />
<br />
The above extension of the <code>action</code> hierarchy with <code>suppose_dead</code>, will only need an additional line to register itself.<br />
<br />
===<span id="polishing">Polishing</span>===<br />
Some inconsistencies are present in the code (e.g. the way units are referenced). Some other parts needs clean up or/and optimisation (e.g. usage of <code>boost::dynamic_pointer_cast</code>).<br />
<br />
The goal of this task is to find this kind of small problem and fix them.<br />
These two ones have been spotted by Gabba, but I'm planning to add other small problems to this list as I found them.<br />
<br />
Also, they can be a good introduction to the code that's why I'm planning to start working on them before the GSoC start date.<br />
<br />
====<span id="polishing.mapbuilder"><code>mapbuilder</code></span>====<br />
Although, the <code>mapbuilder</code> refactoring was one of the main task, I'm putting it here since it'll mainly be refactored as part of the [[#visitorhier|visitor hierarchy refactoring]] and as part of the [[#actioncore|transfer of the action and validation logic into the core]].<br />
Indeed, the <code>mapbuilder</code> isn't badly designed, all the problems are coming from the API it has to use.<br />
<br />
Gabba, mentioned the possibility of an “incremental mapbuilding”, with the new <code>action_set</code> class, this will be really easy to do.<br />
Currently <code>apply_temp_modifier</code> is called by the function <code>mapbuilder::process</code> which is itself called on every action by <code>enable_visit_all</code>.<br />
However, the task [[#visitorhier|visitor hierarchy refactoring]] will replace <code>enable_visit_all</code> with a class allowing a more fine grained access to the <code>side_actions</code> objects, for example an access by turn (on all <code>side_actions</code> objects) can easily be implemented.<br />
<br />
====<span id="polishing.swap_check">Validation of action swapping</span>====<br />
This problem is more difficult than it looks like, indeed it needs a double dispatch (AKA multimethod).<br />
The current implementation use what Alexandrescu call a ''double switch-on-type'', a more elegant approach would be to use a static or logarithmic dispatcher.<br />
But do we really need it?<br />
I don't think so, indeed, currently one of the argument is always a <code>move</code>, so we can instead use a unique <code>dynamic_pointer_cast</code> (to check if the action is a <code>move</code> or derives from it) and then rely on a visitor doing the check for each <code>action</code> type.<br />
<br />
So we would end-up with:<br />
<!-- Original:<br />
class swapable_with_move: public visitor {<br />
public:<br />
swapable_with_move(move_ptr first): first_(first), valid_(false) {}<br />
bool valid() const { return valid_; }<br />
<br />
// If we don't define visit for an action, the swap is necessarily valid.<br />
void visit(action&){<br />
valid_ = true;<br />
}<br />
<br />
void visit(move &second){<br />
valid_ = first_->get_dest_hex() != second.get_source_hex();<br />
}<br />
<br />
// etc…<br />
<br />
private:<br />
move_ptr first_;<br />
bool valid_;<br />
};<br />
Formated: --><code><div style="border: 1px dashed #AAA;background:#FAF3E9;padding:7px;"><span style="color:#000000; font-weight:bold">class</span> swapable_with_move<span style="color:#000000">:</span> <span style="color:#000000; font-weight:bold">public</span> visitor <span style="color:#000000">{</span><br /><span style="color:#000000; font-weight:bold">public</span><span style="color:#000000">:</span><br />&nbsp; &nbsp; <span style="color:#010181">swapable_with_move</span><span style="color:#000000">(</span>move_ptr first<span style="color:#000000">):</span> <span style="color:#010181">first_</span><span style="color:#000000">(</span>first<span style="color:#000000">),</span> <span style="color:#010181">valid_</span><span style="color:#000000">(</span><span style="color:#000000; font-weight:bold">false</span><span style="color:#000000">) {}</span><br />&nbsp; &nbsp; <span style="color:#0057ae">bool</span> <span style="color:#010181">valid</span><span style="color:#000000">()</span> <span style="color:#0057ae">const</span> <span style="color:#000000">{</span> <span style="color:#000000; font-weight:bold">return</span> valid_<span style="color:#000000">; }</span><br />&nbsp; &nbsp; <br />&nbsp; &nbsp; <span style="color:#838183; font-style:italic">// If we don't define visit for an action, the swap is necessarily valid.</span><br />&nbsp; &nbsp; <span style="color:#0057ae">void</span> <span style="color:#010181">visit</span><span style="color:#000000">(</span>action<span style="color:#000000">&amp;){</span><br />&nbsp; &nbsp; &nbsp; &nbsp; valid_ <span style="color:#000000">=</span> <span style="color:#000000; font-weight:bold">true</span><span style="color:#000000">;</span><br />&nbsp; &nbsp; <span style="color:#000000">}</span><br />&nbsp; &nbsp; <br />&nbsp; &nbsp; <span style="color:#0057ae">void</span> <span style="color:#010181">visit</span><span style="color:#000000">(</span>move <span style="color:#000000">&amp;</span>second<span style="color:#000000">){</span><br /> &nbsp; &nbsp; &nbsp; &nbsp; valid_ <span style="color:#000000">=</span> first_<span style="color:#000000">-&gt;</span><span style="color:#010181">get_dest_hex</span><span style="color:#000000">() !=</span> second<span style="color:#000000">.</span><span style="color:#010181">get_source_hex</span><span style="color:#000000">();</span><br />&nbsp; &nbsp; <span style="color:#000000">}</span><br /><br />&nbsp; &nbsp; <span style="color:#838183; font-style:italic">// etc…</span><br /><br /><span style="color:#000000; font-weight:bold">private</span><span style="color:#000000">:</span><br />&nbsp; &nbsp; move_ptr first_<span style="color:#000000">;</span><br />&nbsp; &nbsp; <span style="color:#0057ae">bool</span> valid_<span style="color:#000000">;</span><br /><span style="color:#000000">};</span><br /></div></code><br /><br />
<br />
Then, we can use it like this:<br />
<!-- Original:<br />
// Check if we can swap the two actions<br />
if (move_ptr bump_earlier = dynamic_pointer_cast<move>(*position)) {<br />
swapable_with_move swap_check(bump_earlier);<br />
(*previous)->accept(swap_check);<br />
if(!swap_check.valid())<br />
return end();<br />
}<br />
Formated: --><code><div style="border: 1px dashed #AAA;background:#FAF3E9;padding:7px;"><span style="color:#838183; font-style:italic">// Check if we can swap the two actions</span><br /><span style="color:#000000; font-weight:bold">if</span> <span style="color:#000000">(</span>move_ptr bump_earlier <span style="color:#000000">=</span> dynamic_pointer_cast<span style="color:#000000">&lt;</span>move<span style="color:#000000">&gt;(*</span>position<span style="color:#000000">)) {</span><br />&nbsp; &nbsp; swapable_with_move <span style="color:#010181">swap_check</span><span style="color:#000000">(</span>bump_earlier<span style="color:#000000">);</span><br />&nbsp; &nbsp; <span style="color:#000000">(*</span>previous<span style="color:#000000">)-&gt;</span><span style="color:#010181">accept</span><span style="color:#000000">(</span>swap_check<span style="color:#000000">);</span><br />&nbsp; &nbsp; <span style="color:#000000; font-weight:bold">if</span><span style="color:#000000">(!</span>swap_check<span style="color:#000000">.</span><span style="color:#010181">valid</span><span style="color:#000000">())</span><br />&nbsp; &nbsp; &nbsp; &nbsp; <span style="color:#000000; font-weight:bold">return</span> <span style="color:#010181">end</span><span style="color:#000000">();</span><br /><span style="color:#000000">}</span><br /></div></code><br />
<br />
====<span id="polishing.manager_pimpl">Usage of a PIMPL in <code>manager</code></span>====<br />
Here is the list of file recompiled when <tt>whiteboard/manager.hpp</tt> is modified:<br />
{|<br />
|-<br />
|<ul><br />
<li><tt>actions.cpp</tt></li><br />
<li><tt>game_display.cpp</tt></li><br />
<li><tt>game_events.cpp</tt></li><br />
<li><tt>menu_events.cpp</tt></li><br />
<li><tt>mouse_events.cpp</tt></li><br />
<li><tt>play_controller.cpp</tt></li><br />
<li><tt>playmp_controller.cpp</tt></li><br />
</ul><br />
|<ul><br />
<li><tt>playsingle_controller.cpp</tt></li><br />
<li><tt>playturn.cpp</tt></li><br />
<li><tt>replay.cpp</tt></li><br />
<li><tt>reports.cpp</tt></li><br />
<li><tt>whiteboard/highlight_visitor.cpp</tt></li><br />
<li><tt>whiteboard/manager.cpp</tt></li><br />
<li><tt>whiteboard/move.cpp</tt></li><br />
</ul><br />
|<ul><br />
<li><tt>whiteboard/recall.cpp</tt></li><br />
<li><tt>whiteboard/recruit.cpp</tt></li><br />
<li><tt>whiteboard/side_actions.cpp</tt></li><br />
<li><tt>whiteboard/suppose_dead.cpp</tt></li><br />
<li><tt>whiteboard/utility.cpp</tt></li><br />
<li><tt>whiteboard/validate_visitor.cpp</tt></li><br />
</ul><br />
|}<br />
<br />
That is, 20 files (as an order of comparison, there is currently 462 <tt>.cpp</tt> files in src).<br />
Although, this number might increase, I'm not sure whether the PIMPL is really necessary.<br />
For now, I'm putting it on my TODO list with a low priority.<br />
<br />
===<span id="designdoc">Design document</span>===<br />
This idea is inspired by the GUI2 design document present in the SVN.<br />
<br />
Doxygen documents the code at a function or class level.<br />
The goal is to write a documentation at the module level. That is a document describing the Whiteboard design globally and not function-by-function.<br />
Actually it shouldn't duplicate what is in doxygen but complement it.<br />
This document could also include informations on how to extend the Whiteboard to help future contributors.<br />
<br />
This design document will be written as a doxygen page, this will leave the documentation next to the code.<br />
<br />
However, I'll begin to put some drafts on the wiki before committing it. Indeed, that will make reviewing easier.<br />
<br />
===Openings===<br />
Here are some possible openings to transform this Google summer of code into a Google year of code:<br />
*Use the new action hierarchy wherever it's needed<br />
*As suggested by Gabba, replace the current <code>wb::manager::on_gamestate_change</code> by something more generic (maybe something like <code>ai::gamestate_observer</code>)<br />
<br />
===Timeline===<br />
Two of my five tasks are actually best done continuously: the design document and the polishing.<br />
Although I haven't clearly placed a week for them, I set two dates at which they should have been completed.<br />
<br />
Of course, the plan is not to have any delay and to finish each task early, however I have reserved two weeks (actually one week and a half) for unexpected delay.<br />
I named them "movable weeks", because they can move in my timeline if anything goes wrong. :)<br />
<br />
On the other hand, I have some [[#Openings|openings]] planned.<br /><br /><br />
<br />
<!-- Wikitext hell 101 --><br />
{| style="border:1px dashed #AAA;border-collapse:collapse;"<br />
|-<br />
!style="border:1px dotted #AAA;padding:5px;"|Date<br />
!style="border:1px dotted #AAA;padding:5px;"|Week<br />
!style="border:1px dotted #AAA;padding:5px;"|Description<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''17/03 - 20/04''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''-11..-5''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Student application evaluation''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|17/03 - 20/04<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|-11..-5<br />
|style="border:1px dotted #AAA;padding:5px;"|Refine the proposal.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''23/04 - 20/05''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''-4..-1''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Community Bonding Period (4 weeks)''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|'''23/04 - 20/05'''<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|'''-4..-1'''<br />
|style="border:1px dotted #AAA;padding:5px;"|'''Phase 0: Approach'''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|23/04 - 20/05<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|-4..-1<br />
|style="border:1px dotted #AAA;padding:5px;"|Familiarise myself with the Whiteboard, in the process start a draft of the design document.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|23/04 - 20/05<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|-4..-1<br />
|style="border:1px dotted #AAA;padding:5px;"|Start working on the ''polishing''.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''21/05''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''0''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Start of GSoC''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|21/05 - 12/08<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|0..11<br />
|style="border:1px dotted #AAA;padding:5px;"|Continuously work on the design document and on the code polishing.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''21/05 - 15/07''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''0..7''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''First half term (8 weeks)''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|'''21/05 - 10/06'''<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|'''0..2'''<br />
|style="border:1px dotted #AAA;padding:5px;"|'''Phase 1: <code>side_actions</code> refactoring'''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|21/05 - 27/05<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|0<br />
|style="border:1px dotted #AAA;padding:5px;"|Prepare <code>side_actions</code> for the change. Add debug informations to the logs. Add the new member <code>turn_beginnings_</code>.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|28/05 - 03/06<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|1<br />
|style="border:1px dotted #AAA;padding:5px;"|Change the type of <code>actions_</code> and rewrite the associated functions. Delete the custom iterators.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|04/06 - 10/06<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|2<br />
|style="border:1px dotted #AAA;padding:5px;"|Debug, write unit test and documentation.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|'''11/06 - 01/07'''<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|'''3..5'''<br />
|style="border:1px dotted #AAA;padding:5px;"|'''Phase 2: Validator hierarchy refactoring'''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|11/06 - 17/06<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|3<br />
|style="border:1px dotted #AAA;padding:5px;"|Write the class <code>action_set</code>.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|18/06 - 24/06<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|4<br />
|style="border:1px dotted #AAA;padding:5px;"|Replace the uses of <code>enable_visit_all</code> with the new interface. Then delete <code>enable_visit_all</code>.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|25/06 - 01/07<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|5<br />
|style="border:1px dotted #AAA;padding:5px;"|Debug, write unit test and documentation.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|'''02/07 - 22/07'''<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|'''6..8'''<br />
|style="border:1px dotted #AAA;padding:5px;"|'''Phase 3: Transfer of the action and validation logic into the core'''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|02/07 - 08/07<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|6<br />
|style="border:1px dotted #AAA;padding:5px;"|Separation of the Whiteboard specific-code from the actions. Transfer of the actions in the core.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|09/07 - 15/07<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|7<br />
|style="border:1px dotted #AAA;padding:5px;"|Use this new API in other places, including the <code>mapbuilder</code>.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''13/07''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''7''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Mid-term evaluation''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''16/07 - 26/08''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''8..13''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Second half term (6 weeks)''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|16/07 - 22/07<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|8<br />
|style="border:1px dotted #AAA;padding:5px;"|Document the new action hierarchy. Mark @deprecated copies of it.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|'''22/07 - 12/08'''<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|'''9..11'''<br />
|style="border:1px dotted #AAA;padding:5px;"|'''Phase 4: Finalisation'''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|22/07 - 29/07<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|9<br />
|style="border:1px dotted #AAA;padding:5px;"|Heavy testing week.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|30/07 - 05/08<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|10<br />
|style="border:1px dotted #AAA;padding:5px;"|Test, debug. Finish the ''polishing''.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|06/08 - 12/08<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|11<br />
|style="border:1px dotted #AAA;padding:5px;"|Test, debug. Finish the design document.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|13/08 - 19/08<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|12<br />
|style="border:1px dotted #AAA;padding:5px;"|Movable week.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|20/08 - 26/08<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|13<br />
|style="border:1px dotted #AAA;padding:5px;"|Movable week.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''24/08''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''13''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Final evaluation''<br />
|}</div>Ejlshttps://wiki.wesnoth.org/index.php?title=User:Artemius23&diff=46372User:Artemius232012-04-10T00:12:17Z<p>Ejls: SummerOfCodeIdeas-fication</p>
<hr />
<div>{{SoC2012Student}}<br />
[[Category:SoC Ideas AI Scenario Objectives 2012]]<br />
=Description=<br />
<h4>Yigit Demirag : Development of AI to Play Mainline Campaigns in Battle For Wesnoth </h4><br />
Battle For Wesnoth is a great game to feel a war especially in Linux platform.<br />
Mainly, I can teach AI to play Westnoth's mainline campaings while it can interact user well.I want to develop its AI and put in opportunities of any kind of AI and machine learning algorithms such as supervised and unsupervised learning. <br />
<br />
I am planning implementing feasible logical and reasoning algorithms which suitable for this. Decisions trees and inductive learning again, if it is suitable, are good to code in the game. But the most important part is playing and feeling how it works once than I can fill the necessary parts with the help of any algorithm we can apply.<br />
<br />
=IRC=<br />
Artemius23, Artemius<br />
<br />
=Questionnaire= <br />
<br />
===1) Basics===<br />
<br />
====1.1) Write a small introduction to yourself.====<br />
<br />
I’m Yigit DEMIRAG and I am 21 years old. I have grown up with a passion about science so I graduated from a science school which is one of the best of my country and became an engineer to materialize the ideas taken from the nature. As hobbies, I like professional swimming and I am continuing Bachata dance. That is the way I relax and think clearly. <br />
<br />
====1.2) State your preferred email address.====<br />
<br />
I always use, and be online at yigitdemirag@gmail.com<br />
<br />
====1.3) If you have chosen a nick for IRC and Wesnoth forums, what is it?====<br />
<br />
I use Artemius23 in IRC but currently don’t have an account in Wesnoth forums. <br />
<br />
====1.4) Why do you want to participate in summer of code?====<br />
<br />
I want to participate in summer of code because of that I work really hard in my academic year and try to push it upmost and I need focus on something that I believe it may make a difference in the world. This summer, I can easily focus on an exciting project and make it on air as soon as possible with making it my priority. I am enchanted about coding and I have a great free time to do it.<br />
<br />
====1.5) What are you studying, subject, level and school?====<br />
<br />
I am an undergraduate student in Bilkent University which has the best engineering departments in my country, Turkey. My major is Electrical and Electronics Engineering but I passionately curious about Computer Scince with motto : “It is more fun to compute.”<br />
I’m mostly interested in Artificial Intelligence, Machine Learning and Parallel Computing. <br />
<br />
====1.6) What country are you from, at what time are you most likely to be able to join IRC?====<br />
<br />
I’m from Turkey, and I am most likely to be able to join IRC from 9pm to 3pm. <br />
<br />
====1.7) Do you have other commitments for the summer period ? Do you plan to take any vacations ? If yes, when.====<br />
<br />
I don’t have any other commitments for the summer period. On the other hand, I will be able to be in pool twice a week for a 4 hours each since I have keep my swimming trainings on. <br />
<br />
===2) Experience===<br />
<br />
====2.1) What programs/software have you worked on before?====<br />
<br />
Last summer, I worked on accelerating MLFMA and parallelization algorithms of clusters at BiLCEM ( please check the -World Record- ) http://www.cem.bilkent.edu.tr/world_record<br />
My research area was specifically examining and comparing the MPI and openMP in terms of their memory usages, speeds and their feasibility in supercomputers. By examining and implementing openMP in nodes and MPI within nodes and clusters, we reached almost %25 speeding up in our cluster in our experiments. During this period I wrote a couple of benchmark programs to monitoring our clusters and also helping to develop a meshing algorithm (It was a little part of the research )to use in electromagnetic simulation.<br />
<br />
Last year, I developed a mobile platform based game called “Green World.” , individually. In Green World, every person can create their own virtual world in the limit of only their imaginations. Users can define buildings, temples also add rooms, stuff and objects wherever they want. Each user can view other’s places they created and stroll around it to explore the world. During this process I used Java. At the end of the semester, I participate “Oyun Ciddi Bir İştir.” - Game is a Serious Business- competition and became a finalist from among more than 30 games. <br />
<br />
====2.2) Have you developed software in a team environment before? (As opposed to hacking on something on your own) ====<br />
<br />
We are developing and 3D- Arduino Simulator with some of my friends who have passion to computer science and want to get into code. This is the GitHub link of my projects - still in development process, but will be finished in maximum 1,5 months. https://github.com/kgns/3D-Arduino-Simulator<br />
<br />
====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?====<br />
<br />
I don’t have participated to Google Summer of Code before. I have been in a summer intern last summer and <br />
have to focus that research. <br />
<br />
====2.4) Are you already involved with any open source development projects? If yes, please describe the project and the scope of your involvement.====<br />
<br />
We are planning to make 3D-Arduino Simulator free and easy to access for every enthusiasts. We have already in the interests of some people from open-source community. <br />
<br />
===2.5) Gaming experience - Are you a gamer?===<br />
<br />
I like gaming. I would not identify me as a good gamer but what I like in games is interacting with computers which are sometimes able to good player as well as a human.<br />
<br />
====2.5.1) What type of gamer are you?====<br />
<br />
I play to create things and push my mind efforts. So in my opinion, there is no spesific need to play for me, I play to be relaxed, to challenge or to defeat computer or some human. That is why I want to code in AI. I want a stronger player right before me. <br />
<br />
====2.5.2) What type of games?====<br />
<br />
I prefer mostly strategy games and mmorpgs such as Minecraft, Dragons Age III and Diablo series. <br />
<br />
====2.5.3) What type of opponents do you prefer?====<br />
<br />
I like my opponents when they play the game as professional as me. Whatever the game, they have to attack well and push me back, as well as, defending themselves which makes me search to new ways to attack. I should not feel myself as a nerd who plays a ordinary game, I have to feel deeply inside in the game and feel strongly about it when I away from a computer.<br />
<br />
====2.5.4) Are you more interested in story or gameplay? ====<br />
<br />
In my opinion, story influences me when I away from computer and reminds me that game but gameplay connects me to computer and makes me spending funny times when I play.<br />
<br />
====2.5.5) Have you played Wesnoth? If so, tell us roughly for how long and whether you lean towards single player or multiplayer.====<br />
<br />
I played Wesnoth for one week as a single player last year. So I have general knowledge about Wesnoth and how can it be played.<br />
<br />
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.<br />
<br />
====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.====<br />
<br />
No, I haven’t contribute any project related to Wesnoth before.<br />
<br />
===3) Communication skills===<br />
<br />
====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.====<br />
<br />
I have taking English lessons for 4 years. Also I passed the English proficiency exam and studying in EEE Department which has %100 lessons are in English.<br />
<br />
====3.2) What spoken languages are you fluent in?====<br />
<br />
Turkish and English. <br />
<br />
====3.3) Are you good at interacting with other players? Our developer community is friendly, but the player community can be a bit rough.====<br />
<br />
Until present, I have played lots of online game and I had a tons of conversation with people who I don’t know but expect something from me, then it is never a problem. Additionally, I am good at dealing with people, I run a couple of organization in my university and experienced what is the importance of interacting with people well. <br />
<br />
====3.4) Do you give constructive advice?====<br />
<br />
I attach importance to be a part of solution so I always try to express myself in a solution-based approach. <br />
<br />
====3.5) Do you receive advice well?====<br />
<br />
I believe learning from the mistakes is an important part of life. To keep pushing correctly, you have to know what was the mistakes you have done. So it is a necessity for me to learn from my mistakes.<br />
<br />
====3.6) Are you good at sorting useful criticisms from useless ones? ====<br />
<br />
Since the first time I have to study very hard, I know the role of an agenda for me. I consider sorting useful things and take note of its priority. My brain always want to work as parallel but setting priorities is my priority.<br />
<br />
====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====<br />
<br />
I don’t start a code without full idea that what I have to do. It makes to waste time. Since thinking and dreaming about something is faster than implementing it, I want to know necessary parts of the concept so I can continue to code and fill the empty parts individually.<br />
<br />
===4) Project===<br />
<br />
====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?====<br />
<br />
Actually I do not strongly favor one of the ways of AI development in Wesnoth. But I mainly prefer teaching AI to play Wesnoth’ s mainline campaigns in terms of developing the AI and bringing a sense for the game. I want to concentrate on making player not to feel alone and isolated, I want a game which user can interact with AI and receive an adaptive response while playing the game. <br />
<br />
====4.2) If you have invented your own project, please describe the project and the scope.====<br />
<br />
Before I reading the suggestions of Wesnoth Developers, I thought that making agents that can play with user is such an exciting idea and generally if there is already an AI in a game, making it more intelligent is also perfect.<br />
<br />
====4.3) Why did you choose this project?====<br />
<br />
I choose it because I believe one day people can easily communicate with AI agents. Creating little intelligent agents and watching their behaviours always influences me. When I was coding, search algorithms or supervised machine learning algorithms, I feel deeply concentration about it. But this is a game. Our agents will interacts with real people, be affected by them and responses accordingly. This is why I choose this project.<br />
<br />
====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".====<br />
<br />
First one or two week I have to play Wesnoth well to learn the way a user play and how AI acts on it. This process includes reading documentation and getting touch with people who plays a role of AI development of Wesnoth.<br />
Then, I can start to code as developers expected and watch its consequences. I can keep in touch with people that is not a problem so I can easily handle any problem about algorithm or the system we implementing on it. Even I want to continue if I complete this part well to develop new AI systems on Wesnoth. <br />
<br />
I will be busy with my finals at the last 2 week of the May. So I may not be able to fully concentrate on the project.After that, I will be at home during the summer and I cannot see any obstacle for me to prevent me to code.<br />
<br />
====4.5) Include as much technical detail about your implementation as you can====<br />
<br />
I am planning implementing feasible logical and reasoning algorithms I know. Decisions trees and inductive learning again, if it is suitable, are good to code in the game. But the most important part is playing and feeling how it works once than I can fill the necessary parts with the help of any algorithm we can apply. Also in Bilkent University I know lots of people who interested in AI and Machine Learning. So we can consult them for their help as well.<br />
<br />
====4.6) What do you expect to gain from this project? ====<br />
<br />
I want to implement all of my theoretical knowledge from AI lessons I take from Stanford University and as an open source team, I want to work in an exciting project as an AI developer. <br />
<br />
====4.7) What would make you stay in the Wesnoth community after the conclusion of SOC?====<br />
<br />
Maybe just one Wesnoth T-shirt is enough to stay in the Wesnoth community after the GSoC’ 12. I am still helping my old researcher friends in their projects in parallel computing. I believe that if I help people and improve things, some things become better. And it always worths. <br />
<br />
===5) Practical considerations===<br />
<br />
====5.1) Are you familiar with any of the following tools or languages?====<br />
<br />
I take a Artificial Intellegence lessons from Sebastian Thrun from Stanford University. Through this process I used Python. And in all of my remained projects I used C/C++, Java and FORTRAN 95 . <br />
<br />
====5.2) Which tools do you normally use for development? Why do you use them?====<br />
<br />
Since I use only UNIX, I prefer Eclipse, and also use Sublime Text Editor 2 since it is highly useful while coding and developing its features. <br />
<br />
====5.3) What programming languages are you fluent in?====<br />
<br />
Respectively, <br />
<br />
Java, C/C++, Python, FORTRAN 95<br />
<br />
====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!====<br />
<br />
I have Skype ID : yigitdemirag<br />
And my cellphone is : +905548532255<br />
IRC@freenode.net : Artemius23</div>Ejlshttps://wiki.wesnoth.org/index.php?title=SpellingMistakes&diff=46314SpellingMistakes2012-04-08T00:51:38Z<p>Ejls: Removing a typo fixed by r53847</p>
<hr />
<div>This page is meant to be a list of spelling mistakes in campaigns and other translatable texts in the en_US development version of the game.<br />
<br />
Note: The house style of Wesnoth uses a good many words and constructions that are archaic, poetic, or dialectal. If you speak modern English as a second language you may incorrectly read these as errors. Please see [[NotSpellingMistakes]] for a list of things you will encounter that may look like spelling or usage errors but are not. Note that the mainline campaigns are now using correct typography, including sexed quotes and en and em dashes. These will appear as three byte sequences if you are not using a viewer that supports UTF-8.<br />
<br />
==Mainline Campaigns==<br />
<br />
===An Orcish Incursion===<br />
<br />
===Dead Water===<br />
<br />
===Delfador’s Memoirs===<br />
<br />
===Descent into Darkness===<br />
<br />
===Eastern Invasion===<br />
<br />
===Heir to the Throne===<br />
<br />
===Liberty===<br />
<br />
===Northern Rebirth===<br />
<br />
===Sceptre of Fire===<br />
<br />
===Son of the Black Eye===<br />
<br />
===The Hammer of Thursagan===<br />
<br />
===The Legend of Wesmere===<br />
<br />
===The Rise of Wesnoth===<br />
<br />
===The South Guard===<br />
<br />
===Two Brothers===<br />
<br />
===Under the Burning Suns===<br />
<br />
S6a, line 685 in the .cfg: seems to be missing a verb: ''"[...] but I will '''''???''''' once you finish your mission."'' Maybe "return"?<br />
<br />
==Wesnoth Game==<br />
<br />
===Editor===<br />
<br />
===Help===<br />
<br />
===Tutorial===<br />
<br />
===Manual===<br />
<br />
===Manpages===<br />
<br />
===Units===<br />
<br />
===1.10 Announcement===<br />
<br />
===Other (unit descriptions, ...)===<br />
<br />
===Multiplayer maps===<br />
<br />
===Translation code bugs===<br />
<br />
==Unofficial campaigns==<br />
<br />
===Invasion from the Unknown===</div>Ejlshttps://wiki.wesnoth.org/index.php?title=GSoC_Akihara_Proposal&diff=46312GSoC Akihara Proposal2012-04-08T00:09:22Z<p>Ejls: SummerOfCodeIdeas-fication</p>
<hr />
<div>{{SoC2012Student}}<br />
[[Category:SoC_Ideas_AI_Recruitment_2012]]<br />
<br />
= Description =<br />
==== Aline Riss Recruitment Proposal ====<br />
<br />
For the moment, AI van only use one leader in order to recruit unit even if they are two. Moreover, the recruitment algorithm is very basic.<br />
My proposal will turn around two main points:<br />
* The use of more than one leader even if we have only one keep: placement, chose of the right keep,.. )<br />
* The recruitment according to some map's characteristics (enemy's unit, terrain, limitation, etc.)<br />
<br />
The most important thing for the moment is AI to use several leaders. Then, I will work on limitation for each leader. Finally, I will work on the recruitment algorithm.<br />
<br />
= About me =<br />
<br />
I'm a 22 french student girl. I'm currently studying computer science and I would like to specialize myself in development. I'm fond of open source things but never took part of an project. So GSoC is, for me, a first step in this world. <br />
I'm studying computer science in the University of Technology of Belfort Monbéliard (France). I'm a 3-year student. For the moment, I'm studying very various things (dev, network, ...) but I clearly want to be a dev.<br />
You can join me at aline.riss[at]gmail.com and also on IRC with the nickname Akihara. Moreover, I have an irssi server running without interruption so I will always be connected. So, I'm more joinable and, even if i'm not in front of my screen, I will see messages and things like that. I'm generally here at 9am (France - GMT + 2).<br />
<br />
== IRC ==<br />
Akihara<br />
<br />
= Experience =<br />
<br />
None. It's the first time I will be working on a "real" project. All I have done is school projects for the moment. For example, I developed a graphic interface in order to learn graph theory in a team environment. We were 6.<br />
<br />
It's the first time I want to participate to the Google Summer of Code. As I said before, I never took part in any open source projects.<br />
<br />
= Gaming = <br />
<br />
I'm a real gamer. I'm between a mid-core and hardcore gamer :) I can play video game without interruption but I limit myself. I play very various games. I really like RPGs in which I can discover a new world but also FPS, very relaxig for me (strange, isn't it?), and also Strategy game for reflexion and the joy of aiming the goal. <br />
Generally, I prefer play against AI. But mostly, they are too weak too fast. On the other hand, playing against people is very fun when they are not yelling around.<br />
<br />
The reason I can stop myself is the discovering of the environment and also the story. I can difficulty stop myself playing until I know the end. Because of that, I'm attracted to RPG and other game with an unknown world. But I must admit that a good gameplay is very important. Without it, a game isn't a game anymore. <br />
<br />
I played Wesnoth some years ago (4? 5?) so didn't remember lot of things but I always played as a single player. But, in order to know the environment, I will play a little until the beginning of the GSoc.<br />
<br />
= My contribution to Wesnoth =<br />
== Patches ==<br />
<br />
{| class="wikitable centre" width="80%"<br />
|+<br />
|-<br />
! scope=col | Patch #<br />
! scope=col | Description<br />
! scope=col | Link<br />
|-<br />
| width="10%" |<br />
3237<br />
| width="34%" |<br />
'''''TRANSFORM_UNIT needs a variable renamed'''''<br />
| width="10%" |<br />
[http://gna.org/patch/?3237 Link]<br />
|-<br />
| width="10%" |<br />
3238<br />
| width="34%" |<br />
'''''"maximum auto saves" setting seems ignored'''''<br />
| width="10%" |<br />
[http://gna.org/patch/?3238 Link]<br />
|}<br />
<br />
I'm currently working on an AI problem: in fact, it seems that a unit prefer to repoison an poisoned unit instead of poison other unit.<br />
<br />
= Communication skills =<br />
<br />
I'm daily reading English so I have a good reading comprehension. In written english, I will do my best. I can do some mistakes but nobody didn't understand me.<br />
<br />
I think that the player community can be a bit rough as in mostly communities. I have no problem speaking with them. I'm a player too so I can understand what they say and how they feel. I won't be distracted by some rough players.<br />
<br />
In the dev community, If I can give some advice, I will. I'm not a specialist but I'm always here to help. If I have an idea, why not submit it? And the reciprocal is right too, even if I'm not agree this it. In this case, we can confront both idea. If I am right, the other person will learn something and reciprocally. I think that it is the magic of team work. Of course, part of them can be useful and others useless. I'm the type of person who will think about it again and again. Finally, I will be able to take the good part of them.<br />
<br />
Concerning my behavior when developing, I will say that generally, I need to know the environment (here the game). If I have an idea, I will first search how I can implement it. Parallel, I really like to talk with someone interested in my work in order explain and, why not, improve it.<br />
<br />
If I have no idea, I look sources at the beginning.<br />
<br />
Then, I will "see how it turn out" so I can have a better idea of what I am doing. I prefer doing it this way before losing time on something which will no work.<br />
<br />
= Project =<br />
== Why ==<br />
I choose a project from the list: "Refactor recruitment algorithm". I'm very interrested in AI algorihtm and how make them more intelligent. It's really interresting. I think that recruitment, in a game like this, is the beginning of everything. And it's also a question i'm asking to myself when I'm playing.<br />
<br />
I hope gain some experience from this project , and a view of how dev a game works. I'm very curious about this. And if I'm well integrated, I will stay and continue developing it.<br />
<br />
== Timeline ==<br />
<br />
* Get to know how the current AI work (unit behaviour, recruitment, etc...) '''(~ 1 week)'''<br />
* AI can use more than one leader: '''(~ 3 week)'''<br />
** Recognition of all leaders (few days)<br />
** Work on case 2: ''2 leaders - 2 keeps'' (~ 1,5 week)<br />
*** AI can move leader to keep<br />
*** AI can determine the best couple <leader, keep><br />
*** AI can recruit with all leader<br />
** Work on case 1.1: ''2 leaders - 1 keep - same type'' (1 week)<br />
*** AI can determine which leader will stay on keep<br />
*** if a keep is unoccupied, the second leader will go on it <br />
** Work on case 1.2 ''2 leaders - 1 keep - different type'' (few days)<br />
*** AI can make the change of leader<br />
*** AI can recruit with all leaders<br />
* Limit each leader '''(few days)'''<br />
* Begin work about the recruitment algorithm '''(~ 4 week)'''<br />
** Implementation of minmax algorithm (1 week)<br />
** Determine formula (~ 1,5 week)<br />
*** calculate enemy's unit type<br />
*** number of specific enemy unit type and number of enemy unit which can counter the AI specific unit<br />
*** number of unit we already have<br />
*** knowing the terrain<br />
*** the level of enemy's unit<br />
** Test with a single unit and debug (few days)<br />
** Test with complete list of recruitment (~1,5 week)<br />
*** Determine the full list<br />
*** Associate each list to their leader<br />
<br />
If time, I will also work on the case 3.<br />
<br />
== My idea ==<br />
<br />
I don't know the code structure yet except that it is in C++. I work on a AI once using a min-max algorithm which can be a good start. But I don't think that it is the better solution.<br />
<br />
=== Support multiple leaders ===<br />
<br />
''Current situation: For the moment, AI only use the first leader to recruit even if a 2nd leader is on keep an can recruit. Other point, if leaders are not on keep, AI must figure out a good leep for each leader, and move them to keeps.''<br />
<br />
==== Structure ====<br />
All units (whatever their side) are currently stored into a <code>unit_map</code> which associate unit with their location. <br />
<br />
First, we need to change the function <code>unit_map::unit_iterator unit_map::find_leader(int side)</code> in order to returning the list of leaders of a particular side.<br />
<br />
But with the currently solution, the AI can only use the first leader in the list as a leader (recruitment and move on keep).<br />
<br />
We also have <code>leader_list</code> used for multiplayer game. We can think of a way of using it.<br />
<br />
<br />
==== Placement ====<br />
We can have several case with different number of leaders and different number of keeps. We will look as each separately. <br />
<br />
===== Case 1.1: several leaders (same type) - one keep =====<br />
If we have two, for example, leaders of the same type on a unique keep, we need to know which one will stay on the keep. We know that two different leaders can have different characteristics, so if one of them can be better in battle, he will leave and let the other on the keep.<br />
<br />
But the second leader mustn't go alone. He need to be surrounded. If he can, he will ''capture'' the enemy's keep (see case 2).<br />
<br />
In this case, we have:<br />
* ''a single list of recruitment''<br />
<br />
===== Case 1.2: several leaders (different type) - one keep =====<br />
In this case, we have at least two leaders of different types with only one keep. Let's name them A for the first (on the keep) and B the other one. The problem here is to use the two of them. The choose of the unit will be explain in the recruitment part (see '''recruitment'''). <br />
<br />
In this case, we have:<br />
* ''two recruitment_list''<br />
<br />
So, we have several cases:<br />
* If we only have unit A can recruit in the recruitment list, A will stay. B can go fight but not really far. He also can recruit on the next turn.<br />
* If we only have unit B can recruit in the recruitment list, A will go away and can fight. B will go on the keep in order to recruit.<br />
* If we have unit of both type, we will recruit the A list and then the B list.<br />
<br />
===== Case 2: several leaders - several keep =====<br />
<br />
Moving leaders on the right keep is the first problem. In fact, leaders can have different characteristic like moving faster for example. In this case, we must know the better way to reach the nearest keep as soon as possible. Of course, we can have a "basic" behavior which will assign the fastest leader to the nearest keep. A good things to do will be to calculate the best couple <leader, keep> for having all keeps reached as quickly as possible.<br />
It can be also useful to create a ''new class'' for having this couple in memory. If so, we aren't obliged to recalculate each path a second time. But we must calculate the state of keeps each time. I explain:<br />
Each turn, the enemy can put one of his leader on a keep the AI was watching. In this case, the leader must go back and find an other keep if there is any.<br />
<br />
In this case, we have<br />
* two recruitment list<br />
<br />
===== Case 3: m leaders - n keeps (m > n) =====<br />
If we have a number of leader superior than the number of keeps (and > 2), we will do:<br />
* choose leaders which will stay on keep. If leaders are from different types, we will chosen one of each to be on a keep. It will give to the player an good opportunity to play against various unit.<br />
* the other leaders will go to the front keep. If we can make a mix of type on front keep, we will do so. Otherwise, leaders will fight. <br />
<br />
In that case, we have:<br />
* between n and m recruitment list<br />
<br />
=== Support per-leader recruit/recall list ===<br />
<br />
In the case we can found different leader with different limitation, we need to create, I think, a specific class for them which will inherit the <code>unit</code> class.<br />
In fact, Leader are very special unit: they are the only one which can recruit and they will be the only one which will have a sort of limitation.<br />
<br />
Of course, we can add an other attribute to the <code>unit</code> class.<br />
<br />
For saving these limitation, we can use a mapping <unit, number> which will associate a unit to his limitation. If two leader have the same limitation, they will share the same mapping. Otherwise, they will have their own. The principle is to decrease the number associate to a specific unit when we recruit it. If one dies, the number is increased.<br />
With this method, the AI knows automatically which unit he can recruit.<br />
<br />
=== Recruitment strategie ===<br />
<br />
==== MinMax ====<br />
In order to make an effective counter-recruiting, an idea will to implement an 2-depth minmax algorithm.<br />
<br />
In order to make it, AI needs to cheat a little (all AI cheat... no?) in order to know what the player can recruit.<br />
<br />
This algorithm works very well, but has some negative points:<br />
* he can be a little slow... but it will be ok for a 2-depth algorithm.<br />
* depends on the formula. If the formula is precise, the algorithm will have better result.<br />
<br />
For the formula, according to my experience (I implemented it last year), it's the game experience which will give it. In fact, it can be precise if we don't play. The main question we need to answer is ''When I am in a good situation or in a bad situation?''.<br />
<br />
If it works well, it can also solve few problem of recruitment:<br />
* Knowing how much unit type recruit according to a situation<br />
* Not spend all gold for nothing<br />
* Not overestimating the value of high-level recruits<br />
* Recruit more suitable unit for the terrain<br />
<br />
===== Formula =====<br />
In order to choose the recruitment list, we need to know a few things:<br />
* '''enemy's unit type''': AI must privileged the correct unit type in order to strike back. If we can find a type that can counter several enemy's unit, it will be better to privileged it.<br />
* '''number of specific enemy unit type''' and '''number of enemy unit which can counter the AI specific unit''': in order to know how much unit AI must recruit, we must calculate a good number of unit which are enough to attack the enemy but also cover some killed unit.<br />
* '''number of unit we already have''': for a specific unit, and in order to have a good mix of unit, we need to know how much unit of a specific type we have for knowing if we can, or not, recruit an other one.<br />
* '''knowing the terrain''': some unit are better on some specific terrain. We can look at the map and calculate the most used terrain between two keeps (Ai's and enemy's).<br />
* '''the level of enemy's unit''': in fact, if we have a 3 level enemy unit, one 1 level unit isn't enough to face it. So the level is an important point to considerate.<br />
<br />
==== Working on different recruitment list ====<br />
To create a good recruitment list for each leader, the minmax algorithm will work on one list. This one will contain unit recruited by both of the leader.<br />
In order to do that, we must know the '''number of possible recruitment''' for each leader. The sum of all these number will the maximum list length.<br />
<br />
* In the case of ''same type leader'', we need to determine which leader will recruit the chosen unit. For that, we can look at proximity with the enemy unit (and there type) for example.<br />
* In the case of ''different types leader'', we need to take care of the limitation of each leader in order to not recruit more unit than possible.<br />
<br />
When everything is alright concerning the '''general''' recruitment list, we can separate it into two part and attribute them to their leader.<br />
<br />
= Practical considerations =<br />
<br />
When using a PPO language, I like using an application like Eclipse. It's very usefull and I can be faster with it. Otherwise, I simply use vim in a shell.<br />
I really like PPO language like JAVA. JAVA is obviously the language I have more experience with.<br />
Moreover, I coded in c, c++, python, prolog and I think it's all.<br />
<br />
* Subversion - I have my own svn.<br />
* C++ - I developed in c++ some years ago but I will remember since the start of GSoC<br />
* STL, Boost, Sdl - never used.<br />
* Python - I know it, used some times.<br />
* build environments - I know cmake but not scons<br />
* WML - no :(<br />
* Lua - neither.</div>Ejlshttps://wiki.wesnoth.org/index.php?title=GSoC_Akihara_Proposal&diff=46304GSoC Akihara Proposal2012-04-07T22:18:05Z<p>Ejls: SummerOfCodeIdeas-fication</p>
<hr />
<div>{{SoC2012Student}}<br />
[[Category:SoC_Ideas_AI_Recruitment_2012]]<br />
<br />
= About me =<br />
<br />
I'm a 22 french student girl. I'm currently studying computer science and I would like to specialize myself in development. I'm fond of open source things but never took part of an project. So GSoC is, for me, a first step in this world. <br />
I'm studying computer science in the University of Technology of Belfort Monbéliard (France). I'm a 3-year student. For the moment, I'm studying very various things (dev, network, ...) but I clearly want to be a dev.<br />
You can join me at aline.riss[at]gmail.com and also on IRC with the nickname Akihara. Moreover, I have an irssi server running without interruption so I will always be connected. So, I'm more joinable and, even if i'm not in front of my screen, I will see messages and things like that. I'm generally here at 9am (France - GMT + 2).<br />
<br />
== IRC ==<br />
Akihara<br />
= Experience =<br />
<br />
None. It's the first time I will be working on a "real" project. All I have done is school projects for the moment. For example, I developed a graphic interface in order to learn graph theory in a team environment. We were 6.<br />
<br />
It's the first time I want to participate to the Google Summer of Code. As I said before, I never took part in any open source projects.<br />
<br />
= Gaming = <br />
<br />
I'm a real gamer. I'm between a mid-core and hardcore gamer :) I can play video game without interruption but I limit myself. I play very various games. I really like RPGs in which I can discover a new world but also FPS, very relaxig for me (strange, isn't it?), and also Strategy game for reflexion and the joy of aiming the goal. <br />
Generally, I prefer play against AI. But mostly, they are too weak too fast. On the other hand, playing against people is very fun when they are not yelling around.<br />
<br />
The reason I can stop myself is the discovering of the environment and also the story. I can difficulty stop myself playing until I know the end. Because of that, I'm attracted to RPG and other game with an unknown world. But I must admit that a good gameplay is very important. Without it, a game isn't a game anymore. <br />
<br />
I played Wesnoth some years ago (4? 5?) so didn't remember lot of things but I always played as a single player. But, in order to know the environment, I will play a little until the beginning of the GSoc.<br />
<br />
= My contribution to Wesnoth =<br />
== Patches ==<br />
<br />
{| class="wikitable centre" width="80%"<br />
|+<br />
|-<br />
! scope=col | Patch #<br />
! scope=col | Description<br />
! scope=col | Link<br />
|-<br />
| width="10%" |<br />
3237<br />
| width="34%" |<br />
'''''TRANSFORM_UNIT needs a variable renamed'''''<br />
| width="10%" |<br />
[http://gna.org/patch/?3237 Link]<br />
|-<br />
| width="10%" |<br />
3238<br />
| width="34%" |<br />
'''''"maximum auto saves" setting seems ignored'''''<br />
| width="10%" |<br />
[http://gna.org/patch/?3238 Link]<br />
|}<br />
<br />
I'm currently working on an AI problem: in fact, it seems that a unit prefer to repoison an poisoned unit instead of poison other unit.<br />
<br />
= Communication skills =<br />
<br />
I'm daily reading English so I have a good reading comprehension. In written english, I will do my best. I can do some mistakes but nobody didn't understand me.<br />
<br />
I think that the player community can be a bit rough as in mostly communities. I have no problem speaking with them. I'm a player too so I can understand what they say and how they feel. I won't be distracted by some rough players.<br />
<br />
In the dev community, If I can give some advice, I will. I'm not a specialist but I'm always here to help. If I have an idea, why not submit it? And the reciprocal is right too, even if I'm not agree this it. In this case, we can confront both idea. If I am right, the other person will learn something and reciprocally. I think that it is the magic of team work. Of course, part of them can be useful and others useless. I'm the type of person who will think about it again and again. Finally, I will be able to take the good part of them.<br />
<br />
Concerning my behavior when developing, I will say that generally, I need to know the environment (here the game). If I have an idea, I will first search how I can implement it. Parallel, I really like to talk with someone interested in my work in order explain and, why not, improve it.<br />
<br />
If I have no idea, I look sources at the beginning.<br />
<br />
Then, I will "see how it turn out" so I can have a better idea of what I am doing. I prefer doing it this way before losing time on something which will no work.<br />
<br />
= Project =<br />
== Why ==<br />
I choose a project from the list: "Refactor recruitment algorithm". I'm very interrested in AI algorihtm and how make them more intelligent. It's really interresting. I think that recruitment, in a game like this, is the beginning of everything. And it's also a question i'm asking to myself when I'm playing.<br />
<br />
I hope gain some experience from this project , and a view of how dev a game works. I'm very curious about this. And if I'm well integrated, I will stay and continue developing it.<br />
<br />
== Timeline ==<br />
<br />
First, i will take i few days to know the implementation structure. (1-3 days)<br />
<br />
Second, see the current solution and understand it. It's always usefull to know how it works now before changing everything.(1-2 days)<br />
<br />
Then, even if I have my own idea, I will probably speak to wesnoth players. In fact, I will need different point of view concerning the subject. I will probably also go to the forum. (few days)<br />
<br />
I will begin coding. Of course, the third point is never really closed. It's always usefull to have new argument.<br />
<br />
Test & Play<br />
<br />
If it goes to the right way, it's ok. Otherwise, I will reconsider the third point.<br />
<br />
<br />
<br />
<br />
== My idea ==<br />
<br />
I don't know the code structure yet except that it is in C++. I work on a AI once using a min-max algorithm which can be a good start. But I don't think that it is the better solution.<br />
<br />
=== Support multiple leaders ===<br />
<br />
''Current situation: For the moment, AI only use the first leader to recruit even if a 2nd leader is on keep an can recruit. Other point, if leaders are not on keep, AI must figure out a good leep for each leader, and move them to keeps.''<br />
<br />
==== Structure ====<br />
All units (whatever their side) are currently stored into a <code>unit_map</code> which associate unit with their location. <br />
<br />
First, we need to change the function <code>unit_map::unit_iterator unit_map::find_leader(int side)</code> in order to returning the list of leaders of a particular side.<br />
<br />
But with the currently solution, the AI can only use the first leader in the list as a leader (recruitment and move on keep).<br />
<br />
We also have <code>leader_list</code> used for multiplayer game. We can think of a way of using it.<br />
<br />
<br />
==== Placement ====<br />
We can have several case with different number of leaders and different number of keeps. We will look as each separately. <br />
<br />
===== Case 1.1: several leaders (same type) - one keep =====<br />
If we have two, for example, leaders of the same type on a unique keep, we need to know which one will stay on the keep. We know that two different leaders can have different characteristics, so if one of them can be better in battle, he will leave and let the other on the keep.<br />
<br />
But the second leader mustn't go alone. He need to be surrounded. If he can, he will ''capture'' the enemy's keep (see case 2).<br />
<br />
In this case, we have:<br />
* ''a single list of recruitment''<br />
<br />
===== Case 1.2: several leaders (different type) - one keep =====<br />
In this case, we have at least two leaders of different types with only one keep. Let's name them A for the first (on the keep) and B the other one. The problem here is to use the two of them. The choose of the unit will be explain in the recruitment part (see '''recruitment'''). <br />
<br />
In this case, we have:<br />
* ''two recruitment_list''<br />
<br />
So, we have several cases:<br />
* If we only have unit A can recruit in the recruitment list, A will stay. B can go fight but not really far. He also can recruit on the next turn.<br />
* If we only have unit B can recruit in the recruitment list, A will go away and can fight. B will go on the keep in order to recruit.<br />
* If we have unit of both type, we will recruit the A list and then the B list.<br />
<br />
===== Case 2: several leaders - several keep =====<br />
<br />
Moving leaders on the right keep is the first problem. In fact, leaders can have different characteristic like moving faster for example. In this case, we must know the better way to reach the nearest keep as soon as possible. Of course, we can have a "basic" behavior which will assign the fastest leader to the nearest keep. A good things to do will be to calculate the best couple <leader, keep> for having all keeps reached as quickly as possible.<br />
It can be also useful to create a ''new class'' for having this couple in memory. If so, we aren't obliged to recalculate each path a second time. But we must calculate the state of keeps each time. I explain:<br />
Each turn, the enemy can put one of his leader on a keep the AI was watching. In this case, the leader must go back and find an other keep if there is any.<br />
<br />
In this case, we have<br />
* two recruitment list<br />
<br />
=== Support per-leader recruit/recall list ===<br />
<br />
In the case we can found different leader with different limitation, we need to create, I think, a specific class for them which will inherit the <code>unit</code> class.<br />
In fact, Leader are very special unit: they are the only one which can recruit and they will be the only one which will have a sort of limitation.<br />
<br />
Of course, we can add an other attribute to the <code>unit</code> class.<br />
<br />
For saving these limitation, we can use a mapping <unit, number> which will associate a unit to his limitation. If two leader have the same limitation, they will share the same mapping. Otherwise, they will have their own. The principle is to decrease the number associate to a specific unit when we recruit it. If one dies, the number is increased.<br />
With this method, the AI knows automatically which unit he can recruit.<br />
<br />
=== Recruitment strategie ===<br />
<br />
==== MinMax ====<br />
In order to make an effective counter-recruiting, an idea will to implement an 2-depth minmax algorithm.<br />
<br />
In order to make it, AI needs to cheat a little (all AI cheat... no?) in order to know what the player can recruit.<br />
<br />
This algorithm works very well, but has some negative points:<br />
* he can be a little slow... but it will be ok for a 2-depth algorithm.<br />
* depends on the formula. If the formula is precise, the algorithm will have better result.<br />
<br />
For the formula, according to my experience (I implemented it last year), it's the game experience which will give it. In fact, it can be precise if we don't play. The main question we need to answer is ''When I am in a good situation or in a bad situation?''.<br />
<br />
If it works well, it can also solve few problem of recruitment:<br />
* Knowing how much unit type recruit according to a situation<br />
* Not spend all gold for nothing<br />
* Not overestimating the value of high-level recruits<br />
* Recruit more suitable unit for the terrain<br />
<br />
===== Formula =====<br />
In order to choose the recruitment list, we need to know a few things:<br />
* '''enemy's unit type''': AI must privileged the correct unit type in order to strike back. If we can find a type that can counter several enemy's unit, it will be better to privileged it.<br />
* '''number of specific enemy unit type''' and '''number of enemy unit which can counter the AI specific unit''': in order to know how much unit AI must recruit, we must calculate a good number of unit which are enough to attack the enemy but also cover some killed unit.<br />
* '''number of unit we already have''': for a specific unit, and in order to have a good mix of unit, we need to know how much unit of a specific type we have for knowing if we can, or not, recruit an other one.<br />
* '''knowing the terrain''': some unit are better on some specific terrain. We can look at the map and calculate the most used terrain between two keeps (Ai's and enemy's).<br />
* '''the level of enemy's unit''': in fact, if we have a 3 level enemy unit, one 1 level unit isn't enough to face it. So the level is an important point to considerate.<br />
<br />
==== Working on different recruitment list ====<br />
To create a good recruitment list for each leader, the minmax algorithm will work on one list. This one will contain unit recruited by both of the leader.<br />
In order to do that, we must know the '''number of possible recruitment''' for each leader. The sum of all these number will the maximum list length.<br />
<br />
* In the case of ''same type leader'', we need to determine which leader will recruit the chosen unit. For that, we can look at proximity with the enemy unit (and there type) for example.<br />
* In the case of ''different types leader'', we need to take care of the limitation of each leader in order to not recruit more unit than possible.<br />
<br />
When everything is alright concerning the '''general''' recruitment list, we can separate it into two part and attribute them to their leader.<br />
<br />
= Practical considerations =<br />
<br />
When using a PPO language, I like using an application like Eclipse. It's very usefull and I can be faster with it. Otherwise, I simply use vim in a shell.<br />
I really like PPO language like JAVA. JAVA is obviously the language I have more experience with.<br />
Moreover, I coded in c, c++, python, prolog and I think it's all.<br />
<br />
* Subversion - I have my own svn.<br />
* C++ - I developed in c++ some years ago but I will remember since the start of GSoC<br />
* STL, Boost, Sdl - never used.<br />
* Python - I know it, used some times.<br />
* build environments - I know cmake but not scons<br />
* WML - no :(<br />
* Lua - neither.</div>Ejlshttps://wiki.wesnoth.org/index.php?title=SoC2012_Valectar&diff=46231SoC2012 Valectar2012-04-06T14:23:49Z<p>Ejls: Transfer to the good category</p>
<hr />
<div>{{SoC2012Student}}<br />
[[Category:SoC Ideas Multiplayer Engine Refactoring 2012]]<br />
<br />
=Description=<br />
<h4>Nicholas Colclasure - Improve wesnoth's engine to allow better transitions between scenarios </h4><br />
I will clean up the code which dictates scenario transition and alter it to allow for more sophisticated transitions.<br />
<br />
=IRC=<br />
Valectar<br />
=SoC Application=<br />
Submitted to google<br />
<br />
=Questionnaire=<br />
<br />
<br />
1) Basics<br />
<br />
1.1) Write a small introduction to yourself.<br />
<br />
I'm Nicholas Colclasure, a senior in high school learning programming.<br />
<br />
1.2) State your preferred email address.<br />
<br />
I'll put this in the GSoC app.<br />
<br />
1.3) If you have chosen a nick for IRC and Wesnoth forums, what is it?<br />
<br />
Valectar<br />
<br />
1.4) Why do you want to participate in summer of code?<br />
<br />
I would like to get some experience with coding projects and working with others.<br />
<br />
1.5) What are you studying, subject, level and school?<br />
<br />
I'm in high school, but I plan to study Computer Science when I get to college.<br />
<br />
1.6) What country are you from, at what time are you most likely to be able to join IRC?<br />
<br />
I'm from the USA, and I'll most likely be able to get on IRC from 10:00 to 17:00 PST<br />
<br />
1.7) Do you have other commitments for the summer period ? Do you plan to take any vacations ? If yes, when.<br />
<br />
As of yet, I have no vacation plans or other committments which could interfere with my work.<br />
<br />
2) Experience<br />
<br />
<br />
<br />
2.1) What programs/software have you worked on before?<br />
<br />
I've made some relativley small programs in C, and Objective-C, and completed an intermediate Python course which involved some small programs.<br />
<br />
2.2) Have you developed software in a team environment before? (As opposed to hacking on something on your own)<br />
<br />
I have not.<br />
<br />
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?<br />
<br />
I have not participated in Google Summer of Code previously.<br />
<br />
2.4) Are you already involved with any open source development projects? If yes, please describe the project and the scope of your involvement.<br />
<br />
No<br />
<br />
2.5) Gaming experience - Are you a gamer?<br />
<br />
2.5.1) What type of gamer are you?<br />
<br />
I game in my free time, and I enjoy challenging myself.<br />
<br />
2.5.2) What type of games?<br />
<br />
I play a variety of genres, including RTS, FPS, platformers, and some SHMUPs.<br />
<br />
2.5.3) What type of opponents do you prefer?<br />
<br />
I enjoy a challenge in games I play.<br />
<br />
2.5.4) Are you more interested in story or gameplay?<br />
<br />
I mostly look for gameplay.<br />
<br />
2.5.5) Have you played Wesnoth? If so, tell us roughly for how long and whether you lean towards single player or multiplayer.<br />
<br />
I've played it a couple of times but I haven't really gotten a chance to play through it yet. I've played mostly single player thus far, but after I complete some campaigns I'll likely move on to multiplayer.<br />
<br />
<br />
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.<br />
<br />
3) Communication skills<br />
<br />
<br />
<br />
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.<br />
<br />
English is my first language, and so I am quite fluent.<br />
<br />
3.2) What spoken languages are you fluent in?<br />
<br />
English.<br />
<br />
<br />
3.3) Are you good at interacting with other players? Our developer community is friendly, but the player community can be a bit rough.<br />
<br />
I'm relatively good at keeping a cool head and taking other's perspectives.<br />
<br />
3.4) Do you give constructive advice?<br />
<br />
Yes<br />
<br />
3.5) Do you receive advice well?<br />
<br />
I'm pretty good at taking advice and acting on it.<br />
<br />
3.6) Are you good at sorting useful criticisms from useless ones?<br />
<br />
Yes, it's quite clear to me when a criticism is useful.<br />
<br />
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<br />
<br />
I haven't done much group development in the past, but I would say that I am relatively autonomous in what development I have done. I am fine with working on a problem as I work out what I want to do, as I find it can help my planning.<br />
<br />
4) Project<br />
<br />
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?<br />
<br />
I selected the "Improve wesnoth's engine to allow better transitions between scenarios" project, and I will focus on cleaning up the code.<br />
<br />
4.2) If you have invented your own project, please describe the project and the scope.<br />
<br />
4.3) Why did you choose this project?<br />
<br />
I chose this because it seemed like a good starting place, and it should allow me get a feel for the codebase without tackling too much for me to handle.<br />
<br />
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".<br />
<br />
I will be in school for the first few days of the coding period, until June 2nd, and so won't be able to start working on the project until then. Other than that, I have no other summer plans.<br />
<br />
Before the beginning of the coding time, I'll use what free time I have to familiarize myself with the codebase and get more of an idea of what exactly I will need to change. During the first month, I will work on rewriting the code so that proper practices are adhered to and make sure the code is consistent and clean, making sure to take in to account the future updates to transitions and make those as easy as possible. Next, probably late June/early July, I will work on adding the requested features, such as the ability to change recall lists or difficulty between scenarios. During this stage I will see wether reverse compatibility is feasible, and if so code with that in mind. Then, late July to early August I will make sure reverse compatibility is sound if possible, or work on save conversion if not possible. If the format is too drastically different, I will just work on stabilizing the new version.<br />
<br />
<br />
4.5) Include as much technical detail about your implementation as you can<br />
<br />
I plan to mostly re-implement most of the code, given the reported messy state of it currently. I will to my best to ensure that the transition code is as modular as possible, and properly isolated from the rest of the code, to hopefully ensure that further changes to scenario transition code will be quickly and easily implemented.<br />
<br />
4.6) What do you expect to gain from this project?<br />
<br />
I hope to gain experience working with a large group of people on a project. I also hope to get a foot into the open source community, and hopefully some long lasting connections.<br />
<br />
4.7) What would make you stay in the Wesnoth community after the conclusion of SOC?<br />
<br />
I would love to stay and work more with the community if I find that I can be useful to it. <br />
<br />
<br />
<br />
5) Practical considerations<br />
<br />
<br />
<br />
5.1) Are you familiar with any of the following tools or languages?<br />
<br />
* Subversion (used for all commits)<br />
Not much experience.<br />
<br />
* C++ (language used for all the normal source code)<br />
I've read some, and know C, but haven't written any.<br />
<br />
* STL, Boost, Sdl (C++ libraries used by Wesnoth)<br />
None<br />
<br />
* Python (optional, mainly used for tools)<br />
Yes, I've taken classes and done a number of small, mostly toy projects.<br />
<br />
* build environments (eg cmake/scons)\<br />
Have not used these.<br />
<br />
* WML (the wesnoth specific scenario language)<br />
Haven't tried it out yet.<br />
<br />
* Lua (used in combination with WML to create scenarios)<br />
I've read some about Lua, but haven't had much of a chance to use it yet.<br />
<br />
<br />
5.2) Which tools do you normally use for development? Why do you use them?<br />
I typically use Xcode for Objective-C and C development, as that is the standard environment on OS X. For python, and other languages I have toyed with, Textmate.<br />
<br />
<br />
5.3) What programming languages are you fluent in?<br />
Python, C, Objective C.<br />
<br />
<br />
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!<br />
<br />
I will include my number in my GSoC application, and would be fine talking over telephone with my mentor.<br />
<br />
In general, students should be as verbose as possible in their answers and feel free to elaborate.</div>Ejlshttps://wiki.wesnoth.org/index.php?title=Soc2012_Talbot_Pierre_Refactor_Recruitment_Algorithm&diff=46223Soc2012 Talbot Pierre Refactor Recruitment Algorithm2012-04-06T14:08:19Z<p>Ejls: Transfer to the good category</p>
<hr />
<div>{{SoC2012Student}}<br />
[[Category:SoC_Ideas_AI_Recruitment_2012]]<br />
<br />
/!\ In construction.<br />
<br />
=Description=<br />
<h4>Talbot Pierre - Refactor Recruitment Algorithm</h4><br />
<br />
The current recruitment algorithm is based on a WML recruitment pattern that says which units AI can recruit. Apart for scout, no real strategy is established because most of the units are chosen randomly from this pattern list.<br />
<br />
The units must be chosen for a specific purpose such as getting a village, fighting a specific units, protecting another... AI should be able to keep in mind the original purpose of an unit to take further decisions.<br />
<br />
The recruitment pattern will be improved to allow scenario designer to be more specific on which units should be recruited and a ratio of recruitment. For example: "unit1 4 unit2 3 unit3 3" means for 10 units recruited 4 will be unit1, 3 unit2 and 3 unit3.<br />
<br />
AI should choose where an unit (on which castle) should be recruited to be more efficient, taking into account the number of enemy units and their weaknesses.<br />
<br />
We must manage list of leaders and free keeps, to affect each leader to a keep and change if needed.<br />
<br />
=IRC=<br />
trademark<br />
<br />
=Questionnaire=<br />
===1) Basics===<br />
<br />
====1.1) Write a small introduction to yourself.====<br />
<br />
My name is Pierre Talbot, I'm 20 year old. I didn't discovered the programming when I was young, such we often see. Before I dive into this beautiful world I played a lot. I made the most important step in my life 3 years ago when I began my studies.<br />
<br />
====1.2) State your preferred email address.====<br />
<br />
ptalbot [at] mopong (dot) net<br />
<br />
====1.3) If you have chosen a nick for IRC and Wesnoth forums, what is it?====<br />
<br />
trademark<br />
<br />
====1.4) Why do you want to participate in summer of code?====<br />
<br />
It's for two main reasons, the first is the money. The second is to move forward my dream to become<br />
a game programmer specialised in artificial intelligence.<br />
It's also to meet new people and to discuss around a common passion. It would be the first time I code<br />
for a project of this size, I think it's a necessary step to go beyond the programmer amateur and be ready for the real world.<br />
<br />
====1.5) What are you studying, subject, level and school?====<br />
<br />
I'm finishing this year my B.Sc. in Computer Science at the University of Claude Bernard Lyon 1.<br />
<br />
====1.6) What country are you from, at what time are you most likely to be able to join IRC?====<br />
<br />
I'm from France, so I'll be able to join IRC between 3 am UTC and 6 pm UTC. I'll be the most responsive during in the morning.<br />
<br />
====1.7) Do you have other commitments for the summer period ? Do you plan to take any vacations ? If yes, when.====<br />
<br />
I have an internship during the summer, from may to august. I discussed about it with Crab_ on IRC, I asked him if it was feasible and he helps me to do a long term planning. <br />
<br />
I'll get up early, around 4-5 am UTC+2 and I will work for Wesnoth until 9 am UTC+2. Without any distraction and with my fresh and rested head. My internship will begin at 10 am UTC+2 and finish at 6 pm UTC+2. I'll go to sleep around 8 pm UTC+2.<br />
<br />
The week will be dedicated to code functionalities and the week-end will be reserved to rest myself up and to think about the code design of the next week. <br />
<br />
I'm used to work a lot and all the day, my motivation can defeat the rules of time.<br />
<br />
===2) Experience===<br />
<br />
====2.1) What programs/software have you worked on before?====<br />
<br />
I mainly developed short programs for school purpose such as a chess-game in C++, a pong and a naval battle in C, an adaptation of the well-known board game "Jungle Speed" in Java. I also code few data structures module such as Hash map, Tree, List,... but also the skip-list, Red-black tree in C. I'm used to work with graph and graph algorithm in C++.<br />
<br />
I often code short and efficient programs because I like participate in programming contest. I'm participating for the second year in Prologin, which is an algorithmic French contest. The final is a 36 hours contest where the finalists must code an artificial intelligence of a given subject. I also prepare myself for the regional ACM-ICPC contest in 2012.<br />
<br />
====2.2) Have you developed software in a team environment before? (As opposed to hacking on something on your own)====<br />
<br />
Most of the projects I spoke before were in team of 2 or 3 peoples and we used version control software.<br />
<br />
====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?====<br />
<br />
Yes, I participated as a student in 2011. It was my first real experience. I was accepted in the Boost C++ Library organisation to design and code a check digit verification and computation library oriented "human-error". For example, your credit card number or the ISBN in the back of a book have a check digit. It's not for transmission error control purpose, these checksums are designed to control the human encoding errors.<br />
<br />
I successfully finished the summer and continued to develop and work on it during the year studying permitting. My contribution to this organisation is not done yet and I will continue to prepare my library for a Boost review.<br />
<br />
I gain a lot of experience in C++ and mostly with some Boost library such as MPL, Test, Iterator, Phoenix, Preprocessor, Range, and all the others I've forgotten that made the programmer life easier. I studied these libraries to be sure to do the most generic library as I can. I also learned to use the Boost chain-tools to document and test.<br />
<br />
My mentor was Paul Bristow and we regularly keep in touch since the beginning of GSoC, feel free to contact him here : pbristow [at] hetp.u-net (dot) com.<br />
<br />
====2.4) Are you already involved with any open source development projects? If yes, please describe the project and the scope of your involvement.====<br />
<br />
No.<br />
<br />
====2.5) Gaming experience - Are you a gamer?====<br />
<br />
I was what we called a "real" gamer few years ago. I play a lot less now as my interests has slipped into the programming. Anyway I love games and this passion will never pass away.<br />
<br />
=====2.5.1) What type of gamer are you?=====<br />
<br />
I'm a gamer who hasn't played a lot of different games. I prefer plays online because I love the competition and progress with my rank.<br />
<br />
=====2.5.2) What type of games?=====<br />
<br />
* Strategy : 400 hours in Warcraft III, rank 647 in Free For All and rank 630 in Arranged team 3vs3.<br />
* CCORPG : 3600 hours in Guild Wars over 4 years. Best rank 497 in 1vs1 (PvP, mode Hero vs Hero).<br />
* FPS : Call of duty 4.<br />
* Race : 100 hours in Trackmania.<br />
<br />
There are my prefered games. Currently, when I really need a break, I like to play COD4.<br />
I also played few others games I didn't mention because I didn't play these much.<br />
<br />
=====2.5.3) What type of opponents do you prefer?=====<br />
<br />
In my good days, I like the opponent who defeats me, so I can learn from my losses and improved my technical skills.<br />
<br />
In my bad days, I don't like to lose and I just want to win. Contradictorily, I don't win a lot these days.<br />
<br />
=====2.5.4) Are you more interested in story or gameplay?=====<br />
<br />
When I don't play online, I think the story is important and I like to enjoy the mainline story.<br />
''A contrario'', when I play online, I prefer a balance gameplay which allow you to create new strategy.<br />
<br />
=====2.5.5) Have you played Wesnoth? If so, tell us roughly for how long and whether you lean towards single player or multiplayer.=====<br />
<br />
I started the campaign and I finished few scenarios. I played about 5 hours. I also played online in a custom game. I'm not good enough to play online as I don't know the units and the strategy used (I've started to watch game replay of experienced gamers).<br />
<br />
====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.====<br />
<br />
A bug: [https://gna.org/bugs/?19538 Bug #19538].<br />
<br />
While I read the code I improve a function and did a patch: [https://gna.org/patch/?3236 Patch #3236].<br />
<br />
===3) Communication skills===<br />
<br />
====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.====<br />
<br />
I only write my program in English (even if there are unimportant) and I document them in English as well. I haven't problem to discuss in English.<br />
<br />
====3.2) What spoken languages are you fluent in?====<br />
<br />
French.<br />
<br />
====3.3) Are you good at interacting with other players? Our developer community is friendly, but the player community can be a bit rough.====<br />
<br />
I know how the gamers can be, and mostly when they are experimented. I'll try to do my best to be, as soon as possible, an experienced gamer. I treated guys of noob and be treated as well, I've been on the both side so I know what is good to say or not.<br />
<br />
====3.4) Do you give constructive advice?====<br />
<br />
I'm member of a French forum "Developpez.com" where I give advices and help people. I'm not always good but I try to respond with precision and completeness, I want to show them all the possible tracks I know.<br />
<br />
====3.5) Do you receive advice well?====<br />
<br />
I have difficulties to receive advices from guys of the same level as me, I'm reluctant to follow their ideas if I don't see what's the aimed or the improvement. <br />
<br />
From my mentor or an experienced coder, I follow the ideas more easily because I trust them. Anyway, whatever the advices is it, I try to keep my critical. For example, I change my coding style the last year for Boost, I indent with 2-spaces instead of a tab now.<br />
<br />
====3.6) Are you good at sorting useful criticisms from useless ones?====<br />
<br />
I think so, because, as explain above, I only fully consider criticisms I understand well.<br />
<br />
====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====<br />
<br />
I like to lay down on paper my ideas to be clear. If I'm really not sure about something, I'll ask for help on IRC, forum,... Otherwise, I code it. I have difficulties to thrown away my code, but I have the feeling that is a better way to take a decision. It's a debate in my head and I'll try to code sooner to "see how it turn out".<br />
<br />
===4) Project===<br />
<br />
====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?====<br />
<br />
====4.2) If you have invented your own project, please describe the project and the scope.====<br />
<br />
====4.3) Why did you choose this project?====<br />
<br />
I choose this project because I think that programming AI is like a playground to implement all the theory we want, such as the graph theory.<br />
<br />
====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".====<br />
<br />
====4.5) Include as much technical detail about your implementation as you can====<br />
<br />
====4.6) What do you expect to gain from this project?====<br />
<br />
====4.7) What would make you stay in the Wesnoth community after the conclusion of SOC?====<br />
<br />
<br />
===5) Practical considerations===<br />
<br />
====5.1) Are you familiar with any of the following tools or languages?====<br />
<br />
* Subversion: Yes, I used it during my previous GSoC. For my personal projects, I'm using git.<br />
* C++: My level is correct, I can easily debug and understand the concept and features of this language.<br />
* STL, Boost, Sdl: I know a large part of the STL and some libraries from Boost (MPL, Phoenix, Range,...). I used very few the SDL during a C project.<br />
* Python (optional, mainly used for tools): I wrote one project with it: a SAT solver.<br />
* build environments (eg cmake/scons): I recently used these to compile Wesnoth, but I need to learn deeply how they work (add file,...).<br />
* WML (the wesnoth specific scenario language): I read the manual and some files' campaign.<br />
* Lua (used in combination with WML to create scenarios): No.<br />
<br />
====5.2) Which tools do you normally use for development? Why do you use them?====<br />
<br />
I'm using VIM and g++, because they are open-source, light and everything is in the terminal, so I rarely quit my keyboard to use the mouse. I'm using git because there are local commit and branches.<br />
<br />
However I also programmed under Visual Studio the last year.<br />
<br />
====5.3) What programming languages are you fluent in?====<br />
<br />
C++ mostly but also C and Java.<br />
<br />
====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!====<br />
<br />
I'll let you my number in the official form but I'm not very confident in my comprehension and speaking. However, if you speak clearly, it should be alright.<br />
<br />
=Proposal=<br />
<br />
There are few points to refactor. I try to explain these with an incremental approach, for a specific point, there is few steps and they can't be jump. This is useful to code & test and directly spot the potential bugs.<br />
<br />
The class <tt>recruitment_phase</tt> and <tt>aspect_recruitment_phase</tt> are the main classes related to this proposal. But the entire file ai/testing/ca.* and the directory ai/testing/* will be usefull as well. Of course, we are not limited to these files.<br />
<br />
===Recruiting with multiple leaders===<br />
<br />
'''Current implementation'''<br />
<br />
During the evaluation phase, BAD_SCORE is returned if the first leader is not on keep, if the castle is full or if there is no leader available.<br />
During the execution phase, only one location is considered.<br />
<br />
'''Goal'''<br />
<br />
AI should consider multiple leaders and use a list of leaders which are on a keep.<br />
<br />
If the leaders are not on keep, we must choose a castle not too far and not too close from the battle for each leaders. Anyway, if it's not possible we choose the furthest keep from the battle and we don't move a leader to the closest.<br />
<br />
'''Implementation'''<br />
<br />
The function <tt>find_leader'''s'''</tt> will help us to achieve this goal. We'll need to modify <tt>recruitment_phase::evaluate()</tt> and when counting neutral village (for the scout), consider all the keeps. The scouts will distributed on all the keeps which have neutral villages around.<br />
<br />
<tt>std::vector<std::pair<unit_iterator, map_location> > get_neutral_village(std::vector<unit_iterator> &leaders);</tt><br />
<br />
Returns: The different location of neutral village per leaders. Every map_location is unique.<br />
<br />
<tt>analyze_potential_recruit_combat</tt> should be leader specific.<br />
<br />
===Easy limiting of recruitable units===<br />
<br />
The scenario editors would like to control more easily the recruitment phase. WML markup can be implement and the recruitment pattern modify. A ratio could be use to specified the maximum units we want on the ground, or the minimum. More specific markup could be added to be accurate on when and what units should be recruited.<br />
<br />
===Analyse map terrain to recruit more useful units===<br />
<br />
As I said before, most of the units are chosen randomly. An analyse of which enemy units are on the map and which enemy units are recruitable should help us to choose better units. The criteria of an analysed unit should be the distance, how much of the same kind, the cost, and the threaten (if a enemy is close from our leader).<br />
Each units should have a goal, for example, getting a village, kill a specific category of units, block others (these ideas join other proposals so we'll need to work together on these parts).<br />
<br />
===Improve counter-recruiting strategies===<br />
<br />
===Random units===<br />
<br />
A good part of the AI is to choose random units when it doesn't know what to do. We should improve it to recruit the best units against the closest enemies and against the most numerous units. Another criteria should be the units that threaten the leaders.</div>Ejlshttps://wiki.wesnoth.org/index.php?title=User:Ejls/GSoC_2012/Whiteboard_Backend_Refactoring&diff=46178User:Ejls/GSoC 2012/Whiteboard Backend Refactoring2012-04-05T23:39:07Z<p>Ejls: update</p>
<hr />
<div><!--<br />
Excuse the heavy wikitext, I tried to make it as readable as possible and I put a lot of comments.<br />
-->__NOTOC__<!--<br />
-->__NOEDITSECTION__<!--<br />
-->{{SoC2012Student}}<!--<br />
-->[[Category:SoC_Ideas_Whiteboard_Backend_Refactoring_2012]]<!--<br />
-->'''''Note: This proposal is in continuous construction, if you have any remark, please drop me a line on IRC or on the [[{{TALKPAGENAME}}|talk page]].'''''<br /><br /><br />
<br />
<!--***********************************************************************<br />
* * Table of Content * *<br />
* ******************** *<br />
* *<br />
* WARNING: don't forget to add a TOC entry when adding a new section. *<br />
***********************************************************************--><br />
{|style="background:#FAF3E9;margin:none;padding:5px;border:3px double #AAA;-moz-border-radius:20px 5px 20px 5px;-webkit-border-radius:20px 5px 20px 5px;border-radius:20px 5px 20px 5px;"<br />
|-<br />
| style="text-align: center; padding: 0px 10px 5px 10px;"|'''Content'''<hr /><br />
|-<br />
| style="text-align: left; padding:0px 10px 10px 10px;"|<br />
[[#Description|Description]]<br /><br />
[[#SoC Application|SoC Application]]<br /><br />
[[#Contact|Contact]]<br /><br />
[[#Questionnaire|Questionnaire]]<br /><br />
:[[#1) Basics|1 - Basics]]<br /><br />
:[[#2) Experience|2 - Experience]]<br /><br />
:[[#3) Communication skills|3 - Communication skills]]<br /><br />
:[[#4) Project|4 - Project]]<br /><br />
:[[#5) Practical considerations|5 - Practical considerations]]<br /><br />
[[#Proposal|Proposal]]<br /><br />
:[[#The problems|The problems]]<br /><br />
:[[#side_actions|<tt>side_actions</tt> refactoring]]<br /><br />
::[[#side_actions.situation|The current situation]]<br /><br />
::[[#side_actions.idea|The idea]]<br /><br />
::[[#side_actions.implementation|Implementation details]]<br /><br />
:::[[#side_actions.containers|Choice of the containers]]<br /><br />
:::[[#side_actions.example|Example]]<br /><br />
:::[[#side_actions.reconsideration|Reconsideration of Boost.MultiIndex]]<br /><br />
:[[#visitorhier|Visitor hierarchy refactoring]]<br /><br />
::[[#visitorhier.situation|The current situation]]<br /><br />
::[[#visitorhier.idea|The idea]]<br /><br />
::[[#visitorhier.implementation|Implementation details]]<br /><br />
:::[[#visitorhier.example|Example]]<br /><br />
:[[#actioncore|Transfer of the action and validation logic into the core]]<br /><br />
::[[#actioncore.situation|The current situation]]<br /><br />
::[[#actioncore.idea|The idea]]<br /><br />
::[[#actioncore.implementation|Implementation details]]<br /><br />
:::[[#actioncore.whiteboard|Changes in the Whiteboard]]<br /><br />
:::[[#actioncore.example|Example]]<br /><br />
:[[#polishing|Polishing]]<br /><br />
:[[#designdoc|Design document]]<br /><br />
:[[#Openings|Openings]]<br /><br />
:[[#Timeline|Timeline]]<br /><br />
|}<br />
<br />
<!--***********************************************************************<br />
* * Description * *<br />
* *************** *<br />
* *<br />
* This section is inserted in the SummerOfCodeIdeas page. It contains *<br />
* only a header of level 4 and a small paragraph summing up the *<br />
* proposal. *<br />
***********************************************************************--><br />
==Description==<br />
====Étienne Simon - Whiteboard backend polishing====<br />
My project is to make the Whiteboard code cleaner and to redesign small parts of it to speed it up. The global design of the Whiteboard won't be changed a lot, each part will be reviewed individually. I'm not only planning to improve the Whiteboard backend, but also to document the overall design and each part of it as well as to write a wide variety of test to improve its stability. Moreover, I'll factorise action handling outside of the Whiteboard so that the same code will be usable in all Wesnoth.<!--<br />
--><br />
<!--***********************************************************************<br />
* * SoC Application * *<br />
* ******************* *<br />
* *<br />
* This section affect the SummerOfCodeIdeas page, if it contains the *<br />
* text "Submitted to google", the application will appear in the *<br />
* "Student proposals submitted both to wiki and google" section, *<br />
* otherwise it'll appear in the "Student proposals not submitted to *<br />
* google" section. *<br />
***********************************************************************--><br />
==SoC Application==<br />
Submitted to google<!--<br />
--><br />
<!--***********************************************************************<br />
* * Contact * *<br />
* *********** *<br />
* *<br />
* The IRC subsection is inserted in the SummerOfCodeIdeas page. It *<br />
* must only contain the IRC nick identifying the author. *<br />
***********************************************************************--><br />
==Contact==<br />
{|<br />
|-<br />
|<br />
=====IRC=====<br />
<span style="color:#3F475E;">ejls </span><br />
=====Email=====<br />
Address at gmail dot com: etienne.jl.simon<br />
| style="width:10em;" |<br />
|<br />
=====Forum=====<br />
ejls<br />
=====Gna=====<br />
ejls<br />
|}<br />
<br />
<!--***********************************************************************<br />
* * Questionnaire * *<br />
* ***************** *<br />
* *<br />
* Although I'm submitting only one application (and so only one *<br />
* questionnaire), I thought it was more elegant to make the *<br />
* questionnaire page reusable. Which explain why it's a template. *<br />
* Like I wrote in the Questionnaire subpage, the argument to this *<br />
* template are the answer to the proposal-specific questions. I order *<br />
* to make the sources more comprehensible, I wrote the corresponding *<br />
* question in comments at the beginning of each parameter. *<br />
***********************************************************************--><br />
{{User:Ejls/GSoC 2012/Questionnaire<br />
|<!-- 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? --><br />
''This is a summary, more details can be found [http://wiki.wesnoth.org/User:Ejls/GSoC%202012/Whiteboard%20Backend%20Refactoring#Proposal here].''<br />
<br />
I originally chose [[SoC Ideas Whiteboard Backend Refactoring 2012]], however it evolved a lot thanks to gabba and Crab. This project is the only one not adding any feature for the user, the main goal is to refactor code, write test and documentation. It follows [http://wiki.wesnoth.org/GSoC-WesnothWhiteboard_Gabba gabba's project] and [http://wiki.wesnoth.org/User:Tschmitz tschmitz's project] on the Whiteboard. Although it doesn't add any feature for the user in itself, I hope it'll help future development of the Whiteboard.<!--<br />
-->|<!-- 4.2) If you have invented your own project, please describe the project and the scope. --><br />
I chose a project from the list, namely [[SoC Ideas Whiteboard Backend Refactoring 2012]]. C.f. above answer.<!--<br />
-->|<!-- 4.3) Why did you choose this project? --><br />
I liked the idea behind the Whiteboard, I think it might be a big plus to Wesnoth. Furthermore, I liked how C++ is used in its code (especially the heavy use of SBRM). However it looks like the Whiteboard is not widely used, and I would like to help changing that! :)<!--<br />
-->|<!-- 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". --><br />
''This is a summary, more details can be found [http://wiki.wesnoth.org/User:Ejls/GSoC%202012/Whiteboard%20Backend%20Refactoring#Timeline here].''<br />
<br />
I separated my summer in five phases:<br />
*Phase 0: Approach (4 weeks)<br />
::→ Start working on the design document. Start the ''polishing''.<br />
*Phase 1: <tt>side_actions</tt> refactoring (3 weeks)<br />
*Phase 2: Validator hierarchy refactoring (3 weeks)<br />
*Phase 3: Transfer of the action and validation logic into the core (3 weeks)<br />
*Phase 4: Finalisation (3 weeks)<br />
::→ Finish the design document. Finish the ''polishing''. Test. Test. Test.<!--<br />
-->|<!-- 4.5) Include as much technical detail about your implementation as you can --><br />
''This is a summary, more details can be found [http://wiki.wesnoth.org/User:Ejls/GSoC%202012/Whiteboard%20Backend%20Refactoring#Proposal here].''<br />
<br />
I separated my project in five tasks:<br />
;<tt>side_actions</tt> refactoring<br />
:Change of the underlying container, creation of new look up functions.<br />
;Visitor hierarchy refactoring<br />
:Replacement of the <tt>enable_visit_all</tt> by a new interface over all of the <tt>side_actions</tt> objects.<br />
;Transfer of the action and validation logic into the core<br />
:Refactoring of <tt>wb::action</tt> in a Whiteboard-independent hierarchy.<br />
;Polishing<br />
:Code uniformisation, small improvements.<br />
;Design document<br />
:Documentation of the global Whiteboard design.<!--<br />
-->|<!-- 4.6) What do you expect to gain from this project? --><br />
I hope it'll help me to join the open source developer community. Actually, the preparation of this proposal already helped me a lot, for example my first patch got committed, it wasn't a big patch, but it was my first step of a (I hope) long path. :) So, I hope to continue learning to walk with the wesnoth community (sorry for the silly metaphor.)<!--<br />
-->|<!-- 4.7) What would make you stay in the Wesnoth community after the conclusion of SOC? --><br />
If my work is appreciated, I would rather ask: what would make me leave the Wesnoth community?.<!--<br />
-->}}<br />
<br />
<!--***********************************************************************<br />
* * Proposal * *<br />
* ************ *<br />
* *<br />
* Finally, my proposal. ;) *<br />
***********************************************************************--><br />
==Proposal==<br />
===The problems===<br />
In the [[SoC_Ideas_Whiteboard_Backend_Refactoring_2012|Whiteboard Backend Refactoring idea page]], several problems are listed, here is how I'm planning to fix them:<br />
{| style="border:1px dashed #AAA;border-collapse:collapse;"<br />
|-<br />
!style="border:1px dotted #AAA;padding:5px;"|Problem<br />
!style="border:1px dotted #AAA;padding:5px;"|Solution<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|<tt>side_actions</tt> complexity<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#side_actions|<tt>side_actions</tt> refactoring]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|Redundancy between <tt>mapbuilder</tt> and <tt>validate_visitor</tt><br />
|style="border:1px dotted #AAA;padding:5px;"|[[#visitorhier|Visitor hierarchy refactoring]], [[#actioncore|Transfer of the action and validation logic into the core]] and [[#Polishing|Polishing]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|Highlighter slowness<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#side_actions|<tt>side_actions</tt> refactoring]] and [[#visitorhier|Visitor hierarchy refactoring]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|Action handling decentralization<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#actioncore|Transfer of the action and validation logic into the core]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|Friend classes vs everything in the action classes<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#visitorhier|Visitor hierarchy refactoring]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|Unit pointer recovery uniformisation<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#polishing|Polishing]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|<tt>boost::dynamic_pointer_cast</tt> vs simple numeric id<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#polishing|Polishing]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|Documentation<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#designdoc|Design document]]<br />
|}<br />
<br />
===<span id="side_actions"><tt>side_actions</tt> refactoring</span>===<br />
====<span id="side_actions.situation">The current situation</span>====<br />
The current implementation of <tt>side_actions</tt> use a <tt>std::deque&lt;std::deque&lt;action_ptr&gt;&gt;</tt>.<br />
In order to use it, iterators have been defined over it (<tt>side_actions::iterator</tt> and the three const and reverse variants).<br />
These “flattening” iterators let users of <tt>side_actions</tt> iterate over all the planned actions, they are performing the ''zip'' operation on the fly.<br />
<br />
Furthermore, some queries like <tt>side_actions::find_first_action_of</tt> are linear in the number of action.<br />
<br />
====<span id="side_actions.idea">The idea</span>====<br />
To simplify the code, I propose to keep the action set zipped. The container's iterators will then be usable directly. In order to delimit turns, a second container will have to keep a sequence of iterators pointing to the first action of each turn.<br />
<br />
For example, let's say eight actions are planned: five for this turn, two for the next turn and one for the turn after. Three iterators will be kept to delimit turns. Here is a proof that I can't use gimp which also show the idea:<br />
http://epsilon012.free.fr/GSoC%202012/side_actions%20idea.png<br />
<br />
Of course another problem emerge: the sequence of iterator has to be kept in sync with the sequence of action.<br />
<br />
Finally, the current implementation gives access to the <tt>action_ptr</tt> only in sequence, in order to speed up different way of querying action (e.g. by hex, by unit's id), I propose to build several indexes on the action set.<br />
<br />
====<span id="side_actions.implementation">Implementation details</span>====<br />
Let's name these containers <tt>actions_</tt> and <tt>turn_beginnings_</tt>.<br />
<br />
The Whiteboard have the following invariant: an empty turn (a turn without planned action) can't be followed by a non-empty turn (with at least one planned action). It means that <code>distance(turn_beginnings_[i], turn_beginnings_[i+1])&gt;0</code>, and so we can unambiguously determine the turn number of each action.<br />
<br />
Also, note that except when <tt>actions_.empty()</tt> : <tt>turn_beginnings_.front()==actions_.begin()</tt>.<br />
<br />
=====<span id="side_actions.containers">Choice of the containers</span>=====<br />
<tt>std::deque</tt> seems to be the perfect container for <tt>turn_beginnings_</tt>. It'll allow random access and we need to add/remove new turns only at the extremities.<br />
<br />
On the other hand, <tt>actions_</tt> need three proprieties:<br />
*Allow fast chronological iteration<br />
*Stable iterators<br />
*Allow fast lookup on different indexes<br />
I propose to use a <tt>boost::multi_index_container</tt>, this container is part of the library [http://www.boost.org/doc/libs/1_49_0/libs/multi_index Boost.MultiIndex] which is in Boost since version 1.32. It allows the construction of several indexes on the same set of object.<br />
<br />
There is however one problem linked to the use of the <tt>boost::multi_index::random_access</tt> index: insertion and deletion are in linear time when their are not done at the extremities.<br />
<br />
So, the new members should be:<br />
<!-- Original:<br />
namespace bmi = boost::multi_index;<br />
typedef bmi::multi_index_container<<br />
action_ptr,<br />
bmi::indexed_by<<br />
bmi::random_access<bmi::tag<chronological> >,<br />
bmi::hashed_non_unique<bmi::tag<by_unit>, bmi::const_mem_fun<action,size_t,&action::get_unit_id> >,<br />
bmi::hashed_non_unique<bmi::tag<by_hex>, bmi::const_mem_fun<action,map_location,&action::get_hex> ><br />
><br />
> action_set;<br />
typedef action_set::iterator iterator;<br />
<br />
action_set actions_;<br />
std::deque<iterator> turn_beginnings_;<br />
Formated: --><code><div style="border: 1px dashed #AAA;background:#FAF3E9;padding:7px;"><span style="color:#000000; font-weight:bold">namespace</span> bmi <span style="color:#000000">=</span> boost<span style="color:#000000">::</span>multi_index<span style="color:#000000">;</span><br /><span style="color:#000000; font-weight:bold">typedef</span> bmi<span style="color:#000000">::</span>multi_index_container<span style="color:#000000">&lt;</span><br />&nbsp; &nbsp; action_ptr<span style="color:#000000">,</span><br />&nbsp; &nbsp; bmi<span style="color:#000000">::</span>indexed_by<span style="color:#000000">&lt;</span><br />&nbsp; &nbsp; &nbsp; &nbsp; bmi<span style="color:#000000">::</span>random_access<span style="color:#000000">&lt;</span>bmi<span style="color:#000000">::</span>tag<span style="color:#000000">&lt;</span>chronological<span style="color:#000000">&gt; &gt;,</span><br />&nbsp; &nbsp; &nbsp; &nbsp; bmi<span style="color:#000000">::</span>hashed_non_unique<span style="color:#000000">&lt;</span>bmi<span style="color:#000000">::</span>tag<span style="color:#000000">&lt;</span>by_unit<span style="color:#000000">&gt;,</span> bmi<span style="color:#000000">::</span>const_mem_fun<span style="color:#000000">&lt;</span>action<span style="color:#000000">,</span><span style="color:#0057ae">size_t</span><span style="color:#000000">,&amp;</span>action<span style="color:#000000">::</span>get_unit_id<span style="color:#000000">&gt; &gt;,</span><br />&nbsp; &nbsp; &nbsp; &nbsp; bmi<span style="color:#000000">::</span>hashed_non_unique<span style="color:#000000">&lt;</span>bmi<span style="color:#000000">::</span>tag<span style="color:#000000">&lt;</span>by_hex<span style="color:#000000">&gt;,</span> bmi<span style="color:#000000">::</span>const_mem_fun<span style="color:#000000">&lt;</span>action<span style="color:#000000">,</span><span style="color:#000000">map_location</span><span style="color:#000000">,&amp;</span>action<span style="color:#000000">::</span>get_hex<span style="color:#000000">&gt; &gt;</span><br />&nbsp; &nbsp; &nbsp; &nbsp; <span style="color:#000000">&gt;</span><br />&nbsp; &nbsp; <span style="color:#000000">&gt;</span> action_set<span style="color:#000000">;</span><br /><span style="color:#000000; font-weight:bold">typedef</span> action_set<span style="color:#000000">::</span>iterator iterator<span style="color:#000000">;</span><br /><br />action_set actions_<span style="color:#000000">;</span><br />std<span style="color:#000000">::</span>deque<span style="color:#000000">&lt;</span>iterator<span style="color:#000000">&gt;</span> turn_beginnings_<span style="color:#000000">;</span><br /></div></code><br /><br />
<br />
This suppose two new pure virtual functions in <tt>action</tt>: <tt>get_unit_id</tt> and <tt>get_hex</tt>.<br />
<br />
Using action's attribute as key brings another drawback: we must notify the <tt>multi_index_container</tt> when we modify a key.<br />
However, the two used keys here (the unit's id and the hex) are never modified in the <tt>action</tt> hierarchy.<br />
<br />
This definition is here to give an idea, in practice other indexes will have to be built (e.g. an index on ''secondary hex'' which could be the source hex in <tt>move</tt>.)<br />
Note that this doesn't necessarily means a new pure virtual function in <tt>action</tt>, a key extractor can be defined to let <tt>action</tt> as it is and use ''RTTI'' instead (this might not be clever though.)<br />
<br />
=====<span id="side_actions.example">Example</span>=====<br />
Here are three functions rewritten with this new design. Note that <tt>side_actions::iterator</tt> is the one defined above.<br />
<br />
<!-- Original:<br />
side_actions::iterator side_actions::end_turn(size_t turn_num){<br />
if(turn_num+1 >= turn_beginnings_.size())<br />
return actions_.end();<br />
else<br />
return turn_beginnings_[turn_num+1];<br />
}<br />
Formated: --><code><div style="border: 1px dashed #AAA;background:#FAF3E9;padding:7px;">side_actions<span style="color:#000000">::</span>iterator side_actions<span style="color:#000000">::</span><span style="color:#010181">end_turn</span><span style="color:#000000">(</span><span style="color:#0057ae">size_t</span> turn_num<span style="color:#000000">){</span><br />&nbsp; &nbsp; <span style="color:#000000; font-weight:bold">if</span><span style="color:#000000">(</span>turn_num<span style="color:#000000">+</span><span style="color:#b07e00">1</span> <span style="color:#000000">&gt;=</span> turn_beginnings_<span style="color:#000000">.</span><span style="color:#010181">size</span><span style="color:#000000">())</span><br />&nbsp; &nbsp; &nbsp; &nbsp; <span style="color:#000000; font-weight:bold">return</span> actions_<span style="color:#000000">.</span><span style="color:#010181">end</span><span style="color:#000000">();</span><br />&nbsp; &nbsp; <span style="color:#000000; font-weight:bold">else</span><br />&nbsp; &nbsp; &nbsp; &nbsp; <span style="color:#000000; font-weight:bold">return</span> turn_beginnings_<span style="color:#000000">[</span>turn_num<span style="color:#000000">+</span><span style="color:#b07e00">1</span><span style="color:#000000">];</span><br /><span style="color:#000000">}</span><br /></div></code><br /><br />
<br />
<!-- Original:<br />
side_actions::iterator side_actions::raw_enqueue(size_t turn_num, action_ptr act){<br />
assert(turn_num <= turn_beginnings_.size());<br />
<br />
iterator new_action = actions_.insert(end_turn(turn_num), act).first;<br />
<br />
if(turn_num >= turn_beginnings_.size())<br />
turn_beginnings_.push_back(new_action);<br />
<br />
return new_action;<br />
}<br />
Formated: --><code><div style="border: 1px dashed #AAA;background:#FAF3E9;padding:7px;">side_actions<span style="color:#000000">::</span>iterator side_actions<span style="color:#000000">::</span><span style="color:#010181">raw_enqueue</span><span style="color:#000000">(</span><span style="color:#0057ae">size_t</span> turn_num<span style="color:#000000">,</span> action_ptr act<span style="color:#000000">){</span><br />&nbsp; &nbsp; <span style="color:#000000; font-weight:bold">assert</span><span style="color:#000000">(</span>turn_num <span style="color:#000000">&lt;=</span> turn_beginnings_<span style="color:#000000">.</span><span style="color:#010181">size</span><span style="color:#000000">());</span><br /><br />&nbsp; &nbsp; iterator new_action <span style="color:#000000">=</span> actions_<span style="color:#000000">.</span><span style="color:#010181">insert</span><span style="color:#000000">(</span><span style="color:#010181">end_turn</span><span style="color:#000000">(</span>turn_num<span style="color:#000000">),</span> act<span style="color:#000000">).</span>first<span style="color:#000000">;</span><br /><br />&nbsp; &nbsp; <span style="color:#000000; font-weight:bold">if</span><span style="color:#000000">(</span>turn_num <span style="color:#000000">&gt;=</span> turn_beginnings_<span style="color:#000000">.</span><span style="color:#010181">size</span><span style="color:#000000">())</span><br />&nbsp; &nbsp; &nbsp; &nbsp; turn_beginnings_<span style="color:#000000">.</span><span style="color:#010181">push_back</span><span style="color:#000000">(</span>new_action<span style="color:#000000">);</span><br /><br />&nbsp; &nbsp; <span style="color:#000000; font-weight:bold">return</span> new_action<span style="color:#000000">;</span><br /><span style="color:#000000">}</span><br /></div></code><br /><br />
<br />
<!-- Original:<br />
side_actions::find_first_action_of(unit const* unit, side_actions::iterator start_position){<br />
// First we get all the action of this unit<br />
typedef action_set::index<by_unit>::type::iterator unit_iterator;<br />
std::pair<unit_iterator, unit_iterator> act = actions_.get<by_unit>().equal_range(unit->underlying_id());<br />
<br />
// Then we find the first of them (chronologically) after start_position<br />
iterator first = actions_.end();<br />
for(unit_iterator it = act.first; it != act.second; ++it){<br />
iterator chrono_it = actions_.project<chronological>(it);<br />
if(chrono_it < first && chrono_it > start_position)<br />
first = chrono_it;<br />
}<br />
return first;<br />
}<br />
Formated: --><code><div style="border: 1px dashed #AAA;background:#FAF3E9;padding:7px;">side_actions<span style="color:#000000">::</span><span style="color:#010181">find_first_action_of</span><span style="color:#000000">(</span>unit <span style="color:#0057ae">const</span><span style="color:#000000">*</span> unit<span style="color:#000000">,</span> side_actions<span style="color:#000000">::</span>iterator start_position<span style="color:#000000">){</span><br />&nbsp; &nbsp; <span style="color:#838183; font-style:italic">// First we get all the action of this unit</span><br />&nbsp; &nbsp; <span style="color:#000000; font-weight:bold">typedef</span> action_set<span style="color:#000000">::</span>index<span style="color:#000000">&lt;</span>by_unit<span style="color:#000000">&gt;::</span>type<span style="color:#000000">::</span>iterator unit_iterator<span style="color:#000000">;</span><br />&nbsp; &nbsp; std<span style="color:#000000">::</span>pair<span style="color:#000000">&lt;</span>unit_iterator<span style="color:#000000">,</span> unit_iterator<span style="color:#000000">&gt;</span> act <span style="color:#000000">=</span> actions_<span style="color:#000000">.</span>get<span style="color:#000000">&lt;</span>by_unit<span style="color:#000000">&gt;().</span><span style="color:#010181">equal_range</span><span style="color:#000000">(</span>unit<span style="color:#000000">-&gt;</span><span style="color:#010181">underlying_id</span><span style="color:#000000">());</span><br /><br />&nbsp; &nbsp; <span style="color:#838183; font-style:italic">// Then we find the first of them (chronologically) after start_position</span><br />&nbsp; &nbsp; iterator first <span style="color:#000000">=</span> actions_<span style="color:#000000">.</span><span style="color:#010181">end</span><span style="color:#000000">();</span><br />&nbsp; &nbsp; <span style="color:#000000; font-weight:bold">for</span><span style="color:#000000">(</span>unit_iterator it <span style="color:#000000">=</span> act<span style="color:#000000">.</span>first<span style="color:#000000">;</span> it <span style="color:#000000">!=</span> act<span style="color:#000000">.</span>second<span style="color:#000000">; ++</span>it<span style="color:#000000">){</span><br />&nbsp; &nbsp; &nbsp; &nbsp; iterator chrono_it <span style="color:#000000">=</span> actions_<span style="color:#000000">.</span>project<span style="color:#000000">&lt;</span>chronological<span style="color:#000000">&gt;(</span>it<span style="color:#000000">);</span><br />&nbsp; &nbsp; &nbsp; &nbsp; <span style="color:#000000; font-weight:bold">if</span><span style="color:#000000">(</span>chrono_it <span style="color:#000000">&lt;</span> first <span style="color:#000000">&amp;&amp;</span> chrono_it <span style="color:#000000">&gt;</span> start_position<span style="color:#000000">)</span><br />&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; first <span style="color:#000000">=</span> chrono_it<span style="color:#000000">;</span><br />&nbsp; &nbsp; <span style="color:#000000">}</span><br />&nbsp; &nbsp; <span style="color:#000000; font-weight:bold">return</span> first<span style="color:#000000">;</span><br /><span style="color:#000000">}</span><br /></div></code><br />
<br />
=====<span id="side_actions.reconsideration">Reconsideration of Boost.MultiIndex</span>=====<br />
As gabba noted ([http://www.wesnoth.org/irclogs/2012/03/%23wesnoth-dev.2012-03-31.log #wesnoth-dev 2012/03/31 7h18]), Boost.MultiIndex might be hard to debug and hard to use.<br />
This section try to reconsider the use of Boost.MultiIndex.<br />
<br />
The major problem we would run into while considering to write a replacement for Boost.MultiIndex is how to allow the usage of the standard algorithms. Indeed, they will be usable only on the underlying container and not on its ''view''. To overcome this, a simple solution have been used in Boost: they rewrote all the iterators. The problem is that, even if it now evolved in something bigger, the first goal with <tt>side_actions</tt> refactoring was to remove the iterator's definitions.<br />
<br />
While, indeed Boost.MultiIndex will make debugging harder and increase compilation time compared to an homemade solution.<br />
It offer numerous advantages:<br />
*It's generic, adding a new key will be as easy as adding a new template parameter in the definition.<br />
*It don't have to be rewritten. :)<br />
*It's already used in Wesnoth (thanks mordante for noting it.)<br />
*It offers some advantages over the standard containers (e.g. a random-access container with stable iterators and strong exception guaranty.)<br />
<br />
===<span id="visitorhier">Visitor hierarchy refactoring</span>===<br />
====<span id="visitorhier.situation">The current situation</span>====<br />
The important classes and class templates of this hierarchy are:<br />
*'''<tt>visitor</tt>''', the base class of the visitor hierarchy, it dispatches the calls to the derived classes.<br />
*'''<tt>enable_visit_all</tt>''', which is actually an interface to the <tt>action_ptr</tt> objects of every single team.<br />
*'''<tt>action</tt>''', the root class of the visitable hierarchy.<br />
<br />
Currently, when the visitor hierarchy needs to visit the visitable hierarchy, all the actions of every sides of every turn are visited using the function <tt>enable_visit_all::visit_all_helper</tt> (e.g. this function is called by <tt>highlight_visitor::find_main_highlight</tt> to find the action to highlight.)<br />
<br />
====<span id="visitorhier.idea">The idea</span>====<br />
I'm favorable to the maintain of the Visitor pattern, it segregates the different components nicely.<br />
I think the problem come from <tt>enable_visit_all</tt> and I would like to replace it with a class offering a more fine-grained access to the actions.<br />
For example, a look up by hex could be defined in this new structure and then used by <tt>highlight_visitor</tt>.<br />
Actually, most of the work of this new class will have to do is to redirect the calls to the <tt>side_actions</tt> (to one in particular or to all depending on the function).<br />
<br />
====<span id="visitorhier.implementation">Implementation details</span>====<br />
Let's name this new class <tt>action_set</tt>.<br />
<br />
The sole problem faced is to place <tt>action_set</tt>, since it is mainly a proxy to a global resource (the <tt>side_actions</tt> of each team), it makes sense to place it directly in the <tt>wb</tt> namespace.<br />
<br />
Note that the access to the <tt>action</tt> hierarchy will no more be done through inheritance.<br />
<br />
=====<span id="visitorhier.example">Example</span>=====<br />
Here is an example function that would speed up <tt>highlight_visitor</tt>.<br />
<!-- Original:<br />
action_ptr action_set::action_at(map_location const &hex){<br />
side_actions::iterator result;<br />
foreach(team& side, *resources::teams){<br />
side_actions actions = side.get_side_actions();<br />
if((result = actions.find_action_at(hex)) != actions.end())<br />
return *result;<br />
}<br />
return action_ptr();<br />
}<br />
Formated: --><code><div style="border: 1px dashed #AAA;background:#FAF3E9;padding:7px;">action_ptr action_set<span style="color:#000000">::</span><span style="color:#010181">action_at</span><span style="color:#000000">(</span>map_location <span style="color:#0057ae">const</span> <span style="color:#000000">&amp;</span>hex<span style="color:#000000">){</span><br />&nbsp; &nbsp; side_actions<span style="color:#000000">::</span>iterator result<span style="color:#000000">;</span><br />&nbsp; &nbsp; <span style="color:#010181">foreach</span><span style="color:#000000">(</span>team<span style="color:#000000">&amp;</span> side<span style="color:#000000">, *</span>resources<span style="color:#000000">::</span>teams<span style="color:#000000">){</span><br />&nbsp; &nbsp; &nbsp; &nbsp; side_actions actions <span style="color:#000000">=</span> side<span style="color:#000000">.</span><span style="color:#010181">get_side_actions</span><span style="color:#000000">();</span><br />&nbsp; &nbsp; &nbsp; &nbsp; <span style="color:#000000; font-weight:bold">if</span><span style="color:#000000">((</span>result <span style="color:#000000">=</span> actions<span style="color:#000000">.</span><span style="color:#010181">find_action_at</span><span style="color:#000000">(</span>hex<span style="color:#000000">)) !=</span> actions<span style="color:#000000">.</span><span style="color:#010181">end</span><span style="color:#000000">())</span><br />&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; <span style="color:#000000; font-weight:bold">return</span> <span style="color:#000000">*</span>result<span style="color:#000000">;</span><br />&nbsp; &nbsp; <span style="color:#000000">}</span><br />&nbsp; &nbsp; <span style="color:#000000; font-weight:bold">return</span> <span style="color:#010181">action_ptr</span><span style="color:#000000">();</span><br /><span style="color:#000000">}</span><br /></div></code><br /><br />
<br />
Note: the implementation of <tt>side_actions::find_action_at</tt> is similar to the one of <tt>side_actions::find_first_action_of</tt>.<br />
<br />
===<span id="actioncore">Transfer of the action and validation logic into the core</span>===<br />
This is a (great) idea of Crab ([http://www.wesnoth.org/irclogs/2012/04/%23wesnoth-dev.2012-04-02.log #wesnoth-dev 2012/04/02 16h11]).<br />
<br />
====<span id="actioncore.situation">The current situation</span>====<br />
Currently, the code related to action execution and checking is duplicated in several places.<br />
For example, <tt>ai::recall_result::do_check_before()</tt>, <tt>wb::validate_visitor::visit(recall_ptr)</tt> and <tt>do_replay_handle()</tt> are doing the same thing: checking whether a recall is valid.<br />
Furthermore, the latter is also executing the recall, as is <tt>wb::recall::execute()</tt> and <tt>ai::recall_result::do_execute()</tt>.<br />
<br />
====<span id="actioncore.idea">The idea</span>====<br />
The idea is simple: factor the code.<br />
<br />
However, we must be careful not to include too many functionalities in this new hierarchy, it must be extensible as much as possible without having to modify it.<br />
<br />
The good thing with the current code duplication is that I'll be able to look at different code doing the same thing before choosing the best implementation. ;)<br />
<br />
====<span id="actioncore.implementation">Implementation details</span>====<br />
A nice point of <tt>wb::action</tt> is that gabba used the visitor pattern, which is exactly what we need here.<br />
Indeed, some functions are strictly related to a module (for example the Whiteboard's highlighter), the visitor pattern will allow virtual functions to be defined outside of the visited hierarchy (the action hierarchy here), moreover the visited hierarchy doesn't need to be recompiled when a new visitor is added.<br />
<br />
The overhead of the visitor is really small: an additional (non-virtual) function call.<br />
<br />
Since the validation of an action is needed by all the game, it can be included as a member function <tt>virtual bool valid() const =0;</tt> in the action hierarchy.<br />
<br />
=====<span id="actioncore.whiteboard">Changes in the Whiteboard</span>=====<br />
It's a good idea to read this part even if you're not interested in the Whiteboard, indeed this gives you an idea on to extends this new action hierarchy.<br />
<br />
Currently, there is a Whiteboard-specific action: <tt>suppose_dead</tt>.<br />
Even if it's disabled for now, the new design need to consider it.<br />
Actually, the changes to do are pretty straightforward:<br />
*A new class <tt>suppose_dead</tt> is derived from <tt>action</tt><br />
*A new class <tt>whiteboard_action_visitor</tt> is derived from <tt>action_visitor</tt> and add a virtual function <tt>visit(suppose_dead&amp;)</tt><br />
That's all. :)<br />
Now, the sole Whiteboard visitor (<tt>highlight_visitor</tt>) can derive from <tt>whiteboard_action_visitor</tt> and override <tt>visit(suppose_dead&amp;)</tt>.<br />
<br />
What is important here is that we can still extends the <tt>action</tt> hierarchy which is in core, without modifying it.<br />
<br />
Of course, I'm planing to write <s>the same</s> a better explanation in the documentation. ;)<br />
<br />
=====<span id="actioncore.example">Example</span>=====<br />
Highlighting a recruit action in the Whiteboard:<br />
<!-- Original:<br />
recruit recruit_action(the_team, the_unit, the_hex);<br />
highlighter_->visit(recruit_action);<br />
Formated: --><code><div style="border: 1px dashed #AAA;background:#FAF3E9;padding:7px;">recruit <span style="color:#010181">recruit_action</span><span style="color:#000000">(</span>the_team<span style="color:#000000">,</span> the_unit<span style="color:#000000">,</span> the_hex<span style="color:#000000">);</span><br />highlighter_<span style="color:#000000">-&gt;</span><span style="color:#010181">visit</span><span style="color:#000000">(</span>recruit_action<span style="color:#000000">);</span><br /></div></code><br /><br />
<br />
Here is the code skeleton for <tt>wb::suppose_dead</tt>:<br />
<!-- Original:<br />
class suppose_dead: public action {<br />
public:<br />
void accept(whiteboard_action_visitor &vis){ vis.visit(*this); }<br />
/* the code… */<br />
};<br />
<br />
class whiteboard_action_visitor: public action_visitor {<br />
public:<br />
virtual void visit(suppose_dead&) =0;<br />
};<br />
<br />
class highlight_visitor: public whiteboard_action_visitor {<br />
public:<br />
void visit(recruit &rec){<br />
/* Display some nice sign */<br />
}<br />
void visit(suppose_dead &dead){<br />
/* Display some scary sign */<br />
}<br />
/* … */<br />
};<br />
Formated: --><code><div style="border: 1px dashed #AAA;background:#FAF3E9;padding:7px;"><span style="color:#000000; font-weight:bold">class</span> suppose_dead<span style="color:#000000">:</span> <span style="color:#000000; font-weight:bold">public</span> action <span style="color:#000000">{</span><br /><span style="color:#000000; font-weight:bold">public</span><span style="color:#000000">:</span><br />&nbsp; &nbsp; <span style="color:#0057ae">void</span> <span style="color:#010181">accept</span><span style="color:#000000">(</span>whiteboard_action_visitor <span style="color:#000000">&amp;</span>vis<span style="color:#000000">){</span> vis<span style="color:#000000">.</span><span style="color:#010181">visit</span><span style="color:#000000">(*</span><span style="color:#000000; font-weight:bold">this</span><span style="color:#000000">); }</span><br />&nbsp; &nbsp; <span style="color:#838183; font-style:italic">/* the code… */</span><br /><span style="color:#000000">};</span><br /><br /><span style="color:#000000; font-weight:bold">class</span> whiteboard_action_visitor<span style="color:#000000">:</span> <span style="color:#000000; font-weight:bold">public</span> action_visitor <span style="color:#000000">{</span><br /><span style="color:#000000; font-weight:bold">public</span><span style="color:#000000">:</span><br />&nbsp; &nbsp; <span style="color:#000000; font-weight:bold">virtual</span> <span style="color:#0057ae">void</span> <span style="color:#010181">visit</span><span style="color:#000000">(</span>suppose_dead<span style="color:#000000">&amp;) =</span><span style="color:#b07e00">0</span><span style="color:#000000">;</span><br /><span style="color:#000000">};</span><br /><br /><span style="color:#000000; font-weight:bold">class</span> highlight_visitor<span style="color:#000000">:</span> <span style="color:#000000; font-weight:bold">public</span> whiteboard_action_visitor <span style="color:#000000">{</span><br /><span style="color:#000000; font-weight:bold">public</span><span style="color:#000000">:</span><br />&nbsp; &nbsp; <span style="color:#0057ae">void</span> <span style="color:#010181">visit</span><span style="color:#000000">(</span>recruit <span style="color:#000000">&amp;</span>rec<span style="color:#000000">){</span><br />&nbsp; &nbsp; &nbsp; &nbsp; <span style="color:#838183; font-style:italic">/* Display some nice sign */</span><br />&nbsp; &nbsp; <span style="color:#000000">}</span><br />&nbsp; &nbsp; <span style="color:#0057ae">void</span> <span style="color:#010181">visit</span><span style="color:#000000">(</span>suppose_dead <span style="color:#000000">&amp;</span>dead<span style="color:#000000">){</span><br />&nbsp; &nbsp; &nbsp; &nbsp; <span style="color:#838183; font-style:italic">/* Display some scary sign */</span><br />&nbsp; &nbsp; <span style="color:#000000">}</span><br />&nbsp; &nbsp; <span style="color:#838183; font-style:italic">/* … */</span><br /><span style="color:#000000">};</span><br /></div></code><br /><br />
<br />
===<span id="polishing">Polishing</span>===<br />
Some inconsistencies are present in the code (e.g. the way units are referenced). Some other parts needs clean up or/and optimisation (e.g. usage of <tt>boost::dynamic_pointer_cast</tt>).<br />
<br />
The goal of this task is to find this kind of small problem and fix them.<br />
These two ones have been spotted by gabba, but I'm planning to add other small problems to this list as I found them.<br />
<br />
Also, they can be a good introduction to the code that's why I'm planning to start working on them before the GSoC start date.<br />
<br />
Although, the <tt>mapbuilder</tt> refactoring was one of the main task, I'm putting it here since it'll be mainly refactored as part of the [[#visitorhier|visitor hierarchy refactoring]] and as part of the [[#actioncore|transfer of the action and validation logic into the core]]. Indeed, the <tt>mapbuilder</tt> isn't badly designed, all the problems are coming from the API it has to use.<br />
<br />
===<span id="designdoc">Design document</span>===<br />
This idea is inspired by the GUI2 design document present in the SVN.<br />
<br />
Doxygen documents the code at a function or class level.<br />
The goal is to write a documentation at the module level. That is a document describing the Whiteboard design globally and not function-by-function.<br />
Actually it shouldn't duplicate what is in doxygen but complement it.<br />
This document could also include informations on how to extend the Whiteboard to help future contributors.<br />
<br />
This design document will be written as a doxygen page, this will leave the documentation next to the code.<br />
<br />
However, I'll begin to put some drafts on the wiki before committing it. Indeed, that will make reviewing easier.<br />
<br />
===Openings===<br />
Here are some possible openings to transform this Google summer of code into a Google year of code:<br />
*Use the new action hierarchy wherever it's needed<br />
*As suggested by gabba, replace the current <tt>wb::manager::on_gamestate_change</tt> by something more generic (maybe something like <tt>ai::gamestate_observer</tt>)<br />
<br />
===Timeline===<br />
Two of my five tasks are actually best done continuously: the design document and the polishing.<br />
Although I haven't clearly placed a week for them, I set two dates at which they should have been completed.<br />
<br />
Of course, the plan is not to have any delay and to finish each task early, however I have reserved two weeks (actually one week and a half) for unexpected delay.<br />
I named them "movable weeks", because they can move in my timeline if anything goes wrong. :)<br />
<br />
On the other hand, I have some [[#Openings|openings]] planned.<br /><br /><br />
<br />
<!-- Wikitext hell 101 --><br />
{| style="border:1px dashed #AAA;border-collapse:collapse;"<br />
|-<br />
!style="border:1px dotted #AAA;padding:5px;"|Date<br />
!style="border:1px dotted #AAA;padding:5px;"|Week<br />
!style="border:1px dotted #AAA;padding:5px;"|Description<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''17/03 - 20/04''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''-11..-5''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Student application evaluation''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|17/03 - 20/04<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|-11..-5<br />
|style="border:1px dotted #AAA;padding:5px;"|Refine the proposal.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''23/04 - 20/05''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''-4..-1''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Community Bonding Period (4 weeks)''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|'''23/04 - 20/05'''<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|'''-4..-1'''<br />
|style="border:1px dotted #AAA;padding:5px;"|'''Phase 0: Approach'''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|23/04 - 20/05<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|-4..-1<br />
|style="border:1px dotted #AAA;padding:5px;"|Familiarise myself with the Whiteboard, in the process start a draft of the design document.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|23/04 - 20/05<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|-4..-1<br />
|style="border:1px dotted #AAA;padding:5px;"|Start working on the ''polishing''.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''21/05''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''0''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Start of GSoC''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|21/05 - 12/08<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|0..11<br />
|style="border:1px dotted #AAA;padding:5px;"|Continuously work on the design document and on the code polishing.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''21/05 - 15/07''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''0..7''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''First half term (8 weeks)''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|'''21/05 - 10/06'''<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|'''0..2'''<br />
|style="border:1px dotted #AAA;padding:5px;"|'''Phase 1: <tt>side_actions</tt> refactoring'''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|21/05 - 27/05<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|0<br />
|style="border:1px dotted #AAA;padding:5px;"|Prepare <tt>side_actions</tt> for the change. Add debug informations to the logs. Add the new member <tt>turn_beginnings_</tt>.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|28/05 - 03/06<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|1<br />
|style="border:1px dotted #AAA;padding:5px;"|Change the type of <tt>actions_</tt> and rewrite the associated functions. Delete the custom iterators.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|04/06 - 10/06<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|2<br />
|style="border:1px dotted #AAA;padding:5px;"|Debug, write unit test and documentation.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|'''11/06 - 01/07'''<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|'''3..5'''<br />
|style="border:1px dotted #AAA;padding:5px;"|'''Phase 2: Validator hierarchy refactoring'''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|11/06 - 17/06<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|3<br />
|style="border:1px dotted #AAA;padding:5px;"|Write the class <tt>action_set</tt>.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|18/06 - 24/06<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|4<br />
|style="border:1px dotted #AAA;padding:5px;"|Replace the uses of <tt>enable_visit_all</tt> with the new interface. Then delete <tt>enable_visit_all</tt>.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|25/06 - 01/07<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|5<br />
|style="border:1px dotted #AAA;padding:5px;"|Debug, write unit test and documentation.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|'''02/07 - 22/07'''<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|'''6..8'''<br />
|style="border:1px dotted #AAA;padding:5px;"|'''Phase 3: Transfer of the action and validation logic into the core'''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|02/07 - 08/07<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|6<br />
|style="border:1px dotted #AAA;padding:5px;"|Separation of the Whiteboard specific-code from the actions. Transfer of the actions in the core.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|09/07 - 15/07<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|7<br />
|style="border:1px dotted #AAA;padding:5px;"|Use this new API in other places, including the <tt>mapbuilder</tt>.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''13/07''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''7''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Mid-term evaluation''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''16/07 - 26/08''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''8..13''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Second half term (6 weeks)''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|16/07 - 22/07<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|8<br />
|style="border:1px dotted #AAA;padding:5px;"|Document the new action hierarchy. Mark @deprecated copies of it.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|'''22/07 - 12/08'''<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|'''9..11'''<br />
|style="border:1px dotted #AAA;padding:5px;"|'''Phase 4: Finalisation'''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|22/07 - 29/07<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|9<br />
|style="border:1px dotted #AAA;padding:5px;"|Heavy testing week.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|30/07 - 05/08<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|10<br />
|style="border:1px dotted #AAA;padding:5px;"|Test, debug. Finish the ''polishing''.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|06/08 - 12/08<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|11<br />
|style="border:1px dotted #AAA;padding:5px;"|Test, debug. Finish the design document.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|13/08 - 19/08<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|12<br />
|style="border:1px dotted #AAA;padding:5px;"|Movable week.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|20/08 - 26/08<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|13<br />
|style="border:1px dotted #AAA;padding:5px;"|Movable week.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''24/08''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''13''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Final evaluation''<br />
|}</div>Ejlshttps://wiki.wesnoth.org/index.php?title=User:Ejls/GSoC_2012/Questionnaire&diff=46169User:Ejls/GSoC 2012/Questionnaire2012-04-05T20:31:47Z<p>Ejls: update</p>
<hr />
<div>__NOTOC__<!--<br />
-->__NOEDITSECTION__<!--<br />
--><noinclude>'''Note: This is a template to be included in a proposal page by transclusion. All question are not answered here, you should refer to a proposal page.'''</noinclude><!--<br />
This template has seven parameters: the seven answers to the proposal-specific questions of section 4. --><br />
{|style="background:#FAF3E9;margin:none;border:3px double #AAA;-moz-border-radius:20px 5px 20px 5px;-webkit-border-radius:20px 5px 20px 5px;border-radius:20px 5px 20px 5px;"<br />
|-<br />
| style="text-align: left; padding: 0px 10px 5px 10px"|<br />
==Questionnaire==<br />
|-<br />
| style="text-align: center; padding:0px 10px 10px 10px;"|[[#1) Basics|Basics]] - [[#2) Experience|Experience]] - [[#3) Communication skills|Communication skills]] - [[#4) Project|Project]] - [[#5) Practical considerations|Practical considerations]]<br />
|}<br />
===1) Basics===<br />
====1.1) Write a small introduction to yourself.====<br />
My name is Étienne Simon (forename: Étienne), I'm 20 years old and I live in Paris, France. I really enjoy programming, particularly in C++ and I would like to use my programming skills on a big project like Wesnoth. Also, this year I'll participate in [http://www.prologin.org Prologin] for the third time. It's the French national programming contest, which I have been 6th and two times finalist.<br />
<br />
====1.2) State your preferred email address.====<br />
Address (at gmail dot com): etienne.jl.simon<br />
<br />
====1.3) If you have chosen a nick for IRC and Wesnoth forums, what is it?====<br />
ejls<br />
<br />
====1.4) Why do you want to participate in summer of code?====<br />
First of all, I can say I have only theoretical knowledge so far and I believe thanks to a SoC on Wesnoth, I can gain lot of experience since I'll work work on a real project. In addition to that, like I said, I like programming, being paid to do what you like doing is quite cool. Besides, I'm using open source softwares a lot, so it would be nice if my first work could be for the open source community. And of course, for the T-Shirt.<br />
<br />
====1.5) What are you studying, subject, level and school?====<br />
I'm in third and last year of a bachelor's degree (licence) in computer science at Pierre et Marie Curie, Sorbonne Université ([http://www.upmc.fr UPMC], Paris VI), I mainly took courses related to algorithm and artificial intelligence. Next year, I'll start a master's degree in artificial intelligence and decision.<br />
<br />
====1.6) What country are you from, at what time are you most likely to be able to join IRC?====<br />
I'm from France, CEST (UTC+2 during summer). I always have an irssi running on a server, but I'm more likely to answer during the afternoon and evening. However before the end of the Spring term (4th of June), I'll be able to connect at these times only the weekend and on Friday, I wont be available before 6p.m. UTC for the rest of the week.<br />
<br />
====1.7) Do you have other commitments for the summer period ? Do you plan to take any vacations ? If yes, when.====<br />
My term (including exams) ends the 4th of June, otherwise I'm considering the GSoC as a full-time job (with more fun and week-end included), therefore I don't have any plans for this summer.<br />
<br />
===2) Experience===<br />
====2.1) What programs/software have you worked on before?====<br />
Only school projects:<br />
<br />
Two years ago (during my first year), we had to code a go/othelo-like game in C. I wrote the game with some extra: a curse interface, a simple AI (alpha-beta) and an AI using unsupervised learning, for this last part, I used NEAT <span style="color: #888; font-size: 0.85em;">[NeuroEvolution of Augmenting Topologies]</span> (a genetical algorithm evolving neural networks), it didn't beat the minimax though :(. Total: 5000 SLOC <span style="color: #888; font-size: 0.85em;">[Source Lines Of Code]</span>.<br />
<br />
Last year, we wrote a BASIC compiler in C (again). I improved the BASIC language a bit: support for array, UDT, function overload and operator overload, the support of references was buggy (poorly designed). Total: 7000 ugly, messy SLOC.<br />
<br />
This year, we had to wrote an image manipulation program in C++ (finally!). I used Gtkmm (a C++ wrapper of Gtk+). The result was pretty good, documented with Doxygen and compilable with CMake or with a basic Makefile. Overall, It allowed me to get familiar with C++11 since before this project I've always used gcc 4.2. Total: 5000 SLOC (doxygen documentation (including code) available [http://epsilon012.free.fr/egami online]).<br />
<br />
====2.2) Have you developed software in a team environment before? (As opposed to hacking on something on your own)====<br />
The group projects that I worked in were about web development and database administration so I can't really say yes, but that's one of the main reasons why I want to participate in GSoC.<br />
<br />
====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?====<br />
No, not yet. :)<br />
<br />
====2.4) Are you already involved with any open source development projects? If yes, please describe the project and the scope of your involvement.====<br />
No.<br />
<br />
====2.5) Gaming experience - Are you a gamer?====<br />
Yes, everyone like to play. ;)<br />
<br />
=====2.5.1) What type of gamer are you?=====<br />
Hum… I suppose the answers in this subsection can give you an idea about my type. If I'm playing a game it's to have fun, so I'm a "for the lulz gamer", but I suppose it's the same for most people.<br />
<br />
=====2.5.2) What type of games?=====<br />
Turn-based games like Nethack, Freeciv and of course Wesnoth. I enjoy both strategy and role-playing games, but I like to have time to take a decision.<br />
<br />
I also enjoy programming games like jousting, golfing (with Vim) and programming in esoteric languages. For example, I have completed the three first questions of the French national programming contest's qualification in brainfuck, befunge and whitespace (code [http://epsilon012.free.fr/Prologin2012 here], including a 5289 instructions brainfuck program).<br />
<br />
=====2.5.3) What type of opponents do you prefer?=====<br />
Players using original and unexpected strategy. The HODOR players were really funny, but well…<br />
<br />
=====2.5.4) Are you more interested in story or gameplay?=====<br />
I tend to select a game on his gameplay, but when it misses a good story I'm less likely to play it.<br />
<br />
=====2.5.5) Have you played Wesnoth? If so, tell us roughly for how long and whether you lean towards single player or multiplayer.=====<br />
Not that much, actually I discovered Wesnoth 1.6 two years ago and I can't really say I've played it a lot since then. I prefer to play usually as single player, after completing most of the mainline campaigns (of which I really liked DiD), I played online, but now I'm mostly playing add-ons campaigns. As an indicator: I'm still unable to list drakes units.<br />
<br />
====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.====<br />
I have been lurking the code for a good time now, in January 2011, I reported 3 bugs with 1-line patch attached:<br />
*Two compilation errors: [https://gna.org/bugs/?17584 Bug #17584] and [https://gna.org/bugs/?17585 Bug #17585].<br />
*A minimap bug: [https://gna.org/bugs/?17676 Bug #17676].<br />
I have also written longer patches:<br />
*'''(AI)''' [https://gna.org/patch/?3185 Patch #3185] <tt>power_projection</tt> improvement, it now takes in account future ToD and time areas, I also cleaned the code a bit (task from the [[EasyCoding]] page.)<br />
*'''(WB)''' [https://gna.org/patch/?3201 Patch #3201] Make leader unable to move when invalidating a planned recall (fixes [https://gna.org/bugs/?19581 Bug #19581] that I found reading the whiteboard code.)<br />
I have gained commit access the 02/04/2012.<br />
<br />
===3) Communication skills===<br />
====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.====<br />
I have studied one term in London last winter, so, my level is good enough to understand and to be understood, don't expect an error-free essay from me though. :)<br />
<br />
====3.2) What spoken languages are you fluent in?====<br />
French and English.<br />
<br />
====3.3) Are you good at interacting with other players? Our developer community is friendly, but the player community can be a bit rough.====<br />
I'm a really calm person, I always take my time to answer messages. Otherwise, I'm ignoring flamers, I think it's the best to do.<br />
<br />
====3.4) Do you give constructive advice?====<br />
I try to.<br />
<br />
====3.5) Do you receive advice well?====<br />
Well, I enjoy receiving advices and learning, otherwise I wouldn't be here. :)<br />
<br />
====3.6) Are you good at sorting useful criticisms from useless ones?====<br />
I think most criticisms are useful, I'm used to the Internet though, troll don't ambush me.<br />
<br />
====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====<br />
It depends of what have to be done, the bigger the work is the more it has to be discussed. However if my proposal is retained, I might be a bit more scared of doing something bad in the beginning, so I might discuss a solution more than usual. :)<br />
<br />
===4) Project===<br />
====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?====<br />
<noinclude>'''Note: this page is a template, the answer to this question is a parameter. Please, refer to a proposal page.'''</noinclude>{{{1|}}}<br />
<br />
====4.2) If you have invented your own project, please describe the project and the scope.====<br />
<noinclude>'''Note: this page is a template, the answer to this question is a parameter. Please, refer to a proposal page.'''</noinclude>{{{2|}}}<br />
<br />
====4.3) Why did you choose this project?====<br />
<noinclude>'''Note: this page is a template, the answer to this question is a parameter. Please, refer to a proposal page.'''</noinclude>{{{3|}}}<br />
<br />
====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".====<br />
<noinclude>'''Note: this page is a template, the answer to this question is a parameter. Please, refer to a proposal page.'''</noinclude>{{{4|}}}<br />
<br />
====4.5) Include as much technical detail about your implementation as you can====<br />
<noinclude>'''Note: this page is a template, the answer to this question is a parameter. Please, refer to a proposal page.'''</noinclude>{{{5|}}}<br />
<br />
====4.6) What do you expect to gain from this project?====<br />
<noinclude>'''Note: this page is a template, the answer to this question is a parameter. Please, refer to a proposal page.'''</noinclude>{{{6|}}}<br />
<br />
====4.7) What would make you stay in the Wesnoth community after the conclusion of SOC?====<br />
<noinclude>'''Note: this page is a template, the answer to this question is a parameter. Please, refer to a proposal page.'''</noinclude>{{{7|}}}<br />
<br />
===5) Practical considerations===<br />
====5.1) Are you familiar with any of the following tools or languages?====<br />
*Subversion<br />
:I've already used it, but I've opted for git instead.<br />
*C++ (language used for all the normal source code)<br />
:I'm a big fan. I follow the WG21 publications and I often read comp.std.c++ and comp.lang.c++.moderated.<br />
*STL, Boost, Sdl (C++ libraries used by Wesnoth)<br />
:I'm of course used to the stdlib (not to all addition of C++11 though). I'm not familiar with all Boost (I don't have enough brain for this). But I have often used the parts of Boost that's are now (more or less) in the C++11 stdlib and the MPL. I also used a bit Asio, Filesystem and Phoenix (for being the most WTF library), and some other small libraries like Program Option and Range. I never worked on a project using the SDL, I'm not a big GUI user.<br />
*Python (optional, mainly used for tools)<br />
:Not really, no, really basic.<br />
*build environments (eg cmake/scons)<br />
:I've already wrote some CMakeList.txt, but I never worked with nor used scons.<br />
*WML (the wesnoth specific scenario language)<br />
:I wrote a [[User:Ejls/Vim|Vim syntax]] file for it, so I'm already a bit familiar with it. I'm missing practice though.<br />
*Lua (used in combination with WML to create scenarios)<br />
:I'm familiar with it, not as much as C++ but I already used it as a scripting language for an (annoying) IRC bot I wrote. I'm not familiar with its integration in Wesnoth though.<br />
<br />
====5.2) Which tools do you normally use for development? Why do you use them?====<br />
Vim and Unix tools, Perl for big stuff. They are the most productive tools for me, I'm used to them. I'm coding with a laptop under OpenBSD (with gcc 4.2). I also compile Wesnoth on a Debian server (with gcc 4.6), but the X over ssh is a bit slow sometimes. Finally, I temporally have a laptop with FreeBSD 9.0.<br />
<br />
====5.3) What programming languages are you fluent in?====<br />
I'm good in C++, C, Lua, Perl and VimScript. I've a lack of practice in Java, Caml, Scheme, NetLogo, CLIPS and AiML (all of them learnt during my studies). On a different note, I like brainfuck, befunge, whitespace and golfscript.<br />
<br />
====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!====<br />
If you can't join me by email or on IRC, I'm probably dead but sometimes it's easier to speak than to write so I'll include my phone number in my application.</div>Ejlshttps://wiki.wesnoth.org/index.php?title=EasyCoding&diff=46021EasyCoding2012-04-02T20:33:41Z<p>Ejls: Removing the power_projection task, it has been implemented as Patch #3185</p>
<hr />
<div>== Foreword ==<br />
This page is here to document easy to do coding tasks. It is not here to double the feature request database, and should only be filled by people that know the code well enough to judge the difficulty of a given task. <br />
<br />
If you are such a person, you should feel free to edit this page.<br />
<br />
If you're not, you should post a feature request and discuss your idea on the forum or IRC. A coder with better knowledge of the code might give you the green light to add your feature here.<br />
<br />
Anybody should feel free to add "clues" to any tasks, that is entry points, traps to avoid, person to contact to discuss and so on.<br />
<br />
If you plan to work on a feature, write your name at the bottom of the feature, with the date. Note that if you are too long at working on a feature I'll "free" it back (that is if you're not working on it. If you have problems implementing it, just tell us....)<br />
<br />
<br />
--[[User:Boucman|Boucman]] 20:48, 3 October 2006 (CEST)<br />
<br />
<br />
Since bugs are sometimes a good opportunity to get a first idea of the code, i will add some here that are easy to fix as soon as i stumble upon them (the one i had in mind is fixed already ;-).<br />
<br />
--Yogi Bear, 28 February 2008<br />
<br />
== MP related features ==<br />
=== Add possibility to give reason for "ignore" ===<br />
As per FR #16001 [https://gna.org/bugs/?16001]<br />
<br />
on it - uzyszkodnik 31.03.2012<br />
<br />
== WML related features ==<br />
<br />
=== WML configurable village income / upkeep ===<br />
Preferably as a [scenario], [side] or [campaign] keys. As per FR #6301 [https://gna.org/bugs/?6301].<br />
<br />
--[[User:Gabba|Gabba]] 19 March 2012 : This is currently assigned to me, but as I lack time and interest to finish integrating this, GSoC students or other interested coders are welcome to take up the current patch and finish the job: https://gna.org/patch/?1381<br />
<br />
=== Add support of [if] for [scenario] ===<br />
As per FR #4539 [https://gna.org/bugs/?4539]<br />
<br />
=== Side-specific results ===<br />
Giving result=defeat or result=victory for specific sides. ([http://gna.org/bugs/index.php?4960 FR #4960]) -- [[User:dlr365|dlr365]] -- patch submitted [https://gna.org/bugs/index.php?4960]<br />
<br />
--[[User:Boucman|Boucman]] 08:58, 28 February 2010 (UTC) Patch seems abandonned, but can be used for further work feel free to take over the FR<br />
<br />
=== Support for leaderless multiplayergames ===<br />
Add support for the WML key victory_when_enemies_defeated= in the scenario tag during multiplayergames. ([https://gna.org/bugs/index.php?8106 FR #8106])<br />
--[[User:Endercoaster|endercoaster]] 30, March 2010. I'm gonna give this one a try.<br />
<br />
=== Support for standalone multiplayer scenarios ===<br />
There used to be support for standalone scenarios in the userdata tree, in reorganising the trees this feature got lost and an add-on is now required to add a scenario.<br />
Re-add this feature. It is probably a good idea to mirror the mainline multiplayer tree.<br />
<br />
<br />
=== Support variable recall cost in wml ===<br />
see https://gna.org/bugs/?16538<br />
<br />
the syntax needs to be discussed and refined, but the overall idea is good<br />
<br />
make sure to update whiteboard to handle this correctly<br />
<br />
Ask Boucman<br />
<br />
=== Other Ideas ===<br />
See [[FutureWML]]; some ideas there are easier than others.<br />
<br />
== Improvements to AI ==<br />
<br />
Fix some todos, add new formula functions, or do minor improvements to the formula language. Make it easier to debug the formula language, add more ai components.<br />
<br />
Please discuss these with Crab, Dragonking, Sirp or Boucman<br />
<br />
=== Add more ai actions ===<br />
<br />
Add an ai action (and add lua function to do that) to set a goto on a unit<br />
<br />
Add an ai action (and add lua function to do that) to send a chat message to a player<br />
<br />
Add an ai action (and add lua function to do that) to use a right-click menu item.<br />
<br />
=== write a (fai or c++ or lua) candidate action for leader control ===<br />
<br />
== GUI related features ==<br />
-------------------<br />
<br />
Note at the moment Mordante is working on a new GUI system, these <br />
changes will probably affect the way these items need to be implemented.<br />
Contact Mordante on IRC before starting to work on these.<br />
<br />
--[[User:SkeletonCrew|SkeletonCrew]] 14:04, 9 March 2008 (EDT)<br />
<br />
<br />
=== Theme Changes ===<br />
<br />
* allow custom themes to display values of WML variables ([http://gna.org/bugs/index.php?6209 FR #6209])<br />
* hide the hourglass item from the statusbar when there is no timer<br />
<br />
=== Widget Changes ===<br />
* show side number, name and team association information in the status table <br />
* make games sortable in the lobby (open slots, total number of players, era, XP modifier, gold per village, fog/shroud) <br />
* input history (chat, commands, ..) - note: rujasu is working on this feature<br />
=== Story Screen improvements ===<br />
see http://www.wesnoth.org/forum/viewtopic.php?p=439346#p439346 for the suggestion and https://gna.org/patch/?1587 for a patch that already touched that area heavily<br />
<br />
== GUI2 related features ==<br />
GUI2 is the new gui engine Mordante/SkeletonCrew is working on. <br />
* Information on the wiki can be found here http://www.wesnoth.org/wiki/GUIToolkit<br />
* The source code is under src/gui/<br />
* The configuration config files are under data/gui/default<br />
<br />
Some tasks need the --new-widgets since the code is only shown in the experimental mode. Tasks which need this switch have the * in the title.<br />
<br />
At the moment there are no easy tasks available.<br />
<br />
== Miscellaneous ==<br />
<br />
=== More powerful village naming ===<br />
'''Adding mountain names and other features to village names, having a second random name in village names'''<br />
<br />
Currently the village naming engine has a very good structure that could allow <br />
more powerfull names to be generated. <br />
Understanding how it works should be quite easy, and a few usefull improvements could be added.<br />
<br />
* Currently villages can use lake names and river names, this should be extended to other features like bridges, swamps, mountains etc...<br />
* It would be nice to have a separate list of "first sylabus" and "last sylabus" for naming. That's not really needed in english, but some translations could use it<br />
* Again, it is common to have villages with more than one "random" word in them. having a $name2 variable would be nice<br />
<br />
Euschn 24/03/2009<br />
<br />
=== Debug Mode ===<br />
* New debug command functionality (setting additional status.variables, possibly terrain)<br />
=== Option to disable terrain animations globally ===<br />
see https://gna.org/bugs/?15976<br />
<br />
please think a little about use cases (editor, game etc...)<br />
<br />
ask boucman for details<br />
<br />
<br />
=== Add a cycle parameter to the unit animation WML ===<br />
<br />
Animations have a "cycle" internal parameter that decides if the animation loops when it finishes. <br />
<br />
Right now that parameter is decided purely by the engine depending on the circumstances, but it would make sense to move it to a frame paramter.<br />
<br />
This task is mainly to add a new boolean parameter in the particle class and using/exposing it to WML in a way similar to a unit_frame<br />
<br />
ask boucman for details<br />
<br />
== Bugs ==<br />
<br />
<br />
<br />
== See Also ==<br />
<br />
[[NotSoEasyCoding]]<br />
<br />
[[Category:Development]]<br />
[[Category:Future]]</div>Ejlshttps://wiki.wesnoth.org/index.php?title=User:Ejls/GSoC_2012/Questionnaire&diff=46003User:Ejls/GSoC 2012/Questionnaire2012-04-01T21:25:00Z<p>Ejls: typo</p>
<hr />
<div>__NOTOC__<!--<br />
-->__NOEDITSECTION__<!--<br />
--><noinclude>'''Note: This is a template to be included in a proposal page by transclusion. All question are not answered here, you should refer to a proposal page.'''</noinclude><!--<br />
This template has seven parameters: the seven answers to the proposal-specific questions of section 4. --><br />
{|style="background:#FAF3E9;margin:none;border:3px double #AAA;-moz-border-radius:20px 5px 20px 5px;-webkit-border-radius:20px 5px 20px 5px;border-radius:20px 5px 20px 5px;"<br />
|-<br />
| style="text-align: left; padding: 0px 10px 5px 10px"|<br />
==Questionnaire==<br />
|-<br />
| style="text-align: center; padding:0px 10px 10px 10px;"|[[#1) Basics|Basics]] - [[#2) Experience|Experience]] - [[#3) Communication skills|Communication skills]] - [[#4) Project|Project]] - [[#5) Practical considerations|Practical considerations]]<br />
|}<br />
===1) Basics===<br />
====1.1) Write a small introduction to yourself.====<br />
My name is Étienne Simon (forename: Étienne), I'm 20 years old and I live in Paris, France. I really enjoy programming, particularly in C++ and I would like to use my programming skills on a big project like Wesnoth. Also, this year I'll participate in [http://www.prologin.org Prologin] for the third time. It's the French national programming contest, which I have been 6th and two times finalist.<br />
<br />
====1.2) State your preferred email address.====<br />
Address (at gmail dot com): etienne.jl.simon<br />
<br />
====1.3) If you have chosen a nick for IRC and Wesnoth forums, what is it?====<br />
ejls<br />
<br />
====1.4) Why do you want to participate in summer of code?====<br />
First of all, I can say I have only theoretical knowledge so far and I believe thanks to a SoC on Wesnoth, I can gain lot of experience since I'll work work on a real project. In addition to that, like I said, I like programming, being paid to do what you like doing is quite cool. Besides, I'm using open source softwares a lot, so it would be nice if my first work could be for the open source community. And of course, for the T-Shirt.<br />
<br />
====1.5) What are you studying, subject, level and school?====<br />
I'm in third and last year of a bachelor's degree (licence) in computer science at Pierre et Marie Curie, Sorbonne Université ([http://www.upmc.fr UPMC], Paris VI), I mainly took courses related to algorithm and artificial intelligence. Next year, I'll start a master's degree in artificial intelligence and decision.<br />
<br />
====1.6) What country are you from, at what time are you most likely to be able to join IRC?====<br />
I'm from France, CEST (UTC+2 during summer). I always have an irssi running on a server, but I'm more likely to answer during the afternoon and evening. However before the end of the Spring term (4th of June), I'll be able to connect at these times only the weekend and on Friday, I wont be available before 6p.m. UTC for the rest of the week.<br />
<br />
====1.7) Do you have other commitments for the summer period ? Do you plan to take any vacations ? If yes, when.====<br />
My term (including exams) ends the 4th of June, otherwise I'm considering the GSoC as a full-time job (with more fun and week-end included), therefore I don't have any plans for this summer.<br />
<br />
===2) Experience===<br />
====2.1) What programs/software have you worked on before?====<br />
Only school projects:<br />
<br />
Two years ago (during my first year), we had to code a go/othelo-like game in C. I wrote the game with some extra: a curse interface, a simple AI (alpha-beta) and an AI using unsupervised learning, for this last part, I used NEAT <span style="color: #888; font-size: 0.85em;">[NeuroEvolution of Augmenting Topologies]</span> (a genetical algorithm evolving neural networks), it didn't beat the minimax though :(. Total: 5000 SLOC <span style="color: #888; font-size: 0.85em;">[Source Lines Of Code]</span>.<br />
<br />
Last year, we wrote a BASIC compiler in C (again). I improved the BASIC language a bit: support for array, UDT, function overload and operator overload, the support of references was buggy (poorly designed). Total: 7000 ugly, messy SLOC.<br />
<br />
This year, we had to wrote an image manipulation program in C++ (finally!). I used Gtkmm (a C++ wrapper of Gtk+). The result was pretty good, documented with Doxygen and compilable with CMake or with a basic Makefile. Overall, It allowed me to get familiar with C++11 since before this project I've always used gcc 4.2. Total: 5000 SLOC (doxygen documentation (including code) available [http://epsilon012.free.fr/egami online]).<br />
<br />
====2.2) Have you developed software in a team environment before? (As opposed to hacking on something on your own)====<br />
The group projects that I worked in were about web development and database administration so I can't really say yes, but that's one of the main reasons why I want to participate in GSoC.<br />
<br />
====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?====<br />
No, not yet. :)<br />
<br />
====2.4) Are you already involved with any open source development projects? If yes, please describe the project and the scope of your involvement.====<br />
No.<br />
<br />
====2.5) Gaming experience - Are you a gamer?====<br />
Yes, everyone like to play. ;)<br />
<br />
=====2.5.1) What type of gamer are you?=====<br />
Hum… I suppose the answers in this subsection can give you an idea about my type. If I'm playing a game it's to have fun, so I'm a "for the lulz gamer", but I suppose it's the same for most people.<br />
<br />
=====2.5.2) What type of games?=====<br />
Turn-based games like Nethack, Freeciv and of course Wesnoth. I enjoy both strategy and role-playing games, but I like to have time to take a decision.<br />
<br />
I also enjoy programming games like jousting, golfing (with Vim) and programming in esoteric languages. For example, I have completed the three first questions of the French national programming contest's qualification in brainfuck, befunge and whitespace (code [http://epsilon012.free.fr/Prologin2012 here], including a 5289 instructions brainfuck program).<br />
<br />
=====2.5.3) What type of opponents do you prefer?=====<br />
Players using original and unexpected strategy. The HODOR players were really funny, but well…<br />
<br />
=====2.5.4) Are you more interested in story or gameplay?=====<br />
I tend to select a game on his gameplay, but when it misses a good story I'm less likely to play it.<br />
<br />
=====2.5.5) Have you played Wesnoth? If so, tell us roughly for how long and whether you lean towards single player or multiplayer.=====<br />
Not that much, actually I discovered Wesnoth 1.6 two years ago and I can't really say I've played it a lot since then. I prefer to play usually as single player, after completing most of the mainline campaigns (of which I really liked DiD), I played online, but now I'm mostly playing add-ons campaigns. As an indicator: I'm still unable to list drakes units.<br />
<br />
====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.====<br />
I have been lurking the code for a good time now, in January 2011, I reported 3 bugs with 1-line patch attached:<br />
*Two compilation errors: [https://gna.org/bugs/?17584 Bug #17584] and [https://gna.org/bugs/?17585 Bug #17585].<br />
*A minimap bug: [https://gna.org/bugs/?17676 Bug #17676].<br />
I have also written longer patches:<br />
*'''(AI)''' [https://gna.org/patch/?3185 Patch #3185] <tt>power_projection</tt> improvement, it now takes in account future ToD and time areas, I also cleaned the code a bit (task from the [[EasyCoding]] page.)<br />
*'''(WB)''' [https://gna.org/patch/?3201 Patch #3201] Make leader unable to move when invalidating a planned recall (fixes [https://gna.org/bugs/?19581 Bug #19581] that I found reading the whiteboard code.)<br />
<br />
===3) Communication skills===<br />
====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.====<br />
I have studied one term in London last winter, so, my level is good enough to understand and to be understood, don't expect an error-free essay from me though. :)<br />
<br />
====3.2) What spoken languages are you fluent in?====<br />
French and English.<br />
<br />
====3.3) Are you good at interacting with other players? Our developer community is friendly, but the player community can be a bit rough.====<br />
I'm a really calm person, I always take my time to answer messages. Otherwise, I'm ignoring flamers, I think it's the best to do.<br />
<br />
====3.4) Do you give constructive advice?====<br />
I try to.<br />
<br />
====3.5) Do you receive advice well?====<br />
Well, I enjoy receiving advices and learning, otherwise I wouldn't be here. :)<br />
<br />
====3.6) Are you good at sorting useful criticisms from useless ones?====<br />
I think most criticisms are useful, I'm used to the Internet though, troll don't ambush me.<br />
<br />
====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====<br />
It depends of what have to be done, the bigger the work is the more it has to be discussed. However if my proposal is retained, I might be a bit more scared of doing something bad in the beginning, so I might discuss a solution more than usual. :)<br />
<br />
===4) Project===<br />
====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?====<br />
<noinclude>'''Note: this page is a template, the answer to this question is a parameter. Please, refer to a proposal page.'''</noinclude>{{{1|}}}<br />
<br />
====4.2) If you have invented your own project, please describe the project and the scope.====<br />
<noinclude>'''Note: this page is a template, the answer to this question is a parameter. Please, refer to a proposal page.'''</noinclude>{{{2|}}}<br />
<br />
====4.3) Why did you choose this project?====<br />
<noinclude>'''Note: this page is a template, the answer to this question is a parameter. Please, refer to a proposal page.'''</noinclude>{{{3|}}}<br />
<br />
====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".====<br />
<noinclude>'''Note: this page is a template, the answer to this question is a parameter. Please, refer to a proposal page.'''</noinclude>{{{4|}}}<br />
<br />
====4.5) Include as much technical detail about your implementation as you can====<br />
<noinclude>'''Note: this page is a template, the answer to this question is a parameter. Please, refer to a proposal page.'''</noinclude>{{{5|}}}<br />
<br />
====4.6) What do you expect to gain from this project?====<br />
<noinclude>'''Note: this page is a template, the answer to this question is a parameter. Please, refer to a proposal page.'''</noinclude>{{{6|}}}<br />
<br />
====4.7) What would make you stay in the Wesnoth community after the conclusion of SOC?====<br />
<noinclude>'''Note: this page is a template, the answer to this question is a parameter. Please, refer to a proposal page.'''</noinclude>{{{7|}}}<br />
<br />
===5) Practical considerations===<br />
====5.1) Are you familiar with any of the following tools or languages?====<br />
*Subversion<br />
:I've already used it, but I've opted for git instead.<br />
*C++ (language used for all the normal source code)<br />
:I'm a big fan. I follow the WG21 publications and I often read comp.std.c++ and comp.lang.c++.moderated.<br />
*STL, Boost, Sdl (C++ libraries used by Wesnoth)<br />
:I'm of course used to the stdlib (not to all addition of C++11 though). I'm not familiar with all Boost (I don't have enough brain for this). But I have often used the parts of Boost that's are now (more or less) in the C++11 stdlib and the MPL. I also used a bit Asio, Filesystem and Phoenix (for being the most WTF library), and some other small libraries like Program Option and Range. I never worked on a project using the SDL, I'm not a big GUI user.<br />
*Python (optional, mainly used for tools)<br />
:Not really, no, really basic.<br />
*build environments (eg cmake/scons)<br />
:I've already wrote some CMakeList.txt, but I never worked with nor used scons.<br />
*WML (the wesnoth specific scenario language)<br />
:I wrote a [[User:Ejls/Vim|Vim syntax]] file for it, so I'm already a bit familiar with it. I'm missing practice though.<br />
*Lua (used in combination with WML to create scenarios)<br />
:I'm familiar with it, not as much as C++ but I already used it as a scripting language for an (annoying) IRC bot I wrote. I'm not familiar with its integration in Wesnoth though.<br />
<br />
====5.2) Which tools do you normally use for development? Why do you use them?====<br />
Vim and Unix tools, Perl for big stuff. They are the most productive tools for me, I'm used to them. I'm coding with a laptop under OpenBSD (with gcc 4.2). I also compile Wesnoth on a Debian server (with gcc 4.6), but the X over ssh is a bit slow sometimes. Finally, I temporally have a laptop with FreeBSD 9.0.<br />
<br />
====5.3) What programming languages are you fluent in?====<br />
I'm good in C++, C, Lua, Perl and VimScript. I've a lack of practice in Java, Caml, Scheme, NetLogo, CLIPS and AiML (all of them learnt during my studies). On a different note, I like brainfuck, befunge, whitespace and golfscript.<br />
<br />
====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!====<br />
If you can't join me by email or on IRC, I'm probably dead but sometimes it's easier to speak than to write so I'll include my phone number in my application.</div>Ejlshttps://wiki.wesnoth.org/index.php?title=Soc2012_Borgrumm_Defensive_AI&diff=46002Soc2012 Borgrumm Defensive AI2012-04-01T20:16:44Z<p>Ejls: Moved to the good category</p>
<hr />
<div>{{SoC2012Student}}<br />
[[Category:SoC_Ideas_AI_Defense_Strategies_2012]]<br />
<br />
=Description=<br />
<h4>Christopher Conway - Defensive AI </h4><br />
My goal is to develop an AI which is capable of “total defense” behavior, as opposed to the current aggressive AI. It would allow for the AI to function in scenarios like controlled retreats, unit escort, or holding a given area while minimizing unit loss.<br />
<br />
=Proposal Details=<br />
My proposal is to develop an AI which is capable of defensive scenarios. The AI would have different behavior for scenarios such as defending an area, escorting a unit to a given goal, or simply a more defensive version of the current regular AI. Some common behavior in any defensive AI would be to:<br />
*Withdraw wounded units out of harms way, preferably to a place where they can be healed.<br />
*Form defensive lines to minimize the threat to more fragile units<br />
*Alter behavior to take advantage of the map and terrain<br />
*Minimize unit loss, and prioritize the preservation of more experienced/expensive units<br />
<br />
=IRC=<br />
Borgrumm<br />
<br />
=Questionnaire=<br />
<br />
<br />
1) Basics<br />
<br />
1.1) Write a small introduction to yourself.<br />
<br />
My name is Christopher Conway. I'm a Computer Science major, and I'm currently in my third year of study at the University of Arizona.<br />
<br />
1.2) State your preferred email address.<br />
<br />
christopherconway@comcast.net<br />
<br />
1.3) If you have chosen a nick for IRC and Wesnoth forums, what is it?<br />
<br />
Borgrumm.<br />
<br />
1.4) Why do you want to participate in summer of code?<br />
<br />
I'm looking to get experience with professional work that relates to my area of education. I'm also especially interested in work that involves gaming, since that's where I want to end up after I graduate, and I’ve enjoyed the work on AIs I’ve done in the past.<br />
<br />
1.5) What are you studying, subject, level and school? <br />
<br />
I'm studying Computer Science at the University of Arizona. I'm currently in my 3rd year of study, and I'm on track to graduate in May 2013.<br />
<br />
1.6) What country are you from, at what time are you most likely to be able to join IRC?<br />
<br />
I'm from the United States, in Arizona. My daily schedule for the summer isn't nailed down yet, but 5:00 PM - 1:00 AM GMT (10 AM – 6 PM my time) is probably when I'd be most active.<br />
<br />
1.7) Do you have other commitments for the summer period ? Do you plan to take any vacations ? If yes, when.<br />
<br />
I don't currently have any other summer commitments, and have no vacation plans this summer.<br />
<br />
2) Experience<br />
<br />
2.1) What programs/software have you worked on before?<br />
<br />
I haven't done any professional programming yet, but I've done projects in Java, C, Ruby, Haskell, and Prolog, as well as some scripting. Some of the school projects I've worked on include:<br />
<br />
*Multiple games in Java, including a text-based MUD, a simplified version of Risk, and a strategy game with gameplay inspired by the Megaman: Battle Network series, all of which included AI work<br />
*Complex data structures in Java, such as AVL and 2-3-4 trees, and others in C, such as a 3-D orthogonal list.<br />
*Some basic AI work in C<br />
*Experience with threads in java<br />
*Some work on an OS in C<br />
*A plagiarism checker in Haskell, as well as other mathematical functions<br />
*Basic database work in Prolog, including some linguistics-based work<br />
*A social networking-inspired database program in Ruby<br />
<br />
2.2) Have you developed software in a team environment before? (As opposed to hacking on something on your own)<br />
<br />
Yes; some of my work in Haskell, Ruby, and Prolog was done in pairs. My OS work has also been in pairs, and the MUD in Java was done in a group of four.<br />
<br />
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?<br />
<br />
This is my first time participating in GSoC.<br />
<br />
2.4) Are you already involved with any open source development projects? If yes, please describe the project and the scope of your involvement.<br />
<br />
I am not currently involved in any.<br />
<br />
2.5) Gaming experience - Are you a gamer?<br />
<br />
Definitely.<br />
<br />
2.5.1) What type of gamer are you?<br />
<br />
I’m generally a single-player gamer, though I have played some MMOs and competitive games like Starcraft 2 and League of Legends.<br />
<br />
2.5.2) What type of games? <br />
<br />
My favorite games are RPGs, followed closely by strategy games. I prefer games where I have to think in order to win, as opposed to more twitch-based games like most FPSs. My favorite games are Planescape Torment, Baldur’s Gate 2, and older strategy games like Final Fantasy Tactics and the Tactics Ogre series. Some more recent games I’ve liked are The Witcher 2 and just about any RPG to come out of Atlus.<br />
<br />
2.5.3) What type of opponents do you prefer? <br />
<br />
I generally prefer challenging opponents. Games get boring too fast if I’m always winning.<br />
<br />
2.5.4) Are you more interested in story or gameplay?<br />
<br />
I’m interested in both, though I generally place more emphasis on story. I’ll play through poor gameplay if the story grips me, but I’m much less forgiving when it comes to a boring story or characters.<br />
<br />
2.5.5) Have you played Wesnoth? If so, tell us roughly for how long and whether you lean towards single player or multiplayer.<br />
<br />
I first found Battle for Wesnoth last summer, while looking for interesting games to play on IndieDB; I played the tutorial and a couple of the campaigns, and enjoyed it a lot, until school started up again and I got distracted by schoolwork and other games. I recently started playing it again. I lean strongly towards the single player, and have yet to try the multiplayer, though that’s something I’d like to devote some time towards once the semester ends.<br />
<br />
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.<br />
<br />
I have not contributed any patches to Wesnoth.<br />
<br />
<br />
3) Communication skills<br />
<br />
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.<br />
<br />
I am a native English speaker, and I’m completely fluent in written English. <br />
<br />
3.2) What spoken languages are you fluent in?<br />
<br />
Just English. I know some Spanish, enough to generally get the gist of what people are saying, but not enough to communicate effectively.<br />
<br />
3.3) Are you good at interacting with other players? Our developer community is friendly, but the player community can be a bit rough.<br />
<br />
I’m generally good at interacting with other players, including in competitive communities like Starcraft or League of Legends.<br />
<br />
3.4) Do you give constructive advice? <br />
<br />
Yes, whenever I feel I have something to contribute. <br />
<br />
3.5) Do you receive advice well? <br />
<br />
Yes. I like getting feedback on ways I can improve my work, and usually get something helpful out of any advice, even if I don’t feel that the advice itself is specifically helpful.<br />
<br />
3.6) Are you good at sorting useful criticisms from useless ones?<br />
<br />
To my knowledge, yes. I generally consider criticism in the context of what I’m trying to achieve, and decide whether or not it’ll improve my work before trying to follow it.<br />
<br />
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 wants.<br />
<br />
I prefer to get a general guideline of what I’m going to do in my head, start coding early, and make changes as I go and as the project demands. I’m not afraid to scrap my work if it doesn’t turn out to work quite right.<br />
<br />
4) Project<br />
<br />
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?<br />
<br />
I chose the Defensive AI project from the list.<br />
<br />
4.2) If you have invented your own project, please describe the project and the scope.<br />
<br />
I haven’t. <br />
<br />
4.3) Why did you choose this project?<br />
<br />
I’m interested in going into gaming on a professional level. In addition, in my work on games in school, I’ve found that the parts I enjoy the most are working on GUIs and AI design. This project seems like the kind of thing that’s not only good work experience, but something that I’d genuinely enjoy working on.<br />
<br />
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".<br />
<br />
The first thing I would do is try to implement some of the simpler defensive tactics, like withdrawing units for healing and using stronger units to cover for more vulnerable ones like healers, as well as researching other effective defensive strategies in the community. I would try to have a functional defensive AI ready by the mid-term evaluations in July, though it probably wouldn’t be good enough for a final release at this point.<br />
<br />
In the remaining weeks, I’d test the AI extensively, and try to improve and refine its tactics as much as possible. This is also when I would try to implement more reactionary tactics, like keeping as far away from the trees as possible when fighting elves, or isolating and focusing down enemy units more likely to pose a threat of breaking through the AI’s defenses, or other tactics that depend on what the opponent is using over more concrete things like the terrain.<br />
<br />
4.5) Include as much technical detail about your implementation as you can<br />
<br />
Some of the initial goals of the AI would be to:<br />
*Pull damaged units away from possible enemy attacks, preferably to areas where they can be healed.<br />
*Group units in such a way that more fragile units and support units have as few avenues of enemy attack as possible<br />
*Alter behavior based on the map; for instance, elves move through trees wherever possible, orcs behave more aggressively at night, etc.<br />
*Alter behavior based on enemy playstyle; for instance, if the player has more mounted units, try to engage them in forests; pick off lone units; etc.<br />
*Different types of AI behaviors depending on the scenario: for instance, a defensive retreat with the goal to get a certain unit to a set destination would have a different behavior than a scenario in which a certain area needs to be defended.<br />
<br />
4.6) What do you expect to gain from this project?<br />
<br />
I expect to gain a better understanding of how AIs work in games, as well as some good professional experience.<br />
<br />
4.7) What would make you stay in the Wesnoth community after the conclusion of SOC? <br />
<br />
From what I’ve played, Wesnoth seems like it would be a fun game to continue working on even without SOC. After AI work, I think I’d be very interested in designing a campaign.<br />
<br />
5) Practical considerations<br />
<br />
5.1) Are you familiar with any of the following tools or languages?<br />
<br />
I am somewhat familiar with both C++ and Python, though I haven’t used either in any large projects. I’m not familiar with any of the other tools or languages.<br />
<br />
5.2) Which tools do you normally use for development? Why do you use them?<br />
<br />
I use Eclipse for both Java and C, mainly because I prefer the interface to other tools I’ve tried.<br />
<br />
5.3) What programming languages are you fluent in?<br />
<br />
Java, C, Haskell, Prolog, Ruby<br />
<br />
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!<br />
<br />
I have no problem talking over the phone or over Skype, or any other chat software.</div>Ejlshttps://wiki.wesnoth.org/index.php?title=User_talk:MathPlayer&diff=46000User talk:MathPlayer2012-04-01T18:39:13Z<p>Ejls: Leaving a note explaining my last edit</p>
<hr />
<div>==GSoC 2012 Proposal==<br />
Hey, welcome!<br />
<br />
I commented out the two first lines in your proposal page, this removed your page from the list in [[SummerOfCodeIdeas]]. Since you didn't filled the proposal, it was messing up the list.<br />
<br />
Don't forget to remove the comment markers (&lt;!-- and --&gt;) after filling your proposal! :)<br />
<br />
<span class="smallcaps" style="font-variant:small-caps;">[[User:Ejls|éjls]]<sup>[[User_talk:Ejls|t]][[Special:Contributions/Ejls|c]]</sup></span> 18:39, 1 April 2012 (UTC)</div>Ejlshttps://wiki.wesnoth.org/index.php?title=User:MathPlayer&diff=45999User:MathPlayer2012-04-01T18:29:57Z<p>Ejls: Not yet filled, removing it from SummerOfCodeIdeas</p>
<hr />
<div><!--{{SoC2012Student}}<br />
[[Category:SoC_Ideas_Your_Own_Ideas2012]]--><br />
<br />
=Description=<br />
<h4>Bogdan Popescu </h4><br />
TODO: Write a small (1-4 sentences) description of your proposal here.<br />
<br />
TODO: Add more first-level sections to detail your proposal<br />
<br />
=IRC=<br />
put ONLY your irc nickname in there. in case of alternate nicks, separate by ,<br />
<br />
Example content of this section: "user" "user1, user2"<br />
<br />
=Questionnaire=<br />
TODO: fill out this questionnaire<br />
[[SoC_Information_for_Google#Does your organization have an application template you would like to see students use?]]</div>Ejlshttps://wiki.wesnoth.org/index.php?title=User:Ejls/GSoC_2012/Whiteboard_Backend_Refactoring&diff=45971User:Ejls/GSoC 2012/Whiteboard Backend Refactoring2012-04-01T02:14:08Z<p>Ejls: ToC update</p>
<hr />
<div><!--<br />
Excuse the heavy wikitext, I tried to make it as readable as possible and I put a lot of comments.<br />
-->__NOTOC__<!--<br />
-->__NOEDITSECTION__<!--<br />
-->{{SoC2012Student}}<!--<br />
-->[[Category:SoC_Ideas_Whiteboard_Backend_Refactoring_2012]]<!--<br />
-->'''''Note: This proposal is in construction, if you have any remark, please drop me a line on IRC or on the [[{{TALKPAGENAME}}|talk page]].'''''<br /><br /><br />
<br />
<!--***********************************************************************<br />
* * Table of Content * *<br />
* ******************** *<br />
* *<br />
* WARNING: don't forget to add a TOC entry when adding a new section. *<br />
***********************************************************************--><br />
{|style="background:#FAF3E9;margin:none;padding:5px;border:3px double #AAA;-moz-border-radius:20px 5px 20px 5px;-webkit-border-radius:20px 5px 20px 5px;border-radius:20px 5px 20px 5px;"<br />
|-<br />
| style="text-align: center; padding: 0px 10px 5px 10px;"|'''Content'''<hr /><br />
|-<br />
| style="text-align: left; padding:0px 10px 10px 10px;"|<br />
[[#Description|Description]]<br /><br />
[[#Contact|Contact]]<br /><br />
[[#SoC Application|SoC Application]]<br /><br />
[[#Questionnaire|Questionnaire]]<br /><br />
:[[#1) Basics|1 - Basics]]<br /><br />
:[[#2) Experience|2 - Experience]]<br /><br />
:[[#3) Communication skills|3 - Communication skills]]<br /><br />
:[[#4) Project|4 - Project]]<br /><br />
:[[#5) Practical considerations|5 - Practical considerations]]<br /><br />
[[#Proposal|Proposal]]<br /><br />
:[[#The problems|The problems]]<br /><br />
:[[#side_actions|<tt>side_actions</tt> refactoring]]<br /><br />
::[[#side_actions.situation|The current situation]]<br /><br />
::[[#side_actions.idea|The idea]]<br /><br />
::[[#side_actions.implementation|Implementation details]]<br /><br />
:::[[#side_actions.containers|Choice of the containers]]<br /><br />
:::[[#side_actions.example|Example]]<br /><br />
:[[#visitorhier|Visitor hierarchy refactoring]]<br /><br />
::[[#visitorhier.situation|The current situation]]<br /><br />
::[[#visitorhier.idea|The idea]]<br /><br />
::[[#visitorhier.implementation|Implementation details]]<br /><br />
:::[[#visitorhier.example|Example]]<br /><br />
:[[#mapbuilder|Merging of the validation process into <tt>mapbuilder</tt>]]<br /><br />
::[[#mapbuilder.situation|The current situation]]<br /><br />
::[[#mapbuilder.idea|The idea]]<br /><br />
::[[#mapbuilder.implementation|Implementation details]]<br /><br />
:::[[#mapbuilder.example|Example]]<br /><br />
:[[#polishing|Polishing]]<br /><br />
:[[#designdoc|Design document]]<br /><br />
:[[#Timeline|Timeline]]<br /><br />
|}<br />
<br />
<!--***********************************************************************<br />
* * Description * *<br />
* *************** *<br />
* *<br />
* This section is inserted in the SummerOfCodeIdeas page. It contains *<br />
* only a header of level 4 and a small paragraph summing up the *<br />
* proposal. *<br />
***********************************************************************--><br />
==Description==<br />
=====Étienne Simon - Whiteboard backend polishing=====<br />
My project is to make the whiteboard code cleaner and to redesign small parts of it to speed it up. Apart from the visitor hierarchy refactoring, the global design of the whiteboard won't be changed, each part will be reviewed individually. I'm not only planning to improve the whiteboard backend, but also to document the overall design and each part of it as well as to write a wide variety of test to improve its stability.<!--<br />
--><br />
<!--***********************************************************************<br />
* * SoC Application * *<br />
* ******************* *<br />
* *<br />
* This section affect the SummerOfCodeIdeas page, if it contains the *<br />
* text "Submitted to google", the application will appear in the *<br />
* "Student proposals submitted both to wiki and google" section, *<br />
* otherwise it'll appear in the "Student proposals not submitted to *<br />
* google" section. *<br />
***********************************************************************--><br />
==SoC Application==<br />
Submitted to google<!--<br />
--><br />
<!--***********************************************************************<br />
* * Contact * *<br />
* *********** *<br />
* *<br />
* The IRC subsection is inserted in the SummerOfCodeIdeas page. It *<br />
* must only contain the IRC nick identifying the author. *<br />
***********************************************************************--><br />
==Contact==<br />
{|<br />
|-<br />
|<br />
=====IRC=====<br />
<span style="color:#3F475E;">ejls </span><br />
=====Email=====<br />
Address at gmail dot com: etienne.jl.simon<br />
| style="width:10em;" |<br />
|<br />
=====Forum=====<br />
ejls<br />
=====Gna=====<br />
ejls<br />
|}<br />
<br />
<!--***********************************************************************<br />
* * Questionnaire * *<br />
* ***************** *<br />
* *<br />
* Although I'm submitting only one application (and so only one *<br />
* questionnaire), I thought it was more elegant to make the *<br />
* questionnaire page reusable. Which explain why it's a template. *<br />
* Like I wrote in the Questionnaire subpage, the argument to this *<br />
* template are the answer to the proposal-specific questions. I order *<br />
* to make the sources more comprehensible, I wrote the corresponding *<br />
* question in comments at the beginning of each parameter. *<br />
***********************************************************************--><br />
{{User:Ejls/GSoC 2012/Questionnaire<br />
|<!-- 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? --><br />
''This is a summary, more details can be found [http://wiki.wesnoth.org/User:Ejls/GSoC%202012/Whiteboard%20Backend%20Refactoring#Proposal here].''<br />
<br />
I have chosen [[SoC Ideas Whiteboard Backend Refactoring 2012]]. This project is the only one not adding any feature for the user, the main goal is to refactor code, write test and documentation. It follows [http://wiki.wesnoth.org/GSoC-WesnothWhiteboard_Gabba gabba's project] and [http://wiki.wesnoth.org/User:Tschmitz tschmitz's project] on the whiteboard. Although it doesn't add any feature for the user in itself, I hope it'll help future development of the whiteboard.<!--<br />
-->|<!-- 4.2) If you have invented your own project, please describe the project and the scope. --><br />
I chose a project from the list, namely [[SoC Ideas Whiteboard Backend Refactoring 2012]]. C.f. above answer.<!--<br />
-->|<!-- 4.3) Why did you choose this project? --><br />
I liked the idea behind the whiteboard, I think it might be a big plus to Wesnoth. Furthermore, I liked how C++ is used in its code (especially the heavy use of SBRM). However it looks like the whiteboard is not widely used, and I would like to help changing that! :)<!--<br />
-->|<!-- 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". --><br />
''This is a summary, more details can be found [http://wiki.wesnoth.org/User:Ejls/GSoC%202012/Whiteboard%20Backend%20Refactoring#Timeline here].''<br />
<br />
I separated my summer in five phases:<br />
*Phase 0: Approach (4 weeks)<br />
::→ Start working on the design document. Start the ''polishing''.<br />
*Phase 1: <tt>side_actions</tt> refactoring (3 weeks)<br />
*Phase 2: Validator hierarchy refactoring (3 weeks)<br />
*Phase 3: Merging of the validation process into <tt>mapbuilder</tt> (3 weeks)<br />
*Phase 4: Finalisation (3 weeks)<br />
::→ Finish the design document. Finish the ''polishing''. Test. Test. Test.<!--<br />
-->|<!-- 4.5) Include as much technical detail about your implementation as you can --><br />
''This is a summary, more details can be found [http://wiki.wesnoth.org/User:Ejls/GSoC%202012/Whiteboard%20Backend%20Refactoring#Proposal here].''<br />
<br />
I separated my project in five tasks:<br />
;<tt>side_actions</tt> refactoring<br />
:Change of the underlying container, creation of new look up functions.<br />
;Visitor hierarchy refactoring<br />
:Replacement of the <tt>enable_visit_all</tt> by a new interface over all of the <tt>side_actions</tt> objects.<br />
;Merging of the validation process into <tt>mapbuilder</tt><br />
:Deletion of the <tt>validate_visitor</tt> class, injection of its code and other validation code from the <tt>action</tt> hierarchy into <tt>mapbuilder</tt>.<br />
;Polishing<br />
:Code uniformisation, small improvements.<br />
;Design document<br />
:Documentation of the global whiteboard design.<!--<br />
-->|<!-- 4.6) What do you expect to gain from this project? --><br />
I hope it'll help me to join the open source developer community. Actually, the preparation of this proposal already helped me a lot, for example my first patch got committed, it wasn't a big patch, but it was my first step of a (I hope) long path. :) So, I hope to continue learning to walk with the wesnoth community (sorry for the silly metaphor.)<!--<br />
-->|<!-- 4.7) What would make you stay in the Wesnoth community after the conclusion of SOC? --><br />
If my work is appreciated, I would rather ask: what would make me leave the Wesnoth community?.<!--<br />
-->}}<br />
<br />
<!--***********************************************************************<br />
* * Proposal * *<br />
* ************ *<br />
* *<br />
* Finally, my proposal. ;) *<br />
***********************************************************************--><br />
==Proposal==<br />
===The problems===<br />
In the [[SoC_Ideas_Whiteboard_Backend_Refactoring_2012|Whiteboard Backend Refactoring idea page]], several problems are listed, here is how I'm planning to fix them:<br />
{| style="border:1px dashed #AAA;border-collapse:collapse;"<br />
|-<br />
!style="border:1px dotted #AAA;padding:5px;"|Problem<br />
!style="border:1px dotted #AAA;padding:5px;"|Solution<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|<tt>side_actions</tt> complexity<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#side_actions|<tt>side_actions</tt> refactoring]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|Redundancy between <tt>mapbuilder</tt> and <tt>validate_visitor</tt><br />
|style="border:1px dotted #AAA;padding:5px;"|[[#mapbuilder|Merging of the validation process into <tt>mapbuilder</tt>]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|Highlighter slowness<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#side_actions|<tt>side_actions</tt> refactoring]] and [[#visitorhier|Visitor hierarchy refactoring]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|Friend classes vs everything in the action classes<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#visitorhier|Visitor hierarchy refactoring]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|Unit pointer recovery uniformisation<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#polishing|Polishing]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|<tt>boost::dynamic_pointer_cast</tt> vs simple numeric id<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#polishing|Polishing]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|Documentation<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#designdoc|Design document]]<br />
|}<br />
<br />
===<span id="side_actions"><tt>side_actions</tt> refactoring</span>===<br />
====<span id="side_actions.situation">The current situation</span>====<br />
The current implementation of <tt>side_actions</tt> use a <tt>std::deque&lt;std::deque&lt;action_ptr&gt;&gt;</tt>.<br />
In order to use it, iterators have been defined over it (<tt>side_actions::iterator</tt> and the three const and revert variants).<br />
These “flattening” iterators let users of <tt>side_actions</tt> iterate over all the planned actions, they are performing the ''zip'' operation on the fly.<br />
<br />
Furthermore, some queries like <tt>side_actions::find_first_action_of</tt> are linear in the number of action.<br />
<br />
====<span id="side_actions.idea">The idea</span>====<br />
To simplify the code, I propose to keep the action set zipped. The container's iterators will then be usable directly. In order to delimit turns, a second container will have to keep a sequence of iterators pointing to the first action of each turn.<br />
<br />
For example, let's say eight actions are planned: five for this turn, two for the next turn and one for the turn after. Three iterators will be kept to delimit turns. Here is a proof that I can't use gimp which also show the idea:<br />
http://epsilon012.free.fr/GSoC%202012/side_actions%20idea.png<br />
<br />
Of course another problem emerge: the sequence of iterator has to be kept in sync with the sequence of action.<br />
<br />
Finally, the current implementation gives access to the <tt>action_ptr</tt> only in sequence, in order to speed up different way of querying action (e.g. by hex, by unit's id), I propose to build several indexes on the action set.<br />
<br />
====<span id="side_actions.implementation">Implementation details</span>====<br />
Let's name these containers <tt>actions_</tt> and <tt>turn_beginnings_</tt>.<br />
<br />
The whiteboard have the following invariant: an empty turn (a turn without planned action) can't be followed by a non-empty turn (with at least one planned action). It means that <code>distance(turn_beginnings_[i], turn_beginnings_[i+1])&gt;0</code>, and so we can unambiguously determine the turn number of each action.<br />
<br />
Also, note that except when <tt>actions_.empty()</tt> : <tt>turn_beginnings_.front()==actions_.begin()</tt>.<br />
<br />
=====<span id="side_actions.containers">Choice of the containers</span>=====<br />
<tt>std::deque</tt> seems to be the perfect container for <tt>turn_beginnings_</tt>. It'll allow random access and we need to add/remove new turns only at the extremities.<br />
<br />
On the other hand, <tt>actions_</tt> need two proprieties:<br />
*Allow fast chronological iteration<br />
*Stable iterators<br />
*Allow fast lookup on different indexes<br />
I propose to use a <tt>boost::multi_index_container</tt>, this container is part of the library [http://www.boost.org/doc/libs/1_49_0/libs/multi_index Boost.MultiIndex] which is in Boost since version 1.32. It allows the construction of several indexes on the same set of object.<br />
<br />
There is however one problem linked to the use of the <tt>boost::multi_index::random_access</tt> index: insertion and deletion are in linear time when their are not done at the extremities.<br />
<br />
So, the new members should be:<br />
namespace bmi = boost::multi_index;<br />
typedef bmi::multi_index_container<<br />
action_ptr,<br />
bmi::indexed_by<<br />
bmi::random_access<bmi::tag<chronological> >,<br />
bmi::hashed_non_unique<bmi::tag<by_unit>, bmi::const_mem_fun<action,size_t,&action::get_unit_id> >,<br />
bmi::hashed_non_unique<bmi::tag<by_hex>, bmi::const_mem_fun<action,size_t,&action::get_hex>><br />
><br />
> action_set;<br />
typedef action_set::iterator iterator;<br />
<br />
action_set actions_;<br />
std::deque<iterator> turn_beginnings_;<br />
<br />
This suppose two new pure virtual function in <tt>action</tt>: <tt>get_unit_id</tt> and <tt>get_hex</tt>.<br />
<br />
Using action's attribute as key brings another drawback: we must notify the <tt>multi_index_container</tt> when we modify a key.<br />
However, the two used keys here (the unit's id and the hex) are never modified in the <tt>action</tt> hierarchy.<br />
<br />
This definition is here to give an idea, in practice other indexes will have to be built (e.g. an index on ''secondary hex'' which could be the source hex in <tt>move</tt>.)<br />
Note that this doesn't necessarily means a new pure virtual function in <tt>action</tt>, a key extractor can be defined to let <tt>action</tt> as it is and use ''RTTI'' instead (this might not be clever though.)<br />
<br />
=====<span id="side_actions.example">Example</span>=====<br />
Here are three functions rewritten with this new design. Note that <tt>side_actions::iterator</tt> is the one defined above.<br />
side_actions::iterator side_actions::end_turn(size_t turn_num){<br />
if(turn_num+1>=turn_beginnings_.size())<br />
return actions_.end();<br />
else<br />
return turn_beginnings_[turn_num+1];<br />
}<br />
<br />
side_actions::iterator side_actions::raw_enqueue(size_t turn_num, action_ptr act){<br />
assert(turn_num <= turn_beginnings_.size());<br />
<br />
iterator new_action = actions_.insert(end_turn(turn_num), act).first;<br />
<br />
if(turn_num >= turn_beginnings_.size())<br />
turn_beginnings_.push_back(new_action);<br />
<br />
return new_action;<br />
}<br />
<br />
side_actions::find_first_action_of(unit const* unit, side_actions::iterator start_position){<br />
// First we get all the action of this unit<br />
typedef action_set::index<by_unit>::type::iterator unit_iterator;<br />
std::pair<unit_iterator, unit_iterator> act = actions_.get<by_unit>().equal_range(unit->underlying_id());<br />
<br />
// Then we find the first of them (chronologically) after start_position<br />
iterator first = actions_.end();<br />
for(unit_iterator it = act.first; it != act.second; ++it){<br />
iterator chrono_it = actions_.project<chronological>(it);<br />
if(chrono_it < first && chrono_it > start_position)<br />
first = chrono_it;<br />
}<br />
return first;<br />
}<br />
<br />
===<span id="visitorhier">Visitor hierarchy refactoring</span>===<br />
====<span id="visitorhier.situation">The current situation</span>====<br />
The important classes and class templates of this hierarchy are:<br />
*'''<tt>visitor</tt>''' is the base class of the visitor hierarchy, it dispatches the calls to the derived classes.<br />
*'''<tt>enable_visit_all</tt>''' is actually an interface to the <tt>action_ptr</tt> objects of every single team.<br />
*'''<tt>action</tt>''' is the root class of the visitable hierarchy.<br />
<br />
Currently, when the visitor hierarchy needs to visit the visitable hierarchy, all the actions of every sides of every turn are visited using the function <tt>enable_visit_all::visit_all_helper</tt> (e.g. this function is called by <tt>highlight_visitor::find_main_highlight</tt> to find the action to highlight.)<br />
<br />
====<span id="visitorhier.idea">The idea</span>====<br />
I'm favorable to the maintain of the Visitor pattern, it segregates the different components nicely.<br />
I think the problem come from <tt>enable_visit_all</tt> and I would like to replace it with a class offering a more fine-grained access to the actions.<br />
For example, a look up by hex could be defined in this new structure and then used by <tt>highlight_visitor</tt>.<br />
Actually, most of the work of this new class will have to do is to redirect the calls to the <tt>side_actions</tt> (to one in particular or to all depending on the function).<br />
<br />
====<span id="visitorhier.implementation">Implementation details</span>====<br />
Let's name this interface <tt>action_inquirer</tt>, I'm not a particularly good English speaker, so if you have a better name in mind, let me know. :)<br />
<br />
The sole problem faced is to place <tt>action_inquirer</tt>, since it is mainly a proxy to a global resource (the <tt>side_actions</tt> of each team), it makes sense to place it directly in the <tt>wb</tt> namespace.<br />
<br />
=====<span id="visitorhier.example">Example</span>=====<br />
Here is an example function that would speed up <tt>highlight_visitor</tt>.<br />
action_ptr action_inquirer::action_at(map_location const &hex){<br />
side_actions::iterator result;<br />
foreach(team& side, *resources::teams){<br />
side_actions actions = side.get_side_actions();<br />
if((result = actions.find_action_at(hex)) != actions.end())<br />
return *result;<br />
}<br />
return action_ptr();<br />
}<br />
<br />
Note: the implementation of <tt>side_actions::find_action_at</tt> is similar to the one of <tt>side_actions::find_first_action_of</tt>.<br />
<br />
===<span id="mapbuilder">Merging of the validation process into <tt>mapbuilder</tt></span>===<br />
====<span id="mapbuilder.situation">The current situation</span>====<br />
Currently the validation process is separated from the mapbuilding process.<br />
However they are depending on each other.<br />
Indeed, to validate an action the previous actions have to be applied (by the mapbuilder), while in order to build the future state in the mapbuilder, the sequence of action have to be valid.<br />
<br />
====<span id="mapbuilder.idea">The idea</span>====<br />
Inject the validation process into <tt>mapbuilder</tt>. This is not limited to the merging of <tt>validate_visitor</tt> into <tt>mapbuilder</tt>, indeed some validity check are also done in the <tt>action</tt> hierarchy.<br />
<br />
====<span id="mapbuilder.implementation">Implementation details</span>====<br />
I'm still working on this.<br />
<br />
=====<span id="mapbuilder.example">Example</span>=====<br />
Idem.<br />
<br />
===<span id="polishing">Polishing</span>===<br />
Some inconsistencies are present in the code (e.g. the way units are referenced). Some other parts needs clean up or/and optimisation (e.g. usage of <tt>boost::dynamic_pointer_cast</tt>).<br />
<br />
The goal of this task is to find this kind of small problem and fix them.<br />
These two ones have been spotted by gabba, but I'm planning to add other small problems to this list as I found them.<br />
<br />
Also, they can be a good introduction to the code that's why I'm planning to start working on them before the GSoC start date.<br />
<br />
===<span id="designdoc">Design document</span>===<br />
This idea is inspired by the GUI2 design document present in the SVN.<br />
<br />
Doxygen documents the code at a function or class level.<br />
The goal is to write a documentation at the module level. That is a document describing the whiteboard design globally and not function-by-function.<br />
Actually it shouldn't duplicate what is in doxygen but complement it.<br />
This document could also include informations on how to extend the whiteboard to help future contributors.<br />
<br />
Where should this document go?<br />
*In doxygen<br />
:This makes sense since it's where most of the code documentation is.<br />
*In the wiki<br />
:This would make collaborative editing easier.<br />
<br />
If you have an opinion on this, let me know. :)<br />
<br />
===Timeline===<br />
Two of my five tasks are actually best done continuously: the design document and the polishing.<br />
Although I haven't clearly placed a week for them, I set two dates at which they should have been completed.<br />
<br />
Of course, the plan is not to have any delay and to finish each task early, however I have reserved two weeks (actually one week and a half) for unexpected delay.<br />
I named them "movable weeks", because they can move in my timeline if anything goes wrong. :)<br />
<br />
<!-- Wikitext hell 101 --><br />
{| style="border:1px dashed #AAA;border-collapse:collapse;"<br />
|-<br />
!style="border:1px dotted #AAA;padding:5px;"|Date<br />
!style="border:1px dotted #AAA;padding:5px;"|Week<br />
!style="border:1px dotted #AAA;padding:5px;"|Description<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''17/03 - 20/04''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''-11..-5''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Student application evaluation''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|17/03 - 20/04<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|-11..-5<br />
|style="border:1px dotted #AAA;padding:5px;"|Refine the proposal.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''23/04 - 20/05''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''-4..-1''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Community Bonding Period (4 weeks)''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|'''23/04 - 20/05'''<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|'''-4..-1'''<br />
|style="border:1px dotted #AAA;padding:5px;"|'''Phase 0: Approach'''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|23/04 - 20/05<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|-4..-1<br />
|style="border:1px dotted #AAA;padding:5px;"|Familiarise myself with the whiteboard, in the process start a draft of the design document.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|23/04 - 20/05<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|-4..-1<br />
|style="border:1px dotted #AAA;padding:5px;"|Start working on the ''polishing'' and on small parts of the whiteboard in order to gain commit access.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''21/05''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''0''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Start of GSoC''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|21/05 - 12/08<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|0..11<br />
|style="border:1px dotted #AAA;padding:5px;"|Continuously work on the design document and on the code polishing.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''21/05 - 15/07''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''0..7''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''First half term (8 weeks)''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|'''21/05 - 10/06'''<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|'''0..2'''<br />
|style="border:1px dotted #AAA;padding:5px;"|'''Phase 1: <tt>side_actions</tt> refactoring'''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|21/05 - 27/05<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|0<br />
|style="border:1px dotted #AAA;padding:5px;"|Prepare <tt>side_actions</tt> for the change. Add debug informations to the logs. Make the current iterators bidirectional.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|28/05 - 03/06<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|1<br />
|style="border:1px dotted #AAA;padding:5px;"|Change the underlying container and rewrite the associated functions.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|04/06 - 10/06<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|2<br />
|style="border:1px dotted #AAA;padding:5px;"|Debug, write unit test and documentation.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|'''11/06 - 01/07'''<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|'''3..5'''<br />
|style="border:1px dotted #AAA;padding:5px;"|'''Phase 2: Validator hierarchy refactoring'''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|11/06 - 17/06<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|3<br />
|style="border:1px dotted #AAA;padding:5px;"|Write the class <tt>action_inquirer</tt>.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|18/06 - 24/06<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|4<br />
|style="border:1px dotted #AAA;padding:5px;"|Replace the uses of <tt>enable_visit_all</tt> with the new interface. Then delete <tt>enable_visit_all</tt>.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|25/06 - 01/07<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|5<br />
|style="border:1px dotted #AAA;padding:5px;"|Debug, write unit test and documentation.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|'''02/07 - 22/07'''<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|'''6..8'''<br />
|style="border:1px dotted #AAA;padding:5px;"|'''Phase 3: Merging of the validation process into <tt>mapbuilder</tt>'''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|02/07 - 08/07<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|6<br />
|style="border:1px dotted #AAA;padding:5px;"|Merge <tt>validate_visitor</tt> into <tt>mapbuilder</tt>.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|09/07 - 15/07<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|7<br />
|style="border:1px dotted #AAA;padding:5px;"|Hunt down other validity check in the <tt>action</tt> hierarchy and move them to <tt>mapbuilder</tt>.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''13/07''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''7''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Mid-term evaluation''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''16/07 - 26/08''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''8..13''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Second half term (6 weeks)''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|16/07 - 22/07<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|8<br />
|style="border:1px dotted #AAA;padding:5px;"|Debug, write unit test and documentation.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|'''22/07 - 12/08'''<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|'''9..11'''<br />
|style="border:1px dotted #AAA;padding:5px;"|'''Phase 4: Finalisation'''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|22/07 - 29/07<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|9<br />
|style="border:1px dotted #AAA;padding:5px;"|Heavy testing week.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|30/07 - 05/08<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|10<br />
|style="border:1px dotted #AAA;padding:5px;"|Test, debug. Finish the ''polishing''.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|06/08 - 12/08<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|11<br />
|style="border:1px dotted #AAA;padding:5px;"|Test, debug. Finish the design document.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|13/08 - 19/08<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|12<br />
|style="border:1px dotted #AAA;padding:5px;"|Movable week.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|20/08 - 26/08<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|13<br />
|style="border:1px dotted #AAA;padding:5px;"|Movable week.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''24/08''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''13''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Final evaluation''<br />
|}</div>Ejlshttps://wiki.wesnoth.org/index.php?title=User:Ejls/GSoC_2012/Whiteboard_Backend_Refactoring&diff=45970User:Ejls/GSoC 2012/Whiteboard Backend Refactoring2012-04-01T02:11:30Z<p>Ejls: (more nicely)</p>
<hr />
<div><!--<br />
Excuse the heavy wikitext, I tried to make it as readable as possible and I put a lot of comments.<br />
-->__NOTOC__<!--<br />
-->__NOEDITSECTION__<!--<br />
-->{{SoC2012Student}}<!--<br />
-->[[Category:SoC_Ideas_Whiteboard_Backend_Refactoring_2012]]<!--<br />
-->'''''Note: This proposal is in construction, if you have any remark, please drop me a line on IRC or on the [[{{TALKPAGENAME}}|talk page]].'''''<br /><br /><br />
<br />
<!--***********************************************************************<br />
* * Table of Content * *<br />
* ******************** *<br />
* *<br />
* WARNING: don't forget to add a TOC entry when adding a new section. *<br />
***********************************************************************--><br />
{|style="background:#FAF3E9;margin:none;padding:5px;border:3px double #AAA;-moz-border-radius:20px 5px 20px 5px;-webkit-border-radius:20px 5px 20px 5px;border-radius:20px 5px 20px 5px;"<br />
|-<br />
| style="text-align: center; padding: 0px 10px 5px 10px;"|'''Content'''<hr /><br />
|-<br />
| style="text-align: left; padding:0px 10px 10px 10px;"|<br />
[[#Description|Description]]<br /><br />
[[#Contact|Contact]]<br /><br />
<!--[[#SoC Application|SoC Application]]<br /><br />
-->[[#Questionnaire|Questionnaire]]<br /><br />
:[[#1) Basics|1 - Basics]]<br /><br />
:[[#2) Experience|2 - Experience]]<br /><br />
:[[#3) Communication skills|3 - Communication skills]]<br /><br />
:[[#4) Project|4 - Project]]<br /><br />
:[[#5) Practical considerations|5 - Practical considerations]]<br /><br />
[[#Proposal|Proposal]]<br /><br />
:[[#The problems|The problems]]<br /><br />
:[[#side_actions|<tt>side_actions</tt> refactoring]]<br /><br />
::[[#side_actions.situation|The current situation]]<br /><br />
::[[#side_actions.idea|The idea]]<br /><br />
::[[#side_actions.implementation|Implementation details]]<br /><br />
:::[[#side_actions.containers|Choice of the containers]]<br /><br />
:::[[#side_actions.example|Example]]<br /><br />
:[[#visitorhier|Visitor hierarchy refactoring]]<br /><br />
::[[#visitorhier.situation|The current situation]]<br /><br />
::[[#visitorhier.idea|The idea]]<br /><br />
::[[#visitorhier.implementation|Implementation details]]<br /><br />
:::[[#visitorhier.example|Example]]<br /><br />
:[[#mapbuilder|Merging of the validation process into <tt>mapbuilder</tt>]]<br /><br />
::[[#mapbuilder.situation|The current situation]]<br /><br />
::[[#mapbuilder.idea|The idea]]<br /><br />
::[[#mapbuilder.implementation|Implementation details]]<br /><br />
:::[[#mapbuilder.example|Example]]<br /><br />
:[[#polishing|Polishing]]<br /><br />
:[[#designdoc|Design document]]<br /><br />
:[[#Timeline|Timeline]]<br /><br />
|}<br />
<br />
<!--***********************************************************************<br />
* * Description * *<br />
* *************** *<br />
* *<br />
* This section is inserted in the SummerOfCodeIdeas page. It contains *<br />
* only a header of level 4 and a small paragraph summing up the *<br />
* proposal. *<br />
***********************************************************************--><br />
==Description==<br />
=====Étienne Simon - Whiteboard backend polishing=====<br />
My project is to make the whiteboard code cleaner and to redesign small parts of it to speed it up. Apart from the visitor hierarchy refactoring, the global design of the whiteboard won't be changed, each part will be reviewed individually. I'm not only planning to improve the whiteboard backend, but also to document the overall design and each part of it as well as to write a wide variety of test to improve its stability.<!--<br />
--><br />
<!--***********************************************************************<br />
* * SoC Application * *<br />
* ******************* *<br />
* *<br />
* This section affect the SummerOfCodeIdeas page, if it contains the *<br />
* text "Submitted to google", the application will appear in the *<br />
* "Student proposals submitted both to wiki and google" section, *<br />
* otherwise it'll appear in the "Student proposals not submitted to *<br />
* google" section. *<br />
***********************************************************************--><br />
==SoC Application==<br />
Submitted to google<!--<br />
--><br />
<!--***********************************************************************<br />
* * Contact * *<br />
* *********** *<br />
* *<br />
* The IRC subsection is inserted in the SummerOfCodeIdeas page. It *<br />
* must only contain the IRC nick identifying the author. *<br />
***********************************************************************--><br />
==Contact==<br />
{|<br />
|-<br />
|<br />
=====IRC=====<br />
<span style="color:#3F475E;">ejls </span><br />
=====Email=====<br />
Address at gmail dot com: etienne.jl.simon<br />
| style="width:10em;" |<br />
|<br />
=====Forum=====<br />
ejls<br />
=====Gna=====<br />
ejls<br />
|}<br />
<br />
<!--***********************************************************************<br />
* * Questionnaire * *<br />
* ***************** *<br />
* *<br />
* Although I'm submitting only one application (and so only one *<br />
* questionnaire), I thought it was more elegant to make the *<br />
* questionnaire page reusable. Which explain why it's a template. *<br />
* Like I wrote in the Questionnaire subpage, the argument to this *<br />
* template are the answer to the proposal-specific questions. I order *<br />
* to make the sources more comprehensible, I wrote the corresponding *<br />
* question in comments at the beginning of each parameter. *<br />
***********************************************************************--><br />
{{User:Ejls/GSoC 2012/Questionnaire<br />
|<!-- 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? --><br />
''This is a summary, more details can be found [http://wiki.wesnoth.org/User:Ejls/GSoC%202012/Whiteboard%20Backend%20Refactoring#Proposal here].''<br />
<br />
I have chosen [[SoC Ideas Whiteboard Backend Refactoring 2012]]. This project is the only one not adding any feature for the user, the main goal is to refactor code, write test and documentation. It follows [http://wiki.wesnoth.org/GSoC-WesnothWhiteboard_Gabba gabba's project] and [http://wiki.wesnoth.org/User:Tschmitz tschmitz's project] on the whiteboard. Although it doesn't add any feature for the user in itself, I hope it'll help future development of the whiteboard.<!--<br />
-->|<!-- 4.2) If you have invented your own project, please describe the project and the scope. --><br />
I chose a project from the list, namely [[SoC Ideas Whiteboard Backend Refactoring 2012]]. C.f. above answer.<!--<br />
-->|<!-- 4.3) Why did you choose this project? --><br />
I liked the idea behind the whiteboard, I think it might be a big plus to Wesnoth. Furthermore, I liked how C++ is used in its code (especially the heavy use of SBRM). However it looks like the whiteboard is not widely used, and I would like to help changing that! :)<!--<br />
-->|<!-- 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". --><br />
''This is a summary, more details can be found [http://wiki.wesnoth.org/User:Ejls/GSoC%202012/Whiteboard%20Backend%20Refactoring#Timeline here].''<br />
<br />
I separated my summer in five phases:<br />
*Phase 0: Approach (4 weeks)<br />
::→ Start working on the design document. Start the ''polishing''.<br />
*Phase 1: <tt>side_actions</tt> refactoring (3 weeks)<br />
*Phase 2: Validator hierarchy refactoring (3 weeks)<br />
*Phase 3: Merging of the validation process into <tt>mapbuilder</tt> (3 weeks)<br />
*Phase 4: Finalisation (3 weeks)<br />
::→ Finish the design document. Finish the ''polishing''. Test. Test. Test.<!--<br />
-->|<!-- 4.5) Include as much technical detail about your implementation as you can --><br />
''This is a summary, more details can be found [http://wiki.wesnoth.org/User:Ejls/GSoC%202012/Whiteboard%20Backend%20Refactoring#Proposal here].''<br />
<br />
I separated my project in five tasks:<br />
;<tt>side_actions</tt> refactoring<br />
:Change of the underlying container, creation of new look up functions.<br />
;Visitor hierarchy refactoring<br />
:Replacement of the <tt>enable_visit_all</tt> by a new interface over all of the <tt>side_actions</tt> objects.<br />
;Merging of the validation process into <tt>mapbuilder</tt><br />
:Deletion of the <tt>validate_visitor</tt> class, injection of its code and other validation code from the <tt>action</tt> hierarchy into <tt>mapbuilder</tt>.<br />
;Polishing<br />
:Code uniformisation, small improvements.<br />
;Design document<br />
:Documentation of the global whiteboard design.<!--<br />
-->|<!-- 4.6) What do you expect to gain from this project? --><br />
I hope it'll help me to join the open source developer community. Actually, the preparation of this proposal already helped me a lot, for example my first patch got committed, it wasn't a big patch, but it was my first step of a (I hope) long path. :) So, I hope to continue learning to walk with the wesnoth community (sorry for the silly metaphor.)<!--<br />
-->|<!-- 4.7) What would make you stay in the Wesnoth community after the conclusion of SOC? --><br />
If my work is appreciated, I would rather ask: what would make me leave the Wesnoth community?.<!--<br />
-->}}<br />
<br />
<!--***********************************************************************<br />
* * Proposal * *<br />
* ************ *<br />
* *<br />
* Finally, my proposal. ;) *<br />
***********************************************************************--><br />
==Proposal==<br />
===The problems===<br />
In the [[SoC_Ideas_Whiteboard_Backend_Refactoring_2012|Whiteboard Backend Refactoring idea page]], several problems are listed, here is how I'm planning to fix them:<br />
{| style="border:1px dashed #AAA;border-collapse:collapse;"<br />
|-<br />
!style="border:1px dotted #AAA;padding:5px;"|Problem<br />
!style="border:1px dotted #AAA;padding:5px;"|Solution<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|<tt>side_actions</tt> complexity<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#side_actions|<tt>side_actions</tt> refactoring]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|Redundancy between <tt>mapbuilder</tt> and <tt>validate_visitor</tt><br />
|style="border:1px dotted #AAA;padding:5px;"|[[#mapbuilder|Merging of the validation process into <tt>mapbuilder</tt>]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|Highlighter slowness<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#side_actions|<tt>side_actions</tt> refactoring]] and [[#visitorhier|Visitor hierarchy refactoring]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|Friend classes vs everything in the action classes<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#visitorhier|Visitor hierarchy refactoring]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|Unit pointer recovery uniformisation<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#polishing|Polishing]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|<tt>boost::dynamic_pointer_cast</tt> vs simple numeric id<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#polishing|Polishing]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|Documentation<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#designdoc|Design document]]<br />
|}<br />
<br />
===<span id="side_actions"><tt>side_actions</tt> refactoring</span>===<br />
====<span id="side_actions.situation">The current situation</span>====<br />
The current implementation of <tt>side_actions</tt> use a <tt>std::deque&lt;std::deque&lt;action_ptr&gt;&gt;</tt>.<br />
In order to use it, iterators have been defined over it (<tt>side_actions::iterator</tt> and the three const and revert variants).<br />
These “flattening” iterators let users of <tt>side_actions</tt> iterate over all the planned actions, they are performing the ''zip'' operation on the fly.<br />
<br />
Furthermore, some queries like <tt>side_actions::find_first_action_of</tt> are linear in the number of action.<br />
<br />
====<span id="side_actions.idea">The idea</span>====<br />
To simplify the code, I propose to keep the action set zipped. The container's iterators will then be usable directly. In order to delimit turns, a second container will have to keep a sequence of iterators pointing to the first action of each turn.<br />
<br />
For example, let's say eight actions are planned: five for this turn, two for the next turn and one for the turn after. Three iterators will be kept to delimit turns. Here is a proof that I can't use gimp which also show the idea:<br />
http://epsilon012.free.fr/GSoC%202012/side_actions%20idea.png<br />
<br />
Of course another problem emerge: the sequence of iterator has to be kept in sync with the sequence of action.<br />
<br />
Finally, the current implementation gives access to the <tt>action_ptr</tt> only in sequence, in order to speed up different way of querying action (e.g. by hex, by unit's id), I propose to build several indexes on the action set.<br />
<br />
====<span id="side_actions.implementation">Implementation details</span>====<br />
Let's name these containers <tt>actions_</tt> and <tt>turn_beginnings_</tt>.<br />
<br />
The whiteboard have the following invariant: an empty turn (a turn without planned action) can't be followed by a non-empty turn (with at least one planned action). It means that <code>distance(turn_beginnings_[i], turn_beginnings_[i+1])&gt;0</code>, and so we can unambiguously determine the turn number of each action.<br />
<br />
Also, note that except when <tt>actions_.empty()</tt> : <tt>turn_beginnings_.front()==actions_.begin()</tt>.<br />
<br />
=====<span id="side_actions.containers">Choice of the containers</span>=====<br />
<tt>std::deque</tt> seems to be the perfect container for <tt>turn_beginnings_</tt>. It'll allow random access and we need to add/remove new turns only at the extremities.<br />
<br />
On the other hand, <tt>actions_</tt> need two proprieties:<br />
*Allow fast chronological iteration<br />
*Stable iterators<br />
*Allow fast lookup on different indexes<br />
I propose to use a <tt>boost::multi_index_container</tt>, this container is part of the library [http://www.boost.org/doc/libs/1_49_0/libs/multi_index Boost.MultiIndex] which is in Boost since version 1.32. It allows the construction of several indexes on the same set of object.<br />
<br />
There is however one problem linked to the use of the <tt>boost::multi_index::random_access</tt> index: insertion and deletion are in linear time when their are not done at the extremities.<br />
<br />
So, the new members should be:<br />
namespace bmi = boost::multi_index;<br />
typedef bmi::multi_index_container<<br />
action_ptr,<br />
bmi::indexed_by<<br />
bmi::random_access<bmi::tag<chronological> >,<br />
bmi::hashed_non_unique<bmi::tag<by_unit>, bmi::const_mem_fun<action,size_t,&action::get_unit_id> >,<br />
bmi::hashed_non_unique<bmi::tag<by_hex>, bmi::const_mem_fun<action,size_t,&action::get_hex>><br />
><br />
> action_set;<br />
typedef action_set::iterator iterator;<br />
<br />
action_set actions_;<br />
std::deque<iterator> turn_beginnings_;<br />
<br />
This suppose two new pure virtual function in <tt>action</tt>: <tt>get_unit_id</tt> and <tt>get_hex</tt>.<br />
<br />
Using action's attribute as key brings another drawback: we must notify the <tt>multi_index_container</tt> when we modify a key.<br />
However, the two used keys here (the unit's id and the hex) are never modified in the <tt>action</tt> hierarchy.<br />
<br />
This definition is here to give an idea, in practice other indexes will have to be built (e.g. an index on ''secondary hex'' which could be the source hex in <tt>move</tt>.)<br />
Note that this doesn't necessarily means a new pure virtual function in <tt>action</tt>, a key extractor can be defined to let <tt>action</tt> as it is and use ''RTTI'' instead (this might not be clever though.)<br />
<br />
=====<span id="side_actions.example">Example</span>=====<br />
Here are three functions rewritten with this new design. Note that <tt>side_actions::iterator</tt> is the one defined above.<br />
side_actions::iterator side_actions::end_turn(size_t turn_num){<br />
if(turn_num+1>=turn_beginnings_.size())<br />
return actions_.end();<br />
else<br />
return turn_beginnings_[turn_num+1];<br />
}<br />
<br />
side_actions::iterator side_actions::raw_enqueue(size_t turn_num, action_ptr act){<br />
assert(turn_num <= turn_beginnings_.size());<br />
<br />
iterator new_action = actions_.insert(end_turn(turn_num), act).first;<br />
<br />
if(turn_num >= turn_beginnings_.size())<br />
turn_beginnings_.push_back(new_action);<br />
<br />
return new_action;<br />
}<br />
<br />
side_actions::find_first_action_of(unit const* unit, side_actions::iterator start_position){<br />
// First we get all the action of this unit<br />
typedef action_set::index<by_unit>::type::iterator unit_iterator;<br />
std::pair<unit_iterator, unit_iterator> act = actions_.get<by_unit>().equal_range(unit->underlying_id());<br />
<br />
// Then we find the first of them (chronologically) after start_position<br />
iterator first = actions_.end();<br />
for(unit_iterator it = act.first; it != act.second; ++it){<br />
iterator chrono_it = actions_.project<chronological>(it);<br />
if(chrono_it < first && chrono_it > start_position)<br />
first = chrono_it;<br />
}<br />
return first;<br />
}<br />
<br />
===<span id="visitorhier">Visitor hierarchy refactoring</span>===<br />
====<span id="visitorhier.situation">The current situation</span>====<br />
The important classes and class templates of this hierarchy are:<br />
*'''<tt>visitor</tt>''' is the base class of the visitor hierarchy, it dispatches the calls to the derived classes.<br />
*'''<tt>enable_visit_all</tt>''' is actually an interface to the <tt>action_ptr</tt> objects of every single team.<br />
*'''<tt>action</tt>''' is the root class of the visitable hierarchy.<br />
<br />
Currently, when the visitor hierarchy needs to visit the visitable hierarchy, all the actions of every sides of every turn are visited using the function <tt>enable_visit_all::visit_all_helper</tt> (e.g. this function is called by <tt>highlight_visitor::find_main_highlight</tt> to find the action to highlight.)<br />
<br />
====<span id="visitorhier.idea">The idea</span>====<br />
I'm favorable to the maintain of the Visitor pattern, it segregates the different components nicely.<br />
I think the problem come from <tt>enable_visit_all</tt> and I would like to replace it with a class offering a more fine-grained access to the actions.<br />
For example, a look up by hex could be defined in this new structure and then used by <tt>highlight_visitor</tt>.<br />
Actually, most of the work of this new class will have to do is to redirect the calls to the <tt>side_actions</tt> (to one in particular or to all depending on the function).<br />
<br />
====<span id="visitorhier.implementation">Implementation details</span>====<br />
Let's name this interface <tt>action_inquirer</tt>, I'm not a particularly good English speaker, so if you have a better name in mind, let me know. :)<br />
<br />
The sole problem faced is to place <tt>action_inquirer</tt>, since it is mainly a proxy to a global resource (the <tt>side_actions</tt> of each team), it makes sense to place it directly in the <tt>wb</tt> namespace.<br />
<br />
=====<span id="visitorhier.example">Example</span>=====<br />
Here is an example function that would speed up <tt>highlight_visitor</tt>.<br />
action_ptr action_inquirer::action_at(map_location const &hex){<br />
side_actions::iterator result;<br />
foreach(team& side, *resources::teams){<br />
side_actions actions = side.get_side_actions();<br />
if((result = actions.find_action_at(hex)) != actions.end())<br />
return *result;<br />
}<br />
return action_ptr();<br />
}<br />
<br />
Note: the implementation of <tt>side_actions::find_action_at</tt> is similar to the one of <tt>side_actions::find_first_action_of</tt>.<br />
<br />
===<span id="mapbuilder">Merging of the validation process into <tt>mapbuilder</tt></span>===<br />
====<span id="mapbuilder.situation">The current situation</span>====<br />
Currently the validation process is separated from the mapbuilding process.<br />
However they are depending on each other.<br />
Indeed, to validate an action the previous actions have to be applied (by the mapbuilder), while in order to build the future state in the mapbuilder, the sequence of action have to be valid.<br />
<br />
====<span id="mapbuilder.idea">The idea</span>====<br />
Inject the validation process into <tt>mapbuilder</tt>. This is not limited to the merging of <tt>validate_visitor</tt> into <tt>mapbuilder</tt>, indeed some validity check are also done in the <tt>action</tt> hierarchy.<br />
<br />
====<span id="mapbuilder.implementation">Implementation details</span>====<br />
I'm still working on this.<br />
<br />
=====<span id="mapbuilder.example">Example</span>=====<br />
Idem.<br />
<br />
===<span id="polishing">Polishing</span>===<br />
Some inconsistencies are present in the code (e.g. the way units are referenced). Some other parts needs clean up or/and optimisation (e.g. usage of <tt>boost::dynamic_pointer_cast</tt>).<br />
<br />
The goal of this task is to find this kind of small problem and fix them.<br />
These two ones have been spotted by gabba, but I'm planning to add other small problems to this list as I found them.<br />
<br />
Also, they can be a good introduction to the code that's why I'm planning to start working on them before the GSoC start date.<br />
<br />
===<span id="designdoc">Design document</span>===<br />
This idea is inspired by the GUI2 design document present in the SVN.<br />
<br />
Doxygen documents the code at a function or class level.<br />
The goal is to write a documentation at the module level. That is a document describing the whiteboard design globally and not function-by-function.<br />
Actually it shouldn't duplicate what is in doxygen but complement it.<br />
This document could also include informations on how to extend the whiteboard to help future contributors.<br />
<br />
Where should this document go?<br />
*In doxygen<br />
:This makes sense since it's where most of the code documentation is.<br />
*In the wiki<br />
:This would make collaborative editing easier.<br />
<br />
If you have an opinion on this, let me know. :)<br />
<br />
===Timeline===<br />
Two of my five tasks are actually best done continuously: the design document and the polishing.<br />
Although I haven't clearly placed a week for them, I set two dates at which they should have been completed.<br />
<br />
Of course, the plan is not to have any delay and to finish each task early, however I have reserved two weeks (actually one week and a half) for unexpected delay.<br />
I named them "movable weeks", because they can move in my timeline if anything goes wrong. :)<br />
<br />
<!-- Wikitext hell 101 --><br />
{| style="border:1px dashed #AAA;border-collapse:collapse;"<br />
|-<br />
!style="border:1px dotted #AAA;padding:5px;"|Date<br />
!style="border:1px dotted #AAA;padding:5px;"|Week<br />
!style="border:1px dotted #AAA;padding:5px;"|Description<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''17/03 - 20/04''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''-11..-5''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Student application evaluation''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|17/03 - 20/04<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|-11..-5<br />
|style="border:1px dotted #AAA;padding:5px;"|Refine the proposal.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''23/04 - 20/05''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''-4..-1''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Community Bonding Period (4 weeks)''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|'''23/04 - 20/05'''<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|'''-4..-1'''<br />
|style="border:1px dotted #AAA;padding:5px;"|'''Phase 0: Approach'''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|23/04 - 20/05<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|-4..-1<br />
|style="border:1px dotted #AAA;padding:5px;"|Familiarise myself with the whiteboard, in the process start a draft of the design document.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|23/04 - 20/05<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|-4..-1<br />
|style="border:1px dotted #AAA;padding:5px;"|Start working on the ''polishing'' and on small parts of the whiteboard in order to gain commit access.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''21/05''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''0''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Start of GSoC''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|21/05 - 12/08<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|0..11<br />
|style="border:1px dotted #AAA;padding:5px;"|Continuously work on the design document and on the code polishing.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''21/05 - 15/07''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''0..7''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''First half term (8 weeks)''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|'''21/05 - 10/06'''<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|'''0..2'''<br />
|style="border:1px dotted #AAA;padding:5px;"|'''Phase 1: <tt>side_actions</tt> refactoring'''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|21/05 - 27/05<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|0<br />
|style="border:1px dotted #AAA;padding:5px;"|Prepare <tt>side_actions</tt> for the change. Add debug informations to the logs. Make the current iterators bidirectional.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|28/05 - 03/06<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|1<br />
|style="border:1px dotted #AAA;padding:5px;"|Change the underlying container and rewrite the associated functions.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|04/06 - 10/06<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|2<br />
|style="border:1px dotted #AAA;padding:5px;"|Debug, write unit test and documentation.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|'''11/06 - 01/07'''<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|'''3..5'''<br />
|style="border:1px dotted #AAA;padding:5px;"|'''Phase 2: Validator hierarchy refactoring'''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|11/06 - 17/06<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|3<br />
|style="border:1px dotted #AAA;padding:5px;"|Write the class <tt>action_inquirer</tt>.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|18/06 - 24/06<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|4<br />
|style="border:1px dotted #AAA;padding:5px;"|Replace the uses of <tt>enable_visit_all</tt> with the new interface. Then delete <tt>enable_visit_all</tt>.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|25/06 - 01/07<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|5<br />
|style="border:1px dotted #AAA;padding:5px;"|Debug, write unit test and documentation.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|'''02/07 - 22/07'''<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|'''6..8'''<br />
|style="border:1px dotted #AAA;padding:5px;"|'''Phase 3: Merging of the validation process into <tt>mapbuilder</tt>'''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|02/07 - 08/07<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|6<br />
|style="border:1px dotted #AAA;padding:5px;"|Merge <tt>validate_visitor</tt> into <tt>mapbuilder</tt>.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|09/07 - 15/07<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|7<br />
|style="border:1px dotted #AAA;padding:5px;"|Hunt down other validity check in the <tt>action</tt> hierarchy and move them to <tt>mapbuilder</tt>.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''13/07''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''7''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Mid-term evaluation''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''16/07 - 26/08''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''8..13''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Second half term (6 weeks)''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|16/07 - 22/07<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|8<br />
|style="border:1px dotted #AAA;padding:5px;"|Debug, write unit test and documentation.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|'''22/07 - 12/08'''<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|'''9..11'''<br />
|style="border:1px dotted #AAA;padding:5px;"|'''Phase 4: Finalisation'''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|22/07 - 29/07<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|9<br />
|style="border:1px dotted #AAA;padding:5px;"|Heavy testing week.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|30/07 - 05/08<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|10<br />
|style="border:1px dotted #AAA;padding:5px;"|Test, debug. Finish the ''polishing''.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|06/08 - 12/08<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|11<br />
|style="border:1px dotted #AAA;padding:5px;"|Test, debug. Finish the design document.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|13/08 - 19/08<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|12<br />
|style="border:1px dotted #AAA;padding:5px;"|Movable week.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|20/08 - 26/08<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|13<br />
|style="border:1px dotted #AAA;padding:5px;"|Movable week.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''24/08''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''13''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Final evaluation''<br />
|}</div>Ejlshttps://wiki.wesnoth.org/index.php?title=User:Ejls/GSoC_2012/Whiteboard_Backend_Refactoring&diff=45969User:Ejls/GSoC 2012/Whiteboard Backend Refactoring2012-04-01T02:10:09Z<p>Ejls: Making it SummerOfCodeIdeas-friendly</p>
<hr />
<div><!--<br />
Excuse the heavy wikitext, I tried to make it as readable as possible and I put a lot of comments.<br />
-->__NOTOC__<!--<br />
-->__NOEDITSECTION__<!--<br />
-->{{SoC2012Student}}<!--<br />
-->[[Category:SoC_Ideas_Whiteboard_Backend_Refactoring_2012]]<!--<br />
-->'''''Note: This proposal is in construction, if you have any remark, please drop me a line on IRC or on the [[{{TALKPAGENAME}}|talk page]].'''''<br /><br /><br />
<br />
<!--***********************************************************************<br />
* * Table of Content * *<br />
* ******************** *<br />
* *<br />
* WARNING: don't forget to add a TOC entry when adding a new section. *<br />
***********************************************************************--><br />
{|style="background:#FAF3E9;margin:none;padding:5px;border:3px double #AAA;-moz-border-radius:20px 5px 20px 5px;-webkit-border-radius:20px 5px 20px 5px;border-radius:20px 5px 20px 5px;"<br />
|-<br />
| style="text-align: center; padding: 0px 10px 5px 10px;"|'''Content'''<hr /><br />
|-<br />
| style="text-align: left; padding:0px 10px 10px 10px;"|<br />
[[#Description|Description]]<br /><br />
[[#Contact|Contact]]<br /><br />
<!--[[#SoC Application|SoC Application]]<br /><br />
-->[[#Questionnaire|Questionnaire]]<br /><br />
:[[#1) Basics|1 - Basics]]<br /><br />
:[[#2) Experience|2 - Experience]]<br /><br />
:[[#3) Communication skills|3 - Communication skills]]<br /><br />
:[[#4) Project|4 - Project]]<br /><br />
:[[#5) Practical considerations|5 - Practical considerations]]<br /><br />
[[#Proposal|Proposal]]<br /><br />
:[[#The problems|The problems]]<br /><br />
:[[#side_actions|<tt>side_actions</tt> refactoring]]<br /><br />
::[[#side_actions.situation|The current situation]]<br /><br />
::[[#side_actions.idea|The idea]]<br /><br />
::[[#side_actions.implementation|Implementation details]]<br /><br />
:::[[#side_actions.containers|Choice of the containers]]<br /><br />
:::[[#side_actions.example|Example]]<br /><br />
:[[#visitorhier|Visitor hierarchy refactoring]]<br /><br />
::[[#visitorhier.situation|The current situation]]<br /><br />
::[[#visitorhier.idea|The idea]]<br /><br />
::[[#visitorhier.implementation|Implementation details]]<br /><br />
:::[[#visitorhier.example|Example]]<br /><br />
:[[#mapbuilder|Merging of the validation process into <tt>mapbuilder</tt>]]<br /><br />
::[[#mapbuilder.situation|The current situation]]<br /><br />
::[[#mapbuilder.idea|The idea]]<br /><br />
::[[#mapbuilder.implementation|Implementation details]]<br /><br />
:::[[#mapbuilder.example|Example]]<br /><br />
:[[#polishing|Polishing]]<br /><br />
:[[#designdoc|Design document]]<br /><br />
:[[#Timeline|Timeline]]<br /><br />
|}<br />
<br />
<!--***********************************************************************<br />
* * Description * *<br />
* *************** *<br />
* *<br />
* This section is inserted in the SummerOfCodeIdeas page. It contains *<br />
* only a header of level 4 and a small paragraph summing up the *<br />
* proposal. *<br />
***********************************************************************--><br />
==Description==<br />
=====Étienne Simon - Whiteboard backend polishing=====<br />
My project is to make the whiteboard code cleaner and to redesign small parts of it to speed it up. Apart from the visitor hierarchy refactoring, the global design of the whiteboard won't be changed, each part will be reviewed individually. I'm not only planning to improve the whiteboard backend, but also to document the overall design and each part of it as well as to write a wide variety of test to improve its stability.<!--<br />
--><br />
<!--***********************************************************************<br />
* * SoC Application * *<br />
* ******************* *<br />
* *<br />
* This section affect the SummerOfCodeIdeas page, if it contains the *<br />
* text "Submitted to google", the application will appear in the *<br />
* "Student proposals submitted both to wiki and google" section, *<br />
* otherwise it'll appear in the "Student proposals not submitted to *<br />
* google" section. *<br />
***********************************************************************--><br />
==SoC Application==<br />
Submitted to google<br />
<br />
==Contact==<br />
<!--***********************************************************************<br />
* * Contact * *<br />
* *********** *<br />
* *<br />
* The IRC subsection is inserted in the SummerOfCodeIdeas page. It *<br />
* must only contain the IRC nick identifying the author. *<br />
***********************************************************************--><br />
{|<br />
|-<br />
|<br />
=====IRC=====<br />
<span style="color:#3F475E;">ejls </span><br />
=====Email=====<br />
Address at gmail dot com: etienne.jl.simon<br />
| style="width:10em;" |<br />
|<br />
=====Forum=====<br />
ejls<br />
=====Gna=====<br />
ejls<br />
|}<br />
<br />
<!--***********************************************************************<br />
* * Questionnaire * *<br />
* ***************** *<br />
* *<br />
* Although I'm submitting only one application (and so only one *<br />
* questionnaire), I thought it was more elegant to make the *<br />
* questionnaire page reusable. Which explain why it's a template. *<br />
* Like I wrote in the Questionnaire subpage, the argument to this *<br />
* template are the answer to the proposal-specific questions. I order *<br />
* to make the sources more comprehensible, I wrote the corresponding *<br />
* question in comments at the beginning of each parameter. *<br />
***********************************************************************--><br />
{{User:Ejls/GSoC 2012/Questionnaire<br />
|<!-- 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? --><br />
''This is a summary, more details can be found [http://wiki.wesnoth.org/User:Ejls/GSoC%202012/Whiteboard%20Backend%20Refactoring#Proposal here].''<br />
<br />
I have chosen [[SoC Ideas Whiteboard Backend Refactoring 2012]]. This project is the only one not adding any feature for the user, the main goal is to refactor code, write test and documentation. It follows [http://wiki.wesnoth.org/GSoC-WesnothWhiteboard_Gabba gabba's project] and [http://wiki.wesnoth.org/User:Tschmitz tschmitz's project] on the whiteboard. Although it doesn't add any feature for the user in itself, I hope it'll help future development of the whiteboard.<!--<br />
-->|<!-- 4.2) If you have invented your own project, please describe the project and the scope. --><br />
I chose a project from the list, namely [[SoC Ideas Whiteboard Backend Refactoring 2012]]. C.f. above answer.<!--<br />
-->|<!-- 4.3) Why did you choose this project? --><br />
I liked the idea behind the whiteboard, I think it might be a big plus to Wesnoth. Furthermore, I liked how C++ is used in its code (especially the heavy use of SBRM). However it looks like the whiteboard is not widely used, and I would like to help changing that! :)<!--<br />
-->|<!-- 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". --><br />
''This is a summary, more details can be found [http://wiki.wesnoth.org/User:Ejls/GSoC%202012/Whiteboard%20Backend%20Refactoring#Timeline here].''<br />
<br />
I separated my summer in five phases:<br />
*Phase 0: Approach (4 weeks)<br />
::→ Start working on the design document. Start the ''polishing''.<br />
*Phase 1: <tt>side_actions</tt> refactoring (3 weeks)<br />
*Phase 2: Validator hierarchy refactoring (3 weeks)<br />
*Phase 3: Merging of the validation process into <tt>mapbuilder</tt> (3 weeks)<br />
*Phase 4: Finalisation (3 weeks)<br />
::→ Finish the design document. Finish the ''polishing''. Test. Test. Test.<!--<br />
-->|<!-- 4.5) Include as much technical detail about your implementation as you can --><br />
''This is a summary, more details can be found [http://wiki.wesnoth.org/User:Ejls/GSoC%202012/Whiteboard%20Backend%20Refactoring#Proposal here].''<br />
<br />
I separated my project in five tasks:<br />
;<tt>side_actions</tt> refactoring<br />
:Change of the underlying container, creation of new look up functions.<br />
;Visitor hierarchy refactoring<br />
:Replacement of the <tt>enable_visit_all</tt> by a new interface over all of the <tt>side_actions</tt> objects.<br />
;Merging of the validation process into <tt>mapbuilder</tt><br />
:Deletion of the <tt>validate_visitor</tt> class, injection of its code and other validation code from the <tt>action</tt> hierarchy into <tt>mapbuilder</tt>.<br />
;Polishing<br />
:Code uniformisation, small improvements.<br />
;Design document<br />
:Documentation of the global whiteboard design.<!--<br />
-->|<!-- 4.6) What do you expect to gain from this project? --><br />
I hope it'll help me to join the open source developer community. Actually, the preparation of this proposal already helped me a lot, for example my first patch got committed, it wasn't a big patch, but it was my first step of a (I hope) long path. :) So, I hope to continue learning to walk with the wesnoth community (sorry for the silly metaphor.)<!--<br />
-->|<!-- 4.7) What would make you stay in the Wesnoth community after the conclusion of SOC? --><br />
If my work is appreciated, I would rather ask: what would make me leave the Wesnoth community?.<!--<br />
-->}}<br />
<br />
<!--***********************************************************************<br />
* * Proposal * *<br />
* ************ *<br />
* *<br />
* Finally, my proposal. ;) *<br />
***********************************************************************--><br />
==Proposal==<br />
===The problems===<br />
In the [[SoC_Ideas_Whiteboard_Backend_Refactoring_2012|Whiteboard Backend Refactoring idea page]], several problems are listed, here is how I'm planning to fix them:<br />
{| style="border:1px dashed #AAA;border-collapse:collapse;"<br />
|-<br />
!style="border:1px dotted #AAA;padding:5px;"|Problem<br />
!style="border:1px dotted #AAA;padding:5px;"|Solution<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|<tt>side_actions</tt> complexity<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#side_actions|<tt>side_actions</tt> refactoring]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|Redundancy between <tt>mapbuilder</tt> and <tt>validate_visitor</tt><br />
|style="border:1px dotted #AAA;padding:5px;"|[[#mapbuilder|Merging of the validation process into <tt>mapbuilder</tt>]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|Highlighter slowness<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#side_actions|<tt>side_actions</tt> refactoring]] and [[#visitorhier|Visitor hierarchy refactoring]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|Friend classes vs everything in the action classes<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#visitorhier|Visitor hierarchy refactoring]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|Unit pointer recovery uniformisation<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#polishing|Polishing]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|<tt>boost::dynamic_pointer_cast</tt> vs simple numeric id<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#polishing|Polishing]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|Documentation<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#designdoc|Design document]]<br />
|}<br />
<br />
===<span id="side_actions"><tt>side_actions</tt> refactoring</span>===<br />
====<span id="side_actions.situation">The current situation</span>====<br />
The current implementation of <tt>side_actions</tt> use a <tt>std::deque&lt;std::deque&lt;action_ptr&gt;&gt;</tt>.<br />
In order to use it, iterators have been defined over it (<tt>side_actions::iterator</tt> and the three const and revert variants).<br />
These “flattening” iterators let users of <tt>side_actions</tt> iterate over all the planned actions, they are performing the ''zip'' operation on the fly.<br />
<br />
Furthermore, some queries like <tt>side_actions::find_first_action_of</tt> are linear in the number of action.<br />
<br />
====<span id="side_actions.idea">The idea</span>====<br />
To simplify the code, I propose to keep the action set zipped. The container's iterators will then be usable directly. In order to delimit turns, a second container will have to keep a sequence of iterators pointing to the first action of each turn.<br />
<br />
For example, let's say eight actions are planned: five for this turn, two for the next turn and one for the turn after. Three iterators will be kept to delimit turns. Here is a proof that I can't use gimp which also show the idea:<br />
http://epsilon012.free.fr/GSoC%202012/side_actions%20idea.png<br />
<br />
Of course another problem emerge: the sequence of iterator has to be kept in sync with the sequence of action.<br />
<br />
Finally, the current implementation gives access to the <tt>action_ptr</tt> only in sequence, in order to speed up different way of querying action (e.g. by hex, by unit's id), I propose to build several indexes on the action set.<br />
<br />
====<span id="side_actions.implementation">Implementation details</span>====<br />
Let's name these containers <tt>actions_</tt> and <tt>turn_beginnings_</tt>.<br />
<br />
The whiteboard have the following invariant: an empty turn (a turn without planned action) can't be followed by a non-empty turn (with at least one planned action). It means that <code>distance(turn_beginnings_[i], turn_beginnings_[i+1])&gt;0</code>, and so we can unambiguously determine the turn number of each action.<br />
<br />
Also, note that except when <tt>actions_.empty()</tt> : <tt>turn_beginnings_.front()==actions_.begin()</tt>.<br />
<br />
=====<span id="side_actions.containers">Choice of the containers</span>=====<br />
<tt>std::deque</tt> seems to be the perfect container for <tt>turn_beginnings_</tt>. It'll allow random access and we need to add/remove new turns only at the extremities.<br />
<br />
On the other hand, <tt>actions_</tt> need two proprieties:<br />
*Allow fast chronological iteration<br />
*Stable iterators<br />
*Allow fast lookup on different indexes<br />
I propose to use a <tt>boost::multi_index_container</tt>, this container is part of the library [http://www.boost.org/doc/libs/1_49_0/libs/multi_index Boost.MultiIndex] which is in Boost since version 1.32. It allows the construction of several indexes on the same set of object.<br />
<br />
There is however one problem linked to the use of the <tt>boost::multi_index::random_access</tt> index: insertion and deletion are in linear time when their are not done at the extremities.<br />
<br />
So, the new members should be:<br />
namespace bmi = boost::multi_index;<br />
typedef bmi::multi_index_container<<br />
action_ptr,<br />
bmi::indexed_by<<br />
bmi::random_access<bmi::tag<chronological> >,<br />
bmi::hashed_non_unique<bmi::tag<by_unit>, bmi::const_mem_fun<action,size_t,&action::get_unit_id> >,<br />
bmi::hashed_non_unique<bmi::tag<by_hex>, bmi::const_mem_fun<action,size_t,&action::get_hex>><br />
><br />
> action_set;<br />
typedef action_set::iterator iterator;<br />
<br />
action_set actions_;<br />
std::deque<iterator> turn_beginnings_;<br />
<br />
This suppose two new pure virtual function in <tt>action</tt>: <tt>get_unit_id</tt> and <tt>get_hex</tt>.<br />
<br />
Using action's attribute as key brings another drawback: we must notify the <tt>multi_index_container</tt> when we modify a key.<br />
However, the two used keys here (the unit's id and the hex) are never modified in the <tt>action</tt> hierarchy.<br />
<br />
This definition is here to give an idea, in practice other indexes will have to be built (e.g. an index on ''secondary hex'' which could be the source hex in <tt>move</tt>.)<br />
Note that this doesn't necessarily means a new pure virtual function in <tt>action</tt>, a key extractor can be defined to let <tt>action</tt> as it is and use ''RTTI'' instead (this might not be clever though.)<br />
<br />
=====<span id="side_actions.example">Example</span>=====<br />
Here are three functions rewritten with this new design. Note that <tt>side_actions::iterator</tt> is the one defined above.<br />
side_actions::iterator side_actions::end_turn(size_t turn_num){<br />
if(turn_num+1>=turn_beginnings_.size())<br />
return actions_.end();<br />
else<br />
return turn_beginnings_[turn_num+1];<br />
}<br />
<br />
side_actions::iterator side_actions::raw_enqueue(size_t turn_num, action_ptr act){<br />
assert(turn_num <= turn_beginnings_.size());<br />
<br />
iterator new_action = actions_.insert(end_turn(turn_num), act).first;<br />
<br />
if(turn_num >= turn_beginnings_.size())<br />
turn_beginnings_.push_back(new_action);<br />
<br />
return new_action;<br />
}<br />
<br />
side_actions::find_first_action_of(unit const* unit, side_actions::iterator start_position){<br />
// First we get all the action of this unit<br />
typedef action_set::index<by_unit>::type::iterator unit_iterator;<br />
std::pair<unit_iterator, unit_iterator> act = actions_.get<by_unit>().equal_range(unit->underlying_id());<br />
<br />
// Then we find the first of them (chronologically) after start_position<br />
iterator first = actions_.end();<br />
for(unit_iterator it = act.first; it != act.second; ++it){<br />
iterator chrono_it = actions_.project<chronological>(it);<br />
if(chrono_it < first && chrono_it > start_position)<br />
first = chrono_it;<br />
}<br />
return first;<br />
}<br />
<br />
===<span id="visitorhier">Visitor hierarchy refactoring</span>===<br />
====<span id="visitorhier.situation">The current situation</span>====<br />
The important classes and class templates of this hierarchy are:<br />
*'''<tt>visitor</tt>''' is the base class of the visitor hierarchy, it dispatches the calls to the derived classes.<br />
*'''<tt>enable_visit_all</tt>''' is actually an interface to the <tt>action_ptr</tt> objects of every single team.<br />
*'''<tt>action</tt>''' is the root class of the visitable hierarchy.<br />
<br />
Currently, when the visitor hierarchy needs to visit the visitable hierarchy, all the actions of every sides of every turn are visited using the function <tt>enable_visit_all::visit_all_helper</tt> (e.g. this function is called by <tt>highlight_visitor::find_main_highlight</tt> to find the action to highlight.)<br />
<br />
====<span id="visitorhier.idea">The idea</span>====<br />
I'm favorable to the maintain of the Visitor pattern, it segregates the different components nicely.<br />
I think the problem come from <tt>enable_visit_all</tt> and I would like to replace it with a class offering a more fine-grained access to the actions.<br />
For example, a look up by hex could be defined in this new structure and then used by <tt>highlight_visitor</tt>.<br />
Actually, most of the work of this new class will have to do is to redirect the calls to the <tt>side_actions</tt> (to one in particular or to all depending on the function).<br />
<br />
====<span id="visitorhier.implementation">Implementation details</span>====<br />
Let's name this interface <tt>action_inquirer</tt>, I'm not a particularly good English speaker, so if you have a better name in mind, let me know. :)<br />
<br />
The sole problem faced is to place <tt>action_inquirer</tt>, since it is mainly a proxy to a global resource (the <tt>side_actions</tt> of each team), it makes sense to place it directly in the <tt>wb</tt> namespace.<br />
<br />
=====<span id="visitorhier.example">Example</span>=====<br />
Here is an example function that would speed up <tt>highlight_visitor</tt>.<br />
action_ptr action_inquirer::action_at(map_location const &hex){<br />
side_actions::iterator result;<br />
foreach(team& side, *resources::teams){<br />
side_actions actions = side.get_side_actions();<br />
if((result = actions.find_action_at(hex)) != actions.end())<br />
return *result;<br />
}<br />
return action_ptr();<br />
}<br />
<br />
Note: the implementation of <tt>side_actions::find_action_at</tt> is similar to the one of <tt>side_actions::find_first_action_of</tt>.<br />
<br />
===<span id="mapbuilder">Merging of the validation process into <tt>mapbuilder</tt></span>===<br />
====<span id="mapbuilder.situation">The current situation</span>====<br />
Currently the validation process is separated from the mapbuilding process.<br />
However they are depending on each other.<br />
Indeed, to validate an action the previous actions have to be applied (by the mapbuilder), while in order to build the future state in the mapbuilder, the sequence of action have to be valid.<br />
<br />
====<span id="mapbuilder.idea">The idea</span>====<br />
Inject the validation process into <tt>mapbuilder</tt>. This is not limited to the merging of <tt>validate_visitor</tt> into <tt>mapbuilder</tt>, indeed some validity check are also done in the <tt>action</tt> hierarchy.<br />
<br />
====<span id="mapbuilder.implementation">Implementation details</span>====<br />
I'm still working on this.<br />
<br />
=====<span id="mapbuilder.example">Example</span>=====<br />
Idem.<br />
<br />
===<span id="polishing">Polishing</span>===<br />
Some inconsistencies are present in the code (e.g. the way units are referenced). Some other parts needs clean up or/and optimisation (e.g. usage of <tt>boost::dynamic_pointer_cast</tt>).<br />
<br />
The goal of this task is to find this kind of small problem and fix them.<br />
These two ones have been spotted by gabba, but I'm planning to add other small problems to this list as I found them.<br />
<br />
Also, they can be a good introduction to the code that's why I'm planning to start working on them before the GSoC start date.<br />
<br />
===<span id="designdoc">Design document</span>===<br />
This idea is inspired by the GUI2 design document present in the SVN.<br />
<br />
Doxygen documents the code at a function or class level.<br />
The goal is to write a documentation at the module level. That is a document describing the whiteboard design globally and not function-by-function.<br />
Actually it shouldn't duplicate what is in doxygen but complement it.<br />
This document could also include informations on how to extend the whiteboard to help future contributors.<br />
<br />
Where should this document go?<br />
*In doxygen<br />
:This makes sense since it's where most of the code documentation is.<br />
*In the wiki<br />
:This would make collaborative editing easier.<br />
<br />
If you have an opinion on this, let me know. :)<br />
<br />
===Timeline===<br />
Two of my five tasks are actually best done continuously: the design document and the polishing.<br />
Although I haven't clearly placed a week for them, I set two dates at which they should have been completed.<br />
<br />
Of course, the plan is not to have any delay and to finish each task early, however I have reserved two weeks (actually one week and a half) for unexpected delay.<br />
I named them "movable weeks", because they can move in my timeline if anything goes wrong. :)<br />
<br />
<!-- Wikitext hell 101 --><br />
{| style="border:1px dashed #AAA;border-collapse:collapse;"<br />
|-<br />
!style="border:1px dotted #AAA;padding:5px;"|Date<br />
!style="border:1px dotted #AAA;padding:5px;"|Week<br />
!style="border:1px dotted #AAA;padding:5px;"|Description<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''17/03 - 20/04''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''-11..-5''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Student application evaluation''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|17/03 - 20/04<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|-11..-5<br />
|style="border:1px dotted #AAA;padding:5px;"|Refine the proposal.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''23/04 - 20/05''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''-4..-1''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Community Bonding Period (4 weeks)''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|'''23/04 - 20/05'''<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|'''-4..-1'''<br />
|style="border:1px dotted #AAA;padding:5px;"|'''Phase 0: Approach'''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|23/04 - 20/05<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|-4..-1<br />
|style="border:1px dotted #AAA;padding:5px;"|Familiarise myself with the whiteboard, in the process start a draft of the design document.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|23/04 - 20/05<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|-4..-1<br />
|style="border:1px dotted #AAA;padding:5px;"|Start working on the ''polishing'' and on small parts of the whiteboard in order to gain commit access.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''21/05''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''0''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Start of GSoC''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|21/05 - 12/08<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|0..11<br />
|style="border:1px dotted #AAA;padding:5px;"|Continuously work on the design document and on the code polishing.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''21/05 - 15/07''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''0..7''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''First half term (8 weeks)''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|'''21/05 - 10/06'''<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|'''0..2'''<br />
|style="border:1px dotted #AAA;padding:5px;"|'''Phase 1: <tt>side_actions</tt> refactoring'''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|21/05 - 27/05<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|0<br />
|style="border:1px dotted #AAA;padding:5px;"|Prepare <tt>side_actions</tt> for the change. Add debug informations to the logs. Make the current iterators bidirectional.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|28/05 - 03/06<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|1<br />
|style="border:1px dotted #AAA;padding:5px;"|Change the underlying container and rewrite the associated functions.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|04/06 - 10/06<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|2<br />
|style="border:1px dotted #AAA;padding:5px;"|Debug, write unit test and documentation.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|'''11/06 - 01/07'''<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|'''3..5'''<br />
|style="border:1px dotted #AAA;padding:5px;"|'''Phase 2: Validator hierarchy refactoring'''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|11/06 - 17/06<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|3<br />
|style="border:1px dotted #AAA;padding:5px;"|Write the class <tt>action_inquirer</tt>.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|18/06 - 24/06<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|4<br />
|style="border:1px dotted #AAA;padding:5px;"|Replace the uses of <tt>enable_visit_all</tt> with the new interface. Then delete <tt>enable_visit_all</tt>.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|25/06 - 01/07<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|5<br />
|style="border:1px dotted #AAA;padding:5px;"|Debug, write unit test and documentation.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|'''02/07 - 22/07'''<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|'''6..8'''<br />
|style="border:1px dotted #AAA;padding:5px;"|'''Phase 3: Merging of the validation process into <tt>mapbuilder</tt>'''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|02/07 - 08/07<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|6<br />
|style="border:1px dotted #AAA;padding:5px;"|Merge <tt>validate_visitor</tt> into <tt>mapbuilder</tt>.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|09/07 - 15/07<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|7<br />
|style="border:1px dotted #AAA;padding:5px;"|Hunt down other validity check in the <tt>action</tt> hierarchy and move them to <tt>mapbuilder</tt>.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''13/07''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''7''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Mid-term evaluation''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''16/07 - 26/08''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''8..13''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Second half term (6 weeks)''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|16/07 - 22/07<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|8<br />
|style="border:1px dotted #AAA;padding:5px;"|Debug, write unit test and documentation.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|'''22/07 - 12/08'''<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|'''9..11'''<br />
|style="border:1px dotted #AAA;padding:5px;"|'''Phase 4: Finalisation'''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|22/07 - 29/07<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|9<br />
|style="border:1px dotted #AAA;padding:5px;"|Heavy testing week.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|30/07 - 05/08<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|10<br />
|style="border:1px dotted #AAA;padding:5px;"|Test, debug. Finish the ''polishing''.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|06/08 - 12/08<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|11<br />
|style="border:1px dotted #AAA;padding:5px;"|Test, debug. Finish the design document.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|13/08 - 19/08<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|12<br />
|style="border:1px dotted #AAA;padding:5px;"|Movable week.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|20/08 - 26/08<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|13<br />
|style="border:1px dotted #AAA;padding:5px;"|Movable week.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''24/08''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''13''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Final evaluation''<br />
|}</div>Ejlshttps://wiki.wesnoth.org/index.php?title=User:Ejls/GSoC_2012/Whiteboard_Backend_Refactoring&diff=45968User:Ejls/GSoC 2012/Whiteboard Backend Refactoring2012-04-01T02:08:03Z<p>Ejls: mark the proposal as submitted to google</p>
<hr />
<div><!--<br />
Excuse the heavy wikitext, I tried to make it as readable as possible and I put a lot of comments.<br />
-->__NOTOC__<!--<br />
-->__NOEDITSECTION__<!--<br />
-->{{SoC2012Student}}<!--<br />
-->[[Category:SoC_Ideas_Whiteboard_Backend_Refactoring_2012]]<!--<br />
-->'''''Note: This proposal is in construction, if you have any remark, please drop me a line on IRC or on the [[{{TALKPAGENAME}}|talk page]].'''''<br /><br /><br />
<br />
<!--***********************************************************************<br />
* * Table of Content * *<br />
* ******************** *<br />
* *<br />
* WARNING: don't forget to add a TOC entry when adding a new section. *<br />
***********************************************************************--><br />
{|style="background:#FAF3E9;margin:none;padding:5px;border:3px double #AAA;-moz-border-radius:20px 5px 20px 5px;-webkit-border-radius:20px 5px 20px 5px;border-radius:20px 5px 20px 5px;"<br />
|-<br />
| style="text-align: center; padding: 0px 10px 5px 10px;"|'''Content'''<hr /><br />
|-<br />
| style="text-align: left; padding:0px 10px 10px 10px;"|<br />
[[#Description|Description]]<br /><br />
[[#Contact|Contact]]<br /><br />
<!--[[#SoC Application|SoC Application]]<br /><br />
-->[[#Questionnaire|Questionnaire]]<br /><br />
:[[#1) Basics|1 - Basics]]<br /><br />
:[[#2) Experience|2 - Experience]]<br /><br />
:[[#3) Communication skills|3 - Communication skills]]<br /><br />
:[[#4) Project|4 - Project]]<br /><br />
:[[#5) Practical considerations|5 - Practical considerations]]<br /><br />
[[#Proposal|Proposal]]<br /><br />
:[[#The problems|The problems]]<br /><br />
:[[#side_actions|<tt>side_actions</tt> refactoring]]<br /><br />
::[[#side_actions.situation|The current situation]]<br /><br />
::[[#side_actions.idea|The idea]]<br /><br />
::[[#side_actions.implementation|Implementation details]]<br /><br />
:::[[#side_actions.containers|Choice of the containers]]<br /><br />
:::[[#side_actions.example|Example]]<br /><br />
:[[#visitorhier|Visitor hierarchy refactoring]]<br /><br />
::[[#visitorhier.situation|The current situation]]<br /><br />
::[[#visitorhier.idea|The idea]]<br /><br />
::[[#visitorhier.implementation|Implementation details]]<br /><br />
:::[[#visitorhier.example|Example]]<br /><br />
:[[#mapbuilder|Merging of the validation process into <tt>mapbuilder</tt>]]<br /><br />
::[[#mapbuilder.situation|The current situation]]<br /><br />
::[[#mapbuilder.idea|The idea]]<br /><br />
::[[#mapbuilder.implementation|Implementation details]]<br /><br />
:::[[#mapbuilder.example|Example]]<br /><br />
:[[#polishing|Polishing]]<br /><br />
:[[#designdoc|Design document]]<br /><br />
:[[#Timeline|Timeline]]<br /><br />
|}<br />
<br />
<!--***********************************************************************<br />
* * Description * *<br />
* *************** *<br />
* *<br />
* This section is inserted in the SummerOfCodeIdeas page. It contains *<br />
* only a header of level 4 and a small paragraph summing up the *<br />
* proposal. *<br />
***********************************************************************--><br />
==Description==<br />
=====Étienne Simon - Whiteboard backend polishing=====<br />
My project is to make the whiteboard code cleaner and to redesign small parts of it to speed it up. Apart from the visitor hierarchy refactoring, the global design of the whiteboard won't be changed, each part will be reviewed individually. I'm not only planning to improve the whiteboard backend, but also to document the overall design and each part of it as well as to write a wide variety of test to improve its stability.<!--<br />
--><br />
<!--***********************************************************************<br />
* * SoC Application * *<br />
* ******************* *<br />
* *<br />
* This section affect the SummerOfCodeIdeas page, if it contains the *<br />
* text "Submitted to google", the application will appear in the *<br />
* "Student proposals submitted both to wiki and google" section, *<br />
* otherwise it'll appear in the "Student proposals not submitted to *<br />
* google" section. *<br />
***********************************************************************--><br />
==SoC Application==<br />
Submitted to google.<br />
<br />
<!--***********************************************************************<br />
* * Contact * *<br />
* *********** *<br />
* *<br />
* The IRC subsection is inserted in the SummerOfCodeIdeas page. It *<br />
* must only contain the IRC nick identifying the author. *<br />
***********************************************************************--><br />
==Contact==<br />
{|<br />
|-<br />
|<br />
=====IRC=====<br />
<span style="color:#3F475E;">ejls </span><br />
=====Email=====<br />
Address at gmail dot com: etienne.jl.simon<br />
| style="width:10em;" |<br />
|<br />
=====Forum=====<br />
ejls<br />
=====Gna=====<br />
ejls<br />
|}<br />
<br />
<!--***********************************************************************<br />
* * Questionnaire * *<br />
* ***************** *<br />
* *<br />
* Although I'm submitting only one application (and so only one *<br />
* questionnaire), I thought it was more elegant to make the *<br />
* questionnaire page reusable. Which explain why it's a template. *<br />
* Like I wrote in the Questionnaire subpage, the argument to this *<br />
* template are the answer to the proposal-specific questions. I order *<br />
* to make the sources more comprehensible, I wrote the corresponding *<br />
* question in comments at the beginning of each parameter. *<br />
***********************************************************************--><br />
{{User:Ejls/GSoC 2012/Questionnaire<br />
|<!-- 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? --><br />
''This is a summary, more details can be found [http://wiki.wesnoth.org/User:Ejls/GSoC%202012/Whiteboard%20Backend%20Refactoring#Proposal here].''<br />
<br />
I have chosen [[SoC Ideas Whiteboard Backend Refactoring 2012]]. This project is the only one not adding any feature for the user, the main goal is to refactor code, write test and documentation. It follows [http://wiki.wesnoth.org/GSoC-WesnothWhiteboard_Gabba gabba's project] and [http://wiki.wesnoth.org/User:Tschmitz tschmitz's project] on the whiteboard. Although it doesn't add any feature for the user in itself, I hope it'll help future development of the whiteboard.<!--<br />
-->|<!-- 4.2) If you have invented your own project, please describe the project and the scope. --><br />
I chose a project from the list, namely [[SoC Ideas Whiteboard Backend Refactoring 2012]]. C.f. above answer.<!--<br />
-->|<!-- 4.3) Why did you choose this project? --><br />
I liked the idea behind the whiteboard, I think it might be a big plus to Wesnoth. Furthermore, I liked how C++ is used in its code (especially the heavy use of SBRM). However it looks like the whiteboard is not widely used, and I would like to help changing that! :)<!--<br />
-->|<!-- 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". --><br />
''This is a summary, more details can be found [http://wiki.wesnoth.org/User:Ejls/GSoC%202012/Whiteboard%20Backend%20Refactoring#Timeline here].''<br />
<br />
I separated my summer in five phases:<br />
*Phase 0: Approach (4 weeks)<br />
::→ Start working on the design document. Start the ''polishing''.<br />
*Phase 1: <tt>side_actions</tt> refactoring (3 weeks)<br />
*Phase 2: Validator hierarchy refactoring (3 weeks)<br />
*Phase 3: Merging of the validation process into <tt>mapbuilder</tt> (3 weeks)<br />
*Phase 4: Finalisation (3 weeks)<br />
::→ Finish the design document. Finish the ''polishing''. Test. Test. Test.<!--<br />
-->|<!-- 4.5) Include as much technical detail about your implementation as you can --><br />
''This is a summary, more details can be found [http://wiki.wesnoth.org/User:Ejls/GSoC%202012/Whiteboard%20Backend%20Refactoring#Proposal here].''<br />
<br />
I separated my project in five tasks:<br />
;<tt>side_actions</tt> refactoring<br />
:Change of the underlying container, creation of new look up functions.<br />
;Visitor hierarchy refactoring<br />
:Replacement of the <tt>enable_visit_all</tt> by a new interface over all of the <tt>side_actions</tt> objects.<br />
;Merging of the validation process into <tt>mapbuilder</tt><br />
:Deletion of the <tt>validate_visitor</tt> class, injection of its code and other validation code from the <tt>action</tt> hierarchy into <tt>mapbuilder</tt>.<br />
;Polishing<br />
:Code uniformisation, small improvements.<br />
;Design document<br />
:Documentation of the global whiteboard design.<!--<br />
-->|<!-- 4.6) What do you expect to gain from this project? --><br />
I hope it'll help me to join the open source developer community. Actually, the preparation of this proposal already helped me a lot, for example my first patch got committed, it wasn't a big patch, but it was my first step of a (I hope) long path. :) So, I hope to continue learning to walk with the wesnoth community (sorry for the silly metaphor.)<!--<br />
-->|<!-- 4.7) What would make you stay in the Wesnoth community after the conclusion of SOC? --><br />
If my work is appreciated, I would rather ask: what would make me leave the Wesnoth community?.<!--<br />
-->}}<br />
<br />
<!--***********************************************************************<br />
* * Proposal * *<br />
* ************ *<br />
* *<br />
* Finally, my proposal. ;) *<br />
***********************************************************************--><br />
==Proposal==<br />
===The problems===<br />
In the [[SoC_Ideas_Whiteboard_Backend_Refactoring_2012|Whiteboard Backend Refactoring idea page]], several problems are listed, here is how I'm planning to fix them:<br />
{| style="border:1px dashed #AAA;border-collapse:collapse;"<br />
|-<br />
!style="border:1px dotted #AAA;padding:5px;"|Problem<br />
!style="border:1px dotted #AAA;padding:5px;"|Solution<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|<tt>side_actions</tt> complexity<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#side_actions|<tt>side_actions</tt> refactoring]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|Redundancy between <tt>mapbuilder</tt> and <tt>validate_visitor</tt><br />
|style="border:1px dotted #AAA;padding:5px;"|[[#mapbuilder|Merging of the validation process into <tt>mapbuilder</tt>]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|Highlighter slowness<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#side_actions|<tt>side_actions</tt> refactoring]] and [[#visitorhier|Visitor hierarchy refactoring]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|Friend classes vs everything in the action classes<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#visitorhier|Visitor hierarchy refactoring]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|Unit pointer recovery uniformisation<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#polishing|Polishing]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|<tt>boost::dynamic_pointer_cast</tt> vs simple numeric id<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#polishing|Polishing]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|Documentation<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#designdoc|Design document]]<br />
|}<br />
<br />
===<span id="side_actions"><tt>side_actions</tt> refactoring</span>===<br />
====<span id="side_actions.situation">The current situation</span>====<br />
The current implementation of <tt>side_actions</tt> use a <tt>std::deque&lt;std::deque&lt;action_ptr&gt;&gt;</tt>.<br />
In order to use it, iterators have been defined over it (<tt>side_actions::iterator</tt> and the three const and revert variants).<br />
These “flattening” iterators let users of <tt>side_actions</tt> iterate over all the planned actions, they are performing the ''zip'' operation on the fly.<br />
<br />
Furthermore, some queries like <tt>side_actions::find_first_action_of</tt> are linear in the number of action.<br />
<br />
====<span id="side_actions.idea">The idea</span>====<br />
To simplify the code, I propose to keep the action set zipped. The container's iterators will then be usable directly. In order to delimit turns, a second container will have to keep a sequence of iterators pointing to the first action of each turn.<br />
<br />
For example, let's say eight actions are planned: five for this turn, two for the next turn and one for the turn after. Three iterators will be kept to delimit turns. Here is a proof that I can't use gimp which also show the idea:<br />
http://epsilon012.free.fr/GSoC%202012/side_actions%20idea.png<br />
<br />
Of course another problem emerge: the sequence of iterator has to be kept in sync with the sequence of action.<br />
<br />
Finally, the current implementation gives access to the <tt>action_ptr</tt> only in sequence, in order to speed up different way of querying action (e.g. by hex, by unit's id), I propose to build several indexes on the action set.<br />
<br />
====<span id="side_actions.implementation">Implementation details</span>====<br />
Let's name these containers <tt>actions_</tt> and <tt>turn_beginnings_</tt>.<br />
<br />
The whiteboard have the following invariant: an empty turn (a turn without planned action) can't be followed by a non-empty turn (with at least one planned action). It means that <code>distance(turn_beginnings_[i], turn_beginnings_[i+1])&gt;0</code>, and so we can unambiguously determine the turn number of each action.<br />
<br />
Also, note that except when <tt>actions_.empty()</tt> : <tt>turn_beginnings_.front()==actions_.begin()</tt>.<br />
<br />
=====<span id="side_actions.containers">Choice of the containers</span>=====<br />
<tt>std::deque</tt> seems to be the perfect container for <tt>turn_beginnings_</tt>. It'll allow random access and we need to add/remove new turns only at the extremities.<br />
<br />
On the other hand, <tt>actions_</tt> need two proprieties:<br />
*Allow fast chronological iteration<br />
*Stable iterators<br />
*Allow fast lookup on different indexes<br />
I propose to use a <tt>boost::multi_index_container</tt>, this container is part of the library [http://www.boost.org/doc/libs/1_49_0/libs/multi_index Boost.MultiIndex] which is in Boost since version 1.32. It allows the construction of several indexes on the same set of object.<br />
<br />
There is however one problem linked to the use of the <tt>boost::multi_index::random_access</tt> index: insertion and deletion are in linear time when their are not done at the extremities.<br />
<br />
So, the new members should be:<br />
namespace bmi = boost::multi_index;<br />
typedef bmi::multi_index_container<<br />
action_ptr,<br />
bmi::indexed_by<<br />
bmi::random_access<bmi::tag<chronological> >,<br />
bmi::hashed_non_unique<bmi::tag<by_unit>, bmi::const_mem_fun<action,size_t,&action::get_unit_id> >,<br />
bmi::hashed_non_unique<bmi::tag<by_hex>, bmi::const_mem_fun<action,size_t,&action::get_hex>><br />
><br />
> action_set;<br />
typedef action_set::iterator iterator;<br />
<br />
action_set actions_;<br />
std::deque<iterator> turn_beginnings_;<br />
<br />
This suppose two new pure virtual function in <tt>action</tt>: <tt>get_unit_id</tt> and <tt>get_hex</tt>.<br />
<br />
Using action's attribute as key brings another drawback: we must notify the <tt>multi_index_container</tt> when we modify a key.<br />
However, the two used keys here (the unit's id and the hex) are never modified in the <tt>action</tt> hierarchy.<br />
<br />
This definition is here to give an idea, in practice other indexes will have to be built (e.g. an index on ''secondary hex'' which could be the source hex in <tt>move</tt>.)<br />
Note that this doesn't necessarily means a new pure virtual function in <tt>action</tt>, a key extractor can be defined to let <tt>action</tt> as it is and use ''RTTI'' instead (this might not be clever though.)<br />
<br />
=====<span id="side_actions.example">Example</span>=====<br />
Here are three functions rewritten with this new design. Note that <tt>side_actions::iterator</tt> is the one defined above.<br />
side_actions::iterator side_actions::end_turn(size_t turn_num){<br />
if(turn_num+1>=turn_beginnings_.size())<br />
return actions_.end();<br />
else<br />
return turn_beginnings_[turn_num+1];<br />
}<br />
<br />
side_actions::iterator side_actions::raw_enqueue(size_t turn_num, action_ptr act){<br />
assert(turn_num <= turn_beginnings_.size());<br />
<br />
iterator new_action = actions_.insert(end_turn(turn_num), act).first;<br />
<br />
if(turn_num >= turn_beginnings_.size())<br />
turn_beginnings_.push_back(new_action);<br />
<br />
return new_action;<br />
}<br />
<br />
side_actions::find_first_action_of(unit const* unit, side_actions::iterator start_position){<br />
// First we get all the action of this unit<br />
typedef action_set::index<by_unit>::type::iterator unit_iterator;<br />
std::pair<unit_iterator, unit_iterator> act = actions_.get<by_unit>().equal_range(unit->underlying_id());<br />
<br />
// Then we find the first of them (chronologically) after start_position<br />
iterator first = actions_.end();<br />
for(unit_iterator it = act.first; it != act.second; ++it){<br />
iterator chrono_it = actions_.project<chronological>(it);<br />
if(chrono_it < first && chrono_it > start_position)<br />
first = chrono_it;<br />
}<br />
return first;<br />
}<br />
<br />
===<span id="visitorhier">Visitor hierarchy refactoring</span>===<br />
====<span id="visitorhier.situation">The current situation</span>====<br />
The important classes and class templates of this hierarchy are:<br />
*'''<tt>visitor</tt>''' is the base class of the visitor hierarchy, it dispatches the calls to the derived classes.<br />
*'''<tt>enable_visit_all</tt>''' is actually an interface to the <tt>action_ptr</tt> objects of every single team.<br />
*'''<tt>action</tt>''' is the root class of the visitable hierarchy.<br />
<br />
Currently, when the visitor hierarchy needs to visit the visitable hierarchy, all the actions of every sides of every turn are visited using the function <tt>enable_visit_all::visit_all_helper</tt> (e.g. this function is called by <tt>highlight_visitor::find_main_highlight</tt> to find the action to highlight.)<br />
<br />
====<span id="visitorhier.idea">The idea</span>====<br />
I'm favorable to the maintain of the Visitor pattern, it segregates the different components nicely.<br />
I think the problem come from <tt>enable_visit_all</tt> and I would like to replace it with a class offering a more fine-grained access to the actions.<br />
For example, a look up by hex could be defined in this new structure and then used by <tt>highlight_visitor</tt>.<br />
Actually, most of the work of this new class will have to do is to redirect the calls to the <tt>side_actions</tt> (to one in particular or to all depending on the function).<br />
<br />
====<span id="visitorhier.implementation">Implementation details</span>====<br />
Let's name this interface <tt>action_inquirer</tt>, I'm not a particularly good English speaker, so if you have a better name in mind, let me know. :)<br />
<br />
The sole problem faced is to place <tt>action_inquirer</tt>, since it is mainly a proxy to a global resource (the <tt>side_actions</tt> of each team), it makes sense to place it directly in the <tt>wb</tt> namespace.<br />
<br />
=====<span id="visitorhier.example">Example</span>=====<br />
Here is an example function that would speed up <tt>highlight_visitor</tt>.<br />
action_ptr action_inquirer::action_at(map_location const &hex){<br />
side_actions::iterator result;<br />
foreach(team& side, *resources::teams){<br />
side_actions actions = side.get_side_actions();<br />
if((result = actions.find_action_at(hex)) != actions.end())<br />
return *result;<br />
}<br />
return action_ptr();<br />
}<br />
<br />
Note: the implementation of <tt>side_actions::find_action_at</tt> is similar to the one of <tt>side_actions::find_first_action_of</tt>.<br />
<br />
===<span id="mapbuilder">Merging of the validation process into <tt>mapbuilder</tt></span>===<br />
====<span id="mapbuilder.situation">The current situation</span>====<br />
Currently the validation process is separated from the mapbuilding process.<br />
However they are depending on each other.<br />
Indeed, to validate an action the previous actions have to be applied (by the mapbuilder), while in order to build the future state in the mapbuilder, the sequence of action have to be valid.<br />
<br />
====<span id="mapbuilder.idea">The idea</span>====<br />
Inject the validation process into <tt>mapbuilder</tt>. This is not limited to the merging of <tt>validate_visitor</tt> into <tt>mapbuilder</tt>, indeed some validity check are also done in the <tt>action</tt> hierarchy.<br />
<br />
====<span id="mapbuilder.implementation">Implementation details</span>====<br />
I'm still working on this.<br />
<br />
=====<span id="mapbuilder.example">Example</span>=====<br />
Idem.<br />
<br />
===<span id="polishing">Polishing</span>===<br />
Some inconsistencies are present in the code (e.g. the way units are referenced). Some other parts needs clean up or/and optimisation (e.g. usage of <tt>boost::dynamic_pointer_cast</tt>).<br />
<br />
The goal of this task is to find this kind of small problem and fix them.<br />
These two ones have been spotted by gabba, but I'm planning to add other small problems to this list as I found them.<br />
<br />
Also, they can be a good introduction to the code that's why I'm planning to start working on them before the GSoC start date.<br />
<br />
===<span id="designdoc">Design document</span>===<br />
This idea is inspired by the GUI2 design document present in the SVN.<br />
<br />
Doxygen documents the code at a function or class level.<br />
The goal is to write a documentation at the module level. That is a document describing the whiteboard design globally and not function-by-function.<br />
Actually it shouldn't duplicate what is in doxygen but complement it.<br />
This document could also include informations on how to extend the whiteboard to help future contributors.<br />
<br />
Where should this document go?<br />
*In doxygen<br />
:This makes sense since it's where most of the code documentation is.<br />
*In the wiki<br />
:This would make collaborative editing easier.<br />
<br />
If you have an opinion on this, let me know. :)<br />
<br />
===Timeline===<br />
Two of my five tasks are actually best done continuously: the design document and the polishing.<br />
Although I haven't clearly placed a week for them, I set two dates at which they should have been completed.<br />
<br />
Of course, the plan is not to have any delay and to finish each task early, however I have reserved two weeks (actually one week and a half) for unexpected delay.<br />
I named them "movable weeks", because they can move in my timeline if anything goes wrong. :)<br />
<br />
<!-- Wikitext hell 101 --><br />
{| style="border:1px dashed #AAA;border-collapse:collapse;"<br />
|-<br />
!style="border:1px dotted #AAA;padding:5px;"|Date<br />
!style="border:1px dotted #AAA;padding:5px;"|Week<br />
!style="border:1px dotted #AAA;padding:5px;"|Description<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''17/03 - 20/04''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''-11..-5''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Student application evaluation''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|17/03 - 20/04<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|-11..-5<br />
|style="border:1px dotted #AAA;padding:5px;"|Refine the proposal.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''23/04 - 20/05''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''-4..-1''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Community Bonding Period (4 weeks)''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|'''23/04 - 20/05'''<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|'''-4..-1'''<br />
|style="border:1px dotted #AAA;padding:5px;"|'''Phase 0: Approach'''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|23/04 - 20/05<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|-4..-1<br />
|style="border:1px dotted #AAA;padding:5px;"|Familiarise myself with the whiteboard, in the process start a draft of the design document.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|23/04 - 20/05<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|-4..-1<br />
|style="border:1px dotted #AAA;padding:5px;"|Start working on the ''polishing'' and on small parts of the whiteboard in order to gain commit access.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''21/05''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''0''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Start of GSoC''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|21/05 - 12/08<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|0..11<br />
|style="border:1px dotted #AAA;padding:5px;"|Continuously work on the design document and on the code polishing.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''21/05 - 15/07''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''0..7''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''First half term (8 weeks)''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|'''21/05 - 10/06'''<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|'''0..2'''<br />
|style="border:1px dotted #AAA;padding:5px;"|'''Phase 1: <tt>side_actions</tt> refactoring'''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|21/05 - 27/05<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|0<br />
|style="border:1px dotted #AAA;padding:5px;"|Prepare <tt>side_actions</tt> for the change. Add debug informations to the logs. Make the current iterators bidirectional.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|28/05 - 03/06<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|1<br />
|style="border:1px dotted #AAA;padding:5px;"|Change the underlying container and rewrite the associated functions.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|04/06 - 10/06<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|2<br />
|style="border:1px dotted #AAA;padding:5px;"|Debug, write unit test and documentation.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|'''11/06 - 01/07'''<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|'''3..5'''<br />
|style="border:1px dotted #AAA;padding:5px;"|'''Phase 2: Validator hierarchy refactoring'''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|11/06 - 17/06<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|3<br />
|style="border:1px dotted #AAA;padding:5px;"|Write the class <tt>action_inquirer</tt>.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|18/06 - 24/06<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|4<br />
|style="border:1px dotted #AAA;padding:5px;"|Replace the uses of <tt>enable_visit_all</tt> with the new interface. Then delete <tt>enable_visit_all</tt>.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|25/06 - 01/07<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|5<br />
|style="border:1px dotted #AAA;padding:5px;"|Debug, write unit test and documentation.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|'''02/07 - 22/07'''<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|'''6..8'''<br />
|style="border:1px dotted #AAA;padding:5px;"|'''Phase 3: Merging of the validation process into <tt>mapbuilder</tt>'''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|02/07 - 08/07<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|6<br />
|style="border:1px dotted #AAA;padding:5px;"|Merge <tt>validate_visitor</tt> into <tt>mapbuilder</tt>.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|09/07 - 15/07<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|7<br />
|style="border:1px dotted #AAA;padding:5px;"|Hunt down other validity check in the <tt>action</tt> hierarchy and move them to <tt>mapbuilder</tt>.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''13/07''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''7''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Mid-term evaluation''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''16/07 - 26/08''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''8..13''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Second half term (6 weeks)''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|16/07 - 22/07<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|8<br />
|style="border:1px dotted #AAA;padding:5px;"|Debug, write unit test and documentation.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|'''22/07 - 12/08'''<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|'''9..11'''<br />
|style="border:1px dotted #AAA;padding:5px;"|'''Phase 4: Finalisation'''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|22/07 - 29/07<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|9<br />
|style="border:1px dotted #AAA;padding:5px;"|Heavy testing week.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|30/07 - 05/08<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|10<br />
|style="border:1px dotted #AAA;padding:5px;"|Test, debug. Finish the ''polishing''.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|06/08 - 12/08<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|11<br />
|style="border:1px dotted #AAA;padding:5px;"|Test, debug. Finish the design document.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|13/08 - 19/08<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|12<br />
|style="border:1px dotted #AAA;padding:5px;"|Movable week.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|20/08 - 26/08<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|13<br />
|style="border:1px dotted #AAA;padding:5px;"|Movable week.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''24/08''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''13''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Final evaluation''<br />
|}</div>Ejlshttps://wiki.wesnoth.org/index.php?title=User:Ejls/GSoC_2012/Whiteboard_Backend_Refactoring&diff=45952User:Ejls/GSoC 2012/Whiteboard Backend Refactoring2012-03-31T16:36:04Z<p>Ejls: readability</p>
<hr />
<div><!--<br />
Excuse the heavy wikitext, I tried to make it as readable as possible and I put a lot of comments.<br />
-->__NOTOC__<!--<br />
-->__NOEDITSECTION__<!--<br />
-->{{SoC2012Student}}<!--<br />
-->[[Category:SoC_Ideas_Whiteboard_Backend_Refactoring_2012]]<!--<br />
-->'''''Note: This proposal is in continuous construction, if you have any remark, please drop me a line on IRC or on the [[{{TALKPAGENAME}}|talk page]].'''''<br /><br /><br />
<br />
<!--***********************************************************************<br />
* * Table of Content * *<br />
* ******************** *<br />
* *<br />
* WARNING: don't forget to add a TOC entry when adding a new section. *<br />
***********************************************************************--><br />
{|style="background:#FAF3E9;margin:none;padding:5px;border:3px double #AAA;-moz-border-radius:20px 5px 20px 5px;-webkit-border-radius:20px 5px 20px 5px;border-radius:20px 5px 20px 5px;"<br />
|-<br />
| style="text-align: center; padding: 0px 10px 5px 10px;"|'''Content'''<hr /><br />
|-<br />
| style="text-align: left; padding:0px 10px 10px 10px;"|<br />
[[#Description|Description]]<br /><br />
[[#Contact|Contact]]<br /><br />
<!--[[#SoC Application|SoC Application]]<br /><br />
-->[[#Questionnaire|Questionnaire]]<br /><br />
:[[#1) Basics|1 - Basics]]<br /><br />
:[[#2) Experience|2 - Experience]]<br /><br />
:[[#3) Communication skills|3 - Communication skills]]<br /><br />
:[[#4) Project|4 - Project]]<br /><br />
:[[#5) Practical considerations|5 - Practical considerations]]<br /><br />
[[#Proposal|Proposal]]<br /><br />
:[[#The problems|The problems]]<br /><br />
:[[#side_actions|<tt>side_actions</tt> refactoring]]<br /><br />
::[[#side_actions.situation|The current situation]]<br /><br />
::[[#side_actions.idea|The idea]]<br /><br />
::[[#side_actions.implementation|Implementation details]]<br /><br />
:::[[#side_actions.containers|Choice of the containers]]<br /><br />
:::[[#side_actions.example|Example]]<br /><br />
:[[#visitorhier|Visitor hierarchy refactoring]]<br /><br />
::[[#visitorhier.situation|The current situation]]<br /><br />
::[[#visitorhier.idea|The idea]]<br /><br />
::[[#visitorhier.implementation|Implementation details]]<br /><br />
:::[[#visitorhier.example|Example]]<br /><br />
:[[#mapbuilder|Merging of the validation process into <tt>mapbuilder</tt>]]<br /><br />
::[[#mapbuilder.situation|The current situation]]<br /><br />
::[[#mapbuilder.idea|The idea]]<br /><br />
::[[#mapbuilder.implementation|Implementation details]]<br /><br />
:::[[#mapbuilder.example|Example]]<br /><br />
:[[#polishing|Polishing]]<br /><br />
:[[#designdoc|Design document]]<br /><br />
:[[#Timeline|Timeline]]<br /><br />
|}<br />
<br />
<!--***********************************************************************<br />
* * Description * *<br />
* *************** *<br />
* *<br />
* This section is inserted in the SummerOfCodeIdeas page. It contains *<br />
* only a header of level 4 and a small paragraph summing up the *<br />
* proposal. *<br />
***********************************************************************--><br />
==Description==<br />
=====Étienne Simon - Whiteboard backend polishing=====<br />
My project is to make the whiteboard code cleaner and to redesign small parts of it to speed it up. Apart from the visitor hierarchy refactoring, the global design of the whiteboard won't be changed, each part will be reviewed individually. I'm not only planning to improve the whiteboard backend, but also to document the overall design and each part of it as well as to write a wide variety of test to improve its stability.<!--<br />
<br />
***********************************************************************<br />
* * SoC Application * *<br />
* ******************* *<br />
* *<br />
* This section affect the SummerOfCodeIdeas page, if it contains the *<br />
* text "Submitted to google", the application will appear in the *<br />
* "Student proposals submitted both to wiki and google" section, *<br />
* otherwise it'll appear in the "Student proposals not submitted to *<br />
* google" section. *<br />
***********************************************************************<br />
==SoC Application==<br />
Not yet submitted.<br />
***********************************************************************<br />
* * Contact * *<br />
* *********** *<br />
* *<br />
* The IRC subsection is inserted in the SummerOfCodeIdeas page. It *<br />
* must only contain the IRC nick identifying the author. *<br />
***********************************************************************--><br />
==Contact==<br />
{|<br />
|-<br />
|<br />
=====IRC=====<br />
<span style="color:#3F475E;">ejls </span><br />
=====Email=====<br />
Address at gmail dot com: etienne.jl.simon<br />
| style="width:10em;" |<br />
|<br />
=====Forum=====<br />
ejls<br />
=====Gna=====<br />
ejls<br />
|}<br />
<br />
<!--***********************************************************************<br />
* * Questionnaire * *<br />
* ***************** *<br />
* *<br />
* Although I'm submitting only one application (and so only one *<br />
* questionnaire), I thought it was more elegant to make the *<br />
* questionnaire page reusable. Which explain why it's a template. *<br />
* Like I wrote in the Questionnaire subpage, the argument to this *<br />
* template are the answer to the proposal-specific questions. I order *<br />
* to make the sources more comprehensible, I wrote the corresponding *<br />
* question in comments at the beginning of each parameter. *<br />
***********************************************************************--><br />
{{User:Ejls/GSoC 2012/Questionnaire<br />
|<!-- 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? --><br />
''This is a summary, more details can be found [http://wiki.wesnoth.org/User:Ejls/GSoC%202012/Whiteboard%20Backend%20Refactoring#Proposal here].''<br />
<br />
I have chosen [[SoC Ideas Whiteboard Backend Refactoring 2012]]. This project is the only one not adding any feature for the user, the main goal is to refactor code, write test and documentation. It follows [http://wiki.wesnoth.org/GSoC-WesnothWhiteboard_Gabba gabba's project] and [http://wiki.wesnoth.org/User:Tschmitz tschmitz's project] on the whiteboard. Although it doesn't add any feature for the user in itself, I hope it'll help future development of the whiteboard.<!--<br />
-->|<!-- 4.2) If you have invented your own project, please describe the project and the scope. --><br />
I chose a project from the list, namely [[SoC Ideas Whiteboard Backend Refactoring 2012]]. C.f. above answer.<!--<br />
-->|<!-- 4.3) Why did you choose this project? --><br />
I liked the idea behind the whiteboard, I think it might be a big plus to Wesnoth. Furthermore, I liked how C++ is used in its code (especially the heavy use of SBRM). However it looks like the whiteboard is not widely used, and I would like to help changing that! :)<!--<br />
-->|<!-- 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". --><br />
''This is a summary, more details can be found [http://wiki.wesnoth.org/User:Ejls/GSoC%202012/Whiteboard%20Backend%20Refactoring#Timeline here].''<br />
<br />
I separated my summer in five phases:<br />
*Phase 0: Approach (4 weeks)<br />
::→ Start working on the design document. Start the ''polishing''.<br />
*Phase 1: <tt>side_actions</tt> refactoring (3 weeks)<br />
*Phase 2: Validator hierarchy refactoring (3 weeks)<br />
*Phase 3: Merging of the validation process into <tt>mapbuilder</tt> (3 weeks)<br />
*Phase 4: Finalisation (3 weeks)<br />
::→ Finish the design document. Finish the ''polishing''. Test. Test. Test.<!--<br />
-->|<!-- 4.5) Include as much technical detail about your implementation as you can --><br />
''This is a summary, more details can be found [http://wiki.wesnoth.org/User:Ejls/GSoC%202012/Whiteboard%20Backend%20Refactoring#Proposal here].''<br />
<br />
I separated my project in five tasks:<br />
;<tt>side_actions</tt> refactoring<br />
:Change of the underlying container, creation of new look up functions.<br />
;Visitor hierarchy refactoring<br />
:Replacement of the <tt>enable_visit_all</tt> by a new interface over all of the <tt>side_actions</tt> objects.<br />
;Merging of the validation process into <tt>mapbuilder</tt><br />
:Deletion of the <tt>validate_visitor</tt> class, injection of its code and other validation code from the <tt>action</tt> hierarchy into <tt>mapbuilder</tt>.<br />
;Polishing<br />
:Code uniformisation, small improvements.<br />
;Design document<br />
:Documentation of the global whiteboard design.<!--<br />
-->|<!-- 4.6) What do you expect to gain from this project? --><br />
I hope it'll help me to join the open source developer community. Actually, the preparation of this proposal already helped me a lot, for example my first patch got committed, it wasn't a big patch, but it was my first step of a (I hope) long path. :) So, I hope to continue learning to walk with the wesnoth community (sorry for the silly metaphor.)<!--<br />
-->|<!-- 4.7) What would make you stay in the Wesnoth community after the conclusion of SOC? --><br />
If my work is appreciated, I would rather ask: what would make me leave the Wesnoth community?.<!--<br />
-->}}<br />
<br />
<!--***********************************************************************<br />
* * Proposal * *<br />
* ************ *<br />
* *<br />
* Finally, my proposal. ;) *<br />
***********************************************************************--><br />
==Proposal==<br />
===The problems===<br />
In the [[SoC_Ideas_Whiteboard_Backend_Refactoring_2012|Whiteboard Backend Refactoring idea page]], several problems are listed, here is how I'm planning to fix them:<br />
{| style="border:1px dashed #AAA;border-collapse:collapse;"<br />
|-<br />
!style="border:1px dotted #AAA;padding:5px;"|Problem<br />
!style="border:1px dotted #AAA;padding:5px;"|Solution<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|<tt>side_actions</tt> complexity<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#side_actions|<tt>side_actions</tt> refactoring]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|Redundancy between <tt>mapbuilder</tt> and <tt>validate_visitor</tt><br />
|style="border:1px dotted #AAA;padding:5px;"|[[#mapbuilder|Merging of the validation process into <tt>mapbuilder</tt>]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|Highlighter slowness<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#side_actions|<tt>side_actions</tt> refactoring]] and [[#visitorhier|Visitor hierarchy refactoring]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|Friend classes vs everything in the action classes<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#visitorhier|Visitor hierarchy refactoring]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|Unit pointer recovery uniformisation<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#polishing|Polishing]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|<tt>boost::dynamic_pointer_cast</tt> vs simple numeric id<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#polishing|Polishing]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|Documentation<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#designdoc|Design document]]<br />
|}<br />
<br />
===<span id="side_actions"><tt>side_actions</tt> refactoring</span>===<br />
====<span id="side_actions.situation">The current situation</span>====<br />
The current implementation of <tt>side_actions</tt> use a <tt>std::deque&lt;std::deque&lt;action_ptr&gt;&gt;</tt>.<br />
In order to use it, iterators have been defined over it (<tt>side_actions::iterator</tt> and the three const and revert variants).<br />
These “flattening” iterators let users of <tt>side_actions</tt> iterate over all the planned actions, they are performing the ''zip'' operation on the fly.<br />
<br />
Furthermore, some queries like <tt>side_actions::find_first_action_of</tt> are linear in the number of action.<br />
<br />
====<span id="side_actions.idea">The idea</span>====<br />
To simplify the code, I propose to keep the action set zipped. The container's iterators will then be usable directly. In order to delimit turns, a second container will have to keep a sequence of iterators pointing to the first action of each turn.<br />
<br />
For example, let's say eight actions are planned: five for this turn, two for the next turn and one for the turn after. Three iterators will be kept to delimit turns. Here is a proof that I can't use gimp which also show the idea:<br />
http://epsilon012.free.fr/GSoC%202012/side_actions%20idea.png<br />
<br />
Of course another problem emerge: the sequence of iterator has to be kept in sync with the sequence of action.<br />
<br />
Finally, the current implementation gives access to the <tt>action_ptr</tt> only in sequence, in order to speed up different way of querying action (e.g. by hex, by unit's id), I propose to build several indexes on the action set.<br />
<br />
====<span id="side_actions.implementation">Implementation details</span>====<br />
Let's name these containers <tt>actions_</tt> and <tt>turn_beginnings_</tt>.<br />
<br />
The whiteboard have the following invariant: an empty turn (a turn without planned action) can't be followed by a non-empty turn (with at least one planned action). It means that <code>distance(turn_beginnings_[i], turn_beginnings_[i+1])&gt;0</code>, and so we can unambiguously determine the turn number of each action.<br />
<br />
Also, note that except when <tt>actions_.empty()</tt> : <tt>turn_beginnings_.front()==actions_.begin()</tt>.<br />
<br />
=====<span id="side_actions.containers">Choice of the containers</span>=====<br />
<tt>std::deque</tt> seems to be the perfect container for <tt>turn_beginnings_</tt>. It'll allow random access and we need to add/remove new turns only at the extremities.<br />
<br />
On the other hand, <tt>actions_</tt> need two proprieties:<br />
*Allow fast chronological iteration<br />
*Stable iterators<br />
*Allow fast lookup on different indexes<br />
I propose to use a <tt>boost::multi_index_container</tt>, this container is part of the library [http://www.boost.org/doc/libs/1_49_0/libs/multi_index Boost.MultiIndex] which is in Boost since version 1.32. It allows the construction of several indexes on the same set of object.<br />
<br />
There is however one problem linked to the use of the <tt>boost::multi_index::random_access</tt> index: insertion and deletion are in linear time when their are not done at the extremities.<br />
<br />
So, the new members should be:<br />
namespace bmi = boost::multi_index;<br />
typedef bmi::multi_index_container<<br />
action_ptr,<br />
bmi::indexed_by<<br />
bmi::random_access<bmi::tag<chronological> >,<br />
bmi::hashed_non_unique<bmi::tag<by_unit>, bmi::const_mem_fun<action,size_t,&action::get_unit_id> >,<br />
bmi::hashed_non_unique<bmi::tag<by_hex>, bmi::const_mem_fun<action,size_t,&action::get_hex>><br />
><br />
> action_set;<br />
typedef action_set::iterator iterator;<br />
<br />
action_set actions_;<br />
std::deque<iterator> turn_beginnings_;<br />
<br />
This suppose two new pure virtual function in <tt>action</tt>: <tt>get_unit_id</tt> and <tt>get_hex</tt>.<br />
<br />
Using action's attribute as key brings another drawback: we must notify the <tt>multi_index_container</tt> when we modify a key.<br />
However, the two used keys here (the unit's id and the hex) are never modified in the <tt>action</tt> hierarchy.<br />
<br />
This definition is here to give an idea, in practice other indexes will have to be built (e.g. an index on ''secondary hex'' which could be the source hex in <tt>move</tt>.)<br />
Note that this doesn't necessarily means a new pure virtual function in <tt>action</tt>, a key extractor can be defined to let <tt>action</tt> as it is and use ''RTTI'' instead (this might not be clever though.)<br />
<br />
=====<span id="side_actions.example">Example</span>=====<br />
Here are three functions rewritten with this new design. Note that <tt>side_actions::iterator</tt> is the one defined above.<br />
side_actions::iterator side_actions::end_turn(size_t turn_num){<br />
if(turn_num+1>=turn_beginnings_.size())<br />
return actions_.end();<br />
else<br />
return turn_beginnings_[turn_num+1];<br />
}<br />
<br />
side_actions::iterator side_actions::raw_enqueue(size_t turn_num, action_ptr act){<br />
assert(turn_num <= turn_beginnings_.size());<br />
<br />
iterator new_action = actions_.insert(end_turn(turn_num), act).first;<br />
<br />
if(turn_num >= turn_beginnings_.size())<br />
turn_beginnings_.push_back(new_action);<br />
<br />
return new_action;<br />
}<br />
<br />
side_actions::find_first_action_of(unit const* unit, side_actions::iterator start_position){<br />
// First we get all the action of this unit<br />
typedef action_set::index<by_unit>::type::iterator unit_iterator;<br />
std::pair<unit_iterator, unit_iterator> act = actions_.get<by_unit>().equal_range(unit->underlying_id());<br />
<br />
// Then we find the first of them (chronologically) after start_position<br />
iterator first = actions_.end();<br />
for(unit_iterator it = act.first; it != act.second; ++it){<br />
iterator chrono_it = actions_.project<chronological>(it);<br />
if(chrono_it < first && chrono_it > start_position)<br />
first = chrono_it;<br />
}<br />
return first;<br />
}<br />
<br />
===<span id="visitorhier">Visitor hierarchy refactoring</span>===<br />
====<span id="visitorhier.situation">The current situation</span>====<br />
The important classes and class templates of this hierarchy are:<br />
*'''<tt>visitor</tt>''' is the base class of the visitor hierarchy, it dispatches the calls to the derived classes.<br />
*'''<tt>enable_visit_all</tt>''' is actually an interface to the <tt>action_ptr</tt> objects of every single team.<br />
*'''<tt>action</tt>''' is the root class of the visitable hierarchy.<br />
<br />
Currently, when the visitor hierarchy needs to visit the visitable hierarchy, all the actions of every sides of every turn are visited using the function <tt>enable_visit_all::visit_all_helper</tt> (e.g. this function is called by <tt>highlight_visitor::find_main_highlight</tt> to find the action to highlight.)<br />
<br />
====<span id="visitorhier.idea">The idea</span>====<br />
I'm favorable to the maintain of the Visitor pattern, it segregates the different components nicely.<br />
I think the problem come from <tt>enable_visit_all</tt> and I would like to replace it with a class offering a more fine-grained access to the actions.<br />
For example, a look up by hex could be defined in this new structure and then used by <tt>highlight_visitor</tt>.<br />
Actually, most of the work of this new class will have to do is to redirect the calls to the <tt>side_actions</tt> (to one in particular or to all depending on the function).<br />
<br />
====<span id="visitorhier.implementation">Implementation details</span>====<br />
Let's name this interface <tt>action_inquirer</tt>, I'm not a particularly good English speaker, so if you have a better name in mind, let me know. :)<br />
<br />
The sole problem faced is to place <tt>action_inquirer</tt>, since it is mainly a proxy to a global resource (the <tt>side_actions</tt> of each team), it makes sense to place it directly in the <tt>wb</tt> namespace.<br />
<br />
=====<span id="visitorhier.example">Example</span>=====<br />
Here is an example function that would speed up <tt>highlight_visitor</tt>.<br />
action_ptr action_inquirer::action_at(map_location const &hex){<br />
side_actions::iterator result;<br />
foreach(team& side, *resources::teams){<br />
side_actions actions = side.get_side_actions();<br />
if((result = actions.find_action_at(hex)) != actions.end())<br />
return *result;<br />
}<br />
return action_ptr();<br />
}<br />
<br />
Note: the implementation of <tt>side_actions::find_action_at</tt> is similar to the one of <tt>side_actions::find_first_action_of</tt>.<br />
<br />
===<span id="mapbuilder">Merging of the validation process into <tt>mapbuilder</tt></span>===<br />
====<span id="mapbuilder.situation">The current situation</span>====<br />
Currently the validation process is separated from the mapbuilding process.<br />
However they are depending on each other.<br />
Indeed, to validate an action the previous actions have to be applied (by the mapbuilder), while in order to build the future state in the mapbuilder, the sequence of action have to be valid.<br />
<br />
====<span id="mapbuilder.idea">The idea</span>====<br />
Inject the validation process into <tt>mapbuilder</tt>. This is not limited to the merging of <tt>validate_visitor</tt> into <tt>mapbuilder</tt>, indeed some validity check are also done in the <tt>action</tt> hierarchy.<br />
<br />
====<span id="mapbuilder.implementation">Implementation details</span>====<br />
I'm still working on this.<br />
<br />
=====<span id="mapbuilder.example">Example</span>=====<br />
Idem.<br />
<br />
===<span id="polishing">Polishing</span>===<br />
Some inconsistencies are present in the code (e.g. the way units are referenced). Some other parts needs clean up or/and optimisation (e.g. usage of <tt>boost::dynamic_pointer_cast</tt>).<br />
<br />
The goal of this task is to find this kind of small problem and fix them.<br />
These two ones have been spotted by gabba, but I'm planning to add other small problems to this list as I found them.<br />
<br />
Also, they can be a good introduction to the code that's why I'm planning to start working on them before the GSoC start date.<br />
<br />
===<span id="designdoc">Design document</span>===<br />
This idea is inspired by the GUI2 design document present in the SVN.<br />
<br />
Doxygen documents the code at a function or class level.<br />
The goal is to write a documentation at the module level. That is a document describing the whiteboard design globally and not function-by-function.<br />
Actually it shouldn't duplicate what is in doxygen but complement it.<br />
This document could also include informations on how to extend the whiteboard to help future contributors.<br />
<br />
Where should this document go?<br />
*In doxygen<br />
:This makes sense since it's where most of the code documentation is.<br />
*In the wiki<br />
:This would make collaborative editing easier.<br />
<br />
If you have an opinion on this, let me know. :)<br />
<br />
===Timeline===<br />
Two of my five tasks are actually best done continuously: the design document and the polishing.<br />
Although I haven't clearly placed a week for them, I set two dates at which they should have been completed.<br />
<br />
Of course, the plan is not to have any delay and to finish each task early, however I have reserved two weeks (actually one week and a half) for unexpected delay.<br />
I named them "movable weeks", because they can move in my timeline if anything goes wrong. :)<br />
<br />
<!-- Wikitext hell 101 --><br />
{| style="border:1px dashed #AAA;border-collapse:collapse;"<br />
|-<br />
!style="border:1px dotted #AAA;padding:5px;"|Date<br />
!style="border:1px dotted #AAA;padding:5px;"|Week<br />
!style="border:1px dotted #AAA;padding:5px;"|Description<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''17/03 - 20/04''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''-11..-5''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Student application evaluation''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|17/03 - 20/04<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|-11..-5<br />
|style="border:1px dotted #AAA;padding:5px;"|Refine the proposal.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''23/04 - 20/05''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''-4..-1''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Community Bonding Period (4 weeks)''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|'''23/04 - 20/05'''<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|'''-4..-1'''<br />
|style="border:1px dotted #AAA;padding:5px;"|'''Phase 0: Approach'''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|23/04 - 20/05<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|-4..-1<br />
|style="border:1px dotted #AAA;padding:5px;"|Familiarise myself with the whiteboard, in the process start a draft of the design document.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|23/04 - 20/05<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|-4..-1<br />
|style="border:1px dotted #AAA;padding:5px;"|Start working on the ''polishing'' and on small parts of the whiteboard in order to gain commit access.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''21/05''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''0''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Start of GSoC''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|21/05 - 12/08<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|0..11<br />
|style="border:1px dotted #AAA;padding:5px;"|Continuously work on the design document and on the code polishing.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''21/05 - 15/07''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''0..7''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''First half term (8 weeks)''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|'''21/05 - 10/06'''<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|'''0..2'''<br />
|style="border:1px dotted #AAA;padding:5px;"|'''Phase 1: <tt>side_actions</tt> refactoring'''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|21/05 - 27/05<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|0<br />
|style="border:1px dotted #AAA;padding:5px;"|Prepare <tt>side_actions</tt> for the change. Add debug informations to the logs. Make the current iterators bidirectional.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|28/05 - 03/06<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|1<br />
|style="border:1px dotted #AAA;padding:5px;"|Change the underlying container and rewrite the associated functions.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|04/06 - 10/06<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|2<br />
|style="border:1px dotted #AAA;padding:5px;"|Debug, write unit test and documentation.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|'''11/06 - 01/07'''<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|'''3..5'''<br />
|style="border:1px dotted #AAA;padding:5px;"|'''Phase 2: Validator hierarchy refactoring'''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|11/06 - 17/06<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|3<br />
|style="border:1px dotted #AAA;padding:5px;"|Write the class <tt>action_inquirer</tt>.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|18/06 - 24/06<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|4<br />
|style="border:1px dotted #AAA;padding:5px;"|Replace the uses of <tt>enable_visit_all</tt> with the new interface. Then delete <tt>enable_visit_all</tt>.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|25/06 - 01/07<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|5<br />
|style="border:1px dotted #AAA;padding:5px;"|Debug, write unit test and documentation.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|'''02/07 - 22/07'''<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|'''6..8'''<br />
|style="border:1px dotted #AAA;padding:5px;"|'''Phase 3: Merging of the validation process into <tt>mapbuilder</tt>'''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|02/07 - 08/07<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|6<br />
|style="border:1px dotted #AAA;padding:5px;"|Merge <tt>validate_visitor</tt> into <tt>mapbuilder</tt>.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|09/07 - 15/07<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|7<br />
|style="border:1px dotted #AAA;padding:5px;"|Hunt down other validity check in the <tt>action</tt> hierarchy and move them to <tt>mapbuilder</tt>.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''13/07''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''7''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Mid-term evaluation''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''16/07 - 26/08''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''8..13''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Second half term (6 weeks)''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|16/07 - 22/07<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|8<br />
|style="border:1px dotted #AAA;padding:5px;"|Debug, write unit test and documentation.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|'''22/07 - 12/08'''<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|'''9..11'''<br />
|style="border:1px dotted #AAA;padding:5px;"|'''Phase 4: Finalisation'''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|22/07 - 29/07<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|9<br />
|style="border:1px dotted #AAA;padding:5px;"|Heavy testing week.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|30/07 - 05/08<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|10<br />
|style="border:1px dotted #AAA;padding:5px;"|Test, debug. Finish the ''polishing''.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|06/08 - 12/08<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|11<br />
|style="border:1px dotted #AAA;padding:5px;"|Test, debug. Finish the design document.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|13/08 - 19/08<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|12<br />
|style="border:1px dotted #AAA;padding:5px;"|Movable week.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|20/08 - 26/08<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|13<br />
|style="border:1px dotted #AAA;padding:5px;"|Movable week.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''24/08''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''13''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Final evaluation''<br />
|}</div>Ejlshttps://wiki.wesnoth.org/index.php?title=User:Ejls/GSoC_2012/Whiteboard_Backend_Refactoring&diff=45949User:Ejls/GSoC 2012/Whiteboard Backend Refactoring2012-03-31T06:20:44Z<p>Ejls: (4) yeah, that's the problem with wikitext and comment…</p>
<hr />
<div><!--<br />
Excuse the heavy wikitext, I tried to make it as readable as possible and I put a lot of comments.<br />
-->__NOTOC__<!--<br />
-->__NOEDITSECTION__<!--<br />
-->{{SoC2012Student}}<!--<br />
-->[[Category:SoC_Ideas_Whiteboard_Backend_Refactoring_2012]]<!--<br />
-->'''''Note: This proposal is in continuous construction, if you have any remark, please drop me a line on IRC or on the [[{{TALKPAGENAME}}|talk page]].'''''<br /><br /><br />
<br />
<!--***********************************************************************<br />
* * Table of Content * *<br />
* ******************** *<br />
* *<br />
* WARNING: don't forget to add a TOC entry when adding a new section. *<br />
***********************************************************************--><br />
{|style="background:#FAF3E9;margin:none;padding:5px;border:3px double #AAA;-moz-border-radius:20px 5px 20px 5px;-webkit-border-radius:20px 5px 20px 5px;border-radius:20px 5px 20px 5px;"<br />
|-<br />
| style="text-align: center; padding: 0px 10px 5px 10px;"|'''Content'''<hr /><br />
|-<br />
| style="text-align: left; padding:0px 10px 10px 10px;"|<br />
[[#Description|Description]]<br /><br />
[[#Contact|Contact]]<br /><br />
<!--[[#SoC Application|SoC Application]]<br /><br />
-->[[#Questionnaire|Questionnaire]]<br /><br />
:[[#1) Basics|1 - Basics]]<br /><br />
:[[#2) Experience|2 - Experience]]<br /><br />
:[[#3) Communication skills|3 - Communication skills]]<br /><br />
:[[#4) Project|4 - Project]]<br /><br />
:[[#5) Practical considerations|5 - Practical considerations]]<br /><br />
[[#Proposal|Proposal]]<br /><br />
:[[#The problems|The problems]]<br /><br />
:[[#side_actions|<tt>side_actions</tt> refactoring]]<br /><br />
::[[#side_actions.situation|The current situation]]<br /><br />
::[[#side_actions.idea|The idea]]<br /><br />
::[[#side_actions.implementation|Implementation details]]<br /><br />
:::[[#side_actions.containers|Choice of the containers]]<br /><br />
:::[[#side_actions.example|Example]]<br /><br />
:[[#visitorhier|Visitor hierarchy refactoring]]<br /><br />
::[[#visitorhier.situation|The current situation]]<br /><br />
::[[#visitorhier.idea|The idea]]<br /><br />
::[[#visitorhier.implementation|Implementation details]]<br /><br />
:::[[#visitorhier.example|Example]]<br /><br />
:[[#mapbuilder|Merging of the validation process into <tt>mapbuilder</tt>]]<br /><br />
::[[#mapbuilder.situation|The current situation]]<br /><br />
::[[#mapbuilder.idea|The idea]]<br /><br />
::[[#mapbuilder.implementation|Implementation details]]<br /><br />
:::[[#mapbuilder.example|Example]]<br /><br />
:[[#polishing|Polishing]]<br /><br />
:[[#designdoc|Design document]]<br /><br />
:[[#Timeline|Timeline]]<br /><br />
|}<br />
<br />
<!--***********************************************************************<br />
* * Description * *<br />
* *************** *<br />
* *<br />
* This section is inserted in the SummerOfCodeIdeas page. It contains *<br />
* only a header of level 4 and a small paragraph summing up the *<br />
* proposal. *<br />
***********************************************************************--><br />
==Description==<br />
=====Étienne Simon - Whiteboard backend polishing=====<br />
My project is to make the whiteboard code cleaner and to redesign small parts of it to speed it up. Apart from the visitor hierarchy refactoring, the global design of the whiteboard won't be changed, each part will be reviewed individually. I'm not only planning to improve the whiteboard backend, but also to document the overall design and each part of it as well as to write a wide variety of test to improve its stability.<!--<br />
<br />
***********************************************************************<br />
* * SoC Application * *<br />
* ******************* *<br />
* *<br />
* This section affect the SummerOfCodeIdeas page, if it contains the *<br />
* text "Submitted to google", the application will appear in the *<br />
* "Student proposals submitted both to wiki and google" section, *<br />
* otherwise it'll appear in the "Student proposals not submitted to *<br />
* google" section. *<br />
***********************************************************************<br />
==SoC Application==<br />
Not yet submitted.<br />
***********************************************************************<br />
* * Contact * *<br />
* *********** *<br />
* *<br />
* The IRC subsection is inserted in the SummerOfCodeIdeas page. It *<br />
* must only contain the IRC nick identifying the author. *<br />
***********************************************************************--><br />
==Contact==<br />
{|<br />
|-<br />
|<br />
=====IRC=====<br />
<span style="color:#3F475E;">ejls </span><br />
=====Email=====<br />
Address at gmail dot com: etienne.jl.simon<br />
| style="width:10em;" |<br />
|<br />
=====Forum=====<br />
ejls<br />
=====Gna=====<br />
ejls<br />
|}<br />
<br />
<!--***********************************************************************<br />
* * Questionnaire * *<br />
* ***************** *<br />
* *<br />
* Although I'm submitting only one application (and so only one *<br />
* questionnaire), I thought it was more elegant to make the *<br />
* questionnaire page reusable. Which explain why it's a template. *<br />
* Like I wrote in the Questionnaire subpage, the argument to this *<br />
* template are the answer to the proposal-specific questions. I order *<br />
* to make the sources more comprehensible, I wrote the corresponding *<br />
* question in comments at the beginning of each parameter. *<br />
***********************************************************************--><br />
{{User:Ejls/GSoC 2012/Questionnaire<br />
|<!-- 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? --><br />
''This is a summary, more details can be found [http://wiki.wesnoth.org/User:Ejls/GSoC%202012/Whiteboard%20Backend%20Refactoring#Proposal here].''<br />
<br />
I have chosen [[SoC Ideas Whiteboard Backend Refactoring 2012]]. This project is the only one not adding any feature for the user, the main goal is to refactor code, write test and documentation. It follows [http://wiki.wesnoth.org/GSoC-WesnothWhiteboard_Gabba gabba's project] and [http://wiki.wesnoth.org/User:Tschmitz tschmitz's project] on the whiteboard. Although it doesn't add any feature for the user in itself, I hope it'll help future development of the whiteboard.<!--<br />
-->|<!-- 4.2) If you have invented your own project, please describe the project and the scope. --><br />
I chose a project from the list, namely [[SoC Ideas Whiteboard Backend Refactoring 2012]]. C.f. above answer.<!--<br />
-->|<!-- 4.3) Why did you choose this project? --><br />
I liked the idea behind the whiteboard, I think it might be a big plus to Wesnoth. Furthermore, I liked how C++ is used in its code (especially the heavy use of SBRM). However it looks like the whiteboard is not widely used, and I would like to help changing that! :)<!--<br />
-->|<!-- 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". --><br />
''This is a summary, more details can be found [http://wiki.wesnoth.org/User:Ejls/GSoC%202012/Whiteboard%20Backend%20Refactoring#Timeline here].''<br />
<br />
I separated my summer in five phases:<br />
*Phase 0: Approach (4 weeks)<br />
::→ Start working on the design document. Start the ''polishing''.<br />
*Phase 1: <tt>side_actions</tt> refactoring (3 weeks)<br />
*Phase 2: Validator hierarchy refactoring (3 weeks)<br />
*Phase 3: Merging of the validation process into <tt>mapbuilder</tt> (3 weeks)<br />
*Phase 4: Finalisation (3 weeks)<br />
::→ Finish the design document. Finish the ''polishing''. Test. Test. Test.<!--<br />
-->|<!-- 4.5) Include as much technical detail about your implementation as you can --><br />
''This is a summary, more details can be found [http://wiki.wesnoth.org/User:Ejls/GSoC%202012/Whiteboard%20Backend%20Refactoring#Proposal here].''<br />
<br />
I separated my project in five tasks:<br />
;<tt>side_actions</tt> refactoring<br />
:Change of the underlying container, creation of new look up functions.<br />
;Visitor hierarchy refactoring<br />
:Replacement of the <tt>enable_visit_all</tt> by a new interface over all of the <tt>side_actions</tt> objects.<br />
;Merging of the validation process into <tt>mapbuilder</tt><br />
:Deletion of the <tt>validate_visitor</tt> class, injection of its code and other validation code from the <tt>action</tt> hierarchy into <tt>mapbuilder</tt>.<br />
;Polishing<br />
:Code uniformisation, small improvements.<br />
;Design document<br />
:Documentation of the global whiteboard design.<!--<br />
-->|<!-- 4.6) What do you expect to gain from this project? --><br />
I hope it'll help me to join the open source developer community. Actually, the preparation of this proposal already helped me a lot, for example my first patch got committed, it wasn't a big patch, but it was my first step of a (I hope) long path. :) So, I hope to continue learning to walk with the wesnoth community (sorry for the silly metaphor.)<!--<br />
-->|<!-- 4.7) What would make you stay in the Wesnoth community after the conclusion of SOC? --><br />
If my work is appreciated, I would rather ask: what would make me leave the Wesnoth community?.<!--<br />
-->}}<br />
<br />
<!--***********************************************************************<br />
* * Proposal * *<br />
* ************ *<br />
* *<br />
* Finally, my proposal. ;) *<br />
***********************************************************************--><br />
==Proposal==<br />
===The problems===<br />
In the [[SoC_Ideas_Whiteboard_Backend_Refactoring_2012|Whiteboard Backend Refactoring idea page]], several problems are listed, here is how I'm planning to fix them:<br />
{| style="border:1px dashed #AAA;border-collapse:collapse;"<br />
|-<br />
!style="border:1px dotted #AAA;padding:5px;"|Problem<br />
!style="border:1px dotted #AAA;padding:5px;"|Solution<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|<tt>side_actions</tt> complexity<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#side_actions|<tt>side_actions</tt> refactoring]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|Redundancy between <tt>mapbuilder</tt> and <tt>validate_visitor</tt><br />
|style="border:1px dotted #AAA;padding:5px;"|[[#mapbuilder|Merging of the validation process into <tt>mapbuilder</tt>]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|Highlighter slowness<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#side_actions|<tt>side_actions</tt> refactoring]] and [[#visitorhier|Visitor hierarchy refactoring]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|Friend classes vs everything in the action classes<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#visitorhier|Visitor hierarchy refactoring]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|Unit pointer recovery uniformisation<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#polishing|Polishing]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|<tt>boost::dynamic_pointer_cast</tt> vs simple numeric id<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#polishing|Polishing]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|Documentation<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#designdoc|Design document]]<br />
|}<br />
<br />
===<span id="side_actions"><tt>side_actions</tt> refactoring</span>===<br />
====<span id="side_actions.situation">The current situation</span>====<br />
The current implementation of <tt>side_actions</tt> use a <tt>std::deque&lt;std::deque&lt;action_ptr&gt;&gt;</tt>.<br />
In order to use it, iterators have been defined over it (<tt>side_actions::iterator</tt> and the three const and revert variants).<br />
These “flattening” iterators let users of <tt>side_actions</tt> iterate over all the planned actions, they are performing the ''zip'' operation on the fly.<br />
<br />
Furthermore, some queries like <tt>side_actions::find_first_action_of</tt> are linear in the number of action.<br />
<br />
====<span id="side_actions.idea">The idea</span>====<br />
To simplify the code, I propose to keep the action set zipped. The container's iterators will then be usable directly. In order to delimit turns, a second container will have to keep a sequence of iterators pointing to the first action of each turn.<br />
<br />
For example, let's say eight actions are planned: five for this turn, two for the next turn and one for the turn after. Three iterators will be kept to delimit turns. Here is a proof that I can't use gimp which also show the idea:<br />
http://epsilon012.free.fr/GSoC%202012/side_actions%20idea.png<br />
<br />
Of course another problem emerge: the sequence of iterator has to be kept in sync with the sequence of action.<br />
<br />
Finally, the current implementation gives access to the <tt>action_ptr</tt> only in sequence, in order to speed up different way of querying action (e.g. by hex, by unit's id), I propose to build several indexes on the action set.<br />
<br />
====<span id="side_actions.implementation">Implementation details</span>====<br />
Let's name these containers <tt>actions_</tt> and <tt>turn_beginnings_</tt>.<br />
<br />
The whiteboard have the following invariant: an empty turn (a turn without planned action) can't be followed by a non-empty turn (with at least one planned action). It means that <code>distance(turn_beginnings_[i], turn_beginnings_[i+1])&gt;0</code>, and so we can unambiguously determine the turn number of each action.<br />
<br />
Also, note that except when <tt>actions_.empty()</tt> : <tt>turn_beginnings_.front()==actions_.begin()</tt>.<br />
<br />
=====<span id="side_actions.containers">Choice of the containers</span>=====<br />
<tt>std::deque</tt> seems to be the perfect container for <tt>turn_beginnings_</tt>. It'll allow random access and we need to add/remove new turns only at the extremities.<br />
<br />
On the other hand, <tt>actions_</tt> need two proprieties:<br />
*Allow fast chronological iteration<br />
*Stable iterators<br />
*Allow fast lookup on different indexes<br />
I propose to use a <tt>boost::multi_index_container</tt>, this container is part of the library [http://www.boost.org/doc/libs/1_49_0/libs/multi_index Boost.MultiIndex] which is in Boost since version 1.32. It allows the construction of several indexes on the same set of object.<br />
<br />
There is however one problem linked to the use of the <tt>boost::multi_index::random_access</tt> index: insertion and deletion are in linear time when their are not done at the extremities.<br />
<br />
So, the new members should be:<br />
namespace bmi = boost::multi_index;<br />
typedef bmi::multi_index_container<<br />
action_ptr,<br />
bmi::indexed_by<<br />
bmi::random_access<bmi::tag<chronological> >,<br />
bmi::hashed_non_unique<bmi::tag<by_unit>, bmi::const_mem_fun<action,size_t,&action::get_unit_id> >,<br />
bmi::hashed_non_unique<bmi::tag<by_hex>, bmi::const_mem_fun<action,size_t,&action::get_hex>><br />
><br />
> action_set;<br />
typedef action_set::iterator iterator;<br />
<br />
action_set actions_;<br />
std::deque<iterator> turn_beginnings_;<br />
<br />
This suppose two new pure virtual function in <tt>action</tt>: <tt>get_unit_id</tt> and <tt>get_hex</tt>.<br />
<br />
Using action's attribute as key brings another drawback: we must notify the <tt>multi_index_container</tt> when we modify a key.<br />
However, the two used keys here (the unit's id and the hex) are never modified in the <tt>action</tt> hierarchy.<br />
<br />
This definition is here to give an idea, in practice other indexes will have to be built (e.g. an index on ''secondary hex'' which could be the source hex in <tt>move</tt>.)<br />
Note that this doesn't necessarily means a new pure virtual function in <tt>action</tt>, a key extractor can be defined to let <tt>action</tt> as it is and use ''RTTI'' instead (this might not be clever though.)<br />
<br />
=====<span id="side_actions.example">Example</span>=====<br />
Here are three functions rewritten with this new design. Note that <tt>side_actions::iterator</tt> is the one defined above.<br />
side_actions::iterator side_actions::end_turn(size_t turn_num){<br />
if(turn_num+1>=turn_beginnings_.size())<br />
return actions_.end();<br />
else<br />
return turn_beginnings_[turn_num+1];<br />
}<br />
<br />
side_actions::iterator side_actions::raw_enqueue(size_t turn_num, action_ptr act){<br />
assert(turn_num <= turn_beginnings_.size());<br />
<br />
iterator new_action = actions_.insert(end_turn(turn_num), act).first;<br />
<br />
if(turn_num >= turn_beginnings_.size())<br />
turn_beginnings_.push_back(new_action);<br />
<br />
return new_action;<br />
}<br />
<br />
side_actions::find_first_action_of(unit const* unit, side_actions::iterator start_position){<br />
// First we get all the action of this unit<br />
typedef action_set::index<by_unit>::type::iterator unit_iterator;<br />
std::pair<unit_iterator, unit_iterator> act = actions_.get<by_unit>().equal_range(unit->underlying_id());<br />
<br />
// Then we find the first of them (chronologically) after start_position<br />
iterator first = actions_.end();<br />
for(unit_iterator it = act.first; it != act.second; ++it){<br />
iterator chrono_it = actions_.project<chronological>(it);<br />
if(chrono_it < first && chrono_it > start_position)<br />
first = chrono_it;<br />
}<br />
return first;<br />
}<br />
<br />
===<span id="visitorhier">Visitor hierarchy refactoring</span>===<br />
====<span id="visitorhier.situation">The current situation</span>====<br />
The important classes and class templates of this hierarchy are:<br />
*'''<tt>visitor</tt>''' is the base class of the visitor hierarchy, it dispatches the calls to the derived classes.<br />
*'''<tt>enable_visit_all</tt>''' is actually an interface to the <tt>action_ptr</tt> objects of every single team.<br />
*'''<tt>action</tt>''' is the root class of the visitable hierarchy.<br />
<br />
Currently, when the visitor hierarchy needs to visit the visitable hierarchy, all the actions of every sides of every turn are visited using the function <tt>enable_visit_all::visit_all_helper</tt> (e.g. this function is called by <tt>highlight_visitor::find_main_highlight</tt> to find the action to highlight.)<br />
<br />
====<span id="visitorhier.idea">The idea</span>====<br />
I'm favorable to the maintain of the Visitor pattern, it segregates the different components nicely.<br />
I think the problem come from <tt>enable_visit_all</tt> and I would like to replace it with a class offering a more fine-grained access to the actions.<br />
For example, a look up by hex could be defined in this new structure and then used by <tt>highlight_visitor</tt>.<br />
Actually, most of the work of this new class will have to do is to redirect the calls to the <tt>side_actions</tt> (to one in particular or to all depending on the function).<br />
<br />
====<span id="visitorhier.implementation">Implementation details</span>====<br />
Let's name this interface <tt>action_inquirer</tt>, I'm not a particularly good English speaker, so if you have a better name in mind, let me know. :)<br />
<br />
The sole problem faced is to place <tt>action_inquirer</tt>, since it is mainly a proxy to a global resource (the <tt>side_actions</tt> of each team), it makes sense to place it directly in the <tt>wb</tt> namespace.<br />
<br />
=====<span id="visitorhier.example">Example</span>=====<br />
Here is an example function that would speed up <tt>highlight_visitor</tt>.<br />
action_ptr action_inquirer::action_at(map_location const &h){<br />
side_actions::iterator r;<br />
foreach(team& t, *resources::teams){<br />
side_actions sa = t.get_side_actions();<br />
if((r=sa.find_action_at(h)) != sa.end())<br />
return *r;<br />
}<br />
return action_ptr();<br />
}<br />
<br />
Note: the implementation of <tt>side_actions::find_action_at</tt> is similar to the one of <tt>side_actions::find_first_action_of</tt>.<br />
<br />
===<span id="mapbuilder">Merging of the validation process into <tt>mapbuilder</tt></span>===<br />
====<span id="mapbuilder.situation">The current situation</span>====<br />
Currently the validation process is separated from the mapbuilding process.<br />
However they are depending on each other.<br />
Indeed, to validate an action the previous actions have to be applied (by the mapbuilder), while in order to build the future state in the mapbuilder, the sequence of action have to be valid.<br />
<br />
====<span id="mapbuilder.idea">The idea</span>====<br />
Inject the validation process into <tt>mapbuilder</tt>. This is not limited to the merging of <tt>validate_visitor</tt> into <tt>mapbuilder</tt>, indeed some validity check are also done in the <tt>action</tt> hierarchy.<br />
<br />
====<span id="mapbuilder.implementation">Implementation details</span>====<br />
I'm still working on this.<br />
<br />
=====<span id="mapbuilder.example">Example</span>=====<br />
Idem.<br />
<br />
===<span id="polishing">Polishing</span>===<br />
Some inconsistencies are present in the code (e.g. the way units are referenced). Some other parts needs clean up or/and optimisation (e.g. usage of <tt>boost::dynamic_pointer_cast</tt>).<br />
<br />
The goal of this task is to find this kind of small problem and fix them.<br />
These two ones have been spotted by gabba, but I'm planning to add other small problems to this list as I found them.<br />
<br />
Also, they can be a good introduction to the code that's why I'm planning to start working on them before the GSoC start date.<br />
<br />
===<span id="designdoc">Design document</span>===<br />
This idea is inspired by the GUI2 design document present in the SVN.<br />
<br />
Doxygen documents the code at a function or class level.<br />
The goal is to write a documentation at the module level. That is a document describing the whiteboard design globally and not function-by-function.<br />
Actually it shouldn't duplicate what is in doxygen but complement it.<br />
This document could also include informations on how to extend the whiteboard to help future contributors.<br />
<br />
Where should this document go?<br />
*In doxygen<br />
:This makes sense since it's where most of the code documentation is.<br />
*In the wiki<br />
:This would make collaborative editing easier.<br />
<br />
If you have an opinion on this, let me know. :)<br />
<br />
===Timeline===<br />
Two of my five tasks are actually best done continuously: the design document and the polishing.<br />
Although I haven't clearly placed a week for them, I set two dates at which they should have been completed.<br />
<br />
Of course, the plan is not to have any delay and to finish each task early, however I have reserved two weeks (actually one week and a half) for unexpected delay.<br />
I named them "movable weeks", because they can move in my timeline if anything goes wrong. :)<br />
<br />
<!-- Wikitext hell 101 --><br />
{| style="border:1px dashed #AAA;border-collapse:collapse;"<br />
|-<br />
!style="border:1px dotted #AAA;padding:5px;"|Date<br />
!style="border:1px dotted #AAA;padding:5px;"|Week<br />
!style="border:1px dotted #AAA;padding:5px;"|Description<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''17/03 - 20/04''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''-11..-5''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Student application evaluation''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|17/03 - 20/04<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|-11..-5<br />
|style="border:1px dotted #AAA;padding:5px;"|Refine the proposal.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''23/04 - 20/05''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''-4..-1''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Community Bonding Period (4 weeks)''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|'''23/04 - 20/05'''<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|'''-4..-1'''<br />
|style="border:1px dotted #AAA;padding:5px;"|'''Phase 0: Approach'''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|23/04 - 20/05<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|-4..-1<br />
|style="border:1px dotted #AAA;padding:5px;"|Familiarise myself with the whiteboard, in the process start a draft of the design document.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|23/04 - 20/05<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|-4..-1<br />
|style="border:1px dotted #AAA;padding:5px;"|Start working on the ''polishing'' and on small parts of the whiteboard in order to gain commit access.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''21/05''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''0''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Start of GSoC''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|21/05 - 12/08<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|0..11<br />
|style="border:1px dotted #AAA;padding:5px;"|Continuously work on the design document and on the code polishing.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''21/05 - 15/07''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''0..7''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''First half term (8 weeks)''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|'''21/05 - 10/06'''<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|'''0..2'''<br />
|style="border:1px dotted #AAA;padding:5px;"|'''Phase 1: <tt>side_actions</tt> refactoring'''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|21/05 - 27/05<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|0<br />
|style="border:1px dotted #AAA;padding:5px;"|Prepare <tt>side_actions</tt> for the change. Add debug informations to the logs. Make the current iterators bidirectional.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|28/05 - 03/06<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|1<br />
|style="border:1px dotted #AAA;padding:5px;"|Change the underlying container and rewrite the associated functions.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|04/06 - 10/06<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|2<br />
|style="border:1px dotted #AAA;padding:5px;"|Debug, write unit test and documentation.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|'''11/06 - 01/07'''<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|'''3..5'''<br />
|style="border:1px dotted #AAA;padding:5px;"|'''Phase 2: Validator hierarchy refactoring'''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|11/06 - 17/06<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|3<br />
|style="border:1px dotted #AAA;padding:5px;"|Write the class <tt>action_inquirer</tt>.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|18/06 - 24/06<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|4<br />
|style="border:1px dotted #AAA;padding:5px;"|Replace the uses of <tt>enable_visit_all</tt> with the new interface. Then delete <tt>enable_visit_all</tt>.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|25/06 - 01/07<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|5<br />
|style="border:1px dotted #AAA;padding:5px;"|Debug, write unit test and documentation.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|'''02/07 - 22/07'''<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|'''6..8'''<br />
|style="border:1px dotted #AAA;padding:5px;"|'''Phase 3: Merging of the validation process into <tt>mapbuilder</tt>'''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|02/07 - 08/07<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|6<br />
|style="border:1px dotted #AAA;padding:5px;"|Merge <tt>validate_visitor</tt> into <tt>mapbuilder</tt>.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|09/07 - 15/07<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|7<br />
|style="border:1px dotted #AAA;padding:5px;"|Hunt down other validity check in the <tt>action</tt> hierarchy and move them to <tt>mapbuilder</tt>.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''13/07''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''7''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Mid-term evaluation''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''16/07 - 26/08''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''8..13''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Second half term (6 weeks)''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|16/07 - 22/07<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|8<br />
|style="border:1px dotted #AAA;padding:5px;"|Debug, write unit test and documentation.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|'''22/07 - 12/08'''<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|'''9..11'''<br />
|style="border:1px dotted #AAA;padding:5px;"|'''Phase 4: Finalisation'''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|22/07 - 29/07<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|9<br />
|style="border:1px dotted #AAA;padding:5px;"|Heavy testing week.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|30/07 - 05/08<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|10<br />
|style="border:1px dotted #AAA;padding:5px;"|Test, debug. Finish the ''polishing''.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|06/08 - 12/08<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|11<br />
|style="border:1px dotted #AAA;padding:5px;"|Test, debug. Finish the design document.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|13/08 - 19/08<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|12<br />
|style="border:1px dotted #AAA;padding:5px;"|Movable week.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|20/08 - 26/08<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|13<br />
|style="border:1px dotted #AAA;padding:5px;"|Movable week.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''24/08''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''13''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Final evaluation''<br />
|}</div>Ejlshttps://wiki.wesnoth.org/index.php?title=User:Ejls/GSoC_2012/Whiteboard_Backend_Refactoring&diff=45948User:Ejls/GSoC 2012/Whiteboard Backend Refactoring2012-03-31T06:02:47Z<p>Ejls: (ter)</p>
<hr />
<div><!--<br />
Excuse the heavy wikitext, I tried to make it as readable as possible and I put a lot of comments.<br />
-->__NOTOC__<!--<br />
-->__NOEDITSECTION__<!--<br />
-->{{SoC2012Student}}<!--<br />
-->[[Category:SoC_Ideas_Whiteboard_Backend_Refactoring_2012]]<!--<br />
-->'''''Note: This proposal is in continuous construction, if you have any remark, please drop me a line on IRC or on the [[{{TALKPAGENAME}}|talk page]].'''''<br /><br /><br />
<br />
<!--***********************************************************************<br />
* * Table of Content * *<br />
* ******************** *<br />
* *<br />
* WARNING: don't forget to add a TOC entry when adding a new section. *<br />
***********************************************************************--><br />
{|style="background:#FAF3E9;margin:none;padding:5px;border:3px double #AAA;-moz-border-radius:20px 5px 20px 5px;-webkit-border-radius:20px 5px 20px 5px;border-radius:20px 5px 20px 5px;"<br />
|-<br />
| style="text-align: center; padding: 0px 10px 5px 10px;"|'''Content'''<hr /><br />
|-<br />
| style="text-align: left; padding:0px 10px 10px 10px;"|<br />
[[#Description|Description]]<br /><br />
[[#Contact|Contact]]<br /><br />
<!--[[#SoC Application|SoC Application]]<br /><br />
-->[[#Questionnaire|Questionnaire]]<br /><br />
:[[#1) Basics|1 - Basics]]<br /><br />
:[[#2) Experience|2 - Experience]]<br /><br />
:[[#3) Communication skills|3 - Communication skills]]<br /><br />
:[[#4) Project|4 - Project]]<br /><br />
:[[#5) Practical considerations|5 - Practical considerations]]<br /><br />
[[#Proposal|Proposal]]<br /><br />
:[[#The problems|The problems]]<br /><br />
:[[#side_actions|<tt>side_actions</tt> refactoring]]<br /><br />
::[[#side_actions.situation|The current situation]]<br /><br />
::[[#side_actions.idea|The idea]]<br /><br />
::[[#side_actions.implementation|Implementation details]]<br /><br />
:::[[#side_actions.containers|Choice of the containers]]<br /><br />
:::[[#side_actions.example|Example]]<br /><br />
:[[#visitorhier|Visitor hierarchy refactoring]]<br /><br />
::[[#visitorhier.situation|The current situation]]<br /><br />
::[[#visitorhier.idea|The idea]]<br /><br />
::[[#visitorhier.implementation|Implementation details]]<br /><br />
:::[[#visitorhier.example|Example]]<br /><br />
:[[#mapbuilder|Merging of the validation process into <tt>mapbuilder</tt>]]<br /><br />
::[[#mapbuilder.situation|The current situation]]<br /><br />
::[[#mapbuilder.idea|The idea]]<br /><br />
::[[#mapbuilder.implementation|Implementation details]]<br /><br />
:::[[#mapbuilder.example|Example]]<br /><br />
:[[#polishing|Polishing]]<br /><br />
:[[#designdoc|Design document]]<br /><br />
:[[#Timeline|Timeline]]<br /><br />
|}<br />
<br />
<!--***********************************************************************<br />
* * Description * *<br />
* *************** *<br />
* *<br />
* This section is inserted in the SummerOfCodeIdeas page. It contains *<br />
* only a header of level 4 and a small paragraph summing up the *<br />
* proposal. *<br />
***********************************************************************--><br />
==Description==<br />
=====Étienne Simon - Whiteboard backend polishing=====<br />
My project is to make the whiteboard code cleaner and to redesign small parts of it to speed it up. Apart from the visitor hierarchy refactoring, the global design of the whiteboard won't be changed, each part will be reviewed individually. I'm not only planning to improve the whiteboard backend, but also to document the overall design and each part of it as well as to write a wide variety of test to improve its stability.<br />
<br />
<!--***********************************************************************<br />
* * SoC Application * *<br />
* ******************* *<br />
* *<br />
* This section affect the SummerOfCodeIdeas page, if it contains the *<br />
* text "Submitted to google", the application will appear in the *<br />
* "Student proposals submitted both to wiki and google" section, *<br />
* otherwise it'll appear in the "Student proposals not submitted to *<br />
* google" section. *<br />
***********************************************************************--><!--<br />
==SoC Application==<br />
Not yet submitted.<br />
--><br />
<br />
<!--***********************************************************************<br />
* * Contact * *<br />
* *********** *<br />
* *<br />
* The IRC subsection is inserted in the SummerOfCodeIdeas page. It *<br />
* must only contain the IRC nick identifying the author. *<br />
***********************************************************************--><br />
==Contact==<br />
{|<br />
|-<br />
|<br />
=====IRC=====<br />
<span style="color:#3F475E;">ejls </span><br />
=====Email=====<br />
Address at gmail dot com: etienne.jl.simon<br />
| style="width:10em;" |<br />
|<br />
=====Forum=====<br />
ejls<br />
=====Gna=====<br />
ejls<br />
|}<br />
<br />
<!--***********************************************************************<br />
* * Questionnaire * *<br />
* ***************** *<br />
* *<br />
* Although I'm submitting only one application (and so only one *<br />
* questionnaire), I thought it was more elegant to make the *<br />
* questionnaire page reusable. Which explain why it's a template. *<br />
* Like I wrote in the Questionnaire subpage, the argument to this *<br />
* template are the answer to the proposal-specific questions. I order *<br />
* to make the sources more comprehensible, I wrote the corresponding *<br />
* question in comments at the beginning of each parameter. *<br />
***********************************************************************--><br />
{{User:Ejls/GSoC 2012/Questionnaire<br />
|<!-- 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? --><br />
''This is a summary, more details can be found [http://wiki.wesnoth.org/User:Ejls/GSoC%202012/Whiteboard%20Backend%20Refactoring#Proposal here].''<br />
<br />
I have chosen [[SoC Ideas Whiteboard Backend Refactoring 2012]]. This project is the only one not adding any feature for the user, the main goal is to refactor code, write test and documentation. It follows [http://wiki.wesnoth.org/GSoC-WesnothWhiteboard_Gabba gabba's project] and [http://wiki.wesnoth.org/User:Tschmitz tschmitz's project] on the whiteboard. Although it doesn't add any feature for the user in itself, I hope it'll help future development of the whiteboard.<!--<br />
-->|<!-- 4.2) If you have invented your own project, please describe the project and the scope. --><br />
I chose a project from the list, namely [[SoC Ideas Whiteboard Backend Refactoring 2012]]. C.f. above answer.<!--<br />
-->|<!-- 4.3) Why did you choose this project? --><br />
I liked the idea behind the whiteboard, I think it might be a big plus to Wesnoth. Furthermore, I liked how C++ is used in its code (especially the heavy use of SBRM). However it looks like the whiteboard is not widely used, and I would like to help changing that! :)<!--<br />
-->|<!-- 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". --><br />
''This is a summary, more details can be found [http://wiki.wesnoth.org/User:Ejls/GSoC%202012/Whiteboard%20Backend%20Refactoring#Timeline here].''<br />
<br />
I separated my summer in five phases:<br />
*Phase 0: Approach (4 weeks)<br />
::→ Start working on the design document. Start the ''polishing''.<br />
*Phase 1: <tt>side_actions</tt> refactoring (3 weeks)<br />
*Phase 2: Validator hierarchy refactoring (3 weeks)<br />
*Phase 3: Merging of the validation process into <tt>mapbuilder</tt> (3 weeks)<br />
*Phase 4: Finalisation (3 weeks)<br />
::→ Finish the design document. Finish the ''polishing''. Test. Test. Test.<!--<br />
-->|<!-- 4.5) Include as much technical detail about your implementation as you can --><br />
''This is a summary, more details can be found [http://wiki.wesnoth.org/User:Ejls/GSoC%202012/Whiteboard%20Backend%20Refactoring#Proposal here].''<br />
<br />
I separated my project in five tasks:<br />
;<tt>side_actions</tt> refactoring<br />
:Change of the underlying container, creation of new look up functions.<br />
;Visitor hierarchy refactoring<br />
:Replacement of the <tt>enable_visit_all</tt> by a new interface over all of the <tt>side_actions</tt> objects.<br />
;Merging of the validation process into <tt>mapbuilder</tt><br />
:Deletion of the <tt>validate_visitor</tt> class, injection of its code and other validation code from the <tt>action</tt> hierarchy into <tt>mapbuilder</tt>.<br />
;Polishing<br />
:Code uniformisation, small improvements.<br />
;Design document<br />
:Documentation of the global whiteboard design.<!--<br />
-->|<!-- 4.6) What do you expect to gain from this project? --><br />
I hope it'll help me to join the open source developer community. Actually, the preparation of this proposal already helped me a lot, for example my first patch got committed, it wasn't a big patch, but it was my first step of a (I hope) long path. :) So, I hope to continue learning to walk with the wesnoth community (sorry for the silly metaphor.)<!--<br />
-->|<!-- 4.7) What would make you stay in the Wesnoth community after the conclusion of SOC? --><br />
If my work is appreciated, I would rather ask: what would make me leave the Wesnoth community?.<!--<br />
-->}}<br />
<br />
<!--***********************************************************************<br />
* * Proposal * *<br />
* ************ *<br />
* *<br />
* Finally, my proposal. ;) *<br />
***********************************************************************--><br />
==Proposal==<br />
===The problems===<br />
In the [[SoC_Ideas_Whiteboard_Backend_Refactoring_2012|Whiteboard Backend Refactoring idea page]], several problems are listed, here is how I'm planning to fix them:<br />
{| style="border:1px dashed #AAA;border-collapse:collapse;"<br />
|-<br />
!style="border:1px dotted #AAA;padding:5px;"|Problem<br />
!style="border:1px dotted #AAA;padding:5px;"|Solution<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|<tt>side_actions</tt> complexity<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#side_actions|<tt>side_actions</tt> refactoring]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|Redundancy between <tt>mapbuilder</tt> and <tt>validate_visitor</tt><br />
|style="border:1px dotted #AAA;padding:5px;"|[[#mapbuilder|Merging of the validation process into <tt>mapbuilder</tt>]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|Highlighter slowness<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#side_actions|<tt>side_actions</tt> refactoring]] and [[#visitorhier|Visitor hierarchy refactoring]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|Friend classes vs everything in the action classes<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#visitorhier|Visitor hierarchy refactoring]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|Unit pointer recovery uniformisation<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#polishing|Polishing]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|<tt>boost::dynamic_pointer_cast</tt> vs simple numeric id<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#polishing|Polishing]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|Documentation<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#designdoc|Design document]]<br />
|}<br />
<br />
===<span id="side_actions"><tt>side_actions</tt> refactoring</span>===<br />
====<span id="side_actions.situation">The current situation</span>====<br />
The current implementation of <tt>side_actions</tt> use a <tt>std::deque&lt;std::deque&lt;action_ptr&gt;&gt;</tt>.<br />
In order to use it, iterators have been defined over it (<tt>side_actions::iterator</tt> and the three const and revert variants).<br />
These “flattening” iterators let users of <tt>side_actions</tt> iterate over all the planned actions, they are performing the ''zip'' operation on the fly.<br />
<br />
Furthermore, some queries like <tt>side_actions::find_first_action_of</tt> are linear in the number of action.<br />
<br />
====<span id="side_actions.idea">The idea</span>====<br />
To simplify the code, I propose to keep the action set zipped. The container's iterators will then be usable directly. In order to delimit turns, a second container will have to keep a sequence of iterators pointing to the first action of each turn.<br />
<br />
For example, let's say eight actions are planned: five for this turn, two for the next turn and one for the turn after. Three iterators will be kept to delimit turns. Here is a proof that I can't use gimp which also show the idea:<br />
http://epsilon012.free.fr/GSoC%202012/side_actions%20idea.png<br />
<br />
Of course another problem emerge: the sequence of iterator has to be kept in sync with the sequence of action.<br />
<br />
Finally, the current implementation gives access to the <tt>action_ptr</tt> only in sequence, in order to speed up different way of querying action (e.g. by hex, by unit's id), I propose to build several indexes on the action set.<br />
<br />
====<span id="side_actions.implementation">Implementation details</span>====<br />
Let's name these containers <tt>actions_</tt> and <tt>turn_beginnings_</tt>.<br />
<br />
The whiteboard have the following invariant: an empty turn (a turn without planned action) can't be followed by a non-empty turn (with at least one planned action). It means that <code>distance(turn_beginnings_[i], turn_beginnings_[i+1])&gt;0</code>, and so we can unambiguously determine the turn number of each action.<br />
<br />
Also, note that except when <tt>actions_.empty()</tt> : <tt>turn_beginnings_.front()==actions_.begin()</tt>.<br />
<br />
=====<span id="side_actions.containers">Choice of the containers</span>=====<br />
<tt>std::deque</tt> seems to be the perfect container for <tt>turn_beginnings_</tt>. It'll allow random access and we need to add/remove new turns only at the extremities.<br />
<br />
On the other hand, <tt>actions_</tt> need two proprieties:<br />
*Allow fast chronological iteration<br />
*Stable iterators<br />
*Allow fast lookup on different indexes<br />
I propose to use a <tt>boost::multi_index_container</tt>, this container is part of the library [http://www.boost.org/doc/libs/1_49_0/libs/multi_index Boost.MultiIndex] which is in Boost since version 1.32. It allows the construction of several indexes on the same set of object.<br />
<br />
There is however one problem linked to the use of the <tt>boost::multi_index::random_access</tt> index: insertion and deletion are in linear time when their are not done at the extremities.<br />
<br />
So, the new members should be:<br />
namespace bmi = boost::multi_index;<br />
typedef bmi::multi_index_container<<br />
action_ptr,<br />
bmi::indexed_by<<br />
bmi::random_access<bmi::tag<chronological> >,<br />
bmi::hashed_non_unique<bmi::tag<by_unit>, bmi::const_mem_fun<action,size_t,&action::get_unit_id> >,<br />
bmi::hashed_non_unique<bmi::tag<by_hex>, bmi::const_mem_fun<action,size_t,&action::get_hex>><br />
><br />
> action_set;<br />
typedef action_set::iterator iterator;<br />
<br />
action_set actions_;<br />
std::deque<iterator> turn_beginnings_;<br />
<br />
This suppose two new pure virtual function in <tt>action</tt>: <tt>get_unit_id</tt> and <tt>get_hex</tt>.<br />
<br />
Using action's attribute as key brings another drawback: we must notify the <tt>multi_index_container</tt> when we modify a key.<br />
However, the two used keys here (the unit's id and the hex) are never modified in the <tt>action</tt> hierarchy.<br />
<br />
This definition is here to give an idea, in practice other indexes will have to be built (e.g. an index on ''secondary hex'' which could be the source hex in <tt>move</tt>.)<br />
Note that this doesn't necessarily means a new pure virtual function in <tt>action</tt>, a key extractor can be defined to let <tt>action</tt> as it is and use ''RTTI'' instead (this might not be clever though.)<br />
<br />
=====<span id="side_actions.example">Example</span>=====<br />
Here are three functions rewritten with this new design. Note that <tt>side_actions::iterator</tt> is the one defined above.<br />
side_actions::iterator side_actions::end_turn(size_t turn_num){<br />
if(turn_num+1>=turn_beginnings_.size())<br />
return actions_.end();<br />
else<br />
return turn_beginnings_[turn_num+1];<br />
}<br />
<br />
side_actions::iterator side_actions::raw_enqueue(size_t turn_num, action_ptr act){<br />
assert(turn_num <= turn_beginnings_.size());<br />
<br />
iterator new_action = actions_.insert(end_turn(turn_num), act).first;<br />
<br />
if(turn_num >= turn_beginnings_.size())<br />
turn_beginnings_.push_back(new_action);<br />
<br />
return new_action;<br />
}<br />
<br />
side_actions::find_first_action_of(unit const* unit, side_actions::iterator start_position){<br />
// First we get all the action of this unit<br />
typedef action_set::index<by_unit>::type::iterator unit_iterator;<br />
std::pair<unit_iterator, unit_iterator> act = actions_.get<by_unit>().equal_range(unit->underlying_id());<br />
<br />
// Then we find the first of them (chronologically) after start_position<br />
iterator first = actions_.end();<br />
for(unit_iterator it = act.first; it != act.second; ++it){<br />
iterator chrono_it = actions_.project<chronological>(it);<br />
if(chrono_it < first && chrono_it > start_position)<br />
first = chrono_it;<br />
}<br />
return first;<br />
}<br />
<br />
===<span id="visitorhier">Visitor hierarchy refactoring</span>===<br />
====<span id="visitorhier.situation">The current situation</span>====<br />
The important classes and class templates of this hierarchy are:<br />
*'''<tt>visitor</tt>''' is the base class of the visitor hierarchy, it dispatches the calls to the derived classes.<br />
*'''<tt>enable_visit_all</tt>''' is actually an interface to the <tt>action_ptr</tt> objects of every single team.<br />
*'''<tt>action</tt>''' is the root class of the visitable hierarchy.<br />
<br />
Currently, when the visitor hierarchy needs to visit the visitable hierarchy, all the actions of every sides of every turn are visited using the function <tt>enable_visit_all::visit_all_helper</tt> (e.g. this function is called by <tt>highlight_visitor::find_main_highlight</tt> to find the action to highlight.)<br />
<br />
====<span id="visitorhier.idea">The idea</span>====<br />
I'm favorable to the maintain of the Visitor pattern, it segregates the different components nicely.<br />
I think the problem come from <tt>enable_visit_all</tt> and I would like to replace it with a class offering a more fine-grained access to the actions.<br />
For example, a look up by hex could be defined in this new structure and then used by <tt>highlight_visitor</tt>.<br />
Actually, most of the work of this new class will have to do is to redirect the calls to the <tt>side_actions</tt> (to one in particular or to all depending on the function).<br />
<br />
====<span id="visitorhier.implementation">Implementation details</span>====<br />
Let's name this interface <tt>action_inquirer</tt>, I'm not a particularly good English speaker, so if you have a better name in mind, let me know. :)<br />
<br />
The sole problem faced is to place <tt>action_inquirer</tt>, since it is mainly a proxy to a global resource (the <tt>side_actions</tt> of each team), it makes sense to place it directly in the <tt>wb</tt> namespace.<br />
<br />
=====<span id="visitorhier.example">Example</span>=====<br />
Here is an example function that would speed up <tt>highlight_visitor</tt>.<br />
action_ptr action_inquirer::action_at(map_location const &h){<br />
side_actions::iterator r;<br />
foreach(team& t, *resources::teams){<br />
side_actions sa = t.get_side_actions();<br />
if((r=sa.find_action_at(h)) != sa.end())<br />
return *r;<br />
}<br />
return action_ptr();<br />
}<br />
<br />
Note: the implementation of <tt>side_actions::find_action_at</tt> is similar to the one of <tt>side_actions::find_first_action_of</tt>.<br />
<br />
===<span id="mapbuilder">Merging of the validation process into <tt>mapbuilder</tt></span>===<br />
====<span id="mapbuilder.situation">The current situation</span>====<br />
Currently the validation process is separated from the mapbuilding process.<br />
However they are depending on each other.<br />
Indeed, to validate an action the previous actions have to be applied (by the mapbuilder), while in order to build the future state in the mapbuilder, the sequence of action have to be valid.<br />
<br />
====<span id="mapbuilder.idea">The idea</span>====<br />
Inject the validation process into <tt>mapbuilder</tt>. This is not limited to the merging of <tt>validate_visitor</tt> into <tt>mapbuilder</tt>, indeed some validity check are also done in the <tt>action</tt> hierarchy.<br />
<br />
====<span id="mapbuilder.implementation">Implementation details</span>====<br />
I'm still working on this.<br />
<br />
=====<span id="mapbuilder.example">Example</span>=====<br />
Idem.<br />
<br />
===<span id="polishing">Polishing</span>===<br />
Some inconsistencies are present in the code (e.g. the way units are referenced). Some other parts needs clean up or/and optimisation (e.g. usage of <tt>boost::dynamic_pointer_cast</tt>).<br />
<br />
The goal of this task is to find this kind of small problem and fix them.<br />
These two ones have been spotted by gabba, but I'm planning to add other small problems to this list as I found them.<br />
<br />
Also, they can be a good introduction to the code that's why I'm planning to start working on them before the GSoC start date.<br />
<br />
===<span id="designdoc">Design document</span>===<br />
This idea is inspired by the GUI2 design document present in the SVN.<br />
<br />
Doxygen documents the code at a function or class level.<br />
The goal is to write a documentation at the module level. That is a document describing the whiteboard design globally and not function-by-function.<br />
Actually it shouldn't duplicate what is in doxygen but complement it.<br />
This document could also include informations on how to extend the whiteboard to help future contributors.<br />
<br />
Where should this document go?<br />
*In doxygen<br />
:This makes sense since it's where most of the code documentation is.<br />
*In the wiki<br />
:This would make collaborative editing easier.<br />
<br />
If you have an opinion on this, let me know. :)<br />
<br />
===Timeline===<br />
Two of my five tasks are actually best done continuously: the design document and the polishing.<br />
Although I haven't clearly placed a week for them, I set two dates at which they should have been completed.<br />
<br />
Of course, the plan is not to have any delay and to finish each task early, however I have reserved two weeks (actually one week and a half) for unexpected delay.<br />
I named them "movable weeks", because they can move in my timeline if anything goes wrong. :)<br />
<br />
<!-- Wikitext hell 101 --><br />
{| style="border:1px dashed #AAA;border-collapse:collapse;"<br />
|-<br />
!style="border:1px dotted #AAA;padding:5px;"|Date<br />
!style="border:1px dotted #AAA;padding:5px;"|Week<br />
!style="border:1px dotted #AAA;padding:5px;"|Description<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''17/03 - 20/04''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''-11..-5''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Student application evaluation''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|17/03 - 20/04<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|-11..-5<br />
|style="border:1px dotted #AAA;padding:5px;"|Refine the proposal.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''23/04 - 20/05''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''-4..-1''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Community Bonding Period (4 weeks)''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|'''23/04 - 20/05'''<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|'''-4..-1'''<br />
|style="border:1px dotted #AAA;padding:5px;"|'''Phase 0: Approach'''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|23/04 - 20/05<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|-4..-1<br />
|style="border:1px dotted #AAA;padding:5px;"|Familiarise myself with the whiteboard, in the process start a draft of the design document.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|23/04 - 20/05<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|-4..-1<br />
|style="border:1px dotted #AAA;padding:5px;"|Start working on the ''polishing'' and on small parts of the whiteboard in order to gain commit access.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''21/05''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''0''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Start of GSoC''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|21/05 - 12/08<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|0..11<br />
|style="border:1px dotted #AAA;padding:5px;"|Continuously work on the design document and on the code polishing.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''21/05 - 15/07''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''0..7''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''First half term (8 weeks)''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|'''21/05 - 10/06'''<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|'''0..2'''<br />
|style="border:1px dotted #AAA;padding:5px;"|'''Phase 1: <tt>side_actions</tt> refactoring'''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|21/05 - 27/05<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|0<br />
|style="border:1px dotted #AAA;padding:5px;"|Prepare <tt>side_actions</tt> for the change. Add debug informations to the logs. Make the current iterators bidirectional.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|28/05 - 03/06<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|1<br />
|style="border:1px dotted #AAA;padding:5px;"|Change the underlying container and rewrite the associated functions.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|04/06 - 10/06<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|2<br />
|style="border:1px dotted #AAA;padding:5px;"|Debug, write unit test and documentation.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|'''11/06 - 01/07'''<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|'''3..5'''<br />
|style="border:1px dotted #AAA;padding:5px;"|'''Phase 2: Validator hierarchy refactoring'''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|11/06 - 17/06<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|3<br />
|style="border:1px dotted #AAA;padding:5px;"|Write the class <tt>action_inquirer</tt>.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|18/06 - 24/06<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|4<br />
|style="border:1px dotted #AAA;padding:5px;"|Replace the uses of <tt>enable_visit_all</tt> with the new interface. Then delete <tt>enable_visit_all</tt>.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|25/06 - 01/07<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|5<br />
|style="border:1px dotted #AAA;padding:5px;"|Debug, write unit test and documentation.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|'''02/07 - 22/07'''<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|'''6..8'''<br />
|style="border:1px dotted #AAA;padding:5px;"|'''Phase 3: Merging of the validation process into <tt>mapbuilder</tt>'''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|02/07 - 08/07<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|6<br />
|style="border:1px dotted #AAA;padding:5px;"|Merge <tt>validate_visitor</tt> into <tt>mapbuilder</tt>.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|09/07 - 15/07<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|7<br />
|style="border:1px dotted #AAA;padding:5px;"|Hunt down other validity check in the <tt>action</tt> hierarchy and move them to <tt>mapbuilder</tt>.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''13/07''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''7''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Mid-term evaluation''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''16/07 - 26/08''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''8..13''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Second half term (6 weeks)''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|16/07 - 22/07<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|8<br />
|style="border:1px dotted #AAA;padding:5px;"|Debug, write unit test and documentation.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|'''22/07 - 12/08'''<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|'''9..11'''<br />
|style="border:1px dotted #AAA;padding:5px;"|'''Phase 4: Finalisation'''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|22/07 - 29/07<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|9<br />
|style="border:1px dotted #AAA;padding:5px;"|Heavy testing week.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|30/07 - 05/08<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|10<br />
|style="border:1px dotted #AAA;padding:5px;"|Test, debug. Finish the ''polishing''.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|06/08 - 12/08<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|11<br />
|style="border:1px dotted #AAA;padding:5px;"|Test, debug. Finish the design document.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|13/08 - 19/08<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|12<br />
|style="border:1px dotted #AAA;padding:5px;"|Movable week.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|20/08 - 26/08<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|13<br />
|style="border:1px dotted #AAA;padding:5px;"|Movable week.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''24/08''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''13''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Final evaluation''<br />
|}</div>Ejlshttps://wiki.wesnoth.org/index.php?title=User:Ejls/GSoC_2012/Whiteboard_Backend_Refactoring&diff=45947User:Ejls/GSoC 2012/Whiteboard Backend Refactoring2012-03-31T05:46:31Z<p>Ejls: bis</p>
<hr />
<div><!--<br />
Excuse the heavy wikitext, I tried to make it as readable as possible and I put a lot of comments.<br />
-->__NOTOC__<!--<br />
-->__NOEDITSECTION__<!--<br />
-->{{SoC2012Student}}<!--<br />
-->[[Category:SoC_Ideas_Whiteboard_Backend_Refactoring_2012]]<!--<br />
-->'''''Note: This proposal is in continuous construction, if you have any remark, please drop me a line on IRC or on the [[{{TALKPAGENAME}}|talk page]].'''''<br /><br /><br />
<br />
<!--***********************************************************************<br />
* * Table of Content * *<br />
* ******************** *<br />
* *<br />
* WARNING: don't forget to add a TOC entry when adding a new section. *<br />
***********************************************************************--><br />
{|style="background:#FAF3E9;margin:none;padding:5px;border:3px double #AAA;-moz-border-radius:20px 5px 20px 5px;-webkit-border-radius:20px 5px 20px 5px;border-radius:20px 5px 20px 5px;"<br />
|-<br />
| style="text-align: center; padding: 0px 10px 5px 10px;"|'''Content'''<hr /><br />
|-<br />
| style="text-align: left; padding:0px 10px 10px 10px;"|<br />
[[#Description|Description]]<br /><br />
[[#Contact|Contact]]<br /><br />
<!--[[#SoC Application|SoC Application]]<br /><br />
-->[[#Questionnaire|Questionnaire]]<br /><br />
:[[#1) Basics|1 - Basics]]<br /><br />
:[[#2) Experience|2 - Experience]]<br /><br />
:[[#3) Communication skills|3 - Communication skills]]<br /><br />
:[[#4) Project|4 - Project]]<br /><br />
:[[#5) Practical considerations|5 - Practical considerations]]<br /><br />
[[#Proposal|Proposal]]<br /><br />
:[[#The problems|The problems]]<br /><br />
:[[#side_actions|<tt>side_actions</tt> refactoring]]<br /><br />
::[[#side_actions.situation|The current situation]]<br /><br />
::[[#side_actions.idea|The idea]]<br /><br />
::[[#side_actions.implementation|Implementation details]]<br /><br />
:::[[#side_actions.containers|Choice of the containers]]<br /><br />
:::[[#side_actions.example|Example]]<br /><br />
:[[#visitorhier|Visitor hierarchy refactoring]]<br /><br />
::[[#visitorhier.situation|The current situation]]<br /><br />
::[[#visitorhier.idea|The idea]]<br /><br />
::[[#visitorhier.implementation|Implementation details]]<br /><br />
:::[[#visitorhier.example|Example]]<br /><br />
:[[#mapbuilder|Merging of the validation process into <tt>mapbuilder</tt>]]<br /><br />
::[[#mapbuilder.situation|The current situation]]<br /><br />
::[[#mapbuilder.idea|The idea]]<br /><br />
::[[#mapbuilder.implementation|Implementation details]]<br /><br />
:::[[#mapbuilder.example|Example]]<br /><br />
:[[#polishing|Polishing]]<br /><br />
:[[#designdoc|Design document]]<br /><br />
:[[#Timeline|Timeline]]<br /><br />
|}<br />
<br />
<!--***********************************************************************<br />
* * Description * *<br />
* *************** *<br />
* *<br />
* This section is inserted in the SummerOfCodeIdeas page. It contains *<br />
* only a header of level 4 and a small paragraph summing up the *<br />
* proposal. *<br />
***********************************************************************--><br />
==Description==<br />
=====Étienne Simon - Whiteboard backend polishing=====<br />
My project is to make the whiteboard code cleaner and to redesign small parts of it to speed it up. Apart from the visitor hierarchy refactoring, the global design of the whiteboard won't be changed, each part will be reviewed individually. I'm not only planning to improve the whiteboard backend, but also to document the overall design and each part of it as well as to write a wide variety of test to improve its stability.<br />
<br />
<!--***********************************************************************<br />
* * SoC Application * *<br />
* ******************* *<br />
* *<br />
* This section affect the SummerOfCodeIdeas page, if it contains the *<br />
* text "Submitted to google", the application will appear in the *<br />
* "Student proposals submitted both to wiki and google" section, *<br />
* otherwise it'll appear in the "Student proposals not submitted to *<br />
* google" section. *<br />
***********************************************************************--><!--<br />
==SoC Application==<br />
Not yet submitted.<br />
--><br />
<br />
<!--***********************************************************************<br />
* * Contact * *<br />
* *********** *<br />
* *<br />
* The IRC subsection is inserted in the SummerOfCodeIdeas page. It *<br />
* must only contain the IRC nick identifying the author. *<br />
***********************************************************************--><br />
==Contact==<br />
{|<br />
|-<br />
|<br />
=====IRC=====<br />
<span style="color:#3F475E;">ejls</span><br />
=====Email=====<br />
Address at gmail dot com: etienne.jl.simon<br />
| style="width:10em;" |<br />
|<br />
=====Forum=====<br />
ejls<br />
=====Gna=====<br />
ejls<br />
|}<br />
<br />
<!--***********************************************************************<br />
* * Questionnaire * *<br />
* ***************** *<br />
* *<br />
* Although I'm submitting only one application (and so only one *<br />
* questionnaire), I thought it was more elegant to make the *<br />
* questionnaire page reusable. Which explain why it's a template. *<br />
* Like I wrote in the Questionnaire subpage, the argument to this *<br />
* template are the answer to the proposal-specific questions. I order *<br />
* to make the sources more comprehensible, I wrote the corresponding *<br />
* question in comments at the beginning of each parameter. *<br />
***********************************************************************--><br />
{{User:Ejls/GSoC 2012/Questionnaire<br />
|<!-- 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? --><br />
''This is a summary, more details can be found [http://wiki.wesnoth.org/User:Ejls/GSoC%202012/Whiteboard%20Backend%20Refactoring#Proposal here].''<br />
<br />
I have chosen [[SoC Ideas Whiteboard Backend Refactoring 2012]]. This project is the only one not adding any feature for the user, the main goal is to refactor code, write test and documentation. It follows [http://wiki.wesnoth.org/GSoC-WesnothWhiteboard_Gabba gabba's project] and [http://wiki.wesnoth.org/User:Tschmitz tschmitz's project] on the whiteboard. Although it doesn't add any feature for the user in itself, I hope it'll help future development of the whiteboard.<!--<br />
-->|<!-- 4.2) If you have invented your own project, please describe the project and the scope. --><br />
I chose a project from the list, namely [[SoC Ideas Whiteboard Backend Refactoring 2012]]. C.f. above answer.<!--<br />
-->|<!-- 4.3) Why did you choose this project? --><br />
I liked the idea behind the whiteboard, I think it might be a big plus to Wesnoth. Furthermore, I liked how C++ is used in its code (especially the heavy use of SBRM). However it looks like the whiteboard is not widely used, and I would like to help changing that! :)<!--<br />
-->|<!-- 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". --><br />
''This is a summary, more details can be found [http://wiki.wesnoth.org/User:Ejls/GSoC%202012/Whiteboard%20Backend%20Refactoring#Timeline here].''<br />
<br />
I separated my summer in five phases:<br />
*Phase 0: Approach (4 weeks)<br />
::→ Start working on the design document. Start the ''polishing''.<br />
*Phase 1: <tt>side_actions</tt> refactoring (3 weeks)<br />
*Phase 2: Validator hierarchy refactoring (3 weeks)<br />
*Phase 3: Merging of the validation process into <tt>mapbuilder</tt> (3 weeks)<br />
*Phase 4: Finalisation (3 weeks)<br />
::→ Finish the design document. Finish the ''polishing''. Test. Test. Test.<!--<br />
-->|<!-- 4.5) Include as much technical detail about your implementation as you can --><br />
''This is a summary, more details can be found [http://wiki.wesnoth.org/User:Ejls/GSoC%202012/Whiteboard%20Backend%20Refactoring#Proposal here].''<br />
<br />
I separated my project in five tasks:<br />
;<tt>side_actions</tt> refactoring<br />
:Change of the underlying container, creation of new look up functions.<br />
;Visitor hierarchy refactoring<br />
:Replacement of the <tt>enable_visit_all</tt> by a new interface over all of the <tt>side_actions</tt> objects.<br />
;Merging of the validation process into <tt>mapbuilder</tt><br />
:Deletion of the <tt>validate_visitor</tt> class, injection of its code and other validation code from the <tt>action</tt> hierarchy into <tt>mapbuilder</tt>.<br />
;Polishing<br />
:Code uniformisation, small improvements.<br />
;Design document<br />
:Documentation of the global whiteboard design.<!--<br />
-->|<!-- 4.6) What do you expect to gain from this project? --><br />
I hope it'll help me to join the open source developer community. Actually, the preparation of this proposal already helped me a lot, for example my first patch got committed, it wasn't a big patch, but it was my first step of a (I hope) long path. :) So, I hope to continue learning to walk with the wesnoth community (sorry for the silly metaphor.)<!--<br />
-->|<!-- 4.7) What would make you stay in the Wesnoth community after the conclusion of SOC? --><br />
If my work is appreciated, I would rather ask: what would make me leave the Wesnoth community?.<!--<br />
-->}}<br />
<br />
<!--***********************************************************************<br />
* * Proposal * *<br />
* ************ *<br />
* *<br />
* Finally, my proposal. ;) *<br />
***********************************************************************--><br />
==Proposal==<br />
===The problems===<br />
In the [[SoC_Ideas_Whiteboard_Backend_Refactoring_2012|Whiteboard Backend Refactoring idea page]], several problems are listed, here is how I'm planning to fix them:<br />
{| style="border:1px dashed #AAA;border-collapse:collapse;"<br />
|-<br />
!style="border:1px dotted #AAA;padding:5px;"|Problem<br />
!style="border:1px dotted #AAA;padding:5px;"|Solution<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|<tt>side_actions</tt> complexity<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#side_actions|<tt>side_actions</tt> refactoring]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|Redundancy between <tt>mapbuilder</tt> and <tt>validate_visitor</tt><br />
|style="border:1px dotted #AAA;padding:5px;"|[[#mapbuilder|Merging of the validation process into <tt>mapbuilder</tt>]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|Highlighter slowness<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#side_actions|<tt>side_actions</tt> refactoring]] and [[#visitorhier|Visitor hierarchy refactoring]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|Friend classes vs everything in the action classes<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#visitorhier|Visitor hierarchy refactoring]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|Unit pointer recovery uniformisation<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#polishing|Polishing]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|<tt>boost::dynamic_pointer_cast</tt> vs simple numeric id<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#polishing|Polishing]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|Documentation<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#designdoc|Design document]]<br />
|}<br />
<br />
===<span id="side_actions"><tt>side_actions</tt> refactoring</span>===<br />
====<span id="side_actions.situation">The current situation</span>====<br />
The current implementation of <tt>side_actions</tt> use a <tt>std::deque&lt;std::deque&lt;action_ptr&gt;&gt;</tt>.<br />
In order to use it, iterators have been defined over it (<tt>side_actions::iterator</tt> and the three const and revert variants).<br />
These “flattening” iterators let users of <tt>side_actions</tt> iterate over all the planned actions, they are performing the ''zip'' operation on the fly.<br />
<br />
Furthermore, some queries like <tt>side_actions::find_first_action_of</tt> are linear in the number of action.<br />
<br />
====<span id="side_actions.idea">The idea</span>====<br />
To simplify the code, I propose to keep the action set zipped. The container's iterators will then be usable directly. In order to delimit turns, a second container will have to keep a sequence of iterators pointing to the first action of each turn.<br />
<br />
For example, let's say eight actions are planned: five for this turn, two for the next turn and one for the turn after. Three iterators will be kept to delimit turns. Here is a proof that I can't use gimp which also show the idea:<br />
http://epsilon012.free.fr/GSoC%202012/side_actions%20idea.png<br />
<br />
Of course another problem emerge: the sequence of iterator has to be kept in sync with the sequence of action.<br />
<br />
Finally, the current implementation gives access to the <tt>action_ptr</tt> only in sequence, in order to speed up different way of querying action (e.g. by hex, by unit's id), I propose to build several indexes on the action set.<br />
<br />
====<span id="side_actions.implementation">Implementation details</span>====<br />
Let's name these containers <tt>actions_</tt> and <tt>turn_beginnings_</tt>.<br />
<br />
The whiteboard have the following invariant: an empty turn (a turn without planned action) can't be followed by a non-empty turn (with at least one planned action). It means that <code>distance(turn_beginnings_[i], turn_beginnings_[i+1])&gt;0</code>, and so we can unambiguously determine the turn number of each action.<br />
<br />
Also, note that except when <tt>actions_.empty()</tt> : <tt>turn_beginnings_.front()==actions_.begin()</tt>.<br />
<br />
=====<span id="side_actions.containers">Choice of the containers</span>=====<br />
<tt>std::deque</tt> seems to be the perfect container for <tt>turn_beginnings_</tt>. It'll allow random access and we need to add/remove new turns only at the extremities.<br />
<br />
On the other hand, <tt>actions_</tt> need two proprieties:<br />
*Allow fast chronological iteration<br />
*Stable iterators<br />
*Allow fast lookup on different indexes<br />
I propose to use a <tt>boost::multi_index_container</tt>, this container is part of the library [http://www.boost.org/doc/libs/1_49_0/libs/multi_index Boost.MultiIndex] which is in Boost since version 1.32. It allows the construction of several indexes on the same set of object.<br />
<br />
There is however one problem linked to the use of the <tt>boost::multi_index::random_access</tt> index: insertion and deletion are in linear time when their are not done at the extremities.<br />
<br />
So, the new members should be:<br />
namespace bmi = boost::multi_index;<br />
typedef bmi::multi_index_container<<br />
action_ptr,<br />
bmi::indexed_by<<br />
bmi::random_access<bmi::tag<chronological> >,<br />
bmi::hashed_non_unique<bmi::tag<by_unit>, bmi::const_mem_fun<action,size_t,&action::get_unit_id> >,<br />
bmi::hashed_non_unique<bmi::tag<by_hex>, bmi::const_mem_fun<action,size_t,&action::get_hex>><br />
><br />
> action_set;<br />
typedef action_set::iterator iterator;<br />
<br />
action_set actions_;<br />
std::deque<iterator> turn_beginnings_;<br />
<br />
This suppose two new pure virtual function in <tt>action</tt>: <tt>get_unit_id</tt> and <tt>get_hex</tt>.<br />
<br />
Using action's attribute as key brings another drawback: we must notify the <tt>multi_index_container</tt> when we modify a key.<br />
However, the two used keys here (the unit's id and the hex) are never modified in the <tt>action</tt> hierarchy.<br />
<br />
This definition is here to give an idea, in practice other indexes will have to be built (e.g. an index on ''secondary hex'' which could be the source hex in <tt>move</tt>.)<br />
Note that this doesn't necessarily means a new pure virtual function in <tt>action</tt>, a key extractor can be defined to let <tt>action</tt> as it is and use ''RTTI'' instead (this might not be clever though.)<br />
<br />
=====<span id="side_actions.example">Example</span>=====<br />
Here are three functions rewritten with this new design. Note that <tt>side_actions::iterator</tt> is the one defined above.<br />
side_actions::iterator side_actions::end_turn(size_t turn_num){<br />
if(turn_num+1>=turn_beginnings_.size())<br />
return actions_.end();<br />
else<br />
return turn_beginnings_[turn_num+1];<br />
}<br />
<br />
side_actions::iterator side_actions::raw_enqueue(size_t turn_num, action_ptr act){<br />
assert(turn_num <= turn_beginnings_.size());<br />
<br />
iterator new_action = actions_.insert(end_turn(turn_num), act).first;<br />
<br />
if(turn_num >= turn_beginnings_.size())<br />
turn_beginnings_.push_back(new_action);<br />
<br />
return new_action;<br />
}<br />
<br />
side_actions::find_first_action_of(unit const* unit, side_actions::iterator start_position){<br />
// First we get all the action of this unit<br />
typedef action_set::index<by_unit>::type::iterator unit_iterator;<br />
std::pair<unit_iterator, unit_iterator> act = actions_.get<by_unit>().equal_range(unit->underlying_id());<br />
<br />
// Then we find the first of them (chronologically) after start_position<br />
iterator first = actions_.end();<br />
for(unit_iterator it = act.first; it != act.second; ++it){<br />
iterator chrono_it = actions_.project<chronological>(it);<br />
if(chrono_it < first && chrono_it > start_position)<br />
first = chrono_it;<br />
}<br />
return first;<br />
}<br />
<br />
===<span id="visitorhier">Visitor hierarchy refactoring</span>===<br />
====<span id="visitorhier.situation">The current situation</span>====<br />
The important classes and class templates of this hierarchy are:<br />
*'''<tt>visitor</tt>''' is the base class of the visitor hierarchy, it dispatches the calls to the derived classes.<br />
*'''<tt>enable_visit_all</tt>''' is actually an interface to the <tt>action_ptr</tt> objects of every single team.<br />
*'''<tt>action</tt>''' is the root class of the visitable hierarchy.<br />
<br />
Currently, when the visitor hierarchy needs to visit the visitable hierarchy, all the actions of every sides of every turn are visited using the function <tt>enable_visit_all::visit_all_helper</tt> (e.g. this function is called by <tt>highlight_visitor::find_main_highlight</tt> to find the action to highlight.)<br />
<br />
====<span id="visitorhier.idea">The idea</span>====<br />
I'm favorable to the maintain of the Visitor pattern, it segregates the different components nicely.<br />
I think the problem come from <tt>enable_visit_all</tt> and I would like to replace it with a class offering a more fine-grained access to the actions.<br />
For example, a look up by hex could be defined in this new structure and then used by <tt>highlight_visitor</tt>.<br />
Actually, most of the work of this new class will have to do is to redirect the calls to the <tt>side_actions</tt> (to one in particular or to all depending on the function).<br />
<br />
====<span id="visitorhier.implementation">Implementation details</span>====<br />
Let's name this interface <tt>action_inquirer</tt>, I'm not a particularly good English speaker, so if you have a better name in mind, let me know. :)<br />
<br />
The sole problem faced is to place <tt>action_inquirer</tt>, since it is mainly a proxy to a global resource (the <tt>side_actions</tt> of each team), it makes sense to place it directly in the <tt>wb</tt> namespace.<br />
<br />
=====<span id="visitorhier.example">Example</span>=====<br />
Here is an example function that would speed up <tt>highlight_visitor</tt>.<br />
action_ptr action_inquirer::action_at(map_location const &h){<br />
side_actions::iterator r;<br />
foreach(team& t, *resources::teams){<br />
side_actions sa = t.get_side_actions();<br />
if((r=sa.find_action_at(h)) != sa.end())<br />
return *r;<br />
}<br />
return action_ptr();<br />
}<br />
<br />
Note: the implementation of <tt>side_actions::find_action_at</tt> is similar to the one of <tt>side_actions::find_first_action_of</tt>.<br />
<br />
===<span id="mapbuilder">Merging of the validation process into <tt>mapbuilder</tt></span>===<br />
====<span id="mapbuilder.situation">The current situation</span>====<br />
Currently the validation process is separated from the mapbuilding process.<br />
However they are depending on each other.<br />
Indeed, to validate an action the previous actions have to be applied (by the mapbuilder), while in order to build the future state in the mapbuilder, the sequence of action have to be valid.<br />
<br />
====<span id="mapbuilder.idea">The idea</span>====<br />
Inject the validation process into <tt>mapbuilder</tt>. This is not limited to the merging of <tt>validate_visitor</tt> into <tt>mapbuilder</tt>, indeed some validity check are also done in the <tt>action</tt> hierarchy.<br />
<br />
====<span id="mapbuilder.implementation">Implementation details</span>====<br />
I'm still working on this.<br />
<br />
=====<span id="mapbuilder.example">Example</span>=====<br />
Idem.<br />
<br />
===<span id="polishing">Polishing</span>===<br />
Some inconsistencies are present in the code (e.g. the way units are referenced). Some other parts needs clean up or/and optimisation (e.g. usage of <tt>boost::dynamic_pointer_cast</tt>).<br />
<br />
The goal of this task is to find this kind of small problem and fix them.<br />
These two ones have been spotted by gabba, but I'm planning to add other small problems to this list as I found them.<br />
<br />
Also, they can be a good introduction to the code that's why I'm planning to start working on them before the GSoC start date.<br />
<br />
===<span id="designdoc">Design document</span>===<br />
This idea is inspired by the GUI2 design document present in the SVN.<br />
<br />
Doxygen documents the code at a function or class level.<br />
The goal is to write a documentation at the module level. That is a document describing the whiteboard design globally and not function-by-function.<br />
Actually it shouldn't duplicate what is in doxygen but complement it.<br />
This document could also include informations on how to extend the whiteboard to help future contributors.<br />
<br />
Where should this document go?<br />
*In doxygen<br />
:This makes sense since it's where most of the code documentation is.<br />
*In the wiki<br />
:This would make collaborative editing easier.<br />
<br />
If you have an opinion on this, let me know. :)<br />
<br />
===Timeline===<br />
Two of my five tasks are actually best done continuously: the design document and the polishing.<br />
Although I haven't clearly placed a week for them, I set two dates at which they should have been completed.<br />
<br />
Of course, the plan is not to have any delay and to finish each task early, however I have reserved two weeks (actually one week and a half) for unexpected delay.<br />
I named them "movable weeks", because they can move in my timeline if anything goes wrong. :)<br />
<br />
<!-- Wikitext hell 101 --><br />
{| style="border:1px dashed #AAA;border-collapse:collapse;"<br />
|-<br />
!style="border:1px dotted #AAA;padding:5px;"|Date<br />
!style="border:1px dotted #AAA;padding:5px;"|Week<br />
!style="border:1px dotted #AAA;padding:5px;"|Description<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''17/03 - 20/04''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''-11..-5''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Student application evaluation''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|17/03 - 20/04<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|-11..-5<br />
|style="border:1px dotted #AAA;padding:5px;"|Refine the proposal.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''23/04 - 20/05''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''-4..-1''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Community Bonding Period (4 weeks)''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|'''23/04 - 20/05'''<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|'''-4..-1'''<br />
|style="border:1px dotted #AAA;padding:5px;"|'''Phase 0: Approach'''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|23/04 - 20/05<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|-4..-1<br />
|style="border:1px dotted #AAA;padding:5px;"|Familiarise myself with the whiteboard, in the process start a draft of the design document.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|23/04 - 20/05<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|-4..-1<br />
|style="border:1px dotted #AAA;padding:5px;"|Start working on the ''polishing'' and on small parts of the whiteboard in order to gain commit access.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''21/05''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''0''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Start of GSoC''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|21/05 - 12/08<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|0..11<br />
|style="border:1px dotted #AAA;padding:5px;"|Continuously work on the design document and on the code polishing.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''21/05 - 15/07''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''0..7''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''First half term (8 weeks)''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|'''21/05 - 10/06'''<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|'''0..2'''<br />
|style="border:1px dotted #AAA;padding:5px;"|'''Phase 1: <tt>side_actions</tt> refactoring'''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|21/05 - 27/05<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|0<br />
|style="border:1px dotted #AAA;padding:5px;"|Prepare <tt>side_actions</tt> for the change. Add debug informations to the logs. Make the current iterators bidirectional.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|28/05 - 03/06<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|1<br />
|style="border:1px dotted #AAA;padding:5px;"|Change the underlying container and rewrite the associated functions.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|04/06 - 10/06<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|2<br />
|style="border:1px dotted #AAA;padding:5px;"|Debug, write unit test and documentation.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|'''11/06 - 01/07'''<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|'''3..5'''<br />
|style="border:1px dotted #AAA;padding:5px;"|'''Phase 2: Validator hierarchy refactoring'''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|11/06 - 17/06<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|3<br />
|style="border:1px dotted #AAA;padding:5px;"|Write the class <tt>action_inquirer</tt>.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|18/06 - 24/06<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|4<br />
|style="border:1px dotted #AAA;padding:5px;"|Replace the uses of <tt>enable_visit_all</tt> with the new interface. Then delete <tt>enable_visit_all</tt>.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|25/06 - 01/07<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|5<br />
|style="border:1px dotted #AAA;padding:5px;"|Debug, write unit test and documentation.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|'''02/07 - 22/07'''<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|'''6..8'''<br />
|style="border:1px dotted #AAA;padding:5px;"|'''Phase 3: Merging of the validation process into <tt>mapbuilder</tt>'''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|02/07 - 08/07<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|6<br />
|style="border:1px dotted #AAA;padding:5px;"|Merge <tt>validate_visitor</tt> into <tt>mapbuilder</tt>.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|09/07 - 15/07<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|7<br />
|style="border:1px dotted #AAA;padding:5px;"|Hunt down other validity check in the <tt>action</tt> hierarchy and move them to <tt>mapbuilder</tt>.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''13/07''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''7''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Mid-term evaluation''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''16/07 - 26/08''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''8..13''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Second half term (6 weeks)''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|16/07 - 22/07<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|8<br />
|style="border:1px dotted #AAA;padding:5px;"|Debug, write unit test and documentation.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|'''22/07 - 12/08'''<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|'''9..11'''<br />
|style="border:1px dotted #AAA;padding:5px;"|'''Phase 4: Finalisation'''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|22/07 - 29/07<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|9<br />
|style="border:1px dotted #AAA;padding:5px;"|Heavy testing week.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|30/07 - 05/08<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|10<br />
|style="border:1px dotted #AAA;padding:5px;"|Test, debug. Finish the ''polishing''.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|06/08 - 12/08<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|11<br />
|style="border:1px dotted #AAA;padding:5px;"|Test, debug. Finish the design document.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|13/08 - 19/08<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|12<br />
|style="border:1px dotted #AAA;padding:5px;"|Movable week.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|20/08 - 26/08<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|13<br />
|style="border:1px dotted #AAA;padding:5px;"|Movable week.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''24/08''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''13''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Final evaluation''<br />
|}</div>Ejlshttps://wiki.wesnoth.org/index.php?title=User:Ejls/GSoC_2012/Whiteboard_Backend_Refactoring&diff=45946User:Ejls/GSoC 2012/Whiteboard Backend Refactoring2012-03-31T05:44:02Z<p>Ejls: Making it SummerOfCodeIdeas-friendly</p>
<hr />
<div><!--<br />
Excuse the heavy wikitext, I tried to make it as readable as possible and I put a lot of comments.<br />
-->__NOTOC__<!--<br />
-->__NOEDITSECTION__<!--<br />
-->{{SoC2012Student}}<!--<br />
-->[[Category:SoC_Ideas_Whiteboard_Backend_Refactoring_2012]]<!--<br />
-->'''''Note: This proposal is in continuous construction, if you have any remark, please drop me a line on IRC or on the [[{{TALKPAGENAME}}|talk page]].'''''<br /><br /><br />
<br />
<!--***********************************************************************<br />
* * Table of Content * *<br />
* ******************** *<br />
* *<br />
* WARNING: don't forget to add a TOC entry when adding a new section. *<br />
***********************************************************************--><br />
{|style="background:#FAF3E9;margin:none;padding:5px;border:3px double #AAA;-moz-border-radius:20px 5px 20px 5px;-webkit-border-radius:20px 5px 20px 5px;border-radius:20px 5px 20px 5px;"<br />
|-<br />
| style="text-align: center; padding: 0px 10px 5px 10px;"|'''Content'''<hr /><br />
|-<br />
| style="text-align: left; padding:0px 10px 10px 10px;"|<br />
[[#Description|Description]]<br /><br />
[[#Contact|Contact]]<br /><br />
[[#SoC Application|SoC Application]]<br /><br />
[[#Questionnaire|Questionnaire]]<br /><br />
:[[#1) Basics|1 - Basics]]<br /><br />
:[[#2) Experience|2 - Experience]]<br /><br />
:[[#3) Communication skills|3 - Communication skills]]<br /><br />
:[[#4) Project|4 - Project]]<br /><br />
:[[#5) Practical considerations|5 - Practical considerations]]<br /><br />
[[#Proposal|Proposal]]<br /><br />
:[[#The problems|The problems]]<br /><br />
:[[#side_actions|<tt>side_actions</tt> refactoring]]<br /><br />
::[[#side_actions.situation|The current situation]]<br /><br />
::[[#side_actions.idea|The idea]]<br /><br />
::[[#side_actions.implementation|Implementation details]]<br /><br />
:::[[#side_actions.containers|Choice of the containers]]<br /><br />
:::[[#side_actions.example|Example]]<br /><br />
:[[#visitorhier|Visitor hierarchy refactoring]]<br /><br />
::[[#visitorhier.situation|The current situation]]<br /><br />
::[[#visitorhier.idea|The idea]]<br /><br />
::[[#visitorhier.implementation|Implementation details]]<br /><br />
:::[[#visitorhier.example|Example]]<br /><br />
:[[#mapbuilder|Merging of the validation process into <tt>mapbuilder</tt>]]<br /><br />
::[[#mapbuilder.situation|The current situation]]<br /><br />
::[[#mapbuilder.idea|The idea]]<br /><br />
::[[#mapbuilder.implementation|Implementation details]]<br /><br />
:::[[#mapbuilder.example|Example]]<br /><br />
:[[#polishing|Polishing]]<br /><br />
:[[#designdoc|Design document]]<br /><br />
:[[#Timeline|Timeline]]<br /><br />
|}<br />
<br />
<!--***********************************************************************<br />
* * Description * *<br />
* *************** *<br />
* *<br />
* This section is inserted in the SummerOfCodeIdeas page. It contains *<br />
* only a header of level 4 and a small paragraph summing up the *<br />
* proposal. *<br />
***********************************************************************--><br />
==Description==<br />
=====Étienne Simon - Whiteboard backend polishing=====<br />
My project is to make the whiteboard code cleaner and to redesign small parts of it to speed it up. Apart from the visitor hierarchy refactoring, the global design of the whiteboard won't be changed, each part will be reviewed individually. I'm not only planning to improve the whiteboard backend, but also to document the overall design and each part of it as well as to write a wide variety of test to improve its stability.<br />
<br />
<!--***********************************************************************<br />
* * SoC Application * *<br />
* ******************* *<br />
* *<br />
* This section affect the SummerOfCodeIdeas page, if it contains the *<br />
* text "Submitted to google", the application will appear in the *<br />
* "Student proposals submitted both to wiki and google" section, *<br />
* otherwise it'll appear in the "Student proposals not submitted to *<br />
* google" section. *<br />
***********************************************************************--><br />
==SoC Application==<br />
Not yet submitted.<br />
<br />
<!--***********************************************************************<br />
* * Contact * *<br />
* *********** *<br />
* *<br />
* The IRC subsection is inserted in the SummerOfCodeIdeas page. It *<br />
* must only contain the IRC nick identifying the author. *<br />
***********************************************************************--><br />
==Contact==<br />
{|<br />
|-<br />
|<br />
=====IRC=====<br />
<span style="color:#3F475E;">ejls</span><br />
=====Email=====<br />
Address at gmail dot com: etienne.jl.simon<br />
| style="width:10em;" |<br />
|<br />
=====Forum=====<br />
ejls<br />
=====Gna=====<br />
ejls<br />
|}<br />
<br />
<!--***********************************************************************<br />
* * Questionnaire * *<br />
* ***************** *<br />
* *<br />
* Although I'm submitting only one application (and so only one *<br />
* questionnaire), I thought it was more elegant to make the *<br />
* questionnaire page reusable. Which explain why it's a template. *<br />
* Like I wrote in the Questionnaire subpage, the argument to this *<br />
* template are the answer to the proposal-specific questions. I order *<br />
* to make the sources more comprehensible, I wrote the corresponding *<br />
* question in comments at the beginning of each parameter. *<br />
***********************************************************************--><br />
{{User:Ejls/GSoC 2012/Questionnaire<br />
|<!-- 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? --><br />
''This is a summary, more details can be found [http://wiki.wesnoth.org/User:Ejls/GSoC%202012/Whiteboard%20Backend%20Refactoring#Proposal here].''<br />
<br />
I have chosen [[SoC Ideas Whiteboard Backend Refactoring 2012]]. This project is the only one not adding any feature for the user, the main goal is to refactor code, write test and documentation. It follows [http://wiki.wesnoth.org/GSoC-WesnothWhiteboard_Gabba gabba's project] and [http://wiki.wesnoth.org/User:Tschmitz tschmitz's project] on the whiteboard. Although it doesn't add any feature for the user in itself, I hope it'll help future development of the whiteboard.<!--<br />
-->|<!-- 4.2) If you have invented your own project, please describe the project and the scope. --><br />
I chose a project from the list, namely [[SoC Ideas Whiteboard Backend Refactoring 2012]]. C.f. above answer.<!--<br />
-->|<!-- 4.3) Why did you choose this project? --><br />
I liked the idea behind the whiteboard, I think it might be a big plus to Wesnoth. Furthermore, I liked how C++ is used in its code (especially the heavy use of SBRM). However it looks like the whiteboard is not widely used, and I would like to help changing that! :)<!--<br />
-->|<!-- 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". --><br />
''This is a summary, more details can be found [http://wiki.wesnoth.org/User:Ejls/GSoC%202012/Whiteboard%20Backend%20Refactoring#Timeline here].''<br />
<br />
I separated my summer in five phases:<br />
*Phase 0: Approach (4 weeks)<br />
::→ Start working on the design document. Start the ''polishing''.<br />
*Phase 1: <tt>side_actions</tt> refactoring (3 weeks)<br />
*Phase 2: Validator hierarchy refactoring (3 weeks)<br />
*Phase 3: Merging of the validation process into <tt>mapbuilder</tt> (3 weeks)<br />
*Phase 4: Finalisation (3 weeks)<br />
::→ Finish the design document. Finish the ''polishing''. Test. Test. Test.<!--<br />
-->|<!-- 4.5) Include as much technical detail about your implementation as you can --><br />
''This is a summary, more details can be found [http://wiki.wesnoth.org/User:Ejls/GSoC%202012/Whiteboard%20Backend%20Refactoring#Proposal here].''<br />
<br />
I separated my project in five tasks:<br />
;<tt>side_actions</tt> refactoring<br />
:Change of the underlying container, creation of new look up functions.<br />
;Visitor hierarchy refactoring<br />
:Replacement of the <tt>enable_visit_all</tt> by a new interface over all of the <tt>side_actions</tt> objects.<br />
;Merging of the validation process into <tt>mapbuilder</tt><br />
:Deletion of the <tt>validate_visitor</tt> class, injection of its code and other validation code from the <tt>action</tt> hierarchy into <tt>mapbuilder</tt>.<br />
;Polishing<br />
:Code uniformisation, small improvements.<br />
;Design document<br />
:Documentation of the global whiteboard design.<!--<br />
-->|<!-- 4.6) What do you expect to gain from this project? --><br />
I hope it'll help me to join the open source developer community. Actually, the preparation of this proposal already helped me a lot, for example my first patch got committed, it wasn't a big patch, but it was my first step of a (I hope) long path. :) So, I hope to continue learning to walk with the wesnoth community (sorry for the silly metaphor.)<!--<br />
-->|<!-- 4.7) What would make you stay in the Wesnoth community after the conclusion of SOC? --><br />
If my work is appreciated, I would rather ask: what would make me leave the Wesnoth community?.<!--<br />
-->}}<br />
<br />
<!--***********************************************************************<br />
* * Proposal * *<br />
* ************ *<br />
* *<br />
* Finally, my proposal. ;) *<br />
***********************************************************************--><br />
==Proposal==<br />
===The problems===<br />
In the [[SoC_Ideas_Whiteboard_Backend_Refactoring_2012|Whiteboard Backend Refactoring idea page]], several problems are listed, here is how I'm planning to fix them:<br />
{| style="border:1px dashed #AAA;border-collapse:collapse;"<br />
|-<br />
!style="border:1px dotted #AAA;padding:5px;"|Problem<br />
!style="border:1px dotted #AAA;padding:5px;"|Solution<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|<tt>side_actions</tt> complexity<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#side_actions|<tt>side_actions</tt> refactoring]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|Redundancy between <tt>mapbuilder</tt> and <tt>validate_visitor</tt><br />
|style="border:1px dotted #AAA;padding:5px;"|[[#mapbuilder|Merging of the validation process into <tt>mapbuilder</tt>]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|Highlighter slowness<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#side_actions|<tt>side_actions</tt> refactoring]] and [[#visitorhier|Visitor hierarchy refactoring]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|Friend classes vs everything in the action classes<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#visitorhier|Visitor hierarchy refactoring]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|Unit pointer recovery uniformisation<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#polishing|Polishing]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|<tt>boost::dynamic_pointer_cast</tt> vs simple numeric id<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#polishing|Polishing]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|Documentation<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#designdoc|Design document]]<br />
|}<br />
<br />
===<span id="side_actions"><tt>side_actions</tt> refactoring</span>===<br />
====<span id="side_actions.situation">The current situation</span>====<br />
The current implementation of <tt>side_actions</tt> use a <tt>std::deque&lt;std::deque&lt;action_ptr&gt;&gt;</tt>.<br />
In order to use it, iterators have been defined over it (<tt>side_actions::iterator</tt> and the three const and revert variants).<br />
These “flattening” iterators let users of <tt>side_actions</tt> iterate over all the planned actions, they are performing the ''zip'' operation on the fly.<br />
<br />
Furthermore, some queries like <tt>side_actions::find_first_action_of</tt> are linear in the number of action.<br />
<br />
====<span id="side_actions.idea">The idea</span>====<br />
To simplify the code, I propose to keep the action set zipped. The container's iterators will then be usable directly. In order to delimit turns, a second container will have to keep a sequence of iterators pointing to the first action of each turn.<br />
<br />
For example, let's say eight actions are planned: five for this turn, two for the next turn and one for the turn after. Three iterators will be kept to delimit turns. Here is a proof that I can't use gimp which also show the idea:<br />
http://epsilon012.free.fr/GSoC%202012/side_actions%20idea.png<br />
<br />
Of course another problem emerge: the sequence of iterator has to be kept in sync with the sequence of action.<br />
<br />
Finally, the current implementation gives access to the <tt>action_ptr</tt> only in sequence, in order to speed up different way of querying action (e.g. by hex, by unit's id), I propose to build several indexes on the action set.<br />
<br />
====<span id="side_actions.implementation">Implementation details</span>====<br />
Let's name these containers <tt>actions_</tt> and <tt>turn_beginnings_</tt>.<br />
<br />
The whiteboard have the following invariant: an empty turn (a turn without planned action) can't be followed by a non-empty turn (with at least one planned action). It means that <code>distance(turn_beginnings_[i], turn_beginnings_[i+1])&gt;0</code>, and so we can unambiguously determine the turn number of each action.<br />
<br />
Also, note that except when <tt>actions_.empty()</tt> : <tt>turn_beginnings_.front()==actions_.begin()</tt>.<br />
<br />
=====<span id="side_actions.containers">Choice of the containers</span>=====<br />
<tt>std::deque</tt> seems to be the perfect container for <tt>turn_beginnings_</tt>. It'll allow random access and we need to add/remove new turns only at the extremities.<br />
<br />
On the other hand, <tt>actions_</tt> need two proprieties:<br />
*Allow fast chronological iteration<br />
*Stable iterators<br />
*Allow fast lookup on different indexes<br />
I propose to use a <tt>boost::multi_index_container</tt>, this container is part of the library [http://www.boost.org/doc/libs/1_49_0/libs/multi_index Boost.MultiIndex] which is in Boost since version 1.32. It allows the construction of several indexes on the same set of object.<br />
<br />
There is however one problem linked to the use of the <tt>boost::multi_index::random_access</tt> index: insertion and deletion are in linear time when their are not done at the extremities.<br />
<br />
So, the new members should be:<br />
namespace bmi = boost::multi_index;<br />
typedef bmi::multi_index_container<<br />
action_ptr,<br />
bmi::indexed_by<<br />
bmi::random_access<bmi::tag<chronological> >,<br />
bmi::hashed_non_unique<bmi::tag<by_unit>, bmi::const_mem_fun<action,size_t,&action::get_unit_id> >,<br />
bmi::hashed_non_unique<bmi::tag<by_hex>, bmi::const_mem_fun<action,size_t,&action::get_hex>><br />
><br />
> action_set;<br />
typedef action_set::iterator iterator;<br />
<br />
action_set actions_;<br />
std::deque<iterator> turn_beginnings_;<br />
<br />
This suppose two new pure virtual function in <tt>action</tt>: <tt>get_unit_id</tt> and <tt>get_hex</tt>.<br />
<br />
Using action's attribute as key brings another drawback: we must notify the <tt>multi_index_container</tt> when we modify a key.<br />
However, the two used keys here (the unit's id and the hex) are never modified in the <tt>action</tt> hierarchy.<br />
<br />
This definition is here to give an idea, in practice other indexes will have to be built (e.g. an index on ''secondary hex'' which could be the source hex in <tt>move</tt>.)<br />
Note that this doesn't necessarily means a new pure virtual function in <tt>action</tt>, a key extractor can be defined to let <tt>action</tt> as it is and use ''RTTI'' instead (this might not be clever though.)<br />
<br />
=====<span id="side_actions.example">Example</span>=====<br />
Here are three functions rewritten with this new design. Note that <tt>side_actions::iterator</tt> is the one defined above.<br />
side_actions::iterator side_actions::end_turn(size_t turn_num){<br />
if(turn_num+1>=turn_beginnings_.size())<br />
return actions_.end();<br />
else<br />
return turn_beginnings_[turn_num+1];<br />
}<br />
<br />
side_actions::iterator side_actions::raw_enqueue(size_t turn_num, action_ptr act){<br />
assert(turn_num <= turn_beginnings_.size());<br />
<br />
iterator new_action = actions_.insert(end_turn(turn_num), act).first;<br />
<br />
if(turn_num >= turn_beginnings_.size())<br />
turn_beginnings_.push_back(new_action);<br />
<br />
return new_action;<br />
}<br />
<br />
side_actions::find_first_action_of(unit const* unit, side_actions::iterator start_position){<br />
// First we get all the action of this unit<br />
typedef action_set::index<by_unit>::type::iterator unit_iterator;<br />
std::pair<unit_iterator, unit_iterator> act = actions_.get<by_unit>().equal_range(unit->underlying_id());<br />
<br />
// Then we find the first of them (chronologically) after start_position<br />
iterator first = actions_.end();<br />
for(unit_iterator it = act.first; it != act.second; ++it){<br />
iterator chrono_it = actions_.project<chronological>(it);<br />
if(chrono_it < first && chrono_it > start_position)<br />
first = chrono_it;<br />
}<br />
return first;<br />
}<br />
<br />
===<span id="visitorhier">Visitor hierarchy refactoring</span>===<br />
====<span id="visitorhier.situation">The current situation</span>====<br />
The important classes and class templates of this hierarchy are:<br />
*'''<tt>visitor</tt>''' is the base class of the visitor hierarchy, it dispatches the calls to the derived classes.<br />
*'''<tt>enable_visit_all</tt>''' is actually an interface to the <tt>action_ptr</tt> objects of every single team.<br />
*'''<tt>action</tt>''' is the root class of the visitable hierarchy.<br />
<br />
Currently, when the visitor hierarchy needs to visit the visitable hierarchy, all the actions of every sides of every turn are visited using the function <tt>enable_visit_all::visit_all_helper</tt> (e.g. this function is called by <tt>highlight_visitor::find_main_highlight</tt> to find the action to highlight.)<br />
<br />
====<span id="visitorhier.idea">The idea</span>====<br />
I'm favorable to the maintain of the Visitor pattern, it segregates the different components nicely.<br />
I think the problem come from <tt>enable_visit_all</tt> and I would like to replace it with a class offering a more fine-grained access to the actions.<br />
For example, a look up by hex could be defined in this new structure and then used by <tt>highlight_visitor</tt>.<br />
Actually, most of the work of this new class will have to do is to redirect the calls to the <tt>side_actions</tt> (to one in particular or to all depending on the function).<br />
<br />
====<span id="visitorhier.implementation">Implementation details</span>====<br />
Let's name this interface <tt>action_inquirer</tt>, I'm not a particularly good English speaker, so if you have a better name in mind, let me know. :)<br />
<br />
The sole problem faced is to place <tt>action_inquirer</tt>, since it is mainly a proxy to a global resource (the <tt>side_actions</tt> of each team), it makes sense to place it directly in the <tt>wb</tt> namespace.<br />
<br />
=====<span id="visitorhier.example">Example</span>=====<br />
Here is an example function that would speed up <tt>highlight_visitor</tt>.<br />
action_ptr action_inquirer::action_at(map_location const &h){<br />
side_actions::iterator r;<br />
foreach(team& t, *resources::teams){<br />
side_actions sa = t.get_side_actions();<br />
if((r=sa.find_action_at(h)) != sa.end())<br />
return *r;<br />
}<br />
return action_ptr();<br />
}<br />
<br />
Note: the implementation of <tt>side_actions::find_action_at</tt> is similar to the one of <tt>side_actions::find_first_action_of</tt>.<br />
<br />
===<span id="mapbuilder">Merging of the validation process into <tt>mapbuilder</tt></span>===<br />
====<span id="mapbuilder.situation">The current situation</span>====<br />
Currently the validation process is separated from the mapbuilding process.<br />
However they are depending on each other.<br />
Indeed, to validate an action the previous actions have to be applied (by the mapbuilder), while in order to build the future state in the mapbuilder, the sequence of action have to be valid.<br />
<br />
====<span id="mapbuilder.idea">The idea</span>====<br />
Inject the validation process into <tt>mapbuilder</tt>. This is not limited to the merging of <tt>validate_visitor</tt> into <tt>mapbuilder</tt>, indeed some validity check are also done in the <tt>action</tt> hierarchy.<br />
<br />
====<span id="mapbuilder.implementation">Implementation details</span>====<br />
I'm still working on this.<br />
<br />
=====<span id="mapbuilder.example">Example</span>=====<br />
Idem.<br />
<br />
===<span id="polishing">Polishing</span>===<br />
Some inconsistencies are present in the code (e.g. the way units are referenced). Some other parts needs clean up or/and optimisation (e.g. usage of <tt>boost::dynamic_pointer_cast</tt>).<br />
<br />
The goal of this task is to find this kind of small problem and fix them.<br />
These two ones have been spotted by gabba, but I'm planning to add other small problems to this list as I found them.<br />
<br />
Also, they can be a good introduction to the code that's why I'm planning to start working on them before the GSoC start date.<br />
<br />
===<span id="designdoc">Design document</span>===<br />
This idea is inspired by the GUI2 design document present in the SVN.<br />
<br />
Doxygen documents the code at a function or class level.<br />
The goal is to write a documentation at the module level. That is a document describing the whiteboard design globally and not function-by-function.<br />
Actually it shouldn't duplicate what is in doxygen but complement it.<br />
This document could also include informations on how to extend the whiteboard to help future contributors.<br />
<br />
Where should this document go?<br />
*In doxygen<br />
:This makes sense since it's where most of the code documentation is.<br />
*In the wiki<br />
:This would make collaborative editing easier.<br />
<br />
If you have an opinion on this, let me know. :)<br />
<br />
===Timeline===<br />
Two of my five tasks are actually best done continuously: the design document and the polishing.<br />
Although I haven't clearly placed a week for them, I set two dates at which they should have been completed.<br />
<br />
Of course, the plan is not to have any delay and to finish each task early, however I have reserved two weeks (actually one week and a half) for unexpected delay.<br />
I named them "movable weeks", because they can move in my timeline if anything goes wrong. :)<br />
<br />
<!-- Wikitext hell 101 --><br />
{| style="border:1px dashed #AAA;border-collapse:collapse;"<br />
|-<br />
!style="border:1px dotted #AAA;padding:5px;"|Date<br />
!style="border:1px dotted #AAA;padding:5px;"|Week<br />
!style="border:1px dotted #AAA;padding:5px;"|Description<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''17/03 - 20/04''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''-11..-5''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Student application evaluation''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|17/03 - 20/04<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|-11..-5<br />
|style="border:1px dotted #AAA;padding:5px;"|Refine the proposal.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''23/04 - 20/05''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''-4..-1''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Community Bonding Period (4 weeks)''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|'''23/04 - 20/05'''<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|'''-4..-1'''<br />
|style="border:1px dotted #AAA;padding:5px;"|'''Phase 0: Approach'''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|23/04 - 20/05<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|-4..-1<br />
|style="border:1px dotted #AAA;padding:5px;"|Familiarise myself with the whiteboard, in the process start a draft of the design document.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|23/04 - 20/05<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|-4..-1<br />
|style="border:1px dotted #AAA;padding:5px;"|Start working on the ''polishing'' and on small parts of the whiteboard in order to gain commit access.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''21/05''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''0''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Start of GSoC''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|21/05 - 12/08<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|0..11<br />
|style="border:1px dotted #AAA;padding:5px;"|Continuously work on the design document and on the code polishing.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''21/05 - 15/07''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''0..7''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''First half term (8 weeks)''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|'''21/05 - 10/06'''<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|'''0..2'''<br />
|style="border:1px dotted #AAA;padding:5px;"|'''Phase 1: <tt>side_actions</tt> refactoring'''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|21/05 - 27/05<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|0<br />
|style="border:1px dotted #AAA;padding:5px;"|Prepare <tt>side_actions</tt> for the change. Add debug informations to the logs. Make the current iterators bidirectional.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|28/05 - 03/06<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|1<br />
|style="border:1px dotted #AAA;padding:5px;"|Change the underlying container and rewrite the associated functions.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|04/06 - 10/06<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|2<br />
|style="border:1px dotted #AAA;padding:5px;"|Debug, write unit test and documentation.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|'''11/06 - 01/07'''<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|'''3..5'''<br />
|style="border:1px dotted #AAA;padding:5px;"|'''Phase 2: Validator hierarchy refactoring'''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|11/06 - 17/06<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|3<br />
|style="border:1px dotted #AAA;padding:5px;"|Write the class <tt>action_inquirer</tt>.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|18/06 - 24/06<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|4<br />
|style="border:1px dotted #AAA;padding:5px;"|Replace the uses of <tt>enable_visit_all</tt> with the new interface. Then delete <tt>enable_visit_all</tt>.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|25/06 - 01/07<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|5<br />
|style="border:1px dotted #AAA;padding:5px;"|Debug, write unit test and documentation.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|'''02/07 - 22/07'''<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|'''6..8'''<br />
|style="border:1px dotted #AAA;padding:5px;"|'''Phase 3: Merging of the validation process into <tt>mapbuilder</tt>'''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|02/07 - 08/07<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|6<br />
|style="border:1px dotted #AAA;padding:5px;"|Merge <tt>validate_visitor</tt> into <tt>mapbuilder</tt>.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|09/07 - 15/07<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|7<br />
|style="border:1px dotted #AAA;padding:5px;"|Hunt down other validity check in the <tt>action</tt> hierarchy and move them to <tt>mapbuilder</tt>.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''13/07''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''7''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Mid-term evaluation''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''16/07 - 26/08''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''8..13''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Second half term (6 weeks)''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|16/07 - 22/07<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|8<br />
|style="border:1px dotted #AAA;padding:5px;"|Debug, write unit test and documentation.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|'''22/07 - 12/08'''<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|'''9..11'''<br />
|style="border:1px dotted #AAA;padding:5px;"|'''Phase 4: Finalisation'''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|22/07 - 29/07<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|9<br />
|style="border:1px dotted #AAA;padding:5px;"|Heavy testing week.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|30/07 - 05/08<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|10<br />
|style="border:1px dotted #AAA;padding:5px;"|Test, debug. Finish the ''polishing''.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|06/08 - 12/08<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|11<br />
|style="border:1px dotted #AAA;padding:5px;"|Test, debug. Finish the design document.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|13/08 - 19/08<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|12<br />
|style="border:1px dotted #AAA;padding:5px;"|Movable week.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|20/08 - 26/08<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|13<br />
|style="border:1px dotted #AAA;padding:5px;"|Movable week.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''24/08''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''13''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Final evaluation''<br />
|}</div>Ejlshttps://wiki.wesnoth.org/index.php?title=User:Ejls&diff=45945User:Ejls2012-03-31T05:21:33Z<p>Ejls: </p>
<hr />
<div>__NOTOC__<br />
==Contact==<br />
{| style="border:3px double #AAA;border-collapse:collapse;"<br />
|- style="border:1px dashed #AAA;"<br />
! style="text-align:left;"|Email<br />
| Address at gmail dot com: etienne.jl.simon<br />
|- style="border:1px dashed #AAA;"<br />
! style="text-align:left;"|Forum, Gna, IRC (@freenode)<br />
| ejls<br />
|- style="border:1px dashed #AAA;"<br />
! style="text-align:left;"|Wiki<br />
| [[{{TALKPAGENAME}}]]<br />
|}<br />
<br />
==GSoC 2012 proposal==<br />
<center><span style="font-size:1.4em;">'''&gt; [[User:Ejls/GSoC 2012/Whiteboard Backend Refactoring|Proposal page]] &lt;'''</span></center><br />
<br />
==Work==<br />
*[[User:Ejls/Vim|WML syntax support for Vim]]<br />
*[https://gna.org/patch/?3185 Patch #3185] <tt>power_projection</tt> improvement<br />
*[https://gna.org/patch/?3201 Patch #3201] Make leader unable to move when invalidating a planned recall<br />
<br />
==Subpages==<br />
*[[User:Ejls]] <sup>[[User_talk:Ejls|talk]]</sup><br />
*[[User:Ejls/Vim]] <sup>[[User_talk:Ejls/Vim|talk]]</sup><br />
*[[User:Ejls/GSoC 2012/Questionnaire]] <sup>[[User_talk:Ejls/GSoC 2012/Questionnaire|talk]]</sup><br />
*[[User:Ejls/GSoC 2012/Whiteboard Backend Refactoring]] <sup>[[User_talk:Ejls/GSoC 2012/Whiteboard Backend Refactoring|talk]]</sup></div>Ejlshttps://wiki.wesnoth.org/index.php?title=User:Ejls/GSoC_2012/Whiteboard_Backend_Refactoring&diff=45944User:Ejls/GSoC 2012/Whiteboard Backend Refactoring2012-03-31T05:15:02Z<p>Ejls: First version (not finished yet)</p>
<hr />
<div><!--<br />
Excuse the heavy wikitext, I tried to make it as readable as possible and I put a lot of comments.<br />
-->__NOTOC__<!--<br />
-->__NOEDITSECTION__<!--<br />
-->{{SoC2012Student}}<!--<br />
-->[[Category:SoC_Ideas_Whiteboard_Backend_Refactoring_2012]]<!--<br />
-->'''''Note: This proposal is in continuous construction, if you have any remark, please drop me a line on IRC or on the [[{{TALKPAGENAME}}|talk page]].'''''<br /><br /><br />
<br />
<!--***********************************************************************<br />
* * Table of Content * *<br />
* ******************** *<br />
* *<br />
* WARNING: don't forget to add a TOC entry when adding a new section. *<br />
***********************************************************************--><br />
{|style="background:#FAF3E9;margin:none;padding:5px;border:3px double #AAA;-moz-border-radius:20px 5px 20px 5px;-webkit-border-radius:20px 5px 20px 5px;border-radius:20px 5px 20px 5px;"<br />
|-<br />
| style="text-align: center; padding: 0px 10px 5px 10px;"|'''Content'''<hr /><br />
|-<br />
| style="text-align: left; padding:0px 10px 10px 10px;"|<br />
[[#Description|Description]]<br /><br />
[[#Contact|Contact]]<br /><br />
[[#SoC Application|SoC Application]]<br /><br />
[[#Questionnaire|Questionnaire]]<br /><br />
:[[#1) Basics|1 - Basics]]<br /><br />
:[[#2) Experience|2 - Experience]]<br /><br />
:[[#3) Communication skills|3 - Communication skills]]<br /><br />
:[[#4) Project|4 - Project]]<br /><br />
:[[#5) Practical considerations|5 - Practical considerations]]<br /><br />
[[#Proposal|Proposal]]<br /><br />
:[[#The problems|The problems]]<br /><br />
:[[#side_actions|<tt>side_actions</tt> refactoring]]<br /><br />
::[[#side_actions.situation|The current situation]]<br /><br />
::[[#side_actions.idea|The idea]]<br /><br />
::[[#side_actions.implementation|Implementation details]]<br /><br />
:::[[#side_actions.containers|Choice of the containers]]<br /><br />
:::[[#side_actions.example|Example]]<br /><br />
:[[#visitorhier|Visitor hierarchy refactoring]]<br /><br />
::[[#visitorhier.situation|The current situation]]<br /><br />
::[[#visitorhier.idea|The idea]]<br /><br />
::[[#visitorhier.implementation|Implementation details]]<br /><br />
:::[[#visitorhier.example|Example]]<br /><br />
:[[#mapbuilder|Merging of the validation process into <tt>mapbuilder</tt>]]<br /><br />
::[[#mapbuilder.situation|The current situation]]<br /><br />
::[[#mapbuilder.idea|The idea]]<br /><br />
::[[#mapbuilder.implementation|Implementation details]]<br /><br />
:::[[#mapbuilder.example|Example]]<br /><br />
:[[#polishing|Polishing]]<br /><br />
:[[#designdoc|Design document]]<br /><br />
:[[#Timeline|Timeline]]<br /><br />
|}<br />
<br />
<!--***********************************************************************<br />
* * Description * *<br />
* *************** *<br />
* *<br />
* This section is inserted in the SummerOfCodeIdeas page. It contains *<br />
* only a header of level 4 and a small paragraph summing up the *<br />
* proposal. *<br />
***********************************************************************--><br />
==Description==<br />
=====Étienne Simon - Whiteboard backend polishing=====<br />
My project is to make the whiteboard code cleaner and to redesign small parts of it to speed it up. Apart from the visitor hierarchy refactoring, the global design of the whiteboard won't be changed, each part will be reviewed individually. I'm not only planning to improve the whiteboard backend, but also to document the overall design and each part of it as well as to write a wide variety of test to improve its stability.<br />
<br />
<!--***********************************************************************<br />
* * Contact * *<br />
* *********** *<br />
* *<br />
* The IRC subsection is inserted in the SummerOfCodeIdeas page. It *<br />
* must only contain the IRC nick identifying the author. *<br />
***********************************************************************--><br />
==Contact==<br />
{|<br />
|-<br />
|<br />
=====IRC=====<br />
<span style="color:#3F475E;">ejls</span><br />
=====Email=====<br />
Address at gmail dot com: etienne.jl.simon<br />
| style="width:10em;" |<br />
|<br />
=====Forum=====<br />
ejls<br />
=====Gna=====<br />
ejls<br />
|}<br />
<br />
<!--***********************************************************************<br />
* * SoC Application * *<br />
* ******************* *<br />
* *<br />
* This section affect the SummerOfCodeIdeas page, if it contains the *<br />
* text "Submitted to google", the application will appear in the *<br />
* "Student proposals submitted both to wiki and google" section, *<br />
* otherwise it'll appear in the "Student proposals not submitted to *<br />
* google" section. *<br />
***********************************************************************--><br />
==SoC Application==<br />
Not yet submitted.<br />
<br />
<!--***********************************************************************<br />
* * Questionnaire * *<br />
* ***************** *<br />
* *<br />
* Although I'm submitting only one application (and so only one *<br />
* questionnaire), I thought it was more elegant to make the *<br />
* questionnaire page reusable. Which explain why it's a template. *<br />
* Like I wrote in the Questionnaire subpage, the argument to this *<br />
* template are the answer to the proposal-specific questions. I order *<br />
* to make the sources more comprehensible, I wrote the corresponding *<br />
* question in comments at the beginning of each parameter. *<br />
***********************************************************************--><br />
{{User:Ejls/GSoC 2012/Questionnaire<br />
|<!-- 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? --><br />
''This is a summary, more details can be found [http://wiki.wesnoth.org/User:Ejls/GSoC%202012/Whiteboard%20Backend%20Refactoring#Proposal here].''<br />
<br />
I have chosen [[SoC Ideas Whiteboard Backend Refactoring 2012]]. This project is the only one not adding any feature for the user, the main goal is to refactor code, write test and documentation. It follows [http://wiki.wesnoth.org/GSoC-WesnothWhiteboard_Gabba gabba's project] and [http://wiki.wesnoth.org/User:Tschmitz tschmitz's project] on the whiteboard. Although it doesn't add any feature for the user in itself, I hope it'll help future development of the whiteboard.<!--<br />
-->|<!-- 4.2) If you have invented your own project, please describe the project and the scope. --><br />
I chose a project from the list, namely [[SoC Ideas Whiteboard Backend Refactoring 2012]]. C.f. above answer.<!--<br />
-->|<!-- 4.3) Why did you choose this project? --><br />
I liked the idea behind the whiteboard, I think it might be a big plus to Wesnoth. Furthermore, I liked how C++ is used in its code (especially the heavy use of SBRM). However it looks like the whiteboard is not widely used, and I would like to help changing that! :)<!--<br />
-->|<!-- 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". --><br />
''This is a summary, more details can be found [http://wiki.wesnoth.org/User:Ejls/GSoC%202012/Whiteboard%20Backend%20Refactoring#Timeline here].''<br />
<br />
I separated my summer in five phases:<br />
*Phase 0: Approach (4 weeks)<br />
::→ Start working on the design document. Start the ''polishing''.<br />
*Phase 1: <tt>side_actions</tt> refactoring (3 weeks)<br />
*Phase 2: Validator hierarchy refactoring (3 weeks)<br />
*Phase 3: Merging of the validation process into <tt>mapbuilder</tt> (3 weeks)<br />
*Phase 4: Finalisation (3 weeks)<br />
::→ Finish the design document. Finish the ''polishing''. Test. Test. Test.<!--<br />
-->|<!-- 4.5) Include as much technical detail about your implementation as you can --><br />
''This is a summary, more details can be found [http://wiki.wesnoth.org/User:Ejls/GSoC%202012/Whiteboard%20Backend%20Refactoring#Proposal here].''<br />
<br />
I separated my project in five tasks:<br />
;<tt>side_actions</tt> refactoring<br />
:Change of the underlying container, creation of new look up functions.<br />
;Visitor hierarchy refactoring<br />
:Replacement of the <tt>enable_visit_all</tt> by a new interface over all of the <tt>side_actions</tt> objects.<br />
;Merging of the validation process into <tt>mapbuilder</tt><br />
:Deletion of the <tt>validate_visitor</tt> class, injection of its code and other validation code from the <tt>action</tt> hierarchy into <tt>mapbuilder</tt>.<br />
;Polishing<br />
:Code uniformisation, small improvements.<br />
;Design document<br />
:Documentation of the global whiteboard design.<!--<br />
-->|<!-- 4.6) What do you expect to gain from this project? --><br />
I hope it'll help me to join the open source developer community. Actually, the preparation of this proposal already helped me a lot, for example my first patch got committed, it wasn't a big patch, but it was my first step of a (I hope) long path. :) So, I hope to continue learning to walk with the wesnoth community (sorry for the silly metaphor.)<!--<br />
-->|<!-- 4.7) What would make you stay in the Wesnoth community after the conclusion of SOC? --><br />
If my work is appreciated, I would rather ask: what would make me leave the Wesnoth community?.<!--<br />
-->}}<br />
<br />
<!--***********************************************************************<br />
* * Proposal * *<br />
* ************ *<br />
* *<br />
* Finally, my proposal. ;) *<br />
***********************************************************************--><br />
==Proposal==<br />
===The problems===<br />
In the [[SoC_Ideas_Whiteboard_Backend_Refactoring_2012|Whiteboard Backend Refactoring idea page]], several problems are listed, here is how I'm planning to fix them:<br />
{| style="border:1px dashed #AAA;border-collapse:collapse;"<br />
|-<br />
!style="border:1px dotted #AAA;padding:5px;"|Problem<br />
!style="border:1px dotted #AAA;padding:5px;"|Solution<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|<tt>side_actions</tt> complexity<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#side_actions|<tt>side_actions</tt> refactoring]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|Redundancy between <tt>mapbuilder</tt> and <tt>validate_visitor</tt><br />
|style="border:1px dotted #AAA;padding:5px;"|[[#mapbuilder|Merging of the validation process into <tt>mapbuilder</tt>]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|Highlighter slowness<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#side_actions|<tt>side_actions</tt> refactoring]] and [[#visitorhier|Visitor hierarchy refactoring]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|Friend classes vs everything in the action classes<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#visitorhier|Visitor hierarchy refactoring]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|Unit pointer recovery uniformisation<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#polishing|Polishing]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|<tt>boost::dynamic_pointer_cast</tt> vs simple numeric id<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#polishing|Polishing]]<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|Documentation<br />
|style="border:1px dotted #AAA;padding:5px;"|[[#designdoc|Design document]]<br />
|}<br />
<br />
===<span id="side_actions"><tt>side_actions</tt> refactoring</span>===<br />
====<span id="side_actions.situation">The current situation</span>====<br />
The current implementation of <tt>side_actions</tt> use a <tt>std::deque&lt;std::deque&lt;action_ptr&gt;&gt;</tt>.<br />
In order to use it, iterators have been defined over it (<tt>side_actions::iterator</tt> and the three const and revert variants).<br />
These “flattening” iterators let users of <tt>side_actions</tt> iterate over all the planned actions, they are performing the ''zip'' operation on the fly.<br />
<br />
Furthermore, some queries like <tt>side_actions::find_first_action_of</tt> are linear in the number of action.<br />
<br />
====<span id="side_actions.idea">The idea</span>====<br />
To simplify the code, I propose to keep the action set zipped. The container's iterators will then be usable directly. In order to delimit turns, a second container will have to keep a sequence of iterators pointing to the first action of each turn.<br />
<br />
For example, let's say eight actions are planned: five for this turn, two for the next turn and one for the turn after. Three iterators will be kept to delimit turns. Here is a proof that I can't use gimp which also show the idea:<br />
http://epsilon012.free.fr/GSoC%202012/side_actions%20idea.png<br />
<br />
Of course another problem emerge: the sequence of iterator has to be kept in sync with the sequence of action.<br />
<br />
Finally, the current implementation gives access to the <tt>action_ptr</tt> only in sequence, in order to speed up different way of querying action (e.g. by hex, by unit's id), I propose to build several indexes on the action set.<br />
<br />
====<span id="side_actions.implementation">Implementation details</span>====<br />
Let's name these containers <tt>actions_</tt> and <tt>turn_beginnings_</tt>.<br />
<br />
The whiteboard have the following invariant: an empty turn (a turn without planned action) can't be followed by a non-empty turn (with at least one planned action). It means that <code>distance(turn_beginnings_[i], turn_beginnings_[i+1])&gt;0</code>, and so we can unambiguously determine the turn number of each action.<br />
<br />
Also, note that except when <tt>actions_.empty()</tt> : <tt>turn_beginnings_.front()==actions_.begin()</tt>.<br />
<br />
=====<span id="side_actions.containers">Choice of the containers</span>=====<br />
<tt>std::deque</tt> seems to be the perfect container for <tt>turn_beginnings_</tt>. It'll allow random access and we need to add/remove new turns only at the extremities.<br />
<br />
On the other hand, <tt>actions_</tt> need two proprieties:<br />
*Allow fast chronological iteration<br />
*Stable iterators<br />
*Allow fast lookup on different indexes<br />
I propose to use a <tt>boost::multi_index_container</tt>, this container is part of the library [http://www.boost.org/doc/libs/1_49_0/libs/multi_index Boost.MultiIndex] which is in Boost since version 1.32. It allows the construction of several indexes on the same set of object.<br />
<br />
There is however one problem linked to the use of the <tt>boost::multi_index::random_access</tt> index: insertion and deletion are in linear time when their are not done at the extremities.<br />
<br />
So, the new members should be:<br />
namespace bmi = boost::multi_index;<br />
typedef bmi::multi_index_container<<br />
action_ptr,<br />
bmi::indexed_by<<br />
bmi::random_access<bmi::tag<chronological> >,<br />
bmi::hashed_non_unique<bmi::tag<by_unit>, bmi::const_mem_fun<action,size_t,&action::get_unit_id> >,<br />
bmi::hashed_non_unique<bmi::tag<by_hex>, bmi::const_mem_fun<action,size_t,&action::get_hex>><br />
><br />
> action_set;<br />
typedef action_set::iterator iterator;<br />
<br />
action_set actions_;<br />
std::deque<iterator> turn_beginnings_;<br />
<br />
This suppose two new pure virtual function in <tt>action</tt>: <tt>get_unit_id</tt> and <tt>get_hex</tt>.<br />
<br />
Using action's attribute as key brings another drawback: we must notify the <tt>multi_index_container</tt> when we modify a key.<br />
However, the two used keys here (the unit's id and the hex) are never modified in the <tt>action</tt> hierarchy.<br />
<br />
This definition is here to give an idea, in practice other indexes will have to be built (e.g. an index on ''secondary hex'' which could be the source hex in <tt>move</tt>.)<br />
Note that this doesn't necessarily means a new pure virtual function in <tt>action</tt>, a key extractor can be defined to let <tt>action</tt> as it is and use ''RTTI'' instead (this might not be clever though.)<br />
<br />
=====<span id="side_actions.example">Example</span>=====<br />
Here are three functions rewritten with this new design. Note that <tt>side_actions::iterator</tt> is the one defined above.<br />
side_actions::iterator side_actions::end_turn(size_t turn_num){<br />
if(turn_num+1>=turn_beginnings_.size())<br />
return actions_.end();<br />
else<br />
return turn_beginnings_[turn_num+1];<br />
}<br />
<br />
side_actions::iterator side_actions::raw_enqueue(size_t turn_num, action_ptr act){<br />
assert(turn_num <= turn_beginnings_.size());<br />
<br />
iterator new_action = actions_.insert(end_turn(turn_num), act).first;<br />
<br />
if(turn_num >= turn_beginnings_.size())<br />
turn_beginnings_.push_back(new_action);<br />
<br />
return new_action;<br />
}<br />
<br />
side_actions::find_first_action_of(unit const* unit, side_actions::iterator start_position){<br />
// First we get all the action of this unit<br />
typedef action_set::index<by_unit>::type::iterator unit_iterator;<br />
std::pair<unit_iterator, unit_iterator> act = actions_.get<by_unit>().equal_range(unit->underlying_id());<br />
<br />
// Then we find the first of them (chronologically) after start_position<br />
iterator first = actions_.end();<br />
for(unit_iterator it = act.first; it != act.second; ++it){<br />
iterator chrono_it = actions_.project<chronological>(it);<br />
if(chrono_it < first && chrono_it > start_position)<br />
first = chrono_it;<br />
}<br />
return first;<br />
}<br />
<br />
===<span id="visitorhier">Visitor hierarchy refactoring</span>===<br />
====<span id="visitorhier.situation">The current situation</span>====<br />
The important classes and class templates of this hierarchy are:<br />
*'''<tt>visitor</tt>''' is the base class of the visitor hierarchy, it dispatches the calls to the derived classes.<br />
*'''<tt>enable_visit_all</tt>''' is actually an interface to the <tt>action_ptr</tt> objects of every single team.<br />
*'''<tt>action</tt>''' is the root class of the visitable hierarchy.<br />
<br />
Currently, when the visitor hierarchy needs to visit the visitable hierarchy, all the actions of every sides of every turn are visited using the function <tt>enable_visit_all::visit_all_helper</tt> (e.g. this function is called by <tt>highlight_visitor::find_main_highlight</tt> to find the action to highlight.)<br />
<br />
====<span id="visitorhier.idea">The idea</span>====<br />
I'm favorable to the maintain of the Visitor pattern, it segregates the different components nicely.<br />
I think the problem come from <tt>enable_visit_all</tt> and I would like to replace it with a class offering a more fine-grained access to the actions.<br />
For example, a look up by hex could be defined in this new structure and then used by <tt>highlight_visitor</tt>.<br />
Actually, most of the work of this new class will have to do is to redirect the calls to the <tt>side_actions</tt> (to one in particular or to all depending on the function).<br />
<br />
====<span id="visitorhier.implementation">Implementation details</span>====<br />
Let's name this interface <tt>action_inquirer</tt>, I'm not a particularly good English speaker, so if you have a better name in mind, let me know. :)<br />
<br />
The sole problem faced is to place <tt>action_inquirer</tt>, since it is mainly a proxy to a global resource (the <tt>side_actions</tt> of each team), it makes sense to place it directly in the <tt>wb</tt> namespace.<br />
<br />
=====<span id="visitorhier.example">Example</span>=====<br />
Here is an example function that would speed up <tt>highlight_visitor</tt>.<br />
action_ptr action_inquirer::action_at(map_location const &h){<br />
side_actions::iterator r;<br />
foreach(team& t, *resources::teams){<br />
side_actions sa = t.get_side_actions();<br />
if((r=sa.find_action_at(h)) != sa.end())<br />
return *r;<br />
}<br />
return action_ptr();<br />
}<br />
<br />
Note: the implementation of <tt>side_actions::find_action_at</tt> is similar to the one of <tt>side_actions::find_first_action_of</tt>.<br />
<br />
===<span id="mapbuilder">Merging of the validation process into <tt>mapbuilder</tt></span>===<br />
====<span id="mapbuilder.situation">The current situation</span>====<br />
Currently the validation process is separated from the mapbuilding process.<br />
However they are depending on each other.<br />
Indeed, to validate an action the previous actions have to be applied (by the mapbuilder), while in order to build the future state in the mapbuilder, the sequence of action have to be valid.<br />
<br />
====<span id="mapbuilder.idea">The idea</span>====<br />
Inject the validation process into <tt>mapbuilder</tt>. This is not limited to the merging of <tt>validate_visitor</tt> into <tt>mapbuilder</tt>, indeed some validity check are also done in the <tt>action</tt> hierarchy.<br />
<br />
====<span id="mapbuilder.implementation">Implementation details</span>====<br />
I'm still working on this.<br />
<br />
=====<span id="mapbuilder.example">Example</span>=====<br />
Idem.<br />
<br />
===<span id="polishing">Polishing</span>===<br />
Some inconsistencies are present in the code (e.g. the way units are referenced). Some other parts needs clean up or/and optimisation (e.g. usage of <tt>boost::dynamic_pointer_cast</tt>).<br />
<br />
The goal of this task is to find this kind of small problem and fix them.<br />
These two ones have been spotted by gabba, but I'm planning to add other small problems to this list as I found them.<br />
<br />
Also, they can be a good introduction to the code that's why I'm planning to start working on them before the GSoC start date.<br />
<br />
===<span id="designdoc">Design document</span>===<br />
This idea is inspired by the GUI2 design document present in the SVN.<br />
<br />
Doxygen documents the code at a function or class level.<br />
The goal is to write a documentation at the module level. That is a document describing the whiteboard design globally and not function-by-function.<br />
Actually it shouldn't duplicate what is in doxygen but complement it.<br />
This document could also include informations on how to extend the whiteboard to help future contributors.<br />
<br />
Where should this document go?<br />
*In doxygen<br />
:This makes sense since it's where most of the code documentation is.<br />
*In the wiki<br />
:This would make collaborative editing easier.<br />
<br />
If you have an opinion on this, let me know. :)<br />
<br />
===Timeline===<br />
Two of my five tasks are actually best done continuously: the design document and the polishing.<br />
Although I haven't clearly placed a week for them, I set two dates at which they should have been completed.<br />
<br />
Of course, the plan is not to have any delay and to finish each task early, however I have reserved two weeks (actually one week and a half) for unexpected delay.<br />
I named them "movable weeks", because they can move in my timeline if anything goes wrong. :)<br />
<br />
<!-- Wikitext hell 101 --><br />
{| style="border:1px dashed #AAA;border-collapse:collapse;"<br />
|-<br />
!style="border:1px dotted #AAA;padding:5px;"|Date<br />
!style="border:1px dotted #AAA;padding:5px;"|Week<br />
!style="border:1px dotted #AAA;padding:5px;"|Description<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''17/03 - 20/04''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''-11..-5''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Student application evaluation''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|17/03 - 20/04<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|-11..-5<br />
|style="border:1px dotted #AAA;padding:5px;"|Refine the proposal.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''23/04 - 20/05''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''-4..-1''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Community Bonding Period (4 weeks)''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|'''23/04 - 20/05'''<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|'''-4..-1'''<br />
|style="border:1px dotted #AAA;padding:5px;"|'''Phase 0: Approach'''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|23/04 - 20/05<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|-4..-1<br />
|style="border:1px dotted #AAA;padding:5px;"|Familiarise myself with the whiteboard, in the process start a draft of the design document.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|23/04 - 20/05<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|-4..-1<br />
|style="border:1px dotted #AAA;padding:5px;"|Start working on the ''polishing'' and on small parts of the whiteboard in order to gain commit access.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''21/05''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''0''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Start of GSoC''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|21/05 - 12/08<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|0..11<br />
|style="border:1px dotted #AAA;padding:5px;"|Continuously work on the design document and on the code polishing.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''21/05 - 15/07''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''0..7''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''First half term (8 weeks)''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|'''21/05 - 10/06'''<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|'''0..2'''<br />
|style="border:1px dotted #AAA;padding:5px;"|'''Phase 1: <tt>side_actions</tt> refactoring'''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|21/05 - 27/05<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|0<br />
|style="border:1px dotted #AAA;padding:5px;"|Prepare <tt>side_actions</tt> for the change. Add debug informations to the logs. Make the current iterators bidirectional.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|28/05 - 03/06<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|1<br />
|style="border:1px dotted #AAA;padding:5px;"|Change the underlying container and rewrite the associated functions.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|04/06 - 10/06<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|2<br />
|style="border:1px dotted #AAA;padding:5px;"|Debug, write unit test and documentation.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|'''11/06 - 01/07'''<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|'''3..5'''<br />
|style="border:1px dotted #AAA;padding:5px;"|'''Phase 2: Validator hierarchy refactoring'''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|11/06 - 17/06<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|3<br />
|style="border:1px dotted #AAA;padding:5px;"|Write the class <tt>action_inquirer</tt>.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|18/06 - 24/06<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|4<br />
|style="border:1px dotted #AAA;padding:5px;"|Replace the uses of <tt>enable_visit_all</tt> with the new interface. Then delete <tt>enable_visit_all</tt>.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|25/06 - 01/07<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|5<br />
|style="border:1px dotted #AAA;padding:5px;"|Debug, write unit test and documentation.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|'''02/07 - 22/07'''<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|'''6..8'''<br />
|style="border:1px dotted #AAA;padding:5px;"|'''Phase 3: Merging of the validation process into <tt>mapbuilder</tt>'''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|02/07 - 08/07<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|6<br />
|style="border:1px dotted #AAA;padding:5px;"|Merge <tt>validate_visitor</tt> into <tt>mapbuilder</tt>.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|09/07 - 15/07<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|7<br />
|style="border:1px dotted #AAA;padding:5px;"|Hunt down other validity check in the <tt>action</tt> hierarchy and move them to <tt>mapbuilder</tt>.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''13/07''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''7''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Mid-term evaluation''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''16/07 - 26/08''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''8..13''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Second half term (6 weeks)''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|16/07 - 22/07<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|8<br />
|style="border:1px dotted #AAA;padding:5px;"|Debug, write unit test and documentation.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|'''22/07 - 12/08'''<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|'''9..11'''<br />
|style="border:1px dotted #AAA;padding:5px;"|'''Phase 4: Finalisation'''<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|22/07 - 29/07<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|9<br />
|style="border:1px dotted #AAA;padding:5px;"|Heavy testing week.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|30/07 - 05/08<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|10<br />
|style="border:1px dotted #AAA;padding:5px;"|Test, debug. Finish the ''polishing''.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|06/08 - 12/08<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|11<br />
|style="border:1px dotted #AAA;padding:5px;"|Test, debug. Finish the design document.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|13/08 - 19/08<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|12<br />
|style="border:1px dotted #AAA;padding:5px;"|Movable week.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;"|20/08 - 26/08<br />
|style="border:1px dotted #AAA;padding:5px;text-align:center;"|13<br />
|style="border:1px dotted #AAA;padding:5px;"|Movable week.<br />
|-<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;"|''24/08''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''13''<br />
|style="border:1px dotted #AAA;padding:5px;color:#444;text-align:center;"|''Final evaluation''<br />
|}</div>Ejlshttps://wiki.wesnoth.org/index.php?title=User:Ejls/GSoC_2012/Questionnaire&diff=45943User:Ejls/GSoC 2012/Questionnaire2012-03-31T05:12:01Z<p>Ejls: update</p>
<hr />
<div>__NOTOC__<!--<br />
-->__NOEDITSECTION__<!--<br />
--><noinclude>'''Note: This is a template to be included in a proposal page by transclusion. All question are not answered here, you should refer to a proposal page.'''</noinclude><!--<br />
This template has seven parameters: the seven answers to the proposal-specific questions of section 4. --><br />
{|style="background:#FAF3E9;margin:none;border:3px double #AAA;-moz-border-radius:20px 5px 20px 5px;-webkit-border-radius:20px 5px 20px 5px;border-radius:20px 5px 20px 5px;"<br />
|-<br />
| style="text-align: left; padding: 0px 10px 5px 10px"|<br />
==Questionnaire==<br />
|-<br />
| style="text-align: center; padding:0px 10px 10px 10px;"|[[#1) Basics|Basics]] - [[#2) Experience|Experience]] - [[#3) Communication skills|Communication skills]] - [[#4) Project|Project]] - [[#5) Practical considerations|Practical considerations]]<br />
|}<br />
===1) Basics===<br />
====1.1) Write a small introduction to yourself.====<br />
My name is Étienne Simon (forename: Étienne), I'm 20 years old and I live in Paris, France. I really enjoy programming, particularly in C++ and I would like to use my programming skills on a big project like Wesnoth. Also, this year I'll participate in [http://www.prologin.org Prologin] for the third time. It's the French national programming contest, which I have been 6th and two times finalist.<br />
<br />
====1.2) State your preferred email address.====<br />
Address (at gmail dot com): etienne.jl.simon<br />
<br />
====1.3) If you have chosen a nick for IRC and Wesnoth forums, what is it?====<br />
ejls<br />
<br />
====1.4) Why do you want to participate in summer of code?====<br />
First of all, I can say I have only theoretical knowledge so far and I believe thanks to a SoC on Wesnoth, I can gain lot of experience since I'll work work on a real project. In addition to that, like I said, I like programming, being paid to do what you like doing is quite cool. Besides, I'm using open source softwares a lot, so it would be nice if my first work could be for the open source community. And of course, for the T-Shirt.<br />
<br />
====1.5) What are you studying, subject, level and school?====<br />
I'm in third and last year of a bachelor's degree (licence) in computer science at Pierre et Marie Curie, Sorbonne Université ([http://www.upmc.fr UPMC], Paris VI), I mainly took courses related to algorithm and artificial intelligence. Next year, I'll start a master's degree in artificial intelligence and decision.<br />
<br />
====1.6) What country are you from, at what time are you most likely to be able to join IRC?====<br />
I'm from France, CEST (UTC+2 during summer). I always have an irssi running on a server, but I'm more likely to answer during the afternoon and evening. However before the end of the Spring term (4th of June), I'll be able to connect at these times only the weekend and on Friday, I wont be available before 6p.m. UTC for the rest of the week .<br />
<br />
====1.7) Do you have other commitments for the summer period ? Do you plan to take any vacations ? If yes, when.====<br />
My term (including exams) ends the 4th of June, otherwise I'm considering the GSoC as a full-time job (with more fun and week-end included), therefore I don't have any plans for this summer.<br />
<br />
===2) Experience===<br />
====2.1) What programs/software have you worked on before?====<br />
Only school projects:<br />
<br />
Two years ago (during my first year), we had to code a go/othelo-like game in C. I wrote the game with some extra: a curse interface, a simple AI (alpha-beta) and an AI using unsupervised learning, for this last part, I used NEAT <span style="color: #888; font-size: 0.85em;">[NeuroEvolution of Augmenting Topologies]</span> (a genetical algorithm evolving neural networks), it didn't beat the minimax though :(. Total: 5000 SLOC <span style="color: #888; font-size: 0.85em;">[Source Lines Of Code]</span>.<br />
<br />
Last year, we wrote a BASIC compiler in C (again). I improved the BASIC language a bit: support for array, UDT, function overload and operator overload, the support of references was buggy (poorly designed). Total: 7000 ugly, messy SLOC.<br />
<br />
This year, we had to wrote an image manipulation program in C++ (finally!). I used Gtkmm (a C++ wrapper of Gtk+). The result was pretty good, documented with Doxygen and compilable with CMake or with a basic Makefile. Overall, It allowed me to get familiar with C++11 since before this project I've always used gcc 4.2. Total: 5000 SLOC (doxygen documentation (including code) available [http://epsilon012.free.fr/egami online]).<br />
<br />
====2.2) Have you developed software in a team environment before? (As opposed to hacking on something on your own)====<br />
The group projects that I worked in were about web development and database administration so I can't really say yes, but that's one of the main reasons why I want to participate in GSoC.<br />
<br />
====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?====<br />
No, not yet. :)<br />
<br />
====2.4) Are you already involved with any open source development projects? If yes, please describe the project and the scope of your involvement.====<br />
No.<br />
<br />
====2.5) Gaming experience - Are you a gamer?====<br />
Yes, everyone like to play. ;)<br />
<br />
=====2.5.1) What type of gamer are you?=====<br />
Hum… I suppose the answers in this subsection can give you an idea about my type. If I'm playing a game it's to have fun, so I'm a "for the lulz gamer", but I suppose it's the same for most people.<br />
<br />
=====2.5.2) What type of games?=====<br />
Turn-based games like Nethack, Freeciv and of course Wesnoth. I enjoy both strategy and role-playing games, but I like to have time to take a decision.<br />
<br />
I also enjoy programming games like jousting, golfing (with Vim) and programming in esoteric languages. For example, I have completed the three first questions of the French national programming contest's qualification in brainfuck, befunge and whitespace (code [http://epsilon012.free.fr/Prologin2012 here], including a 5289 instructions brainfuck program).<br />
<br />
=====2.5.3) What type of opponents do you prefer?=====<br />
Players using original and unexpected strategy. The HODOR players were really funny, but well…<br />
<br />
=====2.5.4) Are you more interested in story or gameplay?=====<br />
I tend to select a game on his gameplay, but when it misses a good story I'm less likely to play it.<br />
<br />
=====2.5.5) Have you played Wesnoth? If so, tell us roughly for how long and whether you lean towards single player or multiplayer.=====<br />
Not that much, actually I discovered Wesnoth 1.6 two years ago and I can't really say I've played it a lot since then. I prefer to play usually as single player, after completing most of the mainline campaigns (of which I really liked DiD), I played online, but now I'm mostly playing add-ons campaigns. As an indicator: I'm still unable to list drakes units.<br />
<br />
====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.====<br />
I have been lurking the code for a good time now, in January 2011, I reported 3 bugs with 1-line patch attached:<br />
*Two compilation errors: [https://gna.org/bugs/?17584 Bug #17584] and [https://gna.org/bugs/?17585 Bug #17585].<br />
*A minimap bug: [https://gna.org/bugs/?17676 Bug #17676].<br />
I have also written longer patches:<br />
*'''(AI)''' [https://gna.org/patch/?3185 Patch #3185] <tt>power_projection</tt> improvement, it now takes in account future ToD and time areas, I also cleaned the code a bit (task from the [[EasyCoding]] page.)<br />
*'''(WB)''' [https://gna.org/patch/?3201 Patch #3201] Make leader unable to move when invalidating a planned recall (fixes [https://gna.org/bugs/?19581 Bug #19581] that I found reading the whiteboard code.)<br />
<br />
===3) Communication skills===<br />
====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.====<br />
I have studied one term in London last winter, so, my level is good enough to understand and to be understood, don't expect an error-free essay from me though. :)<br />
<br />
====3.2) What spoken languages are you fluent in?====<br />
French and English.<br />
<br />
====3.3) Are you good at interacting with other players? Our developer community is friendly, but the player community can be a bit rough.====<br />
I'm a really calm person, I always take my time to answer messages. Otherwise, I'm ignoring flamers, I think it's the best to do.<br />
<br />
====3.4) Do you give constructive advice?====<br />
I try to.<br />
<br />
====3.5) Do you receive advice well?====<br />
Well, I enjoy receiving advices and learning, otherwise I wouldn't be here. :)<br />
<br />
====3.6) Are you good at sorting useful criticisms from useless ones?====<br />
I think most criticisms are useful, I'm used to the Internet though, troll don't ambush me.<br />
<br />
====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====<br />
It depends of what have to be done, the bigger the work is the more it has to be discussed. However if my proposal is retained, I might be a bit more scared of doing something bad in the beginning, so I might discuss a solution more than usual. :)<br />
<br />
===4) Project===<br />
====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?====<br />
<noinclude>'''Note: this page is a template, the answer to this question is a parameter. Please, refer to a proposal page.'''</noinclude>{{{1|}}}<br />
<br />
====4.2) If you have invented your own project, please describe the project and the scope.====<br />
<noinclude>'''Note: this page is a template, the answer to this question is a parameter. Please, refer to a proposal page.'''</noinclude>{{{2|}}}<br />
<br />
====4.3) Why did you choose this project?====<br />
<noinclude>'''Note: this page is a template, the answer to this question is a parameter. Please, refer to a proposal page.'''</noinclude>{{{3|}}}<br />
<br />
====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".====<br />
<noinclude>'''Note: this page is a template, the answer to this question is a parameter. Please, refer to a proposal page.'''</noinclude>{{{4|}}}<br />
<br />
====4.5) Include as much technical detail about your implementation as you can====<br />
<noinclude>'''Note: this page is a template, the answer to this question is a parameter. Please, refer to a proposal page.'''</noinclude>{{{5|}}}<br />
<br />
====4.6) What do you expect to gain from this project?====<br />
<noinclude>'''Note: this page is a template, the answer to this question is a parameter. Please, refer to a proposal page.'''</noinclude>{{{6|}}}<br />
<br />
====4.7) What would make you stay in the Wesnoth community after the conclusion of SOC?====<br />
<noinclude>'''Note: this page is a template, the answer to this question is a parameter. Please, refer to a proposal page.'''</noinclude>{{{7|}}}<br />
<br />
===5) Practical considerations===<br />
====5.1) Are you familiar with any of the following tools or languages?====<br />
*Subversion<br />
:I've already used it, but I've opted for git instead.<br />
*C++ (language used for all the normal source code)<br />
:I'm a big fan. I follow the WG21 publications and I often read comp.std.c++ and comp.lang.c++.moderated.<br />
*STL, Boost, Sdl (C++ libraries used by Wesnoth)<br />
:I'm of course used to the stdlib (not to all addition of C++11 though). I'm not familiar with all Boost (I don't have enough brain for this). But I have often used the parts of Boost that's are now (more or less) in the C++11 stdlib and the MPL. I also used a bit Asio, Filesystem and Phoenix (for being the most WTF library), and some other small libraries like Program Option and Range. I never worked on a project using the SDL, I'm not a big GUI user.<br />
*Python (optional, mainly used for tools)<br />
:Not really, no, really basic.<br />
*build environments (eg cmake/scons)<br />
:I've already wrote some CMakeList.txt, but I never worked with nor used scons.<br />
*WML (the wesnoth specific scenario language)<br />
:I wrote a [[User:Ejls/Vim|Vim syntax]] file for it, so I'm already a bit familiar with it. I'm missing practice though.<br />
*Lua (used in combination with WML to create scenarios)<br />
:I'm familiar with it, not as much as C++ but I already used it as a scripting language for an (annoying) IRC bot I wrote. I'm not familiar with its integration in Wesnoth though.<br />
<br />
====5.2) Which tools do you normally use for development? Why do you use them?====<br />
Vim and Unix tools, Perl for big stuff. They are the most productive tools for me, I'm used to them. I'm coding with a laptop under OpenBSD (with gcc 4.2). I also compile Wesnoth on a Debian server (with gcc 4.6), but the X over ssh is a bit slow sometimes. Finally, I temporally have a laptop with FreeBSD 9.0.<br />
<br />
====5.3) What programming languages are you fluent in?====<br />
I'm good in C++, C, Lua, Perl and VimScript. I've a lack of practice in Java, Caml, Scheme, NetLogo, CLIPS and AiML (all of them learnt during my studies). On a different note, I like brainfuck, befunge, whitespace and golfscript.<br />
<br />
====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!====<br />
If you can't join me by email or on IRC, I'm probably dead but sometimes it's easier to speak than to write so I'll include my phone number in my application.</div>Ejlshttps://wiki.wesnoth.org/index.php?title=User:Avrilfanomar&diff=45925User:Avrilfanomar2012-03-29T22:28:25Z<p>Ejls: Put it in the good category</p>
<hr />
<div>{{SoC2012Student}}<br />
[[Category:SoC_Ideas_AI_Defense_Strategies_2012]]<br />
<br />
=Description=<br />
<h4>Andriy Andriychuk - "Total defence" strategy</h4><br />
The idea is to group own troops so they are in advantageous position and get less damage.<br />
=Brief algorithm=<br />
Troops will hold advantageous position and protect weak units. If it is possible, damaged units will be changing with more healthy. It is also important not to give opponent a chance to attack one unit using many own units(to surround unit). <br />
Of course, this is are just very basics. Much more principles and ideas will be included.<br />
<br />
=IRC=<br />
avrilfanomar<br />
<br />
=Questionnaire=<br />
==1) Basics==<br />
<br />
===1.1) Write a small introduction to yourself.===<br />
<br />
My name is Andriy Andriychuk, I'm student learning programming. I am persistent and responsible.<br />
<br />
===1.2) State your preferred email address.===<br />
<br />
andrey000mar@gmail.com<br />
<br />
===1.3) If you have chosen a nick for IRC and Wesnoth forums, what is it?===<br />
<br />
avrilfanomar<br />
<br />
===1.4) Why do you want to participate in summer of code?===<br />
<br />
First of all, it's great experience to contribute in such a good program. Second, it's very interesting to deal with open source. Third, it's an opportunity to show everybody your skills.<br />
<br />
===1.5) What are you studying, subject, level and school?===<br />
<br />
I'm studying programming languages(C++, Java, Python), paradigms, web-technologies, math. I'm a third-year student on Faculty of Cybernetics at Taras Shevchenko National University of Kyiv.<br />
<br />
===1.6) What country are you from, at what time are you most likely to be able to join IRC?===<br />
<br />
I'm from Ukraine, Kyiv. I can be able on IRC from 10:00 till 17:00 (UT0).<br />
<br />
===1.7) Do you have other commitments for the summer period ? Do you plan to take any vacations ? If yes, when.===<br />
<br />
No. <br />
<br />
<br />
<br />
==2) Experience==<br />
<br />
<br />
<br />
===2.1) What programs/software have you worked on before?===<br />
<br />
I've worked in game development (C++). I made a lot of different programs in Java using most popular technologies. Also i have some skills in Python. For more details, please watch my CV.<br />
<br />
===2.2) Have you developed software in a team environment before? (As opposed to hacking on something on your own)===<br />
<br />
Yes. I've used SVN (in company i've worked on) and Mercurial (in students team and alone). <br />
<br />
===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?===<br />
<br />
No.<br />
<br />
===2.4) Are you already involved with any open source development projects? If yes, please describe the project and the scope of your involvement.===<br />
<br />
No. <br />
<br />
===2.5) Gaming experience - Are you a gamer?===<br />
<br />
Well, I like to play, but not too often.<br />
<br />
====2.5.1) What type of gamer are you?====<br />
<br />
I prefer strategy games(graphics is the most unimportant thing for me) where it's a must to think of what you are doing every step.<br />
<br />
====2.5.2) What type of games?====<br />
<br />
Strategy games, RPG.<br />
<br />
====2.5.3) What type of opponents do you prefer?==== <br />
<br />
I prefer a strong skilled player(or AI), even stronger than me. That's because of I don't want to win easy and I want to improve my skills.<br />
<br />
====2.5.4) Are you more interested in story or gameplay?====<br />
<br />
Gameplay, definetly. But I also like to dive into interesting stories. <br />
<br />
===2.5.5) Have you played Wesnoth? If so, tell us roughly for how long and whether you lean towards single player or multiplayer.====<br />
<br />
<br />
<br />
Yes, I played campaign latest weeks. <br />
<br />
<br />
<br />
===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.===<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
==3) Communication skills==<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
===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.===<br />
<br />
<br />
<br />
Intermediate English. <br />
<br />
<br />
<br />
===3.2) What spoken languages are you fluent in?===<br />
<br />
<br />
<br />
English, Ukrainian, Russian. <br />
<br />
<br />
<br />
===3.3) Are you good at interacting with other players? Our developer community is friendly, but the player community can be a bit rough.===<br />
<br />
<br />
<br />
Yes. I'm patient and ready to explain everything correctly.<br />
<br />
<br />
<br />
===3.4) Do you give constructive advice? ===<br />
<br />
<br />
<br />
Yes.<br />
<br />
<br />
<br />
===3.5) Do you receive advice well?===<br />
<br />
<br />
<br />
Definitely. I like good advice and appreciate that.<br />
<br />
<br />
<br />
===3.6) Are you good at sorting useful criticisms from useless ones?===<br />
<br />
<br />
<br />
Yes. Good criticism is almost always clear, in cases it is not I'm able to understand gamers too.<br />
<br />
<br />
<br />
===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.===<br />
<br />
<br />
<br />
I always try to explain every step of my work before I make it, because it's much better I think.<br />
<br />
<br />
<br />
===4) Project===<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
===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?===<br />
<br />
<br />
<br />
Yes. I selected project "AI: Implement a 'total defense' strategy". I want to concentrate on making AI really strong.<br />
<br />
<br />
<br />
===4.2) If you have invented your own project, please describe the project and the scope.===<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
===4.3) Why did you choose this project?===<br />
<br />
<br />
<br />
Because it's really interesting and I have experience in similar programming. <br />
<br />
<br />
<br />
===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".===<br />
<br />
<br />
<br />
As i have exams from 12.05 till 28.05 I'll be able only to study game engine and specially needed for my project part of it till June.<br />
<br />
<br />
<br />
In June I'll be coding the skeleton(basics) of my defensive AI.<br />
<br />
<br />
<br />
In July I'll code all planned functionality.<br />
<br />
<br />
<br />
August will be testing and fixing any errors that can appear.<br />
<br />
<br />
<br />
===4.5) Include as much technical detail about your implementation as you can===<br />
<br />
<br />
<br />
I'll code on C++ using QT Creator environment and SVN version control system.<br />
<br />
<br />
<br />
===4.6) What do you expect to gain from this project?===<br />
<br />
<br />
<br />
Experience, first of all. I hope to gain estimation also and some money, of course.<br />
<br />
<br />
<br />
===4.7) What would make you stay in the Wesnoth community after the conclusion of SOC? ===<br />
<br />
<br />
<br />
Interesting projects, payment or opportunity to get great work in the future. <br />
<br />
<br />
<br />
==5) Practical considerations==<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
===5.1) Are you familiar with any of the following tools or languages?===<br />
<br />
<br />
<br />
* Subversion (used for all commits)<br />
<br />
<br />
<br />
Yes, I have experience with it.<br />
<br />
<br />
<br />
* C++ (language used for all the normal source code)<br />
<br />
<br />
<br />
Yes, of course.<br />
<br />
<br />
<br />
* STL, Boost, Sdl (C++ libraries used by Wesnoth)<br />
<br />
<br />
<br />
I have some experience in STL.<br />
<br />
<br />
<br />
* Python (optional, mainly used for tools)<br />
<br />
<br />
<br />
Yes, I wrote some programs on it.<br />
<br />
<br />
<br />
* build environments (eg cmake/scons)<br />
<br />
<br />
<br />
No.<br />
<br />
<br />
<br />
* WML (the wesnoth specific scenario language)<br />
<br />
<br />
<br />
No.<br />
<br />
<br />
<br />
* Lua (used in combination with WML to create scenarios)<br />
<br />
<br />
<br />
No.<br />
<br />
<br />
<br />
===5.2) Which tools do you normally use for development? Why do you use them?===<br />
<br />
<br />
<br />
QT Creator. Because it's comfortable to deal with it.<br />
<br />
<br />
<br />
===5.3) What programming languages are you fluent in?===<br />
<br />
<br />
<br />
C++, Java, Python.</div>Ejlshttps://wiki.wesnoth.org/index.php?title=User:Avrilfanomar&diff=45924User:Avrilfanomar2012-03-29T22:26:21Z<p>Ejls: Making the page SummerOfCodeIdeas-friendly.</p>
<hr />
<div>{{SoC2012Student}}<br />
[[Category:SoC_Ideas_Your_Own_Ideas2012]]<br />
<br />
=Description=<br />
<h4>Andriy Andriychuk - "Total defence" strategy</h4><br />
The idea is to group own troops so they are in advantageous position and get less damage.<br />
=Brief algorithm=<br />
Troops will hold advantageous position and protect weak units. If it is possible, damaged units will be changing with more healthy. It is also important not to give opponent a chance to attack one unit using many own units(to surround unit). <br />
Of course, this is are just very basics. Much more principles and ideas will be included.<br />
<br />
=IRC=<br />
avrilfanomar<br />
<br />
=Questionnaire=<br />
==1) Basics==<br />
<br />
===1.1) Write a small introduction to yourself.===<br />
<br />
My name is Andriy Andriychuk, I'm student learning programming. I am persistent and responsible.<br />
<br />
===1.2) State your preferred email address.===<br />
<br />
andrey000mar@gmail.com<br />
<br />
===1.3) If you have chosen a nick for IRC and Wesnoth forums, what is it?===<br />
<br />
avrilfanomar<br />
<br />
===1.4) Why do you want to participate in summer of code?===<br />
<br />
First of all, it's great experience to contribute in such a good program. Second, it's very interesting to deal with open source. Third, it's an opportunity to show everybody your skills.<br />
<br />
===1.5) What are you studying, subject, level and school?===<br />
<br />
I'm studying programming languages(C++, Java, Python), paradigms, web-technologies, math. I'm a third-year student on Faculty of Cybernetics at Taras Shevchenko National University of Kyiv.<br />
<br />
===1.6) What country are you from, at what time are you most likely to be able to join IRC?===<br />
<br />
I'm from Ukraine, Kyiv. I can be able on IRC from 10:00 till 17:00 (UT0).<br />
<br />
===1.7) Do you have other commitments for the summer period ? Do you plan to take any vacations ? If yes, when.===<br />
<br />
No. <br />
<br />
<br />
<br />
==2) Experience==<br />
<br />
<br />
<br />
===2.1) What programs/software have you worked on before?===<br />
<br />
I've worked in game development (C++). I made a lot of different programs in Java using most popular technologies. Also i have some skills in Python. For more details, please watch my CV.<br />
<br />
===2.2) Have you developed software in a team environment before? (As opposed to hacking on something on your own)===<br />
<br />
Yes. I've used SVN (in company i've worked on) and Mercurial (in students team and alone). <br />
<br />
===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?===<br />
<br />
No.<br />
<br />
===2.4) Are you already involved with any open source development projects? If yes, please describe the project and the scope of your involvement.===<br />
<br />
No. <br />
<br />
===2.5) Gaming experience - Are you a gamer?===<br />
<br />
Well, I like to play, but not too often.<br />
<br />
====2.5.1) What type of gamer are you?====<br />
<br />
I prefer strategy games(graphics is the most unimportant thing for me) where it's a must to think of what you are doing every step.<br />
<br />
====2.5.2) What type of games?====<br />
<br />
Strategy games, RPG.<br />
<br />
====2.5.3) What type of opponents do you prefer?==== <br />
<br />
I prefer a strong skilled player(or AI), even stronger than me. That's because of I don't want to win easy and I want to improve my skills.<br />
<br />
====2.5.4) Are you more interested in story or gameplay?====<br />
<br />
Gameplay, definetly. But I also like to dive into interesting stories. <br />
<br />
===2.5.5) Have you played Wesnoth? If so, tell us roughly for how long and whether you lean towards single player or multiplayer.====<br />
<br />
<br />
<br />
Yes, I played campaign latest weeks. <br />
<br />
<br />
<br />
===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.===<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
==3) Communication skills==<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
===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.===<br />
<br />
<br />
<br />
Intermediate English. <br />
<br />
<br />
<br />
===3.2) What spoken languages are you fluent in?===<br />
<br />
<br />
<br />
English, Ukrainian, Russian. <br />
<br />
<br />
<br />
===3.3) Are you good at interacting with other players? Our developer community is friendly, but the player community can be a bit rough.===<br />
<br />
<br />
<br />
Yes. I'm patient and ready to explain everything correctly.<br />
<br />
<br />
<br />
===3.4) Do you give constructive advice? ===<br />
<br />
<br />
<br />
Yes.<br />
<br />
<br />
<br />
===3.5) Do you receive advice well?===<br />
<br />
<br />
<br />
Definitely. I like good advice and appreciate that.<br />
<br />
<br />
<br />
===3.6) Are you good at sorting useful criticisms from useless ones?===<br />
<br />
<br />
<br />
Yes. Good criticism is almost always clear, in cases it is not I'm able to understand gamers too.<br />
<br />
<br />
<br />
===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.===<br />
<br />
<br />
<br />
I always try to explain every step of my work before I make it, because it's much better I think.<br />
<br />
<br />
<br />
===4) Project===<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
===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?===<br />
<br />
<br />
<br />
Yes. I selected project "AI: Implement a 'total defense' strategy". I want to concentrate on making AI really strong.<br />
<br />
<br />
<br />
===4.2) If you have invented your own project, please describe the project and the scope.===<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
===4.3) Why did you choose this project?===<br />
<br />
<br />
<br />
Because it's really interesting and I have experience in similar programming. <br />
<br />
<br />
<br />
===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".===<br />
<br />
<br />
<br />
As i have exams from 12.05 till 28.05 I'll be able only to study game engine and specially needed for my project part of it till June.<br />
<br />
<br />
<br />
In June I'll be coding the skeleton(basics) of my defensive AI.<br />
<br />
<br />
<br />
In July I'll code all planned functionality.<br />
<br />
<br />
<br />
August will be testing and fixing any errors that can appear.<br />
<br />
<br />
<br />
===4.5) Include as much technical detail about your implementation as you can===<br />
<br />
<br />
<br />
I'll code on C++ using QT Creator environment and SVN version control system.<br />
<br />
<br />
<br />
===4.6) What do you expect to gain from this project?===<br />
<br />
<br />
<br />
Experience, first of all. I hope to gain estimation also and some money, of course.<br />
<br />
<br />
<br />
===4.7) What would make you stay in the Wesnoth community after the conclusion of SOC? ===<br />
<br />
<br />
<br />
Interesting projects, payment or opportunity to get great work in the future. <br />
<br />
<br />
<br />
==5) Practical considerations==<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
===5.1) Are you familiar with any of the following tools or languages?===<br />
<br />
<br />
<br />
* Subversion (used for all commits)<br />
<br />
<br />
<br />
Yes, I have experience with it.<br />
<br />
<br />
<br />
* C++ (language used for all the normal source code)<br />
<br />
<br />
<br />
Yes, of course.<br />
<br />
<br />
<br />
* STL, Boost, Sdl (C++ libraries used by Wesnoth)<br />
<br />
<br />
<br />
I have some experience in STL.<br />
<br />
<br />
<br />
* Python (optional, mainly used for tools)<br />
<br />
<br />
<br />
Yes, I wrote some programs on it.<br />
<br />
<br />
<br />
* build environments (eg cmake/scons)<br />
<br />
<br />
<br />
No.<br />
<br />
<br />
<br />
* WML (the wesnoth specific scenario language)<br />
<br />
<br />
<br />
No.<br />
<br />
<br />
<br />
* Lua (used in combination with WML to create scenarios)<br />
<br />
<br />
<br />
No.<br />
<br />
<br />
<br />
===5.2) Which tools do you normally use for development? Why do you use them?===<br />
<br />
<br />
<br />
QT Creator. Because it's comfortable to deal with it.<br />
<br />
<br />
<br />
===5.3) What programming languages are you fluent in?===<br />
<br />
<br />
<br />
C++, Java, Python.</div>Ejlshttps://wiki.wesnoth.org/index.php?title=SoC2012_Template_of_Student_page&diff=45923SoC2012 Template of Student page2012-03-29T22:23:46Z<p>Ejls: Undo Avrilfanomar's edits</p>
<hr />
<div>{{SoC2012Student}}<br />
[[Category:SoC_Ideas_Your_Own_Ideas2012]]<br />
<br />
=ATTENTION=<br />
'''DO NOT EDIT THIS PAGE, SoC2012_Template_of_Student_Page, - MAKE A COPY!'''<br />
<br />
=Description=<br />
<h4>TODO: Copy this page and write "your name - proposal title" in this h4 section </h4><br />
TODO: Write a small (1-4 sentences) description of your proposal here.<br />
<br />
TODO: Add more first-level sections to detail your proposal<br />
<br />
=IRC=<br />
put ONLY your irc nickname in there. in case of alternate nicks, separate by ,<br />
<br />
Example content of this section: "user" "user1, user2"<br />
<br />
=Questionnaire=<br />
TODO: fill out this questionnaire<br />
[[SoC_Information_for_Google#Does your organization have an application template you would like to see students use?]]</div>Ejlshttps://wiki.wesnoth.org/index.php?title=User:Ejls/GSoC_2012/Whiteboard_Backend_Refactoring&diff=45825User:Ejls/GSoC 2012/Whiteboard Backend Refactoring2012-03-25T20:26:25Z<p>Ejls: Setting up my userspace (part 3), preparing a proposal.</p>
<hr />
<div>=Description=<br />
I'm planning to propose a project based on [[SoC Ideas Whiteboard Backend Refactoring 2012]]. But it's still in redaction. ;)</div>Ejlshttps://wiki.wesnoth.org/index.php?title=User:Ejls/GSoC_2012/Questionnaire&diff=45824User:Ejls/GSoC 2012/Questionnaire2012-03-25T20:26:13Z<p>Ejls: My answers to the questionnaire</p>
<hr />
<div>__NOTOC__<noinclude>'''Note: This is a template to be included in a proposal page by transclusion. All question are not answered here, you should refer to a proposal page.'''</noinclude><!-- This template has seven parameters: the seven answers to the proposal-specific questions of section 4. --><br />
{|style="background:#FAF3E9;margin:none;border:3px double #AAA;-moz-border-radius:20px 5px 20px 5px;-webkit-border-radius:20px 5px 20px 5px;border-radius:20px 5px 20px 5px;"<br />
|-<br />
| style="text-align: left; padding: 0px 10px 5px 10px"|<h1>Questionnaire</h1><hr /><br />
|-<br />
| style="text-align: center; padding:0px 10px 10px 10px;"|[[#1) Basics|Basics]] - [[#2) Experience|Experience]] - [[#3) Communication skills|Communication skills]] - [[#4) Project|Project]] - [[#5) Practical considerations|Practical considerations]]<br />
|}<br />
===1) Basics===<br />
====1.1) Write a small introduction to yourself.====<br />
My name is Étienne Simon (forename: Étienne), I'm 20 years old and I live in Paris, France. I really enjoy programming, particularly in C++ and I would like to use my programming skills on a big project like Wesnoth. Also, this year I'll participate in [http://www.prologin.org Prologin] for the third time. It's the French national programming contest, which I have been 6th and two times finalist.<br />
<br />
====1.2) State your preferred email address.====<br />
Address (at gmail dot com): etienne.jl.simon<br />
<br />
====1.3) If you have chosen a nick for IRC and Wesnoth forums, what is it?====<br />
ejls<br />
<br />
====1.4) Why do you want to participate in summer of code?====<br />
First of all, I can say I have only theoretical knowledge so far and I believe thanks to a SoC on Wesnoth, I can gain lot of experience since I'll work work on a real project. In addition to that, like I said, I like programming, being paid to do what you like doing is quite cool. Besides, I'm using open source softwares a lot, so it would be nice if my first work could be for the open source community. And of course, for the T-Shirt.<br />
<br />
====1.5) What are you studying, subject, level and school?====<br />
I'm in third and last year of a bachelor's degree (licence) in computer science at Pierre et Marie Curie, Sorbonne Université ([http://www.upmc.fr UPMC], Paris VI), I mainly took courses related to algorithm and artificial intelligence. Next year, I'll start a master's degree in artificial intelligence and decision.<br />
<br />
====1.6) What country are you from, at what time are you most likely to be able to join IRC?====<br />
I'm from France, CE(S)T (UTC+1, +2 during summer). I always have an irssi running on a server, but I'm more likely to answer during the afternoon and evening. However before the end of the Spring term (4th of June), I'll be able to connect at these times only the weekend and on Friday, I wont be available before 6p.m. UTC for the rest of the week .<br />
<br />
====1.7) Do you have other commitments for the summer period ? Do you plan to take any vacations ? If yes, when.====<br />
My term (including exams) ends the 4th of June, otherwise I'm considering the GSoC as a full-time job (with more fun and week-end included), therefore I don't have any plans for this summer.<br />
<br />
===2) Experience===<br />
====2.1) What programs/software have you worked on before?====<br />
Only school projects:<br />
<br />
Two years ago (during my first year), we had to code a go/othelo-like game in C. I wrote the game with some extra: a curse interface, a simple AI (alpha-beta) and an AI using unsupervised learning, for this last part, I used NEAT <span style="color: #888; font-size: 0.85em;">[NeuroEvolution of Augmenting Topologies]</span> (a genetical algorithm evolving neural networks), it didn't beat the minimax though :(. Total: 5000 SLOC <span style="color: #888; font-size: 0.85em;">[Source Lines Of Code]</span>.<br />
<br />
Last year, we wrote a BASIC compiler in C (again). I improved the BASIC language a bit: support for array, UDT, function overload and operator overload, the support of references was buggy (poorly designed). Total: 7000 ugly, messy SLOC.<br />
<br />
This year, we had to wrote an image manipulation program in C++ (finally!). I used Gtkmm (a C++ wrapper of Gtk+). The result was pretty good, documented with Doxygen and compilable with CMake or with a basic Makefile. Overall, It allowed me to get familiar with C++11 since before this project I've always used gcc 4.2. Total: 5000 SLOC (doxygen documentation (including code) available [http://epsilon012.free.fr/egami online]).<br />
<br />
====2.2) Have you developed software in a team environment before? (As opposed to hacking on something on your own)====<br />
The group projects that I worked in were about web development and database administration so I can't really say yes, but that's one of the main reasons why I want to participate in GSoC.<br />
<br />
====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?====<br />
No, not yet. :)<br />
<br />
====2.4) Are you already involved with any open source development projects? If yes, please describe the project and the scope of your involvement.====<br />
No.<br />
<br />
====2.5) Gaming experience - Are you a gamer?====<br />
Yes, everyone like to play. ;)<br />
<br />
=====2.5.1) What type of gamer are you?=====<br />
Hum… I suppose the answers in this subsection can give you an idea about my type. If I'm playing a game it's to have fun, so I'm a "for the lulz gamer", but I suppose it's the same for most people.<br />
<br />
=====2.5.2) What type of games?=====<br />
Turn-based games like Nethack, Freeciv and of course Wesnoth. I enjoy both strategy and role-playing games, but I like to have time to take a decision.<br />
<br />
I also enjoy programming games like jousting, golfing (with Vim) and programming in esoteric languages. For example, I have completed the three first questions of the French national programming contest's qualification in brainfuck, befunge and whitespace (code [http://epsilon012.free.fr/Prologin2012 here], including a 5289 instructions brainfuck program).<br />
<br />
=====2.5.3) What type of opponents do you prefer?=====<br />
Players using original and unexpected strategy. The HODOR players were really funny, but well…<br />
<br />
=====2.5.4) Are you more interested in story or gameplay?=====<br />
I tend to select a game on his gameplay, but when it misses a good story I'm less likely to play it.<br />
<br />
=====2.5.5) Have you played Wesnoth? If so, tell us roughly for how long and whether you lean towards single player or multiplayer.=====<br />
Not that much, actually I discovered Wesnoth 1.6 two years ago and I can't really say I've played it a lot since then. I prefer to play usually as single player, after completing most of the mainline campaigns (of which I really liked DiD), I played online, but now I'm mostly playing add-ons campaigns. As an indicator: I'm still unable to list drakes units.<br />
<br />
====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.====<br />
I have been lurking the code for a good time now, in January 2011, I reported 3 bugs with 1-line patch attached:<br />
*Two compilation errors: [https://gna.org/bugs/?17584 Bug #17584] and [https://gna.org/bugs/?17585 Bug #17585].<br />
*A minimap bug: [https://gna.org/bugs/?17676 Bug #17676].<br />
I have also written longer patches:<br />
*'''(AI)''' [https://gna.org/patch/?3185 Patch #3185] <tt>power_projection</tt> improvement, it now takes in account future ToD and time areas, I also cleaned the code a bit (task from the [[EasyCoding]] page.)<br />
*'''(WB)''' [https://gna.org/patch/?3201 Patch #3201] Make leader unable to move when invalidating a planned recall (fixes [https://gna.org/bugs/?19581 Bug #19581] that I found reading the whiteboard code.)<br />
<br />
===3) Communication skills===<br />
====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.====<br />
I have studied one term in London last winter, so, my level is good enough to understand and to be understood, don't expect an error-free essay from me though. :)<br />
<br />
====3.2) What spoken languages are you fluent in?====<br />
French and English.<br />
<br />
====3.3) Are you good at interacting with other players? Our developer community is friendly, but the player community can be a bit rough.====<br />
I'm a really calm person, I always take my time to answer messages. Otherwise, I'm ignoring flamers, I think it's the best to do.<br />
<br />
====3.4) Do you give constructive advice?====<br />
I try to.<br />
<br />
====3.5) Do you receive advice well?====<br />
Well, I enjoy receiving advices and learning, otherwise I wouldn't be here. :)<br />
<br />
====3.6) Are you good at sorting useful criticisms from useless ones?====<br />
I think most criticisms are useful, I'm used to the Internet though, troll don't ambush me.<br />
<br />
====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====<br />
It depends of what have to be done, the bigger the work is the more it has to be discussed. However if my proposal is retained, I might be a bit more scared of doing something bad in the beginning, so I might discuss a solution more than usual. :)<br />
<br />
===4) Project===<br />
====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?====<br />
<noinclude>'''Note: this page is a template, the answer to this question is a parameter. Please, refer to a proposal page.'''</noinclude>{{{1|}}}<br />
<br />
====4.2) If you have invented your own project, please describe the project and the scope.====<br />
<noinclude>'''Note: this page is a template, the answer to this question is a parameter. Please, refer to a proposal page.'''</noinclude>{{{2|}}}<br />
<br />
====4.3) Why did you choose this project?====<br />
<noinclude>'''Note: this page is a template, the answer to this question is a parameter. Please, refer to a proposal page.'''</noinclude>{{{3|}}}<br />
<br />
====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".====<br />
<noinclude>'''Note: this page is a template, the answer to this question is a parameter. Please, refer to a proposal page.'''</noinclude>{{{4|}}}<br />
<br />
====4.5) Include as much technical detail about your implementation as you can====<br />
<noinclude>'''Note: this page is a template, the answer to this question is a parameter. Please, refer to a proposal page.'''</noinclude>{{{5|}}}<br />
<br />
====4.6) What do you expect to gain from this project?====<br />
<noinclude>'''Note: this page is a template, the answer to this question is a parameter. Please, refer to a proposal page.'''</noinclude>{{{6|}}}<br />
<br />
====4.7) What would make you stay in the Wesnoth community after the conclusion of SOC?====<br />
<noinclude>'''Note: this page is a template, the answer to this question is a parameter. Please, refer to a proposal page.'''</noinclude>{{{7|}}}<br />
<br />
===5) Practical considerations===<br />
====5.1) Are you familiar with any of the following tools or languages?====<br />
*Subversion<br />
:I've already used it but I'm more used to mercurial, so I'll maybe opt for git instead since it looks like it's already used by some devs.<br />
*C++ (language used for all the normal source code)<br />
:I'm a big fan. I follow the WG21 publications and I often read comp.std.c++ and comp.lang.c++.moderated.<br />
*STL, Boost, Sdl (C++ libraries used by Wesnoth)<br />
:I'm of course used to the stdlib (not to all addition of C++11 though). I'm not familiar with all Boost (I don't have enough brain for this). But I have often used the parts of Boost that's are now (more or less) in the C++11 stdlib and the MPL. I also used a bit Asio, Filesystem and Phoenix (for being the most WTF library), and some other small libraries like Program Option and Range. I never worked on a project using the SDL, I'm not a big GUI user.<br />
*Python (optional, mainly used for tools)<br />
:Not really, no, really basic.<br />
*build environments (eg cmake/scons)<br />
:I've already wrote some CMakeList.txt, but I never worked with nor used scons.<br />
*WML (the wesnoth specific scenario language)<br />
:I wrote a [[User:Ejls/Vim|Vim syntax]] file for it, so I'm already a bit familiar with it. I'm missing practice though.<br />
*Lua (used in combination with WML to create scenarios)<br />
:I'm familiar with it, not as much as C++ but I already used it as a scripting language for an (annoying) IRC bot I wrote. I'm not familiar with its integration in Wesnoth though.<br />
<br />
====5.2) Which tools do you normally use for development? Why do you use them?====<br />
Vim and Unix tools, Perl for big stuff. They are the most productive tools for me, I'm used to them. I'm coding with a laptop under OpenBSD (with gcc 4.2). I also compile Wesnoth on a Debian server (with gcc 4.6), but the X over ssh is a bit slow sometimes. Finally, I temporally have a laptop with FreeBSD 9.0.<br />
<br />
====5.3) What programming languages are you fluent in?====<br />
I'm good in C++, C, Lua, Perl and VimScript. I've a lack of practice in Java, Caml, Scheme, NetLogo, CLIPS and AiML (all of them learnt during my studies). On a different note, I like brainfuck, befunge, whitespace and golfscript.<br />
<br />
====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!====<br />
If you can't join me by email or on IRC, I'm probably dead but sometimes it's easier to speak than to write so I'll include my phone number in my application.</div>Ejlshttps://wiki.wesnoth.org/index.php?title=User:Ejls&diff=45823User:Ejls2012-03-25T20:26:07Z<p>Ejls: Setting up my userspace (part 2).</p>
<hr />
<div>__NOTOC__<br />
==Contact==<br />
{| style="border:3px double #AAA;border-collapse:collapse;"<br />
|- style="border:1px dashed #AAA;"<br />
! style="text-align:left;"|Email<br />
| Address at gmail dot com: etienne.jl.simon<br />
|- style="border:1px dashed #AAA;"<br />
! style="text-align:left;"|Forum, Gna, IRC (@freenode)<br />
| ejls<br />
|- style="border:1px dashed #AAA;"<br />
! style="text-align:left;"|Wiki<br />
| [[{{TALKPAGENAME}}]]<br />
|}<br />
<br />
==GSoC 2012 proposal==<br />
{{User:Ejls/GSoC 2012/Whiteboard Backend Refactoring#Description}}<br />
<br />
<center><span style="font-size:1.4em;">'''&gt; [[User:Ejls/GSoC 2012/Whiteboard Backend Refactoring|Proposal page]] &lt;'''</span></center><br />
<br />
==Work==<br />
*[[User:Ejls/Vim|WML syntax support for Vim]]<br />
*[https://gna.org/patch/?3185 Patch #3185] <tt>power_projection</tt> improvement<br />
*[https://gna.org/patch/?3201 Patch #3201] Make leader unable to move when invalidating a planned recall<br />
<br />
==Subpages==<br />
*[[User:Ejls]] <sup>[[User_talk:Ejls|talk]]</sup><br />
*[[User:Ejls/Vim]] <sup>[[User_talk:Ejls/Vim|talk]]</sup><br />
*[[User:Ejls/GSoC 2012/Questionnaire]] <sup>[[User_talk:Ejls/GSoC 2012/Questionnaire|talk]]</sup><br />
*[[User:Ejls/GSoC 2012/Whiteboard Backend Refactoring]] <sup>[[User_talk:Ejls/GSoC 2012/Whiteboard Backend Refactoring|talk]]</sup></div>Ejlshttps://wiki.wesnoth.org/index.php?title=User:Ejls/Vim&diff=45822User:Ejls/Vim2012-03-25T20:25:56Z<p>Ejls: Setting up my userspace.</p>
<hr />
<div>I wrote a very basic WML syntax highlighter for Vim: [http://forums.wesnoth.org/viewtopic.php?f=21&t=36248 forum post] (including syntax file).<br />
<br />
==Future==<br />
What is needed now:<br />
*More error detection.<br />
*Better support of Formula.<br />
*Matching of tags to support folding.<br />
*Merging with the current Lua 5.2 syntax.<br />
*Documentation, Vimball.<br />
<br />
It would be great to convert/use a WML schema file in a plugin to detect standard keys in a tag. However the schema project need some more work first.<br />
<br />
If you have any remark, you can drop me a line on the forum or on the [[{{TALKPAGENAME}}|talk page]].<br />
<br />
==Screeshots==<br />
{| style="border-collapse:collapse;"<br />
|- style="border-bottom:2px dashed #AAA;"<br />
|style="padding:15px;"|http://forums.wesnoth.org/download/file.php?id=55624#.png<br />
|- style="border-bottom:2px dashed #AAA;"<br />
|style="padding:15px;"|http://forums.wesnoth.org/download/file.php?id=55625#.png<br />
|- style="border-bottom:2px dashed #AAA;"<br />
|style="padding:15px;"|http://forums.wesnoth.org/download/file.php?id=55626#.png<br />
|- <br />
|style="padding:15px;"|http://forums.wesnoth.org/download/file.php?id=55627#.png<br />
|}</div>Ejlshttps://wiki.wesnoth.org/index.php?title=Soc2012_Teugon_Refactor_Recruitment_Algorithm&diff=45795Soc2012 Teugon Refactor Recruitment Algorithm2012-03-24T02:12:32Z<p>Ejls: done</p>
<hr />
<div>{{SoC2012Student}}<br />
[[Category:SoC_Ideas_AI_Recruitment_2012]]<br />
=Description=<br />
<h4>Paolo De Luca - Refactoring recruitment algorithm</h4><br />
<p> Refactoring recruitment algorithm as stated in the proposed ideas. I think those points are quite enough yet. However I would consider to detail what I've intended for "recruit units that are more useful" for I suppose it's highly connected with the rest of AI playstyle. Different behaviour based on<br />
<ul> <br />
<li> current map;<br />
</li><li> AI mission objetives: chase, retire, kill specific units;<br />
</li><li> initial Time of Day;<br />
</li><li> distance from enemy;<br />
</li><li> allies (which will repeat the above points if it's an AI);<br />
</li><li> current and future gamestyle ( aggressive/defensive) MUST include the fact that AI have to switch between them;<br />
</li></ul><br />
</p><br />
=Additional Details=<br />
<p> I know there are lots of maps where the player have to work with AI allies.<br />
As gamer I've seen the major times I have to play with AI allies, I can achieve victory only If I can protect it from it's own mistakes.<br />
What I say applies to all games, this applies to Wesnoth in particular since campaigns often involve players to deal with AI allies.<br />
Summing Up IMHO players should be able to ask modify allies AI behaviour without directly controll them.<br />
This is kind OT kind not for it touch trasversally the whole AI behaviour.<br />
</p><br />
=IRC=<br />
Teugon<br />
<br />
=Questionnaire=<br />
<p>1) Basics<br />
</p><p>1.1) Write a small introduction to yourself.<br />
</p><p>I'm Paolo De Luca, 21 years old Computer Science student.<br />
</p><p>1.2) State your preferred email address.<br />
</p><p>teugon@gmail.com<br />
</p><p>1.3) If you have chosen a nick for IRC and Wesnoth forums, what is it?<br />
</p><p><br />
<ul> <br />
<li> IRC = "Teugon";<br />
</li><li> forum = "Teugon";<br />
</li></ul><br />
</p><p>1.4) Why do you want to participate in summer of code?<br />
</p><br />
<ul><li>I want to gain as much professional experience as possible and this sounds like a good opportunity <br />
</li><li>I'm really annoied by my university approach to teaching. In Italy it always about theory less about pratic, real world stuff not even to think of..<br />
</li><li>I very interested in the whole game making life-cycle.<br />
</li><li>frankly talking: I think working within GSOC can worth something inside my Curriculum.<br />
</li></ul><br />
<p>1.5) What are you studying, subject, level and school?<br />
</p><p>I'm currently in my third year of Computer Science studies at Alma Mater Studiorum (Bologna)<br />
</p><p>1.6) What country are you from, at what time are you most likely to be able to join IRC?<br />
</p><p>I'm from Italy and I'm actully living here soI should be able to join IRC from 10:00 AM to 00:00 AM GMT. I usually get up late for I go to sleep late.<br />
</p><p>1.7) Do you have other commitments for the summer period&nbsp;? Do you plan to take any vacations&nbsp;? If yes, when.<br />
</p><p> I've not planned nor I'm gonna plan some any vacations but some break time to meet friends could be taken probably during weekend.<br />
however since I would like to graduate as soon as possible. My SURE Summer period is only august(from monday to sunday) month, for I could required all July.<br />
June is full. Semptember should be soso one since I could lessons/"unfortunate exams" or thesis could take it's time there. <br />
</p><p>2) Experience<br />
2.1) What programs/software have you worked on before?<br />
</p><p>I have experience programming with C, scheme, Objective-C (iOS), javascript, java.<br />
these languages I've dealt with<br />
</p><br />
<pre><br />
* -- Objective-C -- A mobile Application iOS 4+ complaint ( Actually under development)<br />
* -- javascript -- Programming exercises<br />
* -- javascript -- client's side ( for a server federation project)<br />
* -- Scheme -- Programming execises (for the programming course)<br />
* -- java -- Healthcare Management ( Actually under development, for Software Engeneering project)<br />
* -- C -- The AmyKaya OS project ( not the whole one) <br />
* -- C -- A proxy mhttp complain mhttp ( for a networking project) <br />
* -- C -- changed a part of the UI of XCModel software ( working with the xtools library)<br />
* -- C -- Programming exercises in Linux.<br />
<br />
<br />
</pre><br />
Others languages I know are Python and Lua BUT I've never used them in any kind of complex work. I could mention Pascal too but imo I would nothing with it.<br />
<p>2.2) Have you developed software in a team environment before? (As opposed to hacking on something on your own)<br />
I have worked/am working in small groups of ( 3/4) on all my projects, so I think to know..<br />
</p><p>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?<br />
</p><p>I haven't participated in gsoc yet.<br />
</p><p>2.4) Are you already involved with any open source development projects? If yes, please describe the project and the scope of your involvement.<br />
</p><p>I'm not involved yet.<br />
</p><p>2.5) Gaming experience - Are you a gamer?<br />
</p><p>Who is not? :D <br />
</p><p>2.5.1) What type of gamer are you?<br />
</p><p>It depends on the kind of games and on the kind of oppenenets: against players I'll experiment different strategies <br />
(all based on the attack first tactic), against AI I'm usually using a full defense till I'm able to defeat him in one full blow attack, when possible. <br />
</p><p>2.5.2) What type of games?<br />
</p><p>Mostly RPGs and Strategies. The only kind I can't play are horror ones if the have enough graphics/sounds gameplay to be realistic.<br />
</p><p>2.5.3) What type of opponents do you prefer?<br />
</p><p>I usually like AI for players tend to be arrongant, selfish, lazy and, above all, rude. This is true both for experienced and newbies one.<br />
Indeed I've experienced these defects too, all of them. But very few person comes back to say: "hey, I'm sorry for before, I had a bad day. Can I repair/help somehow."<br />
or even the simple "I'm sorry, I was wrong".<br />
but the next point holds the another motivation.<br />
</p><p>2.5.4) Are you more interested in story or gameplay?<br />
</p><p>I really like both of them. Stories for when well made they are a pleasure to learn but also a world to meet.<br />
Gameplay for I would end up making games as a work or at least have the chance to make a game the way I want it. <br />
</p><p>2.5.5) Have you played Wesnoth? If so, tell us roughly for how long and whether you lean towards single player or multiplayer.<br />
</p><p>I've done only 1 match 1vs1 against a human player and.. he smashed me, maybe I'll try again after collecting expertise however I've ended all the 2.8 standard campaign and also some others one. <br />
</p><p>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.<br />
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.<br />
</p><p>3) Communication skills<br />
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.<br />
As Computer Science student I'm used to read mostly english books, so I could say I'm good enough to read tecnical book, tutorial, guides, & Co. in English.<br />
problems I could have are about words I do not know yet. p.e heavy descriptions books like novels however. <br />
Even if so, I'm usually able to understand their meaning by the context or with a motherlanguage vocabulary. <br />
Listenting is ok if the other one is talking clearly not fast and there is not so much noise <br />
(I do not understand most of railway station announce or pharmaceutical spots even in my own language so I guess the problem isn't myself).<br />
Speaking could be a problem. But I've been in other countries (I would mention I was at FOSDEM's game-dev this year) and it seems to be good enough<br />
<br />
</p><p>3.2) What spoken languages are you fluent in?<br />
</p><p>just English. <br />
</p><p>3.3) Are you good at interacting with other players? Our developer community is friendly, but the player community can be a bit rough.<br />
</p><p>I can be both unsocialable, or everyones buddy. I just fear Arrogant peers: they can't be helped. They are always right.<br />
</p><p>3.4) Do you give constructive advice?<br />
</p><p>I always try to document myself when giving advices. I do not advice for something I do not know enough.<br />
</p><p>3.5) Do you receive advice well?<br />
</p><p>sometimes, but mostly they are useless criticism or completely out of topic.<br />
</p><p>3.6) Are you good at sorting useful criticisms from useless ones?<br />
</p><p>I think I am.<br />
</p><p>3.7) How autonomous are you when developing&nbsp;? 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<br />
</p><p> Each developing approch isn't always good: You always have to choose and it's always a tradeof. this is like I would act in this case:<br />
<ul><li>1. document myself till I know which is the code to refactor. What depends on it.<br />
</li><li>2. Which are the implicit assumption ( usually there always something not written) in that code.<br />
</li><li>3. State an implementation of the algorithm. I need players here, badly too.<br />
</li><li>4. What said above till now needs to get documented if it isn't done. Now experimenting can take place. test for new features will be written.<br />
</li><li>5. At this point I should be friendly enough to start the surgery.<br />
</li><li>6. test & play.<br />
</li><li>7. bugfix.<br />
</li><li>8. if ( !deployable) goto 3.<br />
</li></ul><br />
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?<br />
</p><p>I've choose Refactor recuitment algorithm. <br />
</p><p>4.2) If you have invented your own project, please describe the project and the scope.<br />
</p><p>I haven't<br />
</p><p>4.3) Why did you choose this project?<br />
</p><p>I preafear the total AI defense stuff for I feel like it's easier but I've been slow.<br />
However I like AI related stuff, so what's the matter! <br />
Preference is based on time: I prefear start and complete something rather than leave it up for someone else.<br />
</p><p>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".<br />
</p><p> Based on what I said in point 3.7. It would be like this:<br />
<ul><li> 1. --- about [1 week + 2 days (buffer time)] --- highly variable, based on the existing documentation.<br />
</li><li> 2. --- [1 day + 1 day (buffer time)] code should be known here.<br />
</li><li> 3. --- [1 day + 0 (no buffer time)] presentation and discussion with players must be booked on point 1. and yet have been accomplished.<br />
</li><li> 4. --- [1 week + 2 days (buffer time)] this phase is high risk documentation is needed as roadmap to me and as explaination to future developers. tests will drive the implementation.<br />
</li><li> 5. --- [3 days + 2 days (buffer time)] if you know what to do you're fast<br />
</li><li> 6. --- [1 day + 0 (no buffer time)] harvesting bug<br />
</li><li> 7. --- [1 week] fixes can be hard, since it's my code I'm expecting half week.<br />
</li><li> 8. --- [???] I'm sure I won't make a one time injection of features for I'm thinking to use Extreme Programming.<br />
Anyhow I can not state how much iteration. I also have the minus of the Language which I don't know and this could add the need of more time.<br />
I'm not scared about the language for every project I've been asked for in my university espected me to know the language yet. Obviously I did not but I'd be lying telling it is not a problem. <br />
</li></ul><br />
</p><p>4.5) Include as much technical detail about your implementation as you can<br />
</p><p>I do not know the actual implementation at all neither I know the C++ language, however I can try to summ up something with design pattern in the GSOC application<br />
</p><p>4.6) What do you expect to gain from this project?<br />
</p><p>Knowledge, good expertise with C++ , and maybe some friend.<br />
</p><p>4.7) What would make you stay in the Wesnoth community after the conclusion of SOC?<br />
</p><p>I'd like to support like a Graphic Artist but I do not actually own any skill which is need. I just know Inkscape and just a few things abouts GIMP,<br />
worse of all no drawing skill background. When I'll be able I'll close the topic "Hints for a newcomer in artworking" which has been open by me some month ago.<br />
</p><p>5) Practical considerations<br />
5.1) Are you familiar with any of the following tools or languages?<br />
</p><p>Subversion (used for all commits)<br />
</p><p>Never used any versioning system yet on my projects.<br />
I've started experimenting git 1 month ago but I decided to stop.<br />
</p><p>C++ (language used for all the normal source code)<br />
</p><p>No, but I know the OOP. I'm planning to learn C++ during April. <br />
</p><p>STL, Boost, Sdl (C++ libraries used by Wesnoth)<br />
</p><p>I've only heard about the Sdl. For the XCModel UI I've used a department library based on Xlib libraries. <br />
</p><p>Python (optional, mainly used for tools)<br />
</p><p>I know the language but never actually used.<br />
</p><p>build environments (eg cmake/scons)<br />
</p><p>No. I've used automake and autoconfig once but usually I've settled out makefiles manually. <br />
</p><p>WML (the wesnoth specific scenario language)<br />
</p><p>No<br />
</p><p>Lua (used in combination with WML to create scenarios)<br />
</p><p>I know the language, and I've read a book on it, but never actually used. AFAIK it's just a loose C.<br />
</p><p>5.2) Which tools do you normally use for development? Why do you use them?<br />
</p><p>I prefear gedit, or geany. Actually I'm using eclipse for the Software Engeneering project.<br />
I've used geany on the early stage when I had no or insufficient programming experience. After that I moved to gedit. It just follow the KISS principle.<br />
Someone says use eclipse it's professional, it's full of feature etc.. Ok but I did not need 'em always. Moreover Eclipse it's heavy and it's width it's full of feature,<br />
It would drain much more resource than I need for nothing, also I'm used to have whole screen width with code and few icons.<br />
So, just use the right tool for your task.<br />
I'm starting to use Eclipse for it's a non.said constrain of our project however it's said to be the best tool for coding with Java.<br />
Actually I've used a bit Aptana but just for javascript exercises.<br />
</p><p>5.3) What programming languages are you fluent in?<br />
</p><p> I'm strong on C.<br />
</p><p>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!<br />
</p><p>No problem with phone but I prefear skype. It's free. About phone's contact I'd like to email my mentor with it.<br />
</p><p>------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------<br />
there are something I would like to say something by myself.<br />
<ul><li> the following link will let you download the whole part I had to make for the networking project to work, there should be both english and italian<br />
comments around there, however what I'm shipping it for is to you my way to organize/write code. I remember you it's about C language.<br />
LINK: http://db.tt/RZj4P7cf<br />
All the material inside the test/ directory is not mine.<br />
</li><li> I'll try to be on IRC during weekends from now on. Non-weekend time I can't assure anything.<br />
</li><li> If you think there is something I should start learning for this project, I'm all ears up.<br />
</li></ul><br />
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------<br />
</p></div>Ejlshttps://wiki.wesnoth.org/index.php?title=Soc2012_Teugon_Refactor_Recruitment_Algorithm&diff=45794Soc2012 Teugon Refactor Recruitment Algorithm2012-03-24T02:10:44Z<p>Ejls: a bit more</p>
<hr />
<div>{{SoC2012Student}}<br />
[[Category:SoC_Ideas_AI_Recruitment_2012]]<br />
=Description=<br />
<h4> <span class="mw-headline"> Paolo De Luca - Refactoring recruitment algorithm </span></h4><br />
<p> Refactoring recruitment algorithm as stated in the proposed ideas. I think those points are quite enough yet. However I would consider to detail what I've intended for "recruit units that are more useful" for I suppose it's highly connected with the rest of AI playstyle. Different behaviour based on<br />
<ul> <br />
<li> current map;<br />
</li><li> AI mission objetives: chase, retire, kill specific units;<br />
</li><li> initial Time of Day;<br />
</li><li> distance from enemy;<br />
</li><li> allies (which will repeat the above points if it's an AI);<br />
</li><li> current and future gamestyle ( aggressive/defensive) MUST include the fact that AI have to switch between them;<br />
</li></ul><br />
</p><br />
<h1> <span class="mw-headline">Additional Details</span></h1><br />
<p> I know there are lots of maps where the player have to work with AI allies.<br />
As gamer I've seen the major times I have to play with AI allies, I can achieve victory only If I can protect it from it's own mistakes.<br />
What I say applies to all games, this applies to Wesnoth in particular since campaigns often involve players to deal with AI allies.<br />
Summing Up IMHO players should be able to ask modify allies AI behaviour without directly controll them.<br />
This is kind OT kind not for it touch trasversally the whole AI behaviour.<br />
</p><br />
=IRC=<br />
Teugon<br />
<br />
=Questionnaire=<br />
<p>1) Basics<br />
</p><p>1.1) Write a small introduction to yourself.<br />
</p><p>I'm Paolo De Luca, 21 years old Computer Science student.<br />
</p><p>1.2) State your preferred email address.<br />
</p><p>teugon@gmail.com<br />
</p><p>1.3) If you have chosen a nick for IRC and Wesnoth forums, what is it?<br />
</p><p><br />
<ul> <br />
<li> IRC = "Teugon";<br />
</li><li> forum = "Teugon";<br />
</li></ul><br />
</p><p>1.4) Why do you want to participate in summer of code?<br />
</p><br />
<ul><li>I want to gain as much professional experience as possible and this sounds like a good opportunity <br />
</li><li>I'm really annoied by my university approach to teaching. In Italy it always about theory less about pratic, real world stuff not even to think of..<br />
</li><li>I very interested in the whole game making life-cycle.<br />
</li><li>frankly talking: I think working within GSOC can worth something inside my Curriculum.<br />
</li></ul><br />
<p>1.5) What are you studying, subject, level and school?<br />
</p><p>I'm currently in my third year of Computer Science studies at Alma Mater Studiorum (Bologna)<br />
</p><p>1.6) What country are you from, at what time are you most likely to be able to join IRC?<br />
</p><p>I'm from Italy and I'm actully living here soI should be able to join IRC from 10:00 AM to 00:00 AM GMT. I usually get up late for I go to sleep late.<br />
</p><p>1.7) Do you have other commitments for the summer period&nbsp;? Do you plan to take any vacations&nbsp;? If yes, when.<br />
</p><p> I've not planned nor I'm gonna plan some any vacations but some break time to meet friends could be taken probably during weekend.<br />
however since I would like to graduate as soon as possible. My SURE Summer period is only august(from monday to sunday) month, for I could required all July.<br />
June is full. Semptember should be soso one since I could lessons/"unfortunate exams" or thesis could take it's time there. <br />
</p><p>2) Experience<br />
2.1) What programs/software have you worked on before?<br />
</p><p>I have experience programming with C, scheme, Objective-C (iOS), javascript, java.<br />
these languages I've dealt with<br />
</p><br />
<pre><br />
* -- Objective-C -- A mobile Application iOS 4+ complaint ( Actually under development)<br />
* -- javascript -- Programming exercises<br />
* -- javascript -- client's side ( for a server federation project)<br />
* -- Scheme -- Programming execises (for the programming course)<br />
* -- java -- Healthcare Management ( Actually under development, for Software Engeneering project)<br />
* -- C -- The AmyKaya OS project ( not the whole one) <br />
* -- C -- A proxy mhttp complain mhttp ( for a networking project) <br />
* -- C -- changed a part of the UI of XCModel software ( working with the xtools library)<br />
* -- C -- Programming exercises in Linux.<br />
<br />
<br />
</pre><br />
Others languages I know are Python and Lua BUT I've never used them in any kind of complex work. I could mention Pascal too but imo I would nothing with it.<br />
<p>2.2) Have you developed software in a team environment before? (As opposed to hacking on something on your own)<br />
I have worked/am working in small groups of ( 3/4) on all my projects, so I think to know..<br />
</p><p>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?<br />
</p><p>I haven't participated in gsoc yet.<br />
</p><p>2.4) Are you already involved with any open source development projects? If yes, please describe the project and the scope of your involvement.<br />
</p><p>I'm not involved yet.<br />
</p><p>2.5) Gaming experience - Are you a gamer?<br />
</p><p>Who is not? :D <br />
</p><p>2.5.1) What type of gamer are you?<br />
</p><p>It depends on the kind of games and on the kind of oppenenets: against players I'll experiment different strategies <br />
(all based on the attack first tactic), against AI I'm usually using a full defense till I'm able to defeat him in one full blow attack, when possible. <br />
</p><p>2.5.2) What type of games?<br />
</p><p>Mostly RPGs and Strategies. The only kind I can't play are horror ones if the have enough graphics/sounds gameplay to be realistic.<br />
</p><p>2.5.3) What type of opponents do you prefer?<br />
</p><p>I usually like AI for players tend to be arrongant, selfish, lazy and, above all, rude. This is true both for experienced and newbies one.<br />
Indeed I've experienced these defects too, all of them. But very few person comes back to say: "hey, I'm sorry for before, I had a bad day. Can I repair/help somehow."<br />
or even the simple "I'm sorry, I was wrong".<br />
but the next point holds the another motivation.<br />
</p><p>2.5.4) Are you more interested in story or gameplay?<br />
</p><p>I really like both of them. Stories for when well made they are a pleasure to learn but also a world to meet.<br />
Gameplay for I would end up making games as a work or at least have the chance to make a game the way I want it. <br />
</p><p>2.5.5) Have you played Wesnoth? If so, tell us roughly for how long and whether you lean towards single player or multiplayer.<br />
</p><p>I've done only 1 match 1vs1 against a human player and.. he smashed me, maybe I'll try again after collecting expertise however I've ended all the 2.8 standard campaign and also some others one. <br />
</p><p>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.<br />
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.<br />
</p><p>3) Communication skills<br />
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.<br />
As Computer Science student I'm used to read mostly english books, so I could say I'm good enough to read tecnical book, tutorial, guides, & Co. in English.<br />
problems I could have are about words I do not know yet. p.e heavy descriptions books like novels however. <br />
Even if so, I'm usually able to understand their meaning by the context or with a motherlanguage vocabulary. <br />
Listenting is ok if the other one is talking clearly not fast and there is not so much noise <br />
(I do not understand most of railway station announce or pharmaceutical spots even in my own language so I guess the problem isn't myself).<br />
Speaking could be a problem. But I've been in other countries (I would mention I was at FOSDEM's game-dev this year) and it seems to be good enough<br />
<br />
</p><p>3.2) What spoken languages are you fluent in?<br />
</p><p>just English. <br />
</p><p>3.3) Are you good at interacting with other players? Our developer community is friendly, but the player community can be a bit rough.<br />
</p><p>I can be both unsocialable, or everyones buddy. I just fear Arrogant peers: they can't be helped. They are always right.<br />
</p><p>3.4) Do you give constructive advice?<br />
</p><p>I always try to document myself when giving advices. I do not advice for something I do not know enough.<br />
</p><p>3.5) Do you receive advice well?<br />
</p><p>sometimes, but mostly they are useless criticism or completely out of topic.<br />
</p><p>3.6) Are you good at sorting useful criticisms from useless ones?<br />
</p><p>I think I am.<br />
</p><p>3.7) How autonomous are you when developing&nbsp;? 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<br />
</p><p> Each developing approch isn't always good: You always have to choose and it's always a tradeof. this is like I would act in this case:<br />
<ul><li>1. document myself till I know which is the code to refactor. What depends on it.<br />
</li><li>2. Which are the implicit assumption ( usually there always something not written) in that code.<br />
</li><li>3. State an implementation of the algorithm. I need players here, badly too.<br />
</li><li>4. What said above till now needs to get documented if it isn't done. Now experimenting can take place. test for new features will be written.<br />
</li><li>5. At this point I should be friendly enough to start the surgery.<br />
</li><li>6. test & play.<br />
</li><li>7. bugfix.<br />
</li><li>8. if ( !deployable) goto 3.<br />
</li></ul><br />
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?<br />
</p><p>I've choose Refactor recuitment algorithm. <br />
</p><p>4.2) If you have invented your own project, please describe the project and the scope.<br />
</p><p>I haven't<br />
</p><p>4.3) Why did you choose this project?<br />
</p><p>I preafear the total AI defense stuff for I feel like it's easier but I've been slow.<br />
However I like AI related stuff, so what's the matter! <br />
Preference is based on time: I prefear start and complete something rather than leave it up for someone else.<br />
</p><p>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".<br />
</p><p> Based on what I said in point 3.7. It would be like this:<br />
<ul><li> 1. --- about [1 week + 2 days (buffer time)] --- highly variable, based on the existing documentation.<br />
</li><li> 2. --- [1 day + 1 day (buffer time)] code should be known here.<br />
</li><li> 3. --- [1 day + 0 (no buffer time)] presentation and discussion with players must be booked on point 1. and yet have been accomplished.<br />
</li><li> 4. --- [1 week + 2 days (buffer time)] this phase is high risk documentation is needed as roadmap to me and as explaination to future developers. tests will drive the implementation.<br />
</li><li> 5. --- [3 days + 2 days (buffer time)] if you know what to do you're fast<br />
</li><li> 6. --- [1 day + 0 (no buffer time)] harvesting bug<br />
</li><li> 7. --- [1 week] fixes can be hard, since it's my code I'm expecting half week.<br />
</li><li> 8. --- [???] I'm sure I won't make a one time injection of features for I'm thinking to use Extreme Programming.<br />
Anyhow I can not state how much iteration. I also have the minus of the Language which I don't know and this could add the need of more time.<br />
I'm not scared about the language for every project I've been asked for in my university espected me to know the language yet. Obviously I did not but I'd be lying telling it is not a problem. <br />
</li></ul><br />
</p><p>4.5) Include as much technical detail about your implementation as you can<br />
</p><p>I do not know the actual implementation at all neither I know the C++ language, however I can try to summ up something with design pattern in the GSOC application<br />
</p><p>4.6) What do you expect to gain from this project?<br />
</p><p>Knowledge, good expertise with C++ , and maybe some friend.<br />
</p><p>4.7) What would make you stay in the Wesnoth community after the conclusion of SOC?<br />
</p><p>I'd like to support like a Graphic Artist but I do not actually own any skill which is need. I just know Inkscape and just a few things abouts GIMP,<br />
worse of all no drawing skill background. When I'll be able I'll close the topic "Hints for a newcomer in artworking" which has been open by me some month ago.<br />
</p><p>5) Practical considerations<br />
5.1) Are you familiar with any of the following tools or languages?<br />
</p><p>Subversion (used for all commits)<br />
</p><p>Never used any versioning system yet on my projects.<br />
I've started experimenting git 1 month ago but I decided to stop.<br />
</p><p>C++ (language used for all the normal source code)<br />
</p><p>No, but I know the OOP. I'm planning to learn C++ during April. <br />
</p><p>STL, Boost, Sdl (C++ libraries used by Wesnoth)<br />
</p><p>I've only heard about the Sdl. For the XCModel UI I've used a department library based on Xlib libraries. <br />
</p><p>Python (optional, mainly used for tools)<br />
</p><p>I know the language but never actually used.<br />
</p><p>build environments (eg cmake/scons)<br />
</p><p>No. I've used automake and autoconfig once but usually I've settled out makefiles manually. <br />
</p><p>WML (the wesnoth specific scenario language)<br />
</p><p>No<br />
</p><p>Lua (used in combination with WML to create scenarios)<br />
</p><p>I know the language, and I've read a book on it, but never actually used. AFAIK it's just a loose C.<br />
</p><p>5.2) Which tools do you normally use for development? Why do you use them?<br />
</p><p>I prefear gedit, or geany. Actually I'm using eclipse for the Software Engeneering project.<br />
I've used geany on the early stage when I had no or insufficient programming experience. After that I moved to gedit. It just follow the KISS principle.<br />
Someone says use eclipse it's professional, it's full of feature etc.. Ok but I did not need 'em always. Moreover Eclipse it's heavy and it's width it's full of feature,<br />
It would drain much more resource than I need for nothing, also I'm used to have whole screen width with code and few icons.<br />
So, just use the right tool for your task.<br />
I'm starting to use Eclipse for it's a non.said constrain of our project however it's said to be the best tool for coding with Java.<br />
Actually I've used a bit Aptana but just for javascript exercises.<br />
</p><p>5.3) What programming languages are you fluent in?<br />
</p><p> I'm strong on C.<br />
</p><p>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!<br />
</p><p>No problem with phone but I prefear skype. It's free. About phone's contact I'd like to email my mentor with it.<br />
</p><p>------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------<br />
there are something I would like to say something by myself.<br />
<ul><li> the following link will let you download the whole part I had to make for the networking project to work, there should be both english and italian<br />
comments around there, however what I'm shipping it for is to you my way to organize/write code. I remember you it's about C language.<br />
LINK: http://db.tt/RZj4P7cf<br />
All the material inside the test/ directory is not mine.<br />
</li><li> I'll try to be on IRC during weekends from now on. Non-weekend time I can't assure anything.<br />
</li><li> If you think there is something I should start learning for this project, I'm all ears up.<br />
</li></ul><br />
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------<br />
</p></div>Ejlshttps://wiki.wesnoth.org/index.php?title=Soc2012_Teugon_Refactor_Recruitment_Algorithm&diff=45793Soc2012 Teugon Refactor Recruitment Algorithm2012-03-24T02:06:31Z<p>Ejls: a bit of wikifaction.</p>
<hr />
<div>{{SoC2012Student}}<br />
[[Category:SoC_Ideas_AI_Recruitment_2012]]<br />
=Description=<br />
<h4> <span class="mw-headline"> Paolo De Luca - Refactoring recruitment algorithm </span></h4><br />
<p> Refactoring recruitment algorithm as stated in the proposed ideas. I think those points are quite enough yet. However I would consider to detail what I've intended for "recruit units that are more useful" for I suppose it's highly connected with the rest of AI playstyle. Different behaviour based on<br />
<ul> <br />
<li> current map;<br />
</li><li> AI mission objetives: chase, retire, kill specific units;<br />
</li><li> initial Time of Day;<br />
</li><li> distance from enemy;<br />
</li><li> allies (which will repeat the above points if it's an AI);<br />
</li><li> current and future gamestyle ( aggressive/defensive) MUST include the fact that AI have to switch between them;<br />
</li></ul><br />
</p><br />
<h1> <span class="mw-headline">Additional Details</span></h1><br />
<p> I know there are lots of maps where the player have to work with AI allies.<br />
As gamer I've seen the major times I have to play with AI allies, I can achieve victory only If I can protect it from it's own mistakes.<br />
What I say applies to all games, this applies to Wesnoth in particular since campaigns often involve players to deal with AI allies.<br />
Summing Up IMHO players should be able to ask modify allies AI behaviour without directly controll them.<br />
This is kind OT kind not for it touch trasversally the whole AI behaviour.<br />
</p><br />
=IRC=<br />
Teugon<br />
<br />
<h1> <span class="mw-headline">Questionnaire</span></h1><br />
<p>1) Basics<br />
</p><p>1.1) Write a small introduction to yourself.<br />
</p><p>I'm Paolo De Luca, 21 years old Computer Science student.<br />
</p><p>1.2) State your preferred email address.<br />
</p><p>teugon@gmail.com<br />
</p><p>1.3) If you have chosen a nick for IRC and Wesnoth forums, what is it?<br />
</p><p><br />
<ul> <br />
<li> IRC = "Teugon";<br />
</li><li> forum = "Teugon";<br />
</li></ul><br />
</p><p>1.4) Why do you want to participate in summer of code?<br />
</p><br />
<ul><li>I want to gain as much professional experience as possible and this sounds like a good opportunity <br />
</li><li>I'm really annoied by my university approach to teaching. In Italy it always about theory less about pratic, real world stuff not even to think of..<br />
</li><li>I very interested in the whole game making life-cycle.<br />
</li><li>frankly talking: I think working within GSOC can worth something inside my Curriculum.<br />
</li></ul><br />
<p>1.5) What are you studying, subject, level and school?<br />
</p><p>I'm currently in my third year of Computer Science studies at Alma Mater Studiorum (Bologna)<br />
</p><p>1.6) What country are you from, at what time are you most likely to be able to join IRC?<br />
</p><p>I'm from Italy and I'm actully living here soI should be able to join IRC from 10:00 AM to 00:00 AM GMT. I usually get up late for I go to sleep late.<br />
</p><p>1.7) Do you have other commitments for the summer period&nbsp;? Do you plan to take any vacations&nbsp;? If yes, when.<br />
</p><p> I've not planned nor I'm gonna plan some any vacations but some break time to meet friends could be taken probably during weekend.<br />
however since I would like to graduate as soon as possible. My SURE Summer period is only august(from monday to sunday) month, for I could required all July.<br />
June is full. Semptember should be soso one since I could lessons/"unfortunate exams" or thesis could take it's time there. <br />
</p><p>2) Experience<br />
2.1) What programs/software have you worked on before?<br />
</p><p>I have experience programming with C, scheme, Objective-C (iOS), javascript, java.<br />
these languages I've dealt with<br />
</p><br />
<pre><br />
* -- Objective-C -- A mobile Application iOS 4+ complaint ( Actually under development)<br />
* -- javascript -- Programming exercises<br />
* -- javascript -- client's side ( for a server federation project)<br />
* -- Scheme -- Programming execises (for the programming course)<br />
* -- java -- Healthcare Management ( Actually under development, for Software Engeneering project)<br />
* -- C -- The AmyKaya OS project ( not the whole one) <br />
* -- C -- A proxy mhttp complain mhttp ( for a networking project) <br />
* -- C -- changed a part of the UI of XCModel software ( working with the xtools library)<br />
* -- C -- Programming exercises in Linux.<br />
<br />
<br />
</pre><br />
Others languages I know are Python and Lua BUT I've never used them in any kind of complex work. I could mention Pascal too but imo I would nothing with it.<br />
<p>2.2) Have you developed software in a team environment before? (As opposed to hacking on something on your own)<br />
I have worked/am working in small groups of ( 3/4) on all my projects, so I think to know..<br />
</p><p>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?<br />
</p><p>I haven't participated in gsoc yet.<br />
</p><p>2.4) Are you already involved with any open source development projects? If yes, please describe the project and the scope of your involvement.<br />
</p><p>I'm not involved yet.<br />
</p><p>2.5) Gaming experience - Are you a gamer?<br />
</p><p>Who is not? :D <br />
</p><p>2.5.1) What type of gamer are you?<br />
</p><p>It depends on the kind of games and on the kind of oppenenets: against players I'll experiment different strategies <br />
(all based on the attack first tactic), against AI I'm usually using a full defense till I'm able to defeat him in one full blow attack, when possible. <br />
</p><p>2.5.2) What type of games?<br />
</p><p>Mostly RPGs and Strategies. The only kind I can't play are horror ones if the have enough graphics/sounds gameplay to be realistic.<br />
</p><p>2.5.3) What type of opponents do you prefer?<br />
</p><p>I usually like AI for players tend to be arrongant, selfish, lazy and, above all, rude. This is true both for experienced and newbies one.<br />
Indeed I've experienced these defects too, all of them. But very few person comes back to say: "hey, I'm sorry for before, I had a bad day. Can I repair/help somehow."<br />
or even the simple "I'm sorry, I was wrong".<br />
but the next point holds the another motivation.<br />
</p><p>2.5.4) Are you more interested in story or gameplay?<br />
</p><p>I really like both of them. Stories for when well made they are a pleasure to learn but also a world to meet.<br />
Gameplay for I would end up making games as a work or at least have the chance to make a game the way I want it. <br />
</p><p>2.5.5) Have you played Wesnoth? If so, tell us roughly for how long and whether you lean towards single player or multiplayer.<br />
</p><p>I've done only 1 match 1vs1 against a human player and.. he smashed me, maybe I'll try again after collecting expertise however I've ended all the 2.8 standard campaign and also some others one. <br />
</p><p>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.<br />
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.<br />
</p><p>3) Communication skills<br />
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.<br />
As Computer Science student I'm used to read mostly english books, so I could say I'm good enough to read tecnical book, tutorial, guides, & Co. in English.<br />
problems I could have are about words I do not know yet. p.e heavy descriptions books like novels however. <br />
Even if so, I'm usually able to understand their meaning by the context or with a motherlanguage vocabulary. <br />
Listenting is ok if the other one is talking clearly not fast and there is not so much noise <br />
(I do not understand most of railway station announce or pharmaceutical spots even in my own language so I guess the problem isn't myself).<br />
Speaking could be a problem. But I've been in other countries (I would mention I was at FOSDEM's game-dev this year) and it seems to be good enough<br />
<br />
</p><p>3.2) What spoken languages are you fluent in?<br />
</p><p>just English. <br />
</p><p>3.3) Are you good at interacting with other players? Our developer community is friendly, but the player community can be a bit rough.<br />
</p><p>I can be both unsocialable, or everyones buddy. I just fear Arrogant peers: they can't be helped. They are always right.<br />
</p><p>3.4) Do you give constructive advice?<br />
</p><p>I always try to document myself when giving advices. I do not advice for something I do not know enough.<br />
</p><p>3.5) Do you receive advice well?<br />
</p><p>sometimes, but mostly they are useless criticism or completely out of topic.<br />
</p><p>3.6) Are you good at sorting useful criticisms from useless ones?<br />
</p><p>I think I am.<br />
</p><p>3.7) How autonomous are you when developing&nbsp;? 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<br />
</p><p> Each developing approch isn't always good: You always have to choose and it's always a tradeof. this is like I would act in this case:<br />
<ul><li>1. document myself till I know which is the code to refactor. What depends on it.<br />
</li><li>2. Which are the implicit assumption ( usually there always something not written) in that code.<br />
</li><li>3. State an implementation of the algorithm. I need players here, badly too.<br />
</li><li>4. What said above till now needs to get documented if it isn't done. Now experimenting can take place. test for new features will be written.<br />
</li><li>5. At this point I should be friendly enough to start the surgery.<br />
</li><li>6. test & play.<br />
</li><li>7. bugfix.<br />
</li><li>8. if ( !deployable) goto 3.<br />
</li></ul><br />
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?<br />
</p><p>I've choose Refactor recuitment algorithm. <br />
</p><p>4.2) If you have invented your own project, please describe the project and the scope.<br />
</p><p>I haven't<br />
</p><p>4.3) Why did you choose this project?<br />
</p><p>I preafear the total AI defense stuff for I feel like it's easier but I've been slow.<br />
However I like AI related stuff, so what's the matter! <br />
Preference is based on time: I prefear start and complete something rather than leave it up for someone else.<br />
</p><p>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".<br />
</p><p> Based on what I said in point 3.7. It would be like this:<br />
<ul><li> 1. --- about [1 week + 2 days (buffer time)] --- highly variable, based on the existing documentation.<br />
</li><li> 2. --- [1 day + 1 day (buffer time)] code should be known here.<br />
</li><li> 3. --- [1 day + 0 (no buffer time)] presentation and discussion with players must be booked on point 1. and yet have been accomplished.<br />
</li><li> 4. --- [1 week + 2 days (buffer time)] this phase is high risk documentation is needed as roadmap to me and as explaination to future developers. tests will drive the implementation.<br />
</li><li> 5. --- [3 days + 2 days (buffer time)] if you know what to do you're fast<br />
</li><li> 6. --- [1 day + 0 (no buffer time)] harvesting bug<br />
</li><li> 7. --- [1 week] fixes can be hard, since it's my code I'm expecting half week.<br />
</li><li> 8. --- [???] I'm sure I won't make a one time injection of features for I'm thinking to use Extreme Programming.<br />
Anyhow I can not state how much iteration. I also have the minus of the Language which I don't know and this could add the need of more time.<br />
I'm not scared about the language for every project I've been asked for in my university espected me to know the language yet. Obviously I did not but I'd be lying telling it is not a problem. <br />
</li></ul><br />
</p><p>4.5) Include as much technical detail about your implementation as you can<br />
</p><p>I do not know the actual implementation at all neither I know the C++ language, however I can try to summ up something with design pattern in the GSOC application<br />
</p><p>4.6) What do you expect to gain from this project?<br />
</p><p>Knowledge, good expertise with C++ , and maybe some friend.<br />
</p><p>4.7) What would make you stay in the Wesnoth community after the conclusion of SOC?<br />
</p><p>I'd like to support like a Graphic Artist but I do not actually own any skill which is need. I just know Inkscape and just a few things abouts GIMP,<br />
worse of all no drawing skill background. When I'll be able I'll close the topic "Hints for a newcomer in artworking" which has been open by me some month ago.<br />
</p><p>5) Practical considerations<br />
5.1) Are you familiar with any of the following tools or languages?<br />
</p><p>Subversion (used for all commits)<br />
</p><p>Never used any versioning system yet on my projects.<br />
I've started experimenting git 1 month ago but I decided to stop.<br />
</p><p>C++ (language used for all the normal source code)<br />
</p><p>No, but I know the OOP. I'm planning to learn C++ during April. <br />
</p><p>STL, Boost, Sdl (C++ libraries used by Wesnoth)<br />
</p><p>I've only heard about the Sdl. For the XCModel UI I've used a department library based on Xlib libraries. <br />
</p><p>Python (optional, mainly used for tools)<br />
</p><p>I know the language but never actually used.<br />
</p><p>build environments (eg cmake/scons)<br />
</p><p>No. I've used automake and autoconfig once but usually I've settled out makefiles manually. <br />
</p><p>WML (the wesnoth specific scenario language)<br />
</p><p>No<br />
</p><p>Lua (used in combination with WML to create scenarios)<br />
</p><p>I know the language, and I've read a book on it, but never actually used. AFAIK it's just a loose C.<br />
</p><p>5.2) Which tools do you normally use for development? Why do you use them?<br />
</p><p>I prefear gedit, or geany. Actually I'm using eclipse for the Software Engeneering project.<br />
I've used geany on the early stage when I had no or insufficient programming experience. After that I moved to gedit. It just follow the KISS principle.<br />
Someone says use eclipse it's professional, it's full of feature etc.. Ok but I did not need 'em always. Moreover Eclipse it's heavy and it's width it's full of feature,<br />
It would drain much more resource than I need for nothing, also I'm used to have whole screen width with code and few icons.<br />
So, just use the right tool for your task.<br />
I'm starting to use Eclipse for it's a non.said constrain of our project however it's said to be the best tool for coding with Java.<br />
Actually I've used a bit Aptana but just for javascript exercises.<br />
</p><p>5.3) What programming languages are you fluent in?<br />
</p><p> I'm strong on C.<br />
</p><p>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!<br />
</p><p>No problem with phone but I prefear skype. It's free. About phone's contact I'd like to email my mentor with it.<br />
</p><p>------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------<br />
there are something I would like to say something by myself.<br />
<ul><li> the following link will let you download the whole part I had to make for the networking project to work, there should be both english and italian<br />
comments around there, however what I'm shipping it for is to you my way to organize/write code. I remember you it's about C language.<br />
LINK: http://db.tt/RZj4P7cf<br />
All the material inside the test/ directory is not mine.<br />
</li><li> I'll try to be on IRC during weekends from now on. Non-weekend time I can't assure anything.<br />
</li><li> If you think there is something I should start learning for this project, I'm all ears up.<br />
</li></ul><br />
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------<br />
</p></div>Ejlshttps://wiki.wesnoth.org/index.php?title=SoC2012_Ivan_Addon_Server&diff=45782SoC2012 Ivan Addon Server2012-03-22T21:24:00Z<p>Ejls: Formating</p>
<hr />
<div>{{SoC2012Student}}<br />
[[Category:SoC Ideas Addon Server 2012]]<br />
<br />
=Description=<br />
<h4>Ivan Savenko - Addon Server</h4><br />
The goal of this project is to write a new add-on server for Wesnoth from scratch.<br />
Original draft in SVN (latex): http://svn.gna.org/viewcvs/wesnoth/trunk/doc/design/<br />
<br />
Will be written in C++, networking part - boost::asio.<br />
<br />
=Server=<br />
===Essential===<br />
* Basic upload\download\update functionality.<br />
* Basic dependencies support for add-ons.<br />
* WML and content validation via external tools.<br />
* Integration with Wescamp (translations only?)<br />
<br />
=== Optional ===<br />
This features that can be added anytime, during or after GSoC.<br />
* Extend dependencies with "Conflicts" and "Recommends".<br />
* Integration with existing user database from forums (similar to multiplayer server).<br />
* Some way to ease bugreporting by players.<br />
* Send add-on icons to client? Currently some add-ons use icons from resource of not-yet-installed add-on. Another option is to handle this as error.<br />
<br />
=IRC=<br />
IvanSav<br />
<br />
=Questionnaire=<br />
== Basics ==<br />
<br />
=== Write a small introduction to yourself. ===<br />
My name is Ivan Savenko, I'm from Ukraine, Chernihiv, really interested in programming and computers in general, I am an avid gamer which makes games development even more interesting for me.<br />
<br />
=== State your preferred email address. ===<br />
Check Google application - I'll post it there<br />
<br />
=== If you have chosen a nick for IRC and Wesnoth forums, what is it? ===<br />
IvanSav on IRC, not registered on forums right now<br />
<br />
=== Why do you want to participate in summer of code? ===<br />
I really love coding and I would like to spend summer on something that will be used in real world in quite big community.<br />
<br />
=== What are you studying, subject, level and school? ===<br />
I study system programming at Chernihiv State Technological University, 4th year of study.<br />
<br />
=== What country are you from, at what time are you most likely to be able to join IRC? ===<br />
I'm from Ukraine (GMT+2), can be on IRC from ~12:00 GMT and till ~24:00 GMT. <br />
<br />
=== Do you have other commitments for the summer period ? ===<br />
I only have exams in May, will be free for all 3 summer months.<br />
<br />
== Experience ==<br />
I've been working on several small apps for fun, one of my goals usually were speed, usage of new features like C++11, trying to implement some complex algorithms (like SDL game that uses only runtime-generated images).<br />
<br />
=== What programs/software have you worked on before? ===<br />
Apart from small university tasks I'm working on VCMI project.<br />
<br />
=== Have you developed software in a team environment before? ===<br />
I think I can say yes. I've been working in team on VCMI but apart from some discussions on forums work is usually separate.<br />
<br />
=== Have you participated to the Google Summer of Code before? ===<br />
Nope. This is first time and most possibly the last time I'm trying to take part in GSoC - will be too busy with graduation next year.<br />
<br />
=== Are you already involved with any open source development projects? If yes, please describe the project and the scope of your involvement. ===<br />
VCMI, open-source engine for Heroes of Might and Magic III. (vcmi.eu)<br />
I've joined this project ~2 years ago. It's quite small project which turned out to be really good way to learn more about C++ after studying it in the university. Apart from some minor stuff I've been working on bringing support for 32-bit graphics in originally 256-colors only game and JSON-based configuration system.<br />
<br />
=== Gaming experience - Are you a gamer? ===<br />
Definitely :)<br />
<br />
==== What type of games? ====<br />
Either strategy games (Heroes of M&M, Civilization) or RPG's (Baldur's Gate, The Elder Scrolls)<br />
<br />
==== What type of opponents do you prefer? ====<br />
I'm playing singleplayer only so I prefer AI. Smart one, if possible.<br />
<br />
==== Are you more interested in story or gameplay? ====<br />
Good story mostly or gameplay where you need to think at least from time to time.<br />
<br />
==== Have you played Wesnoth? If so, tell us roughly for how long and whether you lean towards single player or multiplayer. ====<br />
Can't tell for how long but I've completed all campaigns that were in 1.8. Played single player games only.<br />
<br />
=== If you have contributed any patches to Wesnoth, please list them below. ===<br />
None so far.<br />
<br />
== Communication skills ==<br />
<br />
=== Though most of our developers are not native English speakers, English is the project's working language. Describe your fluency level in written English. ===<br />
Written English is probably good. Have no problems with understanding others and vice versa.<br />
<br />
=== What spoken languages are you fluent in? ===<br />
Russian and Ukrainian. Probably English, but I've never spoke with native English speakers so can't say for sure about this one.<br />
<br />
=== Are you good at interacting with other players? Our developer community is friendly, but the player community can be a bit rough. ===<br />
Shouldn't be a problem. <br />
<br />
=== Do you give constructive advice? ===<br />
So far there were no complains regarding my advices so I think that yes.<br />
<br />
=== Do you receive advice well? ===<br />
If somebody is trying to help me then why should I complain? If he is right I may learn something useful after all.<br />
<br />
=== Are you good at sorting useful criticisms from useless ones? ===<br />
I hope so. <br />
<br />
=== How autonomous are you when developing ? ===<br />
I definitely can code autonomously but I'd rather discuss all points I'm not sure about before working on them. So in general it will be a mix of both. At first - discuss all basics, then make some small proof-of-concept and go back to discussion. It's much more easier for me to explain something with small snippets of code instead of trying to this in words.<br />
<br />
== Project ==<br />
<br />
=== 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? ===<br />
I've took it from the list, Addon server. Considering that this should work as daemon I should foxus on stability and keep it extendable to implement all optional features Wesnoth may need.<br />
<br />
=== Why did you choose this project? ===<br />
It's (mostly) a standalone app, that have to be fast and stable, should use boost::asio (which I would like to learn).<br />
Addon server is something that I may need sooner or later myself. <br />
<br />
=== Include an estimated timeline for your work on the project. ===<br />
Currently this is only predictions, will update when I'll know more.<br />
April - getting used to boost::asio.<br />
May - exams, won't be able to work on GSoC.<br />
first half of June - finish specification.<br />
second half of June, July - coding.<br />
August - testing, bugfixing, hopefully - integration.<br />
<br />
If anything won't be finished by August then I'll continue to work on it after GSoC.<br />
<br />
=== Include as much technical detail about your implementation as you can ===<br />
See [[SoC2012_Ivan_Addon_Server#Description]]<br />
<br />
=== What do you expect to gain from this project? ===<br />
Experience making actively used application, some networking knowledge.<br />
Working addon server that I can use myself apart from using it in Wesnoth.<br />
<br />
=== What would make you stay in the Wesnoth community after the conclusion of SOC? ===<br />
Basically any work on this project in case if I won't finish something in time or in case of new feature request.<br />
<br />
== Practical considerations ==<br />
<br />
=== Are you familiar with any of the following tools or languages? ===<br />
* Subversion - basic commit\checkout via GUI<br />
* C++ and STL - good I think. Have been actively using it for at least 2 years.<br />
* Boost - I've used several libraries (filesystem, functions, algorithms...), but not asio<br />
* SDL - more-less familiar with SDL 1.2<br />
* build environments - used autotools, would like to learn cmake at some point<br />
* WML - Nope. <br />
* Python Lua - No experience with scripting languages, would like to learn Python though<br />
<br />
=== Which tools do you normally use for development? Why do you use them? ===<br />
* Linux (Ubuntu) - It may not be perfect but it's really easy to use for developing.<br />
* C++ - Have some flaws but it is more-less portable and powerfull without notable speed loss.<br />
* CodeLite - quite small C++ IDE that have all functionality I need.<br />
<br />
=== What programming languages are you fluent in? ===<br />
I think I'm good in C++, decent in C, know a bit about Java\C#<br />
<br />
=== Would you mind talking with your mentor on telephone / internet phone?===<br />
OK. But my spoken English is most possibly awful so I hope that this won't be necessary :) Will post it in Google application.</div>Ejlshttps://wiki.wesnoth.org/index.php?title=User_talk:IvanS&diff=45781User talk:IvanS2012-03-22T21:22:44Z<p>Ejls: Created page with 'Please, have a look at SoC2012 Template of Student page, especialy: TODO: Copy this page and write "your name - proposal title" in this h4 section TODO: Write a small (1-4 …'</p>
<hr />
<div>Please, have a look at [[SoC2012 Template of Student page]], especialy:<br />
TODO: Copy this page and write "your name - proposal title" in this h4 section<br />
TODO: Write a small (1-4 sentences) description of your proposal here.<br />
TODO: Add more first-level sections to detail your proposal<br />
The content of the &lt;h4&gt;Description&lt;/h4&gt; section is dynamically inserted in the [[SummerOfCodeIdeas]] page. If everyone add subsection, it will quickly become unreadable. After writing the small description, you should start another first-level section (with only one =). I've changed your proposal, I hope you don't mind.<br />
<span class="smallcaps" style="font-variant:small-caps;">[[User:Ejls|éjls]]<sup>[[User_talk:Ejls|t]][[Special:Contributions/Ejls|c]]</sup></span> 21:22, 22 March 2012 (UTC)</div>Ejlshttps://wiki.wesnoth.org/index.php?title=SoC_Ideas_Whiteboard_Backend_Refactoring_2012&diff=45739SoC Ideas Whiteboard Backend Refactoring 20122012-03-20T20:49:57Z<p>Ejls: Correction of category</p>
<hr />
<div>{{Template:SoC2012Idea}}<br />
= Description =<br />
<h2>Whiteboard: Refactor the backend</h2><br />
<br />
Page for the idea: [[SoC Ideas Whiteboard Backend Refactoring 2012]]<br />
<br />
Improve the whiteboard's (the wesnoth action-planning system) backend code by refactoring the data structure which holds the planned actions. Also refactor the verification and mapbuilding processes by combining them, and use this single new process to cache as much data as possible to avoid redundant lookups. You can also propose other simplifications.<br />
<br />
Produce complete unit tests to cover all operations on the new planned action storage and the new combined mapbuilding/verification.<br />
<br />
Document this new backend, explaining your design approach and including all diagrams necessary for the reader's understanding.<br />
<br />
Finally, do exhaustive playtesting and bugfixing involving devs and community members to make sure the whiteboard is fully reliable.<br />
<br />
{{#dpl:<br />
|resultsheader=''There are %PAGES% submitted student proposals for this idea''<br />
|oneresultheader=''There is 1 student proposal for this idea''<br />
|suppresserrors=true<br />
|noresultsheader=''There are no student proposals for this idea''<br />
|category=Summer of Code 2012 Student Page&SoC Ideas Whiteboard Backend Refactoring 2012<br />
|notcategory=SoC 2012 Not Submitted To Google<br />
|include=#Description<br />
|nottitlematch=SoC2012_Template_of_Student_page<br />
|mode=userformat<br />
|format=,,<br/>See [[%PAGE%|%TITLE%]] for more information.<br/><br/>,<br />
}}<br />
<br />
=Additional Information=<br />
<br />
==Combining the mapbuilding and action verification==<br />
The whiteboard planning system can show you things like possible enemy moves "in the future", after you've moved your units to the planned positions. To achieve this, it builds an internal future state by taking the orders of the player and applying them to the game state in the correct order, a process we call "mapbuilding".<br />
<br />
The issue here is that we also have a separate "verification" of said orders to make sure they are possible. This is used everytime the game state might have changed outside of the whiteboard's control, or whenever the player deletes one of his planned actions, and so on. For historical reasons this is separate from mapbuilding, which is a problem since we end up with a lot of duplicate code, and since they don't handle actions spread over multiple turns consistently.<br />
<br />
Another issue is that we often do a full search of the planned actions for various purposes, which is not optimal.<br />
<br />
The solution to both of those is to combine mapbuilding and verification in a single process, so that we basically validate actions every time we build the future state. We also want to take advantage that we're going over every planned action to cache some data, such as which hexes are planned moves destinations: this way we avoid going over the planned actions again when displaying the whiteboard's visual aids.<br />
<br />
Lastly we also have a "highlighting" process which identifies which planned actions should receive a visual highlight depending on the mouse position. A lot if not all of the information processed there should be instead cached inside the combined mapbuilding/validator.<br />
<br />
==Refactoring the actions container==<br />
Right now the actions for each turn are held in a separate stl container, and we have an iterator front-end to make all of a player's actions accessible as one container. This makes for an overly complicated and wasteful backend. The objective here is to simplify it as much as possible and make it rock-solid.<br />
<br />
==Playtesting==<br />
<br />
Past experience has shown that properly testing the whiteboard means testing:<br />
* campaigns<br />
* multiplayer scenarios vs the AI and vs players, with and without heavy WML scripting<br />
* observers (can cause bugs and should be tested)<br />
* 2v2 matches<br />
<br />
For proper playtesting you'll need to create several very simple scenarios that allow to quickly test all the possible planned actions, i.e. recruit, recall, move (including over several turns), attack, and eventually the "suppose dead" action if we re-enable it.<br />
<br />
You should at first do exhaustive tests by yourself up to simulating 2v2 matches with 4 local clients, and when you're confident the game is bug-free, organise matches with devs and community members to put the whiteboard's usability to the test, and to find the last, least obvious bugs.<br />
<br />
=Requirements=<br />
<br />
Good skills with the C++ stl, and boost shared pointers, are recommended. As is basic experience in writing unit tests. Prior Wesnoth multiplayer experience is a plus, but not essential.<br />
<br />
Since this project is very focused you're expected to have a pretty complete view of what you want to develop down to the most important class members, before GSoC starts. You're also expected to provide a realistic development calendar.<br />
<br />
Note that all development must be finished by the GSoC midterm evaluation, after which all the time will be reserved for documenting, playtesting and bugfixing.<br />
<br />
=Whom to ask about this=<br />
<br />
[[User:Gabba|Gabba]]<br />
<br />
gabba on irc. If I'm hard to reach you can also find my email in the game's source files (if you're gonna make the effort to find it, I can make the effort to read your mail ;) ).</div>Ejlshttps://wiki.wesnoth.org/index.php?title=SoC_Ideas_Whiteboard_Multiple_CTK_2012&diff=45738SoC Ideas Whiteboard Multiple CTK 20122012-03-20T20:49:54Z<p>Ejls: Correction of category</p>
<hr />
<div>{{Template:SoC2012Idea}}<br />
= Description =<br />
<h2>Whiteboard: Multiple Chance-to-kill calculations and interface polish</h2><br />
<br />
Page for the idea: [[SoC Ideas Whiteboard Multiple CTK 2012]]<br />
<br />
The whiteboard (the wesnoth action-planning system) allows you to plan several attacks on a single unit. Wesnoth already computes your chances to kill an attacked unit in a 1v1 fight in the battle dialog: extend this dialog to compute total kill chances taking into account all successive planned attackers.<br />
<br />
In addition, the whiteboard interface still has some outstanding bugs or incomplete features and usability issues. Identify as many of those problems as possible and propose ways to solve them (see details for some ideas).<br />
<br />
Finally, do exhaustive playtesting and bugfixing involving devs and community members to make sure the whiteboard is fully reliable.<br />
<br />
{{#dpl:<br />
|resultsheader=''There are %PAGES% submitted student proposals for this idea''<br />
|oneresultheader=''There is 1 student proposal for this idea''<br />
|suppresserrors=true<br />
|noresultsheader=''There are no student proposals for this idea''<br />
|category=Summer of Code 2012 Student Page&SoC Ideas Whiteboard Multiple CTK 2012<br />
|notcategory=SoC 2012 Not Submitted To Google<br />
|include=#Description<br />
|nottitlematch=SoC2012_Template_of_Student_page<br />
|mode=userformat<br />
|format=,,<br/>See [[%PAGE%|%TITLE%]] for more information.<br/><br/>,<br />
}}<br />
<br />
=Additional Information=<br />
<br />
==Chance-to-kill calculations for multiple planned attacks==<br />
<br />
The main challenge here besides computing the odds will be to design a good interface to accomodate this new info. You should at the very least submit UI mockups. Be aware that your UI should still work at the lowest resolution Wesnoth supports.<br />
<br />
Optional addition: When several attacks are planned it can be hard to remember which unit is using which weapon. Try and find a way to display this information. Again, UI mockups are necessary so we can evaluate your idea.<br />
<br />
==Polishing up the Suppose Dead feature==<br />
<br />
The whiteboard has a "suppose dead" feature from GSoC 2011 which is currently disabled for lack of a good UI. This feature allows to basically remove a unit from the game temporarily to see how it affects pathfinding and zones of control. Propose visuals and a UI for this feature to try and redeem it. Yes, you guessed it, UI mockups needed.<br />
<br />
==Misc polishing==<br />
<br />
* Current whiteboard bugs on the tracker: https://gna.org/bugs/?group=wesnoth&bug_group_id=117 (Fixing one or two of those as part of your submission is highly recommended, to show you can handle the wesnoth code base.)<br />
<br />
* Ensure the interface to show/hide your allies' plans works properly and has good usability.<br />
<br />
* Reduce visual clutter as much as possible: more visual elements such as numbers for planned moves should probably only display when a planned action is highlighted. This and other visual choices should be made optional: show always/show on highlight/never show.<br />
<br />
* The interface for moves which go over multiple turns needs some work. Currently the emphasis is on the last future position of the unit (even if that is 5 turns from now), while it should probably on where the unit will end up during this turn.<br />
<br />
==Playtesting==<br />
<br />
Past experience has shown that properly testing the whiteboard means testing:<br />
* campaigns<br />
* multiplayer scenarios vs the AI and vs players, with and without heavy WML scripting<br />
* observers (can cause bugs and should be tested)<br />
* 2v2 matches<br />
<br />
For proper playtesting you'll need to create several very simple scenarios that allow to quickly test all the possible planned actions, i.e. recruit, recall, move (including over several turns), attack, and eventually the "suppose dead" action if we re-enable it.<br />
<br />
You should at first do exhaustive tests by yourself up to simulating 2v2 matches with 4 local clients, and when you're confident the game is bug-free, organise matches with devs and community members to put the whiteboard's usability to the test, and to find the last, least obvious bugs.<br />
<br />
=Requirements=<br />
<br />
Prior Wesnoth playing experience is required, since you're gonna do interface design, and a multiplayer match versus the whiteboard developer will be part of the acceptance process (don't worry, he sucks at competitive Wesnoth, and you're only expected to show that you have some clue on how to play the game).<br />
<br />
Good C++ skills are recommended, as is at least basic experience in interface design. You should also have a basic grasp of statistics, for the CTK calculations.<br />
<br />
Note that all feature development (i.e. multiple CTK and Suppose Dead) must be finished by the GSoC midterm evaluation, after which all the time will be reserved for playtesting and further polishing.<br />
<br />
=Whom to ask about this=<br />
<br />
[[User:Gabba|Gabba]]<br />
<br />
gabba on irc. If I'm hard to reach you can also find my email in the game's source files (if you're gonna make the effort to find it, I can make the effort to read your mail ;) ).<br />
<br />
Crab_ on irc can point you to the existing code for chance-to-kill calculations.</div>Ejlshttps://wiki.wesnoth.org/index.php?title=EasyCoding&diff=45559EasyCoding2012-03-08T20:02:02Z<p>Ejls: I'm taking the power projection task</p>
<hr />
<div>== Foreword ==<br />
This page is here to document easy to do coding tasks. It is not here to double the feature request database, and should only be filled by people that know the code well enough to judge the difficulty of a given task. <br />
<br />
If you are such a person, you should feel free to edit this page.<br />
<br />
If you're not, you should post a feature request and discuss your idea on the forum or IRC. A coder with better knowledge of the code might give you the green light to add your feature here.<br />
<br />
Anybody should feel free to add "clues" to any tasks, that is entry points, traps to avoid, person to contact to discuss and so on.<br />
<br />
If you plan to work on a feature, write your name at the bottom of the feature, with the date. Note that if you are too long at working on a feature I'll "free" it back (that is if you're not working on it. If you have problems implementing it, just tell us....)<br />
<br />
<br />
--[[User:Boucman|Boucman]] 20:48, 3 October 2006 (CEST)<br />
<br />
<br />
Since bugs are sometimes a good opportunity to get a first idea of the code, i will add some here that are easy to fix as soon as i stumble upon them (the one i had in mind is fixed already ;-).<br />
<br />
--Yogi Bear, 28 February 2008<br />
<br />
== MP related features ==<br />
=== Add possibility to give reason for "ignore" ===<br />
As per FR #16001 [https://gna.org/bugs/?16001]<br />
<br />
== WML related features ==<br />
<br />
=== Make map-related FormulaAI functions accessible to WML ===<br />
As described in this forum post [http://forums.wesnoth.org/viewtopic.php?p=481087#p481087],<br />
some of the FormulaAI functions should be made available as core functions instead of AI only functions, e.g. distance_between(). Full list of FormulaAI functions is available here: [http://wiki.wesnoth.org/FormulaAI_Functions]<br />
<br />
=== WML configurable village income / upkeep ===<br />
Preferably as a [scenario], [side] or [campaign] keys. As per FR #6301 [https://gna.org/bugs/?6301]. Patch submitted: [https://gna.org/patch/index.php?1162] (gabba)<br />
<br />
--[[User:Boucman|Boucman]] 08:56, 28 February 2010 (UTC) : this is postponed for 1.8, can be considered reserved<br />
<br />
=== Add support of [if] for [scenario] ===<br />
As per FR #4539 [https://gna.org/bugs/?4539]<br />
<br />
=== Side-specific results ===<br />
Giving result=defeat or result=victory for specific sides. ([http://gna.org/bugs/index.php?4960 FR #4960]) -- [[User:dlr365|dlr365]] -- patch submitted [https://gna.org/bugs/index.php?4960]<br />
<br />
--[[User:Boucman|Boucman]] 08:58, 28 February 2010 (UTC) Patch seems abandonned, but can be used for further work feel free to take over the FR<br />
<br />
=== Support for leaderless multiplayergames ===<br />
Add support for the WML key victory_when_enemies_defeated= in the scenario tag during multiplayergames. ([https://gna.org/bugs/index.php?8106 FR #8106])<br />
--[[User:Endercoaster|endercoaster]] 30, March 2010. I'm gonna give this one a try.<br />
<br />
=== Support for standalone multiplayer scenarios ===<br />
There used to be support for standalone scenarios in the userdata tree, in reorganising the trees this feature got lost and an add-on is now required to add a scenario.<br />
Re-add this feature. It is probably a good idea to mirror the mainline multiplayer tree.<br />
<br />
<br />
=== Support variable recall cost in wml ===<br />
see https://gna.org/bugs/?16538<br />
<br />
the syntax needs to be discussed and refined, but the overall idea is good<br />
<br />
make sure to update whiteboard to handle this correctly<br />
<br />
Ask Boucman<br />
<br />
=== Other Ideas ===<br />
See [[FutureWML]]; some ideas there are easier than others.<br />
<br />
== Improvements to AI ==<br />
<br />
Fix some todos, add new formula functions, or do minor improvements to the formula language. Make it easier to debug the formula language, add more ai components.<br />
<br />
Please discuss these with Crab, Dragonking, Sirp or Boucman<br />
<br />
=== AI Batch testing ===<br />
<br />
Finish patch #1169 [https://gna.org/patch/?1169]<br />
<br />
=== Add more ai actions ===<br />
<br />
Add an ai action (and add formula_ai function to do that) to set a goto on a unit<br />
<br />
Add an ai action (and add formula_ai function to do that) to send a chat message to a player<br />
<br />
Add an ai action to set formula ai variable (convert existing code from formula_ai)<br />
<br />
Add an ai action to set formula ai unit variable (convert existing code from formula_ai)<br />
<br />
<br />
Add an ai action (and add formula_ai function to do that) to fire a WML event <br />
<br />
=== write a (fai or c++ or lua) candidate action for leader control ===<br />
<br />
=== write a (fai or c++ or lua) candidate action for using leadership/illuminate ===<br />
special handling of units with leadership to have them support units. Only do it if it actually is useful (less hits needed to kill the unit) and ability to help multiple units in a single turn (assuming enough MP)<br />
<br />
=== write a (fai or c++ or lua) candidate action for healer control ===<br />
Handle units with healing power, moving them at places where they can provide the most healing<br />
<br />
=== berserker improvement ===<br />
The default AI's strategy of attacking as much as possible is very bad with berserker... A simple AI that would prevent the berserker from attacking (and keeping him close to fight without being exposed) and attack when the chance to kill is high enough would be an interesting addition<br />
<br />
<br />
=== power projection improvement ===<br />
AI sometimes wants to calculate 'how much firepower can enemy bring on location X'. in doing so, it considers enemy possible moves, time of day, attacks, enemy defense, etc.<br />
There is specific problem with 'time_of_day' used in that calculation -sometimes, it's really needed to check 'time of day for NEXT turn', not time of day for THIS turn.(since the time of day might change next turn). <br />
<br />
power_projection must be fixed to account for the possibility of time_of_day being different.<br />
<br />
Note that some enemies might go after us (so, still on THIS turn), and some - before us (so, their next turn will be on NEXT turn).<br />
::-- let's do it. <span class="smallcaps" style="font-variant:small-caps;">[[User:Ejls|éjls]]<sup>[[User_talk:Ejls|t]]</sup></span> 20:02, 8 March 2012 (UTC)<br />
<br />
== GUI related features ==<br />
-------------------<br />
<br />
Note at the moment Mordante is working on a new GUI system, these <br />
changes will probably affect the way these items need to be implemented.<br />
Contact Mordante on IRC before starting to work on these.<br />
<br />
--[[User:SkeletonCrew|SkeletonCrew]] 14:04, 9 March 2008 (EDT)<br />
<br />
<br />
=== Theme Changes ===<br />
<br />
* allow custom themes to display values of WML variables ([http://gna.org/bugs/index.php?6209 FR #6209])<br />
* hide the hourglass item from the statusbar when there is no timer<br />
<br />
=== Widget Changes ===<br />
* show side number, name and team association information in the status table <br />
* make games sortable in the lobby (open slots, total number of players, era, XP modifier, gold per village, fog/shroud) <br />
* input history (chat, commands, ..) - note: rujasu is working on this feature<br />
=== Story Screen improvements ===<br />
see http://www.wesnoth.org/forum/viewtopic.php?p=439346#p439346 for the suggestion and https://gna.org/patch/?1587 for a patch that already touched that area heavily<br />
<br />
== GUI2 related features ==<br />
GUI2 is the new gui engine Mordante/SkeletonCrew is working on. <br />
* Information on the wiki can be found here http://www.wesnoth.org/wiki/GUIToolkit<br />
* The source code is under src/gui/<br />
* The configuration config files are under data/gui/default<br />
<br />
Some tasks need the --new-widgets since the code is only shown in the experimental mode. Tasks which need this switch have the * in the title.<br />
<br />
At the moment there are no easy tasks available.<br />
<br />
== Miscellaneous ==<br />
<br />
=== More powerful village naming ===<br />
'''Adding mountain names and other features to village names, having a second random name in village names'''<br />
<br />
Currently the village naming engine has a very good structure that could allow <br />
more powerfull names to be generated. <br />
Understanding how it works should be quite easy, and a few usefull improvements could be added.<br />
<br />
* Currently villages can use lake names and river names, this should be extended to other features like bridges, swamps, mountains etc...<br />
* It would be nice to have a separate list of "first sylabus" and "last sylabus" for naming. That's not really needed in english, but some translations could use it<br />
* Again, it is common to have villages with more than one "random" word in them. having a $name2 variable would be nice<br />
<br />
Euschn 24/03/2009<br />
<br />
=== Debug Mode ===<br />
* New debug command functionality (setting additional status.variables, possibly terrain)<br />
=== Option to disable terrain animations globally ===<br />
see https://gna.org/bugs/?15976<br />
<br />
please think a little about use cases (editor, game etc...)<br />
<br />
ask boucman for details<br />
<br />
<br />
=== Add a cycle parameter to the unit animation WML ===<br />
<br />
Animations have a "cycle" internal parameter that decides if the animation loops when it finishes. <br />
<br />
Right now that parameter is decided purely by the engine depending on the circumstances, but it would make sense to move it to a frame paramter.<br />
<br />
This task is mainly to add a new boolean parameter in the particle class and using/exposing it to WML in a way similar to a unit_frame<br />
<br />
ask boucman for details<br />
<br />
== Bugs ==<br />
<br />
<br />
<br />
== See Also ==<br />
<br />
[[NotSoEasyCoding]]<br />
<br />
[[Category:Development]]<br />
[[Category:Future]]</div>Ejlshttps://wiki.wesnoth.org/index.php?title=SpellingMistakes&diff=45542SpellingMistakes2012-03-07T17:55:19Z<p>Ejls: new typo: extra ] in schema_validator usage</p>
<hr />
<div>This page is meant to be a list of spelling mistakes in campaigns and other translatable texts in the en_US development version of the game.<br />
<br />
Note: The house style of Wesnoth uses a good many words and constructions that are archaic, poetic, or dialectal. If you speak modern English as a second language you may incorrectly read these as errors. Please see [[NotSpellingMistakes]] for a list of things you will encounter that may look like spelling or usage errors but are not. Note that the mainline campaigns are now using correct typography, including sexed quotes and en and em dashes. These will appear as three byte sequences if you are not using a viewer that supports UTF-8.<br />
<br />
==Mainline Campaigns==<br />
<br />
===An Orcish Incursion===<br />
<br />
===Dead Water===<br />
<br />
===Delfador’s Memoirs===<br />
<br />
===Descent into Darkness===<br />
<br />
===Eastern Invasion===<br />
<br />
===Heir to the Throne===<br />
<br />
===Liberty===<br />
<br />
===Northern Rebirth===<br />
<br />
===Sceptre of Fire===<br />
<br />
===Son of the Black Eye===<br />
<br />
===The Hammer of Thursagan===<br />
<br />
===The Legend of Wesmere===<br />
<br />
===The Rise of Wesnoth===<br />
<br />
===The South Guard===<br />
<br />
===Two Brothers===<br />
<br />
===Under the Burning Suns===<br />
<br />
S6a, line 685 in the .cfg: seems to be missing a verb: ''"[...] but I will '''''???''''' once you finish your mission."'' Maybe "return"?<br />
<br />
==Wesnoth Game==<br />
<br />
===Editor===<br />
<br />
===Help===<br />
<br />
===Tutorial===<br />
<br />
===Manual===<br />
<br />
===Manpages===<br />
<br />
===Units===<br />
<br />
===1.10 Announcement===<br />
<br />
===Other (unit descriptions, ...)===<br />
src/tools/validator/validator_tool.cpp:46 an extra ] appearing in the help of the schema validator tool (<tt>schema_validator -h</tt>):<br />
usage: ./schema_validator [-hV] [-s <schema_file>] ]<br />
The line 46 should be:<br />
<< " [-hV] [-i <input_file>] [-s <schema_file>]\n"<br />
<br />
===Multiplayer maps===<br />
<br />
===Translation code bugs===<br />
<br />
==Unofficial campaigns==<br />
<br />
===Invasion from the Unknown===</div>Ejls