Its not so simple. You need to stable the camera too. Some space game did a blog on this, dont remeber the game. Open world space game of some sort
1 Like
I’ve seen our character controllers mentioned a few times here so I thought that I would chime in.
One of the key things that you want to look for is extensibility. No asset is going to provide you with exactly what you want out of the box. Because of this you’ll want to be looking for something that can be extended/tweaked for your specific use case. UFPS doesn’t include any parkour functionality, but as @egable mentioned it does include an ability system which allows you to extend the controller without having to change any of the core scripts.
I don’t want to keep promoting UFPS in this thread but if you have any questions on what you can change feel free to reach out at support@opsive.com or post any pre-purchase questions in the Ultimate Character Controller thread .
2 Likes
On the contrary, I think the asset store is the best place to find it. There’s not a lot that doesn’t exist on the store, by this stage there are all sorts of ex-AAA devs on there who are perfectly capable of providing the same quality (within the constraints of the engine) as any game out there.
But unless you find some way to get the asset for a ‘trial period’ it’s unlikely you’ll find exactly what you need right off the bat in a demo.
Cool! I have a question. I just tried the demo again (this one, windows version: https://opsive.com/demos/first-person-controller-demo/ ). First of all, what other first person shooters do you or other devs on the team play? What’s the pool of references that informs your design decisions?
For example when I aim down sights with the assault rifle or pistol, the camera zooms in, and the mouse sensitivity should be decreased for a more precise aim, but instead it is increased. I verified it by moving the mouse right up to the edge of my keyboard, moved it till I’ve turned 180 degrees ingame, aimed down sights, and moved the mouse back the same distance up to the edge fo my keyboard, and that moved me about 270 degrees back in the other direction ingame. I think that’s a bug and I think that every hardcore AAA FPS player would agree that this is a bug. I can’t think of a single AAA shooter that behaves like this, and I’ve played a lot of those. Please explain why you went with increasing the sensitivity during ADS instead of decreasing it, or if it’s a bug, why no one on your team noticed it.
Personally I have always been a Halo fan. The aim sensitivity is decreased, but because of the zoom level it may have appeared that it is increased. This setting is determined by a preset using the state system so you can easily tweak it. I will also decrease it a bit more.
One of the few shooter franchises I never played on PC, but a friend of mine is really fond of the masterchief collection.
It is not, at least on my pc. Please reproduce the test setup I have described in my post. There is nothing subjective about where a rotation of the same mouse movement distance ends up rotating me ingamge.
You’re absolutely certain there’s no acceleration or “enhancement” of your mouse input?
On an OS level? Yes I’m absolutely 100% certain, because it would drive me crazy. Moving the mouse the same distance at varying speeds moves my cursor the exact same distance on my desktop, as it should be. Also the way I performed the ingame test it wouldn’t matter, since I moved the mouse at a steady pace and got steadily reproducible results.
I am also pretty certain that there is some form of (by my guess unintentional) mouse accelleration in the FirstPersonController Demo, since there the same distance of mouse movement at different speeds does not result in the same amount of ingame rotation.
If you’re curious, download the demo and try it. It’s only 252mb.
@opsive : alternatively try this: connect a gamepad, launch the demo, pick up the rifle, keep turning in 360° rotations with the gamepad, then hold down LT to ADS and see that the speed of rotation noticably increases and the time it takes to rotate 360 degrees is noticably shorter. Also why is no button on the controller mapped to sprint? And why doesn’t sprint cancel crouch? Again, I can’t think of a single AAA shooter that is set up that way. It makes no sense to me. If Halo is set up that way, it’s against current industry standard. Correct me if I’m wrong, but didn’t they originally have very different button mappings on consoles (RS to ADS, LT to throw grenades iirc) but then caved and changed it to the industry standard (COD) layout? I remember their - for me - unusual controls being one of the reasons for not getting along with Halo ODST on xbox 360.
I own Opsive’s UFPS and can say hands down it is the best fps asset on the market.
1 Like
I have downloaded and tested it in Unity now. Turns out there was a bug in the jump code. I fixed and reported it.
There seem to be more bugs/design flaws regarding the movement, because the behaviour varies a lot when changing the physics timestep value to extreme settings. But it’s probably easy to fix too, I just haven’t looked too closely yet and I thought maybe the developer will do it themselves.
Overall I was quite happy with the code of the controller and learned a couple things. I’m not sure anymore starting from scratch makes more sense than polishing this one.
The FPS builder asset actually has a view model for the body, but the movement is still done with physics forces. I think many TPS controllers are moved via rootmotion. Locking a first person camera to a rootmotion animation driven body could feel super clunky and unresponsive.
I think you’re both right. Physics based controllers are a tradeoff imho. I’m most worried about the physics based controllers running on fixed timestep and thus getting a slight lag and choppy movement if your framerate is much higher than the physics timestep.
Has anyone experimented with a hybrid approach where the movement code runs in Update() and when it detects the need for a physics based interaction it seamlessly switches to physics based movement and running the code in FixedUpdate() ?
No, you don’t. You can easily listen for collision callbacks and apply forces yourself, which also gives you more control than just having physics handle it.
Edit: And it works both ways. You can also move yourself based on things hitting you if you want the player to get knocked around.
1 Like
I would just get used to using FixedUpdate for anything that has to do with game state. Using Update is asking for issues down the line, especially if you’re thinking about doing anything network related. In my opinion you should only use Update for reading input, visual effects etc. that don’t affects game state and use FixedUpdate for movement, shooting, and everything else that affects game state. And then you can do interpolation in Update to ensure smoothness.
If it’s for a serious project I would make a character controller where I have full control over everything like this one: https://assetstore.unity.com/packages/tools/physics/kinematic-character-controller-99131
The only other scenario I can think of is if I wanted actual physics force based movement. Anything else I would consider to be a lazy solution.
There’s a fairly solid free Kinematic character controller available on the Asset Store as well: https://assetstore.unity.com/packages/tools/physics/scivolo-character-controller-170660
And they’re surprisingly easy to make yourself as well, especially looking at existing ones for inspiration.
Another area where I’ve not seen any Unity asset do things correctly is shooting logic. What to do when your gun shoots faster than your framerate? They all handle shooting in the most naive way possible, similar to Unity’s own tutorials, comparing a timer variable with delta time seeing if a bullet should be fired this frame or not, but if 2 or more bullets are supposed to be fired in 1 frame the logic fails.
1 Like
Most guns shoot in the 700 to 900 rounds per minute ballpark. Way slower than the fps of a game. Miniguns can fire up to 6000 rounds per minute or 100 per second. Those might need to fire off more than one per frame.
Assuming FPS is something you as a developer has control over is wrong. You’re of course free to do it wrong, and even AAA developers do it wrong, but then it of course wouldn’t be correct. 
If you made a competitive multiplayer game it would be unacceptable. Assume FPS can be 1, assume ping can be 1000 and so fourth.
1 Like
We don’t assume anything. We do it like this. We calculate when next shot should be then fire it off when time has passed this. Then we remove any overshoot delta so next shot will be a little bit earlier. This way over time you will get a even distributed shots close to the fire rate of the real world firearm.
Our game is a VR game with perfect performance so it will always be 90/120/144 Hz though. Unless you have a background application doing something.
Don’t assume all you talk with here are failed devs or noobs, most are but we have gunplay and ballistics that are among the best.
https://www.youtube.com/watch?v=rVBaLkjaW8s
1 Like
I care a lot about smooth and responsive input. I’m not sure using fixedUpdate and then interpolating in update can be done in a way that sufficiently satisfies both. I’ll have to look into it, but to me it seems like a tradeoff with no universally right answer.
And I’m 100% sure I’m never touching multiplayer.
Thanks, I’ll take a look. Those look very similar to this one from the humble bundle that we both bought:
https://assetstore.unity.com/packages/templates/systems/easy-character-movement-57985?_ga=2.76601429.1557958792.1607622074-1035445175.1576450274
Really? That’s quite underwhelming, considering it’s not even that hard to solve. I had taken care of that edge case even on my first proper unity project, because I wanted a minigun.
Thanks for caring about such implementation details, way too few indie devs do imho.
1 Like
The sniper zooms in 14x. The look sensitivity wasn’t being decreased by this amount so it appeared to move quicker.
The demo uses Unity’s Input Manager which doesn’t support gamepads very well. I recommend the Unity Input System or Rewired integrations for better gamepad support.
No asset is going to have the exact feature set/gameplay elements that you are looking for out of the box. The key is being able to extend it properly or to create your own.
I never talked about the sniper rifle, I was talking about the assault rifle which has about 2x zoom I’d estimate. Also what you’re describing isn’t the problem I’m describing. I don’t know how to phrase it any more clearly than I already did. If you’re not seeing the behaviour I’m seeing in the build of your demo, then it has a bug that isn’t reproducible on your system, but it is on mine. However since we’re not even talking about the same weapon, I have to suspect you didn’t replicate the test exactly as I described it.
I tried to replicate the test with the sniper rifle and gamepad, and because of the 14x zoom it makes it very hard to perform this test in an objective way. However as far as I can tell it is the only weapon so far that I have tested that has the same sensitivity when zoomed in as when zoomed out. That is still imho a bad default for a sniper rifle with 14x zoom, but not an obvious bug. However with the bow, pistol, assault rifle, and shotgun the sensitivity while aiming is about twice as high as without aiming. That is very easily and objectively measurable by counting the time a full 360 degree turn takes to perform with a gamepad. You don’t need a stopwatch to know whether turning once takes one or two seconds.
Also after spinning that way for a while, I was suddenly no longer able to look around with the right analog stick of the gamepad. The left one for moving was still working fine and after relaunching the demo the right one was working normally again too. There might be another bug hidden somewhere.
I was looking on your forum for other threads related to sensitivity and found this one:
It seems like the look sensitivity in general is dependant on the framerate, and your suggested fix is to lock the framerate - correct? It shouldn’t be dependant on the framerate in the first place in my opinion, because you can’t make the assumption of the player having a stable framerate, and randomly varying look sensitivity is an absolute no-go for an fps.
It may very well be that UFPS is the most feature-complete fps asset on the market, but with design decisions like this it looks like a poor fit for me personally.
Ah, you’re right. I was referring to the sniper rifle. Not the assault rifle. I’m not near the project right now but I’m not sure what preset is being used for smoothing while aiming. In any situation this value is easy to change for your own project with the preset system.
The input is not framerate dependent. Depending on the mode you are using, you can smooth the look vector within FixedUpdate and then use that smoothed look vector.
1 Like