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 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.
In Unity by default, there is an 'Update()' function which gets called for each game object when there is a frame update. Unfortunately, there was no way for me to control which order the objects would be updated in. I didn't like this as there are a few cases where I want a specific game object to run its logic before, let's say, the main character. So how did I fix this? I decided to have only one game object use the 'Update()' function and had it call a 'Step()' function for all of the registered game objects. For anyone who has ever used Game Maker, this terminology may seem oddly familiar, I wonder why? By adding a priority queue for each game object type, I was able to fully predict when each object would be updated for each iteration of the main game loop.
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:
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.