The Pitch

Why this benefits Facepunch:

• The Ultimate Community Hub: It reinforces sbox.game as the one-stop shop. Players don’t just launch games there; they read the patch notes, check the leaderboards, and read the wiki all in one ecosystem.
  
  
• SEO Dominance: User-generated wiki content is an SEO goldmine. Keeping that on the Facepunch domain brings massive organic search traffic directly to the s&box platform instead of lining Fandom’s pockets.
  
  
• Retention: Keeping players in the s&box ecosystem reduces the friction of tabbing out to third-party, ad-riddled sites.
  
  

Why this benefits Creators (The Anti-Fandom Angle): 

• Clean, Ad-Free UX: A native, dark-mode-friendly interface that respects the player's screen real estate.
  
  
• No Fandom Drama: Creators retain control over their wiki's layout and moderation, without worrying about corporate Fandom overriding their CSS or selling their community data.
  
  
• Steam / Facepunch Auth: No need to create a separate account to edit pages. Players just log in with their existing s&box/Steam credentials.
  
  

S&box Specific Integrations (The "Killer Features"): 

• Asset Linking: Imagine typing [asset:mygame/cool_sword] in a wiki page and having it automatically generate a 3D preview, stats, or a link to the item via the cloud asset system.
  
  
• Auto-Updating API Docs: For games that expose variables or scripting APIs, the wiki could automatically pull data from the game's C# codebase using Roslyn (since s&box already compiles it on-demand).
  
  
• GitHub Syncing: Since a lot of s&box development is already tied to Git (and Facepunch open-sourced the C# side last year), allow creators to just host a /docs markdown folder in their repo that automatically pushes to the sbox.game wiki!
  
  

• C# Reflection & Roslyn Hooks: Since s&box compiles our C# code on-demand, the web backend could parse the code for specific attributes. For example, if a creator tags a class with [WikiData(Category = "Weapons")], the s&box backend could automatically pull its public variables (BaseDamage, FireRate, Durability) and generate a live-updating stats table on the wiki.
  
  
• Asset File Parsing: Most game data (items, NPCS, loot tables) is stored in structured .asset files. The wiki engine could be pointed at a specific folder in the project (e.g., /assets/weapons/), read the JSON/metadata, and procedurally generate a subpage for every single item inside it.
  
  
• AI-Assisted Formatting: While the hard stats are pulled from the code, Facepunch could integrate a lightweight AI pass to read the item's internal description strings and format them into readable, structured paragraphs on the auto-generated page.
  
  

Potential Hurdles to Consider:

• Moderation & Vandalism: Open wikis attract trolls. We would need robust rollback features and granular permissions (e.g., "Only users with 5+ hours played in this game can edit the wiki").
  Simply letting a game creator control access towards the wiki could/would already work although a little counterintuitive against the soul of a community driven wiki.
  Not every project needs the same kind of wiki. Some creators may want fully public community editing, while others may only want developer-maintained documentation. The system should be flexible enough to support both. 
  
  
• Storage Costs: Image hosting for wikis can get expensive, though this could potentially be tied into the existing cloud asset storage limits or simply solved by hotlinking images instead.