vrijdag 22 oktober 2010

Moving platforms

Dear dear readers,

This week I've worked with Joep on fixing bugs in ****. Pretty much all bugs have been fixed, so we're happy about that. One bug in particular was nasty as it happened only in the online version. In the end it turned out to be an old online file which apparently was out of date since a long time ago, but up until this moment it didn't cause any problems.

For the Rhino Rush game, we've had another meeting discussing what should be in the game and how we're going to do it. The... frolicking... ;) game designers thought it would be fun to put in some moving platforms. Easier said then done as is the case in almost every feature they come up with. But it's also a challenge of course.
As we're using physics on the character for collision detection and resolving, the platforms have to be done using physics as well. I started out with a box as a platform and making it move by interpolating the platform's position between its begin- and endpoint. Well... the platform moves but when the player stands on it while the platform moves up, he was hardly able to move due to constant collision resolving by the physics engine. And when the platform went down the player suddenly moved normally again as the platform wasn't constantly placed in the player anymore. Also by bluntly setting positions of objects the physics engine won't know the linear velocity of the object so I'm not surprised this didn't work very well. Anyway it should be clear that this is not the way to do it.

So I turned to my spring constraints, attached 1 spring constraint (a very strong spring with rest length 0) to the platform and another constraint to keep the platform in a set orientation (you don't want the platform to rotate when the player stands on the edge of the platform). Then instead of setting the position of the platform, I set the endposition of the spring and linear interpolate that between the desired begin- and endpositions of the platform. That worked a lot better, but the platforms were a bit wobbly: they would move around when you jump and land on them and when they reached their begin- and endposition. But when I showed it to the game designer he wasn't too pleased with it. Although wobbly platforms can actually work fine a game if you give it an appearance of not being to sturdy. But ok, let's try to get the wobbliness out of the platforms as well.

This required me to use the 6DOF joint. A joint that is very generic and allows you to do many things. As such it comes with a great deal of variables you can set: axisDrive, axisMotion, biNormalDrive, biNormalMotion, driveAngularVelocity, driveLinearVelocity, driveOrientation, drivePosition, globalAnchor, linearLimit, localAnchorA, localAnchorB, localAxisA, localAxisB, localNormalA, localNormalB, normalDrive, normalMotion, swing1Limit, swing1Motion, swing2Limit, swing2Motion, swingDrive, twistDrive, twistLimit, twistMotion. Well, ok that's all fine and dandy, but where's the documentation? Well... there was very little documentation about it. So I just had to experiment a bit with it. And I also found this image, which was also helpful in figuring out variables:
















I mean seeing a variable named swing1Motion, it isn't exactly clear what it's for. But from the image we can see it's actually pitch. And twistMotion is yaw, while swing2Motion is roll. We can prevent changes in pitch, yaw and roll by locking them because we don't want our platform to do any of these movements. There is actually only one kind of movement we want and that's along the local axis (See platform image, where A is platform beginposition and B is platform endposition).

 












So we set our local axis to the direction the platform is moving which is the normalized vector of B - A. Then our normal axis should be set by rotating the local axis 90 degrees on the z-axis. And the binormal axis will be calculated by the physics engine (using a cross product). But we're actually working in the 2D plane and we might as well pick the z-axis to be our normal axis, which is simply (0,0,1), thereby avoiding doing a vector rotation. The result is satisfying: no more wobbliness. Unfortunately I can't show you that in an image, so you'll just have to believe it and verify it when the game is finished :P

Till next time,

-- Stijn

Geen opmerkingen:

Een reactie posten