SoC Ideas Whiteboard Backend Refactoring 2012 - Revision history

Esr: Remove Subversion-specific terminology

2013-03-21T04:06:02Z

Remove Subversion-specific terminology

Crab: /* Description */

2012-04-05T12:05:51Z

‎Description

Gabba: /* Related refactoring concerns */

2012-04-02T08:23:04Z

‎Related refactoring concerns

Gabba: /* Related refactoring concerns */

2012-03-30T02:42:06Z

‎Related refactoring concerns

Gabba: /* Related refactoring concerns */

2012-03-30T02:41:24Z

‎Related refactoring concerns

Gabba: /* Related refactoring concerns */

2012-03-30T02:40:11Z

‎Related refactoring concerns

Gabba: /* Additional Information */

2012-03-30T01:51:54Z

‎Additional Information

Gabba: /* Combining the mapbuilding and action verification */

2012-03-30T01:29:22Z

‎Combining the mapbuilding and action verification

Ejls: Correction of category

2012-03-20T20:49:57Z

Correction of category

Gabba: /* Whom to ask about this */

2012-03-20T02:15:29Z

‎Whom to ask about this

@@ Line 31: / Line 31: @@
 The whiteboard planning system can show you things like possible enemy moves "in the future", after you've moved your units to the planned positions. To achieve this, it builds an internal future state by taking the orders of the player and applying them to the game state in the correct order, a process we call "mapbuilding".
-The issue here is that we also have a separate "verification" of said orders to make sure they are possible. This is used everytime the game state might have changed outside of the whiteboard's control, or whenever the player deletes one of his planned actions, and so on. For historical reasons this is separate from mapbuilding, which is a problem since we end up with a lot of duplicate code (for instance compare whiteboard/move.cpp line 369 and whiteboard/validate_visitor.cpp line 87 as of svn revision 53682, both do a unit map find to check for the unit's presence), and since they don't handle actions spread over multiple turns consistently.
+The issue here is that we also have a separate "verification" of said orders to make sure they are possible. This is used everytime the game state might have changed outside of the whiteboard's control, or whenever the player deletes one of his planned actions, and so on. For historical reasons this is separate from mapbuilding, which is a problem since we end up with a lot of duplicate code (for instance compare whiteboard/move.cpp line 369 and whiteboard/validate_visitor.cpp line 87 as of 2012-03-28 14:15:50 -0400, both do a unit map find to check for the unit's presence), and since they don't handle actions spread over multiple turns consistently.
 Another issue is that we often do a full search of the planned actions for various purposes, which is not optimal.

@@ Line 1: / Line 1: @@
 {{Template:SoC2012Idea}}
 = Description =
-<h2>Whiteboard: Refactor the backend</h2>
+<h2>Whiteboard: Refactor the backend [1]</h2>
 Page for the idea: [[SoC Ideas Whiteboard Backend Refactoring 2012]]

@@ Line 45: / Line 45: @@
 * ''Friend classes vs everything in the action classes'': We kind of have a mix of two approaches, one where the action object does the operations itself (mapbuilder calls the action's apply/remove_temp_modifier() ) and one where a friend class does all the work to keep the action classes smaller (validator is friend to all actions and I think it still accesses some of their fields directly). Consider whether moving completely to either approach makes sense.
-* ''Unit pointer recovery uniformization'': The whiteboard uses a mix of approaches to recover pointers to units that actions are related to. One that's very common in the rest of the game code is doing a unit map search on the hex the unit is supposed to be in (which we never know after any kind of game even took place, WML scenario code can erase and replace units at will). See for instance wb::move::apply_temp_modifier(). Another, more recent approach is to store and use the unit's underlying ID and use that to recover the unit pointer from the unit map. See wb::move::get_unit() for that approach. Leftovers of other approaches may exist. Evaluate which of the current approaches make the most sense, stress test it with unit tests, and uniformize unit access where possible.
+* ''Unit pointer recovery uniformization'': The whiteboard uses a mix of approaches to recover pointers to units that actions are related to. One that's very common in the rest of the game code is doing a unit map search on the hex the unit is supposed to be in (which we can't be certain of after any kind of game event took place, WML scenario code can erase and replace units at will). See for instance wb::move::apply_temp_modifier(). Another, more recent approach is to store and use the unit's underlying ID and use that to recover the unit pointer from the unit map. See wb::move::get_unit() for that approach. Leftovers of other approaches may exist. Evaluate which of the current approaches make the most sense, stress test it with unit tests, and uniformize unit access where possible.
 * ''boost::dynamic_pointer_cast vs simple numeric id'': we use dynamic_pointer_cast quite a bit, which is known to have quite an overhead. Our action class hierarchy is pretty small and is not gonna change a lot in the foreseeable future. Evaluate whether using some numeric type IDs such as wb::action::MOVE, wb::action::RECRUIT and so one combined with static pointer casts when appropriate would be better.

@@ Line 43: / Line 43: @@
 ==Related refactoring concerns==
-* Friend classes vs everything in the action classes: We kind of have a mix of two approaches, one where the action object does the operations itself (mapbuilder calls the action's apply/remove_temp_modifier() ) and one where a friend class does all the work to keep the action classes smaller (validator is friend to all actions and I think it still accesses some of their fields directly). Consider whether moving completely to either approach makes sense.
+* ''Friend classes vs everything in the action classes'': We kind of have a mix of two approaches, one where the action object does the operations itself (mapbuilder calls the action's apply/remove_temp_modifier() ) and one where a friend class does all the work to keep the action classes smaller (validator is friend to all actions and I think it still accesses some of their fields directly). Consider whether moving completely to either approach makes sense.
-* Unit pointer recovery uniformization: The whiteboard uses a mix of approaches to recover pointers to units that actions are related to. One that's very common in the rest of the game code is doing a unit map search on the hex the unit is supposed to be in (which we never know after any kind of game even took place, WML scenario code can erase and replace units at will). See for instance wb::move::apply_temp_modifier(). Another, more recent approach is to store and use the unit's underlying ID and use that to recover the unit pointer from the unit map. See wb::move::get_unit() for that approach. Leftovers of other approaches may exist. Evaluate which of the current approaches make the most sense, stress test it with unit tests, and uniformize unit access where possible.
+* ''Unit pointer recovery uniformization'': The whiteboard uses a mix of approaches to recover pointers to units that actions are related to. One that's very common in the rest of the game code is doing a unit map search on the hex the unit is supposed to be in (which we never know after any kind of game even took place, WML scenario code can erase and replace units at will). See for instance wb::move::apply_temp_modifier(). Another, more recent approach is to store and use the unit's underlying ID and use that to recover the unit pointer from the unit map. See wb::move::get_unit() for that approach. Leftovers of other approaches may exist. Evaluate which of the current approaches make the most sense, stress test it with unit tests, and uniformize unit access where possible.
-* boost::dynamic_pointer_cast vs simple numeric id: we use dynamic_pointer_cast quite a bit, which is known to have quite an overhead. Our action class hierarchy is pretty small and is not gonna change a lot in the foreseeable future. Evaluate whether using some numeric type IDs such as wb::action::MOVE, wb::action::RECRUIT and so one combined with static pointer casts when appropriate would be better.
+* ''boost::dynamic_pointer_cast vs simple numeric id'': we use dynamic_pointer_cast quite a bit, which is known to have quite an overhead. Our action class hierarchy is pretty small and is not gonna change a lot in the foreseeable future. Evaluate whether using some numeric type IDs such as wb::action::MOVE, wb::action::RECRUIT and so one combined with static pointer casts when appropriate would be better.
 ==Playtesting==

@@ Line 43: / Line 43: @@
 ==Related refactoring concerns==
-* We kind of have a mix of two approaches, one where the action object does the operations itself (mapbuilder calls the action's apply/remove_temp_modifier() ) and one where a friend class does all the work to keep the action classes smaller (validator is friend to all actions and I think it still accesses some of their fields directly). Consider whether moving completely to either approach makes sense.
+* Friend classes vs everything in the action classes: We kind of have a mix of two approaches, one where the action object does the operations itself (mapbuilder calls the action's apply/remove_temp_modifier() ) and one where a friend class does all the work to keep the action classes smaller (validator is friend to all actions and I think it still accesses some of their fields directly). Consider whether moving completely to either approach makes sense.
-* The whiteboard uses a mix of approaches to recover pointers to units that actions are related to. One that's very common in the rest of the game code is doing a unit map search on the hex the unit is supposed to be in (which we never know after any kind of game even took place, WML scenario code can erase and replace units at will). See for instance wb::move::apply_temp_modifier(). Another, more recent approach is to store and use the unit's underlying ID and use that to recover the unit pointer from the unit map. See wb::move::get_unit() for that approach. Leftovers of other approaches may exist. Evaluate which of the current approaches make the most sense, stress test it with unit tests, and uniformize unit access where possible.
+* Unit pointer recovery uniformization: The whiteboard uses a mix of approaches to recover pointers to units that actions are related to. One that's very common in the rest of the game code is doing a unit map search on the hex the unit is supposed to be in (which we never know after any kind of game even took place, WML scenario code can erase and replace units at will). See for instance wb::move::apply_temp_modifier(). Another, more recent approach is to store and use the unit's underlying ID and use that to recover the unit pointer from the unit map. See wb::move::get_unit() for that approach. Leftovers of other approaches may exist. Evaluate which of the current approaches make the most sense, stress test it with unit tests, and uniformize unit access where possible.
 * boost::dynamic_pointer_cast vs simple numeric id: we use dynamic_pointer_cast quite a bit, which is known to have quite an overhead. Our action class hierarchy is pretty small and is not gonna change a lot in the foreseeable future. Evaluate whether using some numeric type IDs such as wb::action::MOVE, wb::action::RECRUIT and so one combined with static pointer casts when appropriate would be better.

← Older revision		Revision as of 02:40, 30 March 2012
Line 46:		Line 46:

	* The whiteboard uses a mix of approaches to recover pointers to units that actions are related to. One that's very common in the rest of the game code is doing a unit map search on the hex the unit is supposed to be in (which we never know after any kind of game even took place, WML scenario code can erase and replace units at will). See for instance wb::move::apply_temp_modifier(). Another, more recent approach is to store and use the unit's underlying ID and use that to recover the unit pointer from the unit map. See wb::move::get_unit() for that approach. Leftovers of other approaches may exist. Evaluate which of the current approaches make the most sense, stress test it with unit tests, and uniformize unit access where possible.		* The whiteboard uses a mix of approaches to recover pointers to units that actions are related to. One that's very common in the rest of the game code is doing a unit map search on the hex the unit is supposed to be in (which we never know after any kind of game even took place, WML scenario code can erase and replace units at will). See for instance wb::move::apply_temp_modifier(). Another, more recent approach is to store and use the unit's underlying ID and use that to recover the unit pointer from the unit map. See wb::move::get_unit() for that approach. Leftovers of other approaches may exist. Evaluate which of the current approaches make the most sense, stress test it with unit tests, and uniformize unit access where possible.
		+
		+	* boost::dynamic_pointer_cast vs simple numeric id: we use dynamic_pointer_cast quite a bit, which is known to have quite an overhead. Our action class hierarchy is pretty small and is not gonna change a lot in the foreseeable future. Evaluate whether using some numeric type IDs such as wb::action::MOVE, wb::action::RECRUIT and so one combined with static pointer casts when appropriate would be better.

	==Playtesting==		==Playtesting==

@@ Line 18: / Line 18: @@
   |suppresserrors=true
   |noresultsheader=''There are no student proposals for this idea''
-  |category=Summer of Code 2012 Student Page&SoC Ideas AI Defense Strategies 2012
+  |category=Summer of Code 2012 Student Page&SoC Ideas Whiteboard Backend Refactoring 2012
   |notcategory=SoC 2012 Not Submitted To Google
   |include=#Description

← Older revision		Revision as of 02:15, 20 March 2012
Line 63:		Line 63:

	=Whom to ask about this=		=Whom to ask about this=
		+
		+	[[User:Gabba\|Gabba]]
		+
	gabba on irc. If I'm hard to reach you can also find my email in the game's source files (if you're gonna make the effort to find it, I can make the effort to read your mail ;) ).		gabba on irc. If I'm hard to reach you can also find my email in the game's source files (if you're gonna make the effort to find it, I can make the effort to read your mail ;) ).