I’ve been working on a space colonization/exploration/conquest/adventure/arcade/action game for the past eight years or so and I’ve never been able to finish it. The development tools I use keep evolving and I keep wanting to apply new features. Unfortunately, this resulted in a perpetual development cycle with no foreseeable end.
The most recent development tool I’ve been using to develop my game has been Microsoft’s XNA Game Studio; which, while sounding fancy, is really just an API built on top of the .NET framework. XNA provides a .NET friendly layer on top of the DirectX 9 API, which can be easier than accessing the DirectX 9 API directly using C++. While I can program in C++, I’ve found C# and the .NET framework to be easier and quicker to use. The .NET framework handles many of the minutia that programming in C++ requires and this cuts down on development time. Since my time is limited: C#, the .NET framework, and XNA are practical alternatives for me.
Throughout my time developing my game using XNA Game Studio, I’ve found that there are many features that I want in my game that aren’t available “out of the box” in the XNA framework. In other words, there aren’t certain classes available to do what I want and so I have to make them myself. This is understandable given that XNA is designed to be a general framework to start a game project from. As I wrote the classes that I needed to be part of my game (such as an intro screen, main menu, hit detection, buttons, dialogs, popups, etc.) I found that these were features that many, if not all, games use. I started building my own game framework on top of XNA, which in some circles could be referred to as a “game engine.” However, a game engine is usually designed for a specific game and many games use their own game engine. However, I found that the features I need are more general and can be used for a wide variety of games that I may plan to make in the future. An intro screen, main menu, windows, popups, buttons, hit detection, etc. are all things that virtually any game would need and curiously, they are not provided as built-in features of the XNA framework. So I decided to write my own.
The Beginnings of a new Framework
What started as a simple set of classes to handle the core functionality for my space colonization/exploration/conquest/adventure/arcade/action game (which I’ll simply refer to as my “space game” from now on), grew into an actual framework that can provide functionality to all types of games. Primarily, I wanted a framework to give me everything I needed to start right into writing the actual meat of a game whenever I wanted to start a new game project. Every game I plan on making needs to have a main menu, intro screen, etc., so I want those to be available from the start, requiring only a little tweaking.
When I was developing my space game in XNA, I kept coming up with new features that were useful as a generic feature for all my games, so they went into the “Framework” folder of the code library for the game. Eventually, as the “Framework” folder got big enough, I decided it needed to be its own entity, and so the FlexNA framework was born.
“FlexNA” is a name I came up with to distinguish my core game library from my space game. FlexNA started as a folder within my game’s overall solution in Visual Studio. I then separated it out as its own “Game Library” solution and kept my space game as its own solution. However, this posed problems when developing my space game and FlexNA at the same time. Really, they weren’t problems per se, just annoyances and inconveniences associated with syncing and moving between two projects all the time. Because of these quirks, I moved FlexNA back into the space game’s solution and kept it as a separate project within the solution. This allowed me to develop both my space game and FlexNA side-by-side without any inconveniences.
As I continued work on the space game, I noticed that most of the work was going to FlexNA. Also, the FlexNA code was starting to become patch worked and messy as I added the new, removed the old, and tweaked the existing code. This led me to the conclusion that I needed to start FlexNA off right and rebuild it from the ground up as the standalone game library it was meant to be.
FlexNA has once again been put into its own solution and FlexNA 0.1 is now in development. If I can get it to version 1.0, then it will be a complete framework ready to be used in other games. It can then be extended later on to add more features, at which point games can use updated versions of FlexNA as necessary or keep with 1.0.
If you are interested in what FlexNA can do for your game projects, let me know. As I develop the framework, I will post more on what it can do and what I plan for it to do.