GSoC: Endercoaster

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

Project: SoC Ideas New Alliance System

Quick Definitions

Permission: A particular alliance rule.
Active Player: The player who is setting alliance permissions (or equivalent if alliance settings locked)
Passive Player: The player who the active player is setting permissions with regards to.

Description

Endercoaster-New Alliance System

I plan to develop an expanded alliance system for Wesnoth, providing greater granularity and asymmetry in setting permissions. The first major step in this will be refactoring the array enemies_ which stores booleans with an array alliances_, which will store a vector of permissions (Probably stored as booleans, possibly stored as various implementations of an interface that will wrap either booleans or enums).

Extended Description

The permissions stored will be:

• Enemy: Serves the function of the booleans in the enemies_ array to allow for emulation of the current alliance system and less fragility during development. (Things to consider: "Ally" instead such that true is the "friendlier" setting for all permissions)
• CanAttack: If set to false, the active player will be unable to attack units of the passive player. If set to true, they may. (Things to consider: BlockAttack instead such that true is the "friendlier" setting, Is there a penalty to your defense or counterattack if you are attacked by the passive player while CanAttack is false? Prompt to check an attack?)
• TakeVillages: If set to true, the active player can capture the villages of the passive player. (Things to consider: Making true friendly. If set to true, will the active player be unable to move into the village, or will they move into the village without capturing it? Prompt?)
• AllowHealing: If set to true, the active player's healers will heal units of the passive players if those units are within the healer's range. (Things to consider: Possible enum implementation of NO, PREFER_US (Will only heal passive player's units if no active player units in range need healing), EQUAL (Will treat active player and passive player units equal) , PREFER_THEM (Will only heal active player's units if no passive player's units in range need healing)).
• GiveShroud: If set to true, the passive player will receive the shroud information which the active player has.
• GiveFog: If set to true, the passive player will receive the fog information which the active player has.
• AllowVillageTeleport: If set to true, the passive player will be able to use the active player's villages to teleport.
• UseZOC: If set to true, the passive player will be affected by the active player's zone of control. If set to false, passive player units will not be hindered by the zone of control of active player units. (Things to consider: Friendly true: IgnoreZOC)
• ShareTeamChat: If set to true, messages which the active player sends in the team chat channel will be sent to the passive player (Things to consider: Team chat groups?)
• ShareTeamLabels: Shares team labels with the passive player. (Things to consider: seperate permissions for each label would be unwieldy but potentially useful. Label groups?)
• SharedVictory: At the basic level, if two or more players have this true for each other, than when one wins, they all win, and they will not count against each other's victory conditions (e.g. if the objective is "kill all enemy leaders", then two players sharing victory will win when there are no leaders besides theirs). I also would like to put forward the idea to implement this specifically such that a player setting this to true means that the passive player wins when the active player wins and the active player does not count against the passive player's objective. Doing so would provide an asymmetry making shared victory the highest level of trust which it should be.
• If gabba implements his whiteboard idea whether through GSoC or not, at least one additional permission will be required. We are both aware of this fact and will collaborate to work this out.

Upon doing this, a WML tag will be added to scenarios which marks whether the scenario uses the old or new alliance system. This will default to old such that scenarios written before the new alliance system will not be broken. The following step is one by one, making the permissions for the new system "active"--that is to say making the actions that concern permissions account for the permissions. This step may involve making AI that takes these restrictions and permissions into account when planning moves, or doing this may happen after the system is fully implemented for human players.

WML functionality would then be added which allows individual permissions to be locked or unlocked in scenarios, with a default of unlocked. A diplomacy window would then be added to the GUI, allowing players to edit permissions. This window would only be accessible for scenarios where at least one permission is unlocked. This window would have tabs for each player other than the active player, with a checkbox (or if enums are used, radio buttons where appropriate) for each permission unlocked for this scenario. The window can be opened directly to the tab of a player by right clicking on one of that player's units and clicking on a "diplomacy" item on the drop-down menu.

Finally is any AI work left to be done: Level 1 (very doable): AI that takes restrictions and permissions into account when planning moves. Level 2 (probably doable with help from somebody more knowledgeable about AI): AI that will plan moves that benefits "allies" Level 3 (very unlikely for summer, if even possible): AI which is able to change permissions in scenarios where permissions are unlocked. (Without this, all unlocked privileges will remain at their default value, which is just fine)

IRC

endercoaster

SoC Application

Endercoaster-New Alliance System

Questionnaire

1) The Basics)

1.1) Write a small introduction to yourself.

I'm Denny Vaccaro, and I'm a programming student who is passionate about medieval fantasy. Whether it's computer games, tabletop games, or fighting Belegarth, ever since I've gotten to college, a large part of my free time is spent "in" that setting. I eventually would like to get into game development professionally, and recognize the important of experience in breaking into that competitive field.

1.2) State your preferred email address.

vaccarod@grinnell.edu

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

endercoaster

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

While I had a very nice internship with Northrop Grumman last summer, it did not mesh with my personal goals for what I want to program professionally. Coding for Battle of Wesnoth would allow me to gain experience in game development, my first choice for a job post-graduation, while working on a project that I'd be proud to be a part of.

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

I'm a 3rd year Computer Science major at Grinnell College in Iowa

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

I'm from the US, and will most likely be on from 14:00 CT to at least 0:00 CT

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

There are no vacations that I'm aware of. I have another internship, but from the sounds of it, it is roughly equivalent to a part-time job. I'd also be able to work on that on my own schedule, so my plan for handling both is to switch from one to the other when a problem needs time to "percolate".

2) Experience

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

In addition to various minor school assignments, last summer I had an internship with Northrop Grumman where I used QT to develop and "attach" the GUI for the lab test of a radar jammer. The class I am taking now is focused on the development of a large group project, in this case, a competitive multiplayer variant on Conway's Game of Life.

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

Yes, both the GUI and my current class project are/were developed in team environments.

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?

No, this is hopefully my first year doing Summer of Code.

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 have not been involved with any open source projects yet.

2.5) Gaming experience - Are you a gamer?

Yes, I've played video and computer games since the Nintendo 64, and have been tabletop gaming since I got to college.

2.5.1) What type of gamer are you?

That weird type of middle ground where I'm not good enough to call myself a "hardcore" gamer, but care about gaming too much to call myself a "casual" gamer.

2.5.2) What type of games?

Mostly RPGs and strategy games (both turn based and real-time), though I dabble in most genres.

2.5.3) What type of opponents do you prefer?

I prefer opponents that are slightly better than me and friendly enough so that once the game's been decided they'll provide me with constructive criticism on my gameplay.

2.5.4) Are you more interested in story or gameplay?

I think both are important, but am more likely to play a game with flawed gameplay for a good story than vice versa (though there's a difference between a game with a flawed story and a game that doesn't bother with story and just focuses on being a game).

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'm a new Wesnoth player, having only gotten through the tutorial and most of The South Guard. In general, I lean more towards single player than multiplayer, though once I get a bit more attuned to the game through single player, I will give multiplayer a try. Most of all, though I haven't played much yet, I'm hooked, and will play a lot more by the time summer rolls around.

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 S­­V­­N (during the evaluation period or earlier) please state so.

Submitted a small patch that will mark widescreen resolutions as " (widescreen)" in the change resolution screen.(r41930)

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.

Native speaker.

3.2) What spoken languages are you fluent in?

I know Spanish grammar well enough for me to get by with somebody who can put up with me looking up vocabulary as needed.

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'm not quite sure what interacting with "other players" is like, but I've worked as an usher at a movie theater and a concert venue, and between teenage girls texting in the movie theater and middle-aged women with only lawn admission at the concert venue wanting me to throw their panties on stage for them, I think I feel comfortable saying yes.

3.4) Do you give constructive advice?

When I have constructive advice to give, I provide it. If I'm asked to provide some and I don't have any, I say that I don't.

3.5) Do you receive advice well?

I consider who is giving the advice and what the advice is, and if it makes sense to follow it, I follow it.

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

When criticism is specific enough to be useful (i.e. not along the lines of "your game sucks"), it's advice, see 3.5.

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?

I generally prefer to design things before I start coding, but there is definitely a point of design where you can implement two ideas in the time it takes to decide between them, and I generally will limit myself to 15 minutes actively thinking about a decision before either deciding, or moving on to something else and letting the decision work itself out on the backburner.

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 selected the New Alliance System idea. The largest benefit to the game of this, in my opinion, is introducing asymmetry in diplomacy, where you need to trust the other player to have given you permission to do what you want to do.

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

N/A

4.3) Why did you choose this project?

It sounds like the game would benefit from, and while my idea will almost certainly need to be refined as I become more familiar with the code base, it was the project for which a potential implementation first formed in my head.

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

"Path" for development included in proposal. Pre-summer: Refactor enemies_[] and WML to choose between old and new alliance, defaulting to old 5/24-5/30: Implement CanAttack and TakeVillages 5/31-6/6: AllowHealing 6/7-6/13: ShareShroud and ShareFog 6/14-6/20: AllowVillageTeleport and UseZOC 6/21-6/27: ShareTeamLabels and ShareTeamChat 6/28-7/4: SharedVictory 7/5-7/11: WML to have permissions locked or unlocked (New Alliance System now fully functional in scenarios where permissions are locked) 7/12-7/18: Mid-term evaluation, 7/19-7/25: GUI Work 7/26-8/1: AI Work 8/2-8/8: Extra time for clean-up, slack for unexpected difficulty, etc. 8/9-8/15: As above if necessary, but aiming for "pencil down" by 8/9

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

Technical detail included in above proposal.

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

Experience in game development and a place in what seems to be a wonderful developer community.

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

The developer community and a superb product which I would be proud to be a part of.

5) Practical considerations

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

   * Sub­­version (used for all commits)

Yes, used in internship last summer and my current class.

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

Yes.

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

No, though I'd be happy to learn.

   * Python (optional, mainly used for tools)

Yes, but with more reference to documentation than C++

   * build environments (eg cmake/autotools/scons)

Kind of iffy on writing Makefiles at the moment, but I should be better by summer.

   * WML (the wesnoth specific scenario language)

No exposure yet, looking forward to learning it.

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

No exposure, ready to learn

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

I generally use Netbeans for the languages it supports as it provides a very good IDE (though I'll admit that the auto-generation of Makefiles is the reason I didn't really learn Makefiles from my internship last summer). For the languages not supported by Netbeans, I use Emacs, though this is admittedly mostly a matter of familarity and comfort.

5.3) What programming languages are you fluent in?

C, C++, Java, Python, Scheme

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!

Not a problem at all. I'll include my phone number on the Google application.