next »

[Copywright]

Hey,

I'm in the process of programming a beat-em-up in Unity, and I've got some questions on how to best handle things. Here's a screenshot of what I have at the moment:

http://i.imgur.com/yaFATFI.png

I'm using just 2D Toolkit at the moment. What I do now is to set box colliders in the tk2d collections, and set them as triggers, and use those for collision detection for punching or any other contact, and have a compound capsule collider to collide with the walls (or in this case, the ledges), because the before the character would go through the colliders when he ran.

I am just looking for advice on handling things like :

• Jump

The ground is really just a texture, so how will I handle jumping without having the player fall through the ground. Is there anyway I can add collision detection to the ground, keeping it 2D and able to walk on?

• Collision detection with Walls

As it is, I have to set the collider above the ledge, to make it look like the player has hit a wall. IS there a more efficient way to do this? I really want a better solution, especially so I can have sloped walls.

• Chain combos

I was thing of using Playmaker FSMs (or just normal state machines) for this. But, I think maybe enumeration may be a better approach. Any thoughts?
[/list]

I'd appreciate any advice on what I asked, or any other suggestions on programming sidescrollers and beat-em-ups. Thanks!

[Wilson Saunders]

Quick disclaimer, I have never made a pseudo 3d fighting game in unity before, but I plan on getting around to it one of these days.

First off you need some transformation function to act as a go between your world space and your render space. Essentially any movement you have on the Z axis (closer/further away from the camera) in the game world needs to occur on both the Y and Z axis in the render space. The Z component of this won't be immediately noticeable with ortho projections, until you have multiple objects which can overlap each other. I suggest making this a static class so that all classes can access the same function and you don't have to make changes across a multiple files if it needs a tweaking.

With regard to jumping many of these fighting games use a drop shadow to display where on the X/Z plane the character is. So maintain a separate object that maintains the same X/Z position as the player, but is always Y value 0 (or whatever the Y value of the floor is).

If you use Unity's Character controller properly your wall collision problems should be handled for you.

Chain combos your entire animation control system should be a finite state machine, transitioning between walking, jumping and attacking should be based on state and user input. If you are going to have a combo system I suggest the following animation states:

idle
moving
attack1 strike
attack1 recover
attack2 strike
attack2 recover
attack3 strike
attack3 recover

When the user hits the attack button it starts the attack1 strike animation/state, if the user hits the attack button again during before the end of this animation a flag is set. At the end of the animation if the flag is not set the state goes to attack1 recover and then back to idle. If the attack flag is set the animation state goes to attack2 strike and turns the flag off so that the program can process another attack input action. Rinse and repeat for attack3.

The actual frames for attack2 strike and attack1 recover should use the last frame of attack1 strike as its starting point, same with attack2 recover and attack3 strike.

Good luck and happy programming.

[Wilson Saunders]

I'm using just 2D Toolkit at the moment. What I do now is to set box colliders in the tk2d collections, and set them as triggers, and use those for collision detection for punching or any other contact, and have a compound capsule collider to collide with the walls (or in this case, the ledges), because the before the character would go through the colliders when he ran.

I don't know about the 2d toolkit, but you should look into unity's premade CharacterController class. Use its Move() function instead of changing the game object's transform.position. The Move() function checks for other collides and does not allow the character controller to pass through them. It will however allow the character to press up against the object and even slide along it, if the move vector is partially tangential to the collier.

[R.D.]

There is much more to consider for a good fighting game like active frames, frame traps, canceling, magic-series (combo from light to heavy attacks including specials and so on).

For collision an entity has "hitboxes" and "attacks boxes". Both may be invincible doing some attacks.

An attacks has mostly the following steps:
- start-up
- attacks (consits of active frames and normal frames where the enemy can hit)
- recover

Note that every attack may have a priority. This can be useful for attacks which have the same properties.

You might want to look at Mugen and common beat'em'Ups where you can get frame data from (Ultimate Marvel vs. Capcom, Street Fighter, etc).

[Copywright]

Quick disclaimer, I have never made a pseudo 3d fighting game in unity before, but I plan on getting around to it one of these days.

First off you need some transformation function to act as a go between your world space and your render space. Essentially any movement you have on the Z axis (closer/further away from the camera) in the game world needs to occur on both the Y and Z axis in the render space. The Z component of this won't be immediately noticeable with ortho projections, until you have multiple objects which can overlap each other. I suggest making this a static class so that all classes can access the same function and you don't have to make changes across a multiple files if it needs a tweaking.

I'm a little confused here, why move on the Z axis at all? Z axis is just used for level design purposes, so why exactly would the player moves along the Z axis as well as Y?

I don't know about the 2d toolkit, but you should look into unity's premade CharacterController class. Use its Move() function instead of changing the game object's transform.position. The Move() function checks for other collides and does not allow the character controller to pass through them. It will however allow the character to press up against the object and even slide along it, if the move vector is partially tangential to the collier.

I've looked into the Character Controller, but it basically functioned the same as the capsule collider I'm currently using. What I really want to do is to be able to set the box collider where it's supposed to be on the ledge instead of above it, and allow the player to pass through it, but not completely. A visual representation can be found here:

http://i.imgur.com/SArVZEN.png

Is there something I'm missing about the Character Controller than can do this?

Thanks for the ideas on the drop shadow and animation states .

[Wilson Saunders]

I'm a little confused here, why move on the Z axis at all? Z axis is just used for level design purposes, so why exactly would the player moves along the Z axis as well as Y?

You need to move on the Z axis to get proper overlapping. Right now you just have one character overlapping terrain, but I am assuming you want multiple characters moving about the scene. How will the program know to have the ones closer to the camera overlapping the ones further back? You can't just pre set it because the characters move so if the player character is approaching the baddies from further away the baddies should be rendered on top, but if the player is approaching the baddies from close to the camera, the player should be rendered on top.

I've looked into the Character Controller, but it basically functioned the same as the capsule collider I'm currently using. What I really want to do is to be able to set the box collider where it's supposed to be on the ledge instead of above it, and allow the player to pass through it, but not completely. A visual representation can be found here:

http://i.imgur.com/SArVZEN.png

Is there something I'm missing about the Character Controller than can do this?

Examine the CharacterController Move() function in more detail:
http://docs.unity3d.com/Documentation/ScriptReference/CharacterController.Move.html

As for the screen shot I see what you are trying to do and it won't work because you are trying to fudge a 3d space with 2d math. To make the best use of the the 3d unity functions, you can do one of two things:

1) Tilt the camera down at a 45 degree angle and do all your movement in actual 3d space with your sprites attached to the CharacterController (tilted to face he camera of course).
2) Disconnect your sprites from the CharacterController, still move the character controller in 3d space, but project your sprite into a 2d space using some standard function (what I suggested earlier)

Here is an example in C#:

Code:

public class GlobalFunc{

  const float ratioZY = 0.5f;

  public static Vector3 WorldToScreen(Vector3 worldPos){
    return new Vector3(
        worldPos.x,
        worldPos.y +worldPos.z*ratioZY;
        worldPos.z
    );
  }

}

public Player:MonoBehavior{

  public Vector3 movement;  // derived from player input
  public CharacterController worldMover; // reference to the Character controller
  public GameObject renderPane; // reference to the object that has your character sprite

  Update(){
    worldMover.Move(movement * Time.deltaTime);
    Vector3 temp = GlobalFunc.WorldToScreen(worldMover.transform.position);
    renderPane.transform.position = temp;
  }

}

[rosholger]

I've looked into the Character Controller, but it basically functioned the same as the capsule collider I'm currently using. What I really want to do is to be able to set the box collider where it's supposed to be on the ledge instead of above it, and allow the player to pass through it, but not completely. A visual representation can be found here:

http://i.imgur.com/SArVZEN.png

Is there something I'm missing about the Character Controller than can do this?

Thanks for the ideas on the drop shadow and animation states .

i don't know anything about unity or if this is a good way to do this, but its how i would do it. i would simply have the body "collision box" not collide with the ledge but instead have a small collision box where his feet would be, like this(the black box)

[EdgeOfProphecy]

If it were me, I wouldn't have the top collider at all.  Just get rid of it and set a max Y that the player can walk to.  When they reach it, clamp their position.  Whenever they jump, don't clamp their position.

My preference probably would be to not use colliders at all for the bottom either, but I guess it depends on how linear you want this to be.  If you envision a lot of moving up and down and semi-platforming stuff, then maybe colliders would make things easier.

[CharsAce]

I think you need two main collision types for your character. One collision shape that keeps you in bounds of the map and one that detects hits from enemies. Or something like what I describe. The shadow in games like Streets of Rage always seemed to be the position of the feet of the characters within the play area.

[Copywright]

I think you need two main collision types for your character. One collision shape that keeps you in bounds of the map and one that detects hits from enemies. Or something like what I describe. The shadow in games like Streets of Rage always seemed to be the position of the feet of the characters within the play area.

Done this, I've shrunken the character controller to the player's feet, as rosholger suggested. I've got collider triggers set by tk2d set on the player just for hit detection. I've also made the player move on the Z-depth by setting it to the Vertical axis, and clamped the Z position. That seems to fix the overlapping problem.

[Matthew]

You're asking some pretty broad questions, so I'm not quite sure how best to guide you.  I'm the programmer on Aztez, which is a beat-em-up made with Unity.  Some footage: 

(that's Ben, the artist, talking over the video).

Some random pieces of info.  Feel free to ask any direct questions about how I've set any of this up:

- Everything is 3D, rendering to a normal perspective camera

- Characters are a single RigidBody with a capsule collider.  We don't use CharacterController

- Enemies don't collide with each other, or hit each other.  We use layers and the "Layer Collision Matrix" in physics setup to do this.  Layer-wise, we have:

* Player, Player No Collide, Player Attack, Player Sensor
* Enemy, Enemy No Collide, Enemy Attack, Enemy Sensor

- Player is for the player, which collides with Enemy and Enemy Attack.  "Player No Collide" is a layer that doesn't collide with Enemy.  Some moves set this (ie a dash or a dive roll you want to move through an Enemy).

- Most everything in the game is a "Move", including some non-attacking animations (getting up, etc).  A move is a character animation clip synced with a prefab.  The prefab contains all of the hitboxes, links, etc.  The hitboxes are sometimes animated within Unity.  We animated quite a lot of things in the animation editor (like toggling booleans for when hitboxes are active).

- Unified architecture helps.  It's actually not a small amount of code, which makes it pretty densely packed, but it means I only have to write debug/etc tools once

- Gizmos are your friend for visualizing all of this.

- We use animation events to trigger code-related changes during move animations.  These are super great: http://docs.unity3d.com/Documentation/Components/animeditor-AnimationEvents.html

- The game has a very generic list of "states" for characters.  Really, it's just an array of strings.  Moves can ignore collisions based on states, or require a state to fire in the first place, etc.

- There's a list of moves that are always available to the player.  There are "link" objects as part of a move that will add to the list of possible moves for a short duration.  All combos are handled this way.

- The same input may trigger multiple moves at any given time.  Moves have a priority, which determines which move actually fires.

- Required states are used heavily to manage different moves from the same input.  An opening (always available) move might require the "Airborne" state, and have a higher priority, which means the same button is a simple ground swipe or an air swipe, depending.

Let me know how else I can help!

[gimymblert]

Now that's a great post
What sensor are for?

Edit: the video hasa realllly good feel congrats!
About the ai, enemy takes ticket to attacks or it is a random scheduler?

[Matthew]

Now that's a great post
What sensor are for?

They're actually used to detect the presence of a thing (so Player Sensor only collides with Player).  We specifically use triggers for this.

Moves can require the presence of an opponent is a specific location in order to fire.  For instance, an enemy standing in front of you in the "Dizzy" state will trigger one of the sacrifice moves instead of a normal attack.  I use the sensor layer to check for this.

[Wilson Saunders]

@Matthew
Are you using 3d models or sprites on billboards? If the latter do you orient them vertically or with look at camera?

I have never used the layer collision matrix but it sounds interesting.

[gimymblert]

Okay thanks
And what about the ai?

[Matthew]

@Matthew
Are you using 3d models or sprites on billboards? If the latter do you orient them vertically or with look at camera?

I have never used the layer collision matrix but it sounds interesting.

Everything is a fully-animated 3D model.  Don't have much advice on billboards, sadly!

[Matthew]

Okay thanks
And what about the ai?

Nothing fancy, at the moment, but we're also mid-development.

Aztez has some assumptions:  You're the only "player" avatar in the game, and everyone else is an enemy.  You're the only object everyone cares about (so a lot of this AI is actually you emitting raycasts and things).  With that in mind:

- Enemies maintain a list of their close neighbors

- Right now, characters have "confidence", "bravery", and "presence"

- Confidence goes down heavily when they get hurt, some when their nearby allies get hurt, and back up when the opposite is happening (they're hurting you)

- Bravery is just a number that affects how quickly they return to baseline confidence, presence how much they affect their friends

- You shoot out a big capsulecast in each direction.  Enemies are aware of which # they are in order from you (in the orange sphere):



- They have a target position from you, modulated by their confidence and the order they're in.  If you're fighting a bunch of guys of the same type, they'll stack.  If you scare off the closest guy (or kill him), they'll fill in.  If someone from the rear does a jumping forward attack, the others will make room, etc.

- Target position in that screenshot is the gray box in front of them

- Enemies do dice rolls every so often for a variety of attacks.  Some attacks are frequently attempted by have strict requirements (you in an airborne state, you in a particular relative position i.e. for defensive slashes if you get too close, etc).

- When an attack is attempted, it can have a desired target position relative to you.  Some ranged enemies move into position first, for instance.

[gimymblert]

Oh cool, thanks! 

[Lith]

Hey Copywright! I'm the other half of the Aztez team, and I write compulsively about beat 'em up art and design at www.aztezgame.com and there's years of writings in there. And by all means, feel free to hit me up if you have questions or want to talk shop. I could ramble about beat 'em ups anytime.

[Lith]

And that applies to everyone else, of course.