The final piece of the puzzle! We built up a nice navigation graph with ledge run-offs, one-way platforms and various types of jumps. We can query the data using our graph search algorithm and get back a path from our agent to the goal. Now we need to put that path to use and make our agent follow it.
In the previous 3 parts of this series, we built up a knowledge of graph search algorithms and started to generate our platformer pathfinding graph. In this post we will add jump connections to the graph.
This part will expand upon the last by adding cross-platform edges for our AI agent to traverse. We are going to continue handling all of our Node and edge creation at runtime so that our pathfinding solution is flexible and can work with procedurally generated content. It should be noted that you can of course do all of the graph creation at build time as well as long as your levels are not procedurally generated.
In part 1 of the series we basically just laid down the details of graph search algorithms. In the process, hopefully we learned that they are not something to be feared and are in fact quite simple in most cases. With that out of the way we are all clear to start digging into the actual pathfinding.
The amount of information on the web about 2D platformer pathfinding is dismal. This blog post series aims to fill the gap and provide enough information in enough detail to get you up and running. Part 1 will cover some required background information, mainly graph search algorithms.
This two part series will go over the details of handling tile map collisions. For some reason, there really aren't any good, generic guides on the web that detail tile map collisions despite all the games out there that utilize tile maps. Today that changes.
The rendering pipeline in Nez aims to be simple to use but still cover all possible use cases. If you are just whipping up a quick demo everything you need will most likely be already included in Nez. Once you start getting into some more advanced effects you can take control of things and render as you see fit.
Update: Nez has officially been released! You can get it on GitHub.
If you have followed along with the 2D framework evaluation posts you will already know how we ended up here. Nez is the result of this journey. Nez aims to be a lightweight 2D framework that sits on top of MonoGame. It provides a solid, but flexible base to work with that's easy enough for beginners but customizable to the core for pros.
Here we are in the final 2D framework evaluation post. It shouldn't come as too much of a surprise that I angered a bunch of people with this series. Even though several times it was stated that all of these posts were my personal opinion and that yours will vary, certain individuals still decided to send me hate mail because I didn't like their favorite game engine. My apologies for laughing at your ridiculous emails. Hate mail from a proper zealot always makes me chuckle.
Making the Cut
Now that the trash bin is overflowing with plenty of capable game engines that just aren't for me what's left? At this point in my evaluation something really odd kept coming up over and over again. A few of the engines that made it this far (and some that didn't such as Stencyl and Kha) seemed to share a commonality: they use the Haxe programming language. This was a big red flag for me initially. Let's take a quick aside here to explain a few things that I learned about Haxe before moving forward.