well, not much to say... it works, the code looks good, that's a great first step...
here are possible next steps from here * small work on the drawing side : get a filename convention and change the hardwired image to a set of images in the arrow folder I would go for * arrow-start-n.png arrow-start-ne... for the start of arrows * arrow-n-n.png arrow-n-ne... for the middle of arrows * arrow-n-end.png arrow-ne-end... for the tips of arrows * something similar for when an arrow "breaks" due to a teleport * start working on the gameplay side of the arrow structure, * add a quick advance setting to activate arrows instead of classical undo (this way all arrow vs undo code will be marked for the day we want to handle it differently) * study how input work to see where to plug the framework * Start to think about the gameplay side of arrows would work... we can go with UML again to communicate * start the "path arrow" subclass, which should handle visibility correctly my guess is that you will need the "clean arrow" is not that important at the moment, and can be done at any time path arrows is something you'll need quite soon, but there is nothing tricky there at this point. You probably don't need much advice from me to do it, so do it "in your free time" i.e when you need to change your mind from the internal structure of the input layer :P Cheers Boucman _______________________________________________ Wesnoth-dev mailing list [email protected] https://mail.gna.org/listinfo/wesnoth-dev
