This all sounds good, i agree with your conclusion wrt data structures vs config.
I'll post a few comments about the data structures themselves note that these are general comments on some things you might not have thought of yet, or not put in your diagram for simplification purpose. If that the case, that's perfectly fine just tell me so PlannedActionSet * to have a getChanges, you need to somehow know "since when" either as a param to getChange or an internal data from the Planned ActionSet => this is probably a "not looking at the details of network management yet" problem, and I totally agree with that * std::vectors have much more than just get and set actions, stuff like iterators are very handy... will the internal vector be exposed ? or do you plan to reimplemnt the iterator routines (drawing will need to iterate on the vector) an other way to do it would be to inherit from vector instead of having an internal one (or simply use a vector without any wrapping if none is needed) ConflictSet *same question about std::vector Planned* *you probably want an inherited draw() routine rather than all sorts of drawGhost,drawPath, thus you would just have to iterate on the PlannedActionSet to do the drawing. This draw will probably take a hex as parameter (the hex to redraw) (just mentionning that last point since you havn't put your function params in) *related : some of your classes should probably contain some cached pathfinding results *i'm at work so I can't check, but if units contain their own position, you don't need to store the start position on a move *if they don't contain their start position, then you should probably store the targeted hex in the PlannedAttack rather than the targeted unit (maybe both) Conflict * I assume that "type" will become an enum at some point, once we have a good idea of all the types of conflict. Will their be some class hierarchy of conflict types ? SMALL CODING TASK : MULTIPLE FAKE UNITS this is a task that you will need, which is independant of your project, and that you can commit directly to mainline once done. It will also help you get familiar with the display engine The game has a hard limit of one and only one unit per hex. However, there are cases where we need to draw more than one unit in a given hex (typically when a unit moves through an occupied hex) To do that, the display engine (in the display or game_display class, i'm not sure) keeps a unit object and a location object, which represent the "fake unit" it basically says "there is an extra unit in hex XX" the problem is that the engine directly keeps a single unit that way, which means that there can only be a single fake unit With your ghosted units, you will need to draw more than one of these units, so your task is to allow the engine to have multiple such units, probably using a set of pair<unit,loc> or something like that keep in mind that you will need a "key" to somehow allow people to find their fake unit within the multiple units we'll discuss this whenever we meet on IRC, but you can have a look right away _______________________________________________ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
