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!