Best-laid Plans of Designers

The Designer At Work

A Rough Approximation of How I Felt on Wednesday

Unsurprisingly, even for a relatively relaxed quarter, this one has been pretty intensive, making it difficult to post as frequently as I would like. So today shall make do with a quick post about my most recent unforeseen enormous mistake and what’s been learned from it. Maybe in a day or two I’ll be able to post something far more interesting. Onward and upward!

As I have before, I will cut to the chase here at the outset for those of a tl;dr mindset (but shame on you if you’re in that category):

Things will go wrong in the ways you never thought they could. You’ll forget something simple, something crazy will get in the way… whatever. It’s at these points where you need to be able to make a swift, considered, and possibly bold decision, and you need to carry through on it with fervor once you make it, and you can’t stand around wringing your hands because it’s forcing your hand in a direction you didn’t want.

This quarter’s project isn’t all that important to the topic at hand, except to say that it’s a game system rather than a game, and that it largely involves shoving data around into new and more interesting configurations without a lot popping up on-screen.

I’d decided to be responsible and moderately intelligent by not choosing to do this in C# and XNA, on the grounds that I’m spending my spare time learning those things but it would on the whole be a good idea to use technology I’ve used before for a project with a deadline. thus I chose to write it in TorqueScript for TGB, as I have at this point finished two projects in such and feel reasonably comfortable in dealing with it.

Good idea, on paper.

The problem is, in short, a discovery—as you learn to more-or-less work in more and more programming languages (in my case C/C++, Lua, Perl, Java, Javascript, C-Script/Torquescript, along with things like MEL, MAXScript, MUSHcode, LISP and whatever else I’ve forgotten), there is a tendency to have the various quirks, features, strengths and weaknesses of them all blur together to one degree or another. This is Lesson One. It’s pretty important to keep these things straight somehow if you don’t want to shoot yourself in the foot and loose serious time on a project.

In this case, TorqueScript’s design worked against me. It is, after all, designed to do what Torque needs it to do, which mostly deals with moving things around in a game in whatever fashion the developer needs them moved. It is not really designed for abstract data classes, because it is most likely assumed anyone dealing with anything complex enough to need it will modify the source code to provide it. But I don’t own the source code nor plan to, for various reasons.

Still, I was willing to bite the bullet and take a sloppy solution, by building on the SceneObject class and just accepting that it was going to be ugly and full of unneeded overhead. The problem was, for reasons I’m still unable to figure out and with two days to my midterm check-in, I couldn’t get the hacked-together data class to attach to the objects and actually execute the code. So, in the end, I bit the bullet, did what I didn’t want to do, fired up Visual Studio, cracked my C# and XNA books, and crash-coded for two days or so in a panicky flurry.

Fortunately, I was able to get the first prototype working to an acceptable level for midterms, though it was down to the wire and not nearly as far along as I’d wanted. But it was working.

Final thought: Today’s lesson is largely true of life in general most of the time, too.

This entry was posted in Game Design, Menu. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *