Dev Diary: Camera

[76561198207001389]

Hello LEGO Worlds fans...I’m Chris, and I’m a Senior Programmer at TT. I’ve been there for 14 years and for the last 3 or 4 have been working mostly on camera systems. I’m here to explain a bit about how the current camera works, and hopefully find out more about how our EA supporters prefer to use it.

So, cards on the table first – no chase camera is ever 100% finished! There’s always some tricky corner case that goes wrong in any game, because it’s a hard problem to solve. By “corner case” I mean any unusual occurrence, not a literal corner of a room. Although some actual corners are corner cases :)

The camera has a bunch of requirements, some partially contradictory:
• Always show the player’s avatar
• Always show what the player is doing
• Never move unexpectedly
• But always move when the player expects it
• Let the player look around
• But never clip through objects

A “chase camera” literally chases the player’s avatar as they move around the world. This means you can see your avatar and where you’re going 90% of the time, right off the bat, without the player having to make any adjustments. It also minimises camera movement, which is good for motion sickness – if you’re moving around in front of the camera, it will just pan left and right to follow you rather than tracking alongside. This is also helpful to avoid problems with the trickiest part of a tricky problem – COLLISION.

Collision

Every time the camera moves, it might move into a wall. Or something might come between the camera and the player, blocking your view. So the camera needs to scan the immediate area to find all possible obstructions and try to avoid them. This is hard work in a normal game, but in a fully editable landscape it’s particularly challenging.

Here’s what LEGO Worlds looks like to you:
http://steamcommunity.com/sharedfiles/filedetails/?id=482594404

And here’s what the camera code sees of that same scene:
http://steamcommunity.com/sharedfiles/filedetails/?id=482594512

Notice that the camera only cares about a small box containing just the player and the camera. It ignores the rest of the world. Each of those red lines is a column of bricks.

The camera takes two slices through these columns – one horizontal, to detect terrain coming in from the side, and one vertical to detect floors and ceilings. Here’s what those slices look like as a side view and top view:
http://steamcommunity.com/sharedfiles/filedetails/?id=482594818

The cyan lines are the vertical slice, showing the floor and some branches overhead. The red lines are the two tree trunks either side of the camera. That’s all the code needs to know about the surrounding space…now it needs to decide what to do about it.

Avoidance

Let’s continue with the screenshot above as our example. If you run forwards from here, the camera will detect the overhanging branches getting close to the centre of the screen, and rotate away from them – same for the tree trunks if you run sideways. It has to be balanced so the camera doesn’t judder if squeezed from both sides in doorways or narrow tunnels.

So far so good. But what if the player manually rotates the camera towards one of those trees? We can’t move the camera away from the tree trunk, because then we’re refusing to do what the player asked. But we don’t want the tree to block the player’s view, and if it was a steep hillside instead of a tree then following the player’s input would put the camera INSIDE the hill. The only option is to zoom in so that we can rotate past the tree, and then zoom back out once we’re clear of it.

This mostly works well. But I’m sure you’ve all found an awkward corner of a house or a cave where the camera has zoomed in unnecessarily and you’ve ended up looking down on your own head. Fixing these errors while still preserving the correct behaviour is an ongoing balancing act.

As soon as you move your avatar, the camera assumes you’ve finished looking at the view and resumes chasing after the avatar – on the assumption that seeing where you’re going is the most important thing when you’re moving around the world.

There’s also a bunch of special code to handle particular corner cases such as the player stepping off a sheer cliff (the camera has to get directly overhead REALLY fast), walking directly towards the camera, skydiving, vehicles (camera mustn’t try to avoid the vehicle you’re driving) and so on. Sometimes we need to make the camera anticipate movement before it happens - with a ground slam from a great height, for example - otherwise by the time the camera catches up the animation is finished!

Editor

In the editor, the rules are different. You need complete freedom, so we disable collision entirely. If you move the camera underground, we slice away the foreground bricks so that you can see at least partly where you are – but we don’t want the editor to be a shortcut to finding hidden caves! We also slice away the foreground according to the size of the tool you’re using, to try to give you a clear view of what you’re editing. Unfortunately this means that sometimes we slice away too much. This is another ongoing balancing act.

The Brick Building tool has slightly different slice logic since Update 1 – it only slices away the landscape if your view of the crosshair is blocked. This seems to work better, so I’m planning to make that the default behaviour for all tools, as well as making the crosshair more obvious.

Questions and Answers

I’ve read a lot of comments about the camera, and it seems like some of you would prefer the camera to track alongside the moving avatar - preserving the angle you chose, instead of always chasing behind the avatar. So I’m working on an option for that.

Some of you have wondered why you have to hold the right mouse button to move the camera – that’s because the mouse also moves the cursor for point-and-click movement, shooting and menus, and we need to know which one you’re trying to move.

Finally...it wouldn’t be a camera thread without mentioning first-person mode. As the modders amongst you have demonstrated, it’s easy to zoom the camera in extremely close and look around.

But this creates a host of new corner cases – it’s not good enough to give you a first-person camera that you can only use standing still or walking forward. It has to work correctly when you’re strafing, fighting, climbing, shooting, riding creatures or vehicles, building, switching tools, and so on. Some of those are simple technical fixes, others are design challenges – such as how do you climb up an overhanging cliff in first person? We think we’ve solved that with the chase camera, but we’d have to solve it again in first person. And, of course, in first person you'd never see your character or any of the animations, which is a core part of the LEGO games' appeal.

So we are investigating improvements for tight spaces, but whether first person is the right solution remains to be seen.

I hope it’s interesting to see a little of what goes on under the hood. If you still have burning questions, fire away and I’ll answer as many as I can!

[qMeisterp]

I dont mind pressing a key to rotate the camera freely, but the right mouse button also let me jump or deletes a brick, which I do quite often accidentally, so better bind camera to another key with no other use like ctrl.
Also I would like to have keys to rotate the camera around the avatar, like q and e.

Im aware first person mode brings many other problems and is not the best solution for every situation, but please give us both and let us choose which solution works best for everyone individual.

[Left_Corrupted]

Thanks Chris, very usefull topic!
I think you and the team have already created a great game and it only keeps improving. Keep up the good work!

[Aloan]

Awesome information. I believe 1st, at least a 1st person toggle for when we are standing still and want to look around 360 degrees 9say for example) insinde our own house, to admire the interiors, or outside to admire the landscape. That coupled with the "-" key will allow for some great screenshots of the land in 1st person!
Then, if we move (walk) it goes back to 3rd. ;)

[Sirisian]

The third person camera really doesn't work for navigating in tight environments. Having a solid first person mode I think is almost more important than the third person in that regards. People are building cities and houses with complex layouts and the chase camera won't give a good view in those environments. (Even if you coded the best chase camera I mean it won't show you what the player wants to see). Also definitely want to see first person building after the building mechanics are cleaned up a bit.

Also in regards to building, and this is kind of separate from the camera in a way, it's almost better to remove the minifigure from screen. It either gets in the way or you have to awkwardly maneuver the character out of the way to take screenshots. (Need toggles probably later for UI/Character rendering).

Originally posted by TT Chris Payne:

such as how do you climb up an overhanging cliff in first person?

Climbing up an overhanging cliff seems like a small issue especially if first/third is a toggle. Not sure if alt-look would help, but it would be a neat feature. (The ability to move in one direction while looking in another).

[hymn]

Originally posted by TT Chris Payne:

But we don’t want the tree to block the player’s view, and if it was a steep hillside instead of a tree then following the player’s input would put the camera INSIDE the hill. The only option is to zoom in so that we can rotate past the tree, and then zoom back out once we’re clear of it.

Don't you mean the camera dollies in instead of zoom? A zoom doesn't change perspective nor view obstruction. Given the complications camera work faces in an open world I really think a third-person camera is an AI cameraman, Nintendo was smart communicating this aspect by introducing Lakitu in Mario 64 (the koopa in the cloud holding a fishing rod with a camera attached to it). It helped even younger kids understand that a camera in a game is really an NPC trying to figure out what the player wants to see and responding to it.

Interesting info, and thanks a lot for the changes on the building camera, it's a world of difference saving so much time, still occasionally freaks out when copying a selection though.

[76561198207001389]

You're absolutely right hymn, technically that is a dolly. I was trying to minimise the jargon :)

[hymn]

Originally posted by TT Chris Payne:

You're absolutely right hymn, technically that is a dolly. I was trying to minimise the jargon :)

My jargon isn't entirely accurate either. What the camera is doing obviously can't be described in a single camera operation because its focus remains fixed in space when the camera moves along the depth axis and also changes height to avoid objects blocking the frame. To pull off these moves in reality you would need some advanced robotics or it starts looking real jenky.

But back to the camera, I have a confession to make, the very first thing I do when entering the game is disabling depth of field (currently the option doesn't stick after game quit), to me personally it makes the game look like an ugly blurry mess in far too many situations rather than add a photographic quality to the visuals.

In an open world, exactly because we can go anywhere, a substantial amount of time is spent peering into the distance rather than our characters direct proximity. If the effect is meant to remain as strong and enabled by default then I think it needs some work. Maybe dial to a smaller apertures when it's clear that the player is looking into a distance. I'm not sure if pursuing a photographic camera focus is worth it stylistically when the game's lighting isn't trying to match that realism.

Or is this depth of field meant to be the new fog? trying to hide inevitable drawing distance limits.

[Aloan]

Dof, motion blur, bloom and FSAA settings are not being remembered by the game's save settings after restart. There was a Dev who said they are looking into fixing this for the next update!

[Luna Fate]

I understand the difficulties of adding a first person mode (though I still hold out hope that you'll implement one in the future) but how about adding an option to lock the camera position?

For example, angling the camera inside your house, locking the camera position and doing some building in build mode. Maybe at that point usual character movement controls instead move the camera position.

Just a thought!

[Ben Davies]

First of all, Chris, I just wish to thank you for this article. As one of the aforementioned modders of this game (actually, most of TT's games, as well as early LEGO games), I always find these behind the scenes features interesting, especially when they contain in-engine or debug mode screenshots, such is the case here.

During my trawling through LEGO Lord of the Rings, some time ago, I came across a primitive, developer freecam. It was disguised as a little red quad, which lacked physics and any form of collision, and could fly upwards and downwards. (Some footage of the mentioned freecam can be seen in the video here: https://youtu.be/D6ILMzhHx2Q (sorry for the laggy video)) My question to you is how you would evaluate the viability of implementing a freecam to assist us when taking screenshots in the game. Currently, the only thing we have tantamount to a freecam is the build and model mode camera, which doesn't work in tight environments, and cannot be positioned without getting crosshairs in the screenshot. The actually creation of freecam would probably not be too incredibly complicated, as it would esentially require the changing of the 'stick_length', 'stick_height', and 'stick_sphere_radius' all to '0', disabling rendering of the player mesh, and disabling the influence of physics on the invisible mesh (or adding the flying char ability to an unlisted char serving as the camera), as well as applying to the freecam a custom control scheme.

If you need any inspiration as to the ideal freecam, I'd advise you to look no farther than the camera of the Unreal 4 editor, which from my experience, tends to be heavily regarded as the industry standard, controls-wise.

Thanks!

[adrver]

First of all thanks for the detailed information! This gives us the community valuable insight in what you guys do. So more Dev diaries please! :-)

Regarding the camera: I too support the idea of toggleable first person build mode. It makes interior building/exploring so much easier. Don't delete the current camera though, it works great for exteriors.

[The Row]

Focus on the camera? Nice! It was needed. Alot of people have been asking for it and it is nice that it is here for us to read up on.
Some questions I have for this topics is about the first person view and also the way the camera operates, I will start with the last.

Alot of people have a problem with motion sickness ingame, a popular fix for this is window mode, less shaky camera aswell as an fov-option were the player can increase the fov. It sounds like an option like this would be alot of work seeing the way the camera operates, when it comes to things like selecting what blocks needs to be seen throu and things like that, could you tell us about how such an option would work, or if it is even possible to implement with the current system?

Alot of fps games make use of a first person camera (dooh! why else would they be called first person shoters.) But an reacurring trend have been to zoom out to a 3rd person perspective when some actions are taken, such as but not limited to, climbing ladders, pulling leavers and showing short animations here and there, not to mention car/boat/plane segments tend to be 3rd person in alot of the games, or atleast have an option for it to be soo.
You mentioned that the animations is a core part of lego games, and I agree, but could a solution like this be worth considering? That way you would still get to se alot of the animations, but the players would still have the option to navigate in first person. Something that would be really welcomed in some situations. (indoors, when building, and simular situations comes to mind were I personaly would like first person view.)

Best regards.
The Row.

[404_Not_Found]

Having to hold the mouse button to rotate the camera is just awkward. It should rotate the camrea by default, and you should be able to hold a key like ctrl or alt to bring up the cursor to click on things when it's needed since I can't imagine clicking on stuff with the cursor would be used half as much as the camera...

...then again that's a KBM issue and my experience with all the other LEGO games (except lego island obviously) is that they are best played with a controller which is exactly what I'm going to do anyway. ;v

I found this interesting by the way. Obviously it's stuff people who've played games for most of their lives know but it's neat to see it explained from the perspective of someone actually programming it instead of the usual outside ovservations.

[Rockon]

Allow me to direct your attention to an old game called Blockland:

http://store.steampowered.com/app/250340

This game has individual brick building, all possible in first-person, third-person, and free camera modes. I suggest taking a look at how Blockland accomplishes this type of construction and considering how LEGO Worlds could benefit from it.

[Koitenshin]

If you want people to truly take this game seriously, and to enjoy it to the utmost it NEEDS a 1st person camera. Whether you like it or not, at this stage you're competing with Minecraft.

This game has a lot more variety, ceiling to bedrock space, vehicles, weapons, and a lot more systems. Until we can build in first person, it is merely an exploration action game.