Archived

This topic is now archived and is closed to further replies.

kill

High level engine API design. Please read.

Recommended Posts

Hi. I''ve worked through a couple of engines that are now rotting on my harddrive. Every time the API got better and better. I''m sure a lot of you went through the same thing. If anyone is interested, please post suggestions for the APIs and their organization. If this works out well, we can use this thread to build our own engines.

Share this post


Link to post
Share on other sites
Don't impose on the user a massive class hierarchy where everything is one cohesive whole.

If you make a portal system, make it exactly that, and nothing else which interdepends on anything else. If you make a terrain system, make it that, and nothing which interdepends on anything else. If the user wants to combine the two, then it's simply a higher level piece of code which calls each at the appropriate time. So, don't impose, and don't mix stuff up.

Make default behavior. Make a library which does all of the initialization automatically without the user even calling those functions. In other words, main() or WinMain() is in the library, opens the window, initializes the devices, etc. and then calls the user function. So the user starts his code with an entry point where the user can get to the heart of what he wants to program. Make this the default, but don't impose it on the user. Do it like this:

preStart ()
{
}

postStart ()
{
}

render ()
{
}

preRender ()
{
}

preImageFlip ()
{
}

postImageFlip ()
{
}

etc...

So, the user is responsible to flesh out those functions. He does not need to define the windows, the image swapping, or any of that. All he has to do is define those functions, or something similar. In fact, if he wrote his program exactly as above with no content, he would have a fully functional image swapping 3d program.

Here's how it works. The engine library starts up in main() or WinMain() and is prepared to create a window. But, first it calls preStart(), giving the user the opportunity to change values with set functions. He can change window sizes, do any preprocessing, etc if he wants to. If he doesn't, then the program goes on to create a default style window.

The point is, default behavior exists and will run the program. The user is given the opportunity at all relevant points in the program's life to change this behavior, turn off features, turn on features, change parameters, etc. Relevant points in the programs life include the functions above, but there are probably others.

Anyway, that's just my idea. That's how I would pursue it.



[edited by - bishop_pass on April 29, 2002 2:38:54 AM]

Share this post


Link to post
Share on other sites
Yeah, I do something similar. Basically the game doesn''t run the engine, the engine runs the game.

I have a class CEngine, and a class CEngineEventHandler. You derive your game from the event handler, then in WinMain, just call CEngine::Run and pass it your event handler.


Helpful links:
How To Ask Questions The Smart Way | Google can help with your question | Search MSDN for help with standard C or Windows functions

Share this post


Link to post
Share on other sites
Take a look at the PurpleLib. (www.bunnz.com) it takes this to the OO by defining a standard CGame which can be overloaded by the user... It''s kinda like the MFC, just for games
It''s still under developement, but it''s movin''

cya,
Phil


Visit Rarebyte!
and no!, there are NO kangaroos in Austria (I got this questions a few times over in the states )

Share this post


Link to post
Share on other sites
I really don''t know why everyone likes this architecture so much. For GUI it makes sense, but for games it takes away more then it provides.

Share this post


Link to post
Share on other sites