Grand Strategy: Space War - "Mercenaries" -- Unity
For the longest time, I was hesitant to use Unity. Truth is, I'm not a big fan of editors: I generally feel I don't have sufficient control over what I'm trying to achieve, and this can be quite frustrating.
That being said, not meeting desired velocity can be equally (if not more) frustrating however, and after several months of Dart development, I ended up looking up Unity.
My research led me directly to the Unity tutorials, where I've seen absolutely gorgeous entries such as:
"Input.GetAxis" (which would roughly translate into poking 3 different classes in my current architecture)
Digging deeper, I've seen how they employed cameras (omg!) and simply had to stop. Further analysis revealed that over 25% of my code was simply handled de facto by Unity.
When my brain cooled down to appropriate levels, I took the very easy decision to move all current developments away from Dart and into Unity. I realize this may be a harsh move, possibly inconsiderate, but the truth is that I had no specific reason to use Dart in the first place: it was just the tech laying around when I started on this project.
Given I've been able to re-create months of work in but 2 evenings, I'm quite confident about my efforts in Unity, so much so in fact that I'm wondering why I'm not seeing a lot MORE Unity games around.
Unity 2D is great... for platformers.
Looking at it more and more, I realize that, even though I'm primarily making 2D games, I'm much more likely to opt for a 3D approach.
While 2D Physics may sound appealing, it's interesting to note that the actual inner workings of collision detection will assume that all objects are at the same Z coordinate (0).
While this is theoretically appropriate to a 2D game, let's not forget that, long before there were 3D games, there were 2D layers.
For example, in earlier games, such as Zelda: A Link to the Past, it was possible to walk on a bridge that passed over a level, and respond to different collisions.
Built "as is" in Unity 2D (using 2D physics), this would be impossible. One would either have to manipulate the Z axis through code to ignore certain collision (troublesome) or resort to using 3D physics and understand that they are not at the same Z position. The latter is a much more WYSIWYG method and far more sustainable in the long run, especially if you plan on having multiple levels and complex collisions.
This is probably not a big deal (especially on this project) and to be fair, it's the "worse" I've found this far about Unity 2D, but it's still reason enough.
One of my primary reasons to use Unity (past the initial excitement to achieve the velocity I strongly desired) was it's growing crowd of adepts. There's virtually very little that hasn't been attempted before and this means that there's a lot of code out there that can be used. If I can't do something efficiently myself, or if I can't be arsed to reinvent the wheel, I get to google it and find just what I need.
But wait... there's a store for that! All the better.
Worse comes to worse, I can just go directly to the Unity website and open up one of their tutorials and do it on my own... More importantly, I can have a look at live sessions where games are being made before my eyes, with actual commentaries as to why certain choices were made. It doesn't really get any better than this!
In retrospect, I'm glad I've bled myself dry on Dart: it allowed me to quickly identify the strengths of Unity and truly appreciate it. That allowed me to force myself into using an editor, which I'm glad I've managed to do so seamlessly.
Unity is not all joy and fun, but for this project, it's a big and much needed overhaul that should, hopefully, imply faster development cycles.
We shall see!