Jump to content

  • Log In with Google      Sign In   
  • Create Account

Like
11Likes
Dislike

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

By Tim Shea | Published Feb 18 2014 07:21 PM in GameDev.net Soapbox
Peer Reviewed by (jjd, jbadams, Aldacron)

leadwerks c++ ai wings

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:


Attached Image: TwoGoblins.jpg


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



About the Author(s)


I am an undergraduate computer science major at CSU Sacramento, and a long-time indie game developer. My interests are in novel gameplay techniques, artificial intelligence, and cognitive science.

License


GDOL (Gamedev.net Open License)




Comments

Is there a free version other than the 30 day trial for Leadwerks?

No, Leadwerks does not offer a free version, and I am somewhat conflicted about that.

 

On the one hand, I think the actual cost of the software is incredibly reasonable. If you plan to actually produce any content (games, demos, whatever) $200 is almost negligible.

 

On the other hand, I got my start with games and programming by downloading free versions, and I enjoyed it so much that I'm now finishing my CS degree, so I think there are peripheral benefits when companies offer those options.

I really like your comparison at the end.

Unity is a great tool. It is an amazing engine. I love it. But I am also very hesitant to recommend it to individuals and beginners. I try not to give an anti-recommendation because learning it can be valuable, but the tool is often too much.

If you have a small team, with a few modelers and animators and programmers, Unity provides a solid engine to develop upon for many game genres. Animators can leverage Mecanim to make heavily rigged models do amazing things. Programmers can sit back and watch as the physics system runs the world, allowing you to handle a small number of events needed to tie everything together.

But if you have just one person, and that one person is a programmer, Unity probably isn't the right tool.

I agree nearly 100% with you on your comparison between Unity3D and Leadwerks (or similar engines). I prefer to have a nice "low-level" view of my game's code, even if it isn't as easy to work with.

 

A few months ago, I reverse engineered the concept behind Unity3D (so no actually code reverse engineering) and figured out that UnityEngine.dll was just a wrapper for code built-in to the game executable and mono runtime. This annoyed me that it was such high level that we don't even have true control of the engine.

 

I find this "flaw" in other engines as well. One of the most used engines that does this is UDK. It's doesn't seem as high-level as Unity3D since just about all logic code is done through UnrealScript, but it's still not as "low-level" as I'd like. Engines like CryENGINE on the other hand are absolutely perfect in my opinion. Not only can you script logic in Lua, but they give you the source code to CryGame.dll as well!

 

Nowadays, I mostly try to stay away from engines designed to be "easy to use" since (as you mentioned) they hide a lot of stuff from the programmer. Really, the only "easy to use" engine I've actually considered using is Godot, but only after it was open-sourced. Still, it's scripting language is a bit of a turn-off. :(

Josh, thanks for the input. CryENGINE is one I haven't tried yet. I keep meaning to, and then forgetting.

I agree on the facts about Unity. Sometimes, you may feel you master the tool to some extend and almost think of yourself as an intermediate developer (or more), that is before you try DirectX or other framework.

 

Then you realize Unity has lied to you, and you actually know little about game development, particularly on the rendering side.

 

Don't get me wrong, Unity is the perfect tool for a company which wants to develop good and fast, but I would not recommend it as a starter tool for sure as you most of the time performs actions without knowing why and how they work.

 

Though, I used Unity for most of my projects :).

I disagree fafase, Unity has not lied to you, rendering code is not game development, game development is game development. I am also interested in what rendering barrier you hit?

 

Tim, your issue is the same issue I have seen time and time again with programmers coming to Unity3D and I have posted about this before here.

 

Basically a programmer sees Unity3D and goes like this: Oh my goodness, components are so awesome! Then they go ahead and code in a pure component based way. Later on, they end up feeling like they are limited or unable to do something nicely and that is when I have to remind them that they are just coding in C#! It seems like, because Unity has this component structure you MUST use this to create a game, well this is completely false and you can create a purely OOP game and just provide a Game.Initialise and Game.Run function to use in your main.cs behaviour!

 

Although I wouldn't recommend writing a pure oop game in Unity, I believe to leverage Unity3D to it's fullest you must sprinkle in OOP every now and again.

 

Maybe I just don't get this 'hiding' from the programmer thing. Can I get some specifics of what is being hidden from the programmer in Unity3D that you need for feature X?

 

I seem like some kind of Unity shill now that I read what I typed...

Interesting article, I too am a serial prototyper and lately I have been playing around with mobile dev,

Uity looked appealing but I usually have an aversion to such engines, i am serial engine writer-restarter too. But as I was determined to get a game out I decided to settle on something HTML5y (so that i could release on android, iphone, Tizen, windows and firefox OS

As a C++ programmer, I found Javascript very jarring and found it very difficult to write non-hacked code.

then i came across Emscripten, and set about knocking something together in C++ and SDL (to convert to HTML5 and canvas based).

But i find myself getting bogged down in engine land again, which as much as I secretly enjoy, I know it will lead to me not releasing anything :P

I am mainly hoping to do some 2D dev, most of my games-in-the-pipeline are relatively simple but one would be A.R. (augmented reality) so I would need access to the camera and shaders. There is another that would require a custom post processing render system, shader based with custom computer-generated-attributes. 

I am starting to think that for the simple ideas I could get away with emscripten but people keep telling me im crazy and should use unity.

for the A.R game it think i will have to go native and then port.

With your experience with various tools I wondered if you had any thoughts? does Leadwerks support mobile dev? i can see it supports post processing...

I disagree fafase, Unity has not lied to you, rendering code is not game development, game development is game development. I also am also interested in what rendering barrier you hit?

Rendering code is not game development, true. What I meant is that Unity is doing a lot of abstraction, rendering is only one of them. If you need another example, networking, one method to connect to a server and open a session. Memory management, well more likely object management in a scene, just create it and what is going on?

 

You don't need to know all that but considering someone starting with Unity and then trying on some Xna (I know it is off) which is already doing more than DirectX, well the user faces some familiar naming but should be close to drop it for considering it way too hard. 

 

Just my point of view. Again I do use Unity everyday at work so I don't consider it a bad tool.

Basically a programmer sees Unity3D and goes like this: Oh my goodness, components are so awesome! Then they go ahead and code in a pure component based way. Later on, they end up feeling like they are limited or unable to do something nicely and that is when I have to remind them that they are just coding in C#! It seems like, because Unity has this component structure you MUST use this to create a game, well this is completely false and you can create a purely OOP game and just provide a Game.Initialise and Game.Run function to use in your main.cs behaviour!

 

Although I wouldn't recommend writing a pure oop game in Unity, I believe to leverage Unity3D to it's fullest you must sprinkle in OOP every now and again.

 

Maybe I just don't get this 'hiding' from the programmer thing. Can I get some specifics of what is being hidden from the programmer in Unity3D that you need for feature X?

 

Thanks for your input. I didn't actually use the words hidden or hiding anywhere. I don't feel like Unity is hiding things, to the contrary, they actually have fantastic docs that do a good job of exposing things.

 

What I would say is that for me, when a tool recommends and most strongly supports a particular paradigm, impressions are going to be shaped by that paradigm, and I don't think it is unfair of users to do that. For example, it is possible to write procedural server-side scripts in Ruby on Rails, but that doesn't make it unreasonable to say "I'm not going to use Rails because I don't like MVC".

 

That being said, I appreciate your perspective. Implementing an object-oriented game structure may have been exactly what I needed to get my prototype working, it didn't occur to me try and completely bypass the game management components.

for the A.R game it think i will have to go native and then port.

With your experience with various tools I wondered if you had any thoughts? does Leadwerks support mobile dev? i can see it supports post processing...

 

Leadwerks 3 supports mobile platforms, but the latest update does not. I don't have much experience with mobile games, so I wouldn't want to make a bad recommendation.

 

Personally, I would probably go for a more traditional app framework for augmented reality, rather than a game engine. There is a whole lot going on in most engines that you may not have any need for.

 

Actually, earlier on Saturday I spent a while discussing some geo-gaming ideas with a group of devs, and one of them mentioned that Adobe Air could do a native app camera overlay kind of thing pretty easily, but I don't have any experience with it.

I agree nearly 100% with you on your comparison between Unity3D and Leadwerks (or similar engines). I prefer to have a nice "low-level" view of my game's code, even if it isn't as easy to work with.

 

A few months ago, I reverse engineered the concept behind Unity3D (so no actually code reverse engineering) and figured out that UnityEngine.dll was just a wrapper for code built-in to the game executable and mono runtime. This annoyed me that it was such high level that we don't even have true control of the engine.

 

I find this "flaw" in other engines as well. One of the most used engines that does this is UDK. It's doesn't seem as high-level as Unity3D since just about all logic code is done through UnrealScript, but it's still not as "low-level" as I'd like. Engines like CryENGINE on the other hand are absolutely perfect in my opinion. Not only can you script logic in Lua, but they give you the source code to CryGame.dll as well!

 

Nowadays, I mostly try to stay away from engines designed to be "easy to use" since (as you mentioned) they hide a lot of stuff from the programmer. Really, the only "easy to use" engine I've actually considered using is Godot, but only after it was open-sourced. Still, it's scripting language is a bit of a turn-off. sad.png

If you actually get an Unreal Engine license you get the same amount of control as in cry-engine, you get all of the C++ code. However that license is offcourse more expensive. I have a feeling this will get worse for UDK 4 where they ditch UnrealScript in preference of Kismeth and C++, which I guess you only get access to Kismeth.

I've spent a lot of time with various engines and in the end we decided to give Unity a proper go, I mean only over the last couple of weeks have we really even begun to tap into what it's all about and what to do with it and I've been using it for four months now.

 

Unity is a double edged sword, deceptively easy at first glance. But going through all the production steps of a game I really do believe it's the most difficult to use if you want to create something substantial.

 

CryEngine and Unreal has things like UberShaders, advanced GI, Kismet, material editors, Speedtree a whole suit of post effects, CryEngine probably has the best water I have ever seen and in CE again the occlusion techniques are fantastic. In Unity you have Umbra, no realtime GI and the shaders are basic.. All the great AAA tools like Face FX, Scaleform and speedtree you don't have.  But there are real time GI solutions available, there are phsyx upgrades.. There's a whole suite of PBR shaders etc.etc. Made by the creative users there's even marmoset's IBL setup.

 

So you are forced to buy or make your own shaders, improve the lighting and the shadow system.. Potentially even the terrain system and do what you can with the UI.. So aren't fragment shaders and having to build advanced tools enough? Unity allows you to tap in .DLL's so all the C++ wonder you want can be stuck right in there.

 

If you want to make a high quality 3D product, Unity is extremely flexible.. You may not have complete control of the rendering pipeline like the stencil buffer is restricted to a certain percentage. But for the most part everything can be swapped out like modules..  I will say this, if you're planning to do anything substantial in Unity you need to know what you're doing, I mean garbage collection will haunt you with mono and general performance will also haunt you. Let's not also forget that CryEngine has the same flexibility with C# and Mono. Making Unity look good is an artform within itself, but Unreal and CE give you all of this and Unreal in it's latest iteration seems to have a much higher focus on beginners and artists.

 

What it comes down to is, how prepared are you to get your hands dirty? Do you consider cost a factor. If yes is the answer and you're aiming big with a small team, Unity Pro is the perfect engine.

 

Sometimes an engine that gives you all the tools like CE seems a better option, even with the royalty. But I feel now after a lot of frustration, I made the right choice.

I agree nearly 100% with you on your comparison between Unity3D and Leadwerks (or similar engines). I prefer to have a nice "low-level" view of my game's code, even if it isn't as easy to work with.

 

A few months ago, I reverse engineered the concept behind Unity3D (so no actually code reverse engineering) and figured out that UnityEngine.dll was just a wrapper for code built-in to the game executable and mono runtime. This annoyed me that it was such high level that we don't even have true control of the engine.

 

I find this "flaw" in other engines as well. One of the most used engines that does this is UDK. It's doesn't seem as high-level as Unity3D since just about all logic code is done through UnrealScript, but it's still not as "low-level" as I'd like. Engines like CryENGINE on the other hand are absolutely perfect in my opinion. Not only can you script logic in Lua, but they give you the source code to CryGame.dll as well!

 

Nowadays, I mostly try to stay away from engines designed to be "easy to use" since (as you mentioned) they hide a lot of stuff from the programmer. Really, the only "easy to use" engine I've actually considered using is Godot, but only after it was open-sourced. Still, it's scripting language is a bit of a turn-off. sad.png

If you actually get an Unreal Engine license you get the same amount of control as in cry-engine, you get all of the C++ code. However that license is offcourse more expensive. I have a feeling this will get worse for UDK 4 where they ditch UnrealScript in preference of Kismeth and C++, which I guess you only get access to Kismeth.

 

Yeah, but most estimates I've read for a UE3 license are around the $750k-1m area and they only license to "established" studios. So for an indie developer, UE3/4 is a bit out of the way with the exception of UDK (which is just $99 per development studio, plus a small amount of royalties after $25k of profits). CryENGINE on the other hand provides the source code to CryGame.dll as part of the FreeSDK and an indie commercial license is free, but it comes with royalties (I believe they are calculated case-by-case).

 

Also, UE4's run-time C++ complication is nothing new. It's actually derived from an open-source (zlib license) project called RuntimeCompiledCPlusPlus (runtimecompiledcplusplus.blogspot.com). My understanding is that Kismet is now just a front-end to UnrealScript which can be edited manually (not too sure about this though).

Hi, if you're into C++ and powerful API, maybe Esenthel Engine would be to your liking.

I'm always open to hear some feedback.

Have a nice day :)


Note: Please offer only positive, constructive comments - we are looking to promote a positive atmosphere where collaboration is valued above all else.




PARTNERS