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

Greywhind - New Alliance System

I plan to implement a system for configurable privileges and protections between players in Battle for Wesnoth, in order to create a more flexible and more extensible alliance system. I plan to implement the suggested settings, and also to provide unintrusive tooltip notifications when an action is permitted or denied by an alliance setting. As someone who enjoys the board game Diplomacy, I know how an interesting alliance system can really make for an engaging game. Therefore, additionally, I would like to consider putting in place a system whereby these settings can be secret or public, and whereby public or private written treaties (in text form, and unenforced by code) can be proposed and accepted or rejected.

IRC

Greywhind

SoC Application

Greywhind's Improved Alliance System, with Configuration Options and Textual Treaties

Proposal

Brief

I will work on improving the alliance system. I think that it is an idea with many interesting possibilities, and that it could really be a cool new feature that would keep players engaged. The new system will be layered on top of the old "teams" system - there will be a parameter to switch on or off the detailed alliance settings, so that scenario/map makers can choose to stick with the simple method. The new parameters will be settable both in WML and in the GUI and will be as follows:

* unit_peace - we can or cannot attack the player's units
* village_peace - we can or cannot capture villages from this player
* use_healers - the player can or cannot use our healers
* use_leaders - the player can or cannot use our leaders
* share_fog - the player can or cannot see what we see without fog
* share_territory - the player can or cannot teleport using our villages and be affected by our ZOC
* share_victory - if we win, does the other player win automatically as well?
* team - this will be a shortcut to set all the other parameters at once - if both players have "team" selected for the other, they will show with the same team label.

Note: After discussing the matter with noy, he suggested that the "use_leaders" parameter would be best left just in WML, not in the GUI, since players shouldn't usually be able to change it. I'll take his suggestion, and it will be just a WML feature if it is included.

I would also like to try to make the visual indications of these things obvious and useful. For instance, units that cannot be attacked due to alliance settings will have a tooltip to indicate this. Ally-controlled villages will similarly be marked. Additionally, the scenario creator will be able to specify whether the settings chosen by a given player should be visible to the rest of the players. Secret alliances can be quite fun.

NOTE: After discussion with the developers, the following section is currently undecided and probably not included, unless I hear some strong support for it:

Finally, I would really like to consider adding a textual treaty feature (for multiplayer only), where two players (or perhaps even a group) could set up a written agreement that would allow even more interesting interactions. These written treaties would have no coded enforcement - it would be up to the participants to follow or break them as they please.

Why this project?

I chose this project because I believe it would be something I am capable of figuring out during a single summer and because I think it could create a new avenue for Battle for Wesnoth to explore, adding to the appeal for players who like complex diplomatic interaction.

Timeline

Note: This timeline is highly tentative and I would like to hear feedback from anyone and everyone on it. The dates given would be proposed deadlines.

May 30: The first week will be spent familiarizing myself with the code (what relevant parts I haven't looked at in advance of the starting date) and planning the details of basic implementation of the preferences for allies. If all goes well, I would hope to have a data structure for these preferences in place by the 30th.

June 6: I will definitely have the basic preferences for allies capable of being stored by this date, although the user-interface will not necessarily allow setting them yet. This information will all be settable through WML by this point.

June 13: This week will involve beginning the GUI setup for the basic ally parameters. I will have a basic user interface (simple checkboxes, probably) in place by this date. The parameters will not have a gameplay effect at this point.

June 20: I will add written treaty support, if that feature is thought valuable by other developers. This will extend the original basic preferences in the back end. If this feature is not going to happen, I will instead polish the GUI and give players visual feedback on how to use it. At this time, it looks like the latter case is more likely.

June 27: The written treaty support will be available through the GUI and in WML. If this feature is not going in, I will instead implement secret/public status for the other settings.

July 4: I will put in enforcement of some of the simpler ally preferences. These will now have an actual effect on the game.

July 11: I will spend this week polishing up and finishing the work from the previous weeks to prepare for the midterm.

July 18: I will add the enforcement of the other ally preferences.

July 25: I will create graphical means of showing when an action is prohibited by ally preferences. For instance, attempting to attack a unit that should not be attacked according to your ally preferences will show some sort of visual indication of why it is disallowed.

August 1: If I have not yet finished the secret/public preferences implementation, I will do it this week. If I have, I will continue to improve the user-friendliness of the system.

August 8: This week I will leave for fallback time to finish previous features that proved more difficult than expected.

Note: August 7th through 14th is the Thousand Parsec Hack-a-Week (a week-long time for Thousand Parsec developers to make progress on the code). I will potentially have less time this week to work on the project, if I attend. However, this is a "pencils-down" time, so it should be after most of the major work is done for GSOC. If necessary, I will scale back my work on Thousand Parsec to complete the GSOC project - succeeding in this year's project is much more important to me.

August 15: I will spend this week writing documentation, comments, and other polish.

This is the end of the program.

Additional Technical Detail

The WML tags will probably look something like this (where team_name is still present, but used only for display purposes, if the detailed alliance settings are used):

[side]
  ...
  team_name = someteam
  [relation]
    side = 2
    unit_peace = yes
    village_peace = no
    ...
    share_fog = yes
  [/relation]
  ...
[/side]

Additionally, there will be the "use_detailed_alliances" setting, to turn off these parameters, in which case "team_name" will still be used to set the old-style alliances:

[scenario]
  ...
  use_detailed_alliances = no
[/scenario]

If these tags are missing, the default will be "no."

For hosts of multiplayer games, the option will be listed to turn on or off the detailed settings for alliances, and to allow or disallow textual treaties.

The settings will be stored in a class, since I'd like to allow extensibility for non-boolean settings if necessary for some future upgrade. The class will allow listing the parameters, setting/getting them by name, and locking them. Textual treaties will be stored in a separate class from the standard settings. The scenario will store the information about whether to use the detailed settings, rather than having each individual settings class contain that toggle. Each side will have a list or hash table of these settings, one entry for each other side. If there is no entry for a particular side, it will be assumed that all settings are "no."

These will require changes to the "team" source files, multiplayer game settings files, and in-game menus. There will also be several changes to code in various game logic checks, such as the code to determine whether a unit can be attacked. A new popup window will be needed for treaty proposals. I cannot give much more detail until I have had more time to study this code.

Note: At this time, I do not plan to implement AI support for detailed team settings. This may be added to the project if there is time, but this proposal is intended primarily for multiplayer use, at least as far as this summer's work goes.

Questionnaire

1) Basics

1.1) Write a small introduction to yourself.

I am Greywhind (note, real name will be given on the Google application form), a college sophomore in the United States. I have been interested in and working towards game programming as a profession since the end of elementary school, and I would love to work on a Google Summer of Code project for Battle for Wesnoth this year. Last summer, I successfully completed a GSOC project for Thousand Parsec, details of which can be found on my blog. I have also enjoyed working on my own open-source game, Leges Motus, with two other students. The website can be found here.

1.2) State your preferred email address.

npartlan@cs.brown.edu

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

Greywhind

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

Summer of code last year taught me a gigantic amount about working with other developers and coming into an existing project, learning it, and helping to improve it. I would love to have that kind of experience again, and I would love to make a difference for a project like Battle for Wesnoth that has made such an impact on open source gaming.

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

I am studying computer science at Brown University. I am a sophomore.

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

I am from the United States, and I can usually join IRC after about 4:00 pm EST. My availability will improve greatly when summer break begins.

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

I might take a vacation, but if I do, it will be to somewhere with internet access. I should still be able to work on the project while away from home. There is some chance that I may get an internship elsewhere, but if that happens, I would be able to notify Google and Battle for Wesnoth of my withdrawal before the deadline for accepting student applications, so it would give time to choose another student.

2) Experience

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

As far as significant work, I have worked on the Thousand Parsec project for a high-school internship and then for the Google Summer of Code as both a student and a mentor. Thousand Parsec is a framework for playing turn-based space strategy games (4X style games), and I was responsible for making many bug fixes, a few new features, and then a complete overhaul of the wxPython client for a new version of the networking protocol, adding flexibility and dynamicism and improving the user interface.

I am also one of the founding designers and lead gameplay programmer for the open-source team-based zero-gravity shooter Leges Motus. With two other students, I have enjoyed creating a truly unique zero-gravity top-down view shooter, with highly extensible and customizable maps and weaponry. We are nearly prepared to release our third open beta, with the new support for multiple weapons, among other improvements.

For classes, I have completed various less significant programming assignments, involving various tasks, from using C to re-implement the "lsof" command (searching through raw information about open files and sockets), to attempting to automatically piece together arbitrary jigsaw puzzles using Java, to managing the storage and failure-tolerant access to data across a distributed system of computers.

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

I have worked in groups to develop both relatively small programming projects for class and to create Leges Motus. I have also worked with a mentor and with a student in the Google Summer of Code.

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 been both a mentor and a student for the Google Summer of Code before, both times for the Thousand Parsec project.

My previous mentor was Tim Ansell (mithro_AT_mithis.com).

I was a mentor first, because I was not yet 18 and thus could not be paid by Google for work. I provided advice and guidance for and evaluated the successful completion of jmtan's 2008 project to create a 3D client for Thousand Parsec. He was a very self-sufficient student, and I was quite pleased with his work.

As a student, I was able to complete and surpass the original goals for my project, which was to significantly overhaul the main game client for Thousand Parsec, allowing it to handle the new TP04 networking protocol and thus to enable much greater flexibility for new rulesets. With the ability to specify completely new types of objects (beyond the standard fleets, planets, and systems), and the ability to more effectively make use of multimedia information about objects and to fully utilize the ship design interface, the client is more capable of providing an interesting gameplay experience. More details of my work can be found on my blog, including frequent reports on my progress over the summer.

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

I am currently involved in the Leges Motus project, although the other two developers have very little time to devote to the project at the moment, so it is moving slowly and taking up little of my time.

2.5) Gaming experience - Are you a gamer?

Of course!

2.5.1) What type of gamer are you?

I tend to enjoy the excitement and challenge of working with others in a game, and I also enjoy fantasy worlds. I have found that team tactics and strategies in multiplayer games are the most enjoyable thing for me.

2.5.2) What type of games?

I tend to play mostly multiplayer games, from first person shooters to RPGs to strategy games. I also enjoy text-based MUDs (RPG games that are massively multiplayer and that usually involve programming a "system" to automate various actions and assist in playing. I like the combination of fantasy worlds, programming, and heart-pounding combat that these games provide).

2.5.3) What type of opponents do you prefer?

I prefer opponents who are respectful, and who are also interested in having a good time, even while being serious in their efforts.

2.5.4) Are you more interested in story or gameplay?

I enjoy a good story, especially when mixed with humor and interactiveness. Gameplay is probably my primary concern, however.

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

I have played Wesnoth, though not extensively. I played the single-player at the time, but I would like to do some multiplayer. Unfortunately, I have less time for gaming at this moment than I would like.

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

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

I have not yet contributed any patches. I will try to submit at least one patch within the next two weeks, so that you can see some of my code and I can start to learn the project's code.

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.

English is my native language. I generally do well in English courses.

3.2) What spoken languages are you fluent in?

I am not fluent in any other languages, but I have some experience with French.

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 am generally a level-headed individual. I usually get along well with other players, and I have been a member of various gaming clans that have had people of many different personalities. I do not think I have alienated anyone in these cases, even when there have been splits between factions within these groups.

3.4) Do you give constructive advice?

I really enjoy helping others. I have been an undergraduate teaching assistant for multiple computer programming classes, and in this context I have worked with many students to answer their questions and help them improve their code.

3.5) Do you receive advice well?

I am quite happy to hear and consider the advice of others. While there have been times when I have noticed myself becoming slightly too defensive, I am working diligently to suppress any such feelings and make sure that I take others' advice and put it to good use in improving my code. During Summer of Code last year, I made extensive use of code review technology to get specific advice about my coding practices and to make my code fit the advice of my mentor. It was a very useful thing to do.

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

I am usually able to pick out the most valid and important critical advice I receive, and to ignore or just quickly fix minor differences of opinion.

3.7) How autonomous are you when developing ? Would you rather discuss intensively changes and not start coding until you know what you want to do or would you rather code a proof of concept to "see how it turn out", taking the risk of having it thrown away if it doesn't match what the project want

I tend to enjoy working closely with a mentor, discussing the best way to do things and showing them preliminary results for advice. I try to avoid wasting time on a solution that doesn't fit what others want to see.

4) Project

Please see the "Project" section near the beginning of the page for details.

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

I expect to gain a detailed knowledge of the Battle for Wesnoth code, additional confidence in my capability to put together and stick to a well-designed coding plan and to contribute to existing code bases, and a really worthwhile summer activity that allows me to contribute to and become part of a good community.

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

I have enjoyed participating in the Thousand Parsec community before, during, and after GSOC. Although I do not have quite as much time to devote to it now, I enjoy being part of the community and helping when I can. I do not doubt that Wesnoth could be a really great community to be involved in beyond the GSOC, and having a good experience during the program would definitely encourage me to stick around.

5) Practical considerations

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

   * Subversion (used for all commits)

Yes. I have worked with Subversion for Leges Motus.

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

Yes. Leges Motus is written entirely in C++, and I have used it for other smaller coding tasks.

   * STL, Boost, Sdl (C++ libraries used by Wesnoth)

I have used some parts of the STL. I have some experience with SDL, although it has been a while since I used it regularly.

   * Python (optional, mainly used for tools)

Yes. Thousand Parsec's client is written in Python, and I have used it for a class I was TAing.

   * build environments (eg cmake/autotools/scons)

I have used Make, but don't have any experience with developing using cmake/autotools/scons. (I have compiled some things that made use of these technologies, but not developed with them).

   * WML (the wesnoth specific scenario language)

No experience yet, but I'd definitely be looking into it during the summer.

   * Lua (used in combination with WML to create scenarios)

No experience, but I'd be glad to pick it up if it was necessary for this project.

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

I tend to use gedit or another simple text editor for C++, with make or other command-line tools for compilation. I prefer avoiding the sluggishness in the user interfaces of most IDEs.

5.3) What programming languages are you fluent in?

I am fluent in C++, Java, Python, and TinyFugue script. I have some experience with Perl, Visual Basic (older versions), JavaScript.

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!

I would not mind at all. I will list my phone number for my mentor, but not for the public.

SummerOfCodeGreywhind

Contents