Where are the good first person controller assets for Unity?

I'm looking for a first person controller that is on the level of a proper big budget immersive sim like Dishonored 2. Example video:

I have searched for a bit and can't find anything that comes close. In general it seems harder than it should be to find any kind of comprehensive comparison between the different available FP controllers. UFPS comes up a lot, but after trying its demo I'm not confident that this is the answer that I'm looking for. To me it still has that "Unity feel" that I'm trying to avoid. However I can not confidently say that this is a fault of the technical implementation of UFPS and not just a problem of the artistic implementation - tweaking all the exposed parameters to get the behaviour I'm looking for.

Are there any assets that might be closer to what I'm looking for, or is this something that simply does not exist on the assetstore? And if so, why?

Also has Unity ever improved on their old first person controller? During my search I stumbled over this article:
http://nothkedev.blogspot.com/2017/11/how-to-cope-with-standard-unity-fps.html

To be honest I don't expect they ever made anything better available, but I'd be happy to be proven wrong.


I once had found a fairly good physics driven first person controller on github, but I can't find it anymore .

There's probably a gem or two hidden on github among tons of solutions that don't do what I'm looking for, and if possible I'd like to avoid trying them out one by one. Any recommendations?

 

I can recommend a programmer who does custom work, works at very reasonable price, and specializes in making controllers like this.

I imagine doing very detailed work to sell on the store is simply a waste of time. Need wide distribution to make up for devalued work from over-competition.

 

I believe you'd need a custom solution, if we're bringing dishonored here. I may be wrong, however.

Basically, Dishonored does not match standard run of the mill FPS controlller, due to all the magical powers. Hence it would need to be custom.

 

Hi there, https://assetstore.unity.com/packages/3d/props/weapons/low-poly-fps-pack-free-sample-144839
is really good for starting, if you don't mind the cartoon looks,you can change the models up yourself

 

I tried the first person controller from the standard assets again. Wow... the worst of all I've tried today.

I found it again but it isn't quite as good as I remembered. Only in comparison to the standard assets does it shine. And I immediately found a hilarious bug - when you turn mid jump, your trajectory rotates with your view direction x].

Thanks! I don't want to hire anyone, but I'll keep it in mind. I'm pretty sure I'd be able to do this myself but it has a pretty big timesink potential I think. If there is a really good finished solution that I can buy it just makes no sense to do this myself.

I don't need the fancy powers, I just picked it as a quick example for a reasonably smooth and responsive implementation of walk, run, jump, high jump, climb, crouch, crouch under, slide, lean and the many necessary micro tweaks needed to make it feel "good". I find it hard to believe that no one ever thought "hey, lets polish a first person controller like the pros do it!". But so far I haven't seen anything close to that.

Hi and thanks! I tried it, but this one is too bare bones.




I also tried the demo of this:
https://assetstore.unity.com/packages/templates/systems/fps-builder-167252

The jump is weird and I dislike a bunch of other things, but I at least see an intention of polish. Maybe this would be closer with properly tweaked parameters on the controller component? It's a shame I'd have to download over 3 gig just to find out if I can tweak the right parameters there.


And this one:
https://assetstore.unity.com/packages/templates/systems/easy-character-movement-57985

I liked the jump but some other things don't work for me.


And the Unity FPS Microgame:
https://assetstore.unity.com/packages/templates/fps-microgame-156015

Imho it's much better than the one from the old standard assets. But still too simple and unpolished for what I'm going for.

 

@TwiiK: I just noticed you reviewed that FPS builder. Did you end up using it? How did you like it?

 

The thing is that a lot of this is still game specific. It has to be tuned for things such as "what is the standard corridor width in our game?" and "what kind of movements to players want or need to regularly make?" and "what is a good balance between responsiveness and smoothness for our use cases?" This is an iterative process over the course of a game's development and design. It's not something that a programmer wraps up early on in a project, and for that reason it's also not something that can be got off a shelf without significant tweakability, which also increases the complexity and may in fact make it harder to polish.

 

This is such a core part of a FPS I wouldn't outsource it to the asset store. Probebly one of the last things I would outsource actually.

 

That is of course true, but while tweaking towards the game's requirements will of course always be required, I still think there are some "archetypical" controller types that could cover a lot of ground. E.g. one like Q3 for retro and arena shooters, one like COD for your average FPS, and a more agile parcour controller. I don't see how this would be inherently impractical as off-the-shelf solution in many cases, but on the other hand I see tons of devs not putting in the work to roll a really good custom solution.

Out of curiosity what's the most polished "modern" first person controller in a Unity game that you know?

 

Well, with the quality of the stuff I've seen on there so far, I wouldn't either! But if I could find one that makes me say "yeah, that's what I had in mind", then it would be a considerable time-saver.

 

Standard first person functionality functionality is "walk, run, jump and shoot". And that's it.

Crouch is a fairly common feature.
"Climb ladders by walking" is common.
"Climb ladders with hands" is uncommon (because it requires body or at least animations).
"Climb over ledges" is uncommon.
Slide and high jump are uncommon.
Lean is very rare.
"First person martial arts" is rare.

There are even less frequently used things like "crawl" or "mouse aim without turning body".

Then there are games with first person body.

And that's why they aren't part of a standard asset. They aren't a part of every game and accounting for them makes the asset more complicated.

You'll need to create a list of things you want and then make something custom and spend time polishing it.

 

Even if you find one that feels good it might be a horrible Spagetti. Which means tweaking it and integrating it will be a pain.

We went custom controller from day one. VR game though

 

Probably for prototyping, I just can't imagine them being used much past that. Heck, I was messing around with a simple FPS a couple of years ago and even for a one weekend muck about project I still wrote my own controller rather than use an off-the-shelf one.

And it didn't take long at all, which could be why people aren't selling them? For the simple cases it's super easy for people who understand transforms, physics and raycasting. For the complicated cases it has to get game specific pretty early on.

When I say "game specific" keep in mind that it works both ways. You mentioned parkour, let me raise a simpler case: a ladder. How does the controller know that it has to change into ladder mode? How does it know the orientation of the ladder? If animated, how does it know where to place its hands?

What about doors? Do doors in my game open automatically? Do I have to "use" them? Do I need to be in a trigger and then get a button press, or is it raycast based?

These are all easy questions to answer, but the answers will be game specific and have a flow-on effect to the rest of the game and (just as importantly) the workflows used to construct it. Asset store solutions tend to take the kitchen sink approach, which means that they come with assumed answers to a lot of this kind of thing or significantly increase complexity in order to provide that kind of flexibility. That kind of baggage is likely to cost far more on a complex project than having one of the coders write what we need in the first place.

I don't recall playing any Unity-based first person games, so I can't say.

 

I agree that many of the FPS assets on the store have demos that feel a bit clunky, but I think it's likely the difference is mostly in the settings. I can't guarantee it, but the chances of finding exactly the feel that you want in a demo is low.

My advice would be to try to figure out exactly what the technical issue is, by grabbing a couple of free or cheaper ones and trying to tweak them until they either work properly or you can see what the issue is.

That might help you figure out the right questions to ask the devs of more expensive, feature-complete assets, or at least to know what to tell someone if you do end up hiring.

Otherwise it's very difficult to define the problem.

 

Thanks for the replies guys! Seems like there is a strong consensus that looking for a really good solution on the assetstore is a waste of time. Since that's the case I'll gladly stop this tiring search.
I think I'll download FPS builder to see how they did a couple of things, since it came the closest so far, and then I'll start from scratch with my own solution.

 

@Martin_H Yeah, it was included with a Humble bundle I bought a while back. I reviewed it because it was the first properly good "template" asset I've seen on the Asset Store and I felt that deserved a mention. By that I mean it's an asset that I would actually consider building a game around, which can't be said for most similar assets on the Asset Store which I feel just pile on unfinished and barely working features willy-nilly on an already shaky foundation by trying to cater to the wishes of buyers with no real interest in writing code of their own or making an actual game, but instead just want to play with the asset they've bought. The end result just becomes this convoluted mess of barely working features and functionality where nothing feels good or how you'd expect. With that said this asset is fairly new so for all I know it could be heading down the same path, but at least for the time being I think it seems really well made.

I'm not using the asset for my project though so you should take what I say with a grain of salt. My project requires a character controller and animations that are so custom that I doubt any asset will fit my needs, but I and am using features from the asset in my project and I've spent quite a bit of time deconstructing the asset looking for other things to take inspiration from. The surfaces/decals systems for example I think is excellent and I'm using that in my own project and I probably will use that for other projects as well because it's basically plug & play. I was able to just cut and paste it and use it within 15 minutes. If it had been any other asset I feel it either would not have been good enough to warrant using or it would have been so intermingled with all the other functionality in the asset that it wasn't possible to cut it out without bringing everything else. I'm also looking at the weapon system and the character controller for inspiration as well as the cool usages of editor scripts and scriptable objects. As well as overall project structure. Everything feels very clean and organized.

If my game was a more conventional FPS like Battlefield or Call of Duty then I would most likely use this entire asset as a starting point because it does a lot of what you need and it does it rather well. The asset feels somewhat comparable to those games right out of the box and not just like some wonky developer prototype. I mean if the asset developer isn't able to make something that feels passable then why should it be expected that the asset is even able to get there? I don't care that the asset allows for swimming, climbing ropes, riding bikes, driving cars or going to the moon if walking and shooting doesn't feel proper to begin with. Adding features to a game isn't hard, making them feel good is hard. In this asset the fundamental systems feel quite good and I feel with some time and effort you would be able to make them feel exactly how you want.

I also joined the Discord server for the asset and the developer seems like a very knowledgeable guy. There are a lot of cool new stuff in the works for the asset. But it's currently just that one guy though and he doesn't have all the time in the world to work on the asset so that's worth mentioning, I guess. And like the rest of us he's struggling with Unity's SRP decisions.

And I of course understand why all these other asset developers do things the way they do it because they obviously sell really well, but I doubt many, if any, actual games are made using those assets.

 

That guy who was making the Gravity game in feedback friday awhile back had a nice feeling controller to me. I played a lot of FPS's over the years and usually I think simple is the best. Direct input, usually "physics" just makes it feel cumbersome to me.

As example, Tarkov is cool game but I don't enjoy shooting in it because it's difficult. CounterStrike is easy to move quick, precise, and intuitive. I just guessing but I bet counterstrike probably has a simpler setup. (and please, nobody tell me Tarkov is more "realistic")

 

If character needs to interact with physical objects in the world like pushing them aside you need physics enabled controller

 

Have you looked at Opsive's Ultimate Character Controller? It supports both first and third person operation, including the ability to toggle between them. It's modular, has decent document, and includes examples on how to make your own custom behaviors to plug into it for things like advanced Parkour. It has existing modules which already implement a lot of the parkour functionality you might need. You can purchase supplemental motion capture animation sets from other people on the store and mod them into your UCC implementation. It's not going to be a "one and done" sort of thing where you just buy it and plug it in and it does everything you want, but it should get you 80% - 90% of the way there. The remaining parts you will have to fill in with your own custom modules for it.

I am currently using it for my own characters and have plugged it into Final IK and Puppetmaster for advanced inverse-kinematic and ragdoll interactions with the environment. I have several other animation sets I've purchased to integrate into it, but have not yet gotten that far into the character controller construction yet.

That being said, I am currently working on an ECS conversion of my game given how long it will be before I am ready to publish it. Unity has a new ECS-based motion matching character controller system they are working on. I'm mulling over the idea of switching to that and going straight to a custom implemented character controller based on that system with Final IK and Puppetmaster layered on top of it.

 

One tip, you can also try and modify some TPS controllers, so that the camera is placed in the head position, this way you get the animation based movements and also you can then see the body. Only thing is that you need the head to be detachable then, so that you can disable it, otherwise you'd see the teeth and insides of the model at some point...
Just an idea if you want to go an extra mile.

 

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

 

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.

 

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.

 

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.

 

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.

 

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.

 

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.

 

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/packag...9.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.

 

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:

https://www.opsive.com/forum/index....w-in-editor-works-fine-in-built-version.4557/

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.

 

So you are looking for an asset made by usually one guy to magically do the quality work of a huge team with decades of experience on a big budget? ...

 

It's at least what I've concluded with based on my own experience and what I've seen elsewhere outside of Unity. Basically if you design your game as if it was multiplayer you'll end up with a more solid foundation regardless if you intend to make it multiplayer or not. Multiplayer, online at least, highlights a lot of flaws with common design practices. And competitive multiplayer games gets scrutinized down to the smallest detail so they need to ensure things are done correctly.

But ultimately it's about where to put your resources as a developer. I'm just talking about what I feel goes into making stuff the way it ideally should be made.

That one is physics based. I looked at that one, but it wasn't interesting to me. It's maybe a good one if you want a physics based character controller, but in my opinion you should handle your own collision logic for your character controller unless you for some specific gameplay reason want it to be physics based and then I'm thinking games like Human Fall Flat or Gang Beasts, any other game I wouldn't want to rely on the physics engine for collision logic because it could and probably would lead to unforeseen results. The Kinematic character controller and the other one I linked handles their own collision logic. They only have a collider for bounds checking etc. They also have a rigidbody attached, but it's set to be kinematic, meaning it's not affected by physics. I've always read that you need a rigidbody attached to a moving collider in Unity, otherwise you'll endure a performance overhead, which is surely why they have it there, but I'm not sure that's the case anymore.

But there's of course pros/cons with everything of course and it's up to the developer to decide. The above character controller will interact with physics objects by default. A kinematic character controller you have to code every interaction yourself.

I misspoke last time. Unity's own examples, and I assume how you've solved it in your project work fine independently of framerate if getting the correct amount of bullets out is the only thing that matters, but what's essential to competitive shooters, and in my opinion in general if you care about things being consistent is ensuring that the same amount of bullets are spawned in the same amount of time independent of framerate, ie. ensuring the damage per second of your guns remains consistent. This is an issue that both PUBG and Fortnite dealt with not too long ago because neither of them handled this correctly either.

If I have a gun that shoots 10 bullets per second and my shooting logic is based around spawning 0-1 bullets per frame then those 10 bullets will be spawned quicker/slower depending on the framerate. Of course in a competitive multiplayer game this is unacceptable, but I feel it isn't any less so in a singleplayer game, it's just most players probably won't care or notice because such games are under way less scrutiny, and again it's a question about where to put your resources as a developer.

I wasn't assuming anything. I told you that ignoring a fact doesn't make it any less true. As a developer if you pretend you have control over the end user's framerate then you're doing it wrong. That's a fact. Ultimately it may not affect your game, but that doesn't make it any less wrong.

And I have no idea who you are or what your game is so I certainly wasn't talking about that. I was talking in general. You may handle this correctly in your game for all I know, but based on what you've said I now assume you don't. I've yet to see anyone do this correctly in a Unity project that I've seen the code for, and like I wrote further up major developers often don't do this correctly either, in fact inconsistency across framerates is a very common sight, even in AAA games. And I have to assume that they are very aware of what they were doing and why they are doing it, but as a PC gamer primarily when I see games with locked framerates due to framerate dependent logic I can't help but think the developers of said games are incompetent, even if the ultimate reason for this decision was financial and out of their hands.

Bottom line: If you assume the the game is going to run at a specific framerate and design it so that it doesn't behave consistently if the framerate changes, that's wrong. That's a fact. Not an assumption or attack on you or your game.

And like I wrote further up I misspoke last time. The problem with the naive implementation is ensuring that the bullets (damage) per second remains consistent independent of framerate, not ensuring that you spawn the correct number of bullets.

 

A VR game is designed never to drop below target framerate becasue if it does it will start to make the player sick. That said we don't assume we can keep framerate, we even out the firerate between shots to accommodate for change in framerate.

I did talk about that in last post but you seem to ignore that.

 

https://matthew-isidore.ovh/unity-tutorial-full-body-fps-controller-part-2-upperbody-ik/

here is a really good tutorial on how to get a full body FPS working

 

It is enough to take any TPS asset, attach the camera to the head and the true FPS is almost ready. Of course, a lot more polish will be needed, like FinalIK to handle head shake and new walking and aiming mechanics. But you can take any TPS template as a basis.

If we talk about ready-made solutions, then I recently came across an HQ FPS Template. It looks like AAA. The developer has a lot of plans: to climb and swim like in Far Cry 5, body view, grabbing, inventory like Escape from Tarkov, etc. Let's see how diegetically all this will look. I don't know if he plans to add a real body or if it will be just an illusion in the form of a separate legs model, which can be seen from the first person.

But is it really that important for the player? Rather, it is important to me as a developer, because it is easier for me to animate 1 human model and use it for both the first person player and the characters. If the game has a lot of interactions with the environment and parkour, it is also easier to have one character model without dividing it into first and third person.

 

I had to work with UFPS a couple of years ago. It is a layer hog. I was perplexed why this is considered a top asset. Navigation and camera were clunky and unintuitive to my sorry butt. Overwriting layers already in place was a royal pain. Is the expectation here that you can add this to a game that is in development or rather you start with this asset and build a game around it's mechanic and layer hogging.

 

Yer controller for two hands is not that impressive. You couldn't even bother locking your NPC's feet to the ground in your demo video on the Steam store.

 

An FPS controller can be written by a competent programmer that understands dynamics in a day with exposed fields for tweaking behavior..

 

yes and then it takes 12 months to polish it

 

A couple of years ago likely was version 1? UFPS has evolved a lot since then. I'm not sure if you're referring to animator or physics layers but in both cases you are able to customize it for your own project.