TGB for Point and Click, Fighting and 2.5D Games

#1 I just purchased TGB, and would definitely like to know this as well. My ideas for a couple of games follow those same lines.

#2 1. and 2.
Sure, no problem here.

3.
As far as I know, you would have to extend the engine here as that would require some more complicated map setups and probably per-pixel collision detection.

I thought a bit about doing something along those lines to be able to create 2.5D stuff in ZBrush and directly use it in TGB. Would be cool.

#3 Thanks Jeramy and Rene. :)

I have additional questions though:

Regarding 2.5D, does TGB support dynamic 3D objects? I mean like for example, in Resident Evil, the backgrounds may look like 3D but in fact are just 3D scenes pre-rendered in 2D bitmaps. Only the actor (Jill, Chris, etc.) as well as the enemies and other moveable objects are in 3D.

Also, if I'd be after bounding box collisions only (and not per-pixel collision) for a 2.5D game, would that be implementable in Torque Script alone?

#4 I wouldn't consider RE 2.5d, really. I consider most isometric or "fakey 3D" 2D engines 2.5d. I would consider RE and FFVII 3D engines with a 2D renderplane. But that's just my own take on the terminology.

You would have to do some refactoring to the source code to provide 3D models with 2D interactions the way you are thinking of. The way that many games from that perspective are done is by having a simple 3D engine with invisible and visible 3D objects (with collision meshes). Whether the 3D objects are visible or visible depends on whether they are utilized in the view or not.

For example, if you have the main character, a zombie, and a crate, you have three 3D objects that are visible in the view. But you have the collision data which is mostly invisible and extremely simple (often line or large-polygons or extremely simple meshes) as well. You don't render the collision data for the area, but you render the image plane which matches this collision data. That way you can have beautiful (or horrendous, depending on the flavor) areas with no 3D rendering overhead. Then you only render the 3D objects that are mobile on top of the render plane for the camera. All of the 3D objects will use the invisible collision data, but because of the view plane attached to the camera, it appears that they are interacting with the environment in a per-pixel manner (because the rendering is taken from a more advanced scene with the same orientation, size, etc as the simple collision meshes.

I think I'm explaining it badly.

It could most likely be done with TGB and adding collision polygons to your camera areas, with each camera plane being a new area of the level, but I'm not sure about how robust the 3D aspects of the engine are in terms of interacting with those points since I haven't done much on this. I had originally thought about doing something similar back in the day, but never actually got around to it. Maybe I'll revisit it. I think it would be much easier in a 3D engine, though, and I think it would be quite easy to prototype in Blitz3D or DarkBasic or Irrlicht, I think; at least my original, badly related concept of how it is often done.

#5 When you say 2.5D i think of an angled sidescroller. like the arcade Teenage Mutant Ninja Turtles games. or the arcade Simpsons game.
I'm not 100% sure but i doubt that would be a problem. i mean it'll be angled like a point and click (which Rene already said was good) and played like a platformer.
i'm glad to hear that fighting games are possible too. i might have to buy this.

#6 You will need to work on some collision trickery to get solid animation collisions in a fighting game.