Crystal Towers 2 - Vertical Platforms
Feb. 9th, 2008 11:51 am![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
But after a lot of frustration this week, and even more whiteboard note-taking (Whitney got me a whiteboard for Christmas, and it was fantastic, because I'm miswired like that) I think I might have just got them working. Nearly.

I was always pretty fascinated by the state of whiteboards in the CS department after someone had been working on something for ages. Presumably every fragment of information on them is in some way useful, but altogether they always look like unorthodox impressionist paintings born from too many packs of Wine Gums.
Anyway, the real point of this overambitious week is that I now have a grand unified Platform object that can move horizontally, vertically or any direction in between. Have a look at the practical demonstration - graphics are very much temporary, but it shows the kind of thing that can be done, starting off with dull simple left-right movement but gradually introducing more elements such as vertical movement and movement by sine waves for swinging platforms.
Vertical platforms sound simple in themselves, but it took ages to get these working at all - with plain horizontal movement you only need to worry about moving left and right in the same way as walking normally, but if the player is to be moved vertically, you've got to work against the gravity that you've written and build in support for that. And as much as you know I like MMF2, there's something very wrong with its detection of collisions of objects that have moved during fastloops - the whole thing works by looking at one invisible detector underneath the player and another one on top of the platform, seeing whether they match when the player is moving down and while the platform is moving in any direction. But as collision detection was so erratic I had to switch over to looking at the positions of each object instead and decide whether they were overlapping based on that information.
Another problem was that as I was moving detectors and objects around so much on each frame, it became very difficult to keep track of where objects actually were during it, no matter how much I put into debug information during the loops. (MMF2 provides a debugger for examining each frame, which helps a bit, but it's actions before drawing a frame that I was worried about this time). So in the end, I made it up to the player object to decide whether it was on a moving platform or not - that's what the "OnVert" property that's still in the text at the top right of the screen is for. When a platform is told to move, it checks whether the player is over it first and sets the OnVert property to its own ID value before doing so, and this is later used to decide whether to allow gravity to affect the player or not.
The trigonometric movement of the platforms is done by giving each individual platform a "Type", and writing a special-case set of pixels to move horizontally and vertically for each of them (I finally had to remember differentiation again to work out how the swinging ones should move). I might be able to simplify it a bit by putting another couple of values on the platforms to specify where they should move to on the next frame, and let the game work out the actual distances itself from there.
Frankly I'm very surprised that you've read this far.