mrtumbles's Forum Posts

  • Another options is:

    Zombie is overlapping Zombie

    Pick top instance of Zombie

    Zombie: Pathfinding: Set Speed to <decreased speed>

    Might work well enough with some tweaking - although collision checks will suck if you're planning L4D/DR-style hordes

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Radulepy I would create the vector field by pre-filling an array with vectors (which are number pairs describing a 2D direction and speed of movement).

    For each zombie, find all zombies within whatever range you want them to avoid one another. For each one of these, compare its location (relative to the first zombie) to a location on the array, which will contain a vector. Add these vectors together, and apply them to the X and Y position of the first zombie, and they will all automagically avoid one another.

    For more detailed description please see the link I posted above. It describes the process far better than I can.

  • I have a suspicion that 'on tap gesture' relies on the user touching and releasing - similar to the difference between 'key is down' and 'key is pressed' in the Keyboard object, or 'mouse button pressed' / 'on click'.

    I'm assuming your users will touch to begin aiming, and release to fire? I can't view the video (very poor internet connections here) so can't verify what you're trying to do, but this is my best guess. If this is the case, you'll want to use 'On any touch start' instead.

    [ Edit: Can confirm, through use of RTFM - tap is a touch and a release within a given time-frame:

    https://www.scirra.com/manual/119/touch ]

  • You might want to consider vector field collision avoidance. You can use it alongside existing pathfinding (if you're careful) to create the behaviour you describe.

    Read more here:

    buildnewgames.com/vector-field-collision-avoidance/

  • Only if every object in that family has its solid enabled, which it doesn't, and only if all objects required for collisions are of the same object type, which they're not. As I said - I tested both methods, it's more efficient and easier to read an angle check. All of these things have been discussed earlier, you should really read the thread before posting.

  • As discussed before, this would involve multiple families, multiple events, and it turns out an excess of collision detection. Angle check works like a charm using a single event. Alternative took ~15 events and made an absolute mess of the rest of the capx adding unnecessary properties to objects by family etc. Marking solved.

  • I am already. There are a few other sprites pinned to the bullet which give me usable angles for everything else thankfully, the bullet is JUST used to control movement angle of the collection of sprites so haven't used its common angle property at all.

  • Just the 1!

  • Grah.

    Another more elegant suggestion from reddit: compound the angle changes made in a tick to a single variable without passing them to the bullet, store it for the next tick along with the bullet angle, then check the bullet's previous angle against its current angle, offsetting for the previous tick's angle-adjustment - if there's a difference it should mean the bullet a bounced. Out of frustration I've moved to another part of the game to work on that, but when I return to collisions I'll try both implementations I think.

  • Because the events might end up getting complex in the future as I add more solid objects, and not all objects carrying the solid property have this enabled.

    Construct classic had this functionality OOTB - you could select the 'Solid' attribute in place on the selected object in the 'on collision with...' dialog - hence my hope there is some way of simply checking for collision with a solid.

  • Would that not have the same effect as doing the collision checks on the bullet itself?

  • I have a bullet which bounces off solids. When it bounces, I want it to decrease in speed, and generate a particle effect. How can I detect a bounce, in order to do this without performing a bajillion 'on collision with' conditions?

    Edit: Other factors control the angle of the bullet - so detecting an angle change isn't accurate enough unfortunately

  • It does! Only a few at present, but the full list planned for release is:

    All basic tools (single strokes of letter keys - rush, [E]raser, [K]rop,

    atch, catter, [C]opy, [V]aste, dropper)

    Previous/Next Patch ( [ / ] )

    Layer selection (Ctrl + 1/2/3)

    Save/Open project (Ctrl + S / O)

    Undo/Redo (Ctrl + Z / Y)

    Thanks for giving me a good excuse to write those down by the way. You may have noticed the ability to store 'patches' for convenience - it would be nice to be able to hotkey some patches, but I'm sure that would require ground-up rewrites of some areas so may have to wait for now. Thanks for the question!

  • Regarding that issue - Laid (as you may have noticed) does have layers, which are always exported separately. Lots of opportunities for handling multiple tilemaps!

  • What's wrong with Tiled?

    I'm aware this question was aimed at another commentor but it deserves answering by me anyway

    Tiled can be a little impenetrable for new users. This is partly due to it having advanced functionality that's not supported by Construct 2. Between those two things it seemed to me that there was room for another tilemap editor that forms a halfway-house between the inbuilt C2 tilemap editor and Tiled in terms of usability - and hopefully on-par with Tiled when it comes to Construct-compatible features. I'm not saying there's anything wrong with Tiled - but perhaps there's something a little bit right-er for C2 users