oosyrag's Forum Posts

  • No need to put yourself down! Everyone has to start somewhere.

    So a normal animation usually runs one animation frame per system frame. So the speed is dependent on your system frame, or fps.

    By using Sprite.AnimationVariable+60*dt, your animation will progress at 60 frames per second regardless of what your system fps is. If your fps is lower than 60, some frames will be skipped. Or you can use 10*dt for 10 frames a second.

    The problem is that you can only set a whole number as an animation frame, like frame 1, 2, or 3. You cannot have a frame 3.248. The dt expression will start giving you fractional numbers. So to get past this we use either floor(), which means round down, and ceil() (ceiling), which rounds up. Floor(3.5) = 3, ceil(3.5) = 4.

    This gives us a new problem though - if I just use the animation frame and add to it, it might keep rounding down, preventing the animation from progressing! For example, I'm on frame 2, and dt adds .9 on tick. This 2.9 gets rounded down to 2. Next tick, I add .7 - this 2.7 also gets rounded down to 2.

    This is why we need a separate variable to keep track of our progress. As in the previous example, If I stored the 2.9 in a variable, this tick would show animation frame 2, then next tick I add .7 to 2.9 resulting in 3.6, this would show frame 3.

    Looping -

    Sprite.AnimationFrameCount gives you how many frames an animation is, lets say 13. Normally, it would progress from 0, 1, 2, and so on until 13. Then instead of 14, which doesn't exist, it would go back to 0. Now we have the same problem as above when using dt - we get decimals instead of whole numbers. If we progress from 13.7 to 14.5, we want to carry over that .5 when we go back to the beginning. You can do this with modulo. 14.5%14=0.5

    So basically the loop event I described as above goes like this:

    If my current AnimationVariable (14.5) is greater than AnimationFrameCount+1 (14. I didn't have +1 above but should have since we're rounding down), set AnimationVariable to 0 + whatever is leftover after 14 (14.5%14=0.5). Then of course we would need to round down to set the actual animation frame which is 0. But the next tick would continue adding from 0.5.

    This is a bit past beginner territory, so don't be discouraged if you don't get it. Good luck with your project!

  • On Bullet Hit

    Create particle at Bullet.X, Bullet.Y

    Set Particle angle to Bullet.Angle

    Move Forward Particle Offset Amount.

    Destroy Bullet

    Might have to play with a little trig math to get a really accurate offset amount, but you might not need that.

  • The built in animation is by frame, so each frame rendered will progress the animation by one frame.

    You want to set the animation speed to 0, and use events to progress the animation.

    Every tick - Set Sprite.AnimationVariable to Sprite.AnimationVariable+60*dt

    Every tick - Set Sprite.AnimationFrame to floor(Sprite.AnimationVariable)

    This assumes you want it to run at 60 animation frames per second. You need a variable and Floor is to round down to the nearest whole number. You can use ceil() to round up instead.

    To Loop

    If Sprite.AnimationVariable > Sprite.AnimationFrameCount - Set Sprite.AnimationVariable to floor(0+Sprite.AnimationVariable%Sprite.AnimationFrameCount)

    Use modulo (%) - this will give you the remainder of a division. In this case, its how much you overshot total frames by.

    Depending on how fast you want the animation to play, you might have skipped animation frames if the target device is running at a very low fps. Could be desired though!.

  • One simple method would be to have your object made up of several pinned sprites, and each one can be destroyed/damaged on its own.

  • I'm gonna say a build-your-own flexible combo system would be pretty awesome - like the original Xenogears or Majika.

    One of the most memorable mechanics for me in Secret of Mana was when you maxed out your magic, it would get a whole new set of animations. Also how each weapon was pretty unique and had their own sets of special moves.

  • Great!

    Just an additional quick tip - you can add additional image points to a sprite besides just the origin point, and get those point positions via expressions for all sorts of uses. You can have different points/locations on different animation frames too.

  • Is this the place for C3 requests? Just wanted to put in my two cents: built in vector graphics support would be great. I know there are some plugins already, but it was one of the most obvious things missing for someone who for example worked with flash before: SVG file support, canvas/drawing support, tweening.

  • Simple solution! Sorry I don't use behaviors much so wasn't familiar with the quirks.

  • It is possible, but quite a bit of a roundabout method. Any particular reason you need to use XML?

    Here is a rough idea of the steps:

    Import your XML file as a project file. https://www.scirra.com/manual/141/files

    Load the XML file into memory with AJAX.request. https://www.scirra.com/manual/107/ajax

    Access the data with AJAX.lastdata.

    Use tokenat() to parse the information you need from your XML file. https://www.scirra.com/manual/126/system-expressions

    Use the information you got to set the Sprite Animation, or to destroy and replace with another Sprite.

  • Here you go, see if this helps

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

    Use arrow keys to move, pin is automatic when you run over the black dot, and press E to drop it.

  • I think it is the wait that is stopping the event from updating the direction of the bullet. Try having the wait and stop in another event, maybe if Bullet is Moving - Wait 1, Stop Bullet by itself.

  • When you disabled wait did you also disable the bullet disable action too?

    Try setting a static speed and see what happens?

  • When working with invisible/instant bullets, I highly suggest avoiding actually using the bullet behavior on a sprite for any sort of hit calculation. Basically with speed 5000, for example, your sprite jumps 5000 pixels every frame - it doesn't actually travel through those pixels. So if your collision object is somewhere in the middle there, the two sprites never touch each other, so there is no collision. It's fine for just visuals though, for example your tracer lines.

    For your hitbox mechanics, you'll need some work in some custom code, since as you mentioned there are no built in behaviors for instant hit projectiles in C2 (also remember all behaviors are just shortcuts, they can all be recreated with the event system).

    You can try using a line of sight style calculation. The condition to check for is if the target is within angle of your shot, which you can base on either the current angle of the player sprite or the angle from the player sprite to your mouse, depending on what your controls are like. When you fire, if your target is within this angle, then hit! From there, you can add sub-events to have % chance to crit, or % chance to hit even when the shot is on target. Then create the visual based on what actually happened. Also, you can use the Line of Sight behavior to make sure there isn't an obstacle between player and target.

    Some angle expressions you might find useful when working on this -

    angle(targetSprite.x, targetSprite.y, playerSprite.x, playerSprite.y) - The angle between player and target.

    angle(mouse.x, mouse,y, playerSprite.x, playerSprite.y) - The angle between player and mouse.

    playerSprite.angle - The angle the player is currently facing.

    random(100) - A random number between but not including 0 and 100

    cel(random(100)) - A random WHOLE number between and including 1 and 100

    I'm working on something similar so let me know if you want a .capx example. I find there's a lot of satisfaction in figuring it out for yourself though!

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Make sure your pin behavior is on the item, not the player. A simple system would be to pin the item to the player when you pick it up, and unpin when you want to drop it.

  • I assume your coins and life are already variables.

    Condition

    System - Compare two values: CoinsVariable = 100

    Action

    Add 1 to LifeVariable

    Set CoinsVariable to 0