■ Description
Kinematic 2D is a fully Kinematic (non-physics based) 2D Character controller solution that allows you to do the movement of your 2D character while handling collisions.
■ Main Characteristics
It offers the functionalities the default Unity Character Controller offers and many more (steps and slopes handling, ground alignment, ground clamping, etc).
It was designed only for two dimensional movement (2D).
The collision detection method works with 2D and 3D colliders.
The character body shape is a box (instead of a capsule, this is great for platformers).
Designed with Unity’s rigidbody interpolation in mind, you can choose between three availables types of motion modes: “Transform”, “Rigidbody Non-Interpolated” and “Rigidbody Interpolated”.
Really good performance, (tested in desktop with 500 2D interpolated moving characters, resulting in >300 fps without Vsync).
■ Games
This asset was initially designed for 2D platform games (platformers) in general, although you can use it in some clever way and make it work the way you want (like for example a top-down 2D game).
■ Main Content - The Core: The main part of the package, it does the heavy lifting regarding collision detection and movement in general. - The Implementation: Consist of a bunch of components that implement the functionality of “the core” (Input, movement handling, animation, AI). This part of the package acts as an example implementation of the Core, although it’s super handy and useful. It include a character state machine, some useful abilities, and more. - Extras: A bunch of scripts with some useful functionality (Platform controller, 2D Camera, etc). - Walkthrough: 27 dedicated scenes included with the aim of introduce the main features of the package (Core and Implementation).
■ Collision Detection
The main difference with others character controllers out there is that Kinematic2D uses a combination of Boxcast and Raycast methods to detect collisions, this means not only fine precision but performance. The Boxcast solution is great for complicated shapes and it is very efficient.
■ Requirements
Even if everything works just fine from the get go It’s recommended to have at least some basic C# programming skills (intermediate level recommended) to take full advantage of the asset, for example to extend the character controller, add new states or new abilities, customize the animation system, create the AI, etc.
■ Main Features Core:
Completely Kinematic.
Box-based collision detection.
Raycast and Boxcast collision detection methods integrated.
No GC Allocations.
It supports 2D and 3D collisions.
It supports rigidbody interpolation movement.
Can handle steps.
Can handle slopes.
Can depenetrate from moving/rotating colliders.
The character will never go through walls.
It supports moving and rotating platforms.
Ground clamping.
Orientation friendly (this means that you can move your character perfectly in any orientation, good for gravity shifting scenarios).
Ground alignment.
Vertical alignment modes (this allows you to set the vertical axis of your character, independet from the ground alignment).
Independence between Collision Shape and Character Graphics.
Facing direction modes, “Rotation” and “Negative local scale” with individual Yaw and Roll parameters.
Fully commented C# Source Code.
Tooltips available.
Implementation:
Chraracter controller implemented as a state machine with separated abilities.
External movement data (scriptable objects) allowing pluggable movement behaviours.
Create Movement Areas (also called “environments”), such as water, ice, honey, etc (this affects the horizontal and vertical movement parameters separately).
Configurable horizontal movement.
Configurable vertical movement.
Precise Jump.(as many as you want)
Cancel jump with the release of a button.
Air control.
Crouch
Precise Dash.(as many as you want)
Input based Dash (inspired by the game “Celeste”).
Wall slide.
Input based Wall Jump.
Wall and Corner alignment.
Action-based movement, not input based ( useful when integrating the AI).
AI behaviours, customizable via scriptable objects.
Create your custom abilities by right clicking on the Project View.
Override the animation actions with your custom solution.
Override the input methods.
Extras:
Characters: Boxy2D , Boxy3D and Roboto (animated).
Moving/Rotating Platform Controller.
2D Camera.
FPS Counter.
etc.
VIDEOS
Final Note Please, if you have any questions feel free to send me an email and ask me anything, i’m open to answer to your questions about what this asset can or can not do.
However how easy it is to extend this package to include more features?
Like you have mentioned above that you can use it to build games like Hollow Knight or Celeste , but as you know these 2 games have more player features like in Celeste you have Dash in 8 directions and in Hollow Knight you can melee attack in 3 direction (front, up and down), also Super Meat Boy you have an Air controller where you can change the jump direction while you are in the air… etc.
So how easy it is to extend this package and build such a features?
Hi, thanks! The main goal of the asset is to offer just a “Move method”, if you are familiar with the Unity default character controller component you know what i’m talking about, if not, is just a method that puts the character in X position, while handing collisions, simple as that.
So, if you want to do a three direction air attack (like in Hollow Knight, the attack behaviour is completely independent of the movement behaviour), swimming ability, the new climbing feature that will define your game, or whatever custom feature you are thinking of you will have to manage the velocity vector of the character yourself,. The character motor is already defined, based on grounded/air behaviours that I have imposed (All suggestion are welcome of course).
The rest of the package is based on my custom implementation. Of course this is the part is when the usual customer is interested, add this ability, add that new feature, etc.
Again, with the Hollow knight 3 dir air attack example, you could force the velocity vector to zero when an attack action is performed.
It is coming a little doc about the implementation, in order to explain things better, maybe with a couple of examples/tutorials.
Thanks for the answer, I have been playing with multiple 2D platform packages from the asset store but always the biggest challenge is how easy it is to extend it, all the packages owners claim that their packages is easy to understand and extend but once you start trying to extend, will not take long time to know that this is not true and you will start facing a lot of complexity issues that will make you surrender and search for something easier.
So a couple of questions:
1- How easy it is to understand and extend (because if you did not understand you will not be able to extend)?
2- Does the package support colliding with any 2D collision? like for example tilemaps and such?
Hi Luis, the moving/rotating platform feature is quite straightforward, every time the character is grounded it store the ground information. Every Update/LateUpdate/FixedUpdate (whatever method you choose) the character will update this information and based on the position/rotation change and will perform the action needed. The only caution the user must have is to put the “platform” execution order before the Character execution order. With the LateUpdate is really easy, put the platform in updates, the character in LateUpdate. Another approach is to simple make a “system”, this system will perform all the movement for the characters/platforms for you, a nice alternative.
Let me ask you, Are you Luis Pedro Fonseca from the Reddit post? if so, thanks for the suggestion on the rotating platform, because of that i’ve implemented it.
Exactly, that’s why i keep saying that this is not “an engine”, I tried to limit myself to the “Move method”, but also include my little implementation, nothing fancy, just as an example. In previous versions (not released) i had a proper state machine, you could add abilities and states to the character, but that wasn’t the initial goal, so i removed it … who knows, maybe i could include this feature as a “new implementation”, that would be cool.
1 - It depends, the starting guide that i included explain how the character moves, maybe it’s not 100% clear, but at least it’s 85% clear (i’m working on that), although the interface between you and the whole asset is just the Move method, you should not modify the character motor, character physics, etc.
2 - Yes It does, with any type of collider, box, circle, composite, etc. Also 3D colliders.
In my case I’d like to “attach” to a moving platform, but the character wouldn’t be grounded. Imagine the player is on a sticky wall that moves. Would that be possible?
Also, do you expose the current character collision information? I’d need to know if the player is colliding on top/bottom, left/right.
P.S.: Yes, I commented on your Reddit post a while back. Glad to see you implemented my suggestion!
The answer is “mostly yes”, currently there is an internal struct like this:
/// <summary>
/// Container of information regarding the collision process.
/// </summary>
public struct CollisionInfo
{
// Ground Info
public GameObject m_groundObject;
public int m_groundLayer;
public Vector3 m_groundNormal;
public Vector3 m_groundContactPoint;
// Collision flags
public bool m_bottom;
public bool m_top;
public bool m_left;
public bool m_right;
// Slope hitInfo
public float m_slopeSignedAngle;
public float m_slopeAngle;
public float m_slopeAngleSign;
public bool m_onStableGround;
// Slope hitInfo
public float m_wallSignedAngle;
public float m_wallAngle;
public float m_wallAngleSign;
//Movement
public Vector3 m_groundMovementDirection;
…
}
there are properties related with the current state, for example:
public bool isGrounded
{
get
{
return m_info.m_bottom;
}
}
public bool isAgainstLeftWall
{
get
{
return m_info.m_left;
}
}
public bool isAgainstRightWall
{
get
{
return m_info.m_right;
}
}
All of these properties are related with the top,bottom, left, right and slopes, they have nice names (isGrounded ↔ bottom = true). The “mostly yes” is because initially i used this values only for internal purposes, but recently some people had sent me about this request. In 1.2.2 i will expose everything at 100%, probably right now is “Ok”, but in the next release i will do things right with an online API reference, once and for all!
Short answer: Possible? yes, but not by click two buttons, i mean, there isn’t a method like “stick to the walls”, at least not internally in the characterMotor, but, you can do it on your own implementation (i know is not a nice and promising answer). In the description of the package, by “you can use it in some clever way and make it work the way you want” i meant this type of situations. This is an interesting feature, i could implement this behaviour, trigger the moving platform stuff not only with the grounded state but with the left/right state… I will consider it.
Sorry i missed your previous question about the “grab”, i guess it is related to this matter.
I’m now trying to follow your starter guide I reach the topic(CREATING A BASIC CHARACTER) , however I’m not able to find the character you are using in the documentation the only thing I found is drawing1.png in the folder (Kinematic2D\Demo\Characters\Roboto\Sprites) but the problem with that sprite is that it’s scattered and not ready like the one you present on the document !
So it will be good practice to include the asset in the tutorial in your package so it will be easy to follow.
I just finish reading the starter guide, and I’m sorry to say it’s far away from being 40% complete (you mentioned to me that it’s 85% complete), and here is why I’m saying that:
1- The document show a rough example of how to setup a character but the example does not explain for example when and why to add a rigidbody2d (this component is there in all the prefab examples).
2- The 2D playercontroller you have no mentioned anything about it and not explain any of it’s parameters.
3- regarding the section 5.1 “move method” and section 5.2 “GROUNDED VS AIR MOVEMENT” the explanation is so much abstract explanation, you will need to give at least an example how to implement the things that you are writing about.
4- The features what you called implementation features these are not explained at all.
Hope you will used these points as advise to improve your getting started guide, and let me suggest something here, try to make video recording (host in youtube) to explain things, that will save you a lot of time on writing, and for us always seeing examples is better that reading too much pages.
Now see for me I want to understand your code (because if I did not understand it I will never be able to extend and add my own features), so where should I start reading? and in what order?
Like you have 3 folders that look important:
1- Character Implementation: this one include 2 folders one is “Scripts” and second is “Scriptable objects” and inside the second one there are two folders "AI behavior " and “Player input” What are these?
2- Core: This one include many scripts.
3- In the Demo folder there is a script folder as well that include many scripts.
So Where should I start read to learn the underlying structure of this component? and in what order?
Appreciate you support to get the required benefit of the package.
it’s funny, because yesterday i was looking to put into the scene this character and i couldn’t find it. The character “Roboto” was in 1.0, he was a test character, for 1.2.0 i put a new character “Boxy”, it’s like the default, for the keyImages and everything, for 1.2.2 (i’m going to update tomorrow) i’m putting back Roboto, (a Prefab of the character), i really don’t know why I have removed it.
The guide has the following purposes:
1 - Explain the character motor parameters (i am aware that are some missing, i am working on that)
2 - Make clear one thing: “use only the move method”, that’s your entry point.
3 - Explain the basics of the boxshape (air vs grounded).
4 - Explain the two components of the input vector.
Remember that the “extend the character controller” part in the description is inside the section **“**Requierements” as a suggestion based on the C# knowledge: “It’s recommended to have at least some basic C# programming skills (intermediate level recommended) to take full advantage of the asset, for example to extend the character controller, add new states or new abilities, customize the animation system, create the AI, etc.”
By “full advantage” i meant that if you know some basic/intermediate C# you could go inside the Character Controller and adapt it to your liking, maybe create a new one based on this structure, or whatever (a not being attach only to the “Move” part). Look that “extend the character controller” is not part of the “features” part.
Because that’s an implementation that i came up, it was never intended to be an “official” package. But (as i poorly predicted) people is interested in this part more than the collision part, so i receive a lot of “can yo do this?” “can yo do that?” and i’m started to put more effort in this Character Controller (from >1.2.2), this “effort” include a better guide/tutorials/doc.
Think of this part like a helper, a “what you can do” with the character motor (and the rest). As I said in previous post (i think, sorry if i’m wrong, too many mails), i will in include a guide exclusively to this implementation.
Anyway, almost every parameter has a “Tooltip”.
It isn’t so abstract to me, maybe i’m wrong, here is what i said in the doc:
" The Move method is the main interface between any script and the CharacterMotor, and it would be your only entry point. It takes a Vector2 variable as an input argument and a “deltaTime” float (could be a frame deltaTime or a fixed deltaTime). The input vector corresponds to an increment/decrement of local position, or “deltaPosition”."
For the starting guide purpose this is the thing you should know about moving the character (the method at least), works the same that the default Unity character controller component. For the behaviour of the character on slopes see the parameters section.
I agree with the implementation part, that’s why the “85%” i mentioned, that section act as a simple explanation of the two components of the input vector and the effective box shape of the character while moving in the air/grounded, with that in mind you have an overall idea how the character shape will collide with the world, that’s really “the meat”, for a character design you don’t need to know more than that (this + the tooltips should he enough).
Again, i agree, this section need a mini example and is being currently modified.
Ah, maybe i missed this part! i admit it, that’s on me, thanks for point that out!. Just to be clear, if you are moving your character via Rigidbody.Move o Rigidbody.position you need a Rigidbody (2D / 3D).
Explained how? I thought they were self explanatory:
Configurable horizontal movement. (can configure the horizontal movement)
Air control. (how much control the character has in the air, close to 0 → super meatboy , 1 → hollow knight)
Multiple Jumps. (more than one jump)
Cancel jump on release of a button. (if you release the button the “jump” is canceled)
Multiple Dash (with animation curve). (more than one dash)
Input based Dash (inspired by the game “Celeste”). (dash based on the current input)
Wall slide. (you can do wall Slide)
Input based Wall Jump. (wall jump based on the current input)
Action based movement, not input based. (You won’t find a “Input.GetKey” inside the character controller)
Choose the “Update method” ( Update, LateUpdate or FixedUpdate) with just one click.
AI behaviours, customizable via scriptable objects.
Of course, feel free to keep posting about this or send me an email, it will help the package, me and the customers.
Ok, nice question, if you want to understand the whole package first read the starting guide, that guide is there for you in order to do a custom implementation. Once you get that start from the top to the bottom. The structure works like this:
Character Human Brain (or maybe the AI Brain) → Character Controller 2D → Character Motor
1 - Go to the character brain (Human or AI). In this component the input is updated and sent to the character controller 2D, in the form of an actionValue struct. The input (of course) is independent of the motion update method (update, fixed, etc).
(Don’t worry about the protected override, the “customBehaviour” do the update work)
2.1 - UpdateState will manage the states based on the current action value. This is currently a big switch, go inside a take a look, it’s nothing fancy/complicated. If you want to add a new state (specifically for this implementation in v1.2.1) do the following:
2.1.1 - Go to line 13 and add your state:
public enum CharacterState
{
Normal = 0,
Jumping,
Falling,
WallSlide,
Dash,
WallJump,
ShiftingGravity,
Climbing ,
MyNewState //<-----
}
2.1.2 - Create your “transition” (the way you want) inside the big switch, for example:
2.2 - Then the character motor will do the “Move function”.
2.3 - The character animation (another implementation of mine) is updated.
2.4 - if the brain isn’t an AI brain the action value will do a Reset So the input will replace the actionValue frame by frame.
3 - the Move method , and the character motor, well, this is the end of the ride :), inside the character motor you have boxcast/raycast method in order to move properly the character, to do a slide from slopes, etc etc, you should not touch this part of the package , and i think the basics are explained in the starting guide, not at 100%, because the new wallClimb and slopeALignment are not there (for now).
For the extras part, don’t worry about it, these are scripts/helpers that i used to make the scenes, move the platforms, etc. They are there just for the demo scenes, if you want to use them in your project go ahead (the platform component is really helpful) , but they are not the main part of the package. see the demo scenes to maybe “learn” from them, but i wouldn’t pay too much attention to this scripts, even some of them are really easy and straighforward.
Thanks to you, this helps a lot, the feedback like the one you are delivering right now is extremely important. Sorry if the response is too long:).
For the documentation part in general i ask you for a little patience, i know is too much to ask but currently i’m working on it, tomorrow i will upload 1.2.2 with some modifications requested, along with the Roboto character. For 1.2.3 or 1.3 i will upload a better doc and include the implementation, i promise.
Appreciate your detailed answer, it was really helpful and appreciate also you co-operation to improve the code / Documentation.
I enjoyed reading your answer as it give a good perspective about the asset, and now I know where exactly I need to focus (mainly the brain and the 2D controller) to add more features, so I can leave the underlying details for later.
Now I’m playing around with the 2D player controller, but I notice something when I was playing with the update modes (update, late update, fixed update) I notice nothing changes on the behavior of Boxy while I’m playing the 2D demo scene, so what is the advantage of using this option and when we should use it?
Hi bravery, thanks! i forgot to mention, in order to extending the character controller go to the “brain” and do the input testing that you want first, that information will go directly to this struct, so the first step would be modifying this structure (prepared for the inputs of your game, for example adding a “dashReleased”, or a “SuperJumpPressed” , or whatever you want):
[System.Serializable]
public struct CharacterActionInfo
{
public bool m_right;
public bool m_left;
public bool m_up;
public bool m_down;
public bool m_jumpPressed;
public bool m_jumpReleased;
public bool m_dashPressed;
public void Reset()
{
m_right = false;
m_left = false;
m_up = false;
m_down = false;
m_jumpPressed = false;
m_jumpReleased = false;
m_dashPressed = false;
}
}
If you want to create custom signals or actions just go inside the struct and create whatever variable you like, in this case i have bools, but they can be floats, ints, etc, as long as you asssign some unity input to them (axis, pressed/released, etc). Then the brain will modify them by testing the Unity inputs frame by frame (or in the case of AI via the scriptable objects actions), here you have to do some “if” (see the code for examples).
If you don’t notice anything is “good”, but you will eventually notice something, specially if you put your character in a non-linear moving platform… let me explain (and this is going to be in the Doc, is an important section i’m writing right now):
This part is there as an underlying structure for motion/update setting, it’s just there for support. Currently the character can move in all the possible ways, and can be updated in every update mode. In v1.0 the character was moved by an Update/LateUpdate method, transform.Translate, and that’s it, everybody happy (specially my poor brain), but, if you want to sync with the physics world the super fast (or super slow) update world may not properly interact with the dynamic rigidibodies. Also having a lots of characters in scene the fixed update mode is more eficient (we are talking of 600 characters in desktop vs maybe 400 of the update, i know, madness, but still).
These are the three “valid” combinations: (this is why i said in the HelpBox “Be sure to correspond the…”), although you can combine them the way you want:
Motion : Transform, Update : Update/LateUpdate:
this works 100%, moving and rotating platform look perfect, physics reacts not so perfectly, you could reduce the physics step from 0.02 (50 fps) to 0.016 (60 fps), so with the vsync enabled the difference will be not so noticeable.
Motion : RB.non interpolated, Update : FixedUpdate:
this works 100%, moving and rotating platform " look almost perfect" , they don’t look smooth as the previous one, there is so jittery, specially with an “update camera”, because you have (by default) 50 fps (the 0.02 from before), physics reacts perfectly.
Motion : RB interpolated, Update : FixedUpdate:
this works (IMO) at 80%, same as the previous setting, looks smooth! but this time the moving and rotating platform tend to look clunky, i don’t get why this is happening, the fixed update looks ok, so i expect that the interpolation will do it job, but no, only chaos in extremely situations. Maybe you didn’t notice this, by in the two available demos the setting is this one. The physics interaction are perfect, just like the previous setting.
I’m doing every movement in one call, whether is “Translate” “rigidbody.position” or “rigidbody.MovePosition(—)”, the character internally updates a virtualTransform(position adn rotation), then all the collision testing happens, and by the end the “movement call” is made. This is why if you touch the transform of the character directly (from an external scrip) nothing will happen, because you need to update the “virtual transform” too. In 1.2.2 i’m adding a “Teleport” method.
Here is where the combination may be causing the problem, are the platforms in “Translate”? is the Camera in Update or FixedUpdate? is being interpolated? are the platforms being moved frame by frame? … In summary, If you have any doubt, go with the Update/Late + Transform, every CharacterController2D that i know (at least 2D) uses this aproach. This is why i said before that “is just there for support”, i’m new to the interpolation world, so maybe i am missing something. it works, but use it wisely.
Hi bravery, the Dash ability that i made works like this: once you have pressed the “dash” input the current state change to “CharacterState.Dash” plus the ability is setup (“SetupDash”). Inside the dash state the character moves to the left or right with a given speed (based on the animation curve) during a given duration time. This is the default behaviour, you could easily make a constant curveand modify the duration to make the trick. The things is that the hollow knight dash is “infinite” in duration, so to simulate this behaviour you could do the following:
But there is one more thing, you have to provide an exit to this state (otherwise it will never ends, ok it will ends at 99999.00001 seconds). You could check for the right/left flags of the collision info (isAgainstLeft/RightWall), if this is true return to the CharacterState.Normal state, maybe also check for some input.
Of course the 99999 is a trick, maybe is not a good idea to replace the normal dash with the super dash. It would be better to replicate the behaviour of the normal dash by creating a new one, the “super dash”.
Also the HK dash has an initial state, like a “charging dash” state.
