UFPS : Ultimate FPS [ RELEASED ]

Hi skorpah,
Check out this post: http://forum.unity3d.com/threads/126886-Ultimate-FPS-Camera-RELEASED?p=942794&viewfull=1#post942794

 

I guess i could mess with it btw, if i remember correctly, i read some where that in the next
Update that will be implemented along with reload function? And if so, is that configureabli with max bullet per clip / max clips
Etc?

and also, when using the modernweapon asset, and i press second mouse button for zoom,
it gets far off, where do i adjust it ?

Thx // skorpah

 

This is correct. Weapons will have current and max ammo. Though since dealing with ammo is slipping outside the scope of this system and I'm trying to keep it game generic, there will be no further "clip logic". The basic ammo support should be seen as a helper feature / placeholder for your game's "real" inventory system, which is likely specific to your particular game design (and maybe your choice of network/database solution, if any). Max clips should be very easy to implement in your own inventory code though.

This is adjusted in the zoom preset (text file). See this post: http://forum.unity3d.com/threads/126886-Ultimate-FPS-Camera-RELEASED?p=996950&viewfull=1#post996950

Cheers

/Cal

 

I bought it, couple of days ago. This script is really awesome! Easy to setup, works great and looks very nice! Thanks!

 

Really interested in the image effect bug fix as I just encountered that myself in a project. Would have to buy it instantly to see how it was solved in that case.

 

Thanks, cram. Glad you like it =)

 

Hey TwiiK,
I just wrapped up all the image effects work today. The build is basically done and I'm working on the docs. Hold on ...

 

Looking forward to version 1.3, you think it'll be up on the asset store before Friday?

 

Not that quick, I'm afraid. I don't want to give an estimation because estimations mostly fail. Though I dare to say days and not weeks. And that it's quite a substantial update. All features + bugfixes are done and the only remaining work is docs and submission.

 

I bought it anyway just to have a look.

2 things I noticed immediately:
- Bullet casings aren't affect by the momentum of the player so if I run to the right the casings now exit the left of the gun
- Setting the timescale really low (pausing the game) breaks everything.

Are there other ways of pausing a Unity game or does this mean you can't pause a game using this at the moment?

Apart from those things it looks really good. The asset seems a bit too complex to put into my existing project, but there's a lot of nice tidbits to learn from here and there.

Edit: Well, it seems you can pause your game without using timescale, but bullet time (slow motion) effects surely require the ability to tweak it?

Another thing I noticed is that if I have my weapon hierarchy like this:
- Weapon (vp_FPSWeapon script)
-- Mesh
--- Gun Body
--- Magazine

Then the gun body and magazine aren't added to the weapon camera layer and won't be rendered properly.

 

Ok, I'll make a note of this.

This is a known issue that will be fixed in a future release. Btw, according to drew's post above, he managed to get it working by setting timescale to .000001.

Yeah it's a real challenge to keep the scope of the asset limited. Even though it's clearly defined ("Ultimate FPS Camera"), I feel most of my users want a fully featured FPS kit so there is gravity towards that. Problem is: the more features you add, the fewer experienced programmers want the asset (it starts overlapping their existing technology). I am trying to keep it as modular as I can though. For example you should be able to use the Bullet class in pretty much any project, and you should be able to easily skip the Shooter class and implement your own shooting logic. I have also tried to make it easy to rip out the Controller for those who may want to implement a rigidbody based controller, or a more deterministic one that doesn't rely on the Unity CharacterController.

As you say, the asset is also valuable because of the sheer amount of tips and trick's I've put into it. The mouse smoothing and acceleration part, for example, was inspired by classic hardcore shooters and took quite some archaeology to get right (most examples I found in the Unity community were incorrectly implemented). So there's some value in that aspect.

Thanks for buying it and thanks for the feedback

/Cal

 

Yeah, that's pretty much it. By all means, this isn't a bad thing if done properly, but it's something I see in a lot of the more popular assets on the asset store. They turn into games you can mod instead of additions for your game. Obviously you know this and it's evident in the code. The reason I bought it was the casing ejections. I tried for some hours getting a proper spin on my bullet casings and then spending a few bucks to see how you do it didn't seem like a bad idea.

It's really fun to play around with all the parameters to see how they affect the camera and the gun.

I've also got 2 small usability improvements. You have vector 3 fields for "Shell Eject Position" and "Muzzle Flash Position". I usually use game objects for that. That way I can position them in my 3d application if I want to, but I also feel it's easier to position them inside Unity as well instead of fiddling with arbitrary positions.

 

The hiearchy issue I reported on the last page looks like just a simple oversight.

This code block (vp_FPSWeapon.cs, line 119):

Code (csharp):

1. // put weapon object in the 'WeaponLayer', so the
2. // weapon camera can render it individually
3. gameObject.layer = vp_Layer.Weapon;
4. foreach (Transform t in transform)
5. {
6.  
7.     // all the children too
8.     t.gameObject.layer = vp_Layer.Weapon;
9.  
10.     // rename transforms at root level, because if the main
11.     // gameobject has transforms with identical names, unity
12.     // will override sync rotations across gameobjects
13.     if (t.parent == transform)
14.         t.name = t.name + "_";
15. }

Should probably read:

Code (csharp):

1. // put weapon object and all its children in the 'WeaponLayer',
2. // so the weapon camera can render it individually
3. Transform[] allChildren = GetComponentsInChildren<Transform>();
4. foreach (Transform t in allChildren)
5. {
6.  
7.     t.gameObject.layer = vp_Layer.Weapon;
8.  
9.     // rename transforms at root level, because if the main
10.     // gameobject has transforms with identical names, unity
11.     // will override sync rotations across gameobjects
12.     if (t.parent == transform)
13.         t.name = t.name + "_";
14. }

foreach (Transform t in transform) returns just the immediate children of transform while GetComponentsInChildren() returns all the children. The weird behavior with that method though is that it returns the parent as well, but in this case that's ok.

 

I just double checked and I used four 0s not five (0.00001). Probably doesn't make any difference since it seems to be a divide by zero error. Which is what gave me the idea to use a really low number that was more or less 0.

 

I wasn't actually using 0 because I read somewhere that it was better to use 0.00001 or similar if you were going to pause because it enabled you to use some time specific functions while your game was paused or something or other.

So I was using 0.00001, but it still crashes. No biggie though.

On an unrelated note, after having fiddled with the code some more I realize that I'm a dolt and that my old way of positioning muzzle flashes and shell ejectors doesn't work because of the different field of views for the main camera and weapon camera. Probably why you did it this way in the first place.

I've gutted this asset so much now that I feel sort of like this:

Warning: Gory scene from Predator 1:
http://youtu.be/CjWVWLTAHaU

Edit: Haha, was really struggling with the whole casing ejection thing. As I changed the field of view of my main camera the ejection position of the shells seemingly changed because of the perspective. I thought that I had to find a way of fixing this, but first went to Battlefield 3 to see how they've fixed it. Apparently they didn't bother. Same issue there as well. If you change the field of view to something big like 120 it looks like the casings spawn in front of the gun, lol. Neat seeing that even massive AAA developers struggle with or even simply ignore small issues like this.

 

Ok, yeah this is likely a good fix for weapon hierarchies with additional children. Noted and I'll look into this for a future release.

 

Haha, no problem... Feedback like this is invaluable for improving the system. Besides, gory scenes from Predator 1 is good for your health.

Yeah, they're human too. Generally in released games, minor bugs and issues are usually well known by the developer but end up postponed in favor of hundreds/thousands of more serious bugs. Anecdote: back in 2001 I was as a technical artist on Battlefield 1942. The technical director always kept a copy of "C++ for Dummies" on his desk, for reference. And he's one of the best game programmers alive

 

Encountered another issue with the dual camera approach. World shadows. How do I get them on my weapon when the weapon camera only renders the weapon itself?

Judging from your last reply and the quality of the asset itself you're probably the best guy to ask on these forums about such things.

 

Well, since the weapon exists in the same world space as the character, it will receive light from the same light sources so that works atleast. I assume you mean hard soft shadows cast from light sources. I haven't looked into lighting issues at all yet but I did a quick test and the weapon will receive shadows cast by itself (see attached image). The problem then is shadows cast by other objects. I'm thinking one could fake it in a few ways by detecting the light/shadow at the location and manipulating the brightness of the weapon. I'll have to do some more research into this. Thanks for the headsup.

Hehe, I'm quite sure that's not the case.

EDIT: What you can also do is set the layer on the weapon to zero (i.e. not using the weapon camera), in which case environment shadows will work fine. You will then have to use other means of preventing the gun from sticking through walls - such as raycasting and moving it back near objects. And you will loose control over weapon FOV, but this can be amended by tweaking its position and simulated by manipulating its z scale when pointed forward.

EDIT 2: Ultimate FPS Camera 1.4 has a weapon retraction feature which solves the problem of weapon sticking through walls. So in summary:

1. Don't use a weapon camera. Use the new Z Scale feature on the weapon instead of weapon FOV.
2. Make sure the layer on the weapon is zero
3. Use the new weapon retraction feature on the vp_FPWeapon to prevent weapons from sticking through walls.

This will allow external object shadows to be cast on weapons.

 

Just a question. But does Ultimate FPS Camera support platforms movements? The basic chracter motor in unity has this feature. I bought this, but cant seem to get it to work with a moving platform.

 

EDIT: See this post.

 

I swapped in the FPSController last night to test it and I have some issues with it.

Firstly it seems dampening affects jump force so if you set dampening to 1 it's almost impossible to jump. I set it to 1 because I didn't like the sliding movement it created.

This doesn't seem to be intentional judging from these lines (vp_FPSController.cs line 82):

Code (csharp):

1. // dampen motor force, but only apply vertical damping
2. // if going up, or jumping will be damped too
3. float motorDamp = (1 + (MotorDamping * m_Delta));
4. m_MotorThrottle.x /= motorDamp;
5. m_MotorThrottle.y = (m_MotorThrottle.y > 0.0f) ? (m_MotorThrottle.y / motorDamp) : m_MotorThrottle.y;
6. m_MotorThrottle.z /= motorDamp;

Secondly, air speed doesn't work how I imagined it would. If you turn it off you can't jump horizontally anymore. I want to be able to jump horizontally, just not be able to affect the trajectory of my character while in the air. Dampening affects this as well so with a low dampening you're able to jump slightly horizontal, but with it set close to 1 the character barely moves when you jump.

My third issue is probably more of a personal preference or a requisite of how this is set up. Acceleration and dampening seems to affect everything from weapon sway to bobbing, or it may be the speed of the controller that's affecting them, but is there a way to limit or stop this from happening? If I set up the bobbing and sway how I like it and then change the acceleration or dampening of the controller to make my character move at a different speed everything else is changed, increased or decreased based on the speed of the controller. Suddenly the effects are too exaggerated or subtle and I need to go over all the parameters again.

Btw, just curious. Do you think it is profitable for you to keep supporting this to such a degree opposed to make something new for the asset store? I'm looking at the release notes and you've added a ton to this after the initial release. Do you see an influx of customers when you release a new version or has it been a constant stream since the initial release?

 

True, not much use for platform movements in a FPS. lol. But there are 'other' uses that the platform feature can be used for.
I give it a shot and check out unitys chracter motor. Thanks!

 

I am definitely going to use this. One question though, does it work on iOS and android?

 

Yeah, I've tried that and from what I've found on the great interweb fixing the sticking through walls thing is possible without 2 cameras, but I'm not sure about the FOV. What do you mean by z scale? Wouldn't you have to freeform scale the weapon to simulate the look of a different FOV?

On a related note if it was possible to do this without 2 cameras and a separate weapon layer then the image effects problem would be automatically fixed as well.

 

Well, the main purpose of using a different FOV (for me atleast) is to prevent long weapons from getting distorted along the z-axis (see the "1999 Internet Café" weapon perspective example in the demo). An old trick to prevent this (without using FOV) is to reduce the z-scale of the weapon, compressing it toward the camera. This is not a geometrical equivalent of changing the FOV but it does the trick very well as long as the weapon is kept pointed forward. Ofcourse, if the weapon is rotated around its y vector it looks ridiculous so this should be a context sensitive logic This is not the method I would have chosen, it's just a tip if you want to go with ditching the weapon cam.

BTW, the raycasting method of moving back the weapon for preventing it to intersect objects was used in Tribes / Torque Game Engine. It has a rather tactile feel to it, if you're OK with the weapon sometimes disappearing out of view.

 

Hi Likos. It's not mobile ready out-of-the-box yet, but plenty of people have used it for mobile projects and it doesn't seem very hard to get it working. See the following discussions:
http://forum.unity3d.com/threads/126886-Ultimate-FPS-Camera-RELEASED?p=921763&viewfull=1#post921763
http://forum.unity3d.com/threads/126886-Ultimate-FPS-Camera-RELEASED?p=934829&viewfull=1#post934829
http://forum.unity3d.com/threads/126886-Ultimate-FPS-Camera-RELEASED?p=941358&viewfull=1#post941358
http://forum.unity3d.com/threads/126886-Ultimate-FPS-Camera-RELEASED?p=946712&viewfull=1#post946712
http://forum.unity3d.com/threads/126886-Ultimate-FPS-Camera-RELEASED?p=947516&viewfull=1#post947516

Cheers

/Cal

 

TwiiK, thanks for testing this so thoroughly. I'm a bit pressed for time and can't take an in depth look at the controller right now but I have saved your notes for the next time I have a look at it. You have some good points, I'm sure.

For Ultimate FPS Camera specifically, the size of the customer base seems to have some relation to the size of the feature set and there is an influx of new buyers for every release. On the other hand, in general I don't think the profit of an asset has a direct relation to the amount of hours spent. I see some small assets in the store that probably do very well.

 

Tried a ton of different setups for the cameras last night and compared them mainly to Battlefield 3 as that is the only first person shooter I currently have installed, as well as the game that's put the most effort into achieving what I'm trying to achieve - extremely enjoyable gunplay.

Battlefield 3 uses two cameras as you can change field of view without it affecting the weapon and the weapon is rendered last on top of everything. It also seems to fake shadow on the weapon. And like I said earlier it also has the problem with shells ejecting from the wrong position if you change the field of view. They don't however have the problems I have with image effects. The vertical field of view for the weapon camera seems to be somewhere around 50 which actually is quite a lot. The weapons in Battlefield 3 look a lot longer than I remembered.

50 is not that far from 65 which is what I'm currently running for my game so I started testing with just a single camera ditching the weapon camera all together. I lose some flexibility with the per weapon field of view and especially the zoomed in / iron sights field of view and I get the weapon sticking through things problem My characters legs and torso is visible if you look down and the weapon is intersecting those as well which seems harder to fix than the sticking through walls issue. This setup feels more robust as far as image effects, shadows, lighting is concerned as it is all being rendered by the same camera, but I don't like the lack of flexibility in terms of field of view and possibly other things you lose when just using a single camera.

These are issues that anyone who has made a FPS has encountered, but I'm having a hard time googling them as nobody seems to refer to this as "cameras" and I'm not proficient enough to translate the various DirectX and similar code snippets I find into something I can apply to Unity.

 

@TwiiK: Very interesting comparison. FYI: I may have mentioned this but the new version (that I hope to ship this week) has a new implementation of weapon cameras. There is only one weapon camera (as opposed to one per weapon) and I have tested all standard Unity Image effects with the system. You can choose to put the image effects on the FPSCamera, in which case only the background will display the effect, or on the new WeaponCamera in which case the weapon + the background will display the effect. The weapon camera is no longer created at runtime; it exists also when the game is not running which means you can configure it however you like.

This new approach will likely still have the issues with shadowing that we discussed, but it will solve most issues with image effects.

 

Does it work with Sun Shafts as well?

I have all my image effects on the weapon camera and they're all full screen effects post effects like tone mapping, color correction etc., but the sun shafts is the only effect that depends on actual geometry blocking the effect and if I put that on the weapon camera it seems only the weapon is able to block the effect as the rest of the geometry is rendered before the effect is processed by the other camera.

Just installed the CryEngine SDK as well as UDK to look at how they're doing it. Haven't managed to peak under the hood yet as I have no idea how you actually get down and dirty with the code in those applications, but I ran through the example demos and ran some console commands and it's pretty much the same setup I saw in Battlefield 3. Except that both UDK and CryEngine seem to either approximate shadows on the weapon very well or they have a way of actually getting the real world shadows onto the first person view model of the weapon. Both used a dual camera approach and CryEngine actually defaults with a 60 vertical FOV for the weapon model, but the weapon models still look nice and beefy.

Currently I'm testing with just a single camera. Sun shafts is just something I'm testing with as I generally don't like that effect in games anyway, but having the weapon properly shadowed can really add to the immersion.

Anyway, a new release is always exciting.

 

Yeah it works, and as far as I can tell it has the limitation you describe, but it looks very cool anyway

Ok, they could be messing with the object's scale as I mentioned.
I must say you're a very driven researcher! =)

 

It comes with the curse of being a perfectionist. I could have dropped this weeks ago and focused on what actually matters like finishing my animations etc., but instead I feel compelled to figure out the best way of actually setting up a first person camera in Unity. I read through all of Cryteks, Valves and Bungies publications last night to see if they mentioned weapon view models or anything similar in any of them, which they didn't.

The worst part is that I feel like I can't even start on other things until I know what I have is better than what I am comparing myself to and when I'm comparing myself to games like Battlefield 3 and Crysis I'm setting myself up for failure.

I'm leaning towards using a single camera. The only big issue would be clipping, but seeing as I'm striving towards realism in this game and that I already have actual physical projectiles spawning from the barrel of the gun putting a collider on the gun would perhaps end up looking good in this case. I could also perhaps add some animations that makes the gun point up and come closer to the player as he approaches a wall. We'll see.

The single thing I want to avoid is that the animations etc. get in the way of the player input. In Battlefield 3 moving around makes you feel like you're a pirate with a peg leg because of how weird all their animations and physics are. And in "ultra-realistic" games like Arma 2 just shooting your gun is a pain in the ass. It doesn't need to be as tight as Quake 3, but it shouldn't be far from it no matter how much physics and animations you add.

That's also something I noticed with the FPSController. If you create sort of a staircase and try to jump up it the character will sort of jerk before each landing and you will have to press the jump button multiple times on each step to get up. I'm thinking it has something to do with the antibunnyjump code, but haven't looked more into it.

I'm spending so much time on this because I want to create a FPS system I can use for any project later on, but I'm starting to realize that you'll have to fake things and limit yourself to get things done in game development so perhaps I will just do what I can to make it as good as I can for this specific project.

With a single camera control over the FOV would be a problem for other projects, but in this I'm not going to allow people to change it and I actually like the look of having 65 vertical FOV for both the weapon and the game.

Either way the spring physics in Ultimate FPS Camera are essential for making this as good as it can be. And even though I have deleted the component preset code I still think you could take that as well as the spring physics code and turn them into their own assets on the asset store. Mostly because a lot of people could use something like that and doesn't know it is included here, but also for those who perhaps know it's in here, but thinks it's interleaved with a lot of other features or doesn't want to pay the full price for just a sub feature of this package. Even the mouse smoothing and timer functionality could be turned into their own assets. There's so much in here for $30.

 

Alright, I'll let Unity sum this up for me



Version 1.3 is a wrap. I'll post here as soon as it's live.

 

AWESOME! Hopefully it'll be up by the time I get home today. Can you post the updates?

 

Sure thing, here's a link to the Release Notes. The Unity review process usually takes between 2-3 days.

 

Aaahh...Hope sometime this Friday then.

 

Looks a complete overhaul.

Almost approaching the point where I can stop working on my game and instead just wait for you to update this package so I can copy what I need.

Sadly that fits me well at the moment as my Unity vacation is over and it's back to web development for the time being.

 

Good news! Ultimate FPS Camera v1.3 has been approved by Unity and is now available on the Asset Store. I'm very excited to ship this and can't wait to see what you guys will do with it. Big thanks to those of you who helped out with bug reports, suggestions and bugfixing!

>> UPDATING? BACKUP AND DELETE YOUR OLD FOLDER FIRST! <<
Do NOT install this version over the previous version of the Ultimate FPS Camera folder! This is a very extensive overhaul of the system. It's more than likely to break your project. If you're close to a deadline you will want to wait. It might be a good idea to first install v1.3 into a clean project and have a look before integrating it into your project.



Ultimate FPS Camera v.1.3 is a major update with many new features, optimizations, bugfixes and system overhauls. This release aims to make it easier to get started with Ultimate FPS Camera, to reduce scripting complexity and add many requested features, helper scripts and special effects for getting up and running quickly with a new FPS. The manual has also been expanded with 14 more pages, explaining new and old concepts in great detail.

Read the Full Release Notes.
Check out the updated Webplayer Demo with some new cool stuff in it (if you don't see anything new, try clearing your web browser cache).

Have fun!

/Cal

 

Pick it apart and use what you want. That's what it's there for

I know how you feel, man ...

 

Ammo, reload and damage handler scripts were exactly what i needed. You just saved me like 300 bucks for not hiring programmer. Thanks.

 

Wow it looks like 1.3 has become more of the well tuned machine I'm looking for with the post effects fix, I'll probably scoop it up tonight after work. Looks like a completely killer deal for the price.

Do elevators work with it now?

Is there much Inspector control over the parameters?
*edit*
just played through the webplayer demo... really impressive. definitely getting it tonight, looks like heaps and heaps of content and tons of flexibility.

 

Hi zerobounds. Great to hear this!

Not yet, I'm afraid.

Oh yeah. Across all scripts there are over 100 parameters exposed to the Inspector.

 

NP

 

No kidding, been waiting for it as well, now I can finally continue my project. The price has been lowered to $20 as well so that's a really good deal, get it while it's hot!

 

So with the new Damage Handler, is it possible to add this component to the player as well?

 

Unfortunately not. See comments regarding this in the "Damage Handler" chapter in the manual. Also, see comments in the vp_FPSPlayer script.

EDIT: There is a chance it will work in Unity 4, by the way. They are redesigning the "SetActiveRecursively" functionality so complex objects like the FPSPlayer will handle external enabling disabling more gracefully.

 

Ah ok, I'll read up on it once I get home and update.

 

Here's the video updated with some of the new explosions and a pistol reload motion (new stuff begins at about 1m 45s) ...

 

How would something like a Lean (left/right) be implemented?