playMaker

Author Topic: (Solved)there HAS to be a way to JUMP with Character Controller in 2020...right?  (Read 7692 times)

Qbanyto

  • Full Member
  • ***
  • Posts: 137
  • Vista Larga, Paso corto
absolutely LOVING playmaker but..

I've been looking at many posts that show how to jump using a chaacter controller. How to do it with scripts, actions, etc. But did something change? Cause they don't work for me. I'm talking about the one by Jeanfabre with the characterMotor.js script

Also I saw many YouTube links posted by Padur but the videos are down! I tried the other one by  but they are outdated, or when i try this, it won't work.

Can we put our heads together and try to figure this out for a Character Controller (no rigid body) and maybe save it in the ecosystem?

Right now I'm using a "Controller Move" action to move my play on the Y Axis to jump and manipulating the animation timing so it looks like a jump. but that's like the "bootleg" version of a real jump. looks a bit weird.

Keypoints:
How to make a jump for a third person character controller player?

Please advise fellow devs!
« Last Edit: August 25, 2020, 02:39:56 PM by Qbanyto »

djaydino

  • Administrator
  • Hero Member
  • *****
  • Posts: 7616
    • jinxtergames
Hi.
May i ask, why no rigidbody?

As if you do not use rigidbody you can not use velocity or force.
So you could only use translate, which will ignore any collisions as it will ignore any physics.

nuFF3

  • Beta Group
  • Junior Playmaker
  • *
  • Posts: 74
  • Are we even real?
    • One Month Studio
Good thing I made a few videos on the subject of a basic fps character controller using Playmaker.
They are somewhat long and I'm not going by a script so it might be a bit rambly, but I go thru' everything you need to set up a basic character controller.
Movement - Jumping - Crouching -
The same principles can be used for thirdperson, since it's just an issue of camera placement, everything else is the same.

nuFF3

  • Beta Group
  • Junior Playmaker
  • *
  • Posts: 74
  • Are we even real?
    • One Month Studio
Hi.
May i ask, why no rigidbody?

As if you do not use rigidbody you can not use velocity or force.
So you could only use translate, which will ignore any collisions as it will ignore any physics.

I think it's generally a bad idea to use rigidbody character controllers, where the physics are controlled by a rigidbody and a collider.
Since it leads to physics issues with collision detection and the general issue of "physics objects digging into stuff" when given much force.

Using Unitys character controller and calculating the gravity by script, along with the jumping is the best way to go for physics stability in a character controller.
« Last Edit: August 02, 2020, 04:18:23 PM by nuFF3 »

djaydino

  • Administrator
  • Hero Member
  • *****
  • Posts: 7616
    • jinxtergames
Hi.
It probably depends on your project as i our project we need all sorts of physics.

I just took a quick look and i noticed @7:46 that you mentioned that transitioning to a other state 'cost a frame'.

This is not the case, you can loop thru 1000's of states in 1 frame.

But depending on your actions used you can have other results.

nuFF3

  • Beta Group
  • Junior Playmaker
  • *
  • Posts: 74
  • Are we even real?
    • One Month Studio
Hi.
It probably depends on your project as i our project we need all sorts of physics.

I just took a quick look and i noticed @7:46 that you mentioned that transitioning to a other state 'cost a frame'.

This is not the case, you can loop thru 1000's of states in 1 frame.

But depending on your actions used you can have other results.

Yeah I generalized it, but I've always felt it runs slower when I move through too many states quickly, idk might have been placebo :S
Perhaps it's because I've only ""noticed"" latency when doing 'every frame' stuff within those states if required.

But I feel it's better to do more things within one state than to have it spread out without it needing to be spread out into different states.

If you can solve the problem within one state, why wouldn't you :P

djaydino

  • Administrator
  • Hero Member
  • *****
  • Posts: 7616
    • jinxtergames
Hi.
its definitely not a 'general' thing :)

For something like movement yes, for other things maybe not.
But its important to know that changing to another state is Not using a Frame.

Qbanyto

  • Full Member
  • ***
  • Posts: 137
  • Vista Larga, Paso corto
Dude! I loved those videos (It was one of them first ones I watched to making a character controller) and i did PRECISELY what u suggest about a week ago. I said “well i can apply this to my third person controllers easily” But I couldn’t get the animations animate. But I’m gonna try ur method again.but the more I use playmaker the better I get at it. So I’m gonna give your videos another go. Awesome that you are here man.  I thought this was a ghost town.

And I agree About rigid bodies. I’ve had weird spams with them.


Good thing I made a few videos on the subject of a basic fps character controller using Playmaker.
They are somewhat long and I'm not going by a script so it might be a bit rambly, but I go thru' everything you need to set up a basic character controller.
Movement - Jumping - Crouching -
The same principles can be used for thirdperson, since it's just an issue of camera placement, everything else is the same.

Broken Stylus

  • Beta Group
  • Hero Member
  • *
  • Posts: 772
Hi.
It probably depends on your project as i our project we need all sorts of physics.

I just took a quick look and i noticed @7:46 that you mentioned that transitioning to a other state 'cost a frame'.

This is not the case, you can loop thru 1000's of states in 1 frame.

But depending on your actions used you can have other results.

Yeah I generalized it, but I've always felt it runs slower when I move through too many states quickly, idk might have been placebo :S
Perhaps it's because I've only ""noticed"" latency when doing 'every frame' stuff within those states if required.

But I feel it's better to do more things within one state than to have it spread out without it needing to be spread out into different states.

If you can solve the problem within one state, why wouldn't you :P

If you can keep your state tidy, why not?
It follows that using events to jump from state to state would require more computation simply in dealing with these events, which cannot be free no matter what. So there would logically be a practical advantage in keeping more stuff inside a state.

nuFF3

  • Beta Group
  • Junior Playmaker
  • *
  • Posts: 74
  • Are we even real?
    • One Month Studio
Hi.
It probably depends on your project as i our project we need all sorts of physics.

I just took a quick look and i noticed @7:46 that you mentioned that transitioning to a other state 'cost a frame'.

This is not the case, you can loop thru 1000's of states in 1 frame.

But depending on your actions used you can have other results.

Yeah I generalized it, but I've always felt it runs slower when I move through too many states quickly, idk might have been placebo :S
Perhaps it's because I've only ""noticed"" latency when doing 'every frame' stuff within those states if required.

But I feel it's better to do more things within one state than to have it spread out without it needing to be spread out into different states.

If you can solve the problem within one state, why wouldn't you :P

If you can keep your state tidy, why not?
It follows that using events to jump from state to state would require more computation simply in dealing with these events, which cannot be free no matter what. So there would logically be a practical advantage in keeping more stuff inside a state.
Yes, my point exactly (but I didn't word myself well enough).

I did make a mistake by saying "it costs a frame", what I should have said is "it costs more computational power".
In fact, it costs quite a lot of computational power.
I've previously searched the web to quell a thirst for knowledge, that of "How expensive are operations on a CPU", and my answer was as follows:

It varies depending on instruction set and bit width and cpu architecture, but adding and subtracing is fairly cheap (pretty much the cheapest you can get), followed by multiplication.
Division is very expensive, and doing exponent and cos/sin operations is even more expensive.
Then we have branching. Branching is in orders of magnitude more expensive than division and the likes.
But branching can also be somewhat cheap, if the branch was predicted "right".

So I'd have a hard wager that switching between states with events can cost quite a lot if done too much.

I guess bottom line is; keep your states, and subsequently your code tidy.
« Last Edit: August 04, 2020, 04:41:02 AM by nuFF3 »

djaydino

  • Administrator
  • Hero Member
  • *****
  • Posts: 7616
    • jinxtergames
Hi.
Quote
In fact, it costs quite a lot of computational power.

This is untrue as well. changing states does virtually nothing.
C# you could compare this as methods (but i am not sure how Playmaker is doing this back-end)

Things like Creating / Destroying objects, those are cpu heavy stuff and can lag your game.

ManInAShedGames

  • Playmaker Newbie
  • *
  • Posts: 37
If you have the playmaker editor open while playing your game, it slows down and chugs as it changes states. Could this be the issue? Closing the editor stops this.

djaydino

  • Administrator
  • Hero Member
  • *****
  • Posts: 7616
    • jinxtergames
Hi.
Making inspector and playmaker window not visible will reduce editor lag indeed.
The reason for that is the (Gui) refresh for the inspector uses a lot of resources.

"Inspector" is actually more heavy than the Playmaker window depending on how many and what kind of components are used on the selected object.
Many fsms on a selected object can make things a lot slower, this is due to the way unity handles their ui refreshing.

But its actually not (only) slowing down changing states, it slows down everything.

For performance tests you should always test in a build, even if you are not using Playmaker.

Broken Stylus

  • Beta Group
  • Hero Member
  • *
  • Posts: 772
Hi.
Quote
In fact, it costs quite a lot of computational power.

This is untrue as well. changing states does virtually nothing.

It could depend on how many events and transitions you use in FSMs, the spread of the logic tree.
I haven't pushed that too far either into some kitbashed benchmarking project, but since it's always greatly advised not to have big FSMs on gameObjects, thus not too many states; there's an implied performance cost somewhere down the road with having tons of small states instead of less but bigger states. That's my speculation though.

As for an event transition, I suppose it just says endThisMethodNowAndLaunchThisOtherOne(). :)
 

djaydino

  • Administrator
  • Hero Member
  • *****
  • Posts: 7616
    • jinxtergames
Hi.
In the editor is will indeed slowdown if you have lots of states.
But in a build not.

Reason is that unity GUI refresh need to refresh more stuff to get the visuals playmaker has.