Why Use Containers for Games?

Imagine you’re moving to a new apartment, but instead of packing everything in boxes, you could magically transport your entire room – furniture, decorations, even the air temperature – exactly as it is. Container technologies do something similar for software: they package applications with everything they need to run, isolated from the host system.

For game distribution, containers solve critical problems:

• Dependency hell: “It works on my machine” syndrome
• System conflicts: Different games needing different library versions
• Security: Isolating potentially untrusted code
• Portability: Same package works across different Linux distributions

The Three-Layer Architecture

The system you found uses three complementary technologies that work together like layers of an onion:

┌─────────────────────────┐
│      Bubblewrap         │ ← Security & Isolation
├─────────────────────────┤
│    FUSE-OverlayFS       │ ← Filesystem Layering
├─────────────────────────┤
│       DwarFS            │ ← Compression & Storage
└─────────────────────────┘

Let’s understand each layer:

Layer 1: DwarFS – The Storage Foundation

What is DwarFS?

DwarFS is a read-only compressed filesystem designed for distributing large amounts of data efficiently. Think of it as a highly advanced ZIP file that can be mounted as a real filesystem.

Traditional File Distribution Problem:

Game Files (Uncompressed): 50GB
├── textures/     (30GB)
├── audio/        (15GB)
├── models/       (4GB)
└── executables/  (1GB)

Problems:
- Huge download sizes
- Slow extraction time
- Wasted disk space for duplicate files

DwarFS Solution:

Game Files (DwarFS): 15GB compressed
├── Deduplication: Identical files stored once
├── Compression: LZMA/ZSTD algorithms
├── Fast Access: No extraction needed
└── Direct Mounting: Files accessible immediately

How DwarFS Works:

1. Compression: Uses advanced algorithms (LZMA, ZSTD) to shrink data
2. Deduplication: If multiple games have the same DLL, it’s stored only once
3. Block-level Storage: Files are split into blocks, compressed separately
4. FUSE Integration: Mounts as a regular filesystem

Example Usage:

# Create a DwarFS image from game directory
mkdwarfs -i /path/to/game -o game.dwarfs

# Mount the compressed filesystem
dwarfs game.dwarfs /mnt/game

# Game files now accessible at /mnt/game/
ls /mnt/game/
# Output: MyGame.exe, data/, dlls/, ...

Benefits for Game Distribution:

• Reduced Download Size: 60-80% smaller than uncompressed
• Faster Distribution: Smaller files = faster downloads
• Instant Access: No extraction waiting time
• Space Efficient: Multiple games can share common files

Layer 2: FUSE-OverlayFS – The Filesystem Mixer

What is FUSE-OverlayFS?

FUSE-OverlayFS creates a unified view of multiple filesystem layers. Imagine having transparent sheets of paper – you can see through all of them, but what’s written on the top sheet takes priority.

The Layering Concept:

User sees this unified view:
/game/
├── MyGame.exe          (from Game Layer)
├── wine/               (from Wine Layer)
├── steam_api.dll       (from Game Layer - overrides system)
└── system32/           (from System Layer)

Actually composed of:
┌─────────────────┐
│   Game Layer    │ (Read-Write) - Game-specific files
├─────────────────┤
│   Wine Layer    │ (Read-Only)  - Wine installation
├─────────────────┤
│  System Layer   │ (Read-Only)  - Base libraries
└─────────────────┘

Why This Matters for Games:

1. Isolation: Each game has its own view of the filesystem
2. Customization: Games can override system files safely
3. Efficiency: Common components (Wine, libraries) shared between games
4. Clean Uninstall: Remove game layer = complete uninstallation

How OverlayFS Works:

# Create overlay mount
mount -t overlay overlay \
  -o lowerdir=/system/libs:/wine/installation,\
     upperdir=/game/files,\
     workdir=/tmp/overlay-work \
  /game/unified-view

# Now /game/unified-view contains:
# - All files from /system/libs (bottom layer)
# - All files from /wine/installation (middle layer)  
# - All files from /game/files (top layer)
# - Top layers override bottom layers for same filenames

Real-World Example:

Game needs: steam_api.dll version 2.1
System has: steam_api.dll version 1.9
Wine layer: (no steam_api.dll)

Result: Game gets version 2.1 from its own layer
        Other applications still see version 1.9
        No system conflicts!

Layer 3: Bubblewrap – The Security Guard

What is Bubblewrap?

Bubblewrap is a sandboxing tool that creates secure containers for applications. Think of it as creating a “fake” operating system environment where the application runs, but with strict controls on what it can access.

The Sandbox Concept:

Host System:
├── /home/user/documents/     (PRIVATE)
├── /home/user/photos/        (PRIVATE)
├── /system/critical-files/   (PROTECTED)
└── /tmp/                     (ACCESSIBLE)

Sandboxed Game sees:
├── /home/user/MyGame/        (ALLOWED)
├── /tmp/game-temp/           (ALLOWED)
├── /usr/lib/                 (READ-ONLY)
└── Everything else: BLOCKED

Security Benefits:

1. File System Protection: Game can’t access personal files
2. Network Control: Restrict internet access if needed
3. Process Isolation: Game can’t interfere with other applications
4. Resource Limits: Control CPU, memory usage

Bubblewrap in Action:

# Launch game in sandbox
bwrap \
  --dev-bind /dev /dev \                    # Device access
  --ro-bind /usr/lib /usr/lib \             # Read-only libraries
  --ro-bind /wine/prefix /wine/prefix \     # Read-only Wine
  --bind /game/save-data /game/save-data \  # Read-write saves
  --tmpfs /tmp \                            # Temporary filesystem
  --unshare-pid \                           # Separate process space
  --unshare-net \                           # Network isolation
  wine /game/MyGame.exe                     # Run the game

What the Game Experiences:

From Game's Perspective:
"I'm running on a normal Windows system through Wine"

Reality:
- Running in isolated container
- Limited file system access
- Controlled resource usage
- Cannot harm host system

How All Three Work Together

The Complete Pipeline:

1. Game Distribution:
   Developer → DwarFS Archive (compressed)
   
2. User Download:
   MyGame.dwarfs (15GB instead of 50GB)
   
3. Runtime Setup:
   ┌─────────────────────┐
   │ Mount DwarFS        │ → /mnt/game-files/
   └─────────────────────┘
   
   ┌─────────────────────┐
   │ Create OverlayFS    │ → /game-environment/
   │ - Game files        │   (top layer)
   │ - Wine installation │   (middle layer) 
   │ - System libraries  │   (bottom layer)
   └─────────────────────┘
   
   ┌─────────────────────┐
   │ Launch with         │ → Secure execution
   │ Bubblewrap          │
   └─────────────────────┘

Example Launch Script:

#!/bin/bash
# This is similar to what those start.sh scripts do

# 1. Mount compressed game files
dwarfs game.dwarfs /mnt/game-ro

# 2. Create overlay filesystem
mount -t overlay overlay \
  -o lowerdir=/mnt/game-ro:/usr/share/wine-tkg,\
     upperdir=/home/user/.local/share/MyGame,\
     workdir=/tmp/MyGame-overlay \
  /tmp/MyGame-env

# 3. Launch in secure container
bwrap \
  --ro-bind /tmp/MyGame-env /game \
  --bind /home/user/.local/share/MyGame-saves /saves \
  --dev-bind /dev/dri /dev/dri \
  --tmpfs /tmp \
  --unshare-pid \
  cd /game && wine MyGame.exe

Benefits for Your Game Distribution

For Developers:

• Consistent Environment: Game runs the same everywhere
• Smaller Downloads: Compressed distribution
• Easy Updates: Replace single DwarFS file
• Dependency Control: Bundle exact library versions needed

For Users:

• Simple Installation: Download and run
• No System Pollution: Games don’t modify system
• Security: Games can’t access private files
• Clean Removal: Delete one directory = complete uninstall

For System Administrators:

• Predictable Behavior: Games can’t break system
• Resource Control: Limit what games can do
• Easy Management: All game data in known locations

Common Use Cases

1. Legacy Game Preservation

Old Game (2005) → DwarFS with old libraries → 
OverlayFS with period-appropriate Wine → 
Bubblewrap sandbox → Runs perfectly on modern Linux

2. Multi-Version Support

Game v1.0 → DwarFS archive 1
Game v2.0 → DwarFS archive 2
User can run either version without conflicts

3. Mod Support

Base Game (DwarFS, read-only) +
Mods (OverlayFS upper layer, read-write) =
Modified game without touching original files

Performance Considerations

Overhead:

• DwarFS: Decompression CPU cost, but often faster than disk I/O
• OverlayFS: Minimal overhead for filesystem operations
• Bubblewrap: Very low overhead, mainly at startup

Optimization Tips:

• Use ZSTD compression for better decompression speed
• Keep frequently accessed files in upper overlay layers
• Use tmpfs for temporary game files

Comparison with Other Technologies

Technology	DwarFS + Overlay + Bubblewrap	Docker	Flatpak	AppImage
Compression	Excellent	Good	Good	Good
Isolation	Excellent	Excellent	Excellent	Limited
Size	Smallest	Large	Medium	Medium
Startup Speed	Fast	Medium	Medium	Fast
Complexity	High	Medium	Low	Low

Understanding these technologies helps you choose the right approach:

1. Simple Distribution: AppImage or Flatpak
2. Advanced Control: Implementation of the DwarFS + OverlayFS + Bubblewrap stack
3. Hybrid Approach: Using Flatpak with similar layering concepts internally

The system represents the cutting edge of Linux game distribution – it’s complex but provides maximum efficiency, security, and compatibility.