Frayed Knights Update: How’s Unity 3D Working Out?

Posted by Rampant Coyote on June 13, 2013

I got a great suggestion a few weeks ago for a Frayed Knights Dev Diary thingy about my experiences working with Unity 3D.

Brilliant idea! The only trick is, I’m not really sure how to answer it.

My first reaction is, “Huh? I’m using Unity? Oh, yeah, I guess I am.”

It doesn’t sound like a compliment, but it is. Here’s why:

Familiar Language

Most of the work I’ve been doing lately has either been UI stuff (which uses a UI toolkit called NGUI… built on top of Unity), game code, and data framework stuff.  For the latter two cases, well: code be code, mon. I’m using C#, which is a popular high-level language that I’ve used off-and-on over the years, but it’s very similar to C++, which I’ve used like – forever.  The Mono “subset” of libraries that I can use in Unity is pretty extensive – not perfect, but more than adequate for what I’m doing in game code.  It’s a fairly mature language and set of libraries by this point, and it’s a familiar language. So…. I’m right at home.

One big challenge here was, of course, that I’d written a ton of code for the previous engine that now had to be completely re-written. That was a factor in going to a new engine – I knew there’d be a big hit on schedule because of this. To some degree, I was able to “port” the old code over without too much difficulty. But I’ve also taken advantage of the opportunity to completely re-write huge chunks (I’d say 85%+) of the game code. This isn’t as bad as it sounds, but then… I’m a programmer. It’s what I do.

Third-Party Support

In the case of UI stuff using NGUI – you have to have a pretty good handle on how Unity likes to do things, I guess, but it’s still it’s own framework on top of that. I’m never sure I’m doing things optimally or not, but then I’ve never been much of a UI programmer. But NGUI is easy to work with, and has a ton of features. And this says something about Unity – it’s really well-supported by the community right now. There are zillions of third-party libraries out there for it right now, and while most aren’t quite as well-made and fully-featured as NGUI, they tend to address a lot of needs where Unity is found lacking.  Most of the resources are pretty reasonably priced – so if spending $10 or $20 or $50 for a utility or library or $100 for a collection of stand-in content doesn’t freak you out, there’s plenty of stuff out there to make your job easier.

Then there’s the community itself – wow. The forums are incredibly active, with lots of helpful answers from both third- and first-party sources. There’s sample code and tutorials galore. It’s hard to overstate how important this is, until you’ve been screaming silently at your monitor at two in the morning and then do a Google Search and find the answers to your dilemma in seconds.

The Development Environment

Unity has a really nice editor that works well.  By default (I think) there are a number of windows that handle most functions – a hierarchy view of the current scene, a 3D graphical scene editor, a “Game Camera” view, a project file / directory structure pane (with graphical previews of objects, materials, textures, etc.), and an “inspector” that shows you (and allows you to interact with) the properties of whatever object in your scene that you have currently selected (via the hierarchy or 3D view). Then there’s the main menu and some handy widgets, including the ability to run and test your game right there in the editor in the “Game Camera” view.

The default code editor is MonoDevelop, though a lot of people use Visual Studio instead. While I’ve been a VS guy for most of my career, I’m using MonoDevelop right now. It’s already loosely integrated with the Unity editor, and generally works pretty well. I won’t sing it’s praises, but it generally does its job reasonably well and gets out of my way.

I have had some occasional problems with the editor crashing or locking up on me. This is really frustrating if I haven’t saved recently. But I’ve simply taken to making sure that I save early and often.

Another slick feature of the development environment is that it does a lot of work automatically. For example, if you drop in a Blender object into your game’s directory, Unity automatically recognizes it, imports it, and adds it to your game resource tree. If you make a change to it, Unity automatically detects the change and updates it accordingly within memory. While that sounds like a luxury in your content pipeline, it’s amazing how handy it is and how much it can speed development.

Finally – a really big deal is the ease of exporting to different platforms. I haven’t messed with this much – the only time I’ve done a full export has been to web-based and standalone Windows projects. But it’s really, really easy. As easy as it should be, at least from my limited amount of monkeying around with it. You simply choose your target and a few options, including your starting scene, and build. Unity does all the heavy lifting and assembles your project for you.

 Unity Scripting

The Unity scripting system is very easy to use once you get a “feel” for it – which might take a while.  There are a few libraries to get familiar with, and some critical components to be aware of (things like Time, Transform, Mathf,  and Camera are pretty critical off the bat).  But at it’s core, Unity deals with GameObjects – a base class for all objects – which are object-oriented containers for components – behaviors and characteristics.

In practice, it’s pretty straightforward. You have an object. Want to make it player controlled? Link in a player control component. Want to make it visible? Link in a mesh renderer using whatever player mesh you want. Want it to leave a trail behind it? Link in a trail component. For more complex objects, your game object can have a number of “children” objects, all with their own components. It’s powerful and elegant. And of course, much of your job as a programmer is creating these components.

Once I got into the swing of things, I quickly found that a lot of the way things were designed pretty consistently – which means to me that I could predict with decent accuracy how I expect Unity to handle things I needed to do. I felt like it was designed the way I would have designed it. This makes navigating the system much easier – when I’m trying to figure out how to do something, I simply think of how I, as a programmer, would have set it up, and go hunting for a function that sounds right. Four out of five times, I nail it. This is perhaps a subjective aspect of Unity, but it makes things a lot easier and more fun for me. It just makes sense and feels right.

Nobody’s Perfect

Naturally, nothing is perfect, and Unity has some blemishes. I’ve had some upgrades to newer versions that have gone far less than swimmingly with my existing projects. There have been a few things that have seemed needlessly difficult to do in Unity that were fairly trivial in other engines, which doesn’t make sense, but usually it’s the other way around.

There are some other issues I’ve heard but not experienced first-hand. The lack of access to the source code is potentially a problem, but in my own experience so far, I’ve been able to do everything I’ve needed to without digging into source – the framework has plenty of hooks into what’s going on and great plug-in architecture, so I don’t foresee it being much of a problem.

You can take a look at some of the games coming out with the Unreal Engine and compare them with Unity, and grasp some of the claims that Unity is just not as powerful as other engines. In theory, I can see this. As I understand it (and this is hearsay), getting proficient in the Unreal Engine takes a really steep learning curve, but once you break through all of that, you have more immediate access to powerful tools. But for the most part, anything that’s done in Unreal can also be done in Unity, but may require more hoop-jumping to get there. But on the flip side, it’s a lot easier to get at the more common tools.  However, this could also lead to Unity games tending to “look alike,” as developers tend to maximize their use of what comes easy.

There are a few more elements of Unity development that I haven’t messed with – like profiling and some debugging tools – where Unity may end up sucking. I personally still only feel like I’ve tapped maybe 30% of Unity’s potential, so there’s plenty to discover (and possibly be disappointed in).

Still Learning

While the learning curve in Unity (especially with the tutorials) was relatively gentle, there are a few things that I’ve done thus far that I’ve considered going back and changing. I set things up a particular way that made things a little more complicated for me than they really needed to be, but I’m not sure now if it’d be worth the time to change it.  As I said, there’s still plenty I haven’t touched yet, or worked with only a little, so I don’t consider myself an ‘expert’.

With many game engines (at least ones I’ve used or experimented with), putting together a simple world to walk around in isn’t hard, but taking interactions beyond the basics can be quite cumbersome.  So far, Unity’s learning curve has been pretty gentle throughout. Maybe it’s just that I’m, er, “seasoned” at this point, but taking things to the next level has not involved a giant wall of learning.  There have been a few “gotchas” and some document-scouring involved from time to time, but the way forward hasn’t seemed to require a PhD in Unity before taking the next step.

An Engine that Works With Me

I’ve worked with my own, home-brewed 3D engine before (with Void War), with a number of in-house engines, and put serious effort into only a couple other off-the-shelf third-party engines (notable Torque). While it’s unfair to compare Unity with a much older game engine that was really someone else’s in-house engine re-purposed for third-party use, I did feel when using TGE that I spent half my time fighting the game engine, even when I was trying to do things “it’s way.” That sort of thing really blows productivity.  And compared to in-house engines, Unity is far more fully-featured (because it has to be). Overall, with Unity, I feel much more like the engine is working with me, rather than fighting me, on what I’m trying to do.

This all goes back to my comment at the beginning – I often forget that I’m working with Unity. I feel this is a compliment.

The purpose of a game engine and development tool is to do all the heavy lifting and “scut-work” on the mechanical aspects of game development so that you, the game creator, can concentrate on making the game, and making it cool. It is supposed to ease the transition between the minds of the creators and the player’s screen. So if it is doing its job well, you really shouldn’t notice it – it’s like driving along a smooth, well-marked interstate with little traffic. By comparison, you might say, “Oh, wow, this is a really easy trip,” but for the most part it doesn’t draw attention to itself – you get to concentrate on the journey.  That’s really how Unity has been for me. I’m sometimes impressed by how it makes parts of my job easier, but for the most part it simply facilitates the journey. I think, “I’m working on my game,” not, “I’m working with Unity.” And that, I think, is the mark of an excellent game engine.

 

UPDATE:

Free bonus (and worth every penny…)! Since I’m doing a lot of work with dungeon geometry generated in run-time, I can get some weird effects that hit the entire dungeon. This was 100% a “me” bug, not a Unity problem, but I just thought I’d share. The problem is when I flagged certain areas as being water. It worked well – except for sections of the dungeon (which I deem “blocks” – a 20 meter x 20 meter square area) with no water. There, the water didn’t get initialized, and decided to turn all the floors of the “default” material into running water instead.

So it looks like I left the water running in my dungeon.

 

 

Filed Under: Frayed Knights, Game Development - Comments: 6 Comments to Read



top