An afternoon with game engines

After an exciting morning at the XFC, I had an iced coffee and decided to dig into a few game engines. I am looking for technology to support up to three upcoming activities: the digital archaeology simulation mentioned a few days ago, my Fall game programming class (which so far has no plan), and my Spring VBC seminar. This is an informal story about my afternoon explorations, more about impressions than any deep review.

Unity

I started by working with Unity. I had looked at it briefly before, but had not really done anything with it. I was immediately infuriated (yes, infuriated) by this:

I keep my Windows start menu at the top of the screen, where it belongs despite its not being the default position. Unity slams all of the dialog boxes to the top of the screen, and they come up under the taskbar, where I cannot move or close them. Ugh. You know, in Linux I just alt-drag to move any window. For this, I temporarily had to set the taskbar to autohide just to tinker with Unity.

The documentation was high quality, and it didn't take me long to make this:

You can run the "game" and use the keyboard to move the grey box around the blue field. Not too shabby. Note that the scripting language is JavaScript, which is nice since I have passing familiarity with it, and there's a high likelihood that students will have at least seen it before. If not, it's close enough to Java or C# to make progress fairly quickly.

With this impressive start, I started looking at version control, because you should always use version control Unity's own product page lays it out for you: to use external (i.e. third-party) version control systems, you need to get the $1500 Unity Pro (as opposed to the $0 free version), and for an extra $500 per seat you can use their Asset Server. The difference between $1500 per seat and $0 per seat is pretty steep. There are workarounds on various forums, but the long and short of it seems to be that you need the Pro version to make this work.

Torque 2D / Game Builder

Next I decided to look up Torque, which despite having contacted their friendly customer support people and glanced through one of their books, I had never actually used. The main reason for this is that there's a timed 30-day trial, and I never really had set up serious time to evaluate it. My first impression was very good, especially because I am keen on 2D games: that's one less D required for art resources, and my teams are almost always heavy on coders and low on artists.

I started the Fish tutorial, and as soon as I had to start tinkering with scripts, I got worried. First, despite this being an official and apparently-popular tutorial, the scripts and folder structure in the tool were completely different from those in the tutorial: names, directories, functions---all different. I struggled through to a point where it appeared I could start doing some OO scripting, and the tutorial diverged too far from the tool for me to care to go any further. The scripting language was significantly different from what I and my students are used to. Just as an example, functions require "%this" to be sent as the first parameter, and yet they can be invoked via dot-notation on objects:

// Definition
function FishClass::setSpeed(%this) 
{
   %this.speed = getRandom(%this.minSpeed, %this.maxSpeed);
}

// Invocation
%this.setSpeed();

This is not a deal-breaker, but it is quite ugly, and I found the quality of documentation generally to be inferior to Unity's. I will mention that there was an excellent feature in the Torque tutorial in which each step was followed by a link of the form, "If you don't know how to do that, click here." Clicking that would expand a frame containing step-by-step details on how to access the corresponding feature.

I need the documentation to be in sync with the tool if I'm going to throw this at students, especially on a short time-frame project. A good experiment, but time to move on to...

UDK

The mac daddy of readily-available commercial-quality game engines, with incredible university-friendly licensing terms for non-commercial use: basically, no cost. The only real cost with UDK is that it's a bit complicated. After tinkering with Unity and Torque, and glancing again at good old GameMaker (which I taught to kids in grades 2-8 a few Summers ago), UDK is clearly a different kind of beast. I had played with it a little many months ago, and opening it back up, I thought maybe I could recreate the jolly good "move the box with the keyboard" game. No such luck. In fact, I couldn't seem to intuit how to do anything at all. This was late in the day, and at this point I had had enough interruptions to wreck my flow. I brought up some videos and tutorials that I'm pretty sure I had read before, and I remembered bits and pieces of how it works. I also remembered my initial response to UDK the first time I had used it: clearly this is a powerful tool that we could use to build something very tight, but throwing this at a team of undergraduates with no background in any of these ideas would be very dangerous.

Also, I remembered having seen some really high-quality tutorials, including great video tutorials. All these links on the UDK documentation pages are dead. I'll have to come back to it when I'm feeling inspired and the Web site is fixed. I love the idea of using UDK, but I'm afraid of the learning curve.

Slick

I can't shake the feeling that we could always just do it in Slick. The biggest problem with Slick that we had in Morgan's Raid was that it was hard to gain momentum, since we had to do so much ourselves. However, I will have nearly half the Morgan's Raid Spring team on the two big projects (digital archaeology and VBC), and it's tempting to just build off of what we had. The complication with this, which I will discuss in an upcoming post mortem on the project, is that students don't have the experience to do software architecture, and so leaving core engine decisions up to them can have further productivity-impacting consequences.

Something like conclusions

It was a great afternoon of tinkering, though not without frustrations. However, it is good to be reminded of what it feels like to be thrown into an overwhelming interface: this maintains sympathy with the experiences of the undergraduate computer science student.

Working without version control is practically a non-starter for any significant development effort. Spending ten grand on software licenses is definitely a non-starter. This is a shame, since Unity seems to have pulled ahead in the engine wars for projects the scale I am considering. I may have to invest more time into trying some of the version control workarounds that folks have posted so that we can get away with the free version, since there's literally nothing else in the Pro version that I expect I would need.

As always, I am open to your suggestions.