CodiushMaximush

The game-agnostic Unity framework underneath ClassicRPG. It ships as small, single-purpose assemblies, so any one system can be pulled into the next project on its own. The why behind it lives on the ClassicRPG card. This page is the running feature inventory.

Systems

• Core: The foundation the rest of the assemblies build on. Meant to hold primitives.
• Timers: Centralized boilerplate for anything having to do with time. Countdown, countup, curve, and frame timers. Plus, all the fun stuff around time manipulation like slow-mo, freeze frames, and time warping.
• Spawning: Building directly off Resources, Asset Bundles or Addressables is terrible. I just want to spawn a coin or whatever else I want using one line of code without making my load times ridiculous. Also includes related tools like weighted drop tables for the gamblers out there.
• 2D physics: Box2D is cool and all until it isn’t. Includes things like motors and sensors.
• Finite State Machines: Provides a few flavors of FSM for when the logic gets a little too intense for a single class. Behaviour Trees and Utility based graphs coming soon. (Probably)
• Steering: Character controllers can move characters. This package is all about making sure autonomous systems know where they can and can’t go. Nice for AI and smoother player input. (I keep getting caught on that tree when I sprint!)
• Global Events: When the game is about to save, or the player just died. A big thing just happened. Systems need to talk to each other without knowing anything about each other. Data driven with dumb Scriptable Object keys instead of hacky “Scriptable Object event channels” or statics that break on a domain reload.
• Data Pipes: For when I have data I want to move between classes that shouldn’t care about each other. A local data transfer object system meant for the Prefab level. (Might be removed, it causes too much prefab bloat)
• Persistence: Responsible for keeping the game world consistent between launches and scene loads. Each object yields a collection of key-value pairs for a flat dictionary per scene, uses a typed codec registry for primitive and recurring data types (bool, int, float, string, Vector2/3, Quaternion), GUID-based identity resolution. Built with save file migration in mind instead of as an afterthought. Kept async so my loading screens can be buttery smooth.
• SceneManagement: Unity sucks at this. Straightens out all the kinks into a system my games can reason about. Handles scene transitions, loading screens, and provides hooks for other systems to build on that actually make sense.
• Warping: A centralized way to get the player (and other objects) from point A, to point B. Even if they’re in different scenes. Data Driven.
• Input: Sits between Unity’s Input System and the rest of the game. Allows Cutscenes, AI, and other game systems to inject their own simulated input and block player input when it isn’t appropriate.
• InputIndicators: Automatically show the relevant icon for control prompts based on game context and the platform you’re actually using. Built to be reactive and provide juicy feedback for players.
• UI: A necessity after wrangling popups in games as much as I have. Handles popups, transitions, and flow orchestration so I don’t have to think about it anymore.
• UIStacks: Push/pop UI management, load UI with Addressables and stop them from overlapping weirdly.
• HUD: A re-usable way to have the HUD display information from a variety of sources, and have a plan for when those sources suddenly or temporarily don’t currently exist.
• Pausing and PauseMenu: Pause the game in a way where the rest of the game can react reasonably. Also provides a simple pause menu and player ability to get all that input arbitration goodness.
• Cutscenes: Re-use existing game systems to procedurally puppet characters around so I can lore-drop when I need to, and create re-usable sequences for other moments like getting an item out of a chest. Driven by script Coroutines so I’m not mucking about with Timeline.
• SimpleDialogue: Decision Trees? Man, I just wanted to look at this sign. Shows configured messages in order, gated by player input or a cutscene. Allows different controllers in case you want the dialogue panel for your sign to be different than the one used for talking to an NPC.
• Combat: So things can hit each other, and do things when they get hit. Like die, get knocked back, start a cutscene, or anything else.
• Damage: An abstracted system for other systems to build off of. What hit me? How much damage did it do? From what direction? What type of damage is it? That sort of stuff.
• Factions: For answering the surprisingly deep questions like “Do I hate you or like you?” and “Who am I?”. Defined by a configurable matrix map of relationships and supports runtime changes. Put a bunch of enemies in a room, randomize their factions, have a good time.
• Collectables: What’s the difference between picking up a coin, a key, or the Legendary Water Crystal Of Erasmus? Not much apparently. This system handles the boilerplate. A loose inventory system.
• Audio: For when you just want to play a beep when something happens. Audiosources are such a pain to manage. Wraps sound files inside a configurable ScriptableObject and provides an easy path for one off sounds that handles things like amplitude multiplication.
• Behaviours: Somewhat of a catch-all at the moment. Contains things like specialized sprite controllers for managing common shader/material changes on sprites, and generic AI behaviours.
• SignalArbiter: A system for managing competing data streams to flatten into a single, coherent output. Intended to be used with Unity’s animator. It doesn’t have to be, though.
• Character2DAnimation: 2D directional character animation, abstracted for NPC’s, Enemies, and the Player. Built on top of the SignalArbiter.
• AnimationAdapters: I got so tired of writing lines of code to hash parameter names and validate them. So I wrapped a generic solution in a variety of serializable utility classes.
• Topdown.Altitude: So, in topdown games, defining coherent behaviour to simulate depth is pretty hard. With this system, you can have flying enemies, hold things over your head, and fall into holes in the ground even though the game is 2D.
• Inspector field requirements (editor): I got sick of Editor log spam and OnValidate functions that try to do too much work. Just mark fields as red or yellow in the inspector so I know what I need to hook up or what is missing at a glance. Amazed this isn’t included by default.
• Editor tooling (editor): A bucket for editor only tooling used by CodiushMaximush.Core.

Integrations

Thin assemblies that wire two otherwise-independent systems together, so neither side has to know about the other. Each one depends on both halves while the systems themselves stay decoupled.

• CombatFactions: Answers questions like “Am I supposed to try to tackle you or ignore you?”.
• DamageFactions: Handles friendly fire logic.
• AbilitiesUI: bridges ability progress and feedback into the UI and HUD.
• SimpleDialogueUI: Adds UI for the Simple Dialogue System.
• Cinemachine: Neutral extensions for Cinemachine. Things like keeping a virtual camera bounded to a room, and blending between different rooms. The one integration that pulls in a third-party package.

From the devlog

When modularity and Animators don't mix — a concrete example of the framework/game boundary producing a better design.