Now that I’m back at university for the year, our AGD (Advanced Games Development) module has kicked in to full swing! In this module I’m working with a large team (13 people) on a single product for the final ICA submission. It’s totally open ended and working with designers, artsist, modellers & animators to create a functioning and hopefully professional quality game prototype is an extremely exciting prospect.
When we first started meeting as a team we really quickly began building some synergy between everyone, and already had a core concept for a game in place from week 1. We’re aiming to create a tight, short demo level for a 3D platformer game, using Unity 5.4. It’s inspired by the likes of Mario 64, Ratchet & Clank and Yooka Laylee, while we’re putting a string emphasis on making sure that the entire package feels incredibly well thought through and put together, with the product’s strength being the quality at finish rather than a USP mechanic never seen in other games.
The team’s initial meeting focused on introductions of each member, as well as discussing subtle but important goals to mantain throughout production, such as equal input from all members and a balanced workload.
From the get-go I pushed the idea of focusing and the most prevalent interactions in-game in the intial weeks. It almost goes without saying that a 3D open-level platformer with poor movement controls or choppy, tough to control or even a shudders static camera is going to have a rough time engaging it’s players.
The designers were eager to begin rough test concepts for the camera controls, while I highlighted my key priorities when implementing to them. First and foremost, I wanted to ensure that the camera never restricted level design or forced the player into a particular position, so freedom was key. Along with this, it’s generally a good polishing touch in a 3D game to have some camera collision to prevent wall clipping.
As our team were set on a platformer, I looked to other modern platformers for inspiration and research.
I implemented a CameraCollisionFrame
class as a member variable of my third person camera script (Along with making use of debug drawing in the scene editor in Unity.) In the update loop of the camera, I used raycasts from each point in the collision frame to the character position in order to check that the view isn’t obstructed. If it is, move forwards until we can see the character:
The resulting camera collision was suitable for most clipping prevention in the game, but obviously unsuitable for smaller more detailed meshes like foliage or high desnity areas, for which I also implemented a transparency layer and memory stack of objects that have been faded, in order to selectively fade back in meshes that no longer obstruct the player. The result was a subtle but important feature in making a fluent, easy-to-control and unobstructing experience when controlling a third person camera. (The demo below was made in a sandbox environment using assets from another project I’m working on!)