Hello Custom Collision

Recently I’ve been in assigned the task of rapid prototyping, I am to complete 2 prototypes a week for a 6 week period, with each prototype having a small brief with specific items to be included.
At first, this task seemed daunting, however, I thought back to Jam Game weekend and remembered how much fun it had been and jumped on in.

Now this blog isn’t so much about this task as much as it is about what I realised as I approached each prototype, I was given the freedom to choose the tools I used as I saw fit, and as a peer of mine pointed out, I was choosing to work in Unity a lot of the time, this became very evident when I was to tasked with developing a couple of different shaders, now the easiest way of rapid prototyping shaders is most likely in UE4, simple node-based system that is essentially free, however I choose to look around and ended up buying shader forge, which is essentially the same system as UE4 but for unity, with a $90 price tag.

After reflecting on this I had become a little worried I had become too comfortable with using the one tool over and over.
I discussed this with a peer and ended up coming to the conclusion that it isn’t to big a deal to work in the same engine all the time, in fact, it reinforces consistency, however, what might not be terrible good would to get too comfortable with relying on a single API  and forget about what’s happening just a little below the surface.

To this end, I decided to go back to one of the first completed prototypes and strip out any of the Unity API, for example removing any of the Transform.translate or AddForce functions built into Unity and replacing it with my own movement code, that was relatively quick and I was actually very refreshing.

The next thing I decided remove was the Unity Collision stuff.
I started this out thinking it would be pretty quick and easy, make a circle class and a collision manager that checks collision between the circles, which is incredibly easy, HOWEVER, that’s when I realised this wouldnt be sufficient as I have a single sprite that is a long skinny rectangle projectile (think star wars style laser beam) and a circle collision would definitely not do it justice.
I thought about rewriting the whole thing to run on boxes, but decided that if I’m going to rewrite it I might as well make it more robust over all, so I consulted with someone a little more experienced then myself and they suggested I look at the GJK distance algorithm, this is a method of checking the distance between two sets of convex sets, so it doesn’t so much matter what the shapes are you can still test to see what the distance between them are.
Now I’ve seen this before but I have never used it or implemented it myself, which got me a little excited!

So in the next couple days I will continue work on this GJK based collision system and hopefully it will go well, once it is complete I will do a follow up post talking about how I went about it.


Pathfinding Fun

Over the last month, my focus has been on a pathfinding algorithms.
For The final assessment of the year at University, we were tasked with a project of our choice.
My peers choose to work on a variety of interesting ideas and mechanics, and it was exciting to see everyone exploring new programming ideas and methods.
I decided I wanted to learn more about pathfinding, for a couple reasons, one of which being that I have a deep and burning passion for point and click adventure games and have always wanted to know how the walk boxes and movement systems work in those games, the other reason being that I have an interest in video game AI and smooth and natural looking pathfinding is extremely imperative for good game AI.

So, where do I start?
Well, I started reading as much info as I could about the different types of pathfinding commonly used and what their best use cases are, very quickly it became very apparent that, like most things in programming, there are many many different approaches to pathfinding and many many different ways to implement the same algorithms.

So I decided to go with a classic, the “Hello world!” of pathfinding if you will, A*.
A* is relatively simple and effective, it’s not entirely the most efficient but it’s not bad overall.
Now I’m not going to try and explain how A* works, there are much better explanations out there on the web, all you need to know is that my take on it cuts the world up into a grid of “nodes” which hold some values that the A* can use to compare nodes to each other to determine if a node is closer or further away from the destination, I’ll show you the summary I have written up the top of my node class.

It also contains a bool that determines if that node is “walkable”, which determines if it can be used in the path or not, if it’s not the algorithm will ignore that node and build the path around it, hence that actual pathfinding part.
From here it’s as easy as finding the start node, in this case being the player’s position, and the end node, which is a position in the world collected on mouse click (ignoring the Y axis),
then the A* does its thing and compares all the nodes between the start and end node and finds the nodes with the lowest overall cost (f cost), and places them in a list (I’ll talk about lists another time) which then makes up the path.

here’s and example of the grid

The algorithm checks the layer mask of objects and if they are solid it will turn the nodes that the object occupies to “unwalkable”, turning it red and unable to be used in the path.

Ok I’ve rambled enough, I’ll bore you with more details soon.

Thanks for reading!