Game Frameworks for the PC

Posted on January 30, 2013

Update: I made a mistake and assumed when I wrote this for some reason or another that GLFW was a project backed by Khronos. It is an open source project and a good one at that. I cannot recommend it enough. Sorry for the mistake. The offending paragraph has been corrected.

Update Numero Two: More research, updated sections.

I’m in between jobs right now and am in no hurry to return back to work. When the new year came around I settled into a moment of reflection and decided to set out on a journey to rediscover things that I like about programming. I first learned about programming in order to make video games so I decided to start there. So far so good… I’m loving every minute of it.

I thought that compared to when I typed in my first BASIC program that making a game today would be a breeze. For the most part it is: there are tools like GameMaker Studio and Unity now that we didn’t have when I was a kid. And there are plenty of libraries that will set up graphics, handle input, and do everything you used to have to do yourself. I thought this was great — I could focus on the game-play and not worry about video modes, buffers, and polling!

Turns out that the reality isn’t quite that rosy. Cross-platform game development is still a tricky affair. I’m only targeting PC/Mac with my game. The waters are quite muddy and it’s not entirely clear how I’m going to make it work. There are a bunch of libraries out there but they’re having trouble finding maintainers to keep them updated. And the Gamemakers and Unity’s of the world are just too expensive to release my first commercial game with.

How Bad Is It?

As a lone game developer you basically have two choices: license a commercial engine like GameMaker or Unity or roll your own. The first option is a little beyond my grasp right now due to the costs involved. The second option is a little disparaging; rolling your own framework is difficult and it takes a lot longer to start seeing the spoils of your effort. However it can also be more rewarding since you can custom tailor the framework to the needs of your game and reap the benefits of knowing how everything works right down to the metal.

So I’ve been doing a lot of research into the libraries available to the independent developer and here’s what I’ve come up with:

SDL

This is probably the most popular option. It’s open source, cross platform, and includes modules for sound, a plethora of bitmap file formats, and fonts. I’ve used SDL quite a lot myself and have played many games powered by it so I know it’s rock-solid as well.

Unfortunately the 1.2 runtime library seems rather broken on OS X 10.8 as of this writing. That means dynamic language bindings like Pygame and lispbuilder-sdl don’t work right now. It’s not a huge set-back but developing games with Common Lisp is pretty awesome.

If you go with C or C++ then 1.2 still works great.

Although the 2.0 branch is under heavy development. The new version is looking really promising. It’s entirely hardware-accelerated under the hood from what I understand. I’m not sure I know what that means (OpenGL?) but I will definitely be taking a poke. It’s still not considered production-ready so I’d consider waiting unless you like living life on the bleeding edge.

Allegro

Allegro is pretty much the same deal as SDL. It also has a new version coming out that is hardware-accelerated (both libraries have traditionally relied on software rendering). Not much else I can say about it.

IndieLib

I was surprised to see that progress has been made to port this library to platforms other than Windows/Direct3D. It’s now able to target OpenGL and the latest versions even run on Mac. This is the library that powers Aquaria so it has to be fairly decent.

It’s unique from other libraries discussed so far. In addition to handling graphics, input, and the main game loop it also has an entity system baked in. If you don’t know what that is I suggest looking it up. In short an entity system is an efficient way of representing game objects in your code without using class hierarchies (like the dreaded GameObject class that everything must inherit from… shudder).

This library is still under a fair amount of development. I haven’t been using it much since it was Windows-only until fairly recently. However it seems that the project was forked and became what it is today because its primary developer does not have the time for it that he used to. I might need to check this library out before I can give a final word on its stability and usefulness.

So… ymmv with this one. The Mac support is recent and may still be error prone. It’s built on top of SDL afaict.

Cocos2D-x

In short, Cocos2D-x could potentially be the best library ever for independent games developers. It targets the widest variety of platforms (Mac, Win, iOS, Android, HTML5) and has support for a variety of essential tools like the Tiled editor and various texture atlas and animation formats. This library could rival the offerings from commercial engines like GameMaker and Unity.

However the way the project has designed its platform support will make some platforms lower-priority than others. Fonts on Retina devices are currently not displaying correctly at all but the issue has just been pushed back to some indeterminate time in the future. It won’t be fixed in the next release because the focus of this project is on mobile and web. That’s great news if your target platforms are iOS and Android and bad news if you’re going for Mac/PC as I am. Retina support isn’t a deal-breaker but it does indicate that the Mac and PC platforms are second-class citizens in the Cocos2D-x ecosystem.

The primary reason for this, I think, is because Cocos2D-x has been designed in such a way that it uses the target platforms’ native APIs as much as possible. Instead of targeting GLFW it uses Cocoa’s EAGLView on Mac and Window’s own APIs on that platform. The developers could relieve themselves of the burden of maintaining these platforms by moving to GLFW but I don’t see that happening.

Why Rolling Your Own Is Often A Bad Idea

I want to make a game. I have a limited budget and am constrained mostly by the time available to me. Writing a framework will take a lot of time away from writing my game (spent mostly learning about the state of the art and such).

It might be more beneficial to sacrifice a little sanity, money, or features in order to use what’s already available so that instead of writing event loops and compiling shaders I can instead be focusing on getting my game going.

But there’s always that nagging voice in my head that says, “If you’re going to do something you might as well do it right.”

Why I Might Roll My Own

With the exception of IndieLib, none of the frameworks I’ve researched are using modern OpenGL. As far as I can tell SDL only supports OpenGL 1.0. I’d like to see a 2D framework built on GLEW, GLFW, OpenGL 3.x+, and GLSL. So far I haven’t found any.

I’m really keen on GLFW due to its minimal scope. I just want a cross-platform library that can open up a window, create a context, and handle input. This library does that and most importantly nothing else. It’s small, the API is familiar if you’ve done any OpenGL programming, and it supports a number of platforms and input devices.

Of course shaders will open up hardware-acceleration to 2D games. This will enable us to use larger textures, more sophisticated animations, and nicer effects. It also has the benefit of decoupling game code from rendering code which will make the framework code much smaller.

And finally as the hardware continues to get better our games will continue being able to take advantage of it. I think the best way to support Retina devices going forward will be through OpenGL. I will always have fond memories of writing to software buffers of pixels but the time to be thinking of rendering in such terms is long-gone.