godot-port rebuilds Unknown Horizons on Godot 4, one map loader at a time
Unknown Horizons Godot Engine Port
At a glance
- What is it?
- The godot-port repository is a GDScript reimplementation of the Unknown Horizons real time strategy game, started because the original engine and its GUI library are no longer usable. The README states plainly that the port has no playable content and no release date, so it is a repository for contributors, not a download.
- Who is it for?
- Adopt godot-port if you are a Godot programmer or a 2D artist who wants to work on a real time strategy game with a large existing asset library, and if you are comfortable contributing to a project that cannot yet be played from start to finish. Do not adopt it as a way to play Unknown Horizons today, because the README says there is no playable content and no release date, and the playable route remains the original project.
- Can I use it commercially?
- Yes, with conditions. GPL-2.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository last received commits 39 days ago.
- What is it written in?
- Mainly GDScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 22, 2026, and from our analysis. They are not legal advice.
Editorial analysis
A port with no playable content, aimed at contributors
Unknown Horizons is a 2D real time strategy simulation with an emphasis on economy and city building. You expand a small settlement into a colony, collect taxes, supply inhabitants with goods, and use trade and diplomacy to increase your power. The game has been under active development for a decade in its original form.
This repository is a port of that game to the Godot Engine, and the README is unusually direct about its state. The port is described as being in an early experimental state with no playable content at this point of time and therefore no release date set in stone. There are no GitHub releases, and the licence field is GPL-2.0 with a LICENSE.md file in the root.
So the audience is not players looking for a binary. It is contributors, and the README says exactly which ones it wants: mainly Godot programmers, then a graphics artist for new assets and a possible rework of existing graphical content, later a sound effects and music creator, and a design document writer to fill out the project wiki. A volunteer with time and a specific skill is the resource this repository is short of, not money or a publishing deal.
The reason for the port is that the old engine and GUI library died
The motivation is stated in the first lines of the README: they want to port it because the current engine is basically dead, and the used GUI library is also dead with a lot of issues. The same paragraph adds that they really love the game and the community loves it too.
That is the entire case for the work, and it is a case about maintenance rather than features. A game written against an engine and a GUI toolkit that are no longer maintained cannot be updated for new operating systems, cannot easily gain support for modern input methods, and cannot be built by a new contributor without fighting a toolchain that predates the current decade. Porting to Godot 4 resets that clock.
The trade-off is equally plain and the README does not hide it. Porting a codebase means reimplementing it, and the source of truth for how the game should behave and look is the original project, not any specification written for the port. The README is direct about this, pointing contributors at the original repository because a decade of active development history with implemented features gives a better sense of the intended feel than any textual description could. It also points out that existing logic can be grabbed and converted into the Godot and GDScript style, which is the practical reason the port is feasible at all.
Running the project means opening Godot 4, with no compilation
The setup is deliberately simple, because the point of moving to Godot is to remove the barrier of a build toolchain. The README states that the project is based on Godot 4, and the instructions are to get Godot from the engine download page, open the executable, import the project, and you are then set for developing and playtesting. No compilation is needed.
The repository root matches that story. There is a project.godot file, which is the file Godot itself uses to describe a project, along with asset directories such as Assets/ and code directories such as Utils/, DevTools/, Editor/ and External/. There are also small exported resources such as default_env.tres, default_bus_layout.tres and export_presets.cfg, which is the file holding the platform export configurations.
A few shell scripts sit alongside them, including build.sh, run.sh and file_format.sh. The README does not describe what these scripts do, so treat them as project conventions to read rather than as documented entry points. There is also a .vscode/ directory, which tells you that editor configuration is committed for Visual Studio Code users, and a .editorconfig file at the root for whitespace rules.
The one file that will matter most when you begin is CONTRIBUTING.md, which the README points to for the project goals and for setup and coding guidelines. The README does not duplicate those guidelines, so the repository is the place to look for them.
Maps load from a manifest first, with scene files as the fallback
The map loading path is one of the more concrete mechanisms described in the README, and it is a good place to look at how the port is being structured. Bundled maps are loaded from res://Assets/World/maps_manifest.json and also from res://Assets/World/World*.tscn, with the two sources deduplicated by scene path. The two bundled paths are:
res://Assets/World/maps_manifest.json
res://Assets/World/World*.tscnCommunity maps work the same way, but from the user data directory. A community map can be placed in user://maps and is loaded in one of two ways: user://maps/maps_manifest.json, which the README calls the preferred route because it gives an explicit and release-safe map list, or user://maps/World*.tscn, described as the simple drop-in route for map scenes. There is also an optional override, where a map scene sets the root node metadata key MapName to control the display name.
The user:// path is platform specific, and the README gives the three locations, with the application data folder named Unknown Horizons:
~/.local/share/godot/app_userdata/Unknown Horizons/maps
%APPDATA%\Godot\app_userdata\Unknown Horizons\maps
~/Library/Application Support/Godot/app_userdata/Unknown Horizons/mapsThe pattern here is deliberate: a manifest for controlled content, a glob for drop-in content, and metadata for presentation. That is a sensible design for a game with a modding community, and it is a decent deal more finished than the rest of the port.
A wiki, a forum and an IRC channel stand in for documentation
Because the port is early, the documentation burden sits in community spaces rather than in the repository. The README lists a Discord server, a bug tracker on GitHub, an IRC channel on Libera Chat at irc://irc.libera.chat/unknown-horizons with a web client link, and a forum hosted on freegamedev.net.
The wiki is called out specifically in the context of the design document writer the project is looking for. The README frames that role as a way to get a lot more information into the wiki, which tells you the wiki is the intended home for the design decisions that the port needs and does not yet have.
Two consequences follow for anyone evaluating this repository. First, a contributor without a development background can contribute something real, since writing the design documents that do not exist yet is a listed role rather than a consolation prize. Second, the practical instructions for building the game are not in the repository at all. The original project's own website and the wiki are where the reference content lives, and a newcomer who expects a self-contained setup guide will not find one.
GPL-2.0 for the code, separate terms for the assets
The licence situation is split, and it matters for anyone who wants to reuse what is in the repository. The README states that the game is free software and points to the GNU General Public License, version 2, with the licence text held in LICENSE.md in the repository root. The licence field on the repository records GPL-2.0 as well.
Assets are handled differently. The README says the licences used for music, artwork, sounds and similar content can be found in the original project's documentation directory, and the repository root holds a good number of imported image resources, Roads.png, full_terrain_iso.png, icon.png and the boot splash among them. The README also mentions that the project has a lot of blender files. The consequence is that the code licence does not automatically settle the terms for the art and audio, and anyone shipping those assets has to check the original repository for the per-asset terms rather than assuming the GPL covers everything in the tree.
The last push to this repository was on 2026-09-14, so work is continuing, and the branch structure is worth noting before you clone: the default branch is develop rather than master, and the README links the licence file from a master path. There are no tagged releases to install, so the only way to get the code is to clone it.
Where the Godot port stops and the original project takes over
The honest comparison is between two ways of running Unknown Horizons. The original project is a playable, decade-old codebase with a large set of implemented features, and it is the recommended starting point for anyone who wants to see the game. The Godot port is a reimplementation that starts from an empty playing field, using Godot 4 and GDScript, and it inherits the original's assets and its design intent rather than its code.
That difference in approach is the whole point of the port. Rather than trying to keep a dead engine and a dead GUI library alive, the project rebuilds the game on a maintained engine, and pays for that with a rewrite. The cost is that features have to be re-implemented rather than carried over, which is why a decade of existing behaviour has to be read as a specification. The benefit is that the resulting game is on an engine with current tooling, and that a Godot developer can contribute without learning an abandoned framework first.
For a player, the choice is simple and the README makes it: play the original. For a developer, the question is whether you would rather work on a live codebase with an existing feature set, or on a port where the feature set is yet to be written and the assets and the design intent are available to work from.
Editorial conclusion
Adopt godot-port if you are a Godot programmer or a 2D artist who wants to work on a real time strategy game with a large existing asset library, and if you are comfortable contributing to a project that cannot yet be played from start to finish. Do not adopt it as a way to play Unknown Horizons today, because the README says there is no playable content and no release date, and the playable route remains the original project. Before you start, read CONTRIBUTING.md for the project goals and coding guidelines, install Godot 4 rather than Godot 3 since the project is based on Godot 4, and look at the maps_manifest.json loading path to see how much of the surrounding structure already exists.
Frequently asked questions
Is the Unknown Horizons Godot port playable yet?
No. The README states that the Godot port is in an early experimental state with no playable content at this point of time and therefore no release date set in stone. The original project is the one to play.
How do I set up the godot-port project to start developing?
Install Godot 4 from the engine download page, open the executable and import the project; no compilation is needed. The README also points to CONTRIBUTING.md for the project goals and setup and coding guidelines.
How do community maps get loaded in godot-port?
Community maps are placed in user://maps and loaded either from user://maps/maps_manifest.json, the preferred explicit list, or from user://maps/World*.tscn as a drop-in route. A map scene can override its display name by setting the root node metadata key MapName.
What licence applies to the code and the assets in godot-port?
The code is free software under the GNU General Public License, version 2, with the text in LICENSE.md. The licences for music, artwork and sounds are listed in the original project's documentation directory, so the code licence does not automatically cover the assets.
What skills does the godot-port project say it needs?
The README says it is looking mainly for Godot programmers, a graphics artist for new assets and a possible rework of existing artwork, later a sound effects and music creator, and a design document writer to expand the project wiki.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/unknown-horizons-godot-port)Was this useful?