My graph system is working nicely with multiple resolutions, but I realized while working on it that I’ve essentially locked myself into having every scene the same size. While not necessarily a problem, from a design standpoint it really isn’t conducive to the type of levels I want to implement. Of course, allowing scenes to exist that are larger than the size of the screen introduces several new problems, namely:
That doesn’t seem too hard, right?
Easy stuff first: The camera is going to need to center itself between all points I tell it to focus on. All I have to do is get the average value of all positions. Fortunately this actually happened exactly as I thought it would.
Now on to zooming. Essentially, I check distance between the two focus point furthest from each other. If it’s over a certain length, zoom out. If it’s under, zoom in. Stop zooming in once the view is a certain width, so it doesn’t zoom in to eternity.
Seems simple enough, right? That’s what happens when I write up a blog post after the fact. I really should start writing these while I’m in the thick of things…
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:
std::vector< sf::Vector2f > Graph::BuildGrid()
std::vector< sf::Vector2f > Nodes;
for (float height = 20; height < 600; height += 40)
for (float width = 20; width < 800; width += 40)
sf::Vector2f Node = sf::Vector2f(width, height);
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
Obviously this is unacceptable, and really should have been fixed by now. I need a plan!
Currently the Graph class is made up of:
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.
Meander is getting to a point where everything I anticipated having problems with has been resolved, which is a pretty awesome place to be. A year ago all my projects were dying in infancy due to my lack of programming skills. Now I find myself often without a challenging problem to push through, and subsequently not knowing what to do next. It’s about time I put together an actual list of goals I want to meet so I can call this this project complete.
I’m not including assets in my definition of “complete”. Eventually I’ll have a full complement of images, maps, sounds, in-game items, etc. But to call the Meander engine finished I’ll need to implement the following features:
As I complete each item I’ll update this post with a link to the post detailing it.
Everybody loves screenshots, right? Well, I do at least, and this is my blog. So here’s a screenshot of the GUI for my game engine. I’ll have a more technical/in-depth post after I get a video done, but I wanted to put this up right away.
Ladies and gentlemen, allow me to introduce… “Gooey”!
More later. :)