Deadeye, not at all, though I appreciate your being humble. It was a useful honesty, because now, for example, I know that in a final game I'd have to demonstrate to the player that crouched jumping is much more useful than a standing jump. I could animate the player to crouch before every jump, and have them all the same strength, but I felt like including that control. Have you ever tried jumping from a standing position? I can barely do it, heh. But it could be useful for hopping off ledges, etc. As for TimeDelta, I'll double check my events to make sure. For some reason I put "every 10 milliseconds" on a lot of automated events, only using always (every tick) on events that change the value of some variable, such as max speed or jump strength, based on some equation. I don't know what's best performance-wise, though.
revolther - that's actually an interesting idea; simplistic robot, with little latches running about dodging things. The fun part in a game like that would be programming all sorts of hazards to avoid. The autojump in this just works, intrinsically, to allow the player to exit the pool. It's pretty basic: if there's a box in front of the player's feet, and that direction is being pressed, jump. In that test build I think you can actually hold left against the far, low wall in the second level and just hop indefinitely, getting nowhere.
I've changed it so that isn't possible (by raising the bottom of the boxes so they aren't detected), but for example in the pool the reason it works is because after the first hop, the upper protrusion catches the top of that block, which makes the player object think it's on the ground, so it still sees the box, and hops again. It also really relies on the stepped nature of the lower bounding box to catch and hop again if the first jump falls short. I like it, but I'm not sure how to integrate it into a new hang / climb system; maybe it will just work, I don't know yet.
Much of the world interaction requires a good bit of meditation and deliberation on my part to make sure it all works together right. It's sort of daunting, I don't know. I'll probably just work on graphics for a while and then come back to working on the code, etc. I've tried different variations of speeds dependent on crouched height; I can't seem to find something that I like, and since every one thing affects the next thing, it's sort of a balancing act. But I'm not too worried, because it's mostly a cosmetic thing, as I don't plan on making the game very hard - not a lot of deadly enemies or pitfalls, mostly just exploration.
The animation should be interesting. It keeps me up at night. I plan to divide the player into two segments, upper and lower, which animate independently... if you've ever played Quake3, players in that are animated with upper, lower and head - I might separate the head myself - which all animate independently, even though they aren't using full body skeletal animation. Technically, they are, but only the three bones. Maybe I'll use Construct's bone system to connect some of the parts? I don't know, I guess I'll find out when I get there, haha.
In the meantime I've got a couple simpler ideas. To start, I think I'll try to make a platformer with climbing and hanging that doesn't use the segmented body or crouched height stuff; that's what's making this other one so complicated to animate, just thinking about it.
Sorry for the novel. It's easy to go on and on about something like this...