スキル一覧に戻る
nethercore-systems

nethercore-development

by nethercore-systems

1🍴 0📅 2026年1月15日
GitHubで見るManusで実行

SKILL.md


name: Nethercore Development description: | Core development workflow for Nethercore games. Triggers on "nether build", "nether.toml", "asset handles", "determinism", "rollback rules", "WASM game".

Load references when:

  • Full nether.toml examples -> references/nether-toml.md
  • CLI command details -> references/cli-commands.md
  • Determinism patterns -> references/determinism-rules.md version: 1.0.0

Nethercore Development

Overview

Nethercore games compile to WASM and run in the Nethercore player with rollback netcode. All consoles share the same WASM core, ensuring determinism across platforms.

Required Game Exports

Every game exports three functions:

#[no_mangle] pub extern "C" fn init() { }   // Setup, asset loading
#[no_mangle] pub extern "C" fn update() { } // Deterministic logic
#[no_mangle] pub extern "C" fn render() { } // Drawing only

nether CLI

CommandPurpose
nether initCreate nether.toml manifest
nether compileCompile WASM from source
nether packBundle WASM + assets into ROM
nether buildcompile + pack (main command)
nether runBuild and launch in player

Game Manifest (nether.toml)

[game]
id = "my-game"
title = "My Game"
author = "Your Name"
version = "1.0.0"

[build]
script = "cargo build --target wasm32-unknown-unknown --release"
wasm = "target/wasm32-unknown-unknown/release/my_game.wasm"

[[assets.textures]]
id = "player"
path = "assets/player.png"

Netcode (What You DON'T Do)

The Nethercore player handles all networking automatically:

  • GGRS rollback synchronization
  • State snapshots
  • Input transmission
  • Desync detection

Your only responsibility: Make update() deterministic. Never write: Networking code, rollback logic, state sync, or input transmission.

Determinism (Rollback Safety)

The update() function must be deterministic for rollback netcode. Given identical inputs, all clients must produce identical state.

Rules

  1. All state in WASM memory - Use static variables (auto-snapshotted)
  2. Use FFI random() functions - Never external randomness
  3. Use tick_count() not system time - Frame-based logic only
  4. render() is display-only - Never modify game state in render

Forbidden Patterns

PatternProblemCorrect Alternative
rand::thread_rng()External RNGFFI random(), random_range()
SystemTime::now()System clockFFI tick_count()
HashMap iterationUnorderedArrays, BTreeMap
State changes in render()Skipped during rollbackMove to update()

Quick Test

nether run --sync-test --frames 1000

If this fails, you have non-deterministic code.

Project Structure

my-game/
├── nether.toml          # Game manifest
├── src/
│   ├── lib.rs           # Entry point (init/update/render)
│   └── zx.rs            # FFI bindings (console-specific)
├── assets/
│   ├── textures/
│   ├── meshes/
│   └── audio/
└── Cargo.toml

Key principle: Keep entry files minimal (~50 lines). FFI bindings in separate module.

スコア

総合スコア

60/100

リポジトリの品質指標に基づく評価

SKILL.md

SKILL.mdファイルが含まれている

+20
LICENSE

ライセンスが設定されている

+10
説明文

100文字以上の説明がある

0/10
人気

GitHub Stars 100以上

0/15
最近の活動

3ヶ月以内に更新がある

0/10
フォーク

10回以上フォークされている

0/5
Issue管理

オープンIssueが50未満

+5
言語

プログラミング言語が設定されている

+5
タグ

1つ以上のタグが設定されている

0/5

レビュー

💬

レビュー機能は近日公開予定です