Component Based Game Design
So we read about how to design a game before starting coding the game. I know, I know, what!? We did a minimal amount of research and came upon a fascinating approach described here quite readably, here rather less clearly but in great depth... if you're into directX or something. I skimmed it. ... and here in powerpoint format or something.
Basically, instead of coding each game object's functionality individually, you make a bunch of generic States and a bunch of Actions that can be applied in any number and combination to any object within the game. To make a simple asteroid, say, we'd take an entity an apply a state.Position, state.Velocity, state.Rotation, state.Graphic, action.Move, and action.Render. Or something like that. Anyway, it's terribly clever and I can't imagine how I've lived my life up until this point without it.
Pyglet
I'm very impressed by Pyglet. Its like someone went and made all the bits and pieces of code that we were trying to figure out ... hold that, I mean all the code that we were trying to get dcosborn to figure out for us ... to make our game codename: ATTAS. What we wanted was essentially a Pygame-like interface that used OpenGL. Except someone's gone and done all the work now, I see. This is lovely! (And take note dcosborn: this is something to check out.)
Oort
This project is now codenamed: Oort, and we're working on it right now. It'd be easy to haxor pyglet to move a ship around, but it wouldn't be doing it within the super-extensible and dynamic system that we intend to use, so milestone #1 may take 'til the end of this week. Anyway, enough talk, more work. Pictures Friday.
One last thought...
... and this is a subtle one. I have been pretty disappointed with the major games I've bought in the last while (eg. Oblivion), so I really haven't been buying anything, just playing games from 10 years ago. As a nominal indie game developer, I should be playing and supporting indie games. I'd never really done this before because ... I don't know, it's just not something I do. So that's gonna change: I'll find an indie game that looks like fun and buy it (and hey, it'll be 1/3rd the cost of Oblivion was). This insight is incredible.
Perhaps you, dear reader, should consider it too, because it is probably in your self-interest to support a culture of buying independent games rather than blockbusters. This would be a great time to plug my own game that I'm selling except that I don't have one so this golden opportunity is lost.
Actually it's not that direct and implementations get a little hairy. The blog poster's code is full of redundant fluff. I like the idea but not the implementation, the base classes are pure skeletons and all the component stuff has to be re-implemented every time you create an Actor. Not to bash it but this needs some refinement...
Something you might have missed on the subject: you can group position, velocity and rotation in a single State. It will save you some work since they usually don't appear in isolation and you can just make one check and then access all of them.