On middleware: Production and other stories

I am archiving older pieces I have written on other sites, making this the definitive home for all my work. This is one of several I am porting over from my GameDev.Net user journal. Enjoy!

John Hattan wrote these words, and this is the second time I'm quoting them in the last 24 hours:

...I'm not going to present more reasons not to make a game engine. If you're not convinced by now, you deserve your fate.

I'd like to go a step further and say that if you're not leveraging as much specialized code as possible, then you deserve your fate. Source and integrate a renderer, a physics subsystem, even an AI library if at all possible. Spend your time evaluating them for flexibility, extensibility and robustness, then get to work creating your game. The only reason to create a significant subsystem ("engine") of any sort is for learning purposes or if it is to be licensed to other developers.

Switching gears, I'm very excited about the book The Game Producer's Handbook (read the excerpt here). I think we need a greater emphasis on the non-programming aspects of game development at this site, so that resource being published and the excerpt being posted are just fortuitious indicators to me.

I haven't written a game of any sort in years (the Pong I wrote in Python + PyGame a few months ago doesn't count), but I'm forced to write one for a game programming class I took for the upper division credit. That's not the real indignity, though. No, we're using Andre LaMothe's Tricks of the Windows Game Programming Gurus as our text, which is no longer a relevant introductory text to game programming, IMO. I think that the technological and social environment have changed enough that using the book does more harm than good, because it establishes a faulty cognitive model for approaching games and their creation.

More importantly, it's a build-it-from-the-ground-up approach, which isn't as productive, I think, as here's-a-scaffolding, fill-it-in. I've been critical of the way that programming is taught in computer science programs for a while (I've attended two, but at the same time I recognize that programming is merely incidental to computer science, which is more of a specialized or applied mathematics than an engineering discipline), and I think that the various initial attempts at teaching game programming are making many of the same mistakes.

Interestingly, GameDev.net offers an opportunity to counter this by influencing the "community," which includes academics and instructors of various sorts, and by providing superior resources with measured and measurable results in terms of user progress.

Anyway, back to my experiences. So I'm having to write a game from the ground up, and it should be obvious, given my incessant bitching, that I wouldn't actually use the T3DLIB1 included with the book. Yep, I wrote my own "engine." It's nothing fancy; it's effective in delivering the experiences required for the class, and that's it, but it has helped me refresh on the current state of 3D graphics and APIs (even though the class is about 2D side-scrollers, I'm writing a 3D system in which I can then use orthographic projections) and develop a number of criteria for any rendering middleware I procure for future development efforts.

I will not be chronicling the development of my software here. It's tedious. I took a look at a number of the developer journals on this site, and I found them extremely boring. One of my reluctances toward starting my journal, and the reason I stopped writing it for several months, is that if you are given the soapbox, then you have a responsibility to say something interesting. Dumping code? Not interesting. Detailing your day/week/semester/life? *Yawn* I think the key is to ask questions and foster debate of a larger, architectural, more philosophical, pan-technical sort, so that is what I will strive to do here. And I will strive to update regularly from here on out.

Happy hacking!