How arcade games work

Every arcade game is C# inside SWBS Ultimate Jailbreak's arcade engine. The same code runs on the server's wall screens and HUD and, compiled to WebAssembly, on this site. A game is made of:

• <Game>Rules.cs: the rules, levels and scoring, with no engine calls, so they can be tested;
• ArcadeDuels.<Game>.cs: drawing on the screen and HUD, and the controls (W A S D, jump, attack, use);
• its entry in the career catalog (ArcadeCareer.Catalog): XP, ranks, coins, goals and the shop;
• its text in the language file, and tests.

Ghost Arcade games are single player: you against the game, its AI or the clock. Warden games are for the yard, many players at once.

The rules

• Your own work. Original ideas, code and art. No copies of existing games (their names, characters, art, music or levels), no code taken from others, no ripped assets. A genre or a mechanic is fine; a recreation is not.
• Credit what you use. Any third-party code, art or sound must have a licence that allows it, and you must list it with that licence.
• Fit the community. Nothing hateful, sexual, or aimed at real people. Nothing that makes a player pay, gamble real money, or leave the game for another site.
• Fit the engine. Keep to the screen's rows, colours and tick budget, with no lag spikes. No network calls, no files written outside the career save, no adverts or tracking.
• One application at a time. Only open a new one after the last is decided.
• The team's decision stands. We may ask for changes, and we may turn down a game that doesn't fit, with a reason. Approved games ship as part of SWBS Jailbreak, credited to you; agree the terms with the owner before your code is merged.

How games are approved

1. Apply below with your idea: what the game is, how it is played, how long it lasts, how its career works. Attach anything that helps: notes, sketches, a prototype.
2. Idea review. The team answers in your thread with questions, then approves or denies the idea (with a reason).
3. Build it against the baseline below. Post your files in the thread as you go.
4. Final review. The team runs it on the test server and on this site, against every point of the baseline.
5. Release. It ships in the next Jailbreak update and shows up here, with its career and leaderboard.

The baseline: what every game needs before it is added

• It works from start to finish: no crashes, errors or stuck states. A round always ends, and leaving mid-game is safe.
• Every needed function works: controls, win and lose, levels and their unlocks, restart, career XP, rank, coins and goals, the HUD, and every option it shows.
• No beta tags. No "beta", "test", "WIP" or "coming soon" anywhere a player can see.
• Anything unfinished is turned off, not hidden where a player can still reach it.
• It is worth coming back to: a real campaign (at least 10 levels, or an endless mode that gets harder) with a career and goals, not a one-round game.
• It runs in both places: the server's screens and HUD, and this site.
• It is tidy: every line of text is in the language file, there is a How to Play line, and the rules have tests that pass.

What to attach, so it drops in without errors

Files go on your application or on any reply in its thread: .cs, .json, .txt, .md, .xml, .css, .csv, .yml, pictures (.png, .jpg, .gif, .webp) and .zip. Each file can be up to 1 MB, with up to 15 files and 8 MB per application. For anything bigger, post a link.

• <Game>Rules.cs and ArcadeDuels.<Game>.cs, named like that;
• the career entry (XP per level, goals, shop items) and the language lines, as .json;
• your tests;
• a README.md with the controls, the levels, what is done and what is not, and the credits;
• screenshots or a short GIF.

Found a bug in one of our plugins?

Report it here for any SWBS plugin on our CS2 servers (Jailbreak, Extras, the movement and minigames servers, Chicken Coop, the control panel, the Addon Manager), the Workshop packs, the maps or this site. Your report is seen only by you and the team; the team answers in its thread and sets its state.

• One bug per report, with a title that says what goes wrong ("Cells don't open on jb_skyhaven").
• How to make it happen: the steps, the map, the time. A bug the team can repeat is a bug that gets fixed.
• Attach what helps: screenshots, a short clip as a link, the console output as a .txt or .log (1 MB each, 6 files).
• Exploits (a way to cheat, crash the server or get admin): report them here too; they stay private. Don't use or share them.

States: open new, confirmed the team can repeat it, fixed in a release, won't fix, duplicate.

Got an idea for Swoobles?

Suggest anything here: a plugin feature (Jailbreak, Extras, the movement and minigames servers, Chicken Coop and the rest), a site feature, models and skins, maps, store items, events or the Discord. Your suggestion is seen only by you and the team; the team answers in its thread and sets its state.

• One idea per suggestion, with a title that says what it adds ("Favourite emotes on the wheel").
• Say how it would work in game, and why it would make the server better.
• Attach what helps: a sketch, a screenshot, a link to a video (1 MB each, 6 files).

States: open new, planned the team will build it, done in a release, declined, duplicate.

Want to help run Swoobles?

Apply to be an admin here. Your application is seen only by you and the team; the team answers in its thread and decides.

• Be a regular: say how long you have played on the servers and which ones.
• Know the rules (see Rules) and how admins should act: fair, calm, no favourites.
• Tell us about you: any admin or moderation experience, and why you want to help.

States: open being read, accepted, denied. One open application at a time.