oosyrag's Recent Forum Activity

  • It is possible.

    The most straightforward way would be to push the x/y coordinates of the input every tick into an array. To replay, just go through the array and draw from each saved coordinate instead of the mouse/touch input.

    I don't know if there would be performance issues without trying. You can trade resolution/accuracy for performance by adjusting how often you save a set of coordinates.

  • Check out the first example here -

    +1 "not easy".

  • You will use the min() expression. This will give you the smallest number out of the numbers you provide.

    So when you reload, you will subtract min(ammovariable,15) from ammovariable. If ammovariable is more than 15, it will subtract 15, if it is less, it will subtract ammovariable, leaving you with 0.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • That just says the sprite can randomly start at a speed anywhere between myvariable and my variable+50. It is a small optimization, not required, to make it look better, as I am creating multiple instances per frame (due to the repeat). This way multiple sprites created the same frame don't all have the exact same speed, and there is some variation.

    The speed starts at 0 to represent the pressure/spray from a water gun. This is necessary as you requested that the spray gradually decrease after letting go of the fire button.

  • A simple method would be to use an invisible helper sprite pinned to your player. This helper sprite should be as big as whatever you determine "near" to be. Then you can use this helper sprite as a condition - when it overlaps an obstacle, do something to player sprite.

  • Never mind, looks like adjacent doesn't count as overlapping after all. Pretty much ignore everything I said in the last post. Experimented a bit and this seems to work: https://www.dropbox.com/s/xgmojljasm5e6 ... .capx?dl=0

  • That idea sounds about right. You'll want them as close to the edge as possible though, so they'll be able to help you "clear" the corner. If they are 4 pixels away, then you might get stuck on the 1-2 pixels where the helper sprite isn't colliding so you don't get nudged, but your main sprite is still colliding with the solid object.

    So the helper sprites should be just 1 pixel away from the sides as to prevent the "nudge event" collision conditions triggering from objects to the side, and the amount nudged should be at least 2 pixels to allow you to clear the corner of the object and continue moving forward. You might want 3, one dead center. If the center one is overlapping, then no nudge.

    Assuming you're using something similar to solids and 8-direction behavior.

  • myvariable is the base speed of the water. As you hold down fire, the base speed at which it is created increases. The expression min() returns the smallest of the two values, in this case either myvariable+50, or 2000. This constrains the maximum of myvariable to 2000. If myvariable is already 2000, myvariable+50=2050. So min(2050,2000) will give you the smaller number, or 2000.

    As a result, as long as the mouse is held down, myvariable will increase 50 every tick until 2000.

  • I understand now, so the events were to set an offset for the sword.

    To do so simply, you can just make a portion of your sword sprite transparent and set the origin a little farther away. Here it is in my example (still just a line though). https://www.dropbox.com/s/m1ogx3npzi13q ... .capx?dl=0

    If you look at the sprite in the image editor, notice that the origin point is in the transparent area and the the collision box is bound to the red "sword".

    But again, the key to making a fantastic animation is to actually animate it (either the player and weapon together, or weapon alone, it is up to you). Having the player and weapon sprites separate has its advantages, such as when you have a lot of weapons and don't want to draw the player for each weapon combination. The weapon itself can be animated on its own too though.

    If you're interested in art and animation, this is one of my favorite videos regarding animation techniques.

    Subscribe to Construct videos now

    And here is a reference for Zelda. https://s-media-cache-ak0.pinimg.com/or ... 1d7372.png

    While the Zelda style is still relatively simple, you can see that the sword swing isn't just a stick, they add swing lines to represent motion. Also, the animation of Link himself adds weight and substance to the sword swing as well. In Zelda, they use a single animation for both the character and weapon, as Link swings that single weapon as his attack 90% of the time.

  • https://www.dropbox.com/s/auxan5t7q3qvg ... .capx?dl=0

    It is more of an intermediate technique. Let me know if you have any specific questions about how it works.

  • You forgot to add on start of layout on you non-disabled grid generation event. Your grid is being created every tick, which immediately covers up your single "dirt" tile you place.

oosyrag's avatar

oosyrag

Member since 20 Feb, 2013

Twitter
oosyrag has 39 followers

Trophy Case

  • 11-Year Club
  • Forum Contributor Made 100 posts in the forums
  • Forum Patron Made 500 posts in the forums
  • Forum Hero Made 1,000 posts in the forums
  • Regular Visitor Visited Construct.net 7 days in a row
  • Steady Visitor Visited Construct.net 30 days in a row
  • Enduring Visitor Visited Construct.net 90 days in a row
  • Unrelenting Visitor Visited Construct.net 180 days in a row
  • Continuous Visitor Visited Construct.net 365 days in a row
  • RTFM Read the fabulous manual
  • Email Verified

Progress

21/44
How to earn trophies