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.

5 comments:

Matt Worden said...

Not sure if you're still noodling about how to marry cameras to screens and the other objects, but I thought I'd throw an idea at you in case you wish to consider it ...

What if a "screen" was as you described (containing game objects), but did not have cameras as children. Instead, each camera would have a child screen.

Think of a screen as a space to hold things -- like a kitchen table currently holding a board game. (You might also have something useful -- like an options menu -- sitting on a nearby coffee table, etc.).

Cameras would be defined as a view of one of the screens. The camera could be defined by the rotational angle with respect to the screen, and how much of the screen was shown, etc. Perhaps you could then collect multiple cameras within a "display" object which represents the actual output to the player's display hardware.

As an example: You could define "camera 1" as showing a view of "screen gameplay" that was centered on player 1's vehicle and rotated to match that vehicle ... and "camera 2" could be showing a view of that same screen that was centered on player 2's vehicle ... and the Display object knows to show camera 1's view on the left half of the output display and camera 2's view on the right half of the output display for a typical head-to-head racing game.

You could still call a single, central object ("Display") to Draw, which would tell its children (the cameras) to Draw, which would each tell their children (the screens) to Draw, which would each tell their children (the game objects) to Draw. It would seem to fit your design, and allow the designer/developer to think about the game as if it were being shot like a live TV show.

Not sure if that's helpful to you ... but it was helpful for me to get the idea into a written form. ;-)

-Matt

emachine74 said...

Well I spent the weekend in my backyard building a greenhouse kit w/ my wife, so "yes" to "still noodling".

This definitely helps me think outside my own little box here. In it's current implementation, Screens are the end-all, be-all parent node of an Update/Draw chain; but you're right - it doesn't have to be that way. I simply hadn't considered putting cameras "above" screens in the hierarchy. This really gets me wondering if the entire engine should fundamentally be camera-based. It's crossed my mind before, and it just seems to make more and more sense every time I think about it. What's really missing is a camera's matrix, which I'm guessing will be some kind of differential offset between "world" space of what it's following and the "camera" space itself.

Alright, well anyway I'm supposed to be "working" right now :) but the gears are turning...

Matt Worden said...

Now that I've had the chance to rattle things around in my own thought box a bit ... I completely see where you're going now with the screens-as-top-objects. That should be the smoothest way to work things.

Now, working with the normal case of only a single camera involved in a screen, you would set its matrix within the world as if it were another sprite. However, the inverse of its matrix would then be applied to every sprite (and other drawn objects) within the screen right before drawing.

That would allow you to use the screens in a screen-handler for transitions (fade one out, switch to a different one as "current", fade it in) ... and it would allow the camera to move like any other sprite -- chasing, rotating, etc. -- and its matrix would be automatically applied when the screen's objects were drawn.

I think it's a solid and powerful approach. (In fact, I expect to use a variation on it in one of my own project. ;-D)

Cheers,
-Matt

emachine74 said...

Let me slap up an article on this subject later tonight, I'll disclose all the Screen stuff as it is now and then go into what I think I want to do, I'd be interested to know what you think.

emachine74 said...

( I'm still working on this ;) )