   Turn-Based strategy game - need some help
  Hi, my name is Vincent, and I've been learning C++ on/off for the lasts 3 years.I'm getting really comfortable with OOP now, but still have problems with advanced use of pointers.Here a link to the previous thread:http://www.gamedev.net/community/forums/topic.asp?topic_id=509499I'm doing this project to learn more about c++, even if it's not going far, I'd have learned something :)I'm still working on that game, and so far, it's going REALLY good, I've got alot of stuff coded up, except some advanced algorithms (like pathfinding)I've been working really hard lately to understand A*, I believe I now understand the basics of it, and I'm able to adapt it to my needs; witch are; when I click a unit, I need to calculate the movements it can do (cost to get to X tile)I've achieved it coding it from 0, and I'm sort of proud, but I'm using vectors and others stuff, that I think, needs optimizing.http://pastebin.com/m6b3926ceRight, so this so far, is all what I got to find accessible tiles. The code is not so well documented, but I think it's pretty straightforward?Can anyone tell me what would need to be optimized in that?Thanks for any help,-Vincentedit: yes this still need some works because of the vectors of pointers, the node are not deleted, but I think vectors aren't even well suited for this..   
Quote:Original post by agashkaHi, my name is Vincent, and I've been learning C++ on/off for the lasts 3 years.I'm getting really comfortable with OOP now, but still have problems with advanced use of pointers.Ah, it's been a while. ;)Quote:I've been working really hard lately to understand A*, I believe I now understand the basics of it, and I'm able to adapt it to my needs; witch are; when I click a unit, I need to calculate the movements it can do (cost to get to X tile)You don't need a pathfinding algorithm for that, but a fill algorithm. One that stops filling after a certain 'distance' (e.g. when the cost for a next tile becomes too high). Just saying, because they're a little different.Quote:I've achieved it coding it from 0, and I'm sort of proud, but I'm using vectors and others stuff, that I think, needs optimizing.Do you think so, or do you know so? That is, does this code run fast enough? It probably does, so why bother optimizing something that's not causing trouble? Either way, run some tests to see if it's fast enough for your game. Don't optimize things based on gut feelings (unless those feelings are based on experience, and even then, profile first).When looking through the code, I see some issues, mostly usability issues. You're not doing much with OO here, but it could be helpful in certain places. For example, the Node struct: why do you manually fill it's variables, instead of giving it a constructor? Why do you check if two nodes have the same coordinates, while a Node struct could provide a member function for that?Also, how do you plan to reuse the current code for, say, maps of a different size? How would you deal with multiple pathfinding/fill requests? Currently, you've used a bunch of global variables, but these could easily be put in a class (called, say, Pathfinder). The map internals can be tucked under a Map interface that exposes functions such as GetTile(int x, int y) and Width() and Height(), or perhaps a IsValid(int x, int y). How exactly that Map stores it's internal map data is not important for the pathfinding algorithm, as long as it has some way to figure out the cost of a tile.Now, finding a path is a matter of creating a (local) Pathfinder instance, passing it a pointer/reference to the Map you're using, and telling it to go find all tiles that can be reached for a given maximum cost. The Pathfinder constructor can then take care of cleaning up any leftover resources. You're now able to find (and store the results of) multiple paths/areas when you need to.As for vectors, why wouldn't you use them here? Yes, you're not cleaning up any Nodes, which is a problem, but that's easily fixed (just delete them before erasing them from the closed list).As for actual pathfinding, with a few small modifications, you can easily reuse these checks to find the actual paths that units should take once you specify their destination. By storing a pointer to a node's parent (that would be the previous node in a path), you can trace the route from any given node back to the start. This means you don't have to find a path anymore once the player has given a move order.   ;  A*; given a starting state A, an end state B, a mutator that given an input state produces a (cost, state) pair for each reachable adjacent state, and a heuristic that estimates the cost from any state to the state B, find a sequence of states (A, p1, p2 ... pn, B) which is traversable, or answer "impossible".Floodfill; given a starting state A, initial budget B, and a mutator that given an input state produces a (cost, state) pair for each reachable adjacent state, find the lowest-cost answers for all states within budget of A.They're similar, I'll grant, but one is a path finder, while the other is a path explorer. One has a goal, the other has merely a limit.   ;  Wyrframe: Well.. I managed to do a floodfill with a A* tutorial then :DCaptain P:"Do you think so, or do you know so? That is, does this code run fast enough? It probably does, so why bother optimizing something that's not causing trouble? Either way, run some tests to see if it's fast enough for your game. Don't optimize things based on gut feelings (unless those feelings are based on experience, and even then, profile first)."My code (running on SDL) is getting a bit like molasses... It needs optimizing big time (any software to detect slow code or w/e?)First optimization I did , was to replace the closed list with a 2D array, so it doesn't have to iterate the vector anymore."When looking through the code, I see some issues, mostly usability issues. You're not doing much with OO here, but it could be helpful in certain places. For example, the Node struct: why do you manually fill it's variables, instead of giving it a constructor? Why do you check if two nodes have the same coordinates, while a Node struct could provide a member function for that?"My bad... When I'm about to code 'big chucks' of code, I often start a new project from scratch on VC++, code the damn thing, modify it to OOP, then merge it with my project, the compile time is faster, and I don't get to break my working code. It's fully OOP now. But yeah, a member function of the node to check the coords."Also, how do you plan to reuse the current code for, say, maps of a different size?"I... don't really have plans for that now, since I know 2D dynamics array are a bitch..."The map internals can be tucked under a Map interface that exposes functions such as GetTile(int x, int y) and Width() and Height(), or perhaps a IsValid(int x, int y). How exactly that Map stores it's internal map data is not important for the pathfinding algorithm, as long as it has some way to figure out the cost of a tile."The pathfind (name of the class atm) constructor takes a reference to a MapData instance, witch has access to the map data. That approach seems okay."As for actual pathfinding, with a few small modifications, you can easily reuse these checks to find the actual paths that units should take once you specify their destination. By storing a pointer to a node's parent (that would be the previous node in a path), you can trace the route from any given node back to the start. This means you don't have to find a path anymore once the player has given a move order."sounds right, but I'm gonna focus on something else, now that I got that big peice of code coded down, I'm pretty happy of the progress. I'm gonna try to complete the units, building, and map object. Now that the base is coded up, the rest should be really easy!I also need to clean up my game loop, it's getting really REALLY _R_E_A_L_L_Y_ messy because of SDL.   