I assume you're using the platform behaviour? You'll want to change the max fall speed temporarily.

Create an event that detects whatever conditions you want (in air, button pressed, etc.) and then set platform->max fall speed to zero, wait x seconds, set max fall speed back to 1000 or whatever it was before.

Here is a very simple demo using the sine behaviour [r125].

There's obviously a lot more that can be done with this from a gameplay point of view, but short of actually animating the traps frame by frame, the sine behaviour is a solid way to get this kind of repetitive motion.

The browser -> fullscreen action works in node-webkit. Looks awesome to have my C2 games filling the whole screen.

Just had a few minutes to play this. Here are some random things I picked up on:

• I really dig the visuals. They're crisp and clean and definitely oldschool, without feeling like cop-out "programmer graphics".
• The animations for the coin pickup and monster splats are slick. Also very clean - nicely done there.
• In the beginning, when jumping on the snowy roofs, I found that I was expecting to land a little higher up on them. Having some snow behind Rad doesn't make visual sense.
• The power meter seems pointless at this stage. Since so many enemies require the hammer to be used to kill them, I found myself quickly getting irritated because I couldn't use what screams to me as the primary weapon. I suggest offering players perhaps a weaker weapon with unlimited usage, and then switching to the hammer as a stronger, more resource-intensive weapon.
• The Goo lags behind too far when I'm walking quickly (eg: after clearing an area), and I can't see what's in front of Rad. I get that you want the camera to follow the Goo, but I highly recommend that you reconsider to make it follow Rad instead, or perhaps change it based on how far Rad is to the edge of the screen.
• I'm falling through some platforms and getting stuck on others. You should check that the collision polygons are lining up properly.
• Sometimes a slime monster was on top of Rad's head. I think it was because I jumped up underneath it.
• It's not always obvious what I can jump on. Most games of these sort use visual cues to help the player - eg: lighter objects can be jumped on, darker objects are to be considered "in the background" and can't be jumped on.
• I find that there are times when I'd expect that I'd be able to jump on a monster, but instead I take damage. I think it's just the hitboxes that need more testing.
• More of a game design thing: why can Rad kill slime monsters by jumping on him? Does he have magical shoes that protect him from harm?

I'm looking forward to the point-and-click stuff. To be honest it was the mention of that feature that pushed me to actually try out this demo, and not seeing it was kind of disappointing. I'd be very wary of going the Kickstarter route with even the mention of Monkey Island without first proving to potential backers that you're going to deliver just that. Gamers are a fickle bunch.

Stick with it - you're off to a great start!

Run an event that, every tick, increases a variable (let's call it spaceTimer) by 60*dt.

When your player presses the spacebar, set spaceTimer to 0.

Then, depending on what your other events look like, check if spaceTimer > 60 or whatever amount of time you want, and if it is then increase the opponent's score by an increased amount. Or increase the score by a factor of spaceTimer, if you want it to be non-linear.

Run another event that checks if the objects are overlapping. If they are, pick one instance and destroy it, then recreate it elsewhere.

The only issue you'd face with this is that if the player ever sees the items spawn, then they have a chance of seeing the overlapping items for a single tick. To circumvent that issue you could give your items a fade in, active from the start, that is almost instant. That way they'll be invisible when they spawn for just a few ticks.

Example capx.

BluePhaze, thanks for pointing that out. Weird, I tested it when I first put that link there and it worked fine.

That'll do it. Any other movement/rotation/etc commands given to a physics object override the physics and can cause all sorts of weird glitches.

You need to use the right joint for the right situation. I suggest that you read this tutorial: scirra.com/tutorials/65/physics-in-construct-2-forces-impulses-torque-and-joints

Check to see if your touch object has "use mouse input" enabled. It's enabled by default. So, in your case you should either disable it, or use it instead of the mouse. You shouldn't be using both together, which is probably giving you weird results.

Combining the physics behaviour with any other behaviour that affects position is usually a bad idea. The other behaviours override the physics behaviours and create a very unstable physics simulation. You should rather use the physics joints to attach together physics objects.

lukedirago, tutorials are your friend! Mine in particular: it covers everything from placement of turrets to generating waves of enemies.

It's pretty basic, but it should set you on the right path.

Wow, this thread is old.