Comprehensive Level System for your Roblox game (with saving!)

:bar_chart: Level System: A Flexible Multi-Progression System for Roblox

What is it?

Level System is a centralized, config-driven system that lets you create unlimited independent progression systems (levels, ranks, stages, pet levels, weapon mastery, etc.) without writing repetitive code. You can either use this as a guide to learn how to save using data store (ProfileService), or actually use this level system to seamlessly add levels to your characters, items, or pets.

WITH TESTING SCRIPTS SO YOU CAN MESS AROUND WITH LEVELS, REBIRTHS, ETC.

:sparkles: Key Features

  • Multiple Level Types - Define unlimited progression systems in one config
  • Flexible Scaling - Linear or exponential growth formulas
  • Rebirth Support - Multiple rebirth families with custom names
  • Auto-Profile Generation - Profile data structure generates automatically
  • Dynamic Types - Add pet/weapon leveling systems at runtime
  • Zero Boilerplate - Add new types without touching core code
  • Industry Standard - Built on ProfileService/ProfileStore for reliable data persistence
  • Beginner Friendly - Easy to configure, add, or remove level types without coding experience
  • Plug & Play - Quick installation with automatic or manual setup options

:package: Installation

Choose the installation method that works best for you:

Method 1: SuperbulletAI (Recommended - Automatic)

  1. Download and install SuperbulletAI: https://ai.superbulletstudios.com/
  2. Prompt add level system, wait for 60 seconds for it to process it!
  3. Everything is configured and ready to use!
  4. (PS: Don’t forget to enable Enable Studio Access to API Services

Method 2: Manual Setup with Rojo

  1. Clone or download from GitHub: GitHub - Froredion/Level_System: template level system for your roblox game by SuperbulletAI
  2. Use Rojo to sync the files to your Roblox game
  3. Follow the setup instructions in the repository

Method 3: Roblox Place File

  1. Download:
    levelsystem.rbxl (178.7 KB)

  2. Open the file, publish and Enable Studio Access to API Services

:wrench: Easy Configuration

Adding or removing level types is as simple as editing a config file - no coding required! Just add or remove entries in the Types table:

Types = {
    levels = { ... },    -- Remove this whole array to remove levels
    ranks = { ... },     -- Remove this whole array to remove ranks
    prestige = { ... },  -- Remove this whole array to remove prestige
}

Perfect for beginners learning to create their first leveling system!

:rocket: Quick Example

Basic Setup

-- In LevelingConfig.lua
local LevelingConfig = {
    Types = {
        levels = {
            Name = "Level",
            ExpName = "EXP",
            MaxLevel = 100,
            MaxRebirth = 10,
            RebirthType = "rebirth",
            Scaling = { Formula = "Linear" },  -- Uses global formula
        },
        ranks = {
            Name = "Rank",
            ExpName = "Honor",
            MaxLevel = 50,
            RebirthType = "ascension",
            Scaling = {
                Formula = "Exponential",
                Base = 50,
                Factor = 1.25,
            },
        },
    },
    
    Rebirths = {
        enabled = true,
        Types = {
            rebirth = {
                Name = "Rebirths",
                ShortName = "R",
                ActionName = "Rebirth"
            },
            ascension = {
                Name = "Ascensions",
                ShortName = "A",
                ActionName = "Ascend"
            },
        },
    },
    
    Scaling = {
        Formulas = {
            Linear = { Base = 100, Increment = 25 },
            Exponential = { Base = 50, Factor = 1.25 },
        },
    },
}

return LevelingConfig

Usage in Code

-- Server
LevelService:AddExp(player, 100, "levels")
LevelService:PerformRebirth(player, "ranks")

-- Client
local levelData = LevelController:GetLevelData("levels")
local canRebirth = LevelController:GetRebirthEligibility("ranks")

:paw_prints: Dynamic Level Types (Pet/Weapon Systems)

Create per-entity progression systems:

-- PetConfig.lua
local PetConfig = {
    dragon = {
        LevelName = "Dragon Level",
        ExpName = "Dragon EXP",
        Scaling = { Formula = "Exponential", Base = 100, Factor = 1.3 },
    },
    cat = {
        LevelName = "Cat Level",
        ExpName = "Cat EXP",
        Scaling = { Formula = "Linear" },
    },
}
return PetConfig
-- In LevelingConfig.lua (bottom)
local AddExternalTypes = require(script.Parent.Parent.Utilities.Levels.AddExternalTypes)
local PetConfig = require(script.Parent.PetConfig)

AddExternalTypes.Add(LevelingConfig, PetConfig, "_level")
-- Creates: dragon_level, cat_level, etc.

return LevelingConfig

:floppy_disk: Data Persistence with ProfileService

This system uses ProfileService/ProfileStore for industry-standard data management:

  • Reliable - Automatic session locking prevents data loss
  • Scalable - Handles thousands of concurrent players
  • Battle-Tested - Used by top Roblox games
  • Auto-Generated - Profile templates are built automatically from your config

Your level data is automatically saved and loaded without any additional code. The system handles:

  • Profile creation and loading
  • Data replication to clients
  • Safe session management
  • Automatic structure updates when you add new level types

No need to worry about DataStore management - it’s all handled for you! (credits to loleris for the ProfileService)

3 Likes

seems like this is just an advertisement for this AI that no one actually needs

2 Likes

No one’s forcing you to use the 1st option, use the 2nd open-sourced GitHub repository then.

SuperbulletAI exists because there’s no underlying technology that supports automatic retrieval and unpacking. TRF is a new technology I invented to make that possible, this wouldn’t have been possible to set up in 60 seconds otherwise as you’d need to connect it to a data store manually and do the manual setup to your game which would take you probably few hours tops. If you don’t want to use it, then don’t.

I am trying to wrap my head around this entire thing.

I came here looking for a level system just to see if I can utilize some pieces of it for my project, learn how to make different XP curves and whatnot.
What I found was something that takes as much effort to read as it does to figure out a new company’s codebase. I feel like this could’ve been done in a much simpler way, not to mention without the use of a framework like knit.
Putting one of the files into an AI checker shows that its most likely written by AI, which makes sense considering the first install option.
Speaking of, its funneling people into either going with a Roblox slop game generator, or by introducing something that doesn’t fit cleanly into a project.

This repo isn’t “needlessly complex”, it’s production-ready: the level, rebirth, and EXP logic is modular (use just that if you want).

It is intentionally modular and built for scalability, and if you’re a strong programmer, you can easily extract just the XP progression logic without using the full Knit-based setup.

an AI-checker claim is not evidence of authorship. Even Google’s codebase is heavily commented because that’s what the software engineers are hired for, is to build code that is highly scalable.


If something like this simple is very messy for you, you are a beginner scripter - and most Roblox beginners code in a spaghetti, non-modular way. this repo exists as a guide to fix exactly that by following production standards and using proper ProfileService/ProfileStore integration for data handling.

TL;DR
This is how exactly strong programmers/top developers who’s earning $1M+/yr code a Roblox game in JUST 7 DAYS. Modular, clean, and production-ready. Knit is optional.

This repo can be as complex as need be, but I specifically spoke about how the system could’ve been made in a simpler way. It can be “production-ready” all the same, self contained in a single module without the bells and whistles.
Going under the assumption that the module is meant for everyone, beginners will be attempting to figure it out, and then they’ll be stuck either on the download instructions, where they end up being funneled into an AI game generation site, or into a tool that isn’t simple to figure out. Most resources on here rely on the creator hub, or use .rbxm files for a quick import.

However, you’re already going through the hurdle of utilizing AI in all facets of your development, which makes me wonder why you’re going through the trouble of debating this. If it was an issue that I mentioned AI generation in your code, you wouldn’t be advertising the first download option.

At no point did I say that it was very messy, nor that it was difficult for me to learn. I said it was a system that would’ve taken a longer time to read into and learn. I won’t call myself an expert or anything similar, because I get outclassed by colleagues with a year less experience, but I can pinpoint and criticize for the sake of a more broader set of developers.

Despite this, there are still a dozen other ways to make modular, clean, and production-ready code without this much content. Knit is woven (fitting name) into the code, which just adds further stress to the engine, unnecessary in projects that don’t use knit. To say that this is the only way people do it is bugging me.

I’ll add a .rbxl or .rbxlx in the near future (few days) for this. (EDIT: Added it)

Not an issue at all. Just that it’s often false-positives if clearly written by a well-versed user.

Understandable! I apologize if that may have come off as rude.

Knit being “woven” into the code is actually its core advantage, not a flaw. It solves cyclical dependencies and keeps shared logic organized across interconnected systems, something most “simpler” modular setups struggle with once a project scales. This is a good approach, but cyclical dependencies is very confusing for most new users. Also, the claim that it “adds stress to the engine” isn’t accurate, Knit is extremely lightweight and doesn’t affect performance in any measurable way. The only “cost” it adds is structure, which pays off in long-term maintainability and team collaboration.

There are many ways to write modular code, but Knit offers a proven, scalable pattern that keeps complexity manageable. You can strip it out for small prototypes, but for production-level games, that structural consistency saves massive time down the line. Either use Knit or ECS. We chose Knit because it uses OOP and is more easily understandable for beginners. An ECS style of this template system may come.

Knit in our case isn’t used as a full-blown framework, it’s meant to be a light parent system (under 300 lines of code) designed to manage shared public methods and prevent cyclical dependencies between interconnected systems. It’s a modified version of Knit with improved error handling and clearer warnings.

I’m posting about it soon. (SuperbulletFrameworkV1-Knit & SuperbulletFrameworkV1-ECS)