Saturday, June 4, 2011

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.


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 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...


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.


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.


  1. Great post. I'd like to offer a few more options that are Java related for you to check out. The 1st is libgdx.

    It is a cross-platform game dev environment for Java. Check out the authors book too which is really good especially for a 1st time author:
    As I understand it Slick was ported on to libgdx so it runs on Android too.

    I'd also be pleased if you would review in a months time or so my effort TyphonRT. TyphonRT is a fully component oriented cross-platform effort with Java which features an advanced component oriented entity system that goes well beyond Adam Martin's articles. BTW this is how I found you through a post on of those articles. I am wrapping up major engineering on the core runtime and client SDK this month and will be getting a semi-public beta out to everyone who has been waiting. Late June / early July with a full public launch planned for late August / September.

    I'm doing an all day game dev workshop for AnDevCon II this November, so will have a bunch of tutorial content styled in a Khan Academy direction done by then suitable for beginning / intermediate students. Of course a demo suite of examples is available on launch.

    Of interest on the build / configuration side the main core of TyphonRT will be hosted on GitHub and I'm building Git integration tools that are based on Gradle and declarative builds. So all new an interesting tech to teach students as Gradle is great. This will work with IntelliJ Idea Community Edition or Eclipse. So free / available to all.

    No cost for university / education use for either libgdx or TyphonRT. The main 3D game demos for TyphonRT is an engine built on it called Auriga3D which can load Quake 3 assets and I'll be extending this to the iOS Rage assets soon too. There are 2D game demos as well.

    A main difference between libgdx and TyphonRT is that libgdx is a tightly integrated OOP architecture. Whereas TyphonRT is fully component oriented at the platform level and with a runtime COP (component oriented programming) API. This difference is also why I'm just about done with TyphonRT as it has taken quite a bit of effort to fully eliminate OOP as the dominant organizational architecture and release engineering concerns for a component architecture are massive. TyphonRT for the shared / cross-platform and Android assets is ~135k SLOC and ~600 components / ~1500 classes. By launch with the desktop peers added and additional native bindings and such it may be pushing ~200k SLOC and ~800 components.

    I'll be working with the libgdx community to make sure those who wish to mix and match say libgdx + TyphonRT's entity system is possible.
    Also I certainly suggest looking into Android game development with Java and not just purely sticking with the desktop, but you can do both with the frameworks I have mentioned.

    Anyway.. I started following your blog because of your interest in teaching game dev through Java and your interest in entity systems. I'd be glad to chat more offline as I'm actively interested in supporting educators teaching game dev with Java.

    Your post was definitely helpful coming from the Java game dev vantage point.

  2. I remember hearing about your TyphonRT in the past. I look forward to seeing how it shapes up. Unity's use of a component architecture is intriguing to me, and from my experience, it seems much more manageable than Torque's structured programming approach, where there's a rat's nest of script dependencies. Have you done a comparison of your component architecture to Unity's?

    From my experimentation with the entity system architecture (prompted by Adam Martin's post, as you say), the proof of the pudding is in the eating. When the components and systems are well-designed, it's dreamy, but it's also easy to end up with systems in the wrong places. From my limited Unity experience, they have a few core systems that run all the time, and the rest is done with script triggers. I'd be curious how yours compares, as I move forward with my own super-secret, probably-never-to-be-completed hobby project, using what I learned from Morgan's Raid's entity system architecture.

  3. >Have you done a comparison of your component architecture to Unity's

    I haven't yet too deeply as in some ways I'd like to not be influenced by Unity at least in the initial architecture build out.

    My driving aspiration for TyphonRT has been simply, "no compromises". It's also why things have taken a bit longer to get out, but the launch really is imminent.

    Adam Martin's posts are the closest comparison, but I extended the component / system concepts well beyond just entity systems to create a generic in app component oriented programming (COP) API. The platform itself is also component oriented and highly modular with a runtime and client SDK. Presently things are configured by a dynamic XML processing system and reflection, but I'm aiming for full OSGi support by v1.0. The important part is that the actual library of components is well built out and tested.

    The goal for this is to eventually create a PaaS oriented service that can auto download patches (alternate components, etc) to TyphonRT for various misbehaving OS & device combinations whether desktop or mobile oriented. And indeed Android needs such a solution as there has been some nasty fragmentation out there especially for low level / game dev scenarios.

    >When the components and systems are well-designed, it's dreamy, but it's also easy to end up with systems in the wrong places.

    I suppose in an container based architecture which component architectures are usually based on IE integration over a collection of components / systems as a foundational pattern it's possible to misplace components. Being fully declarative and externally configured with readable XML files certainly helps in regard to the runtime configuration. I plan to create GUI tools to manage this eventually.

    I do have a set of well formed entity related components / systems for game development completed that take into account the majority of uses including physics and easy hook up to input control mechanisms in TyphonRT that are all configured with external XML.

    Also speed and performance are core design considerations, so for a component architecture performance is very good in addition to as low as possible memory allocation via lazy initialization.

    I suppose the main difference between TyphonRT is that it's an more open framework insofar that one is free to mix and match platform / runtime components and take the minimal set required to accomplish the task at hand. TyphonRT is definitely geared as a generalized platform suitable for business / enterprise use, but with a heavy focus on game development.

    The other major difference is that TyphonRT doesn't feature (yet) an IDE / integrated asset creation editor.

    I'm working on a separate build / configuration tool that will provide a GUI driven experience with presets / wizards in addition to more advanced controls. This all driving Gradle and Git / GitHub integration under the hood. IE if you check out the source code all project files w/ dependencies are created dynamically from templates for Eclipse or Idea.

  4. This comment has been removed by the author.

  5. This comment has been removed by the author.

  6. *From my limited Unity experience, they have a few core systems that run all the time, and the rest is done with script triggers. I'd be curious how yours compares

    That sounds similar as one can configure TyphonRT to say have Application level entity management as an application lifecycle plugin. IE one can create entities anywhere and they are managed / destroyed as necessary via the Activity lifecycle automatically or globally maintained as specified. I borrow a little from the Application / Activity organization from Android. This would be an example of a core system for game development that is always running, but of course you can configure TyphonRT for non-game development and exclude such functionality.

    I'm also very much into audio / spatialized audio, so I'll be releasing a lot of OSC (Open Sound Control) networking related components to create GUIs and control code for audio hardware & various software DSP engines.

    That and I'm stoked for the ADK and will be um making an automated paintball turret controlled by an Android tablet as my first large ADK project, so this will definitely push TyphonRT.

    While I'll certainly be looking into supporting scripting and particularly integration with Groovy, Scala, one can directly interface with the component architecture through Java. So presently one builds an engine on top of TyphonRT with Java. TyphonRT is not a closed box design that limits a developer.

    I do plan to release additional components for say specific types of engines, IE tile based, parallax scrolling, isometric, etc. My longer term plans though are to work out a client / server type system either using Verse ( or something very much like it.

    *as I move forward with my own super-secret, probably-never-to-be-completed hobby project, using what I learned from Morgan's Raid's entity system architecture.

    I'd be down to check it out when it's ready! I'm definitely excited about all this stuff, so yep a bit chatty here.. :)

  7. @MichaelEGR: Just last night I realized that some blogger comments that I received over email were not actually published, but rather misidentified as spam by the blogger system. Bit of a UX design fail there, to email me the notification but then not actually tell me that it's not publishing the comment. In any case, sorry for the delay, but I did just release your post from quarantine. Some of my best pals' posts were similarly languishing in comment purgatory.

  8. Indeed.. The Blogger comment system is odd and a bit antiquated it seems. Apparently it supports HTML as anything in brackets is seemingly treated as such. The post would show up then vanish on refresh without mentioning it is waiting in moderation; I figured it was in moderation, but this triggered a spam alert on my Google account and I had to verify via text message then tried again. Oh.. Google.. ;P