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.