Alright Boucman, here's my plan for friday and next week: 1. Create an svn branch and track it with git-svn. I spend a lot of time today learning git and git-svn, and the learning curve is steep, so I'm not sure how much of friday is gonna be eaten by this. (Example: I wanted to have separate git working directories for tracking trunk and 1.8, without constantly switching between those and doing a rebuild. And without copying the whole 1.7 GB for nothing. Turns out there are several badly-documented ways to do this, but finding the little git-provided script that does it in an efficient way took way too much searching.)
2. Start on the "multiple fake units" small coding task. Once that's started, I'll dcommit to the svn branch regularly so you can see my progress, once a day is a good target I think. Can I use simply the location of the fake unit as the "key" to find it, or do I need to support multiple fake units per hex? 3. As soon as the feature is pretty complete, (carefully) merge back the branch into trunk with the help of git-svn. I'll try to finish this by wednesday. 4. Implement the arrow drawing engine/framework; at Crab's demand I'll make it pretty generic and accessible from anywhere in the program, so that anybody can create arrows with a specific style, get a pointer to them (do you suggest some smart Boost pointer for this?), modify them and eventually delete them. The point is that after you've added them, they're added to the right layer at the right time and you needn't worry about the details. It may make sense to make displaying fake units available in a similar way, I'll know more about the specifics when I'll have implemented them. 5. Implement PlannedActionSet (with an exposed deque ;) ); the PlannedAction class will at first contain just enough info to define arrows. Then use the arrow-drawing framework to display those and follow updates to the planned moves. You'll probably be back before I finish point #5 since I'll have my summer course at the same time. 2010/4/28 jeremy rosen <jeremy.ro...@enst-bretagne.fr> > 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 >
_______________________________________________ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
