Collision Detection for all frames

0 favourites
  • 14 posts
From the Asset Store
three fully animated characters ideal for your RPG side scroller projects
  • I'm wondering how to set up the collision polygon.

    Is there a quick way to do it for each frame in an animation in one go? At the moment, I have to go through each frame and tell it to guess the shape. Is there a one-click solution to this? I tried the apply to other frames button, but that just duplicates the current shape.

    I currently have only 20, but that's for a single animation. I aim to have another at 50, and the list may grow. If this isn't currently an option, can this be a requested feature?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • That's what the 'apply to whole animation' button is supposed to do, what's it doing wrong?

  • Ashley - it's applying only the first frames poly. Which, in an animation is hardly beneficial.

  • Yeah, this is the problem I am facing. I would prefer the software to automagically update the poly per frame, not just base it on the original :)

  • Ah, so you mean a 'Guess poly for whole animation' button?

  • Exactly! Autopolies for each and every frame would be great.

  • Some of the 'Guesses' C2 has made for me, I would have thought it more practical to do it yourself.

  • Possible, Zenox, but it'll take a very long time for a few of these. I don't need exact precision, but would prefer "guess" to collision with transparent box surrounding sprite.

  • I totally understand what you mean, but personally don't agree :)

    For instance, if I have 10 animated characters, each with 16 frames of animation, it still would only take about 20-30 minutes to quickly setup the collision points as I want them. That's hardly what I would call a long time. Even if it took half a day, that's still a small amount of time for such an important aspect of game creation.

    But, each to his own. If Ashley does this and people find it useful then that's all that really matters in the end :)

    zen

  • I agree with you. If I were to be making a game, and I wasn't confident on the accuracy of the Autopoly, I would probably do it by hand. If, on the other hand, I was making a quick demo/prototype, I would prefer to have it immediately, or even to a state where I could just manually touch it up afterwards.

    In video, I often used to manually mask out footage. Then I bought a green-screen. Using a combination of the two, I can get very good looking results.

    I completely agree with you that manual gives you exactly what you want, rather than the "guesses". The sprite I'm working on now (UFO) has 19 frames looping as a stand still, and 50 frames when it crashes. I could do it by hand, but for me, 20 minutes for what I consider a 'demo' is quite a lot of time.

    As you say though, to each their own <img src="smileys/smiley1.gif" border="0" align="middle" />

  • Also, zenox98 - those 20-30 minutes would be necessary for EACH ITERATION of an animation. So what you are essentially suggesting is - if I tweak the animation I get the super fun times of doing it by hand all over again. And this every time an animation changes, which can be quite often, really.

  • Hi, not sure what the rules are on bringing old threads back from the dead. Just a quick question. Before I purchased Construct 2, I used The Games Factor and MMF2 quite a bit.

    Thinking about this, I found it odd that transparent pixels are included in collision detection, or even that a collision polygon is always needed. I loaded up MMF2, loaded in the same sprites I've used here, set up the scene in the same way, and ran it. I moved one UFO onto another, and there was no collision at all on the transparent section of the sprite, in fact, collision was pixel perfect.

    Now I'm all for sticking with Construct 2. I feel it's got a better future and the features that are coming out are incredible, even it's its development stage.

    My question is - Can we have it so transparent pixels are not included in collision detection? I can't see any practical use for it. If we want players to be stopped by invisible objects, can't we just have a block and make it invisible? I feel this would make a better default, that is if it's possible? Maybe it will be a lot more powerful if included with the collision polygon, or have it as a toggle. Personally I can not see how a collision polygon is better than ignoring transparent pixels altogether.

  • 20-30 minutes is a huge time imo. Applying things for all frames is a must if an engine want's to be called productive, easy to use etc. And about the pollygon collision, can you not edit it ? Like by dragging the rect or something. I thought you could...

  • Hi Kiyoshi,

    Yes, you can edit the polygon collision, but I don't see the reason in including transparent pixels in collisions. It would save a heck of a lot of time if collision polygons were simply not needed.

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