Hi all, this is mainly for my mentor (i.e. boucman) to look at, but feel free to chime in if you have comments. As a remember my project plan is over there: http://wiki.wesnoth.org/GSoC-WesnothWhiteboard_Gabba
To summarize what this is about, I need to create the class for PlannedMove objects, and a data structure to hold them. They are destined to be sent over the network eventually, so they need to either be config objects, to wrap config objects, or to serialize to config objects. The following analysis* "Access vs Serialization"* shows how much I expect the objects will be accessed/modified versus serialized/sent over the network. In the end I decided that constantly accessing the wml, especially during heavy screen refreshes, would be too slow. So I'm going for a custom class hierarchy, unless someone can make a good argument against. In a second section *"Required Fields" *I list the properties and fields that seem to be necessary for the PlannedMove class; you can see a tentative class diagram with the most important details here: http://forums.wesnoth.org/download/file.php?id=40412&mode=view Happy reading, gabba ---------------------------- Access vs Serialization Access and other non-serialization Access 1. Access *Start/End*/*Target/Undoable/Conflict_list* often during drawing. 2. Calculate conflict info 1. access all actions after every commit 2. write to every action in conflict status 1. Modify move/attack destination 1. we could create a new action instead of modifying one 2. On changing order of moves, need to update pointers to undo stack objects Creation/Deletion 1. Add new action 2. Cancel action 3. Execute (usually deletes action) Serialization Every client serializes changes to planned actions at least every second. Every client deserializes received planned action modifications *from every other client* at least every second. Conclusion - Access vs Serialization Directly using a config doesn't seem to be the way to go, since accesses especially during display will happen much more often. A more traditional class structure will allow us to use subclassing and polymorphism. Required fields Class : plannedAction Subclasses if appropriate : - plannedMove - plannedAttack - plannedRecruit Fields : - *Type* of planned action - if we subclass, this is only for serialization - Acting *Unit* (optional, recruit doesn't have it) - *Unit type* (optional, for recruit) - *Start*/*End* location (could reuse Start for recruit location) - *Target* of attack (optional) - *List of conflicts* (not serialized): each element having : - *Conflict status* : soft, hard - *Conflict location : *at least which hexes are concerned - *Undoable* - Pointer to corresponding undo stack object (not serialized) Methods and Constructors : - plannedMove(*Unit, Start, End*) - plannedAttack(*Unit, Start, End, Target*) - plannedRecruit(*Unit_type, Location*) - getXYZ() for most fields - setEnd() [modify move/attack end position] - setConflict(conflictType, location) - removeConflict(conflictType, location) - setUndoable() - drawPath/AttackMarker/Ghost/Conflicts() - useful if we decide that every planned action draws itself
_______________________________________________ Wesnoth-dev mailing list [email protected] https://mail.gna.org/listinfo/wesnoth-dev
