CameraFor2D

Hello everyone,

I'm in the process of doing a 2d platformer engine and as part of that project I needed a good 2d camera system. I was encouraged by some fellow indie developers to make it a full featured asset that could be put up on the asset store for others to enjoy, so while I make progress on the system as documented here, I wanted to solicit some feedback from any would be users of such a 2d camera. What sorts of features would you like to see in a 2d camera that's ideal for your game? So far my feature set list contains:

- Areas that are blocked off via colliders
- Room based camera movement (camera moves when hitting the edge as see in the Zelda series)
- Multiple target focusing, camera points to the mid-point of the group
- Dynamic zooming for multiple targets when they move too far apart to all be on the screen
- Lookahead / lookbehind values
- Momentary "reveal" targets that pan the camera to the target for a moment and then return
- Ability to work on any of the XY / XZ / YZ axes

I'll have a few web player demos up soon to show these modes.

 

I've got the demo posted of the first batch of features.

So far implemented are:
- Areas blocked off by colliders
- One, two, three, and four-way colliders
- Changing targets
- Timed "look at" functionality with configurable travel speeds to and returning from the target

 

intersting one dkoontz ;
i'll try to keep an eye here, iguess i need extra 1000 eye to be tuned with all the good stuff here and there;

is it depending on triggers or what ? to make the one way camera block ?!
m;

 

Yes you set up triggers and then put a script on the GameObject declaring in which directions that collider should be counted as blocking the camera. If you leave the script off, the collider is considered to be blocking all directions.

 

Pretty cool. Good job and keep it up~

 

Love the work you're doing here.

I am prototyping a top-down game for tablets, so I could use a camera with some extra features, such as:

- Ability to zoom the view in/out (with limits) when player does the traditional 2-finger "picture resize" pinching.

- I'm thinking I would like to allow the player to touch and drag on their avatar such that the camera view is offset. In other words, reposition the camera's view of the avatar such that the avatar isn't in the exact center of the screen (again, with limits).

 

I will add a task to make zooming a function of the camera system. There will be a method you can call when you process a pinch/expand gesture to set the zoom value between a minimum and maximum that you've defined.

When you say you can touch and drag on their avatar and have the camera view offset, do you mean that the camera will "look ahead" in the direction the player is facing or moving? If so that feature is what I was referencing above with the "Lookahead / lookbehind values" item so that will definitely be in.

 

Awesome to hear about the zoom.

For the offset, I wasn't specifically referring to "look ahead" (though that would be a good camera option). The "ship" the character will be piloting in my game will actually be rather large, so I am considering allowing the player to drag his view of it to the sides/top/bottom to better see what's around them. The size of the ship is also why I'm interested in the zoom capability (and maybe that will be enough).

Conceptually, it's like the ship is a child of the camera: you touch and drag to give it an offset. The trick is this doesn't change the ship's position in environment, so you're actually moving the camera.

For actually implementing it (just brainstorming here), I imagine it could be set up that if the player touches the ship center and drags one direction, the camera actually moves the other direction. This would give the illusion of dragging the ship off the center of the camera's view. Probably a tap on the ship center would cause the camera to return to the center point.

If you could add this functionality, that would be great - but I certainly understand if it's not something most people will need!

 

Something to consider: there's some cool insight on 2D platformer camera behaviors in Shaun Inman's excellent Super Mario World Camera Logic Review:

 

attilam,

Yes I've seen that review, it is very excellent. That particular video has a lot of very specific functionality relating to a platformer camera system. I will eventually have the same sort of "platform lock" abilities that are shown in the video, but I won't have that ready for the first release of this camera system. My intention was to add on more specific capabilities, like those needed by a platformer, as I develop those systems and have really good test cases. I'm hoping the camera I have here can create all the specifics seen in that video without the need to change much as I think most of what's shown in that video is a matter of decoupling the desired location for the camera from the player, which is quite trivial currently.

 

Backward pieS,

Could you accomplish what you're describing by having the camera target track a GameObject that's not the player but is positioned relative to the player based on the mouse position? This GameObject would of course be restricted in the distance it could move from the center of the ship, as if attached by a string. That plus zoom sounds like it would get you what you want.

 

Another video from Dave Fleming (@Ultima2876) on Twitter. This one is on Insanely Twisted Shadow Planet's camera. The current camera supports all of what's in that video except the nice soft ease-out when arriving at the target. I'm going to put in a new section for the demo showing off the "point of interest camera" type effect though.

 

Very cool camera system. Also: debug visualizations rule!

 

I think my case is a little trickier because I'm going for a touchscreen interface. In my previous suggestion, I began by assuming the ship would have a camera target as a child, and dragging on the ship would offset that child. Then I thought I'd "cut out the middle-man" by just making the camera a child of the ship.

But maybe it's better to not have the camera be a child of the ship, because techniques like panning the camera away to show the player something will probably be easier if the camera is not directly linked to the ship in the hierarchy.

 

So as I've been discussing various needs with people it seems that most of the game specific bits are all wrapped up in how the camera's target moves. So I'm going to concentrate on doing some helper scripts to move the camera target around in a similar fashion to what ISTP is doing. I have a few things like that now, but I think it's worth doing a slightly more comprehensive set of helper scripts to accomplish a few common control schemes such as a twin stick shooter, a top-down or side view racing game, and eventually lots of helpers to make a Super Mario World level of control over the camera.

 

Backward pieS,

For your zooming, are you going to zoom a discreet amount (actual world distance if perspective, camera size if ortho) or would you want to zoom a percentage of your initial zoom?

 

That's a good question. I've been prototyping the 2D game I mentioned above, and am using a perspective camera looking down on the xz plane (in which the game play takes place). I'm working on the assumption that I would base the camera zoom positions in relation to that game plane (maybe by getting the distance of a ray cast from the camera to that plane, if the camera is slightly angled).

Zooming in terms of percentages seems like the most robust, since it would (in theory?) be more removed from the actual scale of the scene than discreet amounts.

But I have a feeling that either case will be fine, and involve some trial-and-error.

 

A new demo with a bunch of new stuff is up.

• Easing for the camera via damping parameter
• Multi-target focusing
• Dynamic zooming
• Point of interest
• Lots of bugfixes and tweaks

There are still a few bits to be added but I'm basically ready to call it good on a 1.0 version for the Asset Store which I'll be submitting tomorrow. I'll continue to respond to feature requests and of course fix bugs that are discovered over the next few weeks but if there's some important bit missing for your use case, please chime in here.

Also tomorrow I'll be recording a video showing off how you can tweak various parameters to get different effects.

 

feels good,

things i noticed:
-is vsync enabled? there is a hickup for me every once in a while

-zooming out on your multiple-camera-target-mode jitters a bit. A wild guess would be that you check the positions on the screen AFTER you modify the size(orthogonal zoom) of the camera (making the camera using the values of last frame) while the camera-position is modified in LateUpdate, but i am not sure about that
--you can get rid of that completely, try LateUpdate when applying the ortho-size, i assume you are doing it already for the player-follow which is perfectly smooth.

-nice lava background. is it procedural :F ?

-i think zooming in percentage is much nicer, the discreet zoom may only be worthwhile in a fully block-environment when you want a specific amount of block in the viewport
-you can also go for hybrid and clamp the zoom to specific values, e.g {20, 24, 29, 35...} blocks of orthogonal size

-i used procentual zoom in my little game if you want to try it out (mousewheel zooms manually)

 

Three things I noticed:

1. When panning to an object of interest (and back), the camera doesn't move directly to the target point, instead it seems to move the same speed vertically as horizontally, and you inevitably hit the end of movement for one before the other. Maybe that's intended, and for some cases even desired, but I would like to also be able to move in a direct line to the target point.

2. The point-of-interest focusing, while really cool, seemed a bit jerky. Maybe related to what Marrt was talking about above?

3. I really like the multi-target focusing, but the transition when returning to just the player seemed like it could be smoother(?).

Nevertheless, there are some really cool things going on here.

 

Yes it was, but I've turned off vsync now.

There was an expensive operation going on to recalculate the screen's bounds for collision checks with camera bumpers going on. Since it's a pretty bad idea to zoom out right next to an area with bumpers anyway, I've made the recalculation optional, so now my example script only calls it when the zooming is complete which drops the CPU utilization quite a bit. I still seem some artifacts which I will try to get to the bottom of. Also, I'm doing everything in LateUpdate already so there shouldn't be an ordering issue.

It's the Electric Liquid material from the free Substance pack on the asset store. In fact all the materials in that scene are substances from that pack.

 

This is an artifact of how Mathf.SmoothDamp does its interpolation. I was going to look into exposing an AnimationCurve instead of using the SmoothDamp method which would allow me to move in a straight line. If that fails there are some tricks I could do to move along the straight line path incrementally instead of just jumping to the final target. I've added this to my todo list.

So the camera in that demo has a really high move speed to "zelda room" style movement. I've added some colliders to lower that speed when moving down in the free camera area which should make that effect be much smoother.

Yeah I've noticed that as well. I think it's partly because of the very high move speed I already mentioned. Raising the damping a bit and lowering the move speed should make that much smoother.

Thanks for all the feedback.

 

Ok, so new demo, new documentation PDF and best of all, the CameraFor2D is released in the asset store. http://u3d.as/content/david-koontz/camera-for2d

Thanks to Unity3D for featuring it!

 

i bought this yesterday . In your video you mention a button were you can choose the axis it works on ..i feel a bit cheated because ..the XY axis is not working.. i see you //'ed it out in the script and i dont think its even finished yet.. ive been trying to edit it myself to make it work on the XY axis but im not very skilled hence why Ipurchased a camera script in the first place. I'll hold off on rating and reviewing this in the asset store if you can fix these problems ASAP

 

Hi slooie2,

So sorry for that. Yes it does seem that I neglected to put back in the code for the XY and YZ axes. I've corrected that now and sent you the file via private message. I'm submitting an updated version of the asset to the asset store so if anyone else is having this issue you should see the updated version shortly.

 

Hello, great looking plugin!

I was wondering though, is it possible to offset the screen a bit so I can place a GUI at the top of the screen (or side, maybe?). For example, the first Zelda game on the NES has a black GUI at the top of the screen, and the game on the bottom. But in your plugin, it looks like the character has to be centered all times, and adding a GUI at the top would make the game screen off centered... does this make sense?

Looking forward to your response, thanks!

 

gregmax17,

Yes what you are looking to do is quite possible. The solution that comes first to mind is to have 2 cameras, each that render part of the screen. This is accomplished via the not-very-often-touched "Normalized View Port Rect" section on the camera. I have an example scene that demonstrates this that will be part of the next update but I'll explain here so you can keep moving on your project.

What I set up was my main camera with these settings:

X:0, Y:0, W:1, H:0.8

And then a second camera that renders the fixed GUI area.

X: 0, Y:0.8, W:1, H:0.2

This should give you the 2 sections you're looking for.

 

thanks for the quick fix!

 

No problem slooie2, let me know if you encounter any further problems or have requests for future functionality.

 

Any chance for 3.5 support? Would love to pick this up but am using Unity 3.5 still.

 

I will get an copy of 3.5 installed and look into what it would take. Do you know of specific issues you're experiencing with 3.5 not working?

 

Instead of zooming in and out could it simply pan and or stop to fit lets say 4 players moving at once, while limiting an axis as which the camera moves?

This is great by the way!

 

Just wanted to say this is great! Keep it up.

 

I just can't download/purchase it from the asset store unless it was built in 3.5. So it might work fine with 3.5 right out of the box for all I know? Thanks for looking into it.

 

Glad that it find a way to AS. good luck pal

M;

 

The zooming is not a required thing, that is under your control. If you want the camera to just move to the centerpoint of multiple objects, you just add them as your current target and it will pan. I'm not sure I understand your comment regarding limiting an axis on which the camera moves. Currently the camera is already limited based on the axis you set for it (XZ, XY, or YZ). If that's not what you're asking about, could you please provide me with an example of what you're trying to accomplish? Thanks.

 

I was totally unaware of that limitation. I will need to ask the asset store people about that as I don't see any way to have 3.5 and 4.x versions uploaded and I don't want the opposite problem of all the 4.x people not being able to purchase it.

 

I ended up putting 4.1 on my PC and purchasing CameraFor2D. I then sent the package over to my computer running 3.5 and tried to import the package. Got a very strange error and caused Unity to crash. I'm sure there is a work around for it I just didn't give more then 5 minutes trying to mess with it. I appreciate you trying to get it to work for us 3.5 scrubs =)

 

Thanks for the answer!
I looked up the video and found my answer in there.( I probably should have done that first than waste a post here ) I managed to fiddle with the parameters and made it fit with what i needed!

 

Ok so it seems to work ok in 3.5, but you're not going to be able to import any of the scenes as those are Unity 4 format. What I did was copy the Scripts directory and the Example/Goodstuff directory to my 3.5 project. The Goodstuff directory not being in Scripts is actually an oversight on my part that will be corrected in the next release. Once those are in your project, you have everything you need. You can of course also bring over any additional scripts from the Example directory if they are useful for you.

 

And of course I spoke too soon. Examples/Scripts/EnableObjectsWhenTouched.cs uses the new Unity 4 method SetActive which will need to be converted into active =. That seems to be the only syntax change that is needed though.

 

Great Ill give it a go as soon as I get a chance. Thanks again for looking into it.

 

This is AMAZING THIS IS EXACTLY WHAT I NEED!!!!! http://forum.unity3d.com/threads/171512-2D-Camera-Follow-help using the collides to block off the camera!!!!

 

On second thought, do you think this asset would be appropriate dktoonz? check annihlator's comment

http://forum.unity3d.com/threads/171512-2D-Camera-Follow-help

i plan on using it to create bounds where the camera cannot go.

Thanks charlie.

 

Are there any known problems with the camera following a rigidbody? I am trying to set it up for a platformer but notice that it is very jittery if I allow any damping at all. I have had problems with other camera scripts when trying to follow rigidbodies too so I just wanted to ask. Otherwise the system is working great for me!

 

If I understand what you're doing, you want to be able to keep the camera centered on the player, but do some sort of easing to follow the player so that jumping does not immediately move the camera up (or simply make the camera not move vertically at all). That is not provided out of the box but is certainly doable with a little bit of scripting. I am planning to very soon add an area you can define around your target that you can move in without causing the camera to move. You could make this area very narrow horizontally but large vertically, which would give the effect you're describing where the camera tracks horizontally but not vertically. I expect to have this "Move Box" feature in the next update, sometime next week. Another simple way to accomplish this is to set the target of your camera to a GameObject that every LateUpdate sets its x position to the player's x position but doesn't modify the y or z. The camera would then never move up or down as the target object would not be moving on the y axis.

 

I just tested by adding a rigidbody to the "Player 1" object in the example scene and it seems to work fine with a damping of 0.3. I'm also using the camera in a few of my projects where I have rigidbodies being tracked and have not experienced this issue. Is the jitter constant or only when moving / colliding? If you could give me some more details I can try to see if I can recreate the problem, or best yet would be to see an example scene demonstrating the issue.

 

Thanks dkoontz i will buy it anyway as it seems like a great asset!

 

The Box thing sounds perfect

 

Any performance hit? It looks like you are using iTween for moving the camera which has had a major impact for me before.