AgateLib

Development on AgateLib has been slow over the past few years, but that does not mean the project is dead. For a long time, I have had several ambitious goals for the future of AgateLib development. This list of goals included things like the development of a GUI layer, the ability to load and render 3D objects, defining pixel and vertex shaders, developing a resource manager application for data-driven content loading, support for Xbox 360 and the GP2X, multi-language support, automatic distribution packaging, and a few other things. Most of this stuff I wanted to do because it sounded cool, and it would be useful in a middleware library like AgateLib. And I started development on several of these things, but most of the time I wound up getting to the same stumbling block for each of these things. The problem has always been that I have no real use-case for these ideas, so I end up trying to design a very generically useful thing because I have no idea of how it would need to be used. To me, that has gotten very far away from the original philosophy of AgateLib.

When I started developing AgateLib, it wasn't because I wanted to write a cross-platform game library that other people could use. I wanted to do some rapid prototyping for a little game, and I just wanted to dive right in without having to deal with the nuances of Direct3D or anything like that. But I also knew that I might eventually want to make that game much more performant than GDI+ could provide, so I spent a little time abstracting an interface so that I could replace the GDI-based back end with a Direct3D one when it became necessary. And thus AgateLib was born, and I spent many nights working on developing it. The development took on a life of its own, and where the utility in the development was clear it made AgateLib into a very useful library. But over the past few years there was just too much feature creep.

So now I'm getting back to my roots. The development of AgateLib will proceed, but it will do so in the fulfillment of the requirements of my game projects. I have a game I'm working on right now (spoiler alert: it's an rpg) which has tested several areas of AgateLib and exposed bugs. I have a few features in mind like blend states and use of the stencil buffer and I see exactly where they will fit into AgateLib. Those features will be developed soon. Also, the various parts of AgateLib are getting a thorough testing on this project, and I'm pleased to say that very few bugs are showing up, and the ones that are so far have had very straightforward fixes.

One thing that impresses me about my current game project is how certain things I thought would be useful in AgateLib don't really seem like they would be helpful at all. For instance, the XML driven resource management. The current project uses a mixture of data-driven resource implementations, which satisfy the requirements of its various subsystems quite well, yet their implementations are so different that there isn't really a unifying theme. The current project also has a GUI, which is very useful in some ways and very inflexible in others. It works very well in this game, and perhaps a future version of it will end up in AgateLib, but it will be quite different from the current incarnation. There are other bits of code I have developed for this project which I can see being incorporated into AgateLib without much change, in particular some extension methods for the System.Xml and System.Xml.Linq classes.

This really gets me back to what AgateLib was all about from the very beginning, as a project to facilitate game development, not as something which was developed to its own end. There will probably be a release of AgateLib 1.0 within a year, and it won't be a whole lot different than the current SVN trunk, with a few more features and bug fixes.