Development Perspective: Graphics APIs or Graphics Engines?

In this post, I'd like to take a step back from personal projects and happenings and discuss a point of view that was raised in dialogue during a class:

Student: "Which is better: Learning a graphics API or learning how to use a graphics engine?"
Professor: "Well, what are you trying to do?"
Student: "I'm a game programmer! I want to make games with cool graphics!"

Those were words spoken and raised an interesting question which made me think about this from a game development standpoint: which is better to learn?

Well, after digging around, I came up with quite a few different answers, so here's my take on the issue and the pros and cons of the two approaches.

When we talk about graphics APIs, we assume we're talking about something like DirectX or OpenGL, at least in the games world, or whatever platform specific graphics API we're using.

What we gain from knowledge of an API is usually allot of nice information on how the graphics pipeline is handled for that specific type of system. This allows us to not only know the process of what happens when we attempt to place, light/shade, and display the objects in our scene, but it also allows to know how to perform lower level, specific calls to enhance or alter that pipeline, which allows us in many ways, a high level of customization and flexibility with our graphics.

What we often lose here though is the bigger picture. With doing low level shading designs and protocols, tweaking the OpenGL state machine for specific functionality, or making DirectX properly flush our vertices to the graphics card, we often do not gain a clear perspective of the needs for content management, scene control and organization, or gain the high level flexibility of being able to make scenes on the fly without having to specify low level constructs, prefering to develop our own methods or ignore previous methods for obtaining niche performance goals or what we consider cool graphics effects.

When we talk about graphics engines, which are often mislabeled game engines, we are usually talking about the rendering engines behind things such as the Unreal Engine (not the engine itself, but the rendering part of it), Open Scene Graph, the Irrlicht Scene Engine, and similar products.

What these offer is usually a higher level of abstraction away from the tiny lighting functions and placement functions, and give us access to many fundamental function and entities for placing and creating graphical scenes. With this comes content management, allot of extra math done behind the scenes for culling and clipping we don't have to implement, and much higher ease of use.

Here though, we lose allot of the customization and performance upgrades we can have by directly interacting with the API. Like it or not, most of these graphics engines eventually play with DirectX or OpenGL to accomplish their goals. As such, the process in which everything happens behind the scenes is often concealed from us with these engines. Because of this, when we attempt to make personal customizations for fancy or advanced graphics, we often are forced down to the API level, and usually have to conform to the order and organization specified by the engine, unless we want to get errors.

Hence, my opinion on this matter is this. For someone that wants to just make a game, without the need or want to make lots of special graphics customizations or the gut to live with what the engine offers you, then going with an engine is a much easier and faster way to get your game running. However, if you want to learn the ins and outs of how the graphics pipeline works to streamline the graphics performance and be able to eventually create more advanced graphics effects, learning an API (or multiple) is a much better approach. Personally, I choose a little of both, liking to delve really deep into the specifics of an API to pull out good performance or awesome effects, while developing those skills to fit into an engine like construct.

Working Architecture

So, finally now that classes have died down and I'm on the last stretch of my BS degree in Software Engineering, I am going to cover future plans and the system I have been devoting some of my spare time to, the Inferno Game Engine.

I will be finishing my BS this fall, in November 2009. Following, I have decided to enter into the MS in Game Design and Development, with a focus on Game Engine Architecture and Design and Creative Narrative / World Creation. Instead of going straight into industry, I decided that I really needed more projects under my belt, which RIT's GDD master's program offers. However, I'm still skeptical to a degree about the prowess of such a program, as often academic programs for games do not produce the best game designers, programmers, architects, and the like. For that, I will rely on my SE background.

Now, to get to the meat of this post, I have been working for the past 3 years on a game engine primer, as I like to call it. What the primer does is specify the core classes and interfaces for making a game system which revolves around having in game entities communicate with one another, how they store and track their arbitrary state information, and how they act on one another. While I could have slapped something like this together easily without much forethought, I've decided that I really need to design it out and weigh all design decisions properly before just allowing the system to be programmed. For that, I've gotten quite a bit.

Below is the basic flow of the primer (If the diagrams don't appear right, try clicking on them to get a better view of the diagrams):



The above image gives an overview of the idea of the primer, and how it can be used to create bindings which are then used for making game or simulations, ideally.



The above image here represents the basic class structure of the primer. The movement from left to right moves upwards in the chain of complexity of the different class elements, as it is in short, a large class hierarchy of increasing complexity, to allow for the most dynamic and flexible interactions and storage of entities possible.



The above image here was playing around with how the concept of updating would work for the system. It appears like a standard update loop. The design here is not final.

My reasons for posting these diagrams is because, eventually, I am planning on making the primer and the related bindings open source. Currently planned are Irrlicht Engine bindings and XNA bindings, though more can be added later. The reason for this, as specified, is to create the means by which entities can interact and control themselves. I feel, personally, that there are not enough powerful open source tools for the game community and that powerful, great tools should not be limited to the powerful or those with millions of dollars of funding. While this may not control the quality of games directly by limiting only to those groups, what it does do is provide better tools that will support burgeoning game developers.

And with that, I will leave it for now. I have more work to do, but these should help others to get a better idea of what the engine does, and what I am engaging myself with. Until the next time.