Since deadeye doesn't seem to like my per-pixel bounding box sprite having protrusions, I can go back to using a simple box object* as my platform movement object, and instead of having the bounding sprite catch ledges, do something similar to his ladders in Platform School. If I have an automatic step-up (hopefully better than the one in the present demo, which is already outdated as it is) then the short distance to "climb" will just be a short, invisible ladder. It will require changing the crouched height so as to pull the legs up with the body/arms still hanging onto the side of the ledge. When the legs reach a certain height, it will then do the step-up. Which would presumably be animated properly at the proper crouched height.

It's all really too complicated; I can think of the gameplay I want, I just don't know the best or most efficient way to implement it. Right now this would also require multiple conditions depending on if the player is pressing in the direction of the cliff they're climbing (releasing the key should make the player drop back to a hang), and animating in an entirely different way depending on if the player faces the other direction while hanging... and allowing an outward wall jump if they are. The list really goes on, and with all the movement I have in mind, the number of animations required (since it's just going to be sprites..) is through the roof, but I have ways of dealing with that, so we will see.

<img src="http://img.photobucket.com/albums/v325/mwahaha/cthulhu/hanging-concept.png">

* I'd probably use a box sprite anyway; box objects don't seem to have 'overlaps at offset'.

No... never!

On the topic of keyboard values, given the popular trend of WASD movement controls in Construct, I am for changing the key detection to something based on key location rather than visual identity. Not everyone uses qwerty and azerty, you know?

To clarify, ',aoe' is my 'wasd', but I know there is a way to make applications register key presses based on their location rather than their character value.

edit: key scan codes? http://en.wikipedia.org/wiki/Scancode

Interesting! Just the sort of feedback I was hoping for. Thanks deadeye, you're the best.

As for the appendages, this is just the bounding box, I guess I should have explained the idea a little. I've got to rewrite everything completely to include TimeDelta, and at that point I think I will integrate them fully - they were more of an accident... but essentially, it's to allow the player multiple stages of 'hanging'. There must be a better way to do it, but I figure once I get a sprite animated and overlayed (these objects hidden) it should make more sense - stepping up, grabbing the ledges, etc. I'm actually lying to myself, because it just won't work. The player's lower half needs to pull up, after hanging on with the upper half, but I can't have both objects with the platform movement, because one is used for testing, etc, and it is just a big sorry mess of my not being a programmer.

... The red flag was also a complete accident, but I thought the movement was predictable. I guess it's sort of complicated, and would need again the animations to be present to understand how your character is moving... but, I could just make it simpler. It's basically, tap left, then right again, but that doesn't really make much sense.

edit: hah, yes, I see, it's doing all sorts of crazy things. Hey, that's a feature..!

Sorry about the physics objects overload, it would have been a cruel thing to crash your whole computer. I was thinking about them last night; this was just for my own amusement, to make a ball pit of sorts, but it also led me to discover various bugs and other methods of creating the effect I want. Basically, in the next re-write there will be no active physics objects until the player splashes them into the air, at which point they are purely cosmetic (and will have sprites to look more like splashes/droplets depending on their upward velocity). I see no reason to have fully simulated crap if it doesn't look right and isn't actually contributing anything but lag most the time, so presumably faking cosmetic stuff is where it's at.

I agree, it is completely unusable at the moment, but it did allow me to get my own thoughts in order. The movement was the main test, everything else basically... crap thrown in to have something to do..? Very sloppily. Next writing, I think I'll concentrate on getting movement working exactly how I want it, instead of a weak approximation. At the moment, it's pretty poorly conceived... movement, acceleration and jump strength are all affected by crouched height, the strongest apparent effect being air x velocity, which is more or less halved if the player is standing. It seems to work well for me if the player knows they must crouch to make a distant jump, but without knowing that I guess it's kind of lame.

Run speed and acceleration increases as the player reaches a height of 75 (100 and 50 being standing/fully crouched) - cosmetically, I thought it added a sort of 'bumbling' effect, but it makes more sense to have acceleration constant and only change the movement speed. The levels aren't meant to be extremely challenging; a lack of TimeDelta may be the reason for its present failing. I really dread implementing it, because from previously setting the speed to an exact value using an equation, it becomes guessing, adding amounts based on some secret hidden decimal...

Good morning!

This isn't much, but a concept for the sort of platformer I'd like to make. I know everyone is making platformers, platformers, platformers, but I do love them myself, so I'm going to try for a sort of cross between Super Metroid (mobility, exploration, atmosphere) and Another World (survival, story and character).

It's not in TimeDelta mode yet, mostly because I'm not sure where to use it, or how to adjust my parameters without just using trial and error so they work they way I want them to. That and the code is pretty sloppy. Still, if you can run it at a vsync'd rate reliably, feedback/ideas would be cool. If you want to stea.. I mean, critique the code, I can upload the cap.

I plan to add a large sequence of animations which change depending on crouched height, as well as a fully animated world. Right now it has absolutely no graphics at all. Not settled on a style yet. But yes, the player character will be a man, not a faceless grey robot. Without further ado,

((I don't know why or how people keep hunting this down (perhaps it's webcrawlers), but it's old and quite terrible, so I'm removing the link.))

<img src="http://img.photobucket.com/albums/v325/mwahaha/cthulhu/movetest0d2009-05-1305-01-38-54.png" border="0" />

Bonus! Ambient music beta: <a rel="nofollow" href="http://www.box.net/shared/uknkz6koyj">http://www.box.net/shared/uknkz6koyj</a>

http://www.youtube.com/view_play_list?p ... 93485CD2F1

Recorded and posted by someone on another forum, thought to repost here. Nice talk, entertaining, etc. Watch it!

Here's a couple tools I've found useful:

• SFXR: The best tool for making your own 8bit sound effects for video games. Highly recommended, if 8bit sound effects are what you're after. And it's free.
• Audacity: Sound editing software. It's good, but not great. Then again, it's free. Oh, and open-source.

SFXR is opensource; has anyone thought to integrate it into Construct?

I like the feel of it. Fun to play with, needs big levels!

The birds are a great touch, I like them too.

Cool game! Needs more shiny and decorations in the environment now.

I really enjoyed the feel of keeping the rocket afloat.

This is neat, but I'm not sure if shadows add like that...

A wired USB 360 controller is about the best gamepad I have found for PC. Because it wasn't built like most flimsy crap PC controllers. PS2 ones are great too, not got an adapter for that yet.

Demo app is epic! Controls nicely. (:

I've played through the tutorials, and they are really grand! Spot on. I commend ye, deadeye.

The moving platforms do not work correctly for me; perhaps this is a bug introduced with *.2.