This page is related to Summer of Code 2010

See the list of Summer of Code 2010 Ideas

This is a Summer of Code 2010 student page

Description

Aranair - Summer of Code Proposal

gna.org : aranair
irc : aranair (will pop by real soon)

I am interested in a new implementation of the alliance system where I will introduce the list of parameters that was listed out in the original post in the list of ideas (with modification). My take to this is that they should not be simply set to true or false but rather with more intricate levels to increase the dynamics through simple means...

Discussed this in more details in my wiki page. Or if you wish to view a pdf version at:
PDF Version of my Idea

IRC

aranair

SoC Application

GSoc Proposal: Wesnoth: A New Alliance System (Aranair)

Questionnaire

1.1) Write a small introduction to yourself.

An easy going person (easiest way to describe oneself lol). I know when to start working, and when to take the time off for breaks. I tend to play more and more games as the stress level increases then when it reaches a certain level, I stop all entertainment to finish up the work I have to complete. I know its a little weird, but that seems to be the very trend of how I work!

1.2) State your preferred email address:

boa.homan@gmail.com

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

aranair

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

I really wish to know more about open source games and softwares and know exactly how the workflow is. I have been studying programming languages for awhile and it just seems like there is no where I can find a 'use' for this interest for coding. And of course, the attractive amount of money given while I am doing something I like, is just additional lure.

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

I am currently in my 3rd year majoring in Computer Science at the National University of Singapore. ( I'm not sure if you know Singapore, but many people seem to not know when I tell them in games , its this little dot on the map right south of Malaysia heh. )

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

As mentioned above, I am from Singapore. Currently, I am only available at night ( PST 4am onwards? ) due to school and other commitments. However, during the summer, I am usually online in the day as well ( PST night ? )

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

I do not have other commitments during the summer period. I was planning to take a short 1 week vacation to perhaps Hong Kong, but it is cancelled because my partner will not be interning instead.

2) Experience

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

Most of my projects have been pretty trivial and done in school.

However, currently I am working on my first "public-release" quality program. More details could be viewed at http://code.google.com/p/gameanywhere/

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

- A year ago, worked on a project in a team of 3 to create a software solution for a specific scenario/requirement pre-fixed by school lecturers. It was pretty trivial, in that there was much flexibility regarding the requirements and there wasn't any clients to please at all.

- I am currently working in a team of 6 people, on a game files synchronization software that is planned to be publicly released to the public. It has been ongoing for 8 weeks and will soon see the public in another week or 2 for the beta release.

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

I have not participated in the GSoC before. I'm in my third year, the only time I would have attempted would be probably in my 2nd year. In the 1st year, I wouldn't dare to imagine myself working in an industrial/real world environment at all. I probably would have joined, last year (year 2) if I actually heard about it. I only just found out about this when I read my university's digest emails.

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

No, I have not been involved with any open source developement before, and it is the primary reason why I would like to learn all about the workflow.

2.5) Gaming experience - Are you a gamer?

Yes, too much so..

2.5.1) What type of gamer are you?

Avid? I do not go for graphics, I go for more gameplay (strategy and what not)

2.5.2) What type of games?

I play a wide range of games ranging from totally graphicless M.U.Ds (multi-user dungeons) online to almost all Blizzard games. (at least I used to, currently too caught up with my school work to game much :/) Also, upon finding Battle for Wesnoth, I have been trying to find time to look into the game to find out the inner workings of the game.

2.5.3) What type of opponents do you prefer?

Heh. I prefer opponents who are smart, yet not smart enough to beat me (I know, its ego speaking)

2.5.4) Are you more interested in story or gameplay?

Gameplay I believe but usually storyline shouldn't be too far behind if the gameplay is good enough for me.

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

Honestly, I have only found out about Wesnoth when I was looking through the 2009 list for GSoC. I have installed the game, and until now, honestly I have only tried the Heir to the Throne campaign on single player. I am also aware that some projects might require a more in-depth knowledge of the game but I will more than willing to spend time on it (as well as the code base behind it of course).

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

I have not submitted any patches but I am actually looking at one of the "Easy Coding tasks" to begin with, I have svn checked out code (1.6 version I believe) and have started looking at the bug#7470 (MP chat font - small request) just to get a first-hand rough idea of the codes right now.

3) Communication skills

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

I believe I am sufficiently proficient in written English as well as spoken English as English is my primary language in my country and schools.

3.2) What spoken languages are you fluent in?

I am also fluent in Chinese, Cantonese, and conversational in French as well.

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

I have been playing interactive games for some time now, so..I do not think communication would be a problem for me.

3.4) Do you give constructive advice?

I am not too sure of that myself really. I tend to be more assertive when I give advice I think, and others might be taken aback from the slightly blunt approach. (from feedbacks heh)

3.5) Do you receive advice well?

Constructive ones yes, but I tend to want to reason it out with the person if I feel that it might not be so beneficial to what I am doing. I am quite reasonable in this area in that so as long as there is reason for this advice, I would accept it most definitely.

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

I think I am pretty ok in this area, I am working in a team right now and although sometimes I get a little confused as to when I should be changing my designs when my team members give some random comments but in the end I think my judgements are going fine!

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.

Although I am aware that no matter how much planning there is the final product might not be what you perceived it to be, I still prefer to discuss it more intensively before starting to code. Throw-away prototypes are commonly used and I am ok with this technique, but of course if given a choice, I prefer to keep them to the lowest level I can manage.

4) Project

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

I wish to handle the creation of the new alliance system.

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

-

4.3) Why did you choose this project?

I want to be more involved with the gameplay aspect instead of doing something more technical such as the spritesheets idea, albeit knowing very well that this project requires more knowledge of the game. However, I believe knowing a game isn't something that difficult with my gaming experience, it just takes a little time if you are willing.

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

May 24th is the first coding day, I would have finished my exams way before that. My exam periods are from 20-24th of April till about 8-9th of May this year. Other than this, I also have a weekly squash competition league that I must be present for, for one night every week. ( Another timeline is provided in the next part)

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

1. Current Alliance System
In the current alliance system, two sides are allies if and only the two sides share/have the same team_name and enemies simply when you do not. Fog and Shroud evaluations are also evaluated on “all or none” based on whether two sides share the same team name (same team), as well as two boolean parameters share_view and share_map. Fog and shroud is either totally shared or totally not shared among teams. Healing is also done on an ally/enemy basis automatically.

2. What can be Improved
The current implementation does not allow any level of alliance status to be involved; it is either ally or enemy. A 'team' is also actually sides(defined in team.cpp) with the same team_name.

Firstly, more levels of detail could be introduced to the alliance system. For example: you could be on a different side, but you might want to share certain resources healers, control, contributions from villages etc with another side etc.

Secondly, a better implementation of an alliance could be made; there needs to be a better way to organize cooperating sides and to handle them together more logically. The current system is more like individual sides playing against each other with benefits, mine is relatively constrasted. My system attempts to depict sides cooperating as a team.

3. New Alliance System
The original idea proposed on the idea page by the developers is to add additional parameters to the symmetric and side-pairwise alliance system currently in place and to make it asymmetric(but still pair-wise).
In this new alliance system, I wish to add in the concept of an alliance that in my opinion, more appropriately defines the relationship between N-sides.

Firstly, I will give a small game example to let you have a brief idea of the system before I zoom into discussing the details.
Scenario: there are 5 players/sides: side1, side2(backstabber), side3(backstabber), side4, side5.
- side1 forms an alliance: WesUnited. -> side1 is the leader of WesUnited.
- side4 forms an alliance: KillBill. -> side4 is the leader of KillBill.

- side2 joins WesUnited -> WesUnited : (side2,Trial), (side1,leader)
- side2 wants to consolidate and cooperate, side2 proposes Friend status to side1 and side1 accepts. -> WesUnited : (side2,Friend), (side1,leader).
- side5 wishing to have company, joins WesUnited -> WesUnited : (side2,Friend), (side1,leader), (side5, Trial)

Side2 is now able to see side5 but not side1. He builds units to counter side5. ----

- side3 joins KillBill and proposes Trusted, leader accepts -> KillBill : (side3,Trusted), (side4,leader)

side3 will now receive heals from side4's forces and use certain resources and vice versa -----

- side1 thinks side2 might be a huge help to him, he proposes Trusted status to him but side2 rejects!
- side2 feels that KillBill is stronger now, side2 joins KillBill as Trial. -> KillBill : (side3,Trusted), (side4,leader), (side2, Trial)

- side2 decides it is time to try to finish off WesUnited. side2 attacks side1. -> side2 pays the penalty for a Friend status to rebel against WesUnited. (example: 100 gold is taken from him, 2 turns void of income and barred from recruiting) -> WesUnited : (side2,Rebel), (side1,leader), (side5, Trial)
- side2 proposes sworn status to leader of KillBill, side4 accepts -> KillBill : (side3,Trusted), (side4,leader), (side2, Sworn)

side1 becomes the strongest now ----

- side2 tries to enter WesUnited again, but he is now a Rebel in WesUnited -> Rejected
- side3 backstabs side2 and proposes Sworn with side1, side1 accepts
->WesUnited: (side2,Rebel), (side1,leader), (side5,Trial), (side3,Sworn), side3 and side1's gold income increases slightly. (explained later)
->KillBill : (side3,Rebel), (side4,leader), (side2,Sworn)

side1 and side3 becomes increasingly powerful and kills side4 and side2! ----

At this point there is only 1 alliance left in game. Victory is automatically shared by side1 and side3. Side5 is only a trial and will not share victory, side1 and side3 have to kill side5 in this case. After which, side1 and side3 will be automatically declared victorious.
The above scenario is just a small example of how it may turn out in a MP game. I have left out details such as to what extent the penalty is, and how much benefits they are getting etc.

Now, I will introduce the new alliance system to you organized by the concepts involved:
Hierarchy
This system will introduce the concept of Hierarchy. 6 Alliance statuses will be in place (details of this status will be explained later on). The basic idea is that a side will become more powerful, and will gain more substantial benefits from units of another side from the same alliance as you rise in alliance status; however with it, there will also be increasing penalties when the side chooses to help against a side in a common alliance.

The 6 statuses I come up with are as follows: { Leader, Sworn, Trusted, Friend, Trial, Rebel }
The Hierarchy is simple: it is highest on the left and lowest on the right. The leader will be the side who has started the alliance. A Rebel is a side that has attacked/helped against a side with a common alliance. Each individual status will automatically dictate a specific set of values for the new parameters involved.

Taking into account the upcoming changes for persistent-gameworld data, the hierarchy might help with letting the WML authors decide how much is to be kept persistent, this system could possibly help them fine tune the definition of things to be recorded.

Alliance Rules
Along with the above mentioned statuses, there must be certain rules to hold this system together, whether to prevent cheating or to make it easier to control. It will also decide the incentives and penalties. A full set of rules must be decided before this begins. Here I will list some preliminary rules that I have come up with:

- An alliance will not contain more than 1/2 the total number of sides in map. (prevents abuse)
- Leader of alliance enjoys the best benefits, such as highest heal amount from the other sides, sharing view of other sides in alliance. (will be discussed again later)
- Leader of alliance is not able to expel anybody from an alliance. This is to prevent the scenario of a leader exploiting the full benefits of other sides and kicking them out after.
- Once you are sworn-ed with alliance, you automatically share victory and defeat with other sides in the alliance with a sworn-ed status.
- Can only be Trusted and above with one alliance.
- Trial will earn a side the least privileges but falling from trial status will not induce penalties. (Rebel status will still be set)
- Once a side backstabs a side from the same alliance, Rebel status is set, penalties must be paid and no re-entry to alliance is possible.
- In the scenario where the game detects that there is only 1 alliance left, Friend status and above will be offered an opportunity to share victory with the rest of the sworn-ed sides. They may also choose to fight to their deaths.

- Going up the ladder of alliance statuses can proposed by any side to the leader or the leader to any side. Either side could reject but of course they would be working to establish more instead of rejecting because of the reward system.

(The above list is preliminary and is subject to changes: please CTRL-B now :P) Changes:
- Sworn status is no longer non-revocable.

Incentives and Penalty
Like I have mentioned above, there will be incentives and penalties. This is one of the measures I have taken to reward team-play and make backstabbing possible but at the same time restricted. Now, I will list some examples of this concept here:

General
- A side is able to see the views of all sides of equivalent or lower status. eg: Leader will see all sides. (this might be changed if it is deemed to be too offsetting)
- Shared healing effectiveness is based on the receiver's status. Higher you are, more you receive.
Trial
- Team chats will be enabled for all statuses other than Rebel.
- Other benefits kept to a minimum.
Friend
- Trial benefits +
- Opportunity to surrender and share victory with sworn when only 1 alliance is left.
Trusted
- Friend benefits +
- Usage of leaders and villages for teleports will be shared among Trusted-s
< Sworn
- Trusted benefits +
- For every side equivalent to Sworn status, these sides will share a boost to the contributions from their villages. (amount is easily settable)
- Victory sharing will be enabled automatically for sworns. I consider it the highest benefit, when persistent game-world data is implemented

(Once again, the above list is preliminary and is subject to changes: )

Manageability
In bigger multiplayer games, the number of sides might increase and if players need to set every single privilege to every other side, it might simply be too cumbersome to handle that they disregard things in general. In my system, while it still provides the additional variety to the alliance scene, it does not offer excessive micromanagement to the gamer. This is one of the key advantages of my idea over total user-control.

Team-play
The main difference of this system where there is real evidence of an alliance, to one that only asymmetrically defines relationships between any 2 sides, is that it encourages team-play. Let me explain why:

In the latter pair-wise system, it is illogical to set penalties for revoking privileges. Since there could be no penalty, the asymmetric privilege granting is entirely based on trust. You can never ever expect something to come back from another side. It might feel logical in real life but as a gamer myself, I feel that it is too dependent on trust. I believe it is realistic to assume that the majority of the MP games will contain more strangers than really trusted friends. Being so dependent on trust makes this system extremely fragile. Seldom will players trust another stranger enough to entrust him with privileges such as view sharing or teleport location or even lesser privileges such as healer sharing only to find that he attacks you 2 turns after. As a result, interactivity between players is kept to a minimum once again.

In my system, I would like to dictate the rules in a particular fashion. It should be well established to players that playing together will be rewarding and leaving that same alliance you were playing in should be punished depending on what you have already taken. The moment a side joins an alliance, he will immediately enjoy benefits and more of them as he rises up. This system , I believe, ultimately encourages team-play in MP.

4. New Parameters and Other Implementation Details:
Enum AllianceStatus {Leader, Rebel, Trial, Friend, Trusted, Sworn}
This status will store information about a side and a team. It will dictate the availability and strength of certain other parameters. Player will be given an option to help against his ally from Trial to Trusted.

Struct alliance_pair {enum AllianceStatus alliance_status_, std::string team_name}
This will contain diplomacy ties that the side has with one team. If there exists team “one” and team “two” and side 1 is a friend of team “one”, then there will be an alliance_pair (AllianceStatus.Friend, “one”).

std::vector<alliance_pair> all_alliance_pairs
This vector will contain all ties that the side has with all teams.

boolean isNewAlliance
To determine if the user is opting for the new parameters to be in.

With the new system, there will not be major modifications to current existing methods and parameters due to the criteria that it should be easy for the old system needs to be emulated. However there are some crucial changes that must be mentioned.

One such change is in calculate_is_enemy () in “team.cpp”, where it determines whether you are a friend of another side in the new system. Now it will need to first go through all_alliance_pairs. If both sides have a diplomacy tie with a common team and neither side has status “Rebel” with the common team, the side is considered a friend. Otherwise the side is an ally.

5. Evaluation of New Parameters:
To determine if a unit can attack this side:
First find the side of that unit and check its all_alliance_pairs to see if it contains a diplomacy tie with the team of this side. If there is, display a prompt to owner of unit (a one-time decision if he chooses to backstab on ally team), otherwise it will continue as per normal.

To determine if a side will take a village from another side:
Similar checks as evaluation for unit attacks.

Usage of Healers:
It will not be done on “all or none” basis; instead the amount healable is evaluated based on the alliance status. Files such as “unit_abilities.cpp” that defines the WML for all unit abilities will not be affected by this.

Such as in the case of healings, since the evaluation of whether it is an ally or an enemy is still done as per normal (all possible levels of alliance status are regarded as allied), there will be no changes to “affects_side ()".
Just before the ability is applied in gameplay, I will add a new method “evaluate_strength ()” that will take in vector of teams in play and the two sides of the units in concern, to set the actual strength of the heal according to the alliance status of the Receiver unit and not the healer’s alliance status.
For example if the recorded value of heal is 8, and alliance status of receiver unit is Trusted, then the actual value of the heal would be 8 * 80% = 6(floor-ed) and it diminishes for each dropping alliance rank.
In a specific scenario shown in Figure 1.0 where the receiver unit is in two common teams with the healer, and the each of the two status differ as well, then the higher alliance status is taken. In this scenario, Unit 2: Receiver will receive 80% (value for Trusted) healing from Unit 1.

The actual value of all beneficial effects coming from a unit whose side shares the team with the receiving unit; will be evaluated in this same fashion.

Contributions from Villages
For every side above trusted in alliance, these sides will enjoy a slight boost to the contributions from their villages. 0.1 times more for each side. For example: alliance have 1 leader, 2 trusted, 2 friends. The leader and the 2 trusted sides will enjoy 1.3 times the contributions. Amount can be decided in future when implementation starts.

Usage of Leaders & Villages for Teleports
A side that is able to use our leaders must have the status Trusted with a common alliance as our side. If there exist two common alliances, once again the higher status will be considered.

Evaluation of Fog and Shroud:
My original idea is to evaluate fog and shroud based on status as well. A side will automatically see views of all sides with a lower status with the common team.
For example in the scenario shown in Figure 1.1 the evaluation of viewable areas for Aranair will be done in this manner. First, it will go through all_alliance_pairs. It finds that Aranair is Trusted with Team 1, it will then see all Side 2’s views because side 2 is of a lower status with the common Team 1.
I am aware that this type of evaluation with views might not be accepted or possible, so I have thought of a replacement scheme. It could be such that it is fixed: below Trusted status, no views will be shared, and above all views will be shared.

Sharing of Victory/Defeat:
This has been implicitly handled by this status system. When a side enter Sworn status with a team, all sides that have Sworn status with the same team will share victory and defeat.

Sharing of Chats:
Any message sent from one side, will be sent to all teams that exist in all_alliance_pairs in the side. Any side who has a status (other than “Rebel”) will receive the same message. I consider this the lowest level of benefit and may give rise to more infiltration with Trial status and backstabbing.

Timeline

I will not be waiting for the official coding period to start coding. I am currently already in the process of looking with much details some parts of the code to gain a better understanding. However, I would be preparing for my exams which will end on the 5th May. After which, I will begin full scale the coding procedures.

First Stage: Analysis and Planning
In this stage, I will first have to find ALL places where this change will affect and attempt to keep these changes as manageable by these current codes as possible, after which I will begin planning and doing a little coding of the new parameter of this new system in the major files. (Note: this stage is still before the official start date of GSoC).
Time Needed: 2 weeks
Deliverables: Analysis report of files affected by this ricochet change and a preliminary API of the new code.

Second Stage: Coding Stage
Upon starting this stage, it will be one week before the official start date. This stage is the major coding stage where I will be adding the new parameters in the team files and exposing these parameters to WML and also propagating these changes to the critical files first while at the same time ensuring that these changes conform to the requirements of the team such as SUF and other filters.
Time Needed: 6-7 weeks
Deliverables: Codes for the new parameters and exposed to WML.

Third Stage: Changing Affected Files
There will be a large number of files affected through this change, especially the AI files. I have not currently looked into the AI files and I would have to speak in greater details with my mentor regarding the changing of these files to enable better planning with this new alliance system. A realistic target for this GSoC’s workload would be to primarily propagate my changes over to the AI side and allow it to work without breaking the trunk version.
Time Needed: 4 weeks
Deliverables: Get affected files working, GUI prototypes for the next stage.

Final Stage: GUI and Merging
As I have mentioned above in my proposal, some form of human intervention will be needed and with this will come GUI changes as well. In this stage, I will be adding the GUI components for this new change, as well as finishing up the code and double checking its workability and trying to merge the branch into the trunk.
Time Needed: 3 weeks
Deliverables: GUI components integrated into final product, and working branch merged into trunk.

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

I wish to know as much about open source workflow as possible. I also wish to meet a group of avid developers who are willing to stay as friends even after this period. And of course, add a game I can always return to when I know I am bored.

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

The group of people I worked with during the course of the SoC. I think if they were friendly and helpful to me, I wouldn't mind at all, to stay and continue my works for Wesnoth. Of course, that would also depend on the community, whether they want the help from me or not!

5) Practical considerations

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

Subversion (used for all commits)

EDITTED: Am currently using subversion for majority of my coding right now with my team. However, I have yet to have experience on the commandprompt svn. I have been using the TortoiseSvn on windows for approximately 3 weeks now.

C++ (language used for all the normal source code)

I coded in C++ awhile ago for a year roughly in school. Although I do not believe I have the full proficiency to handle the C++ code in Wesnoth yet, with online references and a little reading done, it would not be difficult. I am currently looking at the current alliance system right now to make more sense of it.

None- for the the following technical skills unfortunately :/

   * STL, Boost, Sdl (C++ libraries used by Wesnoth)
   * Python (optional, mainly used for tools)
   * build environments (eg cmake/autotools/scons)
   * WML (the wesnoth specific scenario language)
   * Lua (used in combination with WML to create scenarios)

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

I am currently using Microsoft Visual Studio 2008 for my software development in C#.

I used DrJava for simplicity, instead of NetBeans. I actually prefer typing some things out instead of intellisense or autocomplete kind of feature.

5.3) What programming languages are you fluent in?

Java 3 years, C++ 1.5years, C 2years, C# half a year.

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

I am known to be online too much, heh but of course, a number isn't too much to ask I think? I'll add the number when i submit the application to google.

SummerofCode Aranair

Contents