PERSONAL PROJECT – 2 WEEKS OF PROGRESS
WHAT IS IT?
This personal project came about because of some personal things happening that I wanted to process in a healthy manner, so I decided to do it through making a videogame. It’s a story-based 5-15 minute game where you traverse through levels while constantly moving in one of the four cardinal directions.
To be applicable to a school project and kill two birds with one stone, it had to be on 2 different platforms. I chose both PC and Android. This came with some challenges, which I solved in the following ways:
- I had to create a seperate input layer to the codebase so there was no need for duplicate logic. For example, the movement code is the same MonoBehaviour on both platforms, but just gets called by different inputs based on the target platform at compile time.
- I had to take into account the graphical capabilities of both platforms during shader programming, as not all shader functions are supported on both platforms.
- I had to create a modular cutscene system with generic behaviours, due to me still going through the personal things as I was making it.
HOW THE INPUT LAYER WORKS
The input layer starts out by only compiling the call to the input method of the target platform.
Then, the same thing happens to the InputWindows() method.
Lastly, the same is defined for the (as of yet unimplemented) InputAndroid() method.
These #if <platform> #endif statements make Unity3D compile code only if the target platform matches the <platform> during build-time and in-editor. This cuts down on a bit of filesize, but more importantly, removes the need for seperate MovementAndroid or MovementWindows classes and things of that nature.
HOW THE CUTSCENE SYSTEM WORKS
The cutscene system is based on modular, generic cutscene behaviours inheriting and overriding from a base class being played in order of appearance by iterating through an array. Each cutscene is a seperate scene, so the execution code simply does the following:
The base class is just as simple, containing only a public virtual void method named Action() and a public float called waitTime, to indicate the amount of time the CutsceneLogic code has to wait after this CutsceneAction before executing the next one. The base class looks as follows:
This then allows me to write generic behaviours to make the cutscene modular. An example CutsceneAction called CUT_LoadScene then looks as follows:
A quick cutscene slapped together in 2 minutes using this system looks like this:
Well then, what does it actually look like for the designer to create cutscenes?
All the user has to do to create a cutscene like this, is to drag a CutsceneAction behaviour onto a GameObject with a CutsceneLogic behaviour, assign variables and put them in CutsceneLogic’s array called Actions in order of execution. Press the play button, and the cutscene plays.