Ruby.CodeCompared.To/GDScript

GDScript's print appends a newline like puts, and both languages let you call it at the top of a file with no ceremony. The similarity is not a coincidence — GDScript's syntax is deliberately Python-flavored, and both languages optimize for reading like pseudocode.

The specifiers are the ones format/sprintf use in Ruby, so %s, %d, and %.2f behave as expected. A single non-array value works directly, but an array is required for more than one — and passing the wrong count is a runtime error, not a silent truncation.

There is also print_debug, which adds the file and line, and printt/prints, which join their arguments with tabs or spaces. None of them return the value the way p does, so p-in-the-middle-of-an-expression has no GDScript equivalent.

A ## comment above a class member becomes its documentation in Godot's built-in help, the way RDoc or YARD comments feed a doc generator — except the editor reads them directly, with no build step.

This is the single biggest day-to-day difference in feel. Rubyists usually reach for plain var at first, then move to := once they notice that typed variables catch mistakes when the script loads instead of mid-game — and that Godot compiles typed code to faster bytecode.

The types available are the engine's own — int, float, String, bool, every built-in like Vector2 and Color, any Node subclass, and typed collections such as Array[int]. In a game loop running 60 times a second, this is worth real frame time, which is the practical argument for annotating even when you dislike the noise.

Ruby's freeze protects the object, not the name; GDScript's const protects the name, and a constant array's contents stay mutable. The two languages have the guarantee in opposite places, which is worth remembering before assuming const NAMES is deeply immutable.

Ported code does not crash on this — it silently takes the other branch. A Ruby habit like if player.ammo means "does ammo exist?" but reads in GDScript as "does the player have ammo left?", which is a different question with the same spelling. Write if ammo != null when presence is what you meant.

There is no safe-navigation operator either — no &. — so a nullable value gets an if. GDScript does have is_instance_valid() for the specific case of a freed object, which is a real hazard once nodes come into it: a variable can hold a reference to something the engine has already destroyed.

A StringName and a String with the same characters compare equal, so mixing them is harmless; the difference is only cost. Use &"..." for a name compared every frame, and a plain string everywhere else. Note that dictionary keys are strings here, so the { fullscreen: true } shorthand becomes {"fullscreen": true}.

This bites in exactly one place and it is a game-development place: wrapping coordinates or indices around a grid. Ruby's index % width is always in range; GDScript's can be negative, so reach for posmod(index, width) when you want Ruby's behavior.

lerp, inverse_lerp, move_toward, smoothstep, and deg_to_rad have no Ruby counterparts and are used constantly in engine code. Note that ** exists in GDScript too, so pow(2, 10) and 2 ** 10 are both fine.

The big behavioral difference is mutation: Ruby's shuffle returns a new array (shuffle! mutates), while GDScript's shuffle() always mutates in place and returns nothing. Godot also has randomize() to seed from the clock — worth calling once at startup, since the generator is otherwise seeded identically every run.

This is one of the clearest wins of a typed engine language. Vector2, Vector3, Rect2, Transform2D, and Color are value types with overloaded operators, so position += velocity * delta means exactly what it looks like. There is no way to define such a type yourself in GDScript, though — operator overloading is reserved for the engine's own types.

GDScript has no ? or ! in identifiers, so the Ruby convention that tells you a method asks a question or mutates its receiver is simply absent — you check the documentation instead. Strings here are value types: to_upper() returns a new string and never modifies the original, so there is no upcase! equivalent.

Indexing with a single integer works and returns a one-character string, and negative indices count from the end (text[-1] is the last character). What does not exist is a range index — text[0..4] is a syntax error, because .. is not an operator in GDScript.

split returns a PackedStringArray rather than an ordinary Array — a compact, typed array the engine uses for string results. It indexes and iterates exactly like an array, but it will not accept non-string elements, which is usually what you wanted anyway.

This is the first place the missing exception system shows up, and the pattern generalizes across the whole language: check before acting, because nothing will be raised for you. str() is the global stringify function, standing in for to_s.

That is why the GDScript example above starts each line at column zero even though the surrounding code is indented. If you need indented source and unindented text, build the string with "\n".join([...]) or strip the lines afterward.

GDScript also has push_front/pop_front (Ruby's unshift/shift) and pop_back (Ruby's pop). Like Ruby, an array is a reference: assigning it to another variable shares it, and duplicate() is the copy — Ruby's dup.

Typed arrays also let the engine store elements more efficiently and let the editor autocomplete their members. The type may be any built-in or class name, including your own — Array[Enemy] — and Dictionary[String, int] works the same way since Godot 4.4.

select is spelled filter, and there is no sum, min_by, group_by, each_with_object, or flat_map — map, filter, reduce, any, and all are the whole set, so richer pipelines become explicit loops. Nothing chains as far as Enumerable does.

There is no sort_by, so sorting by a key means writing the comparison over that key, as above. Godot's sort is not stable, and a predicate that returns true for equal elements produces an undefined order rather than an error, so keep it a strict <.

slice takes an optional step, which covers Ruby's each_slice-adjacent cases, and negative indices work throughout. Because range() materializes an array, for index in range(1000000) allocates a million elements — the loop is idiomatic, but the huge-range case is one to avoid, unlike Ruby's lazy Range.

Dictionaries preserve insertion order, as Ruby hashes do. The method names to learn are size(), has(), keys(), values(), erase() (Ruby's delete), and merge(). Note that dot access is a convenience on the lookup only — it cannot create a new key.

Reading a missing key with [] is worth care: on a Dictionary it returns null, but indexing past the end of an array is a runtime error rather than nil. There is also get_or_add(key, default), which inserts the default as it returns it.

Because the higher-order helpers are thin, aggregations that are one Enumerable call in Ruby (values.sum, max_by) are explicit loops here. scores.values() and scores.keys() both return real arrays, so they can be sorted or filtered like any other.

duplicate(true) is a deep copy, which Ruby has no built-in for at all (hence the Marshal round-trip). Watch the default on merge: calling it with one argument silently keeps the original values, the opposite of what a Rubyist expects from merge.

Indentation being syntax is the adjustment. Tabs and spaces cannot be mixed within a file, and a stray indent is a parse error rather than a style complaint — which is stricter than anything in Ruby, where whitespace never changes meaning.

Losing unless and the trailing if makes guard-heavy Ruby noticeably longer in GDScript. The compensation is that the ternary composes into expressions, which is how default values are written here, since there is no ||= either.

Because for is a statement rather than a method taking a block, there is no each_with_index — pair it with range(array.size()) when you need the index. while exists; until and loop do do not, so an infinite loop is while true: with a break.

Two differences worth knowing: GDScript patterns cannot express a type constraint (there is no Integer => equivalent — use a guard inside the branch), and a dictionary pattern matches only if the keys listed are the only keys, unless you add .. to allow extras. Multiple alternatives per branch are comma-separated, and there is no fallthrough.

Ruby's next value — returning a value from a block iteration — has no counterpart, because for is not a method call and produces no value. Ruby's redo and retry have no equivalents either.

This is the largest single loss of expressiveness coming from Ruby, and it shows up everywhere — no each, no tap, no each_with_object, no block-based DSLs, no yield. In exchange, everything is explicit: there is only one way to pass behavior, and it has a type you can annotate.

GDScript has no proc/lambda distinction: arity is checked, and a return exits only the lambda, so the proc-returns-from-the-enclosing-method behavior has no counterpart. A multi-line lambda body must be indented under the func(...) line, which is why the assignment form above breaks across lines.

This is a real semantic difference, not a syntax one: Ruby's closure shares the variable, GDScript's copies it. The boxing idiom above (var total := [0]) is the standard workaround, and it is worth knowing before writing a callback that is supposed to remember something.

That last restriction is worth noticing: built-in values are not Objects in Godot, so there is no way to take a Callable to String.to_upper the way Ruby takes "hello".method(:upcase). A bound Callable is what you connect to a signal, hand to a Timer, or store as a callback, so the concept still matters well beyond map — and Godot also writes it object.method_name without parentheses when the type is known.

Getting this backward silently scrambles arguments rather than failing, so it is worth reading bind as "supply the trailing arguments." There is also unbind(n) to drop arguments the caller supplies — genuinely useful when connecting to a signal that passes more values than your handler wants — and bindv to bind an array of them at once.

Neither column runs here, and the reason is worth knowing if you are pasting from this page: both runners execute a snippet at method scope, and a func declaration needs class-body scope. In a real script this is the ordinary way to define a method; to define behavior inside a method, use a func(...) lambda instead (see the Blocks section). GDScript also has no one-line function form to match Ruby 4's def tripled(value) = value * 3.

A default expression is evaluated on every call, as Ruby's is — so func log(entries := []) gets a fresh array each time rather than sharing one, avoiding Python's mutable-default trap. Note that arity is strict: calling with too few or too many arguments is an error, not nil-filling.

Nothing verifies the keys of that dictionary, so a typo becomes a null rather than an ArgumentError — the opposite of the guarantee Ruby keywords give. In engine code the more idiomatic answer is often a small Resource or a class with @exported fields, which the editor can then check and even edit visually.

The one place variable arity does appear is Callable.callv(array), which calls a function with an array spread across its parameters — the closest thing to Ruby's * unsplatting at a call site. Engine functions like print accept many arguments, but that is a privilege of the built-ins, not something a script can declare.

Note that := cannot be used on those elements: an untyped Array holds Variants, so there is nothing to infer and the parser says so. Returning a Dictionary is often better here anyway — result["quotient"] survives someone reordering the return values, where result[0] does not. Destructuring does exist in one place: match patterns, which bind with var.

The constructor is _init, and instance variables are just var declarations at class scope — no @ sigil, and no attr_accessor needed, since all members are public and directly accessible. This example is display-only because the runner executes snippets at method scope, where class_name and func cannot appear.

Because every member is already readable and writable, these blocks are only for behavior, not for access control — GDScript has no private, and a leading underscore is a convention exactly as it is in Ruby-adjacent Python. The engine equivalent of attr_accessor plus editor support is @export var speed := 200.0, which puts the field in Godot's inspector for a designer to tune without touching code.

The engine's answer is composition through the scene tree: instead of mixing Damageable into ten classes, you add a Health child node to ten scenes. That is a genuinely different design habit, and it is the one most worth acquiring — Godot rewards small single-purpose nodes the way Ruby rewards small modules.

There is no separate inspect hook, so a class has one string form rather than Ruby's two. For a lightweight value type, Godot's own Vector2-style structs usually beat writing a class at all; when you do need a data holder that the editor can serialize, extend Resource instead of RefCounted.

That is why this example builds a RefCounted rather than asking a string whether it responds to a method — "hello".has_method(...) does not even parse. Duck typing works in the small (if thing.has_method("damage"): thing.damage(10)), but the engine idiom is a type check or a group membership test, both of which the editor can reason about.

This is the deepest structural difference on the page. Ruby lets a failure travel up to whoever is equipped to handle it; GDScript makes every layer decide immediately. push_error writes to the debugger and the console — it is logging, not control flow — and a genuinely unrecoverable state is usually handled by assert() during development or by defaulting to something safe and continuing, because crashing a running game is rarely the better option.

Some APIs use the other convention instead, returning null on failure with the detail available from a separate call (FileAccess.open plus FileAccess.get_open_error()). Knowing which is which is part of learning the engine, and it is the main thing a Rubyist has to keep in their head where rescue used to catch everything uniformly.

That is the opposite of Ruby, where a raise is a raise in every environment. The practical rule: assert what you believe to be impossible, and handle what you know can happen with an ordinary if. Note also that the arguments to assert are not evaluated in a release build, so any side effect inside one disappears too.

Neither one stops execution — the line after them runs, as the output shows. This is the whole reason they exist: with no exceptions in the language, the engine still needs a way for a script to say "this is wrong" and be noticed, and the Debugger panel is where a developer looks.

The consequences are immediate: your Godot code is distributed across nodes rather than centralized in one function, and it must scale movement by delta because the frame rate is not fixed. Godot also offers _physics_process(delta), which does run at a fixed rate (60 Hz by default) — that is the callback closest to DragonRuby's tick, and the right home for movement and collision.

This inverts where bugs come from. In immediate mode a missing draw is a disappearing object; in retained mode a stale node is an object that will not go away, and the fix is queue_free(). It also changes how you think about state: DragonRuby's render list is derived from state every frame, so state is the single source of truth, while in Godot the node is the state and keeping a parallel copy in a script is how the two drift apart.

The trade is speed of exploration against structure. args.state.whatever ||= 0 needs no declaration and no thought about ownership; var health: int forces you to decide which node owns the value, but the editor can then show it, type-check it, and — with @export — let a designer tune it without touching the script. Godot's equivalent of "state that outlives everything" is a singleton (an autoload) or a saved Resource.

The other shift is indirection: Godot input is addressed through named actions defined in the project's Input Map, so "move_right" can be bound to a key, a gamepad stick, and a touch control at once, and rebinding is a project setting rather than a code change. DragonRuby names the hardware directly (keyboard.key_down.space), which is more immediate and less remappable.

This is the piece of Godot most worth learning early, because the engine itself is built on it: body_entered on an Area2D, timeout on a Timer, pressed on a Button. A Rubyist will recognize it as blocks-as-callbacks with a registration step, and connect takes exactly the Callable from this page's Blocks section.

Once instanced, that enemy runs its own _process and manages itself, which is why Godot code has no central update loop iterating over enemies. The cost is a second place where behavior lives: some of the game is in scripts and some is in scene files edited visually, and a Rubyist used to grepping a codebase has to get comfortable with an editor holding part of the design.

The trade is control against machinery. Rectangle checks are trivially predictable and scale badly by hand; the physics engine handles slopes, sweeping to prevent tunneling, layers and masks, and areas versus bodies — but you configure it in the editor and it makes decisions on your behalf. Note the callback here is _physics_process, which runs at a fixed rate; doing physics in _process is a classic beginner bug.

_ready is the one to reach for: it fires after children exist, which is why get_node() is safe there and unreliable in _init. The Ruby column's idiom has a compensating virtue, though — because setup is just another tick, a hot reload re-runs it, which is what makes DragonRuby's edit-and-see-it loop as fast as it is.

The shapes are closer than they look. Button.new() is document.createElement, add_child(button) is appendChild, and button.pressed.connect(...) is addEventListener — a retained object you keep a reference to and mutate, in both cases. Where they part company is that Godot's event is a declared, typed signal belonging to the class (pressed exists because Button says it does, and connecting to a name it does not have is an error), while an HTML event name is a string the browser looks up at run time. The other difference is what the two are drawing on: HTML reflows into a document and its text is selectable and readable by a screen reader, while Godot paints a fixed pixel grid that knows nothing about either.

A VBoxContainer IS flex-direction: column — it lays its children out in order along one axis, and add_theme_constant_override("separation", 10) is gap: 10px. HBoxContainer is row, GridContainer is display: grid, and a child's size_flags_horizontal = SIZE_EXPAND_FILL is flex: 1. The mapping is close enough that a web developer can usually guess the Godot name. What has no CSS counterpart is that a Godot container is a node in the tree that a script can reach and reconfigure, rather than a property of the parent box; and what has no Godot counterpart is the cascade — Godot styles come from StyleBox resources hung on a Theme, which are looked up by node type, never matched by selector.

This is where a Rubyist feels the absence most sharply: Godot has no template language. There is no ERB, no Slim, no <%= %> — the only way to turn data into an interface is to write the loop and call the constructors, which is why the GDScript column is longer for the same result. The compensation is that everything the loop produces is a live object: who.text = "Ada" can be assigned again next frame and the label changes, whereas re-rendering an ERB template throws the old string away and produces a new one. When a Godot interface needs to be defined declaratively, that happens in the editor and is saved as a .tscn scene file rather than expressed in code at all.

The two are not the same kind of thing, and that is the lesson. SVG is retained: each <circle> is an element that stays in the document, can be styled by CSS and can be given its own event handler. _draw() is immediate: it is called when Godot decides the node needs repainting, it emits commands into a frame, and nothing it drew exists afterwards — to change the circle you change a variable and call queue_redraw(), and the whole method runs again. A Rubyist coming from DragonRuby will recognize immediate mode here; it is the one place Godot works the way tick does, and it is opt-in rather than the whole engine.

The CSS column describes the motion — two endpoints and a timing curve — and hands it to the browser's compositor, which runs it without ever calling back into Ruby. The GDScript column computes the motion: _process(delta) is called once per frame with the seconds elapsed since the last one, and the script decides where the square is now. That per-frame callback is the heart of a game engine and it is why delta is in the signature — a frame that took longer must move things further, or the game runs at a different speed on a different machine. Godot does also offer the declarative form, as a Tween or an AnimationPlayer, for exactly the cases where CSS would be reached for.

Neither column runs here — these are shell commands, not code. Worth knowing for a Rubyist: godot --headless --script makes GDScript usable as a scripting language for build and asset tasks, which is the closest thing to running a plain Ruby script, and it is what the test suite for this page uses.

The upshot is that both ecosystems are vendoring cultures, which is a genuine adjustment from bundle add. Godot's compensation is GDExtension: when GDScript is too slow for a subsystem, you write that subsystem in C++ or Rust and it appears as an ordinary class to your scripts — closer to writing a C extension for CRuby than to anything available in DragonRuby.

The catch is that the guarantee is only as good as your annotations: an untyped var is a Variant, and Variants are checked at runtime exactly as Ruby is. That is the practical argument for := everywhere — and Godot can be configured to warn on untyped declarations, which is the closest thing to running a type checker in CI.

There is no ||= or &&= either, so the "default it if absent" idiom becomes an explicit if x == null:. Watch for this especially around args.state.thing ||= 0, which is DragonRuby's most common line and has no direct translation.

The knock-on effect worth naming: a multi-line lambda has to be indented under its func(...) line, so the compact Ruby habit of a one-line block with a do…end fallback has no equivalent. Deeply nested engine code drifts right quickly, which is part of why Godot pushes behavior out into separate small nodes.

The habit that breaks is sorted = names.sort. GDScript catches that particular one for you — assigning the result of a void call is refused when the script loads, which is one of the nicer consequences of the type system. What it cannot catch is the mutation itself, so when the original matters, duplicate() first — and remember duplicate() is shallow unless you pass true.

Two practical consequences: for index in range(1_000_000) allocates a million-element array (write a while loop for very large counts), and a "between" test is value >= low and value <= high rather than (low..high).include?(value). The in operator does exist, but it tests membership in an array, dictionary, or string.

Calling a method on a freed node is a runtime error, so is_instance_valid(node) exists as the guard — a check with no Ruby counterpart at all, since Ruby has no way to destroy a live object. This matters most for anything that stores a node between frames: an enemy list, a target, a cached child.