23 replies to this topic

[lono]

I am looking for a robust framework that can work with multiple engines, and which also has the initial game loop and management setup.

Essentially I want a Framework that I can simply switch between multiple engines and simply get stuck into making a game / demo.

The purpose for this is to give common ground for testing the current engines available on a like with like basis. I have same artwork ready for each engine, I now want the same game framework.

So I can truly evaluate the performance of engines.

I am currently looking at Yake but is there any others?>

[dave_]

lono said:

I am looking for a robust framework that can work with multiple engines, and which also has the initial game loop and management setup.

Essentially I want a Framework that I can simply switch between multiple engines and simply get stuck into making a game / demo.

The purpose for this is to give common ground for testing the current engines available on a like with like basis. I have same artwork ready for each engine, I now want the same game framework.

So I can truly evaluate the performance of engines.

I am currently looking at Yake but is there any others?>

I'm afraid that doesn't exist. You'll have to export your artwork for each engine, and map your gameplay code onto each too.

Check the engines database link at the top of the page.

[lono]

All the artwork is custom to the specific engines I will be testing. They just happen to be the same models, maps etc with the same textures.

The difference they are exported for each specific engine.

What I am looking for is an Abstracted Game Framework that allows for it to be connected to an engine using proper abstraction and then hook up the various models etc. Obviously some parts will need to be rewitten to suit the task at hand, but I find it terribly hard to believe that there are no Game Frameworks out there.

Yake is out there, GOOF is out there and there are surely countless others. I'm just looking for options on Game Frameworks to have sit ontop of the engine to ensure that I can get the best possible control environment.

[SpreeTree]

Just to clarify, are you looking for a framework that sits onto of multiple open source engines (so a game framework that works equally well with Ogre, Crystal Space, Irrlict for example) or one that supports multiple API's (Directx, GL, Fmod, AL etc.)?

If its the former, then your def. going to be out of luck. People (like Yake) generally will not take the time to generalise multiple engines (whats the point, who has the time, and why would you want to do it?), and usually build a framework around something they prefer (with is what Yake started out as I think, as a wrap around game engine for Ogre... Or was it something else?)

If it's the later, you will be in more luck, but you will be hard pushed to find a general 'game framework' - people generally want to write systems for multiple rendering API's but fon't go much further (Ogre as an example).

Generally, if people want something like that, you have to build it up yourself, and yes that does take a fair bit of coding to do, and do well.

What do you find lacking in Yake and GOOF?

Spree

[Nautilus]

He said "Abstracted Game Framework", so I believe he means
a Software Abstraction Layer to abstract Game Engines' interfaces.
Much like D3D and OpenGL do abstract the hardware =/
And then he wants to use it to test Engines performances.

In my opinion this concept is flawed, Lono.
Assuming that one such software exists, the mere fact of it
sitting between YourApp and the EngineUnderTest would
compromise the output.
Game Engines are already layered onto Direct3D/OpenGL API,
which in turn are layered onto the Hardware's Driver, which
finally sits in front of the Hardware itself.

Normally a game app would position itself in front of the graphics API (or H.A.L.)
Like this:
GameApp -> H.A.L. -> HWdriver -> Hardware!

(Ideally it should sit directly in front of the Hardware, bypassing the driver itself)
(Just think at the boost. Maybe in future nVIDIA/ATI will release their own Engines.)
(Only 1 layer between you and the HW... and The Best Possible Layer Ever too!)
(I dream too much...)

Using Game Engines you shift your app towards the back row.
Like this:
YourApp -> GameEng -> H.A.L. -> HWdriver -> Hardware!
Performance decreases. Speed of development and other advantages
are gained.

Using the Software Abstraction Layer you ask for, then,
you shift your Bench app back once more.
Like this:
BenchApp -> S.A.L. -> GameEng -> H.A.L. -> HWdriver -> Hardware!

Detected Game Engine performance would be lower than what would
normally be.
It's also possible that the S.A.L. doesn't make proper use of every
supported Engine.
In such case you'd get even more reduced performances.

Therefore if you want to properly Benchmark a Game Engine,
you have to write dedicated code (YourApp == S.A.L.)

Ciao ciao : )

[lono]

Let me make it simpler. What I am looking for is a framework that consists of gameManagers, Factories, Callbacks, Controls etc.

This "Game Framework" gives me the ability to directly create the game.

This then sits beside the engine as the gameFramework and I hook it up into the engine.

If I am still not being clear let me know and I will try and work a way to communicate this to you

[Nautilus]

Yes please, try and explain again.
The framework you just described makes me think to a game engine. I'm confused...

[lono]

Right let me start again :p

You have a graphics engine which handles the graphics pipeline and the graphics API etc.

You then have a game engine which sits ontop of your Graphics Engine, and links together other components such as audio, networking, ui etc.

Granted alot of Game Engines do contain game looping structures etc.

Now what I am looking for is a framework that sits above this, that contains basic logic. That more accurately manages the game aspect of the code. By this I mean that it is actually established as a Game Framework structure so that I can spend a little time hooking it upto the game engine and then just get stuck into the game programming aspect.

Consider it a set of files that would be a more optomised way of laying out and programming a game. Irrespective of the engine and the tech behind it.

[dave_]

as I've already said, they don't exist

[sirfalas]

Yes, it does not exist as dave said. And if you really want to know why, its because every game engine works in a different way.

They initialise the graphics in a different way, they render the output different way, they handle gameplay code in a different way and so on.

To have such a framework, one has to get the engine, documentation for the engine, create code for that engine and provide a simplified interface for you that hides away most of the details. Now he has to do this for one engine. Multiply this problem with that fact that there are literally hundreds of engines. Compound the problem somemore by the fact that not all engines are free (such as the unreal engine or the source engine). Further compound this problem by the fact that not all engines are multi-platform. Some only work for windows. Jiggle up the problem by the fact that different engines handle artwork in different formats.

Think im done? Hell no. Further magnify the problem with the fact that it's going to slow down performance because the code has to go through another one more layer. Now finally, magnify the problem infinite times by the fact that no one has that much time to do so much work for free. If someone has such a framework, don't be surprised if they charge you a big price.

I could go on and on but you get the point. :)

[Sol_HSA]

I'll try to say this in another way.

If such thing existed, all game engines would work the same way, and thus all game engines would pretty much be the exact same, and thus you wouldn't even need a wrapper. =)

[eddie]

Well, there are such things like Gangsta Wrapper. I've never used I before (but I love the name), but here's the summary:

Quote

An abstraction layer allowing the use of different physics libraries through a consistent API. It's possible to swap between different physics engines without altering code. Interfaces are provided to connect it to your visualisation framework of choice.

Build enough on top of it, and other 'game' items, and you've essentially got an engine. :)

[lono]

Cheers Eddie

I have found a few others, some contain more features that others.

If you design and develop the framework correctly it shouldn't care what engine it's on, nor should it limit the game that you are making. I'll check out gangsta wrapper, and when I get home I will post up the links to the others that I have.

sirfalas said:

If someone has such a framework, don't be surprised if they charge you a big price.

I have no issue in paying for such a framework.

[eddie]

Well, if you abstract enough, then you technically can 'firewall' your engine/application layer and just have things 'work'. But that isn't free, and it isn't easy.

But some libraries/API's are missing some things that others have, so if you truly 'wrap' those types of items, you're stuck with either the lowest common denominator, or something that'll work - but run ridiculously slow on some implementations.

Personally, the only thing I'd want something like this for is either rapid application development, where I can get a prototype up and running fast and I don't *care* what's running underneath it (which is what I'm learning Flash for), or if something like this would be able to showcase certain features of each of the underlying components, so I could decide on which engine I want based upon such output.

The only problem with the latter, is that to get the *best* output out of an engine/API/whatever-is-under-the-hood will take a *lot* of time -- I worked at EA for years, and even they struggled with getting something of that enormity working.

In all reality, most programmers will tell you that it almost makes better sense to code your own engine, as you can tune the parts that matter to you, and you'll make a better game as such.

Anyhow: I don't mean to dissuade you, but just to give you some perspective on what other people here are saying.

Cheers! Good luck in what you're searching for.

[monjardin]

It sounds to me like Yake is exactly what you want. Ogre3D is the only rendering plug-in out of the box (that I know of), but the intention was for every component to be pluggable. As a result, the development of Yake has been very slow...

If you do decide to interface it with other graphics engines, then I'm sure the Yake team would be happy to add your implementation to the project.

[eddie]

That Yake sounds cool, monjardin. I've never heard of it before.

If it weren't for the fact that I'm sick of being chained to OSS that I take longer to understand than to use, I'd be diving into it.

Has anyone used it before that can comment on it?

[SamuraiCrow]

The original poster said he was looking into it but wanted to know if there were any others. BTW by OSS do you mean Open Source Software or the plural of Operating System?

[eddie]

Oh yeah. :blush: Can't believe I missed that the OP already mentioned Yake. Suppose I glazed over it since it was unfamiliar.

And yes, I meant Open-Source Software.

[monjardin]

When I first heard of Yake (maybe three years ago) I got pretty excited too. It hasn't progressed much, however, and I'm not aware of any outstanding projects using it. Project: Xenocide was using Yake, but I can't even find a working link to them! The last time I tried playing with it I got disgusted at the number of dependencies required and gave up.

To be honest, I probably won't touch it until version 1.0 (if that happens) unless I hear of something special that makes me want to use it and help out. I guess that's the plight of most open source projects.

For the original posters needs, it seems like the only place to start -- other than from scratch. ;)

EDIT:

I'm looking at the YAKE dependencies page and they don't seem that bad (boost & TTL). However, every plug-in wraps another library -- of course -- and each of those may rely on any number of other libraries. Also, I recall some of them having overlapping dependencies on different versions. Working from source control on for every library probably helps keep in sync, but what a headache! :wallbash:

[sirfalas]

Ah, so there does seem to be frameworks like these. So I guess I will apologise gracefully for my 'impossible' comment earlier. Sorry.

But I was thinking that the OP wanted some where he could do the following:

"

void main()
{
.....
engine.UseGraphicsEngine("orge3d");
engine.UseSoundEngine("fmod");
engine.Load3DModel("MyCustomModel.format");
engine.Load3DSound("AnoterSound.format");
engine.Run();
.....
}

That was what I thought when he said "Essentially I want a Framework that I can simply switch between multiple engines and simply get stuck into making a game / demo."

So does yake provide that? I did not look at it at much detail.