Fixing the graph – planning stage

Goal number the last on my roadmap reads: “Decoupling the navigation mesh from specific window sizes”. What on earth does that mean? I’m glad you asked.

Thus far I’ve been programming and debugging my program using a fixed-size window at 800 by 600 pixels. Unfortunately, when I wrote my Graph implementation I was all about magic numbers and not so much about planning for the future. Consider the following code snippet:

At some point I got it into my head to store exact locations in the graph. Now, there’s not anything necessarily wrong with this…as long as

  • I never need to change the window size or resolution
  • The view never changes

Obviously this is unacceptable, and really should have been fixed by now. I need a plan!

Currently the Graph class is made up of:

  • The Walkable list; a set of integers acting as boolean (0/1) variables (see here for why a vector is A Bad Thing)
  • The Node list; a set of Vector2s for positioning objects
  • The State list; a set of rectangles used to map mouse positions to nodes

Looking at this I realized that I really don’t need Nodes or States to be in there. After all, my pathfinder’s solver function only takes two numbers as arguments; the grid indices for the start and end of the path. At each step of the path, the pathfinder accesses the Node list with that step’s index and returns the position. I can easily strip this out and replace it with a simple function to convert a graph index to a Vector2. I’ll need a mesh to determine where on the screen the mouse clicks to signal the start of a pathfinding call, but I can most likely construct this on the fly.

No more delays. Time to get this done.

2 thoughts on “Fixing the graph – planning stage

  1. Pingback: Resolution independence »

  2. Pingback: Building a better pathfinder »

Leave a Reply

Your email address will not be published. Required fields are marked *