Skip to content

NEhnes/Samurai-Skirmish-Fighter-Game

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

90 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

2D Fighter Game - ICS4U Capstone Project

Demo stuff is under releases!

A desktop fighting game built in C# demonstrating core software engineering principles including polymorphic architecture, state management, real-time collision detection, and collaborative development practices. Completed as an ICS4U capstone project within a 2-3 week timeline.

Project Overview

This project showcases the design and implementation of a game engine emphasizing clean game architecture and efficient resource utilization under time constraints. The system was structured around reusable, polymorphic components - an architectural decision that enabled rapid prototyping and multi-developer collaboration on a constrained schedule.

Key Accomplishment: Designed a polymorphic Character class system that reduced implementation time for new character variants by ~70%, allowing the secondary developer to quickly implement character-specific logic without understanding the underlying engine architecture.

Architecture & Design Decisions

Polymorphic Character System

The core design uses abstract inheritance to separate game mechanics from character-specific implementations:

  • Base Character class handles all shared logic: physics, animation state machines, collision detection, input processing, and frame rendering
  • Derived classes (RedSamurai, BlueSamurai) override only character-specific hitbox/hurtbox geometry and attack parameters
  • Virtual method pattern (GetHurtBox()) enables per-character collision boundaries without duplicating physics code

Impact: This design choice allowed one developer to work on character implementation while another refined engine systems in parallel. New characters can be added in ~30 lines of code (defining sprite frames + attack parameters), versus hundreds if each character contained its own physics/collision logic.

State-Driven Animation & Attack System

The Attack class encapsulates all attack metadata as discrete, reusable objects:

public class Attack
{
    public int StartupFrames;      // Frames before hitbox activates
    public int ActiveFrames;       // Frames hitbox is live
    public int HitstunFrames;      // Frames opponent is stunned
    public List<Rectangle> Hitboxes;
    public List<Image> Frames;
}

Characters maintain a state machine (currentState: "idle", "run", "attack1", "stunned", etc.) that determines which animation frames and collision boxes are active. This separates animation logic from game logic, making both easier to debug and extend.

Frame-Accurate Collision Detection

Hitbox and hurtbox validation occurs every frame during the attack active window:

  • Hitbox (attacker's strike zone): Only active between StartupFrames and StartupFrames + ActiveFrames
  • Hurtbox (defender's vulnerable area): Per-frame boundary that adapts to animation state
  • One-hit-per-attack rule: hitLanded flag prevents double-counting the same attack frame

This precision is critical for fighting game feel—startup frames create mind-game depth, active frames define spacing/range, and hitlag ensures impact feedback.

Technical Skills Demonstrated

Software Engineering Principles

  • Polymorphism & Inheritance: Base class encapsulates shared behavior; derived classes customize without duplication
  • State Machines: Clean separation of game states (idle, attacking, stunned, jumping) with per-state logic
  • Composition: Attack objects are composed into Character, allowing data-driven configuration
  • Separation of Concerns: Physics, rendering, input, and collision detection are logically isolated

Real-Time Systems

  • Fixed timestep game loop: 60 FPS target using Windows Forms timer with frame-count-based animation
  • Concurrent physics: Gravity, knockback, and animation counters update independently each frame
  • Responsive input handling: PreviewKeyDown/KeyUp events decouple input state from physics updates

Collaborative Development

  • Git workflow: Managed parallel development using pull requests and merge conflict resolution
  • Code organization: Clear module boundaries (GameScreen, Character, Attack, UI screens) enabled independent work
  • Documentation: Inline comments explain attack timing, collision logic, and animation frame mapping

Feature Breakdown

Core Gameplay

  • Two-player local fighting with independent hitbox/hurtbox systems per character
  • Attack types: Light ground attacks, heavy attacks, aerial attacks with startup/active/recovery frame precision
  • Physics: Double jump, gravity, friction-based knockback with decay
  • Hitstun/Hitlag: Stun duration and brief screen freeze on successful hit impact
  • Round system: First-to-2 wins with persistent leaderboard tracking

Engine Features

  • Frame-by-frame animation: Sprite array indexing synced to game loop
  • Directional flipping: Efficient horizontal flip using RotateFlip for both-direction sprite rendering without duplicate assets
  • Screen shake: Procedural camera offset on collision for impact feedback
  • Debug mode: Real-time hitbox/hurtbox visualization (Toggle with Esc)

User Interface

  • Screen management: Polymorphic UserControl system for menu navigation (Menu → Name Input → Game → Win Screen → Leaderboard)
  • Data persistence: XML-based leaderboard tracking wins across sessions
  • Health bars: Real-time visual feedback with player names

Development Context

This project was completed as a pair-programming exercise with distinct role separation:

  • Primary Developer (Author): System architecture, physics engine, collision detection, state machine design, core class hierarchies
  • Secondary Developer: Character asset integration, attack parameter tuning, UI asset placement, feature enhancement

The polymorphic architecture was specifically designed to allow the secondary developer to implement new characters without requiring deep understanding of the engine—they only needed to define sprite arrays and attack properties in the derived class constructor.

Technical Stack

  • Language: C# .NET Framework (Windows Forms)
  • IDE: Visual Studio 2022
  • Target: Windows Desktop (x64)
  • Graphics: GDI+ (System.Drawing)
  • Audio: Windows Media Player API
  • Data: XML (leaderboard persistence)

Files & Structure

File Purpose
Character.cs Base class: physics, animation, collision, input handling (~470 lines)
Attack.cs Attack metadata container: frames, hitboxes, timing
RedSamurai.cs, BlueSamurai.cs Character implementations: sprites, attacks, hurtboxes (~100 lines each)
GameScreen.cs Main game loop, collision detection, round management
Form1.cs Window management, screen transitions, background music
MenuScreen.cs, NameInputScreen.cs, WinScreen.cs, LeaderBoardScreen.cs UI flow

Skills for Engineering Roles

This project demonstrates capabilities aligned with firmware and systems engineering:

  • State Machine Design: Core pattern in embedded systems (motor control, protocol state machines, device modes)
  • Real-Time Constraints: Fixed timestep, frame-accurate updates, input-to-output latency awareness
  • Collision & Boundary Detection: Geometric computation similar to robotics collision avoidance and sensor calibration
  • Polymorphic Abstraction: Hardware abstraction patterns (e.g., device drivers, sensor interfaces)
  • Data-Driven Configuration: Attack parameters as discrete, reusable objects—analogous to firmware config structures
  • Git & Collaborative Development: Essential for multi-engineer firmware projects
  • Debugging & Profiling: Hitbox visualization debug mode mirrors approach to logging/telemetry in embedded systems

Running the Project

  1. Open in Visual Studio 2022 (.NET Framework target)
  2. Ensure Windows Forms designer dependencies are installed
  3. Build and run (F5)
  4. Navigate: Menu → Enter Names → Play → View Leaderboard

Controls:

  • Player 1 (Red): WASD (move), Q/G (light attack), E/V (heavy attack)
  • Player 2 (Blue): Arrow Keys (move), P/NumPad1 (light attack), O/NumPad3 (heavy attack)
  • Debug: Esc (toggle hitbox/hurtbox overlay)

Demo

See Full-Round.mp4 for a sample gameplay session showing attacking, movement, collision detection, and round progression.

Future Enhancements

  • Networking for online play (client-server architecture with lag compensation)
  • Additional characters with unique move sets (demonstrates scalability of polymorphic design)
  • Replay system (frame-based input recording)
  • Advanced move types: combo detection, special moves, blocking mechanics

Author: Nathan Ehnes
Timeline: 2-3 weeks (ICS4U Capstone)
Status: Complete / Personal Enhancement Phase

About

No description, website, or topics provided.

Resources

Stars

Watchers

Forks

Packages

 
 
 

Contributors 2

  •  
  •  

Languages