1/3/08

Not Vacation

Back from vacation and busy at work. Working on ADO stuff mostly, I've got this 5+ year project ahead of me here and, like most programs now, it's just a big sprawling database front end. I'm building some good base classes for presenting, editing, and saving SQL data, with generic concurrency checking & error handling, irrespective of database or interface. Kind of a generic data access layer "engine" (well, sort of). It'll really help automate the tedium of dealing with database records & concurrency etc., which is super important for this job (medical records, medical billing - you don't want to screw this stuff up) but the reality is, be it a database of medical records or a database of high scores, it's always the same ADO issues no matter what the columns happen to be or what the tables are named. So as per usual, the stuff I'm working on now will eventually help me somewhere else on the XNA side. Which is always cool to think about.

And speaking of XNA I've been thinking about how exactly I want to implement that 2D camera class into the engine. It's all well and good to just have camera code that "works", but now I want it to be simple to use. I want to have a Camera object abstracted to the point where I just define it, add it to the game, and "there you go".

That's going to be a little trickier than I first thought. Possible, just tricky (for me anyway). If you've read along with half the tutorials here you know the gist of the engine - game objects are in a parent/child relationship, their matrices multiply together and that's basically how stuff is put on the screen. I want Cameras to be a "game object" as well, so I can put a camera here or there just as easily as I could put a sprite here or there.

What's tricky is that you can't necessarily make a game object (like say, the player's ship) a child of a Camera. What if the ship needs to show up in 2 Cameras at once? But then, if game objects aren't children of Cameras, how then could the game object be automatically influenced by the Camera's matrix ala the parent/child matrix cascade?

I don't really know yet - but one of the fundamental changes to the engine I'm considering is to say that a Screen holds a set of game objects - for instance, the Game screen holds a players ship, the bad guys, the bullets, all that crap in it's child collection. And then, Cameras are also in the Screen's child collection. The change would be that when a Screen is told to draw, it only draws it's Cameras; and the actual drawing of objects is performed by the Camera, rather than by the Screen. So the Screen becomes something of a Camera manager... or something like that. I haven't actually sat down with it yet, this is mostly mental fragments pieced together while driving to work or falling asleep at night.

The Camera is going to be a significant component of the engine and may play a very important role in how the engine renders sprites onto the screen, so I want to take care to approach it in a somewhat methodical manner. Under the thumb of bad weather here on the US west coast, perhaps this weekend I'll have nothing better to do.