Third Person Controller - Third Person, AI, Multiplayer, Mobile Framework

Hey Mr. S,
Good to see you with us!

Naomi seems to be ready for action!! I've got some thinking about the abilities and weapons. Apologizing in advance, if the list seems too much. I was just think out loud

I wanted to ask; by "vines" Do you mean like she'll be climbing up, just like to a pipe or a static rope?
and also how she'll moving on ledges? grab the ledge with her hands?
or walk slowly on the ledge, her back on the wall?
or walk on the ledge trying to balance herself not to fall ? All of the above?

For abilities:
- Short fall, long fall, fall to death ( at the end of a long fall, pressing jump might make her roll and take no damage from the fall)
- Running to a wall and jumping may make her grab a ledge that is farther up (otherwise she wouldn't jump high enough to grab it)
-She might grab a cable/ rope on her hands and feet and continue slowly like this example
http://www.wilderness-survival.net/mountain-graphics/fig7-16.gif
-She may slide on a rope/cable.
-She may push/pull some crates.
Actually any Lara Croft ability should suit her

As for weapons;
-She may place some bombs on the floor and walls.
-Some melee moves like kick or stomp.

What do you think? anything suitable for the scene on your mind?

 

Hello again. I was able to take some screenshots but I was wondering if I can record my demo gameplay instead and post it somewhere because I found a few more bugs that are easier to explain with a video rather than with a screenshot. I would hate that such a wonderful asset will get less support from the community because of the bugs. Is really good so far, but will be better without the bugs.

First bug, I get stuck when I press "F" too far from the concrete blockade:
This is actually the farthest that I can be from the concrete blockade and be able to see the icon at the same time. If I press the "F" key, the character don't jump over it as he's supposed to, but get stuck instead. I can look around, change weapons and aim, but can't shoot or move.This happens when I stand in front of the barrier and press "F" rather than run against it and press "F".
I'm actually stuck in this screenshot and can aim, change weapons or look around, but can't shoot or move.

Second bug, I get stuck if I'm not in the proper place to get to cover when I press "F":
Far again from the spot but I can see the icon. I press "F" and get stuck again.
Again I'm able to aim, change weapons and look, but not move or shoot. Actually I can jump to "unstuck" the character, but that's still a bug,

Third bug, when I pick the knife close to the edge and try to aim to the turret one floor below, the character start to slip like is being pushed by the wind.
Actually the character is being pushed by the wind here.
This is where he ends after being pushed.

Fourth bug, if I go close to the edge and keep walking backwards to make the character fall, he gets stuck if I walk towards the edge again.
Here I'm stuck again.

Fifth bug, the character displays fall animation while going down in the platform:

There's also a few occasions that I get jerky camera like when I run and jump against the messy boxes after the barrel explodes, when I run and jump against the stairs and against the boxes in general. Also I'm not sure if is actually a bug, but the "roll" and "jump over concrete barrier animations" are kind of too fast. The cover behind boxes feature need more polishing when it finally works.

Also is difficult to make the icon appear when close to the platform control panel. Also I was wondering if it's possible to make the character choose what he's able to pick like weapons and ammo rather than just pick them by walking over them. Also I was wondering if it's possible to make the character jump over the yellow barriers close to the edge. Also make the character take damage by falling from high altitude places. Also, is this compatible with mobile? All of that configurable and selectable of course.

I'm not trying to discourage you with my criticism because I really like the asset. Since I'm a newbie and I'm not a good programmer I'm really interested to see those bugs fixed to be able to use it to the maximum. I think this is a good asset so far, but with the bugs fixed anybody will be able to build a AAA game with this asset. Thanks for taking the time to read my posts and good luck with the asset.

 

@gurayg
"Short fall, long fall, fall to death"
= single initial section with variable length middle and custom end... possibly a general template of that nature would have value.

Your second and subsequent points pretty much outline what I was going to say.

Some sort of "sphere of possible moves, filtered by dis-similarity of paths" projected onto the apparatus.

From that, all other possible awesome combinations would spring...


@BigLouis1971 "Third bug, when I pick the knife close to the edge and try to aim to the turret one floor below, the character start to slip like is being pushed by the wind."

I did have one note about the knife weapon in the shooter demo.

It has some sort of property (that I haven't found yet) that affects the foot IK, this exhibits in a variety of odd behaviors, knee jerking, swaying strongly in one direction or another, foot snapping to weapon et cetera.

There is a dragon in there somewhere.
If found it would possibly clear up the other errant behaviors I noted, for no extra effort.

I too found those issues you mentioned about the edges, and a few others.

It seems to mainly center around perceived body circumference issues (or the perceived "skin width" if you prefer). This may just be a tweaking config thing. hard to say until I understand the settings more.

The "F doesn't trigger for reason X" issues you note possibly are based on Trigger distances or other precursors not being a "required" in the logic flow of action. Or put another way the UI is disconnected from the underlying logic that allows the action to happen. That is pure guesswork but sounds in the area. Again, needs a look.

As you say, nice framework. That will be even nicer given a bit more battle-testing.
I'll hunt around and see if I can figure out the weapon v IK logic issue.

@BigLouis1971 "There's also a few occasions that I get jerky camera like when I run and jump against the messy boxes after the barrel explodes, when I run and jump against the stairs and against the boxes in general"​

What rendering path are you using?
I went with deferred and took the time to bake all the lights/probe, Then disabled all the realtime ones. This has solved many all of the performance issues associated with having a Bazzilion realtime lights....

Are you forward path? No Lightmaps? by any chance? if so, look at your profiler.

 

okay. the IK mangler is in "Melee Weapon" somewhere, sphere collider maybe?



I'll see if I can find it

hmm... seeking to disabled sphere collider maybe in the IK?

 

Wait a minute, I don't understand half the things you said because I'm not a programmer and it seems that you're using programmer vocabulary. I don't actually have the asset yet, I'll get it in a few weeks. I was just playing with the demo and found the bugs I mentioned. Can you tell me in easier vocabulary what you said? As I said, I'm a newbie and I'm just starting to play with Unity.

 

Are you one of the developers?

 

Hi, no I am just a user. Who is looking at the issues you described and re-expressing them in such a way to expedite them getting fixed.

 

Thanks, so basically you rephrased what I said in programmer vocabulary?

 

We were simultaneously doing the same work.

Kwinky-dinkly.

and it looks like there is already that "vault" action you requested...


In other news, I don't think it is the IK seeking to a disabled sphere. Well not just any disabled sphere collider anyway as I added my own ("cube" melee weapon) and did not get the same result when in the same place, with the same layers enabled et cetera.




will have to keep digging

I did find a few "I am stuck on the edge but I shouldn't be" cases that I will look into.




and here is that lot flat shaded for extra awesome



oh yeah

 

@BigLouis1971 -

Thanks for the bug reports! I really appreciate it because it will help make the Third Person Controller a better asset.

It is also good timing because I think that I already have all but the last two bugs fixed. The first two bugs relate to the abilities trying to move the character but the character not responding to that movement. I fixed this a few days ago but I have since been working on some other polish so I haven't uploaded a new demo yet or submitted a new version. The third bug relates to the colliders on the weapons and was fixed this morning. As you can see in @twobob's screenshots, the weapons have a collider to prevent them from clipping through the wall. This collider is intersecting with the character's collider and that is causing the physics to push the character. The fourth bug relates to this. I'll take a look at the falling bug.

In terms of the jerky camera movement, I'll play around with it in that area to try to reproduce it.

We'll take a look at polishing up those animations.

There are a couple of settings that you can adjust for it to determine if the character is in range. I'll take a look at fine tuning those.

It's not possible right now but I do plan on improving the object pickup scripts.

Are you talking about the railings?

You can do that with the current version. If you fall from the very top floor to the bottom you should get some fall damage.

Yes, it is.

I really appreciate all of the feedback. This next release is going to be purely a polish/bugfix release so we'll get it taken care of.

 

@twobob -

I just fixed that sphere issue this morning - I'll send you a PM with a link to try this new version out.

 

good works GUYS !!!

 

Thank you for the feedback @gurayg! Naomi is getting ready for action, and yes I was thinking along the lines of Laura Croft too, since they will have similar weapons/style

By vines, I am picturing Zelda like static vines that you will be able to climb up or across. And for the ledges, I plan to include both the grabbing ledge/moving across and walking slowly with back to wall options. I hadn't planned on the balancing herself not to fall but we should be able to add that, or maybe on a rope instead of a ledge.

All of the ability ideas I have planned, except for the grabbing the cable with both her hands and feet, we will think about adding that later.

For the adventure scene we are focusing on no fire power weapons, I will hold on to the bomb idea though for another scene we have planned. I definitely like the idea for melee moves and will make sure to have some options for those in this scene!

Thanks again for your ideas!

@twobob The flat shading looks awesome!!

Sarah

 

hehehehe !!!! AMAzing !

 

Hmm.."S" like in Sarah!
"S" like in Sorry then.. sorry!

I'm not surprised that you've already planned most of the abilities already, I knew Opsive was awesome, that just proves it

Just a small note, I remembered another good fit for a female action hero with all kinds of melee and action moves. If you're looking for more reference here is Nilin.
But this time I'll let the images talk.
Game "Remember Me" hero " Nilin"

action starts at 2.15 and melee fight starts at 4:45 (It's a bit long you might want to skip)
one thing I should point out is her ability to jump between ledges and jump to her back while holding a ledge.

 

@gurayg Haha, that's ok! Yes "S" like in Sarah

That reference video will be great to have, thanks for posting that! Gives me some more ideas, and I like the long jump with the running start. We will definitely try to include a lot of those abilities! It's nice to have a reference where it's all actually in the game too, helps me to see how animations piece together. I'm really excited about this scene!

 

HARD game??!!

 

Its been a while since I've played "Remember Me" but I don't remember it being hard at all.
It look complex by design, you actually press 2 buttons to do all those moves.

 

OOOH that's VERY nice XD AND tanxxx for tell ME that !!! LOL

 

Small controller feature.

Holding down sprint while jumping causes the fall/grounding cycle to not terminate/start

So "Jumping whilst sprinting without releasing sprint"

resulting in the following final position



releasing sprint fixes this (and probably other stuff does too)

Jumping, notably, does not fix it.

I did run into an issue when converting large amounts of preexisting meshes into other styles (as I COMBINED into one object without thinking about the implications of that) where the stairs "physical" colliders were being considered, and thus impassable. This is user error really. But I note it here since I won't be the last to make this error I would wager.

If I gambled.



so one bug/feature, one idiot.

chalk it up.

Great to have a nice controller though...



Will refactor the weapons to be something a bit more "creative" for our uses
hmm... that sounds like genuine fun now what can I turn a gun into.... hmm

 

Hey opsive,

Was getting the error below when i was trying out the adventure demo and a lot of bouncing going on with the character.
<RI.Hid> Failed to get preparsed data: The request is not supported.
<RI.Hid> Failed to get device caps (0xc0110001) for 췀".

 

Am i wrong or should it be Mrs. or Ms. S then by interpreting Sarah?

 

This ? http://forum.unity3d.com/threads/ri-hid-failed-to-get-preparsed-data.173415/#post-2069810 - as for 췀 that may pertain to an attached devices name (CNJoy?) which may - or may not - help figure out which device is doing it.

 

http://www.opsive.com/about.php

 

@twobob -

Thanks for the bug report. This occurred because the sprint ability doesn't have its own set of animations so when the fall ability ends and the sprint ability starts again it tries to play the sprint ability animations which don't exist. I am now just playing the default set of animations if a particular ability doesn't have any animations. I had to make two changes (one for lower body and one for upper body) so I'll just send you the new file over PM.

 

Thanks man. I was going to fix it myself - then was like - uh no don't - tell him.
Early AM decisions, never been great at them. (similarly I don't do great posts without way more coffee)

Appreciate your excellent support as ever.

 

@RandAlThor Ms. S

Thank you for posting that link @twobob !

 

@twobob -

BTW I really like the flat shading style. I don't know what is with Doug, but he always ends up watching the sunset (second image).

 

@twobob and @TheLetterS
I know that but try to friendly push users charles01 and gurayg in that direction

 

hahaha I remember that image!!

I balanced the light a bit more and took some input on the skybox.


Converted everything to a flat style last night. Maybe I can convince the boss to let me use a gun in a game...
(but I doubt it) will think what /other/ non-lethal things he may hold in his hands

I think I will go read the latest manual from front to back just so I don't make any more stupid mistakes.




Also appreciate the camera - ACTUALLY - doing what I expect, for no garbage.



It is refreshing.

thanks

 

Hey Opsive,

I was wanting an ability where my character stance would change based not the weapon/item he was holding. And my initial thinking was to have DetermineLowerBodyState in AnimatorMonitor reference a different Animator Controller Layer : "Rifle Layer", where I'm Syncing to "Base Layer"...but with different clips replaced:



But I noticed that DetermineLowerBodyState function in AnimatorMonitor.cs however is set for private, and is hard coded to read from layer index 0. I'm going to try and get my functionality be directly editing that source...but it'll likely be bad form once I get a new update.

I'm thinking maybe setting up DetermineLowerBodyState to be virtual, so that I can override it at the wrapper level?

Let me know your thoughts.

Thanks.

-Mike

 

Using layer synching sounds like a great approach. DetermineLowerBodyState is set to private because the calling method - DetermineStates - is set to public and will call both the lower and upper body version of determine states. I don't think that you'll need to change the accessibility level of DetermineLowerBodyState but you'll definitely need to change the layer index. I'll mark it virtual for the next release.

 

Hey Opsive,

I went ahead and implemented my Stance_OnItemEquipped ability locally. And wanted to offer how I did it and get your thoughts on it:

Added public ints for UpperBody and LowerBody index. I also went and updated wherever 0/1 values were hardcoded and replaced them with these index in AnimatorMonitor. This'll let my stance ability have full control over the animation layer used:



Updated DetermineStates to pass these Indexs to upper/lowerbody functions:



And I now have the ability to switch out animation stances based on item equipped. However I didn't quite get Sync Layers working. Here's why:

I get a "Calling Animator.GotoState on Synchronize layer" error when...



ChangeAnimatorStates(){ m_Animator.CrossFade ...; } to the sync layer, and the clip/state.Motion is None/empty:



I need to figure out how to identify/filter and handle this case. I'm thinking I'll need ChangeAnimatorStates virtual, so that that I can override with this functionality.



Anyhows, let me know what your thoughts are.

BTW, I love this asset. And are learning a ton from how you've structured this.

Wonderful work!

-Mike

 

BTW, I also commented out m_ActiveAbility here and in ChangeAnimatorStates:



And did not notice any issues. I also did a solution wide search for and did not getting any hits on it being called outside of AnimatorMonitor. It was causing an out of Index error when my Stance_OnItemEquipped updated the layer index > 1. Maybe it is safe to deprecate???

-Mike

 

It's great to hear that you're learning a lot from the Third Person Controller!

If I change the DetermineUpperBodyStates/DetermineLowerBodyStates to virtual, is there a reason why DetermineStates needs to be virtual as well? I definitely don't mind changing it, I'm just trying to understand and can possibly suggest a better way of doing it. Also, making the layer index a protected variable isn't a bad idea but may not be necessary if DetermineUpperBodyStates and DetermineLowerBodyStates is virtual.

When you get that GoToState error, what is the state that it is trying to go to? Based on your screenshot, the state should be "Crouching Movement". The Animator Monitor changes states, not motions, so having a motion set to None should be no problem.

Yes, thanks for letting me know. I just removed it.

 

I'm still looking into this, and may need to setup a very simple test case to understand what is going on there. I'll update once I find out more...

My understanding is that DetermineStates is a wrapper for Upper/Lower...I'm imagining it being called by another ability not passing in the current layer index info resetting the stance. However, if both DetermineUpperBodyStates/DetermineLowerBodyStates are called directly with the layer index as a protected variable are passed in, then DetermineStates doesn't need to be virtual. Let me know your thoughts.

Thanks for the quick reply and support

-Mike

 

That is correct. If DetermineUpperBodyStates/DetermineLowerBodyStates are overridden then you can just supply the layer index with that overridden method.

 

All of the demo scenes have been updated with the latest set of bug fixes. In addition, the aiming is completely controlled by IK now and you no longer have to specify multiple aim animations to blend between. @BigLouis1971, this should fix bugs 1-5. I am still planning on taking a look at the other things that you mentioned.

 

Hello,

A bug that I found is that the camera's direction velocity is still maintained even when the variable m_AllowGameplayInput is false. This means that the camera will still move when the item wheel is visible provided that the item wheel becomes visible during camera motion.

Also an idea for the item wheel is to allow for time to be paused or slowed when it is visible.

 

Good catch! Open up CameraHandler.cs and change AllowGameplayInput to:

Code (csharp):

1.  
2.   private void AllowGameplayInput(bool allow)
3.   {
4.     enabled = allow;
5.  
6.     // Stop the camera from moving if gameplay input is disallowed.
7.     if (!allow) {
8.       m_Yaw = 0;
9.       m_Pitch = 0;
10.       m_Focus = false;
11.     }
12.   }
13.  

In terms of slowing down/stopping time, that is a good idea. I just wrote it down. We are planning on releasing a polish/bugfix release this week so it should be in the update after that.

 

Hey Justin,

I got stance switching working. I big obstacle was how Abilities like Jump and Fall are hard coded to use 0 and 1 as the upper and lower layer. Here is what I had to do to get things to work locally:



I had to capture the current lower/upper state as additional variables in AnimatorMonitor, and had the abilities update to look them up. Any thoughts on a more elegant approach??

Thanks for your help and attention so far.

-Mike

 

I think that is the best way to go about it. lowerBody_LayerIndex should probably be a property but other than that it looks good. I'll make the change on my end as well

 

Version 0.87 has been sent to opsive.com purchases and should be available to download on the Asset Store soon. You can view the changes here. This is mostly a bugfix/polish release, but it does change how the aiming works. In previous versions the aiming pitch was controlled by blending three different animations. Now only one aim animation is required and IK will do the rest.

@MikeTon - the DetermineLowerBodyState and DetermineUpperBodyState methods within AnimatorMonitor are now virtual. Furthermore, you can override GetLowerBodyLayerIndex and GetUpperBodyLayerIndex to return a different index so you shouldn't need to change the base AnimatorMonitor class anymore.

 

Having tried out the demos, I'm gonna be quite frank, they make a rather poor first impression. The movement and controls are incredibly clunky and unresponsive (changing directions takes far too long, jumping is awful (aside from the aforementioned camera problem, it just doesn't feel right and doesn't work when trying to jump up stuff like boxes) and it locking the camera during a jump is a terrible idea), and the way the camera moves up and down along with the character's steps is one of the worst things you can do with a camera. The whole thing just feels like it's trying too hard to be 'realistic' and just ends up feeling clunky instead, it feels even worse than GTAV in that regard.

Despite the large list of features and positive impressions, I'm not really confident that this can suit my needs unless it's possible to adjust things so the controls are much tighter and much more fluid - I don't want to be locked into 'realistic' movement, I'd like to have room to have tighter, more fluid controls closer to a more old-school game like, say, Quake. I'd love for someone to prove my fears wrong, but the demos have some serious problems that give that kind of impression.

Also, side-question: is it possible to switch between 'adventure' and 'TPS' modes on a dime with this? Think Kid Icarus: Uprising for a good example of what I'm going for.

 

@Candescence -

hmm, do you mind trying out the executable? I'm curious if it is a web player problem. You can download the executable here (if you are on a Mac I can build that as well).

The movement is controlled by root motion so it is completely based on the speed of the animations. The speed in which it changes between states can be adjusted so this would allow you to increase the speed that the character can change directions.

Dealing with the camera, I'd like to be able to reproduce what you are seeing. For example when the character walks, the camera hardly does any bobbing at all with the character's step. If you are having this problem then chances are others are as well so I'd like to get it fixed.

Yes, you can switch between the two with:

RigidbodyCharacterController.Movement = movementType

Where movementType is an enum.

 

@opsive -

Well, the executable has much the same issues.

I figured root motion was mainly the problem. Though I would like to have option for strafing movement that isn't driven by animation, in case, say, someone wants equal speed in all directions, which I'm pretty sure is absent in pretty much every strafing animation set I've encountered so far.

While the camera bob isn't that much, it's certainly noticeable, I think it's because the camera is tied to one of the character's bones rather than the root of the character - it's not a major problem, but still an annoying one. It stops bobbing when aiming. And it most certainly locks up when the player is not grounded.

And, really, the jumping is the biggest problem right now, I think, probably because it's tied to root motion as well at least partially, which I consider to highly counterproductive. But, in any case, it simply doesn't work properly when trying to jump up certain types of objects.

 

I'll add an option to the next version that prevents the controller from requiring root motion. You are right in that some game types it doesn't make much sense to use root motion. This should be a quick change.

You're right - it's tied to the character's head. When the character is aiming a different animation state plays which completely prevents the character's hips from moving up or down so that's why you don't notice it there. You can change what the camera is anchored to via an inspector property though so that's customizable.

Can you tell me how to reproduce this one? When the character is in the air root motion isn't used at all.

 

Oh, that's good. Options for movement that isn't tied directly to root motion would be useful.

Good to hear, thanks.

Just run up against a crate and try to jump while moving forward. It works on some objects but not others, it's kinda weird like that, it's like the controller is getting stuck in the object. Fix that and the camera lock, and hopefully it'll feel a lot less clunky.


Gotta say, these responses have certainly improved my opinion on this one, nice to see a dev addressing concerns in a timely manner. Kudos.

Other things I've noticed in the TPS demo: the weapon wheel doesn't work with the mouse for some reason, it might be helpful to have a button that switches which side of the player the camera is on (or do it automatically if there's a wall to their side, for example) and it's probably better to have the knife animation being on another animation layer for just upper body animations like the guns (generally in third-person games using a knife doesn't stop you in your tracks) but its main problem is that the actual knife attack animation doesn't work properly sometimes, especially if you attack continuously, it starts looking like the player is just trying to weakly push it forward a bit. Just a heads-up on that.

 

Awesome, thanks for these bug reports. The jumping has been fixed and the other bugs have been fixed as well in the latest demo (make sure you force refresh the page to prevent the web player from being cached)

This looks like it is exclusive to the web demo. It's not fixed in the latest demo but I'll have it fixed before the next version is released.

Edit: this is now fixed as well

There is a property on the camera controller which lets you set the offset so that can easily be changed. Having it done automatically would probably be the right way to go, leaving it as an option of course for those that don't want it. I have added this to my todo list.

The knife attack animation is on the upper body layer, but we also have a lower body layer for the knife attack so that's why the character stops. The right way would be to have a separate knife attack animation for the moving state as well.

Thanks - fixed!

I appreciate it We're in it for the long haul so any bug reports are greatly appreciated

 

Hi Everyone!

We've been making a lot of progress on the adventure scene, here are a couple screenshots from the lab area. We are still tweaking colors and arrangements of everything but this is what we have so far.




The main focus for the lab area is to show off the push, pull, and open animations for the adventure character. You will first push the cube over a floor switch which activates the wall lever. The wall lever then opens the door to the small room where you can access and open the crate inside.

The other main areas of the scene include the character's living quarters and a training grounds of sorts to show off most of the animations such as crawling, jumping, climbing, etc. I will post screenshots of the these two areas in the next week or so.

Thanks!

Sarah