Torque Powered (now OpenSource)

[Kornman00]

Demo video as seen at GDC 2010 (loops around at ~2:30)

ol1oO2PxKws

Torque has come a long way. Personally, some of the internal architecture still has a way to go but they've really improved the ability of the engine over the past few years.


Now for the real question at hand: What goatdamn song is that? Does anyone know, or better yet, have it? I have been looking for it for about a year now. I could have sworn it was in a NFS game too (but never found it on any of the soundtracks).

[jcap]

The song is "Genesis" by Justice.

http://www.youtube.com/watch?v=ThKNt-GY1ww

Torque is pretty impressive. I had no idea the engine was that flexible.

[teh lag]

I've also heard that song before. I think it's by Justice, but I'm not sure...

e: jcap'd my ass

[Kornman00]

Thanks


Yeah, I'm looking to make my future endeavours with Toqure (with my own improvements; assuming Bungie doesn't license their stuff, then I'd just drop Torque like an old toy) and the Bullet physics library. Was considering PhysX a while back but ever since nvidia got their dirty nasty mugs on it, it's taken a turn for the worse IMO. They also have failed to make a Mac port these past couple years. Very disappointing product that had potential. At least with Bullet the code is open source and can be compiled for which ever platform (PC, Xbox, etc) I'm targeting. That and the creator is a previous Havok employee. As for Havok...their licenses are HOLYFUCKINGSHIT$$$$$.

[flibitijibibo]

IIrc, Llama Juice's final project used Havok, and it was a BITCH to get it working apparently.

Torque looks amazing though. I haven't seen it since Marble Blast (which was an amazing, hilarious, and under-appreciated game).

[Warsaw]

The statement "Torque has come a long way" couldn't be more...understated. If I weren't in the know, I'd have said "No fucking way that's built from the same shit that powered Tribes 2".

Catchy tune.

[Heathen]

played most of those games bcause most are free

[Kornman00]

Good news, everyone! T3D is going open source! Well, on GitHub. I don't care for Git. Personally, I prefer Mercurial. Anyway, they're releasing it under the MIT license

http://www.garagegames.com/community/blogs/view/21875
http://www.garagegames.com/community/blogs/view/21876

[Zeph]

Did they at least write interfaces for people to code with?

[Kornman00]

...what?

[Zeph]

lmgtfy (http://www.tutorialspoint.com/cplusplus/cpp_interfaces.htm)


From what I recall talking to people about Torque when Snaf was trying to do his thing, the engine was very barebones and required a lot of code from scratch to manipulate a simple game object. I seem to recall you in particular talking about what a pain it was to try and organize AI to behave more like a military unit. Was that not because they didn't take the time to organize enums/structs and pure virtual functions you can initialize to work with?

If Torque's source had that, then I greatly misunderstood people's problems with that engine.

[Kornman00]

The engine isn't tailored to any one type of game, though the stock T3D product came with some example projects for FPS-types and I think a racing one as well. They also sell various asset packs, including genre packs: http://www.garagegames.com/products/browse/genrekits.

Torque is kinda like Unreal as I understand it, where you can work with the engine without actually touching any of the C++ code, as it comes with its proprietary scripting language (that fucking uses the .cs extension). Objects support dynamic properties so you don't need access to the C++ code to create custom game objects. Though I wouldn't make an entire game just through scripts and the stock engine.

IMHO, the engine is rather amateur. Yes, they have a capable GFX engine, but the codebase is piss poor in the organization department (with so many different actual engines, that work off the same core, they would be better off doing a similar framework setup as Havok uses for their array of libraries). Times and tech have changed, but the engine really hasn't.

The code itself is also very bloated. A lot of debug data is still compiled in release builds. If your game isn't meant to be modded post-ship, they should have a *real* shipping build config which doesn't retain the hundreds of Console::warnf or whatever, etc calls and __FILE__/__LINE__ expansions (the engine also uses RTTI). Back in 2010 or so I actually went through and implemented a C macro system for easily turning such information off by various #defines. However, since they just shat down .exes that installed the source code and tools I didn't want to fuck with trying to merge their changes in with my, dare I say fixes, on every new release. So I gave up the effort. At least now they'll be able to more easily accept patches and others will be more easily able to version control when shit rolls down the GG leg.

I actually did a data structure analysis back in March. Before my mind was blown and I said 'fuck this' I had a debug log dumping on startup


Build Config: release

8 WeakRefBase
C StrongRefBase
14 EngineObject
14 ConsoleObject
6C SimObject

8C NetObject
2C0 SceneObject
18 ProcessObject
2D4 GameBase
860 ShapeBase
B74 Player
2788 Vehicle
2AA4 WheeledVehicle

70 SimDataBlock
90 GameBaseData
1E8 ShapeBaseData
3C90 PlayerData
2E4 VehicleData
5D4 WheeledVehicleData

All sizes to the left are in hexadecimal. Notice how large the definition (think a .biped tag) for *single* Player is. That's 15,504 bytes, not including any data like strings or lists that are allocated by the object. Just sizeof(PlayerData). Then their game state (ie, every active instance in-game) for Vehicles starts to pile up. This was in a 32-bit release build (although debug builds don't include that much debug members in the classes anyway). I don't think there's been any real low-level programmers on the main dev team over at GG.

IMO, the engine really needs to be redone. Or they can just keep what they have and market towards just indies.