wretchedshark's Forum Posts

  • procrastinator - are there any drawbacks to using user made plugins? (like do they not work in certain places, on mobile phones or web publishing for example)

  • Rory - someone left a link to an endless runner tutorial on a different program. i've been trying to recreate it in construct to use in my own game with different mechanics and also leave as an example file for anyone who wanted to learn from it - however i am suffering from the same problem.

    if made with dt it leaves tiny (dt spaced i assume) gaps in the floor tiles, i couldn't for the life of me figure out how to account for dt in all the equations

  • Rhindon - i'm not sure about other game types, the tutorials advise in platformer's for your player at least to have an invisible player box with the platform behaviour, and working as your collision mask, and then sticking your animation on top of that box with either pin or set position (i'm not sure which is better, if either is even).

    the reason i mention this is it follows the same principle, you can change your animations but your actual player (invisible under box) remains unchanged and therefore always interacts with the environment in a consistant manner.

    you could use image points to attach other invisible hitsensors and use that instead of the x and the y of the sprite's to weed out even further changes.

    (again i'm not sure which is the "better" approach pinning or setting a position), you could just make sure that it's there - by pin or set position - and then on collision or on overlapping the to-be invisible hit sensor take damage. if you change the sprites size later on you'll just have to change the image points and the hit sensor sizes instead of the code.

    it's not that big of a deal either way, just something to think about   <img src="smileys/smiley1.gif" border="0" align="middle" />

  • Rhindon - yes it is because of that, but only the Y is dead centre (since this is not using X).

    using the height seems the simpler of the two to put into effect. you could use x, just setting similar margins to the sides of both sprites and testing for when the player.x (plus margins) is on the x of the drbox/enemy.x plus margins. just seems a tad fiddly in my mind.

    i would advise not using a set number of pixels to add though (DrBox.y+50 pixels) and instead something that will change with your characters (should you choose to change their height).

    it is not necessary of course but will save a lot of tedium in case you decide your character is too big or small. or for copying and pasting bits of code to apply to other sprites (which i do a lot). and, as i was advised, if you do code something like a characters attack range versus a lot of enemies (for example) if you have to go back and change that in all the code (instead of setting an instance variable for range) it would again be tedious.

    (drbox.y - drbox.height) - instead of (drbox.y - drbox.height/2)

    • this is assuming the origin point is at the very base of the sprite image

  • compare the Y of them, the height instead of their horizontal whereabouts might be more applicable?

    so (this is without looking at your capx and assuming both have origin points in the middle)

    system - compare two values -

    > (mrstick.y + mrstick.height/2) is less than (drbox.y - drbox.height/2)

            > no damage taken

    > (mrstick.y + mrstick.height/2) is greater than (drbox.y - drbox.height/2

            > damage taken

    • plus half his height to give the y of where the bottom of mrstick is, so if his feet are higher than the top of drbox - no damage, if his feet are lower (greater in y) than the top of drbox than he can take damage.. adjust as needed

    *** if i've mixed up the up and down of the y axis just switch the plus and minus signs.

  • yes, i got one of the beta releases to look at another user's capx

    scirra.com/construct2/releases

  • AhemExcuseMe - i tried doing this some time ago (trying to make legs that walked) but was very unsuccessful due to the odd workings of physics and revolute joints.

    i tried to make an example of this using physics and joints but after fiddling with it for some time i decided that simulating a hydraulic joint was much easier than trying to get the picky revolute joint system to work. sometimes the joints of the arm piece would get "pushed out" of where its joint was (attached to the base), and when changing the height of the arm it didn't push the upright piece like i had thought it would.

    here's what i came up with:

    dropbox.com/s/7cv9qr7910xaoh8/hydraulicarms.capx

    if you want to try and fiddle with it, remove the pin behaviour from the arm1, add physics back and update the event sheet to reinclude revolute joints. maybe you will have some ideas that i did not!

    i did learn a new expression that may or may not help with my legs project though <img src="smileys/smiley36.gif" border="0" align="middle" />

  • every random seconds needs to be random(1,5) instead of a dash (random1-5) makes them spawn like crazy. also the spawn event random((12,1024, 1200) that Y coordinate is spawning them off the bottom of the screen - change to 0 if you want them up at the top.

    for easier debugging you can try setting your background to invisible and your squares to visible, it helps a lot when setting up your event systems.

  • gamekill - i made an example. i figure this could all be simplified using families but i don't (yet) have a license for C2 so this is another way to do it without using families. there are notes in the capx about families.

    hope this helps!

    dropbox.com/s/cw24j2xnngc24ub/sizeclicking.capx

  • the centre is probably snapping to the finger because thats where the origin point is, is it possible to set an origin point for each corner say and then pick the closest one for dragging?

  • mrtumbles - very nice solution, this actually might even help me on a game idea i put on the back burner - cool! :D

  • under your collision event sheet change "sword - on collision with beebot"

    to "sword - is overlapping another object (beebot)" and it works.

    to help with debugging i noticed that the top right bee would only die when being struck with the very tip of the sword. so if the player is right on top of the bee and swinging there is no collision to detect, the sword spawns already on top of the bee.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • tiled background:

    scirra.com/manual/118/tiled-background

    Or if your background remains the same it can be on a layer separate from the elements that will spawn and (presumably) scroll and therefore you wouldn't need it to repeat.

    Random spawning:

    gamedev.tutsplus.com/tutorials/from-scratch/build-a-canabalt-style-infinite-runner-from-scratch

    It's not for construct, someone posted it the other day, the same principles can be translated over to construct though. Instead of platforms you could spawn objects or enemies.

  • if you have families this may be able to solve it that way, since you would be able to pick the top/bottom of the family, yes?

    or without families perhaps you could create a condition with sprite1 is overlapping sprite2 and then find a way to get the behaviour you want with that filter. would something like pick top/bottom sprite1 OR pick top/bottom sprite2 work?

  • depends upon the game type i think. you can make it "unlimited" by creating events that randomly spawn objects (or obstacles in say a runner) and having a tiled background i believe.