Another evening of development.
Continuation from Monday’s entry… Jay continues his explanation of why he has to take the short bus to Torque School.

Having gotten the female model to sit in the passenger’s side politely, I now need to do the same for the male character. This is much easier – I create a copy of the female character, delete the polygon mesh leaving just the skeleton and animation data, and then import it on top of the male’s polygon mesh. Then I have to muck around with assigning the vertices to the correct bones, and then I’m good to go.

I do a lot of cutting and pasting to get the male character to sit in the car, but it works perfectly on the first try. Except part of his midsection is up around his nose level. It actually looks kinda cool, like Auron’s high-collared coat in Final Fantasy X, but it’s not what I want. I’m getting to be pretty proficient with fixing vertices by now, so it only takes me a couple of minutes to fix them and re-export the model. He looks good enough in the car by now, so now it’s time to get the car to move.

The built-in Torque “Wheeled Vehicle” object already has most of the functionality I want – it’s just waiting for some controls to tell it what to do. Now there’s a couple of different approaches I can take. I can do what Torque did for players and create a subclass of Wheeled Vehicle called an “AIWheeledVehicle.” I actually start down this path, and then stop. I am not actually planning on having many moving cars in this game – just in the cutscenes – and I definitely do not plan on having any human controllable cars. Since my needs are so simple, I decide to simply add some functionality to the existing Vehicle / Wheeled Vehicle classes.

First, I add a function called “GetIsAI()” – it returns a false for base vehicles, and access a new variable for wheeled vehicles called isAI (a Boolean). Next, I need to add a function that calculates the AI move – called creatively enough “GetAIMove”. Then I go into the ProcessTick function, and find the point where it checks for a null move. I add some logic that says if it’s not a client object and GetIsAI() returns true, to get the move from GetAIMove().

I end up adding a couple more variables, initialize all of said variables in an object’s constructor, and create a few Console functions so these can be accessed via TorqueScript. Very simple changes, all told. The get AI Move simply pushes the car forward.

The couple drives down an (oversized) deserted country road at night - eventually.

So I try it. The car immediately flies backwards down the road, crashing into the side of the mountain in the distance, headlight beams cocked at a weird angle.

Three problems:
#1: I’m working on a somewhat smaller scale than the base car datablock from the demo.
#2: This is a cutscene, not interactive gameplay, so the car’s movement appears very fast from a static viewpoint.
#3: The car is starting its movement before the client is actually admitted into the game, so by the time I see it it’s already halfway gone
#4: I uh… cheated. Remember last blog where I said the car was modeled backwards? I never fixed that. It’s still modeled backwards. That’s why it went backwards – relatively speaking, it went forwards.

I make the necessary modifications. Now what happens? The car starts, drives forward at a good clip, then smashes into the man in the white suit who is standing in front of the car down the road. He doesn’t budge, but the car spins off to the side, keeps driving, and goes over the cliff. Ah, the rigid-body physics system!

I find this bug so horribly amusing I have to watch it a few more times before fixing it. Who ever thought the “step on the gas,” “step off the gas” controls for AI could be so entertaining?
- posted by The Rampant Coyote @ 2:33 PM (Permalink)