CityRP game concept
Last updated
May be stale
This page was last updated ago, on 2 October 2026. Check what it says against the code before relying on it.
Created: 2026-09-18 Status: Approved. This captures the vision of a live game; it is not a pitch for a new one.
Read this before proposing a feature. The pillars are the test a design has to pass, and the anti-pillars are the things we have already decided not to do. Engineering conventions live in AGENTS.md; this document is about what the game is for.
Elevator Pitch
A persistent city roleplay gamemode for Garry's Mod where you hold a job, build your own corner of the city, and grow a character over months, alongside a community the systems keep pushing you towards.
Core Identity
| Aspect | Detail |
|---|---|
| Genre | Persistent multiplayer city roleplay, with sandbox building |
| Platform | PC, Garry's Mod (Source engine). Fixed; not a decision. |
| Target Audience | See Target Player Profile |
| Player Count | Multiplayer, a fleet of persistent servers |
| Session Length | Open-ended. No single session shape; players choose. |
| Monetization | Free to play, with optional membership ranks |
| Estimated Scope | Live service, ongoing |
| Comparable Titles | DarkRP and the serious-RP frameworks built on GMod |
Core Fantasy
A social sandbox. The draw is the community and the things players do to, with and for each other. Jobs, money, crime, property and clans are not ends in themselves; they exist to give people reasons to interact, and to give a character somewhere to grow.
Unique Hook
Like other city roleplay frameworks, and also you can build. Most RP frameworks forbid or heavily restrict sandbox construction. Here building is part of the roleplay: bases, shops, signs and contraptions are how players make the city theirs.
The second hook is that the game does not need a full server. Systems are built so that there is something worth doing when few players are on, and what you do alone still counts towards long-term growth.
Player Experience Analysis (MDA Framework)
Target Aesthetics (What the player FEELS)
| Aesthetic | Priority | How We Deliver It |
|---|---|---|
| Fellowship (social connection) | 1 | Community, clans, jobs that depend on other players, shared spaces |
| Expression (self-expression, creativity) | 2 | Sandbox building, property, signs, character identity |
| Fantasy (make-believe, role-playing) | 3 | Jobs, a persistent character, tools that support deep RP for those who want it |
| Submission (relaxation, comfort zone) | 4 | Gathering, crafting and job loops that work on a quiet server |
| Challenge (obstacle course, mastery) | 5 | Raids, policing, gunfights, the economy |
| Narrative (drama, story arc) | 6 | Player-driven stories; nothing scripted |
| Discovery (exploration, secrets) | 7 | Learning the systems and the map |
| Sensation (sensory pleasure) | 8 | Limited by the engine; not a focus |
Key Dynamics (Emergent player behaviors)
- Players seek each other out because a system gave them a reason to: a buyer, a customer, a patient, a suspect, a rival.
- Players build somewhere and then defend, run or show off what they built.
- Players come back to the same character because it has accumulated something.
- Players roleplay at the depth they are comfortable with, and the two ends share a server.
- A player alone on a quiet server still has something to do, and its output feeds the shared world when others arrive.
Core Mechanics (Systems we build)
- Jobs, across civilian trades, government, emergency services and crime.
- Sandbox building with per-player limits and prop protection.
- A player economy: items, property, vehicles, contraband.
- Gathering, crafting and system-driven job loops that work without other players.
- Long-term progression: MESKA skills and achievements, REP, playtime, clans.
Player Motivation Profile
Primary Psychological Needs Served
| Need | How This Game Satisfies It | Strength |
|---|---|---|
| Autonomy (freedom, meaningful choice) | No mandated playstyle or session shape; build what you want; roleplay as deeply as you want | Core |
| Competence (mastery, skill growth) | MESKA skills, REP, wealth, a base that gets better | Supporting |
| Relatedness (connection, belonging) | Community, clans, interdependent jobs | Core |
Player Type Appeal (Bartle Taxonomy)
- Socializers (relationships, cooperation, community). Primary. The game is built around them.
- Achievers (goal completion, collection, progression). Secondary, through skills, REP, property and wealth.
- Creators (building, making). Secondary, and the point of difference from other RP frameworks.
- Explorers (discovery, understanding systems). Incidental.
- Killers/Competitors (domination, PvP). Served only where the conflict is roleplay; see below.
Flow State Design
Not designed as a difficulty curve. Players set their own level of challenge by the job and the company they choose. Onboarding is an open question; see Risks.
Core Loop
Moment-to-Moment (30 seconds)
Talking to, trading with, working alongside or opposing another player; or placing and adjusting props.
Short-Term (5-15 minutes)
One unit of job work: a call-out, a sale, a harvest, a delivery, a raid.
Session-Level (30-120 minutes)
No single shape, and this is deliberate. A session may be a job shift, a building project, or whatever the player's group is doing. Players choose.
Low-Population Loop
What keeps a player engaged when few others are on:
- Gathering and crafting
- Building
- Skill and REP progression
- NPC or system-driven jobs
These are not a separate game. Their output (goods, skills, money, a finished base) feeds the shared world.
Long-Term Progression
Property, skills, REP, wealth and clan standing accumulate over months. Progress is not wiped.
Retention Hooks
- A character and a base that are still there tomorrow.
- People you know.
- Long-horizon unlocks through REP and skills.
Game Pillars
Five pillars. Each has a design test: the question to ask when two options are on the table. Two philosophies sit across all of them: one about how every system should feel to use, one about how every change must treat what players already have. Individual systems do not serve them; every system owes them.
Pillar 1: Community First
Social interaction is the product, and everything else exists to serve it.
Design test: between a feature that gets players talking to each other and one that doesn't, choose the one that does.
Pillar 2: A City You Can Build
Sandbox building is a first-class part of the roleplay, which most RP frameworks don't allow. CityRP derives from the base Sandbox gamemode, so the spawn menu and toolgun come with it. The work here is mostly to keep that intact: limits, prop protection and tooling, not a building system of our own.
Design test: when building causes a problem, fix it with limits, protection or tooling before you restrict building.
Pillar 3: Systems Create Reasons to Interact
Jobs, the economy, crime and clans exist to give players something to do with and to each other.
Design test: a new system should create at least one reason for two players to meet.
Pillar 4: Fun at Any Population
The game stays worth playing on a quiet server.
Design test: does this still work with three players on? If not, it needs a fallback, such as an NPC or a solo path.
Pillar 5: Long-Term Growth
Characters, property, skills, REP and clans build up over months, and progress is never thrown away.
Design test: does this give a returning player something that lasts?
Philosophy: Meet Players Where They Are
You can jump in and do things. Roleplay depth is something we offer, not something players must pass to get in. We build tools for serious RP, as far as the serious-RP frameworks go, and never require their use.
In practice:
- The rules do not demand a string of
/melines for every mundane action. - Buying things is a menu: open F1 and purchase. It is not a ritual.
- A new player can join, take a job and be doing something within minutes.
Design test: if a feature only works when everyone roleplays to the same standard, or puts ceremony between a player and the thing they came to do, make it opt-in or make it degrade gracefully.
Philosophy: Live Trust Before Features
Real players' time and progress are at stake, so a change must never silently corrupt, duplicate or lose what they've built.
Design test: does this risk silent data loss, duplication or an economy exploit? If so, fix that before shipping.
Tensions Between Pillars
The pillars are meant to pull against each other; that is what makes them useful.
- 3 against 4. Solo-viable content can become a reason not to interact. Solo activity should feed the shared world (goods into the economy, skills other players need) and never be sealed off from it.
- 2 against live trust. Building freedom costs server performance and opens room for abuse. Limits and protection are the answer, not removal.
- Meet players where they are against 1. Tolerating every depth of roleplay, and allowing conflict, puts a burden on rules and staff that a whitelisted server does not carry.
Anti-Pillars (What This Game Is NOT)
- We will not mandate a roleplay standard, or gate play behind whitelists or RP tests, because it compromises Meet Players Where They Are.
- We will not restrict building to solve a roleplay or performance problem while a limit, protection or tooling fix is available, because it compromises A City You Can Build.
- We will not build features whose main use is killing without roleplay, such as deathmatch modes or kill-count rewards, because it compromises Community First. Combat features are fine when the conflict has a roleplay reason behind it.
- We will not ship features that do nothing below a player threshold unless they have a fallback, because it compromises Fun at Any Population.
- We will not add solo content sealed off from other players, because it compromises Community First.
- We will not wipe or reset progression, because it compromises Long-Term Growth.
- We will not ship a feature ahead of a known risk to live data or economy integrity, because it compromises Live Trust Before Features.
Inspiration and References
DarkRP, for the accessible job-and-economy loop and for building. The serious-RP frameworks, for the depth of their roleplay tooling. CityRP takes the tooling of the second without the mandate, and the freedom of the first without the deathmatch.
Target Player Profile
Someone who wants a community and a character to come back to, and who may also want to build. They may be a heavy roleplayer or a casual one; both belong here.
The boundaries are drawn at behaviour, not at player type:
- Conflict is welcome, but it has to be roleplay. Raids, gunfights and aggressive RP are all supported. What CityRP is not aimed at is running round armed and gunning people down with no roleplay behind it.
- Serious RP is supported but never mandated. We build features that support deep roleplay and nobody is required to use them. We meet people where they are.
Visual Identity Anchor
N/A, live game. The look is set by Garry's Mod, the maps and existing content. UI conventions are covered by ui-style.md for colour, type and patterns, and by ui-scaling.md for sizing.
Technical Considerations
N/A as a decision. The engine is Garry's Mod and the architecture exists. See AGENTS.md, plugins.md and modern-apis.md.
Risks and Open Questions
Design Risks
- Solo loops become a reason not to interact (pillar 3 against pillar 4).
- Income that comes from systems and not from other players inflates the economy.
- Supporting every depth of roleplay at once leaves rules and staff to hold the line that a whitelist would otherwise hold.
Technical Risks
- Building freedom against server performance and abuse.
- Legacy code makes Live Trust Before Features expensive to honour: duplication bugs are a recurring class here (AGENTS.md, footgun 7).
Market Risks
- Garry's Mod's player base and the platform's future are outside our control.
Scope Risks
- Every new system has to satisfy both "creates a reason to interact" and "works with three players on", which roughly doubles the design work per feature.
Open Questions
- What should a new player's first ten minutes teach, given there is no mandated playstyle?
- Where exactly is the line between aggressive RP and deathmatch, and which of it should be enforced by systems and which by rules?
MVP Definition
N/A, live game. There is no minimum build to validate; the core loop has been played for years.
Scope Tiers
N/A, live game. Work is prioritised through the issue tracker, not against a ship date.
Next Steps
- Find the system a change belongs to in the systems index, which maps each system to the pillars it serves and the places it is fragile.
- Check a change against the setting, the facts about the city that systems and content have to agree with, and the feature rules, the lines no feature crosses.
- Test new design docs in docs/design/ against the pillars above, and say which pillar a proposal serves.
- When a pillar stops matching how decisions are actually made, change it here first.
Sections
| Doc | Status | Date | Description |
|---|---|---|---|
| In-universe lore | Proposed | 2026-10-01 | The fictional brands and companies that exist inside the city, and what each one is allowed to say and do. |