Summary
Type: Plugin
Completed: Released (Post-Release)
Acquirable: Shareable Link
My Role: Technical Game Designer
Time Frame: 2 months part-time
Overview
The Menu System Plugin is a scalable, C++ driven UI framework I designed to streamline menu development across multiple projects. Built with a focus on predictable behaviour, designer-safe workflows, and clean architectural separation, it enables teams to create full menu flows without specialised UI knowledge. The system is already being used successfully in an unannounced game, where designers onboarded quickly and were able to build screens independently using the accompanying dual-audience documentation.
Purpose
I created this system to solve three core problems I kept encountering across projects:
1. Menus scale badly when built only in Blueprints.
2. UI frameworks like CommonUI are too heavy for small or mid-sized teams.
3. Designers and programmers often step on each other’s toes, causing inconsistent behaviour.
My goal was a system that is:
• Generic (works in any project)
• Scalable (handles dozens of screens cleanly)
• Beginner-friendly
• Strictly separated (programmers define behaviour, designers build screens)
• Fast and reliable through a C++ backend with safe Blueprint tools
How It Works
Layer-Based Architecture
Menus belong to purpose-driven layers. The following are some examples of what these could be:
• Popup
• Main
• Background
This ensures predictable input, visibility, and behaviour without manual wiring.
C++ Core + Blueprint Surface
The heavy lifting lives in C++, while designers work through a minimal set of high-level Blueprint functions such as:
• Create and Open Menu
• Show Menu
• Hide Menu
• Return to Previous
• Query Active Menus
This protects the system from misuse while giving designers creative freedom.
Automatic Input Detection
The subsystem tracks navigation mode (mouse / keyboard / gamepad / touch) and routes focus automatically across menus.
Used In Production
The plugin is currently being used in an unannounced game project where:
• Designers with no formal UI background built complete menu screens in days
• Programmers were able to extend behaviours easily
• The layer system prevented conflicting logic or broken menu states
• The documentation allowed the team to adopt the system with almost no onboarding
• The project scaled from simple prototypes to organised, multi-screen flows without rework
This validated the plugin’s usability, robustness, and general-purpose design.
Documentation Approach
The documentation is intentionally written for both programmers and designers:
For Programmers
• Architecture overview
• Extension points
• Data flow & lifecycle
• C++ examples
• Performance notes
For Designers
• “If you want to do X, use these Blueprint nodes”
• Step-by-step examples
• Layer behaviour explained visually
• Clear, predictable rules for input and focus
This dual approach ensures anyone can work with the system safely.
Why It Shows My Technical Game Design Skills
This project demonstrates my ability to:
• Architect scalable, purpose-driven systems
• Build tools that simplify complex workflows
• Create designer-friendly abstractions
• Write documentation that supports different disciplines
• Combine UX thinking with technical implementation
• Make tools usable in real production environments
It highlights my strength in bridging programming and design — creating systems that reduce friction, prevent spaghetti projects, and allow small teams to scale up UI without frequent refactoring.
What I'd Do Next Time
Next time, I would establish an early documentation outline and iterate on it through designer/programmer feedback sessions. While I shifted to this method partway through, adopting it from the start would have made the documentation phase faster and more efficient.
