Ghost Shot
3D Platformer
Video created and voiced by me.
A cozy 3D platformer set in a sandbox of supernatural abilities. Hop across the land on a journey to photograph ghosts and set them free.
Halloween 2024
CONTENTS
Responsive 3D Movement
Problem Statement
Fluid character movement is the cornerstone of effective platformer design.
Player Experience Goals
I designed a number of responsive systems that increase the level of control the player has over the character.
A key challenge for me while designing movement — our character is 2D!
How can we effectively convey the direction the player is running in, the speed of the character, and more in 3D space with only a 2D sprite?
I used a variety of visual cues paired with audio to convey the character’s movement state to the player, allowing for strong input feedback despite using a flat sprite.
This contributed greatly to a sense of decreased input latency and increased control over the character.
Designing a Good Jump
Level design plays a large role in how a game feels to play. Jumping is the most common action a player will do, and I therefore wanted it to feel as good as possible.
An early playtest finding was that the amount of space available for landing on a platform influences the intensity of the challenge.
This diagram is scaled to 50 Unreal Units Squared per tile, and was used as reference for designing platforming challenges.
The movement system I programmed halves gravity at the peak of a jump, which means that the jump apex is when the player has the most control. From playtest feedback and iteration, I determined that the ideal jump occurs when the player character is at the apex of their jump right before landing on a platform.
All of our jumps follow this principle. We modify the landing sizes to vary intensity and design each jump to coincide with where a player will reach the apex just as they arrive over a platform.
Designing Effortless Controls
Our user experience research revealed that the bottom and left face buttons (A and X), the right trigger, and the left thumbstick are the most easy to reach buttons on a standard controller.
I committed to using those buttons as the primary movement buttons, each with its own role. This ensured general movement was as comfortable as possible on a controller.
From there, I developed an advanced moveset that used combinations of the primary movement buttons. This allowed for more movement possibilities, such as spinning in midair, diving, crawling, and more.
Additionally, some buttons, such as jump, provided more of that input the longer they were held down.
With just the four most reachable controller buttons, I was able to achieve an expressive moveset that combines each move in meaningful ways.
In our playtesting, this drastically increased the ease of control the player had. More importantly, the complex moveset removed friction between movement states (jumping, walking, etc.), allowing players to seamlessly transition into the next move they wanted to execute.
C++ Gameplay Framework
Engineering Approach
My approach to gameplay programming was to build or refactor all core gameplay functionality as native C++ code. This code is designed to be extended in Blueprint to allow for rapid prototyping.
To accomplish this, code needed to be written in a way that made it easy to compose by calling functions exposed to Blueprints.
Engineering Goals
Player Character Class
The player character is made up of a core C++ class (extends APawn), and then composed of multiple actor components that each encapsulate some functionality.
For example, player movement and input handling is done by the PlayerMovementController class. The player’s graphical representation and visual effects is done in PlayerGraphicsController.
This approach allows programmers on the team to reason about encapsulated chunks of functionality, rather than deal with the complexity of the entire character class and everything it does.
Additionally, this also allows for interchangeability among components. Components are not dependent or aware of each other by design, and communicate via event dispatchers in the base character class. This allows each component to be extended, rewritten, or redone to provide new functionality without rewriting other parts of the character class.
Iterative Playtesting
Methodology
The only way to “find the fun” and know that a game mechanic or level idea is successful is to put it in front of players and test it.
I implemented an iterative testing cycle alongside our user experience team to capture player feedback continuously throughout development, iterating as we went.
Playtest Process
Playtest feedback is aggregated on sticky notes using Miro. This lets us organize the feedback we have received and take notes, showing us at a glance where trouble spots or problem mechanics are.
From here, we can build a priority queue of changes to improve on for the next iteration.
All feedback from each iteration is pooled together on one virtual board, so we can see how the mechanics and levels are improving from week to week, and specifically note regressions or observe trends.
Blueprint/C++ Integration
A Combined Approach
C++ and Blueprints work together to enable fast iteration and high performance. Our early prototypes began as Blueprint code and were later refactored to C++ to optimize for performance.
Integrating C++ and Blueprints
All gameplay objects are children of base C++ classes.
Unreal C++ macros are used to demarcate functions and variables that should be exposed to Blueprint code in the child classes.
This allows us to write custom Blueprint nodes in C++, and then use them in the Blueprint node graph to quickly create prototypes or new functionality.
Ensuring gameplay objects are Blueprint children also enables us to utilize Unreal features that are faster in Blueprint, such as editing an object”s components or using asynchronous processes such as Timelines.
A combined approach saves time and effort for programmers and designers, while maintaining high performance.
Character Finite State Machine
Performance and Extensibility
A finite state system provides optimized performance for the player input system. Using discrete states and function pointers, we can isolate functionality and extend it as needed while saving conditional checks.
Representing States via Enums
The enumerator EMoveState defines the discrete movement states the player may be in at any given time.
Then, the actual behavior is defined by a MoveSet. The enum EMoveSet defines the actual movesets, and can be expanded to as needed. These movesets point the function pointers to the state functions for the given MoveSet.
In this example, we have a Standard moveset that the player typically uses. At certain times, we want to limit a player’s actions. For that, we use the “Limited” moveset and define in code a different set of state functions for what “Limited” movement looks like.
Handling Input
All player and engine input is routed through a custom input handling function. The enum EStateInput defines each input, and this input is passed to each state function. The state function then handles behavior or transitions based on the input given.
Inputs include buttons the player presses, as well as engine events such as the event tick.
UENUM(BlueprintType)
enum EMoveState
{
Idle UMETA(DisplayName = "Idle"),
Walking UMETA(DisplayName = "Walking"),
Running UMETA(DisplayName = "Running"),
Jumping UMETA(DisplayName = "Jumping"),
HighJumping UMETA(DisplayName = "HighJumping"),
SpinJumping UMETA(DisplayName = "SpinJumping"),
Falling UMETA(DisplayName = "Falling"),
Crouching UMETA(DisplayName = "Crouching"),
Crawling UMETA(DisplayName = "Crawling"),
Pounding UMETA(DisplayName = "Pounding"),
PoundFlipping UMETA(DisplayName = "PoundFlipping"),
Diving UMETA(DisplayName = "Diving"),
Dodging UMETA(DisplayName = "Dodging"),
};
UENUM(BlueprintType)
enum EMoveSet
{
Standard UMETA(DisplayName = "Standard"),
Limited UMETA(DisplayName = "Limited"),
};/**
* This represents all possible inputs for each
* movement state that the player can be in.
*/
UENUM(BlueprintType)
enum EStateInput
{
TICK,
INIT,
END,
SET_INIT,
SET_END,
JUMP_Pressed,
JUMP_Released,
CROUCH_Pressed,
CROUCH_Released,
FLASH_Pressed,
FLASH_Released,
GRAB_Pressed,
GRAB_Released,
HIT_Pressed,
HIT_Released,
AXIS,
AXIS_HORIZONTAL,
AXIS_VERTICAL,
EVENT_Landed,
EVENT_Jumped,
EVENT_Launched,
EVENT_HitMechanic,
EVENT_CameraMechanic,
TIMER_PoundFlip,
RESET,
};Minimize Clock Cycles with Delegates and Function Pointers
Input and gameplay logic is handled in an event-based manner. This minimizes the need for costly functions to run in the frame tick.
Player movement logic is kept in atomic handler functions, and when the player’s moveset changes, a function delegate is given a pointer to the next handler function. That function then receives player input and engine frame ticks, preventing the need for extraneous if statements or state checks.
// Jump input is abstracted and passed as a state transition into the state machine.
void UPlayerMovementController::JumpActionPressed()
{
if (!InputEnabled) { return; }
(this->*StateFunction)(EStateInput::JUMP_Pressed);
}// Designed to be extended with new movesets.
void UPlayerMovementController::State_Jump_Implementation(EStateInput input)
{
switch (MoveSet)
{
case Limited:
Limited_Jump(input);
break;
default:
Standard_Jump(input);
break;
}
}
Living Design Documents
Methodology
Documentation needs to be up to date in order to be useful. In concert with our iterative playtest method, I incorporated design documentation that grows with the project.
Design decisions are proved via playtest.
After every playtest period, a new entry is created. This typically occurs at least once per sprint.
Feedback from each playtest is accrued and a list of issues is identified. The goal is to improve the feature by the next iteration. Team members comment on the issues list, and tasks are created for the next sprint period.
This is repeated for every new iteration.
Methodology
Documentation needs to be up to date in order to be useful. In concert with our iterative playtest method, I incorporated design documentation that grows with the project.
Online tools allow team members to make in-line comments and suggestions, and all content links are set to update dynamically. This master document can be updated after design reviews, playtests, and at the end of sprints as needed.
