My ongoing list

This forum is currently in read-only mode.
  • Using a separate invisible sprite as a collision mask is the usual way to go about that.

  • Just found out that if you set the collision model to be 'per pixel' and you scale the sprite in the layout editor, the 'per pixel' stuff is still being based on the 1:1 sprite.

    Wouldn't it make more sense to base it off of the actual pixels of how the sprite is being drawn at runtime?

  • Yes it would, that's a bug that should be reported.

  • What??? It definitely shouldn't be doing that - I definitely wrote it to scale and rotate collisions too. Submit a bug report!

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • What??? It definitely shouldn't be doing that - I definitely wrote it to scale and rotate collisions too. Submit a bug report!

    Already did

  • 35) Let's extend the picture (sprite) editor to have an optional collision layer on top of each sprite. Or multiple layers. That we could then trigger through events.

    I think that'd be the simplest way to define weapons and stuff for collision events.

    So, in the picture editor, I'd create my sprite and then create a new collision layer (like in Photoshop) that I could fill up with pixels. Then I call my collision layer "swordCollision" for example. If I go to the next frame, it'll automatically copy over the collision layer from the last frame and I'd just do my adjustments. So for the whole animation, I'd have one big collision set of layers that could be triggered through the name of the collision set.

    So, to set an attack event, I could do this:

    If Attack is pressed, if player.swordCollision collides with enemy = decrease enemy private variable 'HP' by 10.

    Simple.

    Being able to have a seperate layer in any sprite that you could fill up with pixels based on what should and shouldn't collide with whatever would be a very, very handy feature.

  • #35 - I suggested something like this somewhere, along with some other options for collisions. I thought it would be a good idea to have different animated masks for sprites corresponding with the actual animations, giving pixel perfect collisions that don't match the sprite.

    Combining my idea with yours, there could be several collision layers - for sword, shield, body, etc. E.G.:

    On collision between Family('Enemy') and Player.CollisionMask.Sword >> damage Enemy

    On collision between Arrow and Player.CollisionMask.Shield >> Destroy Arrow, play sound

    On collision between Family('Enemy') and Player.CollisionMask.Body >> damage Player

    I think we're onto a winner here.

  • Yes, I think that'd work.

    Pretty please?

  • 36) Export Layout to Exe

    That'd be pretty awesome. If I wanna show a person just a certain level or another developer a certain problem or whatever, I could hop to the layout that I'd need to show them to, press 'Export Layout to EXE' and the layout would be exported into an exe - just as if I'd run the layout as a runtime only.

  • 37) Animate along a path.

    I'm currently trying to put some birds / seagulls in the game and thought of this: It'd be really, really cool if we'd have a feature like in Maya / Max / After Effects or whatever where you could build a spline and then just let an object animate along that path.

    That could be very powerful for animation of all kind, especially for backgrounds. Setting a couple of curves on a layer in a couple of layouts and setting a random value for the intervals would really help making a scene come to life. Leafs, Birds, Dust, Sprites, Particles, etc. - could be used for anything.

  • A path movment is already in the works for .99 I believe, and if not than its already pretty easy to implement with RTS and a bit of coding.

  • 38) Thanks to Deadeye I know how to toggle events now based on timing, but it would be cool if we could do something like this natively without workarounds:

    If Attack is pressed - Set 'Attacking' Global Variable to 1 for 300ms

    • Get it? Means, it'd be cool if we could time actions like that. And once the time runs out, the value that has been set will be set back to what it was before.
  • You could just do

    "Attack key is down." -> Set attacking to 1

    else -> attacking = 0

  • You could just do

    "Attack key is down." -> Set attacking to 1

    else -> attacking = 0

    I know. But that's the catch. Usually, for attacking, you don't want to hold the attack key down.

    You want to press it once, see the attack animation do its thing and set the value back once its done. So you need to time it.

    What I've set-up is:

    1) On "Attack" pressed

    + Is global variable 'Attacking' Equal to 0

    -> Set Animation to Attacking

    Play current animation

    Start ignoring user input

    System: Set gv 'Attacking to 1

    Function: Call function "ReturnControl" after 400ms

    Function "Call function "SetAttackBack" after 400ms

    2) On Function "ReturnControl" -> Player: Stop ignoring user input

    3) On Function "SetAttackBack" -> System: Set gv 'Attacking' to 0

    So it'd be cool if I wouldn't need the function object in every layout just to set the values back.

    Also, the cool thing when you time it is that you can either let the animation play all its frames or interrupt it beforehand, cause if the animation needs 800ms to complete, but you get your input back after 400ms, you can interrupt it and keep going - that's exactly what every Castlevania title is doing, for example.

  • Can't you make it global?

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)