GSoC Akihara Proposal

From The Battle for Wesnoth Wiki
Revision as of 20:55, 7 April 2012 by Akihara (talk | contribs) (Which type of unit)

About me

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

Experience

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.

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.

Gaming

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

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.

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.

My contribution to Wesnoth

Patches

Patch # Description Link

3237

TRANSFORM_UNIT needs a variable renamed

Link

3238

"maximum auto saves" setting seems ignored

Link

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.

Communication skills

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.

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.

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.

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.

If I have no idea, I look sources at the beginning.

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.

Project

Why

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.

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.

Timeline

First, i will take i few days to know the implementation structure. (1-3 days)

Second, see the current solution and understand it. It's always usefull to know how it works now before changing everything.(1-2 days)

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)

I will begin coding. Of course, the third point is never really closed. It's always usefull to have new argument.

Test & Play

If it goes to the right way, it's ok. Otherwise, I will reconsider the third point.



My idea

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.

Support multiple leaders

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.

Structure

All units (whatever their side) are currently stored into a unit_map which associate unit with their location.

First, we need to change the function unit_map::unit_iterator unit_map::find_leader(int side) in order to returning the list of leaders of a particular side.

But with the currently solution, the AI can only use the first leader in the list as a leader (recruitment and move on keep).

We also have leader_list used for multiplayer game. We can think of a way of using it.


Placement

We can have several case with different number of leaders and different number of keeps. We will look as each separately.

Case 1.1: several leaders (same type) - one keep

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.

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

In this case, we have:

  • a single list of recruitment
Case 1.2: several leaders (different type) - one keep

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

In this case, we have:

  • two recruitment_list

So, we have several cases:

  • 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.
  • 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.
  • If we have unit of both type, we will recruit the A list and then the B list.
Case 2: several leaders - several keep

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

In this case, we have

  • two recruitment list

Support per-leader recruit/recall list

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

Of course, we can add an other attribute to the unit class.

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. With this method, the AI knows automatically which unit he can recruit.

Recruitment strategie

MinMax

In order to make an effective counter-recruiting, an idea will to implement an 2-depth minmax algorithm.

In order to make it, AI needs to cheat a little (all AI cheat... no?) in order to know what the player can recruit.

This algorithm works very well, but has some negative points:

  • he can be a little slow... but it will be ok for a 2-depth algorithm.
  • depends on the formula. If the formula is precise, the algorithm will have better result.

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

If it works well, it can also solve few problem of recruitment:

  • Knowing how much unit type recruit according to a situation
  • Not spend all gold for nothing
  • Not overestimating the value of high-level recruits
  • Recruit more suitable unit for the terrain
Which type of unit

We have different type

How much unit type recruit

Analyse map better

Working on different recruitment list

Practical considerations

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. I really like PPO language like JAVA. JAVA is obviously the language I have more experience with. Moreover, I coded in c, c++, python, prolog and I think it's all.

* Subversion - I have my own svn.
* C++ - I developed in c++ some years ago but I will remember since the start of GSoC
* STL, Boost, Sdl  - never used.
* Python  - I know it, used some times.
* build environments - I know cmake but not scons
* WML - no :(
* Lua - neither.