CHUNS
Solo Project
DESCRIPTION
A twin-stick shooter with a fun twist: Utilize enemy's bodies as weapons in this tightly-packed, fast-paced twin-stick shooter chess-like with fun visuals and an original soundtrack.
Chuns is a solo project developed as a student project for Breda University of Applied Sciences.
YEAR
2023
GENRE
Twin-Stick Shooter
PLATFORM
Windows PC / Itch.io
DEVELOPMENT
8 Weeks
TEAM SIZE
Solo
PROJECT HIGHLIGHTS
Design
Programming
Art and Audio
-
Designing game concept and defining project scope.
-
Conducting playtests and organizing the data to guide the next iterations.
-
QA testing and maintaining feature quality.
-
Iterating on game systems such as 3Cs, Enemy Behaviour, and Game Structure based on player feedback.
-
Balancing and fine-tuning variables such as health, ammo, and enemy speed.
-
Hand-crafting 50 enemy waves including 1 final boss fight.
-
Enemy AI with grid-based pathfinding and movement that imitate chess pieces.
-
Global grid and "beat" systems that allow all enemies to take turns when moving and avoid hitting each other.
-
Modular weapon system with customizable aiming directions for controller and mouse.
-
Easily expandable wave creation system.
-
Creation of, in total, 126 unique sprites for all enemies, weapons, and their variations.
-
All UI and Menus.
-
Composing and arranging the Main Theme and variations.
-
Engine implementation and audio mixing of 59 SFX.
DELIVERABLES
As a solo project, my primary deliverable was to produce a twin-stick shooter with a fun twist. I had pretty much unlimited creative freedom as long as the game fit inside the twin-stick shooter genre, which was a really exciting opportunity for me to create something unique and exciting.
GAME CONCEPT AND GAMEPLAY LOOP
Kill enemy -> Use enemy as weapon -> Repeat!
The project required one enemy and one weapon, the idea I had for a fun twist would be to combine them, making the defeated enemies the weapons you possess.
With every enemy being a unique weapon, it was crucial to ensure that players could quickly familiarize themselves with both aspects. I made the "enemy form" move like its chess counterpart while the "weapon form" could only shoot in the directions the chess piece moves. Combining top-down action with the strategic gameplay of Chess.
CORE GAME LOOP
Initial Game Loop Diagram that guided development throughout
Core Loop
One of the first things I did when starting to develop this game concept was to break down and understand what would be my target player experience, and how I would achieve that.
The player experience I decided on was Deliberate, Challenging, Fast-Paced, and Engaging.
Having these defined early on allowed me to make informed design decisions on how each game system could be implemented. For example, the aiming and weapon system contribute to the deliberate aspect, but not the challenging and fast-paced, so it was essential to make aiming and picking up weapons as intuitive as possible to ensure no unintended frustration would be created that doesn't contribute to the game's overall experience.
PLAYER EXPERIENCE AND DESIGN PHILOSPHY
Zubek Model Breakdown detailing Player experience and underlying game systems
The player in CHUNS had a surprising amount of iterations over the game's development, from a fast-paced hero with mountains of ammo to the methodical rebel pawn that makes every bullet count.
PLAYER
What
The player can utilize WASD, the D-Pad, or the joystick to move 1 tile horizontally or vertically.
How
The player movement utilizes the same grid system as the enemies, with the only difference being that the grid slot the character moves to is determined by the player's inputs.
I also implemented input buffering, meaning players can input movement while moving to the next tile, and instantly move again once the current move is complete.
Why
Since aiming also follows the grid, having the player move along it makes it much more intuitive and natural to hit and dodge enemies.
GRID MOVEMENT
Grid Movement
What
The amount of bullets each enemy provides is super important to the flow of combat in CHUNS. Each weapon gives the player 3 bullets. None of the weapons are necessarily better than the others, but they all require the player to position slightly differently. Analyzing and adapting to the currently available weapons is one of the most engaging parts of the game.
How
The weapon system in CHUNS was built modularly so that most of the logic is reused. Each weapon just needs to set the possible aiming angles. Damage, ammo, and any special effects (like the knight's bullets separating into 2) are handled automatically. It'd be easy to add any new weapon that, for example, can only shoot upwards.
Why
Very early versions of the game had enemies take many shots to kill, with weapons rapidly firing many projectiles per second.
This method did not facilitate the deliberate player experience. Heavily limiting ammo and having enemies take only 1 bullet to kill makes sure shooting is a very deliberate move from the player.
WEAPONS AND AMMO
One Shot Kill
Early prototype with multi-shot kill
Getting the enemy's behavior "just right" was one of the biggest challenges in the project. Even though their final behavior is relatively simple, the small details are what make the biggest difference to the feel of the final product.
ENEMIES
What
"Chess piece AI" that tries to get as close as possible to the player within the restrictions of their respective chess piece movement.
How
All enemy behavior follows consistent pulses (Nicely synced to the soundtrack's BPM) from an enemy manager actor. Enemies move every X number of pulses (slightly different for every enemy type) to the tile closest to the player along their possible movement path.
Enemies claim tiles wherever they move. If the best tile along the path is already claimed or occupied, the AI automatically finds the "next best" spot that still follows the chess pathing.
Why
The enemy behavior has key importance to the core loop of the game. This solution allowed me to have precise control over the frequency of enemy movement, allowing different kinds of enemies to move slightly offset from each other. This lets the player react and adapt to every move, emulating the experience of real chess grandmasters, becoming the "Charles Magnussen of chess with guns", if you will.
AI AND MOVEMENT
Diagram Legend
Enemy Behaviour Diagram
Debug enemy "tile claim"
What
In addition to the "beat" system that allows enemies to move at evenly offset times, enemies will also showcase to the player their future movement path for 1 beat before actually moving.
How
At the moment an enemy decides where to move to, they start drawing a line to that position. The target tile is instantly claimed at the beginning of the process, with failsafe protocols to ensure only 1 enemy gets to claim a tile at a time in case multiple enemies decide to move to the same place on the same frame.
Why
Better enemy feedforward allows players to engage in more reactive rather than predictive gameplay, contributing to the engaging player experience while not undermining the deliberate aspects.
IMPROVING ENEMY FEEDFORWARD AND PREDICTABILITY
Enemy Feedforward Diagram
A big part of this project was working within a provided template project and maintaining clean, well-commented, and expandable code throughout that performed well.
TECHNICAL IMPLEMENTATION AND PROJECT MANAGEMENT
All game logic was implemented in Unreal Engine 5 utilizing
Blueprints, the code was kept neatly organized with plentiful comments and names following Epic's Naming Convention.
My code was also completely non-destructive to the provided template, building upon the original parent classes and re-utilizing logic wherever possible.
BLUEPRINTS
Player Blueprint Snippet
Enemy AI Blueprint Snippet
Inevitably, bugs kept popping up throughout development, some more game-breaking than others. Very early on, I created a sheet to keep track of them and assign priority levels. Level 3 bugs were pretty much public enemy number 1 while almost all level 1 issues were only tackled in the last few weeks of development.
BUG TRACKING
Snippet of bug tracker sheet
Enemy waves were hand-crafted as that gave me greater control over the game's difficulty curve, an aspect essential to ensuring the challenging experience doesn't become an unfair experience.
By assigning semi-arbitrary difficulty numbers to each enemy type, I was able to create an estimated difficulty curve that allowed me to gauge if any waves had abnormal spikes and overall maintain the "introduce enemy/expand on the enemy" cycle.
Each dip in the curve is the introduction of a new enemy type, that is later combined with all previously introduced enemies, slowly increasing the difficulty until the next enemy type is introduced. This cycle continues up until the final boss, which requires the player to utilize all the knowledge they've gathered over the game to defeat them.
ENEMY WAVE LOGIC AND DESIGN
Enemy Wave Tracker sheet
Approximate Difficulty Curve
Enemy Waves Examples
As a game designer, the main goal of this project was to design the game's systems and gameplay. To ensure all mechanics are properly conveyed (and to add a little bit of extra charm!) I also invested some time into creating a variety of sprites and sound files for the game.
ART AND AUDIO
SPRITES
The enemy designs themselves did not require much iteration, but their colors and things like outline thickness had to be iterated upon several times to ensure each enemy would be instantly recognizable in motion, and easily distinguished from it's "dead" variant.
Enemies
Dark Variant
Dead Variant
Player
"Chuck Chuns"
Logo
AUDIO
In addition to implementing and mixing the 59 in-game SFX for things like weapon reloads, bullet hits, and such, I created a unique song that has it's BPM synced to the enemy movement, along with various variations for the different in-game situations.
POSTMORTEM
What went well
-
Strong Core Gameplay: The player's second-to-second actions feel very polished and satisfying, hitting the desired experience targets very often when I tested the game with other people.
-
Visual Appeal: The simple art style fits the game very well and gives it an extra layer of appeal that makes it stand out.
-
Great Execution on Concept: I'm very proud that the final game not only maintains the initial "enemies are the weapons" idea but fully integrates it into its gameplay in a fun and unique way.
What went wrong
-
Lack of higher gameplay levels: The core gameplay is a solid base to build upon, but as it is, the game does not offer much more than the 50 enemy waves that are not particularly replayable.
What I learned
-
Playtest, playtest, playtest: Every iteration of CHUNS was 100% guided by playtesting feedback from colleagues, friends, and lecturers. Things I thought to be intuitive proved poorly communicated for someone who hasn't been playing the game full-time for the past 4 weeks.
-
Build the game around the USP: Building the game around the idea of "enemies are weapons" and the desired player experiences ensured I was moving closer to what I initially set out to do with every iteration, having a final goal more or less defined helped determine what needed to be done while keeping it open enough to find what worked best in practice.
-
Restriction breeds creativity: It is often when working with relatively high restrictions that I have my most interesting workarounds and ideas.