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 the cheapest game engine on the market.
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.
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.
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.
Tribes 2 was not a commercial flop, it did extremely well for a 2001 game.
The studio (Dynamix) did not "go under", they were closed by Sierra/Vivendi for "restructuring", which was a shock considering the success of Tribes 2. In fact, the next game (Tribes: Vengeance) was green-lighted due to in large part the success of Tribes 2.
GarageGames was partly made up of some ex-Dynamix employees.
And that's all too frequently how successful studios are rewarded in the post-2000s mega-conglomo AAA game industry: shuttered up and their "resources" (programmers, designers, etc.) distributed to polish turds on the parent company's other big projects.
Dynamix was closed 4 days after Torque(then called V12) v1.0 was released. GarageGames itself was more of an ex-employee spin-off (created several months before the closure) to sell a game engine using the Tribes 2 tech.
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.
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!
The nice thing is that because of the MIT license, those coding up their own engines can borrow missing pieces (such as navmesh generation, pathfinding, animation, etc.) from Torque. I really like this move.
Guess it's time to start wearing my old GarageGames t-shirt again. Unfortunately, college was a few years and a few pounds ago...
Torque did build and run (In-game editor an all) on Linux back in the day, although support was always iffy (not sure if that's pre-Torque3D or not) - maybe open-sourcing will bring out some Linux hackers to shore that back up.
This seems to be a good example of how not 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.
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.
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.
I'm not sure that you're placing it correctly in its historical context. There really weren't (as far as I recall) really suitable implementations of scripting languages for games at the time and there were certainly poorer amenities for people wanting to use them.
Would you consider UnrealScript one of these toy languages (it is) or QuakeC, or the goofy approach of Out Of This World? A problem needed solving, and these devs found something that worked well for their purposes.
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.
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.
<a href="http://www.ogre3d.org/>OGRE 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.
Strictly speaking Ogre is just a 3d engine. But yes, would be nice to hear how people see this comparing against ogre + pile of open source libs + custom game logic core.
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.
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.
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.
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.
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.
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.
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.
I know for a fact Unity powers some of the largest mobile releases out there, so that list is probably incomplete. I've also seen it be the default choice for 3D mobile development at at least two more top studios I've been talking to.
I guess the key phrase there is "fairly successful".
I'm struggling to think of a game that has been an outright hit that has been built on top of unity.
Depends on how you define successful. Unity games tend to be built by smaller teams and therefore don't need to sell millions of copies to be a financial success like big studio games do.
I mean Indie games specifically. The most successful indie games I can think of (e.g minecraft / braid) didn't use any particular monolithic engine.
What I'm wondering is whether this is simply a co-incidence or whether it's that the most successful Indie titles are ones that take big risks in terms of introducing wildly different gameplay and perhaps using a monolithic engine like Unity makes building such a game more difficult because the engine itself will be inherently opinionated.
In other words, if you make a decision on which technology to use before you have a complete game design are you in fact reducing your risk/reward without necessarily realising it?
The industry titans can afford to develop "any" amount of custom tech, subject to schedule constraints, since the art and marketing budgets tend to vastly outweigh the engineering now. But in the last decade, they've tended to shy away from really ambitious tech projects, favoring incremental improvements to a general world-simulation model that applies across all the typical AAA genres. In their risk assessments, they've decided what kind of product and technology is being made early on, so that the bigger expenses aren't in danger. As well, sticking with the same toolset allows it to be further refined.
Indies, on the other hand, have a lot to gain by taking on ambitious technology and de-emphasizing the costly assets - and usually, the technology itself isn't risky, so much as it is just an "unknown engineering challenge" - something that could be a few days or a few months. Something like Braid or Minecraft can be achieved by experimenting and chipping away at the concept over a few iterations. Minecraft's earliest versions didn't have a lot the "big features" that are in the game now.
But it's also incredibly scary to take on those projects all alone, so the majority of indies aren't even going to consider it. Indies are looking for "easy" too, even if it's bad for them from a business standpoint.
I do think that engines like Unity have a lot of value and can even be extended to include some new technology. (I started working on something that builds on Unity's physics system recently - and it shows some promise to be a unique product) But the people who are taking on the unknowns just tend, statistically speaking, to be the people confident enough to write everything themselves too.
>perhaps using a monolithic engine like Unity makes building such a game more difficult because the engine itself will be inherently opinionated.
KSP is actually a good example of this as well. They've had to make a few design decisions because of engine limitations. But it's also let them get a game that's quite good that's developed a dedicated following fairly quickly.
Wasteland 2 would also be a project to watch. They're one of the highest profile projects to go with the engine.
I think it is more of a difference between experienced vs inexperienced. Unity hasn't been around as long as the devs behind braid, super meat boy, or minecraft have been making games. Most of your experienced indie devs will already know how to program, or already have a game engine they like to mod. So you are going to have to wait a few years for kids who picked Unity over OpenGL or Half Life mods to become experienced enough to make something great before you can really make that call.
I dont know for sure, but I dont think games like Fez, Super Meat Boy or Braid used Unity at all. I think they must be mostly OpenGL?
This brings up an interesting point though. For those starting a carer in "Indie Gaming" should they migrate to Unity or it they can learn OpenGL they should do that?
Unity comes with a hefty price tag though, I think $1500.
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 the cheapest game engine on the market.
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.
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.
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.