Beta Testing Results

Technical aspects problem suppose to fix by me:
-Detection of platforms by the 2D player
-Detection of input even though it just left screen
-Detection of platforms reflected by the mirror was failing most of the time
-Crate inventory system was confusing or rather extra.
-Picking up the suit at a close distance does not work

Technical aspects fixed
-Detection of both platforms and reflected platforms are fix however causing a slight drop in frame rate
-Detection of input is fixed by resizing the limitation of how it detect the input
-Remove of crate inventory system, setting it as pick and use.

Additional fixed.
-Changing the material for the gauntlet detection orb, to enable player to tell that they are seeing both input and output even in the dark.

Main Menu

Edited the main menu codes to suit the newer textures look and feel for the main menu.

New Game - done
Controls - done
Extra - 50%
Continue - left linkage to the levels and rooms
Quit - done

Crates

Improvement:

Crates have now a new way for the players to carry around.

This is to prevent the player from stepping onto the "carrying" crates thus flipping their character controls all around. Hence breaking the game as the player would no longer able to walk straight or properly.

Crates have an inventory system that stores in it.

Level 1 of I/O

Scripting for Level1 I/O
Current Progress of
Scripting the event,
Mirror
Input and Output
100%

Ready for Beta Testing ( open house)

Level 3 of I/O

For level 3 of I/O
Current Progress
scripting the events,
turrets,
input and output of the game.

Currently 60-70 percent done.

Refraction is Completed!

Using an additional camera and render texture from the additional camera to create the illusion of refraction solves the problem of different screen size affecting the size of the refraction. Secondly eliminating the problem with the size changing far and near , left and right.

Thus using the base codes for the normal situation for the 2D player on the normal platform and editing it to suit the current situation on the refraction glass. The refraction glass codes for the 2D player to move on the refraction glass is finally finish.

Improvement on Refraction and Main Menu

Refraction Problems

- When Move left and right and forth and back from the refracted glass, affect differently to the refracted image on the glass
- The Screen Dimension affected the size and position of the refracted image


Refraction solutions

- Adjust the screen dimension with the distance forth and back in a formula through trial and error





Main Menu Progress

- Most of the buttons are completed except the back, start new game and continue game

Main Menu Updates!!!!! Nov 13,2013

Changing the whole layout of the main menu.

Current design is more simple than the previous one.

With when you hover the mouse over it, a effect happen to the button, and when you click it, a transition appears from left to right, as though it's clearing the page and a new page follows it.

Done -> First Page of the main menu

          -> Working Buttons

          -> Effect when Hover over button

          -> Transition from the First Page

Not Done -> Other Pages layout and buttons

Main Menu

Basic main menu is currently developing.

Firstly, i research on how other games develop their menu such as what happen when a mouse hover over an button and what happen when you click it.

Interestingly, there are many different types of main menu design and functionality.

Thus, i note down all the button that is needed for the game and is currently developing a prototype design for the main menu

Refraction foundation codes

Refraction foundation codes for the player to sense its distorted platform is done, and left to be implement into a game scene.

The refraction codes faces many obstacles, such as the lack of knowledge and area of maths such as refraction index.

Studying possible ways on index of glass or visible methods or through many data collection such as looking through the distortion and finding where it should be base on the distance you are from the glass, the direction you are facing, where the object is and where the distortion is.

However all this eventually fail, due to my lack of knowledge of maths and ability to decipher on all the data and come out with a reasoning. In which, at that point of research, i realise a major flaw in the distortion created.

Which this major flaw eventually present a major opportunity to solve the problem and finish up the foundation codes for the player to sense its distorted platform.

Smooth-ing the codes for the move-able crates/platforms

This was my first assignment to finish up, to change the crates codes so that it help the people to place the crates at the correct place more on the visual impact.

Firstly, due to the break in between the two semester , there have been some confusion regarding the codes that exists on how i wrote it before.

Secondly, due to the lack of knowledge, new research are needed on how others present on object able to move in game.

With this two in mind, i study my old codes, understanding how and why i wrote it that way in the past due to the limitation of the software or rigid body and at the same time, look into different games that offer carrying object around.

Progress on the codes, current with the new codes, you could at least be sure that the object will surely be there when you drop it as when you touch in on the ground, it will become upright position unlike the old codes that when it touches the ground, it's still in the tilted position and may cause unnecessary shifting again and again on the crates to obtain a perfect position to lay down the crates.

Second Milestone Prototype

The second milestone prototype is now complete

Mechanics in game done by me
- Teleport between rooms
- Refraction visual
- Reflection visual(with jun jie) and 2D player reacting to reflected images
- 2D player locating environment
- Audio
- Audio scripted event
- Scripted event
- Crates movement
- Locating Crates
- Terminal Locating
- Terminal Interaction
- Transition of 2D and 3D (with jun jie)
- Turret
- Turret bullet impact
- Lights Scripted Event (with jun jie)

Locating of Crates

One of the main problem of our crate was the locating of crate at the centre of the screen. This causes a very limited aim target.

Thus i increase the size of interaction from the centre of the screen in game. 

+ Crates are now easier to pick up.

Transferring of the old model to the new model codes

Transferring might be a problem as they are many new linkages that have to be made and sometimes editing of codes.

For the new model, i had to edit one of the code in order for the game to proceed as normal.

Furthermore, there is a new difference between the old model and the new model, regard of pivot point of object which i had to fix where should the pivot point be, and a new room.

Hence a new room which means there should be new script for the event that is taking place in the new room.

For this experience, of transferring the codes over, I learn that sometimes you just had to go in and tap into maya files also to fix the pivot point, which is a new method of solving a certain problem to me.

Audio

Editing and implementing of the sounds of the game.

Searching for relevant sounds was done by jun jie whereas i edited the sounds.
Voice Recording was done by the team with the voice actor, our art lead ,Shafi.
Which then Jun Jie edited the voice.

I then implemented the sounds and the voice into the game and also creating some scripted event of how the sounds should play or stop.

Searching for the ambient music was done by me.

Succeeds in FrameRate

Finally clearing the major obstacle - the low framerate - actually done with it a week or two ago.

By switching off vsync in the past, at the lowest point of frame rate of the game, i hit a bottom low of 20 - 30 framerate. However finding the problem and several ways to optimize the game, we manage to raise the lowest frame rate with vsync off, an increase of seven times more than the bottom low 20-30 frame rate.

Problem - animation vs physics

this causes much junks of physics to occur causing huge memory space.

Optimizing - Codes and Rendering Distance

By stating object via awake, it increase the loading time but decreasing the code affecting the speed at the game works

Rendering Distance, by default, unity sets it at a 1000. However in an enclosed space, our game does not need to look far. Hence decreasing the rendering distance decreases the time needed to render the game view. Thus increasing the frame rate.

Solution A - Crisis

Rendering Frame-rate

By default the rendering distance is 1000, hence it render pretty much how much your screen can view, and render those behind the wall. This creates a problem as when the texture become too heavy, it causes a drop in frame rate

However this still cause a drop in frame-rate via scripting and physics.

Crisis

Problem face on week 15

At the end of week 15, we realise a major problem which is the dropping of frame-rate for no apparent reason when we solve the puzzle in some room

This causes some mechanics to not function well, hence we are working toward a solution now in order a smoother gameplay for players to enjoy the game.

Success In Problem Solving Deactivating the Turrets

Using the Same Variable to send over the script, minuses the script sending over new variable names, thus making less taxing for the system

After several testing on the script, realise that the real problem for the null reference was because there wasn't a collider for the turret, thus creating the null reference when sending of information to the turrets

Deactivating the Turrets

Mechanics

- Must Detect the correct Turret to deactivate

- Must Send information from the 2D character to the Turret to deactivate it

Problem in fixing the Turrets

- Too many raycast to deactivate the turrets

- Null reference in sending over information to the turret

- Telling which turret to switch off.