Day 317 : Good ole Damocles

Just when I thought my collision system was going to work fine, it revealed a great big giant hole right into my XML parser code. Something you need to know about that XML parser code : It's one of the first thing I've coded when I started this project. It came after about a year of C++ break (I was doing actionscript 2.0). So it's probably the most crappy code you've ever seen. Ever. But I kept it because it would do the job. I knew a couple of things that wouldn't parse and I avoided them. But when I came up with my collision tree XML, it collapsed. Instead of patching this horrendous code I decided to trash it and pick up tinyxml to replace it. Still using my old XML and XMLIterator classes as wrapper. But then I found out that a lot of my classes unwillingly (unwittingly?) exploited a bug inside that crappy XML class. In other words, lots of stuff never should've worked but it did. That's the kind of pillar class that when it stops behaving like it used to, everything collapses. So it took a full day to rip the XML class apart and re-build most parts of it. So now the collision tree will work. My XML class still looks like crap, but at least now it points to something stable. I'll have some rewriting to do, especially in the editor, to make my XML loading and saving clean, but the hard part of this port is done.

The collision system I came up with is pretty adequate. I'm happy with it. A combination of AABB tree and spheres. No complex OOBB or collision meshes. For a rail shooter that'd be overkill I think.

Day 309 : Settling collisions

This has been one of the tough streaks of development. I once thought simple bounding-box collision detection would be enough for the game, but a few weeks back I ran into a slew of problems and realized it wouldn't be enough.

Problem is, when it comes to 3D programming, I'm like a blinded buffoon. I use Ogre, and I have a game that works with it. But I don't pretend to know how it works on the inside, nor do I have ambitions to. As far as I'm concerned, Ogre is a tool I use, if it works it works, if it doesn't then I'm screwed. But I trust its team to bring something to the table that's prod ready and rock-solid.

When it comes to collision detection, there is only lib out there that links to Ogre, it's OgreOpCode. I tried it but I didn't feel it had to robustness and level of finish that Ogre has. And if I have to modify it to work with my game, it means I have to understand it. And like I said, when it comes to understanding 3D engines, I'm a blinded buffoon. Can't risk it.

Other options for collision binding included full-blown physics engines. That is greatly overkill for a rail-shooter engine. At least for the first revision. So I've now decided to implement my own collision detection routines. It'll be simplistic, a list of boxes and spheres attached to bones. All defined in an XML file resting at the same place as the .mesh file. It should be enough.

I'm aiming to be able to spend Christmas vacations building content, and maybe deliver the first level with production models at the end of those vacations. Should be smooth sailing from there. Right? RIGHT?

Day 297 : Internet break downs production

5 days without internet isn't a good thing. You don't realize how much you need the damn network until it mysteriously disappears into the void. Well it's back now thank goodness, so I'll be able to look up all the things I couldn't these last few days.

I'm doing a lot of "final" prod things on Exequor. Final modeling, animations and levels. So far looking good. Textures will need some work, but that will come later. Of course, every final production step taken reveals failings in my almighty Shmoulette engine. So I fix those and strengthen it up.

Next big obstacle : collisions. I thought that standard bounding box collisions would be enough for this game. And it is for about 80% of the models. But something like sliding doors are more tricky. I now have to decide how deep I want to go in this. I don't want to get bogged down in some high-tech physics engine just to get slightly more precise collisions.

We'll see. We'll see. I hate to throw in a release date out of the blue, but I would say next fall appears reasonable. With an alpha going into QA near the end of June, during my bi-annual 3 weeks vacation. I have another 3 weeks vacation coming this Christmas, hopefully I will get a lot of things done then.

The scale is so much smaller than The Archangel Chapter, that I have hopes it'll get done soon. Stay tuned! Cheers!