Cinematic!

The opening and closing of each level will comprise of a cinematic of the player'sship (this will be explained) arriving and exiting the scene.  In order to do this I needed to establish a workflow for exchanging assets and animation to and from Unity and Maya.  The decision to use Maya for the camera and animation work was made because it would be far more transferable skill-wise and I already know what I'm doing as opposed to working with Unity's built in animation system.


As the introduction to each scene would involve the player's ship falling from the sky and tumbling into the starting position.
I considered simply dropping the the ship from the sky and letting Unity's physics handle it, but it would be too unpredictable with regards to setting up the camera and the player's starting and ending position (especially as my original plan involved launching it at an random angle into the middle of the map).
Due to this I chose to physically simulate the ship falling in Maya, bake the animation, then import into Unity.


The first step was to recreate the terrain used in the level into Maya, there is no direct way of exporting it as a mesh, however you can export the heightmap from Unity and import it into Maya.

world1 terrain heightmap

In Maya, a plane was created with the dimensions of the matching terrain in Unity (about 16k units) and enough subdivisions to allow approximation of the Unity terrain (128x128 was suffice).

Then in the sculpt geometry tool settings the max displacement was set to the terrain's height (2048 units), the heightmap was imported through the Attribute Maps setting.

As the terrain didn't fully reach it's preset height, a minor amount of tweaking the vertical scale was required in order to get it to match the Unity terrain.

The terrain then needs to be reoriented to match the Unity terrain.

The terrain in Maya with wireframe overlaid

The next step was to create the simulation itself.  After deciding on a starting location and making the terrain a passive rigidbody the trick was to drop a proxy of the players ship from the sky and tweak the physical properties of it and the terrain in order to get a satisfactory crash landing.

It was preferable to have the ship already tumbling as it was falling from the sky.  The easiest way to implement this was to simply have the proxy hit something on the way down like this:

The animation of the falling ship is then baked and a joint is created then positioned and parented to the ship object.  The joints animation is then baked.  The joint's animation is will provide the animation for the falling ship within Unity.

After refining the camera movement to give part of it a somewhat hand-held feel the Maya portion of the sequence was pretty much done:

The red box at the end of the sequence is to get the falling ship to stop sliding with a bit of jolt, rather than sliding to a stop or simply disabling the simulation.  It could potentially be replaced with a rock or some other solid object in-game or merely left as a dramatic jolt.

After importing into Unity, the Maya scene is placed in the Unity scene as a Game Object (making sure it is placed at 0,0,0 in world space) and any unnecessary parts deleted, such as any proxy meshes, lights etc.

I have a prefab set up to be placed in each level of the game, which contains all the necessary Game Objects for the game to work, amongst other things this contains cameras set up to be used in cinematics with a Cinematic.cs script attached to parent them to the camera transforms present in the imported Maya scene.  (The script also contains a line to rotate the camera by 270 degrees along the Y axis, as the look axis of cameras appears to differ between Maya and Unity).

There is also another GameController Game Object with a GameController.cs script attached which finds the cameras and also controls which one the player is currently looking through, as well as having variables to adjust the length of the cinematics.  

Here is the cinematic as it appears in-game, with some rudimentary particle effects attached to the falling ship:

One thing I need to change with this is when the camera cuts, at present it uses just one camera that should move instantaneously from the first location to the second location, however it renders a few frames inbetween the two giving that awkward flicker you see.  I'm not entirely sure if I can set it up to move instantly in Unity (it does in Maya), so I'll probably end up using a multiple camera setup.  Which means changing my code.

Perspectivate!

One problem that I have run into on this, and other projects is that of perspective warping on first-person view models.

While not immediately apparent in the above screenshot, the perspective does seem somewhat exaggerated when in motion, and especially with an increased field of view as I intend to have in order to increase the "epicness" of the game:

In order to correct this I scaled down the entire rig and model along the Z axis, toward the camera and the resulting first person viewmodel is this:

As the rig shared it's root node with the camera, scaling the model in this manner allowed the effect of perspective on the viewmodel to be tuned independently of the camera's FoV without any negative side effects.

Another issue with the viewmodel was that it would pass through other objects in the world:

Again, the problem was solved with scaling, as I realised the viewmodel does not need to be to scale with the rest of the scene, only appear the right size to the player.

Then it was a matter of scaling down the viewmodel until it was within the collision bounds for the character controller, as seen here with the scaling for the perspective correction too (yellow capsule represents the character collider):

Standing in the same position, the resulting view is this (Note:  the field of view differs):

One other minor issue with the camera was that when the camera rotated about it's X-Axis (up and down) it did so from the centre of the character controller, rather than the camera itself.  The effect of this was that it appeared as though you were leaning forward when looking down, and leaning up when looking up.

One effect of this problem was being able to lean into objects in the scene as shown here:

This was solved by modifying the MouseLook script to rotate the Y-Axis of the character controller (necessary to control the rotation of the character) and the X-Axis of the camera.  Providing the camera is centred on the character controller, this works out great.
Standing in the same position produces this result:

Another unexpected benefit of this fix is that it makes it a lot easier to judge where your characters feet are when looking at where you're running and jumping to.  Given the platforming aspects this is mightily useful.

Current Version
Excuse the size.  I've been lightmap testing.

The Beginning

Concept.

The concept for this game is based around the requirement to have a strong focus on visual content as opposed to scripting and gameplay mechanics.  Therefore the design was kept to a minimum of having a world to run about in, a basic goal of collecting items and as little coding needed for character movement and animation.

This lead to the development of a first-person exploration and platforming game.

The fact that Unity comes with scripts for mouselook and first-person character controllers allowed for swift implementation of something workable with only the adjusting of a few variables required.

The exploration concept essentially allows gameplay to be derived from asset creation by giving the player something to do simply by the motivation of it being there.

Similarly the platforming mechanic (with some tuning and refinement of the character controller) allows and element of challenge to be introduced and can be developed almost entirely through the content creation process.

To give a purpose to the exploration and platforming aspects, each level will require the player to collection a certain amount of a particular item to proceed.

A context and backstory for each of the above mechanics has been pieced together, which will be detailed in a later post.

Inspiration.

While the core mechanics of the game are derived from the necessities of simplicities and where the effort is focused, there are a few thematic and stylistic influences on my decisions surrounding them.

Exploration in Minecraft had a strong influence on my choice.  It would be beyond the limitations of the project to attempt anything of the scale of a Minecraft world, and the procedural generation beyond my skillset.

However, aspects that would be desirable to capture would be the sense of wonder and adventure that comes from exploring a new area and the feeling of isolation and danger that come from being so distanced from civilisation.

The post-apocalyptic wastelands of the Fallout series also present a sense of adventure as you poke around and investigate mostly abandoned and ruined buildings and settlements.

One thing that particularly interests me of this is piecing together the backstory of the world from discarded notes and objects found while exploring.

Visually the intention if for the game to be styled similar to platformers such as Banjo Kazooie, Space Station Silicon Valley and Conkers Bad Fur Day, albeit not quite to the same cartoony extremes.  


Here is the game in it's current state: