Snowkid Warfare
itch.io ↗Context
Snowkid Warfare is a stylized, fast-paced prototype built during a 2-week game jam at Abertay. Built upon a twin-stick shooter framework, the goal was to capture the chaotic energy of a childhood snowball fight but make it feel tight and satisfying to play, not just chaotic.
Game Playthrough
Key Accomplishments & Skills
Systems And Followers
Designed and built the follower AI and power-up systems, keeping gameplay pacing at the centre of every decision.
Rapid Prototyping
Iterated on the core loop and spawner logic quickly under a hard 2-week deadline, learning a lot about what to cut and when.
Level Design
Kitbashed a top-down combat arena focused on movement freedom and fast-paced action, working alongside programming to ensure more replayability by using randomized spawn for several gameplay components.
Engineering The Systems
1. Follower Mechanics & AI
Outcome: The follower system ended up feeling organic. Followers fan out naturally instead of stacking rigidly around the player, which made combat much more readable and the movement much more natural.
The Problem: When followers snapped rigidly around the player, they felt "glued" and inorganic, which made the movement feel unnatural and clunky.
The Solution: I built a delayed rotation interpolation system in blueprints. Followers now buffer their pathfinding inputs so they trail behind and spread out naturally, instead of mirroring the player exactly.
Reflection: Next time I'd look into steering behaviours instead of strict buffering. I think that would give more natural-feeling evasion without as much manual tuning.
2. Combat Pacing & Power-Ups
Outcome: Adding the power-up system turned a fairly static shooting gallery into something where players actually moved around and took risks.
The Problem: The core loop encouraged players to stand still and hold the trigger, and moving around felt unrewarding and purposeless.
The Solution: I designed a modular power-up system with buffs such as rapid fire and health regeneration, that rewarded aggressive repositioning and environmental exploration in order to acquire the power ups.
Reflection: I'd use Data Tables to define buff values next time. Adjusting hardcoded variables every iteration was more tedious than I'd expected.
3. Dynamic Spawner Architecture
Outcome: Players stopped camping in corners. The dynamic spawner pushed them to move around the map consistently.
The Problem: Statically placed buffs meant players could just "spawn camp" them, which killed replayability, pacing and fun.
The Solution: I built a spawner that drops randomized buff presents around the map, turning pickups into small objectives that pull players out of their comfort zones and encourages movement.
Reflection: Object pooling would have helped here. During heavier fights there were some performance spikes from spawning and destroying so many actors.
4. Level Design & Tactical Flow
Outcome: The arena ended up being readable and functional. Cover was clear, and the choke points felt intentional.
The Problem: Two weeks didn't leave room for any custom modelling or excessive planning, but the arena still needed to support twin-stick combat properly.
The Solution: I kitbashed the environment using the Stylized Winter City pack, focusing on making the map playable and prioritizing functionality and flow over anything else.
Development Realities & Constraints
Working within a strict 2-week timeline forced ruthless prioritization. Several ambitious systems were ultimately scoped down or cut to ensure the core loop remained polished and performant.
Follower Logic Simplification
Early designs featured autonomous "Snow Kids" that would capture enemy points and automatically retreat if overrun. Due to time constraints, I scrapped the autonomous retreating logic, simplifying the system so companions could only be recalled manually when within the player's radius.
System Dependency Cascade
When the Enemy HP architecture ran over schedule, it didn't just delay one feature, it triggered a cascade that cut 11 of the 17 planned buffs. Damage Amplification, Reflection, Piercing, and Slow required a functioning HP system to be testable at all. Rather than rush an unstable implementation, I made the call to cut the entire dependency branch and ship the 5 most stable, self-contained modifiers instead. This kept the core loop shippable and polished within the jam window.
Buff Pool & Dependencies
I conceptualized an expansive pool of 17 temporary buffs and 10 permanent buffs across 3 active slots. However, sweeping buffs like Ghosting and Omni-directional Shooting were scrapped when dependent systems (like the Enemy HP architecture) took longer than expected to implement. I prioritized shipping the 5 most stable, high-impact modifiers instead.