On Fri, Apr 30, 2010 at 9:03 AM, Gabriel Morin <gabrielmo...@gmail.com> wrote: > 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.) >
ok, fair enough, > 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? > i'm afraid you do, for instance if a unit moves through a hex occupied by a shadow unit, we would have two fake units in the same hex during the crossing > 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. > ok, sounds good > 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?), hmm, I hadn't thought of doing a "generic arrow drawing" code... sounds like a good idea, vocabulary : * owner : the code that knows what the arrow is for and is asking the engine to draw it here are a couple of thoughts on the subject 1) smart-pointer or not, that's an implementation detail, so why not. Let's see if that's what we need. We will find a sort of "key" for the owner of the arrow to be able to find back his arrow in order to modify/delete it, and smart pointer is a way to do it... 2) at what logical level do you want your arrows to be... if it's unit+src+dst then the pathfinding is under the responsability of the arrow engine. That makes a simpler usage for the owner, but limits what the owner can do to describing unit movements only if you register "an array of hex" then you will have problems with arrow continuity and things like that... 3) it would be tempting to expose the arrow engine to WML at some point. Which means we would need to define a bit more what is an arrow style, is it limited to recoloring ? can you provide a whole new set of arrow image, in which case you need to add and parse the WML to find these images somewhere... 4) what about "special places" like teleports in arrows > 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. > not sure what you mean... the fake unit is already available to anybody... the problem is that it's very limited, but it's already used by multiple owners. but yes, the fake unit should stay available in a generic way > 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. > indeed. I will probably be. Take some time to think a clean API for your arrow engine, it is indeed a usefull subproject, and merging keeping it cleanly separated from the underlying whiteboard is a good thing > 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 > > _______________________________________________ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
