About creating a fighting game in C2

0 favourites
  • 8 posts
From the Asset Store
Fully commented source code/event sheet & sprites to create a space shooter game
  • We know that kind of game is tedious to create and needs lots of per-frame precision in order to avoid

    clunckiness controls or unfair situations, etc...I know the AI will be super challenging but my main concert is frame data,

    animation system in general, collision detection etc...

    There's something like the previously mentioned stuff that prevents you from creating a decent fighting game in Construct 2?

    Is out there any example or template or tutorial worth to have a look at?

    I spent some time looking for examples but everything i found was pretty rough stuff, quick tests in capx files and not so much more than that.

    Thanks for the help in advance guys, learning this great engine atm and doing a lil bit better everyday!

  • There might be one for sale but I don't want to have to pay just to look at a capx.

    But I'm not making a fighting game any time soon so that can wait.

  • Making a fighting game is totally possible using C2... dang- just thinking about it makes me want to make one.

  • It is probably simpler than you think - if you have your sprite animations, you can set image points and/or collision boaxes on each frame individually. Different types of collision boxes can be positioned on these image points per frame. Each animation frame naturally runs one frame per tick, so you already have per frame precision.

  • You can definitely do a fighting game in C2. It takes some work and planning to set up, but it's not all that difficult.

    Small video of my own system in action. It's a scaled-down gif so the quality is kinda cack, but you get the idea:

    Here's a rough breakdown of how it works.

    Setup:

    One player controller (green). Two collision boxes to check for obstacles (yellow and orange). And one collision box for attacks (red).

    The green controller object has the platform behaviour attached and holds all the instance variables for that fighter. The actual sprite is a separate object pinned to it. All the sprite animations are controlled by instance variables fed to it from the controller object. The attack collision box gets enabled at the hit frame of the animation, for instance between frame 3 and 4, and then gets disabled again right after. A separate function to check distance, collision against the opponent sprite, and damage dealing gets called at that point.

    Movement:

    I use the platform behaviour as a base, but rolling your own physics calculations might be a better idea. I just didn't want to deal with any more of that stuff than I had to.

    Fighters can push each other on moving i.e. if player 1 walks into player 2 then player 1's speed is divided by 2 and player 2 gets pushed at the same speed. Except when up against a wall. I use an extra collision box (the yellow and orange ones) behind each player to check for those situations.

    There's some extra event code to deal with jumping scenarios. For instance, should a jumping player land in front of or behind the other player when close? For instance (pseudo-code):

    if (player1.x < player2.x + 50 AND player1.x > player2.x - 50)   // are they close enough to do a check?
            if (player1.y > player2.y - 20)                         // is player1 less than 20 units above player2? If so, restrict X movement
                      if (player2.Bool_CantBePushed == TRUE)        // If there's some obstacle behind player2 player1 X speed always becomes zero
                                  player1.speed = 0;
                      else                                        // move freely
                                  // stop X movement and push player2 away 
                                  if ( player1.x < player2.x AND player1.facing = facingRight )
                                             player2.speed = player2.speed + player1.speed;
                                             player1.speed = 0;
                                  // increase player1 speed if far enough along to jump over
                                  else if ( player1.x >= player2.x AND player1.facing = facingRight )
                                             player1.speed = player1.speed * 1.25;
    
                      etc...                             
    [/code:1vgcq8ek]
    
    That's the broad strokes of it, hope it helps
  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Wow that's really awesome and fluid fighting! Do you mean updating the collision box for that particular frame? I use distance to image points for stuff like that but it would be super cool to have more than one collision box. What do you mean by extra collision box?

  • Thanks

    I mean a separate collision box object for attacking that gets enabled during the animation's hit frame. Here's how it works:

    This happens in the main function every loop - resets the attack collision box (AttackBox) and moves it out of reach:

    On start of an attack this gets called - sets up the collision box size, offset from the fighter's position, damage and so on:

    Called every loop for as long as an attack is in progress - when sprite_animationframe is within hitframe scope I set the collision box position and call another function called Check_Collision:

  • ErekT That is awesome! I'm sure I'll be studying this closely when getting combat to work in my game. Thanks for sharing.

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