dpmontes's Forum Posts

  • Pakost

    It would definitely not be efficient to every second check whether every unit in the field is within the ellipse of an enemy unit. A good game will narrow down to just the bare minimum what it needs to be doing every second. For example, a three dimensional game will have algorithms to determine whether objects are occluded from your viewpoint by a wall or some other barrier. If you can't see that hidden object, there's no point in the game wasting time and drawing it. So you would need to develop a way to only test the more costly ellipse collision if there is a definite possibility that the enemy is indeed overlapping the ellipse. An enemy that is on the other side of the screen can't possibly be within the ellipse. One way could be to enclose the ellipse in a basic rectangle. If a unit is overlapping that rectangle, then you will do the ellipse collision test once to determine if the unit is touching the ellipse.

  • dougieddug

    In a nutshell:

    1. Determine the size of your grid tiles such as 16x16

    2. Take the x coordinate of your sprite such as 77.

    3. Divide that coordinate by the size of your grid tile so 77/16 = 4.8125

    4. Discard the .8125 by using the floor(77/16) = 4

    5. Multiply your new value by the size of your grid tile so 4 x 16 = 64.

    What this does it removes the fractional component of each coordinate. So any x coordinate from 0 to 15 will snap to 0. From 16 to 31 will snap to 16. From 32 to 47 will snap to 32. From 48 to 64 will snap to 48.

  • Merries

    Not real sure about which math formulas you need exactly so let me know what you want and I'll see what I can do. Also, start your message with "@farmerdwight" so I get alerted to your response.

  • Pakost

    The basic formula you will need is (x-h)^2/a^2 + (y-k)^2/b^2 <= 1

    x and y are going to be one set of coordinates say for the bad guy

    h and k are the other set of coordinates say for the good guy

    a is the radius that the ellipse extends horizonally

    b is the radius that the ellipse extends vertically

    If the equation is less than 1, than one set of coordiantes is within the ellipse that is centered on the other set of coordinates.

    So lets say that a bad guy is located at x and y coordinates of (50, 100) and has an ellipses sized detection. The ellipse extends 20 pixels above and 20 pixels below the enemy so the b value is 20 and it also extends 50 pixels to the left and 50 pixels to the right so the a value is 50. (Remember that the screen takes place in the 4th quadrant of the cartesian plane so the y axis increases as you move down.) The Hero is located at h and k coordiantes of (90, 95).

    Is the Hero within the ellipse?

    The equation will be populated like this: (50 - 90)^2/50^2 + (100 - 95)^2/20^2 <= 1. If you do the math, you see that it comes out to .7025 which is indeed less than 1. So he is within the enemy's ellipse. It doesn't matter whether you subtract the hero's coordinate minus the enemies coordinate because the value is being squared anyways. Just be consistant. (x - y)^2 will yield the same value as (y - x)^2 so don't get hung up about which coordinate is which. you are just finding the DIFFERENCE between them and squaring that value.

  • I don't have much time to troubleshoot this right now but when I disabled the "System Restart Layout" action, it started working. So the game is constantly restarting the layout so you need to figure out what's up with that.

  • codeHammer

    I've tried your game from Easy to Insane and I don't see the issue you are talking about. Each tile changes colors by itself and doesn't affect adjacent tiles.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • weisdaclick

    The second line you wrote (MYArray.At(0) + MYArray.At(1) + MYArray.At(2) + MYArray.At(3) + MYArray.At(4)) /5 is correct. You have to force the additions to take place first before the division is applied. I guarantee that. As for why it's not working, I can't tell you whats wrong without looking at your exact code or syntax.

  • Post a .capx

  • A + B + C + D / X is not the same as (A + B + C + D)/ X

  • That's why you shouldn't bother with the bullet behavior. Then you have to deal with angles and all that. Much easier to just give him a platform behavior. I've been there, done that. Just give him a platform and give him a little negative or positive x velocity and some negative y velocity. It'll make him pop up and drop back down.

  • I would create a sprite that has several different animation frames. Frame 0 could be a sponge, frame 1 a television and frame 2 a water balloon.

    I would give the sprite platformer behavior. When you want to spawn an instance of that puck in the bottom center of the screen, you would give it a random x velocity from maybe -100 to 100. Then give it a Y velocity of -600 to -800 for example so it will pop up and then fall down. You would also choose which frame would be showing to represent which object you want.

    Platformer isn't necessarily designed for this because it has in mind that you would be controlling the "sprite" with the arrow keys or something. But I find that it's the easiest to manipulate still compared to physics which will have a lot of junk you don't need for a simple object being tossed up in the air and falling down. Doesn't sound you'll be wanting objects to collide or anything cause they didn't in the original game.

  • Real easy to do. Just needs a little math. So suppose your grid is based on 16x16 sized squares. So if a block is anywhere from pixel (I'll just be talking about horizontally so the x-axis but the same will apply to the vertical Y-axis) 0-15, it will be in grid 1 and if it is in 16-31, then grid 2 and so on. So lets pick a pixel location say at x position 17. Take that number 17 and divide by the size of your grids which is 16. 17/16 = 1.0625. Now we want to use the floor fuction on that number so the floor(1.0625) = 1. Now multiply your new number 1 by the size of your grid which is...16! And you get 16. So any location from 0-15 will become 0, any location from 16 to 31 will become 16 and so on.

    Here's some more math stuff you can play around with.

    scirra.com/manual/126/system-expressions

  • I haven't tried this but I would create a rectangular sprite that is red and that covers the whole screen. I would then set the Opacity to oscillate from 100 (red) to 0 (completely transparent) using the SINE behavior.

  • It sounds like what the problem is you have the game subtract health "when overlapping the wall?" as opposed to "on collision with the wall?" The game rapidly constinues to subtract health in the blink of an eye cause the player is still "overlapping" the wall. But if it tests for "on collision", it should only take a hit once even if the player is standing by the wall. The player will then have to break contact with the wall and "collide" again to trigger more health loss. Also, you don't need a compare variable to determine if health is equal to zero. Just compare your global "health" variable directly to zero, not to another variable that is equal to zero cause that's redundant.