Real-time strategy games have always presented developers with an unusual challenge. An RTS may not need the enormous cinematic environments of a modern open-world game, but behind the scenes it can be doing an incredible amount of work.
Hundreds or even thousands of units may be moving simultaneously. Each can have its own destination, health, weapons, targets and orders. Meanwhile, the game may be calculating pathfinding, enemy AI, resource production, construction, line of sight and combat while still trying to maintain a smooth frame rate.
For independent developers attempting to build the next great RTS, that can become a serious technical problem.
One increasingly interesting answer may be an unusual combination: Godot and Rust.
Godot provides an increasingly capable free and open-source game engine, while Rust provides a high-performance systems programming language designed around speed, reliability and memory safety.
Put the two together, and developers have the ingredients for a potentially powerful RTS development stack.
Why Godot?
Godot has grown considerably from its beginnings as a relatively obscure open-source engine.
Today, it provides developers with a full 2D and 3D game engine, an editor, physics, animation, UI tools, networking capabilities and its own scripting language, GDScript.
Perhaps more importantly for independent developers, Godot remains open source.
That means developers aren't building their game around an engine whose licensing terms or business model could suddenly change underneath them. Godot's MIT license permits developers to modify the engine and use it commercially.
For an independent studio trying to build a game over several years, that freedom can be extremely valuable.
Godot is also increasingly relevant within indie development. Research examining games released through Steam and itch.io found that Godot had gained significant relevance among independent developers.
But building an RTS presents a different challenge from building a typical platformer, RPG or small indie game.
Eventually, the number of things happening simultaneously can become enormous.
That's where Rust becomes interesting.
Enter Rust
Rust is a systems programming language designed to provide high performance without abandoning memory safety.
According to the official Rust project, Rust has no garbage collector or runtime and is designed for performance-critical software. Its ownership and type systems are also designed to provide memory and thread safety.
Those characteristics make Rust particularly intriguing for simulation-heavy games.
Imagine an RTS battlefield containing 5,000 units.
Every unit might need information about:
- Its current position
- Destination
- Movement speed
- Health
- Weapon range
- Current target
- Nearby enemies
- Pathfinding
- Formation
- Line of sight
- Attack cooldowns
- Status effects
- AI state
Now multiply those calculations by thousands of units while simultaneously running the rest of the game.
A developer doesn't necessarily want every soldier represented by a huge collection of heavyweight game objects performing expensive operations every frame.
Instead, much of that simulation can potentially be handled as highly optimized data.
And that is exactly the sort of workload where a systems language like Rust becomes interesting.
Godot Doesn't Have to Do Everything
One of the most attractive ideas behind combining Godot and Rust is that developers don't necessarily have to choose between them.
Godot can remain responsible for the parts of the game it already handles well.
That could include rendering the battlefield, displaying units, animation, sound, menus, user input and the game's interface.
Rust could potentially handle some of the heavy simulation underneath it.
For example:
Godot
Rendering
Animation
User interface
Input
Audio
Camera
Scenes
Visual effects
Rust
Unit simulation
Large-scale combat calculations
Spatial searches
Economy simulation
AI systems
Pathfinding algorithms
Formation calculations
Other CPU-intensive systems
That division isn't a requirement, and it certainly won't be appropriate for every game.
But for an RTS attempting to simulate very large battles, it creates some fascinating possibilities.
How Does Rust Actually Talk to Godot?
This isn't simply a theoretical combination.
Godot 4 includes a technology called GDExtension.
Godot describes GDExtension as a way for the engine to interact with native shared libraries at runtime, allowing native code to run without recompiling it into the engine itself.
Community projects can then build language bindings around that interface.
One of those projects is godot-rust.
The project provides Rust bindings for Godot 4 through GDExtension and specifically describes Rust as an alternative that can focus on type safety, scalability and performance. Importantly, developers don't have to abandon GDScript. The godot-rust project says the two languages can coexist within the same game, with custom Rust APIs callable from GDScript.
That opens up a very useful development model.
A developer could prototype an RTS mechanic quickly in GDScript.
If the system works and performs adequately, there may be absolutely no reason to rewrite it.
But if profiling reveals that one particular simulation system is consuming too much CPU time, that component could become a candidate for a native Rust implementation.
Do You Actually Need Rust?
This is probably the most important question in the entire discussion.
Maybe not.
Rust shouldn't be added to a Godot project simply because Rust has a reputation for being fast.
Godot's GDScript is extremely convenient for gameplay development, while Godot also supports C# for developers who prefer a statically typed language.
A game containing 200 units doesn't automatically need an advanced native simulation architecture.
Optimization without measurement can make a game considerably more complicated without producing a meaningful improvement for players.
Even godot-rust's own documentation cautions developers about trading safeguards for additional performance and recommends measuring first rather than assuming that maximum performance is necessary.
That's excellent advice beyond Rust itself.
Build it. Profile it. Find the bottleneck. Then optimize it.
If an RTS performs perfectly well using GDScript, keep using GDScript.
If pathfinding for 3,000 units suddenly destroys the frame rate, now there is a measurable problem worth solving.
Rust becomes a tool rather than a religion.
The 5,000-Unit Question
This is where we think things could get particularly interesting.
Instead of debating which language is theoretically faster, we'd like to see what happens in an actual RTS-style workload.
Imagine a simple battlefield.
Start with 100 units.
Then 500.
Then 1,000.
Then 2,500.
Finally:
5,000 independently simulated units.
Give those units relatively simple RTS behaviors.
Move toward a destination.
Search for nearby enemies.
Acquire targets.
Attack.
Take damage.
Die.
Then measure what happens.
Not just frames per second, either.
Measure simulation time, frame time and CPU usage while increasing the number of active units.
A second implementation could move the computationally expensive portions of that simulation into Rust.
Would it dramatically improve performance?
Would communication between Godot and Rust introduce its own overhead?
At what unit count would the difference become noticeable?
Would a better GDScript architecture eliminate most of the problem without introducing Rust at all?
Those are far more interesting questions than simply declaring one programming language the winner.
Rust Could Also Change How the RTS Is Architected
Performance isn't Rust's only potential advantage.
Rust encourages developers to think carefully about ownership and data.
That could fit particularly well with an RTS architecture in which the simulation is separated from its visual representation.
The soldier the player sees doesn't necessarily have to be the simulation.
Instead, Rust could maintain something resembling:
Unit #2847
with its position, health, orders, target and other state.
Godot could then be responsible for presenting Unit #2847 to the player.
That separation could have additional benefits.
The simulation could potentially become easier to test independently from graphics.
It could also encourage developers to build deterministic or server-authoritative systems for multiplayer games.
Those are architectural possibilities rather than automatic benefits, but they're especially interesting for strategy games where the underlying simulation can be just as important as the graphics.
There Are Trade-Offs
Godot plus Rust isn't a magic button.
Adding another language adds complexity.
Developers need to understand Rust, Cargo, Godot and the interface between them.
The workflow can also be more complicated than writing GDScript directly inside Godot.
And godot-rust itself is still evolving. Its maintainers describe it as usable for games, editor plugins, tools and other Godot applications, but also note that breaking changes can occasionally occur. Mobile and WebAssembly support are currently described as experimental, with documentation and tooling still lacking in those areas.
That's important for developers considering the technology for a commercial project.
A desktop RTS targeting Windows and Linux may face a very different set of concerns from a project expected to ship simultaneously on PC, Android, iOS, web and consoles.
There is also development speed to consider.
GDScript was designed specifically for Godot.
Rust wasn't.
For many gameplay systems, writing 30 straightforward lines of GDScript may be a much better engineering decision than constructing a sophisticated native Rust implementation.
The fastest program isn't necessarily the program that was fastest to develop.
An Open Stack for Independent Developers
There is another reason the combination is interesting beyond raw technical performance.
It represents an unusually open development stack.
Godot is open source and distributed under the MIT license.
Rust is an open-source programming language.
godot-rust itself is open source and licensed under MPL 2.0. Its maintainers explicitly state that the library can be used commercially and that developers can keep their own game code closed source, subject to the license's conditions if they modify godot-rust itself.
For independent game developers, that means access to extraordinarily capable technology without purchasing an expensive engine license just to begin experimenting.
A student can download the tools.
A solo developer can use them.
A small studio can use them.
And a successful commercial developer can use them.
That's healthy for game development.
Could This Help Produce the Next Great RTS?
The RTS genre has always attracted technically ambitious developers.
Games in the genre aren't simply rendering worlds. They're simulating them.
Armies move.
Factories produce units.
Resources disappear.
Projectiles travel.
Buildings collapse.
AI opponents evaluate strategies.
Players issue commands across enormous battlefields while the computer attempts to keep the entire simulation synchronized.
The larger those simulations become, the more interesting technologies such as Rust become.
Godot gives developers a capable engine and editor without locking them into a proprietary ecosystem.
Rust gives programmers another option when portions of that game need native-level performance and stronger compile-time guarantees.
And GDExtension provides the bridge that allows those worlds to meet.
That doesn't mean every Godot RTS should immediately be rewritten in Rust.
Quite the opposite.
Start simple.
Build the game.
Make it fun.
Profile it.
Then, when thousands of units start bringing the simulation to its knees, reach for the bigger hammer.
For some independent RTS developers, that hammer might increasingly be Rust.
And that makes Godot + Rust one of the more interesting open-source game-development combinations worth watching.
NeonRoof News will continue covering Godot, Rust, libre game development and the technology independent developers are using to build the next generation of PC games.*
*
No comments yet. Start the conversation with a useful, on-topic response.