Our Games
Community
Newsletter
Click here to sign up for our newletter! - Privacy Policy
Company
Who am I?
If you are interested in the process of making and selling games, have I got the blog for you!Dinosauria Dev
The Indie Infrastructure: Game Engines
While it’s possible to roll your own engine, if you are looking to create a 3D game you probably will want to work with 3D middleware. If you are new to indie development, take a gander at this list:
Torque - Torque comes in several flavors, the two 3D versions are Torque Game Engine and Torque Game Engine Advanced. TGEA adds shaders, a large terrain rendering system, material stuff. To be honest, it’s not that huge of a leap over TGE basic. In fact, GarageGames recently announced that the TGE branch is essentially dead and TGEA would be receiving all their attention for the forseeable future.
Torque is often difficult to work with, and I hate the scripting language (boy do I wish they would build support for a standard scripting language). The engine is also a bit messy and buggy — it’s poorly documented and if you don’t use it in exactly the way it was intended, it’s really easy to break things. It also has a fairly large memory footprint and distribution file size.
That said, Torque is hands-down the most powerful, most feature rich engine available at indie prices. Torque has strong networking, and tons of ugly but useful hobbiest-written third party code. And the best thing about Torque is that it has a very strong future: subsequent to the IAC buyout of GarageGames last year, they have been putting some really solid attention into the engine and it’s made a ton of progress. A few big-name games like the Penny Arcade series are built on Torque. Various versions of Torque can build on iPhone, Xbox360, Wii, PC and Mac.
If you are capable and willing to put the work in, Torque probably provides the highest cieling amonst all the indie engines. If you are a weekend coder, you might want to go with something simpler, even 2D.
Unity - I have not personally used Unity, but it is starting to gain a solid reputation in indie circles. Notably, the games on Blurst are built with Unity. Unity’s strongest selling point in my opinion is in-browser support. However, you don’t get source code, and as of this post, you have to develop on a Mac (PC dev support is in the works). Their physics is miles ahead of GarageGames. However, I have yet to see a “large-scale” game made with Unity, meaning anything beyond a mini-game. That’s not to say it can’t be done, just saying I haven’t seen it. It also seems to be a cleaner engine than Torque. Unity can build for Wii, iPhone, PC and Mac.
Bottom line, if in-browser support or physics are your thing, or if you really want to use a 3D engine but you dont want the trouble that Torque offers (and you don’t mind developing on a Mac), Unity is the way to go.
XNA – XNA is used for the XBox 360 Creator’s Club, allowing anyone to publish their game on the 360. The only cost is for an XBox Live Gold membership, which is 10 bucks a month. XNA uses C#, which may make production easier, but leaves it somewhat underpowered as compared to other game engines. However, as long as your game isn’t too graphics intensive, this may actually be the easiest way to go. This is more of an API rather than a game engine, but many people prefer a cleaner, smaller architecture to the monolithic, tools-laden 3D game engines.
If you want to get going on the 360 quickly, this is the way to go.
Unreal, Source – In a few cases, indies and students have made deals with Epic and Valveto license their game engines. I don’t honestly know the details of these deals, but I suspect they arose from personal connections within those companies. I probably wouldn’t consider using these unless youve got experience with them, and if you do, well then, you probably don’t need this list. The best choice is usually whatever you are most familiar and comfortable with.
2D Engines
I have less experience with 2D engines (despite a fair amount of work with Flash), but here are my thoughts for what they are worth:
Flash - Flash/Flex is becoming incredibly powerful. It’s everywhere, it’s powerful, and CS3 offers true object-oriented coding. It now offers standalone executable support. Sprite rendering is fast now. Unless another engine or API offers very specific tools that are perfect for your project, there’s really no reason to use anything but Flash. You can practically make an MMO out of the box using SmartfoxServer, Electrotank, or Multiverse, and Box2D offers great 2D physics with a 3 hour setup time. By the way, if you are confused about the difference between Flash and Flex, they both use Actionscript, but Flash is built around the concept of movies and the timeline, whereas Flex is a cleaner coder’s environment.
GameMaker, RPGMaker - Simple engines for non-coders. These are probably the way to go if you just have no interest in trying to wrap your head around coding.
PTK – PTK has a good reputation amongst casual game development crowd. If I were making a 2D casual game for the PC, I’d probably want to evaluate this one.
Popcap Framework – Same as PTK.
Torque - Torque2D is essentially the same engine as TGEA, but does not include the 3D stuff, and includes some extra toolsets that are supposed to make creating 2d games extremely quickly out-of-the-box. The whole thing is a bit too overblown for my taste – a 2D engine should be simple and clean. This probably has the strongest toolset of any of the 2D engines, but it also comes with many of the same problems of the 3D engine.
XNA – If you want on the 360 and quickly, this is the way to go!
Blitzmax – An API, not an engine, but I’ve heard good things.
You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.
December 21st, 2008 at 11:12 pm
Nice list, but don’t discount the value of rolling your own. :)
December 21st, 2008 at 11:46 pm
Also, don’t discount RPG Maker/Game Maker programs. There have been successful games made with both. As for the rest of the descriptions, I think you do a great job of describing the points of everything and pretty much agree with it all.
December 22nd, 2008 at 12:58 am
It’s true that rolling your own can also lead to a very unique look, which can translate into PR and sales down the line. Introversion took that approach, 2DBoy did as well.
December 28th, 2008 at 10:09 pm
Having used both Torque engines (I own TGE and TGB), and a few others on that list (shipped with XNA, etc), I’ll disagree with your conclusion on Torque.
You’ve got it right in the details, but I’ll go farther: It’s kind of a POS.
If you’re willing to endure the pain that comes with using Torque, do yourself a favor and get Ogre instead. The content pipeline tools are all 3rd party but are pretty good, and it’s a fantastically designed and built engine. Plugins for tons of different stuff, you can do your UI in Flash, you can use just about every physics engine out there – it’s even been ported (unofficially) to XBox, XB360 and PS3 (probably more, but it’d definitely work on those.)
Basically, you get all of the benefits of Torque without the horribleness. You can even use real scripting languages instead of Torquescript. :)
Yes, it’s not quite so much “And now I drag the Orc in, and bam, I have a first person shooter!” but that’s a good thing.
December 29th, 2008 at 7:55 am
Ah yes, you’re right, I should have included OGRE. Of course, as you say, OGRE is more of a graphics API than a game engine. And one of the problems I have with OGRE is that (in the absense of personal experience), I’ve only ever heard of one game being released and sold with it. Their success stories seem littered with game engines and graphics related products. There’s not much evidence that it’s actually easy to make a game with it.
Out of curiosity, why do you say Torque is a POS? I don’t entirely disagree, but I’m wondering what about it really chaps your hide.
December 29th, 2008 at 7:24 pm
Well it’s been a while, but what I remember really making me puke:
1. The source code. It’s Tribes. It’s not a game engine, it’s Tribes without the game modules. It’s full of little Tribes specific hacks.
2. Torquescript – Standard programmer bullshit, we want a scripting language and don’t want to learn a new language, and always wanted to write our own script interpreter, so let’s make our own scripting language and make it as close to C as we can get.
3. Dependency on script – If you want to get down into the nitty-gritty to do a game, you can do most of it in script, but it’s a hell of a convoluted environment. When you can’t figure out how to do it in script, it’s a long adventure to figure out what to do in the engine. All wasted time.
There was one (that I know of) book written on Torque – it’s gigantic, and it’s pretty much all about Torquescript. I think there may have been a second volume (fuzzy on this) – but if it’s what I’m thinking of it was equally useless.
4. Results – when all is said and done it’s about what you can do with it, and that’s not that much. The default result is pretty horrible, as is the performance. You really have to bust your ass to get good results, whereas with something like Ogre or another real engine, it’s usually at least somewhat easy to do so.
As for Ogre, ya, there hasn’t been a lot of commercial titles released with it. I tell ya though, I just got out of a contract where I used Infernal (a commercial engine), and the fact that the company BOUGHT that engine instead of just downloading Ogre or even Irrlicht tells me that the problem is psychological and not quality – game studio heads just feel more comfortable when they can pay money for an engine. Support, etc.
If you get a chance, check out Ogre sometime. The sample app framework is pretty horrible, but the guy who wrote it really knows his shit, you can set up the game pretty much anyway you like and just about every bit of the architecture is pluggable and replaceable.
December 29th, 2008 at 7:32 pm
I completely agree with #2 and #3, #4 I only half agree with — I know for a fact you can build fun games with it, and quickly, though I agree that most games shipped with Torque “smell like Torque”. The source code is not great, and it’s almost entirely uncommented, but it’s not unusable. It’s pretty easy to rip things out entirely.
December 29th, 2008 at 7:32 pm
Thanks for your in depth responses, btw.
January 5th, 2009 at 9:10 pm
Fusion Fall, a browser-based MMORPG is being built using Unity by Cartoon Network.
Also, Global Conflict: Palestine was built using it.
I think you’re overvaluing source code access quite a bit. You really owe it to yourself to try building something with Unity. The model is quite different from the Torque world.
I went from being an experienced coder with no game development experience to speak of, to shipping game in 3 months with Unity. Complexity-wise, my game is probably only a factor of 2-3x less than Venture Africa as well.
-JF
February 17th, 2009 at 11:52 am
Just wanted to say that BlitzMax is a great easy to use OOP language based on C++ modules. It’s fab for 2D games (I’ve made 4 casual games with it and 2 with its predecessor BlitzPlus) and you can get free 3D modules for it.
February 28th, 2009 at 7:44 am
Wanted to add some comments regarding my experience with Torque and Ogre.
W.R.T. to Jason Maskell’s comments on Torque (TGE),
1. There are lots of Tribes-specific code, like weapons, etc. even in the engine. This defeats the purpose of a heavily script-driven engine design.
2. I really dislike TorqueScript as well but I think this issues shows how old TGE really is. At the time, there were not many options for embedded scripting languages, and there definitely was a culture of roll-your-own/not-invented-here back then when middleware wasn’t widely available or mature.
3. Script-driven architectures are popular now for game engines, so TGE was probably a bit ahead of the times then for how extensively it relied on scripting. However, this also meant that it had a very complex scripting framework on top of the C++ engine itself. To use TGE effectively, you’d have to learn how both these systems work.
The 2 books Jason mentioned are 3D Game Programming All in One and Advanced 3D Game Programming All in One, both by Kenneth Finney. They deal mostly with TorqueScript but I didn’t find them useful in overcoming TGE’s complexity.
4. TGE is outdated, IMO. The complexity required to learn TGE and deal with its problems is too high.
On the other hand, TGE network is quite well-designed. The problem is that you have to learn about the scripting framework and engine in order to use it properly.
TGE and TGEA are game engines with content creation tools, not just frameworks or APIs, so they do provide more complete solutions. However, some of these tools are a little cumbersome to use and are tightly integrated. This is not an artist-only engine. Scripting will be required.
The community is quite active but for serious support with detailed and authoritative responses (not just guesses), you’ll have to pony up extremely non-indie-friendly fees.
Other issues I’ve had:
* We got TGE early and like many TGE and GG supporters, paid up for TGEA as early adopters, thinking that the money would help GarageGames develop TGEA to get it to market earlier. Imagine our disappointment when GG released Torque2D, then Torque Game Builder for XNA after a year or two, while TGEA didn’t see much progress. Documentation and support efforts reflected GG’s new focus as well. Essentially, we felt like we helped pay for the development of 2 engines for GG that wasn’t useful for us. GG never promised the TGEA early adopter money would be spent on TGEA, but those of us waiting to upgrade to TGEA were pretty much left hanging for years.
* the feature list for TGE sounds great, but many things are either not what they seem or are simply broken in the engine. e.g., player-player collision doesn’t even work http://www.garagegames.com/community/resources/view/12174/1#comment-76503. We don’t feel like we can trust TGEA either.
* console platforms require additional license fees at non-indie-friendly prices. At least 4 figures. And you can’t even do the porting yourself to avoid this fee.
* documentation is outdated, inconsistent, and haphazard. We, and many others in the community, asked for documentation for the custom DTS format to create our own mesh exporter (or maintain abandoned ones) but we never received any help on that other than a “you can look up the source code”.
* a lot of bug fixes and some features get put into the engine through cut-and-paste code from the forums, leading to ad-hoc, highly inconsistent quality code. Try maintaining that.
You can use TGEA instead (with no fixed function rendering support for older machines), or even wait for Torque3D, but frankly, after our experience with TGE and the changes in GG that we’ve seen, it’s left a sour taste.
We are currently developing our own framework that uses Ogre for rendering and other middleware. It’s been quite good so far, but it is a 3D rendering framework (3D API + additional features like an integrated resource system, a plugin architecture that allows extensions, etc), not a full game engine and no real content editing tools. It can be quite complex, but has a good core design.
Performance so far is quite good, even when running in conjunction with other systems like PhysX, Squirrel scripting, etc. On a dev system with Q6600 CPU with 8800GT video card, we are getting up to thousands of frames per second, depending on the complexity of visual effects.
There have been commercial games shipped with it (Pacific Storm, Jack Keane, etc) and some good looking games (http://www.ogre3d.org/gallery/) in progress. It provides both fixed-function and shader pipelines so the visual range is wide.
February 28th, 2009 at 1:30 pm
Dan- I actually agree with you on most of this, but where I think I disagree is in the strength of the alternatives. How much R&D time does it take to get an engine up to speed rather than mash and fix TGEA or T3D into what you want it to be? My money is almost always on using middleware — the unexpected benefits that you encounter usually outweigh the unexpected setbacks.
February 28th, 2009 at 11:00 pm
Andy, actually, I didn’t mean to imply that using Ogre or creating your own engine would be faster or easier, or that it is even a replacement for Torque. Just wanted to elaborate on Jason’s thoughts on Torque and Ogre with our own experience with these 2 products.
As I mentioned, Torque is not just an engine. It comes with integrated content creation tools and this is very important in getting a game up and running quickly. Ogre doesn’t really have any, apart from some community attempts. It doesn’t even have an official run-time binary scene file format (closest is the dotScene plugin) or scene editor.
For most cases, it will be slower (R&D, development, integration, testing, refactoring, bug fixing), more difficult (skills, management), and costlier (manpower * skills * time), to develop your own engine, at least in the short term (1 to 2 years). That’s why we chose to develop a framework that wraps each middleware in a plugin component, instead of an entire game engine. We are using Ogre, PhysX, Squirrel, and RakNet at the moment.
We made this decision based on our requirements (more net-centric in terms of delivery and content loading than traditional engines) and what complete middleware solutions were available at the time that we could afford. Today, we would probably have chosen Unity.
In the end, it came down to expectations for us. Torque’s features promise (as far as a marketing bullet list does) a lot of things, but the reality didn’t live up to our expectations, mainly in terms of quality of code and ease of working with it. So, our recommendation is that if you want to use Torque,
- your game design shouldn’t be too far away from what you see in the Torque games showcase
- make sure you have good programming capabilities in your team because it is not just for artists
- be prepared to deal with a bunch of proprietary stuff that doesn’t have a lot of good documentation (frustration)
- be willing to pay for real support
IMO, the best professional showcase for Torque (don’t know if it is TGE or TGEA) is the Penny Arcade game series by Hothead. Other more polished Torque games are mostly by GG themselves who know the engine thoroughly. Hopefully, Hothead will share details (not just a postmortem) of their experience and tips with other Torque users.
Once we made the decision to build our framework, we started to look for dedicated middleware that only did what they needed to do – lighter weight solutions, not full game engines. In this respect, Ogre delivered more than we expected in terms of capabilities and extensibility, so it was a good first rendering engine for us. However, this also meant that we needed more technical development skills, time, and money to get to the same level of capabilities as Torque. We’ve spent the last year building this foundation for our company’s future and a prototype, more or less according to plan (some setbacks and slow periods, of course), so this year we can start building on the game. Therefore, this route certainly isn’t suitable for everyone.
In general, the adage of “use middleware” is a wise one these days, but evaluate your middleware carefully and thoroughly, and don’t forget the content development tools!
March 1st, 2009 at 10:44 am
Dan- Again, I agree with you on everything here. It’s funny, too, that since I wrote this post things have already changed — Torque has announced web publishing and Unity has a PC dev platform coming out. Thansk for such insightful comments, btw.
April 9th, 2009 at 11:24 pm
I just wanted to mention that XNA is equally viable for publishing to PC. I think it is also free to use if you are looking to make PC-only project. I’m also using XNA for the level editor for my flash game.
March 2nd, 2010 at 5:30 pm
Your site is loading rather slow for me. Might just be my isp but i don’t know… anyways great post. It helps me a lot, many thanks. Will definitely bookmark your blog for future reference :)