Sign in to follow this  
GenuineXP

Hiding Underlying APIs in Engine Design

Recommended Posts

Hello. I've been working for a long time on my little game engine. :-) I was wondering about a simple design issue involving the APIs I'm using to develope it. Although I'm not planning on releasing this engine for others to use (mostly because it's probably far, far under "par") at the moment, I'd like to design it as if I were. Should the underlying APIs used by the engine be transparent? That is, should users of the engine not have to know anything about those APIs? Of course, the idea of the engine is to keep a game developer from worrying about technical implementation details and fiddling with low-level APIs, but what about certain constants and data type? For example, I'm using SDL to handle input, and the classes used to get user input take several SDL data types as arguments when polling for events. Is it necessary to remove these SDL enumerations? I could easily define my own enumerations for keyboard keys, for instance, and then map them to the SDL enumerations, but... is it necessary? For example, what's better here?:
...
if (Keyboard::PollKey(SDLK_SPACE)) { ... } // Uses SDL SDLK_SPACE constant.
...
if (Keyboard::PollKey(XKEY_SPACE)) { ... } // Uses some XEngine constant I could define.
...
Users can also choose whether they want to poll input devices for events or listen for events that are broadcast automatically when one occurs. In fact, it's possible to access the SDL event structure that the engine uses internally to process events! Would it be worth defining my own constants for events and creating my own structures for users of the engine to make use of? It is true that many of the SDL event information is not (yet) used by my engine. Also, some engine classes have accessors that return API data types. For instance, my Texture class has a method called GLID() that returns the texture name of it's associated OpenGL texture in video memory (of the type GLuint). This is necessary for the Texture class to communicate with other graphics classes in the engine. Should this sort of data type be hidden? Should the accessor return an engine type or built in type and be cast by client classes into a GLuint? Thanks for you input. I really appreciate it. :-)

Share this post


Link to post
Share on other sites
Engines generally allow the user to use it with no need to use or have knowledge of the underlying APIs. As the above poster said you should create Interfaces and create different Implementations for each API you want to include. Then the user needs only to create an interface which uses the API they wish to use. All the hard, APi specific work is done deep down in your engine.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this