Working with Unity
I’ve been playing around with Unity for a while ( I even had an indie license when they weren’t free unfortunately ), but only began seriously using it over the past few months. The reason is partly that I’ve been disconnected from my PC desktop and now use my MacBook for development. However, I think I’ve only recently gotten comfortable enough with how Unity works to see what a powerful tool it can be in designing games. It has its flaws (btw, hi Unity guys!) but as I use it more, it keeps growing on me…
I’m principally a designer, only doing a bit of everything else to get anything made, and Unity is the only tool that makes design easier without feeling restrictive in the way that Gamemaker does (admittedly I’ve only fiddled around with it). First, it hides enough of the engine that I can escape low-level coding, which is hardly my forte. This does have the downside of making it harder to get a unique aesthetic amongst other Unity games, the lighting engine is untouchable, for example. A Pro license at least gives you full screen effects to help with this, however. It also means some hacky workarounds must be used sometimes for some trickier mechanics to work, or even to stick with good programming ideologies (like when using C# interfaces). But these are rare cases. What Unity also does good from a design perspective is that the API and it’s excellent documentation helps me with enough of the higher level stuff that I can focus on simple scripting. Source SDK might provide a powerful C++ based engine and framework, but the documentation, for modders anyway, is pretty barebones. I don’t have the time or proficiency to reverse engineer such a complicated code base, so what I can do with it is fairly limited. For blog