Engine: Unreal Engine 4

Languages: Visual scripting (blueprints)

Team Size: 4 scripters/designers

Platforms: PC

Project Length: 4 weeks

Year: 2015

​

I scripted character movement (wall, ceiling and floor movement) and designed levels for a fast-paced 2.5D platformer.

Level Design & Balance​

• DESIGNED half of the level

• Facilitated PLAYTESTER SESSIONS and incorporated FEEDBACK into the LEVEL DESIGN (communicating some issues to the team so larger design decisions could be made as a group)

My level design for the middle of level.

My level design for the end of level ("elevator" to boss fight).

• I chose to make the camera zoom out so players had a clear idea where they were in relation to enemies.

• Since these areas were nestled between areas with zoomed-in views of the player, they added greater variety to the level design.

Example - Playtesting Adjustment

​Players found an electric enemy too underwhelming and didn't realize it was an enemy. I found reference images to demonstrate how the enemy design could be changed. These changes were then implemented into the game.

Scripting

• SCRIPTED a character movement prototype (for fast-paced traversal on walls, ceilings and floors)

• Worked with another scripter to deliver additional versions of characters movement

• IMPLEMENTED TRIGGERS, sounds, etc.

The Challenge

• Movement was the biggest challenge of creating the game, since Unreal Engine 4 didn't allow an easy way of switching gravitational direction. Corners also posed a problem for smooth movement.

Prototype - Character Movement

• I used LINE TRACING to determine how far the character was from a given surface (wall, floor or ceiling). This method of using line tracing for detection ended up in the final version of the character movement.

• A MAIN DIFFERENCE between character movement in the prototype vs. the final game, was I initially ADDED FORCE to the character, depending on the closest jump-able surface type. Subsequently, I tried to balance the force in each corner so the player would move smoothly around it. This method ended up proving imprecise.

Final - Character Movement

• I COLLABORATED with another scripter, where we decided to use an enum for 5 PLAYER STATES - floor state, left wall state, right wall state, ceiling state and jumping state.

  • When players jumped to the ceiling, the controls flipped (although players were unaware of this because the control directions reversed when the state was changed).​ This helped resolve movement issues.

• The corner issue was resolved by shifting between 5 player states to change the character's controls​.

  • The system checked the closest wall and discretely moved the player beside it using a static distance value, thereby ensuring smooth movement around corners.

• We also included logic to adjust camera location and to CHECK JUMP DISTANCE.

What I Learned

• The challenges in creating character movement reinforced the need to DEVELOP A SOLID FRAMEWORK in the initial stages of game development.

  • Such as framework encapsulated each major component within its own function (i.e. checking walls and corners, line tracing from the character).​

• As this was my first game project where I collaborated heavily with other scripters, I learned how to better ORGANIZE scripts and COLLABORATE with other programmers to developer an EASILY MAINTAINABLE SYSTEM.

Programming (C#)

• CODED KEY SYSTEMS, including the dialogue system, quest log and system, etc.

• Scripted many of the sounds, particularly pertaining to the dialogue and UI elements.

I coded UI pop ups, ensuring specific text displayed at specific times. The quest system I created allowed for different conditions (such as player inventory containing an item or allowing a new quest to start when others were in progress or complete).

I programmed the quest log system, ensuring icons in the quest log displayed on quest start, AND icons changed to a star background on quest complete.

Example Code

The dialogue system receives information (such as quest text) from quest classes:

Creating Designer-Friendly Systems

• Designers could use the below fields (in Unity's inspector) to easily create functionality for new NPCs placed in the world.

• Due the behaviors NPCs inherited (from the system I created), NPCs could immediately interact with players.