GrapeFruit Games

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 Tedium, my Source mod, I think I only wrote 100 or so lines, mostly just GUI stuff.

But, let’s face it, coding to me is a means to an end. Unity’s true power is its iteration speed. I can whip up a brand new prototype for only a few hours work (Global GameJam FTW), or more commonly, test out a new/modified mechanic with minimal effort. Some of you guys may have your doubts about C#, some of which I must agree with, but the fact that you can jump in, change a line, then be playing within 30 seconds is vital for an indecisive soul such as myself. Or the fact that assets can be swapped out with barely any effort. My partner in crime can update models or textures without my code being affected. Variables can be tweaked in real-time (in most cases, see below) to get mechanics just right.

Now I must admit, I’m a naive developer and the biggest real team I’ve worked on is 2 strong, but I can see Unity, even if I’m not publishing a game with it, being a vital tool for quick prototyping. There are however, a couple of things that would become hard to work around with different projects I may work on. Most obviously, scaling. Even the small project I’m finishing up (see it soon on a web-browser near you!) is reaching a size limit with Unity Indie. My partner and I had the pleasure of using the Asset Server (Unity’s version control system) with our Pro trial, and that seemed adequate for most reasonably sized games. Without it, we’ve had to resort to Dropbox/USB sticks to transfer builds and assets. Luckily, I’m doing almost all the coding, so we don’t have to worry about conflicts, but essentially we are working on separate branches, then merging. This would simply not be feasible in a bigger team, or one that shares coding responsibilities more. Again, I must stress that this is an Indie issue, however it would put people off working on larger projects with Unity. Another issue I’ve run across, is using Unity as intended with networked games. One of the more powerful features of Unity, design-wise, is the ability to change variables at runtime and view the effects. With networked games, this is a bit unwieldy, and can introduce a bunch of networking quirks when the code recompiles. The networking part of the API also seems to be less robust than the rest, with certain functions not playing nice. Network.Instantiate for example, or the sometimes unclear connection issues.

I’m really just being a spoilt brat, these problems are often project specific, and work arounds for these and several other minor problems (physics layers gah!) are not too hard to use. Affording a Pro license is far beyond my means at the moment, but it would solve a bunch of issues. Unity has become essential for me, I can focus on the part of game making I’m actually interested in, and forget about the chores.

Note: This entry is crossposted to altdevblogaday.org. Check the site out for heaps of useful game dev thoughts, from people far more knowledgeable than myself!