Final Assets and Reflection

As we were getting towards the end of the project, it was turning more from a grey box in to a finished game. I was being given assets to place in and others were placing in their own to the scene.

The climb rocks placed by Monika made a big difference.

I was also provided with platforms from Monika and Ed, which I then built or scaled in to what I needed.

Monika gave me some square platforms which I could scale in Maya and import easily, these were for the affected warp platforms.

Monika also gave me two varieties on plank, with this I built all of the wooden platforms, such as the ones the a grapple-able. A few warp platforms as part of a non-puzzle bridge moment were wooden as well, which I should perhaps have changed.

Ed gave me all the platforms for the gorge. We needed them to look like parts of the gorge, so it was a challenge keeping the same visual language previously formed whilst changing how they look. 

To identify the warp platform, Max, who gave me the rock stacks, gave me a moving/warping sand plane to become the visual language of these platforms.

However, not everything was perfect in the end. The sand planes did not get put in to the final presentation build, nor did anything to visually separate climb blocks from grapple climb blocks. The User Interface was not working properly and one bird animation where it flies overhead did not work properly. I feel this is partly due to use wanting to add a lot in a short space of time, which then became overwhelming for the person trying to sort it out alongside everything else that they need to include.

I feel that on the second part project, or this unit, that in some aspects I did better than I expected and in other I could have done things a lot better and I see potential shortcomings in my level design if not handled correctly. I have found designing game play brilliant but very challenging, there is a lot to think about from the root designs to working with everyone and making sure everything gets implemented properly, such as what makes things clearer to the player, which in the end we didn't quite have time for or only existed in my build.

If I were to go back and do this again, one thing I would do is try to get things in quickly and effectively. I do not feel like I could have done that at the time, but now feel I am in a much better position. Write a simple script, use a few animations for grappling, and you have a glitch free playable section. Although I like doing things on paper, I would have also liked to have thrown in a few more tests together in 3D, not just experiments but do more iterations for final puzzles, though it did get to a point where I had to move on. 

Some aspects of designs I have perhaps need extra featured to make them work properly that I did not think of, such as a changing camera view. I could have done coding better, it got very quick and almost seamless toward the end to the project, however I am aware that at some points I spent a lot of time coding something which resulted in being not needed or changed due to my own development decisions.

Though not perfect, I feel the areas in the game a gradual, interesting and fun and that a lot of what I wanted to do and create came across and worked well. An outside perspective may be different, on that note I think more play testing would have helped, but an early build or playable demo never really seemed to happen.

Overall I have very much enjoyed this project and am happy with the result, I feel like we have all done very well throughout the process and in the result we reached. I know I could have done things better and am always having ideas with how to improve it. With some further research and tweaking there could be some much more fine tuned game play.

The Start Screen

For our game we needed a start screen, so I decided to make one. Visually I had a lot of help with this, however I planned the lighting and coded the functionality.

We wanted the scene to be dark, but for the Armillary Sphere to stand out.

This simply included an option to start and does have a quite function, however this in some cases will not be used. When the player presses start (or E currently) the scene fades to white and the game begins. When the player reaches the end of the game, it fades to black and returns to the start screen.

Updating User Interface

The place holder User Interface could not be used in the final game, so I decided to make some more UI that looked better and was a little more fitting to the game, however I am not an artist so I also intended someone who has the skill to edit and improve them.

I tried to keep a consistent look as I designed something to go around a button, the aiming at the wrong point circle, the aiming at the correct point circle and the in-level elements.

Here is the texture sheet. The grapple hook image was still very rough.

Where as these where by no means perfect, I feel they were a significant step up from what was included previously. I was provided with a font to add in as well, which you see in the screen shots below.

Although no code had changed, my grapple system working with a controller from the lead designer did not quite aim as it should when the screen overlay and in-game aim are compared, because the controller was not designed for my system.

At the moment it is unclear what UI elements are staying in the game however as these are currently not very realistic or fitting, the UI will need further updating for the final product.

Sound and Trigger Events

Of course for the project we needed sound, so I spent roughly a week creating the sound for the character and environment, this included, climbing, foot steps, wood creaking, ambient wind, a bird screech and more. I thought about how sounds would change on different surface, such as footsteps on wood, as I was creating them. I then implemented all prioritized environmental sounds, any character sounds where added by our main coder. 

I used a co-routine to delay when sounds would play in order to fit the visuals. I mention this here because I also made use of these when coding in various animation triggers and events throughout the level.

When making triggers for animation, I would allow a delay at certain points in order to later create the desired effect. This was useful at points where the player would pick something up and text would display at different times, or during the end level sequence, where you want two animations and the level fade out to happen at different times. 

I also made a simple placeholder for what would happen to the gorge as it was suppose to explode and form into a puzzle, however I just had the bridge disappear and the puzzle appear a second later in its place. I also created a script to trigger all the rock stacks I had been given to implement.

Of course the triggers for the particle guide I used a co-routine for as they fade in and out, which also have a sound.

Implementing these aspects I had to think about placement and timings all in a short space of time, which made me think about design in a different way.

*The sounds for the bird flying overhead were adapted with sounds from 'mario1298' & 'thecluegeek' on www.freesound.org

New Terrain and Game Play Changes

 Initial Changes

After designing the first areas, our environment artist, Monika, took them and keeping true to the designs and measurements I made, create a new iteration of the level, an overall terrain where all the elements are linked and the player can progress from start to finish. We had previously decided the overall level plan and map together. Below is a shot I of the most up to date iteration of the level I have.

The previously planned sections however were not the only game play aspects in the level, to suit the environment some aspects were added without sacrificing the planned progress. The level now starts with a piece of climbing and grappling. I did not have any problem with this as they were not complex mechanics to introduce, and it made the start of the game much more interesting.

All the other puzzles remained the same, Monika and I kept on working together in order to make sure everything was being implemented properly. This helped communicate where Monika would place the climb rocks she created, and I could take assets that we discussed and she had provided me with for game play to replace the grey boxes in the scene. This however will be covered in another post.

Jump Distance Change

Upon review of our work, we decided to extend the jump height/distance. The levels had already been designed around what had been decided together and set, however I could understand why people wanted to make the change and if it was possible it would be good. I was skeptical that there would be unforeseen issues in doing so. I found the new jump distance and looked for any changes that would need to be made, and updated Monika on any changes that needed making to the terrain. 

Once we had everything changed, it all still worked and played well, however looking back some complications did appear. There was one part where the terrain didn't get updated properly, it was also more difficult to communicate to the player what gaps they could or could not jump. I have noticed this now occasionally confusing people. If I had more time I could refine the levels more for this new distance, in a few places without too much trouble, this I would like to update when taking the game forward. I do not feel the decision was bad, it definitely has benefits, and it is good it wasn't decided later in production, however I feel it was decided a little too late in production as it was. The problems left do ultimately come down to me, and some could have been avoided with more communication, such as the part below where the platform is not brought out far enough as it would negatively affect the puzzle.

Sudden Change

Just after climbing up at the beginning and before the first puzzle, there was quite a large empty section with a lower section originally intended to kill the character if they fell down. However our producer and lead designer/coder felt we should do something more with it and pitched an idea to me.

I agreed with the idea, so I took what they had suggested and did some lightning level designing, I created an area fairly quickly and discussed it with them. I was surprised at how easily I created something with as few problems as it had. I then tweaked it and finalized it, and it quite naturally became an integrated part of the level. There was an idea where the player could drop down into water below and see some foliage and other environmental aspects before working their way back up, I wasn't too sure about this however we decided the dropping down was not obvious, so I decided it wouldn't hurt to add in. Overall I feel that this addition went well.

Coding and Other Mechanics

Of course I had to think about game play beyond the main mechanics. Of course I have previously mentioned player guidance. I began thinking about this using different coloured blocks and platforms however this of course was not enough. 

Early User Interface

As Unity had an updated User Interface system, I learned how to use it and started implementing UI.

This UI included a yellow target that would appear around objects that the player could grapple, this was bright and rotated to catch the players eye. This early iteration was perhaps too bright and obvious and would not fit in to our intended vision, however I used it as a placeholder which allowed me to experiment with a useful concept.

When aiming with the grapple hook, a redicule would appear in the world where the player was aiming, to help show if the object is too far away, and this would change from red to green when they were aiming at the correct object. I used various Raycast features coupled with the UI for this result. The same image that appears in the world would also appear faded on the screen overlay so that the player could see the size difference and use that to judge distances, useful idea however I am not sure it was necessary in later iterations of the game.

The UI also included text, which would tell the player controls and small instructions. This was done in a subtle way, so that if they player knew the mechanics they could ignore the text. This told the player how to grapple, jump and climb.

Other Visual Guidance

It was important to make sure that things were consistent throughout the game, so the climb blocks we decided should always be a consistent height, and areas where you grapple up would also be a consistent height. The parts that you can grapple also had an object and UI in order to separate them. This ensured so that once the player learned one thing, it could be reused by them.

     

In a similar idea, anything that the player could grapple and pull would be yellow, have a light, an object and UI. This would need to be simplified later on, however it was another visual repetition, where if the player see it they know they can grapple it to make something happen.

For the warping platforms, a pink platform would affect a green platform or object, during testing I kept it as simple as that. Again once the player learns this, they will know what pink platforms do. Of course this was placeholder. I also decided to put a flashing light of the affected object to more clearly show that player what was happening. An issue at this early stage was that if a platform both affected others and was affected itself, it was difficult to communicate.

Particle Guide

I found a script here: http://vincentedeluca.com/ on 03/03/2015

This is the only script I used from online, it allowed me to use empty game objects to create a path of particles. I found this very useful as I could then create a system throughout the level which would suggest to the player where to go, or where they need to go to progress and therefore where they don't need to and can explore. This came in useful during later puzzles to give the player hints without making anything too obvious.

Coding and Refining Main Mechanics

 Of course as part of designing and testing the levels I needed to create them so that they worked, and were playable. Some of which I needed to code a final iteration of for the full game. Others were placeholder until our main coder had finished the final mechanics.

A nicer placeholder grapple

For the grappling early on, you would walk up to a yellow cube, press a button and something would happen. Of course to test grappling properly I needed to create something the grapple length which I could also aim with, as it would behave in a similar enough way to the final mechanic. The placeholder was just a block that appears, but it worked. This allowed to start coding the grapple-able object behavior as well. This started as something physics based, a one-shot force would be applied to an object with limited movement, and it would stop when it collided with another object.

This of course wasn't perfect, but it allowed me to grey box the game and test it to a decent standard.

Animated platform movement

Using physics though had it's own problems, it was a pain to get it to behave properly, and even when I did it was still glitched and problematic. Platforms would fall or fly away, go in the wrong direction or other undesirable things. One reason I stuck with it is because it was easy to duplicate and change for other sections, and it would still work. However, after probably being quite stubborn and trying to get it to work properly, I decided to key-frame animate the platform movement, this decision I should have made sooner. It is slower as each object needs to be individually animated, however the result was much nicer, how the platform moved was much more controllable, and a better part was that there were no glitches. The animation played, the platform was where it needed to be and you could move on.

Warping Platforms and improvement

The warping platform mechanic was a big challenge, getting it to work at all was a learning curve and it took a lot of work and thought. To have it only active at the right time posed difficulties. A script on the player has to be used to detect and affect only the platform it was in contact with and any booleans that needed setting, as soon as the player left the platform in any way it would have to stop working again. The initial mechanic of moving a platform with a normalized distance was not too difficult, however it did take some thought.

I ended up with a mechanic I liked, for the most part. An issue was that in order to get the affected moving platform to the right place, the player would have to stand in the center of the platform they are on. That isn't some that players know to do, or would want to do. So with the much help and explanation from our main coder, we managed to change the code so that the player did not have to stand in the center of the platform, but could walk from side to side without the other platform moving. I also decided to make the mechanic only work with X and Z co-ordinates, which create a much more accurate result.