Gododin at a glance

Gododin lets you write parts of a Godot game in Odin, a systems programming language with structs, free procedures and explicit memory management. An Odin component becomes a native Godot class: you can add its Node to a scene, edit its properties in the Inspector, call its methods from GDScript and connect its signals.

Godot remains your engine. Its scenes, Resources, renderer, editor and export pipeline still build the game, and GDScript remains a natural choice for gameplay, UI and orchestration. Gododin compiles Odin into native libraries loaded through Godot's GDExtension interface.

This page describes the intended complete product. The implementation plan records delivered work, and the version/support policy owns current availability. Start using it through the five-chapter usage guide. For installation and project connection, use the separate setup guide.

Is it for your game?

Consider Gododin when you want to:

• simulate a flock, route many agents or process a large grid in one Odin call;
• generate terrain or bake assets with ordinary Odin code;
• expose native settings and services as Godot Nodes or Resources; or
• integrate an existing Odin package or native library into your game.

Start with one useful operation. For example, a GDScript scene can send a cave generation request to a native Node and receive a whole grid back, then use Godot to draw it and build collisions. You can keep the rest of the game as it is. You should be comfortable with basic Godot scenes and Odin, including pairing allocations with cleanup. A speed benefit depends on the workload and must be measured; the parity matrix records comparisons.

Odin structs and procedures implement native Godot classes. The class marker chooses the engine base; it does not create Odin inheritance. Gododin permanently excludes attachable Odin Script resources and an Odin scripting runtime. The product overview separates accepted scope, that final exclusion and deferred products.

What you write

Ripple Pond uses three small pieces:

1. A Godot scene and GDScript controller handle input, call step() on a native RipplePond Node, and display the returned water frame.
2. An Odin component holds the instance's state and defines its methods, saved damping property and splashed signal.
3. A plain Odin package runs the water simulation and owns its buffers. It has no Godot, Gododin or Raylib imports, so its algorithms can be tested independently of the engine.

Gododin generates the registration and dispatch code that connects the scene to the component. This connection is called the bridge. Its stable native library, the Host, keeps the callbacks Godot retains and calls the right Odin procedure for each instance. You maintain the component and simulation; the build generates the bridge.

Calls can go both ways. A native method that calls Godot receives a temporary gd.Main_Call parameter from the bridge. It permits engine calls during that callback and expires when the method returns. The authoring chapter and diagram show state, cleanup and both directions of the call.

What the complete product provides

The Godot editor remains the durable game workspace, alongside an external Odin editor. Connect the SDK once in the Gododin dock, then open the game normally from Godot's Project Manager. Builds and native editor reload run automatically; Play uses F5/F6 and deployment uses Project > Export. Supported native edits reconstruct state and restore compatible stored properties in the editor; launched games change code through Stop and Play. The development-loop chapter owns the procedure.

Players receive the Godot runtime, game content and required native libraries, without the compiler, Gododin SDK, CLI or development tools. The shipping chapter owns export and SDK maintenance.

Explore further

Follow Getting started to run Ripple Pond, then write a method and observe your own edit in the next two chapters. Ripple Pond is the compact adoption example; Cavern Lab adds substantial computation, background work and asset baking. Other examples have distinct lessons in the example suite. The API design and architecture explain the underlying engine-call and ownership contracts when you need more detail.