An engine independant Game API

#1 You mention walk, jumping, etc. That's player movement, and that involves physics and collision detection, and the handling of those varies wildly across engines, specially if between networked and non-networked ones.

Instead of shapeshifting other engines to work with your code, or changing your code to work with other engines, you could aim for the middle ground: writing an intermediate code layer to make the bridge between your code and the engine you're using.

In TGE-case, that would mean writing a class which updates your game logic, and handles the communication between it and the rest of the engine, like informing your game about inputs, and making TGE load models, play animations and so on when required.

Be aware that it's lots of hard work, but sounds worth if you're aiming for something that is significantly different than the existing TGE game classes' capabilities (a gameplay style which would require a complete re-write of the Player class physics, collision and animation code, as example), and if you really know what you're doing: either you're knowledgeable enough to write a robust game logic layer from scratch or you already have one lying around, and prefers using it instead of modifying TGE's classes until they meet your specifications.

#2 Ali,

I haven't used Torque or any other game engine for very long, so I'm not an expert on game engines. However, in my many years experience developing commercial software, I have seen many similar attempts to build an end-all, be-all API to wrap some specific large scale component with the idea being that you can easily switch the large scale component after the fact. I've seen this attempted for databases, GUI's, manufacturing control systems, etc, etc, ad-infinitum. In my opinion, these efforts have by and large failed. At the very least, creating a generic game engine wrapper such that you can plug in Torque, unreal, c4, or any other game engine is going to be a huge task. You'll either end up with a not so useful least common denominator API or you'll have to end up emulating all the features that are present in one engine but not present in the other engine.

My advice is to pick an engine and go with it and forget about trying to code such that you can easily change engines.

My 2 cents.

-Mike

#3 Mike-

I was thinking along the same lines as you, but you have stated it very clearly and succinctly, so I'm off the hook ;-)