Torque Powered (now OpenSource)

[Zeph]

lmgtfy


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.