GSoC: Endercoaster - Revision history

Esr: Hide historical instance of "SVN" from mediawiki search to avoid false positives.

2013-03-20T20:03:54Z

Hide historical instance of "SVN" from mediawiki search to avoid false positives.

Crab: /* SoC Application */

2010-04-09T22:06:39Z

‎SoC Application

Ivanovic: add link to SoC application

2010-04-09T08:41:28Z

add link to SoC application

Crab at 19:24, 8 April 2010

2010-04-08T19:24:41Z

Endercoaster: /* Questionnaire */

2010-04-06T21:48:42Z

‎Questionnaire

Endercoaster: /* Extended Description */

2010-04-06T21:41:24Z

‎Extended Description

Crab: /* Description */

2010-04-06T21:35:10Z

‎Description

Endercoaster: /* Questionnaire */

2010-04-06T21:29:52Z

‎Questionnaire

Endercoaster: /* Description */

2010-04-06T21:04:07Z

‎Description

Endercoaster: /* Quick Definitions */

2010-04-06T00:24:36Z

‎Quick Definitions

@@ Line 96: / Line 96: @@
 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.
-<h4>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.</h4><br>
+<h4>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&shy;&shy;V&shy;&shy;N (during the evaluation period or earlier) please state so.</h4><br>
 Submitted a small patch that will mark widescreen resolutions as " (widescreen)" in the change resolution screen.(r41930)
@@ Line 163: / Line 163: @@
 <h4>5.1) Are you familiar with any of the following tools or languages?</h4><br>
-     * Subversion (used for all commits)
+     * Sub&shy;&shy;version (used for all commits)
 	Yes, used in internship last summer and my current class.
      * C++ (language used for all the normal source code)

@@ Line 39: / Line 39: @@
 =SoC Application=
-[http://socghop.appspot.com/gsoc/student_proposal/review/google/gsoc2010/endercoaster/t127077880000 t127077880000]
+[http://socghop.appspot.com/gsoc/student_proposal/review/google/gsoc2010/endercoaster/t127077880000 Endercoaster-New Alliance System]
 =Questionnaire=

@@ Line 37: / Line 37: @@
 =IRC=
 endercoaster
 =Questionnaire=

@@ Line 1: / Line 1: @@
-{{SoC2010Student}}
+{{SoC2010Student_2|endercoaster|SoC Ideas New Alliance System}}
 [[Category:SoC Ideas New Alliance System]]
 =Quick Definitions=

@@ Line 136: / Line 136: @@
 Pre-summer: Refactor enemies_[] and WML to choose between old and new alliance, defaulting to old
 /24-5/30: Implement CanAttack and TakeVillages
-/31-6/6: AllowHealing and AllowLeaders
+/31-6/6: AllowHealing
 /7-6/13:  ShareShroud and ShareFog
 /14-6/20: AllowVillageTeleport and UseZOC

@@ Line 17: / Line 17: @@
 *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.

@@ Line 8: / Line 8: @@
 =Description=
 <h4>Endercoaster-New Alliance System</h4>
-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). The permissions stored will be:
+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).
 *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?)

@@ Line 131: / Line 131: @@
 then".</h4><br>
 "Path" for development included in proposal.
-Roughly speaking, I plan to refactor to an array before GSoC begins, Spend the time up until the mid-term evaluation doing the stuff other than the AI, and the time from the mid-term evaluation until the end doing AI.
+Pre-summer: Refactor enemies_[] and WML to choose between old and new alliance, defaulting to old
 <h4>4.5) Include as much technical detail about your implementation as you can</h4><br>

@@ Line 18: / Line 18: @@
 *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: This explanation is an assumption on how team chat works which will be confirmed or corrected when I play multiplayer)
+*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: TODO: Figure out what team labels are.
+*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.

@@ Line 2: / Line 2: @@
 [[Category:SoC Ideas New Alliance System]]
 =Quick Definitions=
-Permission: A particular alliance rule.
+Permission: A particular alliance rule.<br>
-Active Player: The player who is setting alliance permissions (or equivalent if alliance settings locked)
+Active Player: The player who is setting alliance permissions (or equivalent if alliance settings locked)<br>
 Passive Player: The player who the active player is setting permissions with regards to.