Specialization

What’s Specialization?

Specialization is a course we students take during the second half of our second school year at TGA. In this course we’re given the opportunity to lay out a plan and time estimate in an individual project. This course also includes us working on our portfolio and CV.
We’re given 120h in total to work on all of them.

Specialization Reference

My specialization focuses on mimicking the standard movement, camera behaviour and Z-targeting of The Legend of Zelda: Ocarina of Time 3D.

The original OoT (Ocarina of Time) was released in late 1998, and considered by many to be one of the most influential video games of all time as it set the standard for 3rd person action games. I chose the 2011 remake for the 3DS as my reference as it was that version I grew up with and have the easiest access to, and it should have no drastic changes from the original.

In OoT, the player has very minimal direct control of camera. Instead the camera adapts and moves in response to the movement input of the player character. The only control the player has, is that they’re given a ’Focus’ button for Z-targeting. If there’s no entity nearby, the camera repositions to just look straight ahead in the direction the player is facing. If there are entities nearby and within camera view, the ’Focus’ button will instead make the player character face the entity and the camera will reposition to try and keep them both within its frustum.

Features Overview

The main features I will copy from OoT:

Camera Behaviour

Camera will rotate around the player as they move. It will in most cases rotate and try to face the same direction as the player.
When stopping, the camera will after a short delay rotate towards the same direction as the player is facing.
Takes wall collisions into account to never block the view of the player.

Character Control

The controller takes the camera’s orientation into account. So when walking forward, it will always be in relation of the camera view.

Z-Targeting

When pressing and holding in the ’Focus’ button the player will lock in and face a nearby entity.
The camera will adjust to keep both the player and the entity in view simultaneously.
If no entity is nearby, the camera will just face the same direction as the player.

Tools and Help

The engine I developed my specialization in was Bean Engine, our student made engine we developed at TGA. Assets were taken from the Group Project I was working on at the time, Finders Keepers. I was also working on the camera and character controls in that game, so I already had easy access to much of the ground work.

Results

Camera Behaviour and Controls

When the player walks around, the camera will adjust and rotate towards where the player is facing.
Walking straight to the left (or right) will end up with the player walking in a circle. This is intended behaviour as they always walk in correlation to the camera, which itself rotates in a steady speed. It works like this in OoT as well.
As the player stops moving, the camera will after a short delay start to pan behind the player.
An indicator will show up near entities which the player can target onto.

*Circular walking. Indicator appearing and moving towards the targetable entities.*

Z-Targeting

When the player begins to hold down the ’Focus’ button, the camera will enter a Locked-On state.
If no targets are nearby, the camera will position itself behind the player and not rotate. The player character can move in any direction but will only face their initial direction.

*No nearby entities at the start of the lock in.*

If a target is nearby, the camera will behave quite differently.
The camera will adjust its position depending on where the player and the entity are from each other
- When far from each other, the camera will align itself along the player and the entity. As they move closer, the angle will increase. At their closest, the camera will stop perpendicular from them.
- It will always try to keep an angle where the player is closer to the camera, so that they’re never obscured.
- The camera will focus on a position in the middle between the entity and the player. This will keep the player and entity on opposite sides of the screen.
- The side the camera is on depends where it was in proportion to the player when it entered Locked-On state.
- While the camera rotates with the player around the entity, the player can rotate faster when close enough to the entiry. If the player manages to rotate to the other side of the entity in correlation to the camera, the camera will adapt and stay on this new side instead.
The player character will rotate to face the target constantly while the ’Focus’ button is held down.
If the player lets go of the ’Focus’ button, or the distance between the player and the entity grow too wide, the player will return to normal behavior.

*Stationary target lock-in. Camera flips which side of the player is on.*

*Camera becoming more perpendicular as the player move closer, and less so when they move away.*

If two targets are nearby, the camera will prioritize and lock on to the closest. The indicator will then move and display over the second closest.
- If the player let’s go of the ’Focus’ button, then quickly tries to lock on again, the camera will instead lock the second target.
- There is a system in place which prevents the player from locking onto the same target too close upon exiting.
- This is to ensure it being easier to lock onto a certain target when multiple entities are nearby.

Camera Collision

When walking up to a wall, the camera pans upwards and rotates to look down on the player. This way the player won’t be obscured nor will the camera clip into their head if they’re too close.
Walking around a corner or infront of a wall will snap the camera to the other side of the wall.
If the camera collides with a wall while it rotates in idle, the rotation will stop, just like in OoT.
If the player walks around a corner hugging a wall (in direction from the camera), the camera will snap above the player. This can lead to jarring visuals. The camera behaves this way in OoT as well, but that game mainly handles it by having open areas where the player moves around.
How the camera behaves while Z-target will be discussed further below.
In general, I’d allow a small amount of camera clipping. As long as it wawn’t too noticable and the player didn’t end up obscured.

Issues I Ran Into

Collision while Z-Targeting

An issue I ran into when implementing Z-targeting was handling the collision with the terrain.

I wanted to keep both the player and the target in the frame at the same time. However, if any terrain got in the way, the camera would clip inside the wall quite a bit, potentially allowing a player to see the rest of the map. If I would’ve shortened the distance of the camera from either target, one of the would fall out of view. OoT solved this by having very open levels and rooms, so this issue is barely noticable for the most part. What to do?

I implemented check to see if the camera would clip into a wall in it’s current destination it’s rotating towards. If that would’ve happened, another check will occur to see if the camera would’ve collided if it were positioned on the opposite side of the player. If the second check doesn’t collide, the camera will rotate to that side instead. If it does end up colliding there as well, the camera will position itself behind the player, almost similar to Z-targeting without any target.
The camera may clip while rotating to it’s desired destination, as it is for only a few frames. Also the camera may clip a bit into the wall 0.5m at it’s desired destination, as this amount is small enough to make it hard to see the rest of the level while still minimizing the amount of times both checks may fail.

Postmortem

Thoughts

Even if there are rooms for improvements, I’m glad with what I’ve achieved.
I noticed towards later half of the development that OoT’s level design often revolves around open rooms and levers, at least where there are targetable enemies. In tighter corridors there are barely any enemies, and those enemies that exist aren’t targetable! This was likely designed to avoid wall clipping behaviours by the camera. This differs from my test scene, where there are targetable entities near a lot of corners and walls. Even if I noticed this earlier, I still would’ve liked a scene where I can try to work around the camera clipping issue.

I’m especially happy with the camera angle system, where the camera pans to be more perpendicular the closer the player is. In a game featuring enemies, this could lead to a cool situation where the camera pans to make you face the enemy head on from a distance. Then when you’re closing in the camera pans to make you face off next to each other, almost streetfight style.

Potential Improvements

Right now if a target moves behind a wall, the player would have a hard time telling where exactly the target is. The indicators are objects existing in the game world scene, and therefore also gets obscured. The right solution would’ve been to turn them into UI elements which are always visible.
Even if I allow a small amount of camera clipping into the walls, it would’ve been nice if there were none at all, at least in areas where the camera may linger.

The camera snapping beyond the walls can be somewhat jarring. A nice interpolation would be prefered.
When moving in tight or labyrinthean areas, it would probably look better if the camera panned above the player to give them a more top-down view. That way the camera wouldn’t clip and snap as much, if at all.
The camera movement could, and should, be smoothed out. So it doesn’t snap as much when it starts and stops moving.
The rotation speed should be based on how aligned the camera is to the player. So if you move forward at a slight angle the camera should barely rotate at all.

Known Issues and Bugs

When you release ’Focus’ then quickly hold in ’Focus’ again, then indicators won’t disappear properly.
If no other targets are nearby, the currently locked-on target shouldn’t be prevented from being locked-on to again immediately.
If you lock on to a target while that camera faces down on that player near a wall, the camera will continue to face down during the lock-on.
If the lock-on ends in certain positions, the camera may end up behind a wall, covering the player.
When lock-on begins, the camera currently snaps to position instead of lerping smoothly.

Future Applications

While this system has much room for improvement, it stands as a working beta version if we want to use this in future projects. For our seventh game project, there where quite a bit of talk regarding third person games without player-input based camera.