This is great.<p>For those who haven't followed for 11 years, Garage Games started off selling the Torque engine for $100 - full stop, no tiered licensing schemes, making them at the time <i>the</i> cheapest game engine on the market.<p>The engine itself came from that venerable and dated Tribes 2, which was a commercial flop, and when the studio went under the tech rights when to GG. I'm not sure if GG was a third-party or more of an ex-employee spinoff.<p>In any case, I've been doing amateur game dev since around that time, and Torque has always struck me as a highly troubled product. They were offering $100 licenses to a 100% C++ codebase, which attracted all kinds of dreamers who really had no realistic hope of hacking on a C++ engine. I imagine their support load was immense.<p>I'm surprised they've survived this long - at $100 a pop you wouldn't expect the cash flow to be great. But kudos to them for open sourcing this.
I remember that it used to be a choice between Unity and Torque 3D if you wanted a solid 3D engine + integrated toolset. My guess ( I've been out of the loop in making games for a while ) is that this is related to pressure from the success of Unity. In which case I say good luck, the more open source engines out there the more code for people to learn from.
Torque is awesome. It was really quite unnerving when GarageGames was shutting down for a short time before I believe they were purchased by a different company.<p>Torque2D and the iOS version are both fantastic for quickly and easily building 2d games. However, with cocos2d and cocos2d-x, Torque2D has quickly lost it's appeal outside of the fantastic scene builder.
In todays market with Unity3D, UDK, CryEngine all offering free versions this doesnt really stand a chance.
But its free and for hackers who want to dive deep into C++ Game Engine code its a cool thing to hack with!
This seems to be a good example of how <i>not</i> to do a product announcement. No release date, no "email me when it's ready" form, just wait and hope that you'll become aware when it's out. Frustrating.<p>I'd like to hope that this will become an open source alternative to Unity, but I'm skeptical. It's from an era where every game engine inexplicably felt the need to create its own mediocre scripting language rather than using a real language. Replace TorqueScript with C# or Python or Lua, and then it starts to get interesting.
Torque pretty much started my development career, so this is great news to me. Its suffered a bit over the years, especially after InstantAction folded. Even so there is a sizeable group of indies who use it. I myself have been involved with in quite a few Torque projects, and even contributed to the core engine in the early years.<p>It's not perfect, but AFAIK its the only MIT licensed engine which is feature-complete out of the box. I think opening the code is a great step forward and provided GarageGames handle it right we could see some great improvements in the engine from contributors.
Getting a database error. But thankfully Google's got it cached:<p><a href="http://webcache.googleusercontent.com/search?q=cache:idAZix5Pyg8J:garagegames.com/community/blogs/view/21876+http://garagegames.com/community/blogs/view/21876&cd=1&hl=en&ct=clnk&gl=us" rel="nofollow">http://webcache.googleusercontent.com/search?q=cache:idAZix5...</a>
<a href="<a href="http://www.ogre3d.org/>OGRE" rel="nofollow">http://www.ogre3d.org/>OGRE</a> 3D</a> a MIT licensed game engine that has been around since 2001. I think some of the games in the OGRE gallery are far superior to most Torque engine games.
One thing I've always wondered about these game engines that are marketed towards Indie developers is that I don't tend to see many very successful games developed using them.<p>For example the list of Unity3d games here: <a href="http://unity3d.com/gallery/made-with-unity/game-list" rel="nofollow">http://unity3d.com/gallery/made-with-unity/game-list</a><p>There's only a handful there that I've heard of.<p>Most of the Indie games that have been hugely successful (braid, super meat boy, minecraft etc) all seem to use a minimal but fairly custom engine rather than a monolithic solution.<p>I wonder if this is partly because these engines are usually designed to offer features that are as close to stuff available in AAA games as possible meaning that they are better for producing "me too" type games rather than something unique. Whenever you start using large amounts of someone elses code inside your product you are always going to take on some limitations in terms of what that code was designed to do and which edge cases were thought out in advance.<p>One example of this might be in Braid where you have the ability to rewind time. I'm assuming that the game does this by keeping a list of all the previous states of the scene graph in memory and having flags set on objects which do not rewind when everything else does. In this case it is important for the programmer to try and keep the memory footprint of the scene as small as possible so that a large number of states can be kept in a machine with low memory.<p>If you were trying to develop this using a monolithic engine that was built under the assumption that time flows forwards and old states can be thrown away it might be such a hassle to implement this that you either throw the idea out or curtail it to the point where it affects how good the game is.<p>Edit:
Further to this I often get the same dilemma when choosing things like web frameworks. A lot of these provide built in functionality for stuff like authentication and internationalisation. However I often find that the built in solutions to these things don't quite meet the requirements for what I'm trying to build. So the solution tends to be to not use the built in functionality and implement these things myself but then I run up against other parts of the built in functionality or third party plugins which assume that I'm using the "out of the box" solution.<p>This is where Java with it's Factories and Interfaces, or functional languages which allow me to pass implementation around can be very useful. On the other hand I'm not always sure it merits the extra complexity so I prefer to use loosely coupled libraries. If that means that I sometimes have to write boilerplate that converts between object types etc then so be it.