Last Updated: October 2, 2025
Version: v0.0.2
Welcome to the FerrisScript FAQ! Find answers to common questions about installation, usage, and Godot integration.
Can't find your answer? Check TROUBLESHOOTING.md or ask in GitHub Discussions.
- Installation & Setup
- Language & Syntax
- Godot Integration
- Development & Contributing
- Performance & Optimization
- Project Status & Roadmap
- Rust 1.70+ (Install Rust)
- Godot 4.2+ (for Godot integration) (Download Godot)
- Git (for cloning the repository)
See the README Installation section for detailed setup instructions.
First build: 3-5 minutes on modern hardware due to dependency compilation
Subsequent builds: 1-2 seconds if no code changes
Clean rebuild: 3-5 minutes
Tip: Use cargo build --release for optimized builds (takes longer but produces faster binaries).
No! You can build and test the FerrisScript compiler and runtime without Godot:
cargo build --workspace
cargo test --workspaceYou only need Godot if you want to:
- Use FerrisScript scripts in Godot projects
- Test Godot integration (GDExtension)
- Run the example Godot project in
godot_test/
Common issues:
-
Rust version too old - Run
rustc --versionand ensure it's 1.70+- Fix:
rustup update
- Fix:
-
Missing dependencies (Windows) - Need Visual Studio Build Tools
-
Stale build artifacts - Sometimes cached builds cause issues
- Fix:
cargo clean && cargo build
- Fix:
-
Network issues - Can't download crates from crates.io
- Check your internet connection
- Try:
cargo build --offlineif you've built before
See TROUBLESHOOTING.md for platform-specific solutions.
Not in v0.0.1 - Currently FerrisScript is designed for Godot integration.
Coming in v0.2.0 - Standalone mode will allow:
- Running
.ferrisscripts independently - Command-line REPL
- Non-game applications
See v0.1.0-ROADMAP.md for planned features.
The correct extension is .ferris ✅
All FerrisScript files use .ferris:
examples/hello.ferris
examples/bounce.ferris
examples/move.ferris
Note: Early documentation incorrectly referenced .rscr - this was corrected in v0.0.2.
| Feature | Rust | FerrisScript |
|---|---|---|
| Type system | Full Rust ownership | Simplified ownership (v0.0.1) |
| Compilation | Native binary | Interpreted via runtime |
| Target | Systems programming | Game scripting |
| Borrowing | Full borrow checker | Planned for v0.1.0 |
| Macros | Full macro system | Not supported |
| Standard library | std, alloc, core | Godot-specific + subset |
| Async/await | Full async runtime | Not supported yet |
TL;DR: FerrisScript is inspired by Rust's syntax but simplified for game scripting. It's not a Rust compiler.
Not directly - FerrisScript is not a Rust compiler and doesn't have access to cargo/crates.io.
However:
- The FerrisScript runtime is written in Rust and uses Rust crates internally
- You can extend FerrisScript by adding Rust code to the runtime (
crates/runtime/) - Future versions may support a plugin system for Rust interop
Workaround for v0.0.1: Modify the runtime source code to add functionality.
FerrisScript and GDScript can coexist in the same Godot project:
- FerrisScript → Compiled to native code via GDExtension
- GDScript → Interpreted by Godot engine
- Communication → Both can call each other through Godot's scripting API
Example:
// my_script.ferris
pub fn process_input(input: Input) -> Vector2 {
// Performance-critical code in FerrisScript
}
# my_scene.gd
extends Node2D
func _ready():
var ferris_script = FerrisScriptNode.new()
var result = ferris_script.process_input(Input.get_mouse_position())Best practice: Use FerrisScript for performance-critical logic, GDScript for game logic/UI.
v0.0.1 Supported Types:
Vector2- 2D vectorsNode- Base Godot node type- Basic types:
i32,f32,bool,String
Coming in v0.1.0:
Vector3(3D vectors)Color(RGBA colors)Transform(3D transforms)Resource(Godot resources)- More node types
See v0.1.0-ROADMAP.md for complete type roadmap.
Not yet - REPL (Read-Eval-Print Loop) is planned for v0.2.0.
Current workflow:
- Write
.ferrisfiles - Build with
cargo build - Run in Godot or via runtime
Alternatives:
- Use Godot's output console for debugging
- Run tests with
cargo testfor quick feedback
See the README "Using in Godot" section for the 4-step process:
- Build the GDExtension
- Copy library to
godot_test/addons/ferrisscript/bin/ - Create
.gdextensionfile - Import in Godot
Full tutorial: Coming in Phase 4 (Advanced Documentation).
Common causes:
-
Missing .gdextension file - Godot needs this to find FerrisScript
- Location:
res://addons/ferrisscript/ferrisscript.gdextension - See README for template
- Location:
-
Wrong library path -
.gdextensionmust point to correct binary- Windows:
ferrisscript_godot_bind.dll - Linux:
libferrisscript_godot_bind.so - macOS:
libferrisscript_godot_bind.dylib
- Windows:
-
Godot editor needs restart - Changes to GDExtensions require restart
-
Build not complete - Ensure
cargo build --package ferrisscript_godot_bindsucceeded
See TROUBLESHOOTING.md - Godot Integration for detailed fixes.
Yes! They work side-by-side:
my_game/
├── scripts/
│ ├── player.ferris # Performance-critical player controller
│ ├── ui_manager.gd # UI logic in GDScript
│ └── enemy_ai.ferris # AI in FerrisScript
└── scenes/
└── main.tscn
Best practices:
- Use FerrisScript for CPU-intensive tasks (physics, AI, large calculations)
- Use GDScript for prototyping, UI, and game logic
- Keep scripts organized by purpose, not language
Current status (v0.0.1):
- Not optimized yet - Focus is on correctness, not speed
- Early benchmarks show 2-5x faster than GDScript for computation-heavy tasks
- Overhead from runtime interpretation (not JIT compiled)
Optimization plans (v0.1.0+):
- JIT compilation
- Better memory management
- Inline optimizations
- Target: 5-10x faster than GDScript
See v0.1.0-ROADMAP.md - Performance Roadmap for details.
Yes, but limited in v0.0.1:
Vector2support only (2D focus)Vector3coming in v0.1.0- 3D node types coming in v0.1.0
Current 3D workaround:
- Write game logic in FerrisScript
- Use GDScript for 3D-specific code
- Wait for v0.1.0 (planned December 2025)
See CONTRIBUTING.md for complete guide:
- Fork the repository
- Create a feature branch
- Make your changes
- Run tests (
cargo test) - Submit a Pull Request
First-time contributors: Look for issues labeled good first issue.
# Run all tests
cargo test --workspace
# Run tests for specific crate
cargo test --package rustyscript_compiler
# Run specific test
cargo test test_lexer_tokenizes_keywords
# Run with output
cargo test -- --nocaptureSee CONTRIBUTING.md - Testing Guidelines for more.
Process:
- Discuss first - Open an issue describing the feature
- Update lexer - Add tokens in
crates/compiler/src/lexer.rs - Update parser - Add AST nodes in
crates/compiler/src/parser.rs - Update type checker - Add type rules in
crates/compiler/src/type_checker.rs - Update runtime - Add execution in
crates/runtime/src/lib.rs - Add tests - Write tests for each component
- Update docs - Document the feature
Example: See how let mut was implemented by reviewing git history.
- Submit PR - Use the PR template
- CI checks - All tests must pass, code must be formatted
- Maintainer review - Typically within 2-3 days
- Address feedback - Make requested changes
- Approval - At least 1 maintainer approval required
- Merge - Squash and merge into main
See CONTRIBUTING.md - Pull Request Process.
Short answer: Yes, for computation-heavy tasks, but not optimized yet.
Benchmarks (v0.0.1, preliminary):
- Simple math loops: 2-3x faster
- Complex algorithms: 3-5x faster
- String operations: 1.5-2x faster
- Godot API calls: Similar (bottleneck is Godot, not FerrisScript)
Optimization status:
- ❌ No JIT compilation
- ❌ No inlining
- ❌ No dead code elimination
- ✅ Static typing (compile-time checks)
v0.1.0 goals: 5-10x faster with optimizations.
Use FerrisScript for:
- Performance-critical loops
- Complex algorithms (pathfinding, physics)
- Large data processing
- Type safety (catch errors early)
Use GDScript for:
- Rapid prototyping
- UI and game logic
- Godot-specific features
- When performance doesn't matter
Hybrid approach (recommended):
- Prototype in GDScript
- Optimize bottlenecks with FerrisScript
v0.0.1: No built-in profiler yet.
Workarounds:
- Use Godot's profiler for high-level metrics
- Add manual timing with
println!in runtime - Use Rust profilers (e.g.,
cargo flamegraph) on runtime
Coming in v0.2.0:
- Built-in profiler
- Hot reload
- Performance metrics
- Current version: v0.0.1 (released October 2, 2025)
- Status: Early alpha, experimental
- Production ready: Not yet - expect breaking changes
v0.0.1 Features:
- Basic compiler (lexer, parser, type checker)
- Runtime execution
- Godot 4.x GDExtension support
- Variables, functions, basic types
What's NOT ready:
- Match expressions, enums, structs
- Full Rust ownership model
- Standard library
- Debugging tools
- v0.0.2 - Documentation & Polish (October 15, 2025)
- v0.1.0 - Language Features (December 15, 2025)
- v0.2.0 - Tooling & Developer Experience (March 15, 2026)
See v0.1.0-ROADMAP.md for detailed roadmap.
Not recommended for v0.0.1:
- Breaking changes expected
- Limited features
- Not performance-optimized
- Minimal documentation
Wait for v0.2.0 (March 2026) for stable production use.
However:
- ✅ Great for prototyping
- ✅ Learning Rust concepts
- ✅ Game jams (experimental)
- GitHub Releases: Watch the repository
- Discussions: Follow GitHub Discussions
- Issues: Subscribe to feature requests
- Changelog: Check CHANGELOG.md
Not yet - Currently using GitHub Discussions for community interaction.
Community channels (planned for v0.1.0):
- Discord server
- Reddit community
- Twitter updates
For now: Use GitHub Discussions for:
- Questions (Q&A category)
- Feature ideas (Ideas category)
- Show your projects (Show and Tell)
- Bugs/Issues: Open an issue
- Feature Requests: Discussions
- General Help: Q&A Discussions
- Troubleshooting: See TROUBLESHOOTING.md
- Contributing: See CONTRIBUTING.md
Made with 🦀 and ❤️ for the Godot community