Maintaining UML, while ideal, may turn out to be too much work. But it has provided me with a VAST amount of insight on the internals of our engine, so it may be worth it.

Our classes are a mix of hacked in C code, half inheritence, half composition. We have a lot of clean up work todo, but Phillip's initial work on Input should help a lot, now we can be considered "interactive"? Though that needs to be reworked, it's a good start. After finals this week, we should be able to really get something interesting going, so bare with us (not that anyone is following it =P).

Two major barriers right now is a gddf (Game Definition Data File) which may be an ini file, and a sddf (Sprite Definition Data File), which can be a little more lean, but doesn't have to be. We need a config class, which I may tackle tomorrow after my psych final.

I've been using sqlite at work for a configuration backend, so I may consider evaluating that for a backend. But maybe not, requirements are getting fat as it is (though sqlite is rather tiny, and can be used for all sorts of runtime database stuff like scores, save states, etc). That may be worth considering actually...

The fruits of my UML work this weekend, it's gone through many many changes and refactoring. So there's a lot more work behind it then it looks. I have not incorporated the work on Collision detection I talked about yet, as I have not had a chance to think about that.

( UML Diagram )

Interesting reads:
http://www.harveycartel.org/metanet/tutorials/tutorialA.html
http://www.gamedev.net/reference/articles/article1026.asp

Luckly with the system we are creating, we can dynamically implement new algorithms without breaking any code.

Need to get this thought out, without ruining my current UML.

Thinking about ways to handle collision detection polymorphicly, so that we can define the algorithm at runtime in the game definition file. However, though my first pass will will work, I may have a better idea.

First, I'm using a Stratagy Pattern approch, implementing a common CollisionBehavior interface, and using composition to give the sprite class it's own object providing an isColided(Sprite otherSprite) method:



Now I am starting to rethink this. Collision detection does not have to be absolutly one algorithm or another, it can be layered, based on something closer to a Decorator pattern. Wrap them, passing a pass/fail to the next algorithm up, and passing through the result. Something like this:

Start with a Bounding Box algorithm. If that fails, break out and return false to isCollided. If it's true, then go to something more precise, like a bounding circle. If that comes back true, broken rectangles. If that comes back true, pixel perfect detection. We can then specifiy the most precise algorithm we want for a given sprite. We could generate the decorated CollisionBehavior something like this:

 switch(collisionLevel) {
    case CollisionBehavior::PIXEL_PERFECT:
        m_collisionBehavior = PixelPerfectCollision(m_collisionBehavior);
        // Fall through to the next level
    case CollisionBehavior::BROKEN_RECTANGLES:
        m_collisionBehavior = BrokenRectCollision(m_collisionBehavior);
        // Fall through to the next level
    case CollisionBehavior::BOUNDING_CIRCLE:
        m_collisionBehavior = BoundingCircleCollision(m_collisionBehavior);
        // Fall through to the next level
    case CollisionBehavior::BOUNDING_RECT:
        m_collisionBehavior = BoundingCollision(m_collisionBehavior);
        // Fall through to the next level
    default: // Don't do collision detection
        m_collisionBehavior = NullCollision(m_collisionBehavior); // Simply always returns false, may be inefficient, but this prevents
                                                                  // having to have knowledge of the algorithm.
} 

Then we can simply call m_collisionBehavior->isColided(otherSprite), and it just unravels, however, as is, it would unravel backwards. =P But that can be fixed with a little more thinking. This way we never have to do more then a quick and fast bounding box on two sprites that are not even near eachother, even if you want pixel level collision.

SDL_scroller has a Trac! Websvn to go away tonight.

surye@loki ~/projects/programming/sdl_scroller $ make
g++ -c -Wall -I./include -I/usr/include/SDL/ src/Sprite.cpp -o src/Sprite.o
g++ -c -Wall -I./include -I/usr/include/SDL/ src/SpriteBase.cpp -o src/SpriteBase.o
g++ -c -Wall -I./include -I/usr/include/SDL/ src/sdl_scroller.cpp -o src/sdl_scroller.o
g++ -lSDL -lSDLmain src/Sprite.o src/SpriteBase.o src/sdl_scroller.o -o sdl_scroller

Joy, looks like this may get some attention after all =D It's building from windows and linux now.

Well, I suppose this is my first real entry in here, and it will be about sdl_scroller, design patterns, and C++.

SDL_Scroller is my primarily active project right now, current authors are me and eiclectis. It's a side-scroller engine, to practice and get some experience in OO game programming. We have big plans for it, but implementation and work has been slow, mostly due to work and school. You can check out the source code over at .... damnit. Websvn isn't working on the new FreeBSD host. *gets frusterated with bsd's inputrc and vimrc defaults, throws a fit, and copies them from the gentoo cvs* Okay, there we go, for some reason /usr/local/bin/ wasn't in php/apache's path. Anyways, you can check out what we have so far here: http://surye.datamachine.net/websvn/listing.php?repname=SDL+Scroller&path=%2Ftrunk%2F#_trunk_ (note, it's nothing at all to be honest). Websvn is the only anonymous access at this point, we will open up svn for anon ro.

I've been reading a new book, Head First Design Patterns. I have been really lacking in the OO design methodologies, and figured it's high time I start learning the standard design patterns. The book opens up with solving a problem step by step, that eventually evolves into the "Strategy Design Pattern". I must say, I am quite impressed thus far with the book, it is very easy to follow, and the information sticks well. I'm already seeing ways to implement Strategy Design Pattern in sdl_scroller to fix the issue of the ever growing complexities of the sprite superclass. I'm part of the way there, but I'm really not using encapsulation and polymorphism to the extent I could be.

This brings me to my next topic, interfaces in C++. They don't exist... not really anyways. You can create a pure virtual ABC, but even then, I believe there is behavior difference from Java/C#'s interfaces. But I found this to aleast help with creating interfaces:

#define Interface class

#define DeclareInterface(name) Interface name { \
    public: \
    virtual ~name() {}

#define EndInterface };

#define implements public

And then use it as such:

DeclareInterface(IFace)
virtual void test() = 0;
EndInterface

This works, but you have to remember to create all pure virtual functions, and it does not enforce all the requirements of an interface (though it does enforce a virtual destructor, which is the only reason I would even consider using this method). It reminds me of pascal programmers #define start #define end, and it kinda makes me cringe. =/ But it will have to do, Or I just create pure virtual ABCs, which I may just end up doing. MSVC7 and up support __interface keyword through an extension, which properly enforces the interface, but gcc lacks it, so blah :(.

Excerpt from "Dirk Gently's Holistic Detective Agency" by Douglas Adams

    Richard continued, ‘What I mean is that if you really want to understand something, the best way is to try and explain it to someone else. That forces you to sort it out in your own mind. And the more slow and dim-witted your pupil, the more you have to break things down into more and more simple ideas. And that’s really the essence of programming. By the time you’ve sorted out a complicated idea into little steps that even a stupid machine can deal with, you’ve certainly learned something about it yourself. The teacher usually learns more than the pupil. Isn’t that true?’
    ‘It would be hard to learn much less than my pupils,’ came a low growl from somewhere on the table, ‘without undergoing a pre-frontal lobotomy.’
    ‘So I used to spend days struggling to write essays on this 16K machine that would have taken a couple of hours on a typewriter, but what was fascinating to me was the process of trying to explain to the machine what it was I wanted it to do. I virtually wrote my own word processor in BASIC. A simple search and replace routine would take about three hours.’
    ‘I forget, did you ever get any essays done at all?’
    ‘Well, not as such. No actual essays, but the reasons why not were absolutely fascinating. For instance, I discovered that...’
    He broke off, laughing at himself.

I could not have put it better myself.