mattb's Forum Posts

  • Got it Rojo, that makes sense & it works now. I think Chipmunk could do with a new 'bond' or 'superglue' joint which uses the pivot/gear combo.

    CrudeMik - that's not grappling. THIS is grappling <img src="{SMILIES_PATH}/icon_e_wink.gif" alt=";)" title="Wink">

    https://dl.dropboxusercontent.com/u/523 ... index.html

  • Seems you're the only one I'm in there most evenings if you need a tester, but as a regular weekly day/time what would be best for you?

  • Roid rage I had a go at making something like this & also had trouble with joints. I think I found a bug too, so...

    R0J0hound check out the capx below (sorry for not simplifying it). If you enable event 3 then the ContactPointX/Y expressions in event 21 don't seem to work (the hull_damage sprite gets spawned off screen somewhere).

    Strangely this happens if you put any actions in the foreach asteroid event.

    Also the pin joint doesn't work as expected. Instead you get a freely rotating pivot. Maybe this is how chipmunk works & you need 2 pins to lock a pair of objects together?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • So If I understand well your message I can do something like this :

    Create a two dimensional array with a width about 100 and a height about 60, then I fill this array with my block X and Y coordinates and I set the block UID at this index.

    Then I can do : block pick by UID = (array.at(someX,someY)) ?

    And that would work with the expected performances ?

    You only need to fill the array with the block UIDs. You choose which array element to set according to the blocks xy position, using something like this:

    [attachment=0:znm5miv9][/attachment:znm5miv9]

    For performance, as rojo explained you eliminate the need for many (many as in 16 million ) comparisons. Providing this is a desktop game you should be fine, mobiles maybe not.

    So it'd be just like working with a tilemap & you'd be using equivalent expressions to tilemap's 'tileToPositionX/Y' & 'positionToTileX/Y'.

    tileToPositionX's equivalent would be something like: (array.x * gridsize) + (gridsize/2)

    positionToTileX would be like in the image above: floor(block.x/gridsize)

  • here you go:

    EDIT - don't use dt

    [attachment=0:yk7uh39h][/attachment:yk7uh39h]

  • I've been enjoying watching your prototypes & love the sound design in all of them (Attract especially, which I tried to rip-off until discovering that keyboards don't like multiple keypresses).

    If you wanted to make your game fully procedural, you could try Yann's polygon plugin - - to generate the asteroids. That would also allow you to split them, which might make an interesting mechanic where you use the laser to carve up specific shapes.

    Other ideas:

    -let the player zoom out to a macro view & see what's in the neighborhood for planning (fuel, collision interactions).

    -have some global affector to the levels like a swirling gravitational field (like the orbit levels in osmos), or a neaby sun where you use line of sight to heat the ships, & shadow casting to see where the cool spots are.

    -if this is physics based then i recommend rojo's chipmunk plugin over the native one - it lets you do raycasting, query individual collision points, make any kind of joint...

  • — le Canapin I think you should rewrite this to use tilemap for everything. Your slowdowns are probably to do with having separate sprite instances for each block.

    As a quick fix, you could try replacing the 'pick by evaluate' condition in your 'getblocksinradius' function with something like 'block is overlapping explosion' (collision testing is probably more efficient than evaluating an expression for each block instance).

    But still I think you need to be using only a single tilemap, not lots of sprites. If I get time later I'll make a capx to test this...

  • Nice system. The performance should be fine, just loop through the tiles in a square that bounds your explosion radius. You could have a set of jagged-edge sprites around the holes instead of slopes, & could probably get away with a larger tile size in that case (since you're faking extra detail & won't see squares).

  • I'm often in need of some fresh eyes on a control scheme or level that I'm working on, & with playtesting I find a chatroom to be a better venue for feedback & discussion than a forum.

    So is anyone interested in arranging a regular time each week for testing their games or seeing what other c2 users are up to in the chat?

    I'd propose sunday afternoon or evening UTC (which would be after midday EST). What do you think?

    The irc chat is here:

    with an irc client: irc://irc.esper.net/construct

    from your browser: http://client00.chat.mibbit.com/?server ... 3construct

  • Chipmunk starts to use more cpu as the balls settle (which they shouldn't be doing). The settling becomes more pronounced as the object count increases.

    Chipmunk's default settings for putting an object to sleep seem too aggressive. I sometimes get floating physics sprites when an object underneath is knocked away, worse for circle collision shapes since their contact area is lower.

    A fix is to adjust idle speed threshold and/or sleep time threshold. Maybe try an idle speed threshold of 0.5s at first. If things are still settling too soon then lower it, or try a sleep time threshold of 2s.

    You can disable sleeping altogether by setting sleep time threshold to 'Infinity'.

  • R0J0hound - the collisions in chipmunk seem more imprecise than c2's physics. I noticed the 'set fixed timestep' action defaults to 1/30, so does this mean the physics calculations are being done around every 2nd frame?

    The capx shows what i mean - the red box with chipmunk clips into the floor on collision then moves back up, while the c2 physics box just stops dead:

  • Your demo is playable on desktop too with only a few glitches, & I think it's going to make a great mobile game. I was compelled enough to play through all the levels which were well-designed & ramp up in difficulty nicely. Some ideas:

    • The immovable metal crates could be more visually distinct from the wooden moveable crates. Maybe make them look more like parts of the scenery, like girders or rock, & less like crates.
    • Are you going to add a destruction effect when you click on something? That would make clicking much more satisfying & fit with the mining theme.
    • As an extra mechanic, how about explosive crates that explode if you destroy an adjacent object? I know you've already got the skulls as things to avoid, but some TNT crates could also play a role in solving the levels (by moving things from their physics impulse) as well as being obstacles.

  • That could be it, I can't see it though - I found another solution that seems to work so my brain has given up on me I appreciate the idea though.

    What I'm doing is storing the rope's start & end positions for the last frame, then when it overlaps a collision box I lerp a ray backwards from the rope to its previous position. Once the ray isn't overlapping the box & is overlapping a corner test sprite, you pick that corner (or if there's more than one, pick the closest to the rope's start).

    With some optimized lerping, it never takes more than 5 loop steps to find the corner, even over large distances.

  • R0J0hound this is brilliant, exactly what i'm after, thank you!

    Prominent you might already have tried these, but for checking internal points there's the Pick overlapping point condition, & for moving them back out the Custom Movement behavior has lots of 'push out solid' options.