smithery/ArmaOverthrow

overthrow-architecture

Overthrow mod architecture patterns, naming conventions, and project structure

Installation

$ npx skills add smithery/ArmaOverthrow --skill overthrow-architecture

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

Also in this package

Other skills from smithery/ArmaOverthrow.

npx skills add smithery/ArmaOverthrow

Browse all from smithery/ArmaOverthrow

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Skill metadata

Parsed from SKILL.md frontmatter.

Version1.0.0

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 4,785 B
  • docs SUMMARY.md 108 B

History

  1. First recorded snapshot · 0 installs

SKILL.md

Overthrow Architecture

Quick reference for Overthrow mod-specific patterns and conventions. For detailed patterns, see resource files below.


When to Use This Skill

Use this skill when:

  • Creating new Manager or Controller components
  • Understanding Overthrow's architecture patterns
  • Following project naming conventions
  • Organizing code in the correct directories
  • Accessing global systems via OVT_Global
  • Setting up new features or systems

Quick Reference

Manager Components

Singleton components on OVTOverthrowGameMode managing entire systems. Use GetInstance() pattern with static sInstance. Init() and PostGameStart() called manually by game mode.

See: managers.md for complete manager patterns

Controller Components

Non-singleton components managing individual entities (bases, towns, camps). Register with manager in constructor. Multiple instances can exist simultaneously.

See: controllers.md for complete controller patterns

OVT_Global Access

Central static class providing easy access to all manager singletons. Use OVT_Global.GetSomething() instead of calling GetInstance() directly. Cleaner and more consistent.

See: global-access.md for access patterns

OVT_OverthrowController

The modular architecture for client-server communication, and since 2026-08-14 the ONLY one. Each player owns a controller entity carrying 17 specialized components, reached with OVT_ControllerComponent<T>.Get(). The legacy comms monolith it replaced is deleted. Built-in progress tracking support.

See: overthrow-controller.md for complete pattern

File Organization

Scripts in Scripts/Game/, configs in Configs/, prefabs in Prefabs/. Specific subdirectories for Components, GameMode, Entities, Controllers, UI, UserActions.

See: file-structure.md for directory structure

Coding Standards

OVT class prefix, m member prefix, type prefixes (mi, mf, ms, mb, ma, mm). Doxygen-style comments. Getters/setters for protected members.

See: coding-standards.md for complete conventions


Critical Conventions

  • ✅ OVT prefix - All Overthrow classes start with OVT
  • ✅ Managers are singletons - One instance per game mode
  • ✅ Controllers are instances - Multiple instances per entity type
  • ✅ Use OVT_Global - For accessing managers (not direct GetInstance())
  • ✅ Use OverthrowController - For new client→server operations (not PlayerCommsComponent)
  • ✅ Register in constructor - Controllers register with managers
  • ✅ Protected members - Use getters/setters for external access
  • ⚠️ Init() not automatic - Called manually by game mode or manager
  • ✅ Type prefixes - mi for int, mf for float, m_s for string, etc.

Architecture Hierarchy

OVT_OverthrowGameMode (entity)
├── OVT_SomeManagerComponent (singleton)
│   ├── Manages multiple controllers
│   └── Global system state
└── OVT_AnotherManagerComponent (singleton)
    └── Manages different system

Entity in World
└── OVT_SomeControllerComponent (instance)
    ├── Manages this specific entity
    └── Registered with relevant manager

Resource Files

Detailed documentation organized by concern:

  1. managers.md - Singleton manager pattern, GetInstance, Init, PostGameStart
  2. controllers.md - Instance controllers, registration, lifecycle
  3. overthrow-controller.md - NEW: Modular controller pattern for client-server operations
  4. global-access.md - OVT_Global patterns, accessing managers/systems
  5. file-structure.md - Project directory organization and file placement
  6. coding-standards.md - Naming conventions, documentation style, best practices

Common Patterns

Creating a Manager

  1. Extend OVT_Component
  2. Add corresponding OVT_ComponentClass
  3. Implement static s_Instance and GetInstance()
  4. Add Init() and PostGameStart() if needed
  5. Place component on OVT_OverthrowGameMode prefab
  6. Add accessor to OVT_Global

Creating a Controller

  1. Extend OVT_Component
  2. Add corresponding OVT_ComponentClass
  3. Register with manager in constructor
  4. Use protected members with getters/setters
  5. Attach to entity prefab or spawn at runtime

Accessing Systems

  1. Use OVT_Global.GetManager() for managers
  2. Use OVT_Global.GetController() for local controller
  3. Use OVT_Global.GetUI() for UI manager
  4. Use OVT_Global.GetPlayers() for player management
  5. Always check for null before using

Pattern: Start here for quick reference, dive into resource files for implementation details.