A Quick Introduction to KGLT

Those of you that follow me on Twitter, or have the pleasure to listen to my waffling in person, will know that I'm working on a game engine - although I'm still not convinced that's the right terminology. Let's call it a "game framework".

There's a well known saying in the game development world, it goes like this: "Write games, not engines". And, it's actually really good advice, there are plenty of game engines out there, many of them open source and free to use commercially. On top of that, writing a game engine is hard, really hard. It probably is the most difficult user-space application that you can write, and only the insane or brilliant even attempt it.

I must be insane.

Now that I've painted a clear picture of why writing a game engine is an extraordinarily bad idea, let me explain why that's pretty much exactly what I'm doing.

Every so often I grab an old PC game from my shelf, shove it in the DVD drive and prod around the folder tree. If I find something that looks like it could be a new texture format, or model format, I can't resist firing up a Hex editor and trying to decipher it. I've had some moderate success too. I successfully reverse engineered the Ignition texture format for example. And it was during one of these reverse engineering stints that I realized I needed a game engine.

The reason was that, reverse engineering something like a 3D model format is a bit of trial and error, for example "Is that set of floating point data the vertex positions or the vertex normals?" might be the kind of thing you can't decipher just by looking at it in hexidecimal. This is why I needed a game engine, I needed a way to construct a mesh from what I thought was mesh data, and I needed to be able to iterate quickly if a certain block of data wasn't what I thought it was.

After trying a few game engines, I couldn't find anything that did exactly what I wanted. I found loads that did far more than I wanted, but I just needed something simple. And then KGLT was born.

I started by creating an OpenGL window with SDL, then I needed a way to create meshes, then a way to manage those meshes, then a way to skin those meshes, then I needed to render them faster... before I knew it I had been coding this thing for a year and it had grown beyond what I set out to do, hell, I never did get around to reverse engineering that format!

So, now KGLT exists. It's on my GitHub and it provides a really simple API for building up a 2D or 3D scene. It's written in C++ (although you don't need to worry about memory management or any of that nonsense, it's all taken care of). The whole thing is based around a few core concepts:

• When you create a Window, it owns a Scene.
• Each Scene can have multiple SubScenes, although a Scene starts out with one.
• You can add each SubScene to the Pipeline for rendering by specifying a viewport, camera, target and priority.
• To render things, you create Entities from Meshes. A Mesh can be shared across Entities.

KGLT is different to other game engines, it doesn't try to be ultra-flexible, or ultra-powerful, or all encompassing. It just provides a common framework for building on top of, a bit like Django in the web world.

KGLT is still in heavy development, but it would be good to get feedback/other contributors. So if you are into game development and you fancy playing around with it, give it a go! Let me know how you get on!