| categories: tech, free software, luftballons | View Comments

Remember in my last post when I talked about video games as an example of economic inefficency created by proprietary software, because they duplicate so much effort? I've actually been thinking about that idea a lot, for a long time. More specifically I've been thinking about it in terms of the technology; the graphics engines etc. Studios are constantly competing to best eachother in graphics, and they end up creating more or less the same product; most games are about on a level. The competition is clearly driving some innovation, but the fact that they can't build on eachother's work means a lot of wasted effort to maintain what tends to look like a stalemate from without. It's not a terribly gross example of IP going haywire; again, the innovation is getting driven, but open source has been very good at cutting out this kind of inefficiency, for better or worse.

I guess what I'm trying to say is I'm writing a video game engine.

Meet Luftballons.

There's more than a few open video game engines out there. It's probably fair to ask why write another one. To be fair, the eventual scope of Luftballons is to be much more than an engine; I'd like to build an entire suite of open source game development tools that will allow users to develop games from start to finish (there's some proprietary things like this already, but for paranoia's sake I'm not mentioning them). I could build that around another engine, and of the other options out there I'd say I probably looked closest at the nominally successful Ogre3d, but after reading that it did not intend to support deferred rendering pipelines, I decided to sniff around elsewhere. Eventually I conceptualized something unique enough that I felt it was worth striking out on my own.

Luftballons is basically an experiment in how much difficulty I can remove from the OpenGL API without removing any significant functionality. I chose to aggressively target modern OpenGL (somewhat tempered by Mesa only just barely implementing OpenGL 3 on most hardware), and build a framework that would cater to most of the use cases in question, but be dramatically less intricate than OpenGL. The trick is in considering what the OpenGL API can do, but abstracting away the how; removing all the tiny decisions around order of operations and allocation methods and whether to use instanced geometry, etc. The theory is that we can expose a simpler API that is feature-competitive with the raw drawing API if we don't worry about performance and just assume the most obvious way to draw is fine for everyone. The much more exciting theory is that we can then teach the implementation to be clever and do the optimization behind the scenes without hassling the user with more details. More importantly, a simple API is inherently more future-proof, as new OpenGL features just mean small API extensions or improvements to that under-the-hood optimization.

There's obviously a lot more to do, as well as some cleanup on what I already have (hand-rolling makefiles is great! I've only done it for one project and already my hatred of Automake is completely gone! (seriously, early adopters, I swear it will be in autotools within a week. Promise.)) but I have high hopes. Absorbing that inefficiency I mentioned means creating a ubiquitous open source game development platform. Whether it is this project or something else that does it, I'm hoping to one day reach a point where building a new game without using the most common open game engine is as absurd as building a new embedded platform without using the Linux kernel.

In the meantime, who wants to play with GLSL?

blog comments powered by Disqus