Rain in the Valley

It's been a rainy week and there is a flu epidemic in Sacramento. Hacker Lab, the city's premier incubator and coworking space, hosted the 4th semiannual Cereal Hack, a 30-hour competition to support innovation in the City of Trees. On offer: plenty of fruit loops; a brain-controlled competitive beer tap; Thousands of dollars in prizes; a chance for some personal reflection?

Why Leadwerks? (An Opinionated Reflection on Two Game Engines)

Saturday: Sitting in the common area of Hacker Lab and surrounded by some extraordinarily talented indie developers and entrepreneurs, I was ready to throw in the towel. Hours of trying and failing to translate a hasty white-board design into a viable Unity game (combined with a persistent cold) had made this weekend hackathon unproductive and frustrating. Rather than continue to waste my time, I packed up and went home to bed. This was not my weekend.

Sunday: Sitting in my dining room in the twilight between waking up and my wife waking up (the witching hours of code) I pulled together a Lua scripting interface, a unit testing framework, and some performance profiling reports for Wings. In the planning meeting last week, there was a lot of concern about whether we would have enough time to tackle our entire vision. The Wings project is being constructed as the culminating requirement for the team's undergraduate degrees. We had two semesters, and we've used one of them. Making significant progress on three major requirements is no small accomplishment.

This contrast of experience emphasized for me why I enjoy working with Leadwerks, and why I will probably steer clear of Unity in the future.

This was not my first attempt at using Unity. I'm a serial project prototyper. I like to make demos and prototypes, and then move on to new things, so I've used a lot of platforms a time or two. I don't dislike the software. The user experience is fantastic, the tutorials and documentation are great, and the engine itself is impressive.

My issue is not with any of those, but with the way that Unity imposes itself on the game developer. The structure of a Unity game, of game objects and components and scripts, is such that it is incredibly easy to use the tools that are provided, and not easy at all to recognize the underlying software. The process feels almost magically simple, but also deceptively unlike anything that a traditional programmer is used to. Unity is the Ruby-on-Rails of game development: if you're doing it The Right Way, you won't need anything else. But game development, especially for indies, has to be about innovation over convention. Creating novel experiences implies crossing boundaries that nobody thought needed to be crossed and I would argue this is just as true at the technology level as it is at the interaction level.

My hackathon concept was a backburner idea I've had for a terrestrial rover simulator. It isn't very complex, but it requires modifying the normal temporal and physical models and that was enough to torpedo my prototype. I'm fairly certain a Unity expert could have made it work, but that isn't my perspective.

Working with Leadwerks is an entirely different beast. Leadwerks comes in C++ and Lua flavors but I am using the C++ edition and my experiences reflect that. It features a slick OpenGL 4 renderer and it just became the first 3D engine on Steam in December. It has come a long way in the past few years and has a long way to go to catch up with the big guys.

But what is especially interesting to me is that Leadwerks at its core still has the feel of an API. When I create a Leadwerks project, it has a main method with a game loop. Omitting some of the more detail oriented code, this is essentially what you get:

int main(int argc, const char* argv[])
{
    ...
    App* app;
    if (app->Start())
    {
        while (app->Loop()) {}
        ...
      	return 0;
    }
    ...
    return 1;
}    

The autogenerated App class doesn't inherit from anything or apply any partial class scheme to include a bunch of code. It has a Start method and a Loop method. Start creates a World and loads a Map, Loop updates the Time and the World and the player input.

Building a game in Leadwerks is like rendering a scene in OGRE or simulating a world in Bullet, except with easy to use tools for good measure. The end product is a body of code that any programmer could understand without knowledge of the engine itself. It can be as organized or as free-form as you like. For me, this means that development is often hard, but it's hard in exactly the ways that I am really good at overcoming. I have been wrestling with complex objects and algorithms for over a decade. I am intimately familiar with Visual Studio's quirks. I am adept at googling up arcane solutions to uncommon programming problems. Leadwerks lets me exercise all of these abilities and enjoy the rewards.

Leadwerks also allows me to manipulate things that were not intended to be manipulated. At times, this level of freedom can lead to intensely painful debugging, but it can also allow for precisely the kind of innovative solutions that indies depend on. It also provides a foundation for (I think) some pretty cool add-on functionality:

In this screen capture, Wings is controlling the two goblins and the player's barbarian. The attacking goblin is defined in C++ and attached to the model during the map load, while the recently expired goblin is initialized using the in-progress Lua bindings for Wings. Providing these sort of deep hooks into the engine while maintaining a reasonable level of abstraction (Wings has a core library of engine-agnostic functionality) would be much more difficult in a more constricting environment.

Don't get me wrong, I am not a programming paradigm Luddite bemoaning the current era of software development. To the contrary, I am a professional software developer. I appreciate the value of programming constraints, and the utility of applying best practices. I vastly prefer modern software engineering to old-school get-it-done hacking. But when the hammer is so bulky that I can't see the board, driving the nail is a frustrating experience.

Unity is a slick, refined factory when what I really need, given my resources, are some very sharp hand tools. I don't love everything about Leadwerks. In places the engine itself is still rough and the decision to avoid removing deprecated functionality (in spite of the fact that new versions almost always include breaking changes) causes some unnecessary confusion. But as a whole, I find I am much more confident and productive using Leadwerks and that outweighs a lot of minor quibbles.

Disclaimer

I am not an unbiased reviewer, and this really isn't intended to be a review of either Leadwerks or Unity, but rather an explanation of why I find some of the most popular game engines to be harmful to indie development. Josh Klint, CEO of Leadwerks, is the project sponsor (requirements oversight, not financial) for Wings but has provided no input to this article.

Article Update Log

10 Feb 2014: Initial release

GameDev.net Soapbox logo design by Mark "Prinz Eugn" Simpson