- Creator of the fan game Donkey Kong Country 4: The DK Bay - Working solo on my new game Death's Doorstep - Man of many hats - Canadian

Report RSS Fighting the sytem

Posted by on

So for whatever reason I decided to use Unity for my 2D sidescroller. I'm at the point now where I don't at all regret this decision, but thats because I'm not really using Unity the way it's built for. I was given a development application which handled all of the basic engine fundamentals like frame updates, rendering and physics. The only problem was that I didn't care about having any of that stuff. I've built my own game and physics engines for years and I wanted to have the same control over what was happening as I always did.

So what did I do? I fought Unity as hard as I could. I realized early on that I wanted a level of control over the basics of the engine that I was using, which I may not have been able to get had I used the Unity defaults.

Unity is heavily used as a 3D engine because that's what it was built to be. Despite that there are a lot of people who use it to make 2D games. When I was initially looking into building a 2D game for it I had done a bunch of research looking for the most efficient/easy way to render sprite animations. The best thing which I found at that time was the 2DToolkit. I'm not going to go in depth with my opinions with this right now, since I don't even know whether I'll end up using it for the final game (We still haven't decided between 2D sprites or 3D models). I will say though, that while it is good, it is definitely not perfect. I've also heard more recently that there are more alternative solutions for 2D rendering in Unity nowadays, so if your looking for something, I'd say do some research first.

The most important piece of my engine, which I am very happy I did not use the Unity solution for, is the physics portion. It's designed to be heavily modifiable/tweakable, and since I've built it from scratch, there is no bloat (yet). I was able to focus on the things that I thought I needed for level design and remove the elements that I found useless. Granted, I probably could have modified the Unity physics to work the way I wanted to; but, I thought the time tradeoff for that would've have been greater then building it from scratch on my own. Below you can see a wireframed version of our game engine. The red lines represent platforms, the cyan lines represent the mask of collision objects:

Foo Engine Screenshot

Forget ignorance, simplicity is bliss.


The biggest thing that I can take away from all this, having already made the physics engine, is the fact that it is so simple to modify now. Whereas going through Unity documentation can get to be a timesink and a hassle, I don't have to do any of that for my own code. I'm the one who understands how it works and it takes me significantly less time to edit or expand because of that. Yesterday alone I added the ability to walk on slopes, something that I was avoiding because it made my past games more glitchy. Instead, it went very smoothly this time around and, while I can't call it glitch free at this point yet, I haven't found any glitches in it. So now I've already implemented most of the basic elements that I need for the game, which means that I can spend most of my time fully focused on the level design. Personally I think this will have a positive effect on the quality of my level design in the long run.

Post a comment

Your comment will be anonymous unless you join the community. Or sign in with your social account: