On simplicity
If there was one single advise I could give to rookie programmers of any language, It would be: if putting your idea into code turns into something obscure and complex, you are using the wrong approach. I’m not saying anything can be resolved in two lines of code. However, the method itself should be easy to write down, explain and follow. Some of the steps would involve advanced matrix calculations, for example, but still these calculations could be easily wraped into something like “rotate object to face camera”.
It has happened to me countless times during the years: you start with a given algorythm to solve your objective, see how it turns out to be more difficult than you expected, add a lot of obscure if clauses here and there to cover tricky cases when this is parallel to that and you divide by 0, just to end up with three hundred lines of cryptic garbage and nested functions even you don’t fully understand. You exhale in satisfaction, think to yourself “wow, that was more difficult than expected but I am so good I solved it”. Two days later you emerge from the shower feeling an idiot, delete the work from the last two weeks and write it again in one hour unsing two nested loops and one helper function.
This is what has happened to me ( yet again ) last week. Originally, way before I made it public, the FFilmation engine was two dimensional, you had a floor and walls and you moved things along the X and Y axis. Perfect for Diablo clones an Habbohotel look-alikes. So I programmed the zSorting algorythm in 2d. More precisely, I thought it in 2D. And it was clear, not easy, not trivial, but clear. Then, one day, I realized It wouldn’t take much to transform the engine to be fully 3d. Still isometrically rendered, but with freedom to place and move stuff at different heights. Instead of rethinking the zSort in 3D, I patched what I already had, adding more conditionals, functions, loops and whatever I needed to solve every new situation I encountered when testing my own examples.
It worked. At least I thought It did. I’m sure 90% of the people playing with the engine will be building “flat” scenes, without much vertical complexity. But I am not. I am building a complex town scene with tall buildings, similar to the environment in Assassin’s Creed. Ok, not even remotely similar due to obvious technological limitations, but you get the idea. Such scenes need real 3d zSorting of all planes and cells inbetween, and I have painfully discovered that the engine does not provide that. Even more painful is trying to figure out what is not working, tracking obscure variables and method calls I no longer understand. To put it short: currently we have a crappy 3D implementation of a 2D algorythm that doesn’t work well. If you stick to 2d spaces you’ll be fine, but you can’t go very far beyond that.
I’m already in the process of rewritting the zSort algorythm. Several classes are gone (the API doesn’t change, no worries), as they added a lot of bloat and little help, and the result is way smaller, way cleaner and way more understandable. And works well. The repository is already updated.
I hope next time I take my own advise.

Awesome. Real 3D will be great. And I certainly know what you mean. I’ve done the same kind of thing many times.
jk said this on June 4th, 2008 at 11:52 pm
Thank you for the generosity to let us see and use your engine and yes, I do rewriting functions with less calls and more >> or << lots of time. We are the same kind of animal
HappyMan said this on June 20th, 2008 at 7:35 am