Salvos for the turret behaviour

This forum is currently in read-only mode.
0 favourites
From the Asset Store
10 turrets rendered in 3D with top down and menu views. Three upgrade levels per tower.
  • Just a small suggestion.

    I'm sure this can be done using events, but it would be great if the turret behaviour could fire in salvos, i.e. three quick shots, then reload. This is quite a common behaviour in games with turrets.

    I implemented something like this in a game maker game, but it required several variables and nested if statements to make it work properly.

    It could be implemented using two variables - salvoSize and salvoInterval (or similar). These could work in tandem with the other variables and properties of the turret. So if the onShoot event fires, the turret would automatically shoot {salvoSize} bullets with {salvoInterval} milliseconds between them, then wait for it's standard reload time before firing again.

    Any thoughts?

  • Its already set to do this easily.

    You can add additional image points to your sprite, then on the on shoot event trigger the projectiles you can use time.delta for each create bullet at image point.

    1 event 3 actions, you could probably use a loop or even a for each in there.

  • I see. I didn't realise image points could be used in that way.

    I'll give this a go next chance I get.

    I assume the same techniques could be used to create spray and other bullet arrangements?

    Thanks.

  • Image points are unlimited as far as I know.

    You can do single, double, triple, etc, even a machine gun, or shot gun effect.

    Your limited more by hardware more that software here.

    One quick hint, the collision event "object collides with object" is a little bugged atm, so use "object is overlapping".

  • Ah so instead of just having a single shot, the turrets have ammo...so there'd be like a 'between shots' time and a 'reload time' and 'ammo'?

  • Not sure about the "between shots", but lowering the reload time gives the rapid fire.

    Then if you want a set amount of ammo, you could easily add a private variable to the object, then just subtract it on the on shoot event.

    I suppose on the "between shots" if you mean like separate sprays of fire, you could add:

    On sprite shoot

    Every x ticks

    sprite create object

  • This is the code I used in to make this work in GameMaker, after hacking away at it for an entire night:

    if(firing==true) {
        if(shots>0) {
            if(reload==5){
                s=instance_create(x, y, obj_enemyShot);
                s.direction=direction;
                s.speed=4;
                shots-=1;
                reload=0;
                if (shots==0) alarm[0]=30;
            }
        } else {
            firing=false
        }
    }
    if(reload<5) reload+=1;[/code:3kwc4jy7]
    
    Prior to this is code that makes it rotate and decide whether or not to fire (firing=true). This code is executed every step, using GM's fixed time step (30fps).  So, first check if the cannon is firing, then if it has ammo (shots > 0). Then check if the cannon is loaded (reload==5), and if so, fire a bullet in the direction the cannon is facing, reduce the shots available and start the reload cycle. When you run out of shots, start the timer (alarm[0]) to do a full reload. The alarm event has code to set shots back to 3.
    
    Horrible code, I know. But the end result was a really nice turret that tracked the player and fired off a salvo of 3 bullets, 1/6seconds apart, with a 1 second gap between salvoes. Much nicer that an endless stream of bullets. This is the sort of thing I was trying to describe.
    
    As I said, I'm sure something like this could be done using events. It's a question of whether it is significant enough to warrant adding to the behaviour. It doesn't look like it would be used enough to make adding it worthwhile. Case closed.
  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • It's not so difficult to make in Construct as it is in GM

    http://willhostforfood.com/files3/7051053/salvo.cap

    Just four events, makes use of the Function object and "Call function after delay."

    The turret behavior doesn't fire constantly though, which you would expect if they're firing in salvos. If the target moves beyond the angle at which the turret "Has target" then the turret won't fire. Seems to me that the Turret could benefit from some new features (no need to give Platform all the new features, guys ). Something like:

    Ammunition [Amount]

    Fire Rate [In milliseconds]

    Constant Fire [Checkbox] (if target is within the Range limit)

    Then "Reload time" would kick in after Ammunition is depleted. That way you could have separate fire rates and reload times, which is the sort of thing you need for something like this. But then again maybe it's not all that necessary, considering it can be done in a few events.

  • My first turret in GM worked like yours - only firing when the player was in it's field of fire, so it would sometimes only fire two shots, then fire the last one the next time the player came in range.

    The code above was a fix for that problem. By using the 'firing' variable, and toggling the variable when the shots were depleted, I ensured that the entire salvo was fired in one continuous burst. This gave me the more realistic anti-aircraft style firing. When you attach a sound to that action the effect is really nice: boo-boo-boom!

    I'm now positive that such behaviour could be done using events, but is it the sort of thing that would be better implemented in the behaviour?

  • is it the sort of thing that would be better implemented in the behaviour?

    Tough to say. Ultimately, it's down to the developer's judgments on that, and they don't always make their intentions known . It seems to me that adding Ammunition, Fire Rate, and Constant Fire would be useful, though.

  • I could understand a setting for burst of fire, or what ever you want to call it, but I dont think an ammunition setting would be all that great.

    Sure it might be cool for some situations, but what about if the user wants to get more ammunition?

    Besides wouldn't that be better under the bullet behavior?

    Ok not really, as it stands there's a setting under the bullet behavior for speed of the bullet, and personally I think it would be better under the turrets behavior, unless you want to add a different bullet for each turret. Then again you can change just about all of the individual behavior settings during runtime.

  • If the new features were implemented you could make the new turrets act just like the old turrets by setting your Fire Rate to what the Reload is currently, setting the Reload speed to 0, and setting the Ammo to 1. It would behave exactly the same way then.

    Also, I think it's more logical to have your turret store an Ammo amount, rather than the bullet itself... after all, a bullet is just one unit of ammo. As for getting more ammunition, how about a "Reload" action?

    Also, a suggestion (if these features are considered): Setting Ammunition to 0 would mean "infinite." Oh, and what I meant earlier by "Constant fire" is that it should always fire when the target is within range, not just when the angle is appropriate. Unless there's already some method to do this, and I'm missing it.

  • Well first off the on shoot trigger would have to be directly related to ammunition, so every turret that used it would be subtracting something every time its triggered.

    Ok thats great we got that part... blah, blah, blah, but what exactly are they shooting?

    That kind of limits the trigger to the object being created.

    Suppose I wanted to have an additional condition like:

    On tank shoot

    helicoptersprite is in range

    create object misslesprite

    Then if your going to have a rate of fire, wont that variable have be tied to the amount of ammunition?

    So now I would be stuck firing x amount of bullets, as well as missles etc.

    Would it not be just as simple to create a private variable, for something that would be somewhat obscure?

  • Okay then, I take it all back. It's a terrible idea.

  • can't you just make this easily with variables?

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)