A day in the life of a game programmer
This weekend was pretty typical (i.e. frustrating) for game development. In case anyone is unfamiliar with the process (or feels like empathizing), here's how things go far too often.

I was whipping together a new special-effect type object with some rather unusual behavior. I had the basic design "in my head," and it was time to code it up. What happened was, unfortunately, pretty typical.

First, I created a prototype object in the modeler, wiring it up with animation nodes, and exporting it into Torque. I created a new class for this object - a derivative of ShapeBase. Fortunately I have LOTS of ShapeBase derivatives at this point, some with similar behavior, so there's a lot of cut & pasting I can do to speed things up. In all, creating the object and coding it up with simplified "stand-in" behavior takes all of a couple of hours. I'm almost done, right? How hard can it be?

* I spend almost an hour trying to find out why it's not appearing at all, only to realize I forgot to initialize the correct matrix.
* I found out I named the joints incorrectly in the modeler, so the dynamically generated animation behavior isn't working right.
* I make two changes at once (rarely a good idea) - both to make the code more generic instead of a special-case "demo" of behavior. Somehow, this breaks the whole object, and I have to roll back BOTH changes to get things back to where they were before, and re-implement the behaviors step-by-step.
* I break something else, which wasn't noticeable before because I was still testing a single-specific situation. Turns out it's a problem with the server and client being out-of-sync, and the client is missing crucial bits of data to display the model's animation correctly.
* Math still isn't working - I realize that the model is STILL modeled incorrectly, and needs to be re-done. Again.
* Math still isn't working. I realize there's a problem with MathUtils::getAnglesFromVector - it's not calculating the pitch correctly for my purposes. I replace that code, and test it to make sure it's right. I can now guarantee it's returning the correct Euler angles - but the math is STILL not working out correctly, and I'm getting some wonky visuals.
* I try to avoid the problem entirely by creating three entirely new functions to skin the cat a whole different way. None of them work, and I've wasted a good three hours fussing on them. (Note: They still may be used, because they allow new general-purpose effects... which was the whole point)
* I finally realize that the weird, wonky behavior is something I've dealt with MANY times in the past (so I should REALLY KNOW BETTER), and it's related to the non-commutative properties of matrix multiplication. I've been using the default matrix-creation routine for so long I forgot that it might not work for some situations. I fix that, and finally everything comes together and the code appears pretty solid. Not pretty and polished, but solid.

One of the jokes of managing software development is that you should take your estimates, and then double them. And then double them again. Then you won't be too far behind schedule. It's very true - I had everything "basically" working in two hours, but the whole project actually took around eight. And I haven't done any polishing yet.

But hey, polishing shouldn't take too long. Afte all, I'm almost there... how much time could it take? :)

Labels: programming

- posted by The Rampant Coyote @ 10:30 PM (Permalink)