Hi All, I am working on simulation based on TGE (Torque Game Engine). The clients want that I design the simulation in such a way that it is independent of the underlying Engine being used. I worked on it for some time and came to the conclusion that this wasn't that easy and it dawned upon me that such a thing may not be possible. Since I have been involved in game programming I have learnt that Engines should be designed in such a way that they are Game API independent. So that different sorts of games can be written using the same engine. But what my client wants is that the Game API be written in such a way that it is independent of the underlying engine. So that if we someday decide to change the underlying engine the Game API remains the same. I came up with a couple of solutions but none of them guaranteed complete independence from the engine. If we think about it this idea conflicts with the rules of software engineering as well. Since if an application is based on two components both of them cannot be independent of each other. One will be independent and the other dependent. Any engine that we might use later on will always be designed to be independent of the game API, so my question is that is : Is is it possible to design a game API that is highly independent of the underlying game Engine. If so then i definitely need help on this. Regards, Enygmyx.

Certainly it is possible, but you have to consider the diminishing returns and determine if the effort is really worth it.

EDIT: I have a nagging feeling your terminology is backwards (the use of "game API" in particular makes me nervous, it implies the "game" is a layer of abstraction and there is something above it, and this is usually not the case -- usually the game is written on top of the engine's API, which is written on top of deeper APIs; if the engine communicates or knows about the existence of the game written to it at all, it is via an interface (and thus API) defined by the engine, not the game, and the game itself doesn't have an "API" since it doesn't have clients writing to it). If that's true, my answer might not be what you are looking for -- if so you should clarify.

Quote:
But what my client wants is that the Game API be written in such a way that it is independent of the underlying engine. So that if we someday decide to change the underlying engine the Game API remains the same.
I came up with a couple of solutions but none of them guaranteed complete independence from the engine.

So you are essentially saying, here, that you want your simulation to call into an "engine abstraction engine," right? So that you could swap out the Torque engine for, say, the Unreal engine? And so on?

Again -- this is technically doable, but rather pointless. Your "engine abstraction engine" would need to support the union of the feature sets of all the engines you'd want to support, and that in itself is a mammoth undertaking (and would also be catering to the least common denominator). Nevermind making everything play nicely together and achieve similar performance and quality. It would just take far, far too much work. And in the end you've gained nothing: the likelyhood you'll actually need to swap out engines regularly is next to nil, and your simulation is still written to a specific engine (the "engine abstraction engine") so you're not really any more abstract (you could write another "engine abtraction abstraction engine" for even more generality, and continue this ad nauseum -- it's turtles all the way down). The cost/benifit ratio is already well out of your favor and it is only getting worse.

Tell your client to deal with it. The desire to abstractly support any engine "you might want to use in the future" seems born of a fear of writing new code. That is a dangerous thing. The selection of an engine is one of those fundamental early development decisions that needs to be made and stuck with -- just like language. You're writing in a specific language, right? What happens if you want to change that language in the future? Do you instead write in a more-abstract language that can be "compiled" to any other language you may want to use in the future? No. You just start writing in a different language. Engines are the same way.

Pick one, and go with it. An engine is already an abstraction; abstract it further and the return on your investment diminishes to insignifigance and you just waste time.

Quote:Original post by vetroXL
It is possible. Research Design Patterns.

I knew that it was possible but i wanted to find if there was a feasible way to do that in a restricted amount of time and resources. As jpetrie said there is a way to achieve this but its like a "Brute Force Technique" and there is a reason that we don't use those.

Could you explain further, possibly by example or references if there is any other feasible method to do this.

Quote:
EDIT: I have a nagging feeling your terminology is backwards (the use of "game API" in particular makes me nervous, it implies the "game" is a layer of abstraction and there is something above it, and this is usually not the case -- usually the game is written on top of the engine's API, which is written on top of deeper APIs; if the engine communicates or knows about the existence of the game written to it at all, it is via an interface (and thus API) defined by the engine, not the game, and the game itself doesn't have an "API" since it doesn't have clients writing to it). If that's true, my answer might not be what you are looking for -- if so you should clarify.

Well what you are saying is correct the only reason that I used the term "Game API" is because the Game serves as an API for the scripts. Otherwise what you said is exactly what I had in mind.

As for the solution, I already had this in mind but its not feasible by far because of the time and resource constraints that I have.

Thanks for reply, it reaffirmed my belief that creating an "Engine API" independent "Game" was not a good idea.

You should be separating your control code from your rendering code anyway; using the model-view-controller paradigm is a very, very good idea for any piece of software bigger than a breadbox.

If your 'game' exposes an API for scripting, and much of the actual game logic is not in the 'game', then there is a fair point here: the script shouldn't have to know about what the engine is. But I'm with jpetrie's nagging feeling here: I think someone has his terminology mixed up, as there's generally no such thing as a 'game API'.

Quote:Original post by Bob Janova
If your 'game' exposes an API for scripting, and much of the actual game logic is not in the 'game', then there is a fair point here: the script shouldn't have to know about what the engine is. But I'm with jpetrie's nagging feeling here: I think someone has his terminology mixed up, as there's generally no such thing as a 'game API'.

Well maybe I have mixed up the terminology a bit but hopefully you get the idea of what I meant.

I'll try and explain myself a bit more. The Engine (TGE) is at the bottom, on which lies our Game/Simulation and on the top are the scripts. You are right that most of the logic is in the scripts. But the thing is that we are using torque scripting for this. Both engine and game specific funtionality is exposed to the scripts. In this case the scripts are not independent of the engine. If we wanted to do that we would have to write our own scripting module that communicates only with the Game Layer and knows nothing about the engine layer. In order to achieve that we would have to wrap every call from the engine layer so that it doesn't communicate with the scripts directly instead it goes through the Game Layer. My own opinion is that would amount to a lot of work which requires experience (which I lack).

Thanks for your valuable input. Hopefully i have made myself somewhat clear.

Regards,

EnygmyX.

Okay, yeah, that's roughly what I thought you meant. The terminology is kind of undefined in this situation: is the 'game' in the middle tier or the scripting tier?

Anyway, since Torque is (as I understand it) a pretty complete game engine, it's pretty unlikely you'd ever want to switch it, as all sorts of bits of your game will rely on it. So I wouldn't worry about engine independence too much, though it is a good idea in principle. (IMHO, engine independence for the game logic is more essential if you have a separate graphics engine, sound system, physics engine etc where you might want to use a different version of any of them. In the situation where you use a full game engine it's unlikely to matter.)

Having said that, some clarification on why your scripts need engine functionality might be useful in finding parts that don't need to be going directly to the engine. I don't have experience with Torque (it, like, costs money :P) so I don't really know what sort of things it encourages. Generally the sort of logic that goes in scripts should be dealing with high-level game objects and not talking to the engine.