top of page
wideshot.png

System Crash

Revamping Retro

About System Crash

University Project | Unity | 2-5 Months

Based on the theme "modernising retro", System Crash aims to explore the hit classic SMASH TV and reimagine it with a sci-fi twist.

🔗 GitHub 🔗

❌

While I'm not happy with the final visual quality of the public release, the back-end work is something I still think is good to showcase. A playable version of the game can be accessed here.

⚠️ This was a team effort, as such I will only be discussing elements I developed myself. 

Notable Work

  • A data driven weapons system, customisable in-engine using scriptable objects.

  • An extendable hazard and status effect system.

  • Finite state machine AI for a variety of enemies.

Core Gameplay

At it's core SMASH TV was a top down arena style run & gun game, which we tried to emulate as closely as possible when designing the core loop for System Crash.

​

The player moves through several urban locations, in which they are then mobbed by advancing enemies of various abilities. Each level is designed around how the geometry and enemy types play off of one another to create engaging combat scenarios.

​

Level1.png
Level2.png

Data Driven Weapons

WeaponData is a class that holds all data required for a gun to function, which is then exposed to the editor via scriptable objects to allow easy creation of new weapons within the inspector.

​

WeaponBase is a companion class to WeaponData that utilises the data within a generalised implementation of weapon behaviour.
This separation was instrumental in allowing a variety of weapons for both the player and AI without necessitating distinct implementations for both.

WeaponData 2.png
WeaponData 1.png

Environmental Hazards

I instituted a simple system for environmental hazards causing status effects since the scope of them was intended to be small and reusable on an broader scale.

​

EffectBase is an abstract class that enforces application, removal and the behaviour of each status, which depends on child implementations per object.

​

In future implementations I would make status effects a separate data type that can be defined generally, with their application handled by calling an event.

StatusEffects.png

Enemy AI

While finite state machines are an older approach to game AI, they still function more than well enough for this scale and can be built fairly quickly. I based the state pattern on elements from this book with some modifications for ease of use.

​

There are 5 states:

  • Attacking - engaging in combat with the player

  • Chasing - actively moving towards the player

  • Fleeing - actively moving away from the player

  • Guarding - waiting a distance away from the player 

  • Moving - moving to a given location

Units.png

Analysis & Thoughts

This project wasn't ideal for a variety of reasons, developing it during covid and under odd university expectations being some of the lower end problems. I make no secret that I'm displeased with many of the visuals, with the animations being the most problematic as the person designing the character/AI behaviour.

​

Nevertheless, I'm actually quite happy with many of the gameplay systems in the final product. Looking back some years later I'd definitely do things differently but the flexibility I managed to eek out of simple structures was an important lesson.

​

bottom of page