Well, my first tip with the bones system is don't start your bones on the hips. Make a "blank" bone and use that as your primary bone object, and attach your hips and everything else to that. That way you can move the hips around as well. It's a little odd when someone is running along and their hips and torso slide steadily along above the ground at exactly the same height.

Second tip: There's a ton of animation reference material on the web. Do like LmK says and google yourself up some. Depending on how you pose your keys you can make a pretty decent run cycle with four to six frames, but too many more might be overkill.

And a sub-forum might not be a bad idea... like a Help/Tech for anything that's non-Construct specific yet still game-creation related. Like how to make pixel art, or how to use Photoshop or Gimp or sound editing software.

You need to hit up the Construct Discussion forum to find the latest releases. Currently it's 0.99.7. They're always marked as "unstable" at first, so the devs can get community feedback on whether it's working okay or not. They usually get a stable release on the front-page a couple weeks after, depending on how they perform.

Hey Madster, guess what...

That was the first time I ever used it . It doesn't really work any differently than any other object, and it seems pretty intuitive.

In earlier builds people would sometimes complain that their .cap files were corrupted, but that hasn't been a problem in a long time as far as I know. I've never heard of a .cap file coming up blank like that, though.

Even so, crashes and glitches might occur when you least expect them so you should always make regular, sequential backups. That way if something does go wrong you will only lose maybe half an hour of work instead of five hours. Construct is still in beta, you know... you have to cover your butt

What's the filesize on that empty .cap file you have? Is it truly empty or does it just appear to be empty? If it's larger than a regular blank .cap file should be then I'm sure the devs would want to take a look at it, so you should post it to the tracker.

If it is just a plain old blank .cap though, I would try to remember the steps you took in saving it to see if you can recreate how it messed up. These kinds of bugs that only happen occasionally are hard to track down unless the devs have some clue about how to isolate the problem.

No, you will have to make your own particle system by spawning sprites to do that.

This one is a really mixed bag. One the one hand, it has really nice production values. The art, animation, and sound are all really nice. And the level design is interesting. I like how some of the levels have multiple paths.

But the control is... not so hot I would say. Sometimes it feels right, but most of the time it just feels clunky. Often times I would fail to grab a ledge when there was no reason on earth why I should miss it... my dude would be well above the edge of it, and I'd be pressing in the right direction, but he'd just fall anyway. And the inertia is rather unforgiving. I can understand having some inertia but this is just overkill. Unless you're running full speed then you jump or slide like, only half an inch. Obstacles that you trip over like small boxes and stairs are a cool idea, having to switch from running to walking to avoid them is a neat gimmick. But there were other weird problems like I would shake off all of the water after getting wet and he'd still slip anyway, as though I didn't do it all the way even though I know I did.

Overall I would say that for a game like this the control really needs to be more responsive in order to feel truly satisfying. Maybe I just need practice or something, but I made it to level 2 or 3 of the second course and I still felt like I was struggling against the player more than the level itself. The controls detract from the game, but it's not bad overall.

meh

I'm sorry, now I feel like a jerk

I do think the search for a more visual method of displaying math functions is an interesting idea though. I just can't think of anything that doesn't involve a picture of five apples over a picture of three apples and a cartoon worm wearing glasses asking how many apples there are all together.

It's an interesting idea for sure, but (ya know I love ya David, no offense ) in all honesty there's not much difference in reading that than there is in reading

clamp(3 * distance(coordinates, coordinates), 0, 100)

It's just that the components are raised up in their own sections instead of being in between parenthesis. If you were to squash it down flat it would read pretty much the same. Moving the components around is also an interesting idea, but practically speaking is that really any easier than highlighting the part you want to change and typing something else?

I know you were looking for a more visual representation of the structure of a math function, but from the point of view of someone who doesn't understand math, I think it's still going to look pretty much like math. The problem of learning and understanding the math concept behind it is still there.

I'm sorry, I hate to be a naysayer. Perhaps I'm just misunderstanding the point?

Ah. Even so, you still don't need those extra objects. You could give each of your slidey walls a "Slide" attribute and use Overlapping at Offset to check that you're next to that attribute. Or make a family called "Slide" and stick all of your slidey walls into it. Either way, having a bunch of extra sprites hanging around like that is pointless. It just clutters up your layout.

Create a layer as your topmost layer, place a full screen tiled background in black on it, and then fade that layer in and out whenever you need it.

Krush.

That's exactly how I do it. Even if I'm actually changing to another layout, I still manually make my own fader object on the top layer. I guess it just feels like I have more control over how it works that way.

What do you mean you can't have more that two levels? What's happening?

Perhaps it would be easier to help if you posted your .cap file.