// Game Programmer
NEKO GHOST, JUMP!
ABOUT
Company
Primary Role(s)
Game Engine
Project Status
Project Type
Languages
Burgos Games
Gameplay Programmer
Unreal Engine 4
Early Access
Indie
C++, Blueprints
Neko Ghost, Jump! is a cute but challenging puzzle-platformer where you not only switch between 2D & 3D camera perspectives but also between your physical & ghost forms to solves puzzles, combat enemies, and clear levels faster! Take control of Nekoman as he runs, jumps, and fights his way through various environments to find his friends and loved ones that have been taken away by the Space Dog Pirates.
---
This project taught me how to use my time well and effectively work in a fast-paced environment. Me and the rest of staff were monitored and timed on their tasks, The company also utilized Jira with sprints. At the start of every work week, a sprint planning meeting was held and I would be assigned tasks. I was required to fill out my progress on each task by posting comments, images, and/or video. If I felt a task was ready to be checked over, I slotted it as "Feedback". It would then be checked over by the lead programmer as a sort of code review.
I greatly enjoyed working in this environment, as it was highly motivating and encouraged solid programming practice at all times.
Click the buttons below to learn more about my contributions to Neko Ghost, Jump!
Among my primary responsibilities as Gameplay Programmer was constructing new enemies/bosses or modifying existing ones. The logic was done with a mix of C++, Blueprints, Animation Blueprints (ABPs), behavior trees, and blackboards. I would start by creating a derived class from a base enemy class. This base class supplies every enemy with a common set of parameters/events. From there, I would create an ABP if none existed. Creating one involves constructing a state machine and connecting the appropriate animations to each state. Then, I would link up the enemy class, character model, and ABP.
As mentioned, I use behavior trees (BTs) to configure the functional state of the enemy. We designed each enemy's BT to use a common set of generic actions. That way, we could develop different enemy types very quickly. Most of the specific logic for an enemy belongs in their individual blueprint class. Furthermore, I implemented logic for various types of enemy attacks, such as ranged/projectiles, melee, AOE, & special attacks.
A few examples of enemies I developed from the ground-up were:
-
A flying bat that can path traverse around any obstacle in 2D and 3D to reach and attack the player.
-
The hell boss, who has 3 distinct phases of a fight. Mechanics range from raining hellfire to cartwheeling on the ground while throwing tridents.
-
A cloudman that tracks player movement, extends arms, grabs players, and eats them.
-
The desert boss. In the first phase, the boss flies overhead, dropping bombs while mummies are summoned, climbing a pyramid to attack the player. In phase 2, the boss can pick up the player and thrash them about in the sky. In phase, the boss enters a melee phase where it can throw tornadoes or peck at the player with its beak.
-
A nosehugger enemy that can crawl along the ground and latch itself onto the player's face.
Along with creating enemy AI, I also spent time with designing the logic for various gameplay elements and mechanics. One example is a flower trap. This trap has a few different modes: stationary, ranged, and rotatory.
Another example is a pushable block. Despite how simple it sounds, we opted to implement it without using physics. Instead, we used an additive approach depending on the direction in which the box is pushed. This allowed for much greater freedom and control. It also allowed me to construct various types of blocks, such as ice blocks, bomb blocks, jump pads, flamethrower blocks, and asteroid blocks.
A large consideration for any new game mechanic was the 2D/3D switching. Because the player could switch between the two dimensions at any time, much thought was given to how the logic would handle the switch. Even simple mechanics, like the pushable block described above, needed to handle the switch with grace.
A large portion of my work consistent of resolving bug reports. This allowed me to get into and understand mechanics that I didn't necessarily create from the ground up. My method in solving bug reports is to first understand the problem completely. Second is to develop a set of replication steps if one hasn't already been provided. Third is to start debugging the logic via breakpoints, printing looping information, or employing unit testing (called Automation Tests in UE4).
During my time with the project, I strove to write clean and modular blueprint logic that was easy to read. Because of the nature of visual programming, the pin and execution connections can quickly spiral into literal spaghetti code. That's why I focused on simplicity and leanness. Modularity and reusability were key.
A tertiary responsibility of my role was constructing or modifying user interface elements. This process was done via UE4's UMG system. My method for creating these is similar to creating blueprint logic: modular components using generic logic. Having some experience in UI design beforehand, I also knew a key element in UI design is responsiveness to every appropriate resolution for our targeted platforms. I put consideration into designing a robust framework for each UI menu.
One example is the customization menu. Initially, logic was separated between the keyboard and gamepad versions of that menu. In other words, there was many instances of duplicated code. I was tasked with refactoring the entire customization system. I started by introducing a base class that the keyboard and gamepad menus would derive from. The only logic that remained in each of those classes only pertained to specific logic necessary for input.
I also refactored, fixed bugs, and worked along side designers to rework the settings menus, account picker menu, and in-game pause menu.