Skip to content
shr0x edited this page Mar 25, 2026 · 1 revision

About This Project

This project is not just a gamemode.

It is designed to be a foundation framework for building RAGE:MP roleplay servers with:

  • clear structure
  • predictable behavior
  • scalable architecture
  • developer-friendly patterns

Why This Project Exists

Most RAGE:MP projects suffer from the same problems:

  • no structure
  • tightly coupled code
  • unclear data flow
  • poor separation of concerns
  • no documentation

As projects grow, they become:

  • harder to maintain
  • harder to debug
  • harder to extend

This framework was created to solve those issues.


Core Goals

1. Clarity Over Complexity

Every system should be:

  • understandable
  • predictable
  • easy to trace

You should always know:

  • where data comes from
  • where it goes
  • who is responsible for handling it

2. Server is the Source of Truth

All gameplay logic must live on the server.

The server is responsible for:

  • validation
  • game state
  • persistence
  • authority

The client and frontend should never be trusted.


3. Separation of Concerns

Each layer has a clear role:

Layer Responsibility
Server Logic & authority
Client Bridge
Frontend UI

This separation ensures:

  • cleaner code
  • easier debugging
  • better scalability

4. UI is Optional

The framework is designed so that:

  • systems can exist without CEF
  • gameplay logic does not depend on UI

CEF is used only when needed.


5. Predictable Event System

Events follow a structured format:

target:name

Examples:

chat:sendMessage
inventory:moveItem
hud:setData

This ensures:

  • consistency
  • easier debugging
  • better scalability

6. Developer Experience First

The framework is built for developers.

It aims to:

  • reduce confusion
  • remove guesswork
  • provide clear patterns
  • improve readability

7. Structure Over Freedom

This framework is opinionated.

It encourages:

  • consistent folder structure
  • consistent naming
  • defined patterns

While it may feel restrictive at first, it leads to:

  • better long-term maintainability
  • easier collaboration
  • cleaner systems

What This Project Is NOT

This project is NOT:

  • a complete gamemode
  • a feature-heavy server
  • an opinionated gameplay system

It is a foundation, not a finished product.


How You Should Use This Framework

You should use this framework to:

  • build your own systems
  • design your own gameplay
  • extend existing features
  • create your own gamemode

Recommended Approach

  1. Understand the architecture
  2. Follow existing patterns
  3. Build small features first
  4. Expand into larger systems
  5. Keep logic server-side

Common Mistakes

1. Putting logic in frontend

Frontend is UI only.


2. Trusting client data

Never trust:

  • client
  • frontend
  • user input

3. Breaking structure

Avoid:

  • random file placement
  • inconsistent naming
  • mixing responsibilities

4. Overcomplicating systems

Start simple.

Scale when needed.


Mental Model

Think of the framework like this:

  • Server = brain
  • Client = messenger
  • Frontend = screen

All important decisions happen in the brain.


Final Note

This framework is designed to grow with your project.

The more you follow its structure:

  • the easier your development becomes
  • the cleaner your code stays
  • the more scalable your systems are

Summary

This project exists to provide:

  • structure
  • clarity
  • scalability
  • maintainability

It is a tool to help you build better systems — not a system itself.

🚀 Getting Started

🧠 Architecture

🎮 Features

🛠 Development

❗ Help

Clone this wiki locally