Input ''combo'' buttons?

1 favourites
  • 8 posts
From the Asset Store
Combo
$10 USD
Button Combinations like in fightings, supports both keyboard and gamepads
  • Hey there! ^_^

    So you know the fighting games where u input 'down down, forward and X' to perform a special ability?

    Is that possible in C2? And how to do it?

  • Hello, I'll tell you straight away I'm not very experienced in Construct 2 yet, & I haven't helped someone on the forum before, but your question caught my eye. I want to make a fighting game sometime, you see. I set to work making an extremely simple mockup of how to do a "Hadouken" compared to a normal punch using direction inputs.

    I'll post the capx if you want (once I learn how to do that), but here's the explanation:

    Have your character object (Ryu). Give him an instance variable (I called it RyuCommand). I also had 2 Bullet objects from the "Ghost Shooter" tutorial on Scirra. I gave them both "Bullet" movement behavior, but I made one slow (bullet), & the other fast (Hadouken). I made it to where you have to quickly press S & then D & then P to spawn the Hadouken, & just press P to spawn the slow bullet.

    Events:

    On P Pressed -> spawn Bullet

    On S Pressed -> add 1 to RyuCommand

    On D Pressed AND RyuCommand = 1 -> add 1 to RyuCommand

    On P Pressed AND RyuCommand = 2 -> spawn Hadouken

    Hadouken on created -> set RyuCommand to 0

    So that means that if you press P, he'll spawn a bullet (or punch, if you make him punch). But if you pressed S then D, he'll spawn Hadouken. Plus, once the Hadouken is spawned, the variable goes back to 0.

    BUT I don't know how to reset the variable after a certain amount of time has passed; like if you want the player to have to press down>forward within 30 frames or something. The best I know how to do right now is:

    RyuCommand greater than 0 AND Every x seconds -> set RyuCommand to 0

    Of course the timing doesn't work very well on that, but it's what I know for now. Hope this gives you an idea.

  • Haha, I learned how to fix the timing.

    RyuCommand > 0 -> Wait 1.5 seconds -> set RyuCommand to 0

    I just learned about the System's Wait action, very handy.

    Again, I'm not experienced so this may be a bad way to do it. And of course you wouldn't be able to make a big roster of fighters using events like this when you're limited to 100 events. But hopefully you can work with this.

    EDIT: Just noticed that Hadouken still spawns a slow bullet too, because the condition for bullet is "On P pressed". So I also added the condition "RyuCommand smaller or equal to 1".

  • Haha, I learned how to fix the timing.

    RyuCommand > 0 -> Wait 1.5 seconds -> set RyuCommand to 0

    I just learned about the System's Wait action, very handy.

    Again, I'm not experienced so this may be a bad way to do it. And of course you wouldn't be able to make a big roster of fighters using events like this when you're limited to 100 events. But hopefully you can work with this.

    EDIT: Just noticed that Hadouken still spawns a slow bullet too, because the condition for bullet is "On P pressed". So I also added the condition "RyuCommand smaller or equal to 1".

    I see, thanks for the response ^_^

  • If anyone has a thought on how to do this better, feel free to pitch in. I want to learn more too. XD

    BTW I also turned those events into a group, & made RyuCommand a local variable called RyuHadouken. I also implemented "Shoryuken" (which was just a bullet shooting upwards) & made that its own group with its own local variable. Might be a better way to handle that, because then every special/command input is its own group, might make things cleaner. Or if you want, you could make it a global or instanced variable, & just add events for corresponding controls for whatever moves you want. So if you have a move that requires "Forward-Down-Punch" it could use the same variable as "Forward-Down-Back-Punch". Might save on total number of events.

    OR maybe there's a better way other than variables. Got more learning to do.

  • I've made a complicated input system before.

    The basic idea, at least behind how I did it, is that you record inputs (e.g. in a queue) and every X seconds, read those inputs and have an action occur because of it.

    The input window should probably be around .10-.15, if it's too small then what happens is, let's say you need to press A and B at the same time, or Down on a control stick and the X button at the same time, if they aren't on the EXACT same frame and you just do a check, it won't work.

    If you do stuff like wait commands, it can get a bit messy when people press multiple buttons at once, among other scenarios... maybe it can work but I don't think I even tried, I couldn't really imagine how it would.

    For reading inputs, you probably need to differentiate between directions and buttons. So you don't just want to say "what was the last button pressed", but more like, "what were the last 3/4 directional inputs, and the last 2/3 button inputs, and in what order".

    That way you can see, okay, they did down, down-right, and right, in that order, this is a quarter-circle forward, and then they pressed B and A, well A was the last input so we take that one. Or maybe you want them to press two buttons at once, so you can read that, or maybe you only take their first input. There are lots of different possibilities.

    Rather than a wait command, I would start a Timer whenever an input is received (again, for maybe .10 seconds, it means there is a small delay on the inputs but it's almost unnoticeable and even professional games can have small delays like these), and then once the timer is done, you read the inputs.

    Another thing is that, instead of doing:

    "on press A, do this"

    "on press left and A, do this"

    "on press right and A, do this"

    "on press B, do this"

    "on press left and B, do this"

    "on press right and B, do this"

    you now have

    "on press A, record A"

    "on press B, record B"

    "on press left, record left"

    "on press right, record right"

    Read/execute input one time.

    You see how I reduced 6 checks (redundant left/right input checks) to just 4? And the more you have the more the reductions add up. Then you only need to check for each button input once, and you just have an I/O-like system to do things based on the inputs.

    Coding it can be a bit difficult but it's part of game development/programming in general (C2 might not be script-based but programming knowledge is still extremely useful, if not basically required IMO, at least for more complicated things), action/fighting games can be especially hard in this sense, so yeah. Good luck if you choose to try it.

  • I've made a complicated input system before.

    The basic idea, at least behind how I did it, is that you record inputs (e.g. in a queue) and every X seconds, read those inputs and have an action occur because of it.

    The input window should probably be around .10-.15, if it's too small then what happens is, let's say you need to press A and B at the same time, or Down on a control stick and the X button at the same time, if they aren't on the EXACT same frame and you just do a check, it won't work.

    If you do stuff like wait commands, it can get a bit messy when people press multiple buttons at once, among other scenarios... maybe it can work but I don't think I even tried, I couldn't really imagine how it would.

    For reading inputs, you probably need to differentiate between directions and buttons. So you don't just want to say "what was the last button pressed", but more like, "what were the last 3/4 directional inputs, and the last 2/3 button inputs, and in what order".

    That way you can see, okay, they did down, down-right, and right, in that order, this is a quarter-circle forward, and then they pressed B and A, well A was the last input so we take that one. Or maybe you want them to press two buttons at once, so you can read that, or maybe you only take their first input. There are lots of different possibilities.

    Rather than a wait command, I would start a Timer whenever an input is received (again, for maybe .10 seconds, it means there is a small delay on the inputs but it's almost unnoticeable and even professional games can have small delays like these), and then once the timer is done, you read the inputs.

    Another thing is that, instead of doing:

    "on press A, do this"

    "on press left and A, do this"

    "on press right and A, do this"

    "on press B, do this"

    "on press left and B, do this"

    "on press right and B, do this"

    you now have

    "on press A, record A"

    "on press B, record B"

    "on press left, record left"

    "on press right, record right"

    Read/execute input one time.

    You see how I reduced 6 checks (redundant left/right input checks) to just 4? And the more you have the more the reductions add up. Then you only need to check for each button input once, and you just have an I/O-like system to do things based on the inputs.

    Coding it can be a bit difficult but it's part of game development/programming in general (C2 might not be script-based but programming knowledge is still extremely useful, if not basically required IMO, at least for more complicated things), action/fighting games can be especially hard in this sense, so yeah. Good luck if you choose to try it.

    So this will be harder than what we had thought xD

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • > I've made a complicated input system before.

    >

    > The basic idea, at least behind how I did it, is that you record inputs (e.g. in a queue) and every X seconds, read those inputs and have an action occur because of it.

    >

    > The input window should probably be around .10-.15, if it's too small then what happens is, let's say you need to press A and B at the same time, or Down on a control stick and the X button at the same time, if they aren't on the EXACT same frame and you just do a check, it won't work.

    >

    > If you do stuff like wait commands, it can get a bit messy when people press multiple buttons at once, among other scenarios... maybe it can work but I don't think I even tried, I couldn't really imagine how it would.

    >

    > For reading inputs, you probably need to differentiate between directions and buttons. So you don't just want to say "what was the last button pressed", but more like, "what were the last 3/4 directional inputs, and the last 2/3 button inputs, and in what order".

    >

    > That way you can see, okay, they did down, down-right, and right, in that order, this is a quarter-circle forward, and then they pressed B and A, well A was the last input so we take that one. Or maybe you want them to press two buttons at once, so you can read that, or maybe you only take their first input. There are lots of different possibilities.

    >

    > Rather than a wait command, I would start a Timer whenever an input is received (again, for maybe .10 seconds, it means there is a small delay on the inputs but it's almost unnoticeable and even professional games can have small delays like these), and then once the timer is done, you read the inputs.

    >

    > Another thing is that, instead of doing:

    >

    > "on press A, do this"

    > "on press left and A, do this"

    > "on press right and A, do this"

    > "on press B, do this"

    > "on press left and B, do this"

    > "on press right and B, do this"

    >

    > you now have

    >

    > "on press A, record A"

    > "on press B, record B"

    > "on press left, record left"

    > "on press right, record right"

    >

    > Read/execute input one time.

    >

    > You see how I reduced 6 checks (redundant left/right input checks) to just 4? And the more you have the more the reductions add up. Then you only need to check for each button input once, and you just have an I/O-like system to do things based on the inputs.

    >

    > Coding it can be a bit difficult but it's part of game development/programming in general (C2 might not be script-based but programming knowledge is still extremely useful, if not basically required IMO, at least for more complicated things), action/fighting games can be especially hard in this sense, so yeah. Good luck if you choose to try it.

    >

    So this will be harder than what we had thought xD

    Maybe, but if you design it on paper and then implement it bit by bit, it's actually not too bad. Start with doing it for one button, maybe, and then go from there.

    Like basically anything in game design though, it'll take some time to get fully polished, yeah.

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