DotEXE

Dot.EXE

Scripter & Level Designer

Engine: Unreal Engine 4
Platform: PC
Role: Scripter & Level Designer
Total Scripters/Designers: 4
Project Length: 4 week school project (Spring 2015)


Description:
In Dot.EXE, the player takes control of D.O.T.-42, a nano probe armed with laser cannons and the trusted antivirus shield. Part of the virus defense force, D.O.T. is sent to the front lines to scan for potential threats and eliminate them. Dot.EXE is an intense 2D action platformer featuring gravity defying movement and thrilling combat.


SCRIPTING

Overview:
I created one of the early prototypes for the character movement, as well as additional versions of character movement with another scripter. The movement was the biggest challenge of creating the game since Unreal Engine 4 didn’t allow for an easy way of switching gravitational direction. We had to develop this unique movement ourselves. I also implemented many of the sounds and other elements, such as triggers.

Character Movement (Prototype):Dot Explanation
The biggest challenge in building this system was making the movement work for all corners (both outer corners and inner corners). I originally used line tracing to determine how far away the character was from a given surface (i.e. a wall, floor, or ceiling). This method of using line tracing for detection ended up in the final version of the character movement. One of the main differences between the initial prototype and the final version was that 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. Unfortunately, this method ended up being imprecise.

Character Movement (Final):
I collaborated with another scripter to build upon a system where we used an enum for 5 different player states – a floor state, left wall state, right wall state, ceiling state, and is jumping state. When the player jumped to the ceiling, the controls flipped, though the player was unaware of this because the control directions reversed when the state was changed. (Since the player could only jump to parallel surfaces, the player could only switch from the floor state to the ceiling state and the left wall state to the right wall state or vise versa while jumping.)

The issue with corners was solved through a system of shifting between these different 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. This was necessary so the player would smoothly move around the corner of the wall. We also included logic to adjust the camera location and check the jump distance.

DotEXE - Character Movement

What I learned:
The challenges encountered in creating the character movement reinforced the need to develop a solid framework from the onset. Such a framework helped encapsulate each major component within its own function (i.e. checking walls and corners, line tracing from the character).

I learned how to better organize scripts and to collaborate with other programmers in order to develop a stronger and easily maintainable system.



DESIGN & BALANCE

Overview:
I started out as one of the main scripters for Dot.EXE, but due to time constraints, more manpower was required for the level design. In addition to my scripting tasks and bug fixes, I designed half of the level, ensuring my concepts fit seamlessly with that of another designer.

Since Dot.EXE was created to be a hardcore platformer, a lot of playtesting was required to ensure the difficulty suited our target demographic. I facilitated the playtesting and changed the design of the level and balancing at points where players struggled. While I made some of these changes myself, I communicated other issues to the rest of the design team so their parts could be changed or larger design decisions could be made as a group.

Example of design change due to playtesting:
One particular issue required collaboration with the lead artist, as players found the original electric enemy too underwhelming and didn’t realize it was an enemy. I found reference pictures to demonstrate how the enemy could be changed so players would immediately realize the enemy was dangerous, and the changes were then implemented into the game.

My level design for middle of level (mid-way through game):

My level design for end of level (mid-way through game):

I chose to make the camera zoom out during these parts so the player would have a clear idea where they were in relation to the enemies. Since these areas were nestled between areas with a zoomed-in view of the player, they added greater variety to the level design.

Leave a Reply

Your email address will not be published. Required fields are marked *