Skip to main content

Market Analysis — Three Products

Three products, each a different approach to game scripting and modding. Lua and Python included as comparison.


Product 1: Forked Rust Compiler

A forked rustc with game-specific keywords (view, schema, template). Scripts compile to native code via LLVM. Full Rust type system, borrow checker, traits, generics — plus scope system and mod merging.

Target Market

Rust game developers + cross-engine studios via C ABI.

The Rust gamedev ecosystem:

  • Bevy: 45K GitHub stars, 4.87M crate downloads, 22.6K Discord members, pre-1.0
  • Fyrox: 9.1K stars, approaching 1.0, visual editor
  • ~4M Rust developers globally, growing 33% YoY
  • Game dev is a small slice of that — 7K-23K active (Rust GameDev Discord: 7.3K, Bevy Discord: 22.6K)
  • 533 games on itch.io tagged Rust

One commercial proof point: Tiny Glade (2024) — 600K copies in first month, 2-person team, $9M+ gross, BAFTA-nominated. Even Embark Studios (loudest Rust advocate) shipped THE FINALS on Unreal/C++.

Competitive Landscape

The game logic middleware layer in Rust is empty:

CrateDownloadsState
rpg-stat29KToy/dead
big-brain (utility AI)61KBevy-only, basic
game_features20KMinimal
bevy_mod_scripting45KWIP, Bevy-only

No stat/modifier system. No event system. No save/load middleware. No modding framework. Zero paid crates exist in the entire Rust game ecosystem.

Infrastructure is healthy (wgpu: 18.8M, rapier3d: 1M, pathfinding: 2M). The gap is specifically game systems and gameplay middleware.

Revenue Model

No paid middleware culture in Rust. Zero commercial crates. Community expects open-source. Options:

  • Open core (free crate, paid editor/tooling)
  • Dual license (MIT for indie, commercial for studios)
  • Middleware licensing via C ABI to Unity/Godot/Unreal studios (the multiplier)
  • Sponsorship/foundation model

Strengths

  • Empty playing field — literally no competitor
  • Native LLVM performance, zero GC
  • Engine-agnostic via C ABI — not locked to Unity or any ecosystem
  • Rust growing fast (33% YoY)

Risks

  • Small community (23K vs Unity's 1.8M creators)
  • No culture of paying for middleware
  • Bevy API instability (breaking changes every 3 months)
  • "Rust is for the engine, not the game" sentiment
  • Compiler fork maintenance against 6-week rustc release trains

Product 2: Forked C# Compiler (Roslyn)

A forked Roslyn compiler with the same game-specific keywords (view, schema, template). Scripts compile to IL, then JIT or NativeAOT. Full C# type system, generics, LINQ, async — plus scope system and mod merging.

Target Market

1.8 million Unity creators. 6-11 million C# developers globally.

  • C# is TIOBE 2025 Language of the Year (#5, up 2.94pp YoY — largest increase of any language)
  • 27.1% of Stack Overflow respondents use C#
  • Unity powers 51% of Steam releases (2024), 71% of top 1,000 mobile games
  • Game engine market: $3.45B (2024), projected $12.84B by 2033

Every Unity developer already knows C#. Zero language adoption barrier. The keywords are the only new thing to learn.

Roslyn Fork Feasibility

Strong precedent exists:

  • Metalama (PostSharp) — Commercial Roslyn fork, maintained for years, tracks upstream within 3 weeks of Microsoft releases. Proves it's sustainable as a business.
  • Shader DSL fork — Developer added custom keywords, reported "only a small change to the lexer."
  • Marcin Juraszek tutorial — Detailed 3-part walkthrough of adding custom syntax to Roslyn (Lexer → Parser → Binder → Emitter).

Roslyn architecture: 4 clean phases (Parse, Declaration, Bind, Emit) with public APIs at each layer. Designed as "compiler as a service." 2.3M LOC, ~4,300 files. Adding new keywords touches lexer + parser + binder + emitter — same as the rustc fork.

Source generators cannot do this. Microsoft explicitly says: "One could imagine records being implemented as a source generator... This is explicitly considered to be an anti-pattern." New keywords require a compiler fork.

Compilation Speed

ScenarioRoslynrustc
Cold start (first compile)2-4 seconds5-30 seconds
Incremental small change30-50ms1-5 seconds
Hot reload feasibilityYes (well within 100-500ms tolerance)No (too slow)

Roslyn compiles to IL, not native code. That's why it's fast. For native performance, add NativeAOT (seconds more, but only for release builds). This naturally maps to dev-mode (fast JIT iteration) vs ship-mode (NativeAOT for performance).

C# Modding Precedent

C# modding ecosystems already exist — but all are fragile and unsandboxed:

GameApproachProblem
RimWorldCompile DLL + Harmony patchesModders need IDE, no sandboxing, breaks on updates
Cities: SkylinesBuilt-in compiler + HarmonyCS2 modding was a disaster — freezes, incompatibilities
ValheimBepInEx + HarmonyXSame fragility pattern
KSPBepInExSame

What these prove: Demand for C# modding is massive (RimWorld has thousands of C# mods). But the current approach (Harmony runtime patching) is fragile, unsandboxed, and has no contract between game and mods. A structured compiler-based system with schema contracts and validated mod merging would be a step change.

Competitive Landscape

ProductPriceWhat It IsGap
ORK Framework 3$138RPG-only, no-code-onlyNo modding, no scripting, RPG-only
Roslyn C# Runtime Compiler 2.0~$50Runtime C# compilationNo game systems, no mod merging, no type contracts
Lua Modding Framework~$40MoonSharp wrapperLua not C#, no game systems
Easy Save 3$55Unity object serializerNot game system state

Nobody sells a compiled, type-safe game scripting engine for Unity with integrated game systems.

Unity has no GAS equivalent. Unreal ships GAS (Gameplay Ability System) battle-tested in Fortnite. Multiple community GAS ports for Unity (UnityGAS, GASify) — all abandoned. Proves demand, zero supply.

NativeAOT Performance Path

.NET NativeAOT compiles C# to native code ahead of time:

  • Eliminates JIT at runtime, near-instant startup
  • NativeAOT-LLVM is an experimental Microsoft project routing through LLVM — same backend as Rust
  • No runtime dependency for deployment
  • Limitation: No reflection, no dynamic code generation
  • Microsoft claims .NET 8 AOT "rivals systems languages like Rust"

Two-mode model: JIT for development (fast iteration, 30-50ms recompile) → NativeAOT for shipping (native performance). This mirrors the dev/retail split naturally.

Revenue Model

  • Unity Asset Store: $100-250 (proven channel, 1.8M potential customers)
  • Direct licensing: $500-2000/seat/year for studios
  • Tiered: Base framework $150, full systems $250, source license $500+

Comparable pricing: ORK at $138, Ultimate Character Controller at $229, Universal Fighting Engine at $59-499 ($10K+/month from niche domination).

Strengths

  • Addressable market is 100x larger than Rust gamedev (1.8M Unity creators vs 23K Rust gamedev)
  • Zero language learning curve for Unity developers
  • 30-50ms incremental compile enables real hot reload
  • Metalama proves Roslyn forks are commercially maintainable
  • NativeAOT provides native performance path when needed
  • Proven demand for C# modding (RimWorld ecosystem)

Risks

  • Roslyn is 2.3M LOC with 83% cyclic class dependencies — complex codebase
  • Upstream tracking cost (C# ships new features yearly)
  • IL2CPP complicates mod loading on mobile/console
  • Unity's own runtime (forked Mono) is 2-5x slower than modern .NET — capped by Unity's tech debt until they ship CoreCLR
  • Cities: Skylines 2 modding disaster is a cautionary tale for C# mod loading

Product 3: Declarative Modding System (Paradox-Style)

Text-file-based game content system. Triggers, effects, modifiers, events, decisions defined in data files. Hot reload. Modders use a text editor. Studios extend with custom keywords.

The Paradox Model

Paradox shipped 15+ titles over 20 years on this:

  • CK3, EU4, Stellaris, Victoria 3, HOI4: Thousands of mods per game, communities alive 10+ years
  • Cities: Skylines (Unity): 12M copies, modding was primary sales driver
  • Clausewitz/Jomini engine: Key-value text, tree-walked interpretation, file/key replacement

How it works: Two primitives — triggers (read-only bool checks) and effects (state mutations). Everything is composed from these. Mods override by providing later files. No compilation, no programming.

Why it works: Modders are not programmers. Designers, balance tweakers, lore writers, hobbyists edit text files. Lower barrier = larger community = longer game life = more revenue.

Modding as Revenue Driver (Hard Data)

GameEngineSales/RevenueModding Impact
SkyrimCustom$1B+ lifetime100K+ mods, active 15 years, longevity "shocked Bethesda"
RimWorldUnity$100M+Small team, modding is primary retention driver
Cities: SkylinesUnity12M copiesDesigned for Workshop, mods drove sales
ValheimUnity12M copies, 5-person teamBepInEx ecosystem
MinecraftCustom$1B+ annuallyMod downloads in billions/year
FactorioCustom (Lua)3.5M+ copiesDeep Lua modding, fiercely loyal community

"Most AAA titles see predictable player drop-offs months after release, but heavily modded games keep active populations for years or decades."

Competitive Landscape

ProductWhat It DoesWhat's Missing
mod.ioMod distribution (upload/download/browse)No content system, no logic, no parsing
BepInEx/HarmonyRuntime DLL patchingNot designed-in modding, no content system
Lua Modding FrameworkLua scripting for UnityStill programming, no declarative content
Unity AddressablesAsset loading/unloadingNo mod discovery, no layering, no override

Nobody sells a declarative content + modding system for any game engine.

The Keyword Problem

Paradox controls their engine and adds C++/Jomini keywords as games need them. CK3 has hundreds of unique keywords. A third-party product must solve this:

  • Option A: Fixed keyword set for common patterns. Studios extend in C# for anything custom.
  • Option B: Keyword registration IS the API. Studios define triggers/effects in C#. The product is the parser, runtime, override system, and mod tooling.

Option B is more realistic. The product becomes: "here's a declarative content system with hot-reload and mod layering — register your game-specific keywords in C#."

Revenue Model

  • Asset Store: $75-150
  • SaaS: Mod hosting + analytics (compete with mod.io on content side)
  • Bundled: Declarative layer on top of Product 1 or Product 2

Strengths

  • Proven at massive scale (Paradox, 20 years, billions in combined revenue)
  • Most accessible to non-programmers — largest possible modder community
  • Hot reload is instant (<100ms)
  • Cross-platform (text files work everywhere)
  • No compilation, no toolchain, no IDE needed

Risks

  • Limited expressiveness — no functions, closures, generics, pattern matching
  • No type system — misspelled fields silently fail (CWTools community project exists to fix this for Paradox)
  • 10-100x slower than compiled (interpreted tree-walking)
  • Keyword explosion — each game needs hundreds of engine-side implementations
  • Competing with Paradox's 20-year head start on this exact concept

Language Comparison: Lua, Python, and the Three Products

Lua

The dominant game modding language globally.

GameLua Usage
FactorioAll mod logic
Roblox (Luau)All game scripting
World of WarcraftAddOn/UI
Don't StarveFull mod system
Garry's ModMod system
Civilization V/VIAI and scenarios

Unity integration: MoonSharp (pure C# Lua interpreter, works on ALL platforms including IL2CPP and WebGL). xLua (Tencent, 8.5K GitHub stars, 10+ production games, Chinese mobile focus).

DimensionLua
Performance10-100x slower than native
Type safetyNone
Hot reloadTrivial
Platform coverageAll (MoonSharp is pure C#)
Modding mindshareDominant — largest modding community globally
Learning curveLow
SandboxingGood
ExpressivenessMedium (no static types, limited OOP)

Python

Ubiquitous language but poor fit for game scripting.

Used in: Civilization IV (Boost.Python), Blender (extensions), EVE Online (Stackless Python server-side), Ren'Py (visual novels).

DimensionPython
Performance100-1000x slower than native (CPython)
Type safetyRuntime only
Hot reloadTrivial
Platform coveragePoor for Unity — IronPython is dead, Python.NET is clunky
GILGlobal Interpreter Lock — single-threaded, catastrophic for games
Runtime size~30MB+
SandboxingPoor
EmbeddingNo production-grade Unity integration exists

Verdict: Wrong tool for runtime game scripting. Good for build pipelines, asset processing, ML training. The GIL, performance, and embedding complexity kill it for game logic.

Full Comparison Matrix

DimensionForked RustForked C# (Roslyn)DeclarativeLuaPython
Developer pool4M Rust devs (23K gamedev)6-11M C# devs (1.8M Unity)Non-programmers (unlimited)Modders globally50M+ devs (near zero game embedding)
PerformanceNative (LLVM)JIT or NativeAOT (near-native)10-100x slower (interpreted)10-100x slower (interpreted)100-1000x slower
Type safetyFull (compile-time, borrow checker)Full (compile-time)NoneNoneRuntime only
Hot reloadNo (1-5s recompile)Yes (30-50ms incremental)Instant (<100ms)TrivialTrivial
Mod mergingAST-level, compile-time validatedAST-level, compile-time validatedFile/key replacement, last winsNo standard systemN/A
Unity platformsPartial (no IL2CPP/WebGL dynamic)JIT: Mono only. NativeAOT: allAllAll (MoonSharp)Poor
Learning curve for moddersSteep (Rust)Medium (C# is widely known)LowestLowLow
SandboxingCompiled (no runtime escape)Configurable (restrict namespaces)Inherent (no code execution)Good (restrict globals)Poor
Ecosystem maturity~5 years for games20+ years20+ years (Paradox)30+ yearsN/A for game scripting
Compiler fork maintenance6-week rustc trainsYearly C# releasesNo compilerNo compilerN/A
Cross-engineYes (C ABI).NET ecosystemsPortable (text)PortableN/A

Who Picks What

CustomerBest FitWhy
Unity studio wanting moddable gameForked C# or DeclarativeC# familiarity + largest modder pool, or lowest barrier for non-programmer modders
Rust engine studio (Bevy/Fyrox)Forked RustNative ecosystem, C ABI for others
Studio wanting maximum modder communityDeclarative or LuaLowest barrier wins the numbers game
Studio needing performance at scale (100K+ entities)Forked Rust or Forked C# + NativeAOTGC and interpreter overhead unacceptable
Studio where mod quality is criticalForked Rust or Forked C#Compile-time validation prevents broken mods
Mobile game with light moddingLua (MoonSharp)Works everywhere, simple, proven
Cross-engine middlewareForked Rust (C ABI)Only option that's truly engine-agnostic
Quick prototype / game jamLuaFastest iteration

Product Comparison

DimensionProduct 1 (Forked Rust)Product 2 (Forked C#)Product 3 (Declarative)
Addressable marketSmall (23K Rust gamedev + C ABI cross-engine)Largest (1.8M Unity + 6-11M C# devs)Medium (any studio wanting moddable games)
CompetitionNone — empty fieldORK ($138, RPG-only). No real competitor.mod.io (distribution only). No real competitor.
Gap clarity"No game middleware in Rust""Unity has no GAS, no typed modding""Making Unity games moddable is painful"
Revenue per customerUncertain (no paid Rust crate culture)$100-500 (proven Asset Store pricing)$75-150 or SaaS
DefensibilityHigh (Rust compiler expertise + C ABI moat)High (Roslyn fork expertise, Metalama is only precedent)Medium (ecosystem stickiness)
Platform coverageEngine-agnostic (C ABI).NET ecosystems (huge)All (text files)
Hot reloadNoYes (30-50ms)Instant
Time to revenueUncertainFastest (Asset Store is proven channel)Medium

Revenue Estimates

ProductYear 1Year 3Notes
Forked Rust$5K-20K$50K-200K/yrC ABI licensing to non-Rust studios could be larger
Forked C#$30K-100K$100K-300K/yrLargest market, proven pricing channel
Declarative$10K-40K$50K-150K/yrHigher ceiling with SaaS mod hosting

They Layer

These three products can be tiers of a single offering:

  1. Forked Rust = the native engine core. Game systems in Rust. C ABI for any host.
  2. Forked C# = Unity/C# developer interface. Same keywords, C# syntax, Roslyn compilation. Talks to the Rust core or stands alone.
  3. Declarative = modder-facing content layer. Text files on top of either Product 1 or 2. Hot reload, no programming needed.

Optional addition: Lua as the lightweight scripting tier between Declarative and full compiled C#/Rust.

Studio chooses their depth: text files for simple modding → Lua for scripting → forked C# for full typed power → forked Rust for maximum performance.