# Unknown Horizons: Building and Installing a Python Colony Simulation > Unknown Horizons is a 2D real-time strategy game centered on economic growth, city building, trade, and diplomacy. Its Python codebase is approachable for contributors, but installing it requires native game-engine and GUI components that are not included in `requirements.txt`. **unknown-horizons/unknown-horizons** — Unknown Horizons official code repository - Repository: https://github.com/unknown-horizons/unknown-horizons - Website: http://unknown-horizons.org - Stars: 1,555 · Forks: 243 - Language: Python - License: not declared - Published: 2026-10-16 · Updated: 2026-10-16 · Language: en - Canonical page: https://hysenlabs.com/projects/unknown-horizons-unknown-horizons ## What Unknown Horizons Models Beyond Unit Combat Unknown Horizons addresses a specific kind of real-time strategy session in which territorial control alone does not determine success. The README describes a small settlement that can grow into a prosperous colony. Players collect taxes, provide inhabitants with goods, and increase their position through a balanced economy, strategic trade, and diplomacy. That framing makes the project more relevant to readers interested in simulation and management than to players looking primarily for direct combat or twitch action. The target audience has two sides. Players receive a 2D real-time strategy simulation with settlement management and economic systems. Contributors work in a Python codebase that combines game rules, data-driven object definitions, maps, rendering, and optional networking. The repository also publishes starter issues and a contributor guide, which acknowledges that newcomers are part of the intended development audience. The game is not positioned as a general-purpose strategy library. Nothing in the repository description suggests that its economy or city-building systems are designed for unrelated Python applications. The adoption decision should therefore concern the game itself, its development environment, or both. A player evaluating the project must assess installation and content compatibility. A contributor must also account for the native libraries that surround the Python code. ## Python Logic, YAML Data, SQLite Maps, and FIFE Rendering Based on the documented dependency table, Unknown Horizons divides its work across several technologies rather than implementing every layer in Python. Python 3 is described as the language used for everything, but the same table identifies SQLite for maps, YAML for object files containing component-based information, `fifengine` as the C++ game engine with Python bindings, and `fifechan` as the GUI library. This arrangement separates simulation logic from map storage, data definitions, engine behavior, and presentation. SQLite maps provide a persistence layer for game maps. YAML object files store component-based information and are described as easily scriptable, which matters for contributors who want to adjust game objects without treating every definition as handwritten Python logic. The repository layout reinforces that structure: `content/` holds game assets, `horizons/` is the principal Python package, `po/` contains localization resources, and `tests/` contains the test suite. The GUI path crosses into native code through `fifechan`, while `fifengine` supplies the C++ engine and Python bindings. This is the main architectural constraint for developers. Installing Python packages alone does not establish that the engine, rendering layer, assets, and launch path will work together. The README's platform-specific build instructions and container workflow are therefore part of the application setup, not optional background information. ## Source Installation and the First Launch Path The README does not provide a self-contained shell command for installing the game. Instead, it directs users to the Downloads section of the Unknown Horizons website for packaged installations. For the latest source version, it links to separate instructions for GNU/Linux, Windows, and OS X. A new source user should begin with the page for the intended operating system rather than treating `requirements.txt` as a complete installation recipe. The repository includes `run_uh.py`, `run_server.py`, and `run_uh.bat`, which show that the project has distinct entry points and platform-specific launch support. However, the available instructions do not document a verified `python` invocation, expected command-line flags, required working directory, or first-launch output. Presenting an invented launch command would imply support that the documentation does not establish. The first practical use should therefore follow this sequence: 1. Open the website's Downloads section to check whether a prepared installation is available for the target system. 2. If not, follow the repository's GNU/Linux, Windows, or OS X source-build guide. 3. Install or build the native components required by that guide, including the engine and GUI stack. 4. Use the launch entry point supplied by that platform guide and confirm that the game interface appears. 5. Start a new settlement, then observe the economy and city-building options described in the README. For contributors, the README points to a `Getting-started` guide, a container workflow under `development/docker/`, and issues labelled `D-starter`. The repository does not reproduce those instructions, so it does not document a complete container command or dependency bootstrap script. A source user should not substitute `pip install -r requirements.txt` as the documented installation procedure, because that file mainly lists development, testing, packaging, and quality tools such as `pytest`, `mypy`, `Pillow`, and `pyyaml`; it does not list `fifengine`, `fifechan`, or `pyenet`. ## Multiplayer Adds a Separate Native Dependency Unknown Horizons includes multiplayer support through `pyenet`, identified in the dependency table as the multiplayer library. The README explicitly says that this dependency can be ignored when multiplayer is not required. That optional boundary matters for both installations and source review: single-player users do not need to assume every network component is necessary, while multiplayer evaluators must include the library in their compatibility checks. The repository includes `run_server.py` alongside the GUI entry points, which is consistent with the presence of a distinct server-side launch path. Still, the available instructions do not explain server configuration, port selection, transport settings, lobby behavior, discovery, or deployment. The README does not document whether the server is suitable for a public internet-facing environment. Those details must come from the platform or development documentation before the server entry point is used for anything beyond local experimentation. This distinction is useful when deciding what to verify first. A contributor interested only in simulation rules may begin with the normal game path and omit `pyenet`. A network-focused contributor has a larger target because the networking library must cooperate with the engine, Python runtime, game state, and server process. The documented support channel can help with setup questions, but community contact is not a substitute for a written compatibility matrix. ## Operating-System and Dependency Boundaries The most significant limitation is the gap between the apparent simplicity of a Python project and the complexity of running its full engine. `requirements.txt` pins or constrains packages such as `coverage==4.4.1`, `greenlet==0.4.15`, `mypy==0.511`, `Pillow>=7.1.0`, `polib==1.0.8`, `pycodestyle==2.5.0`, `pytest==3.1.1`, and `pyyaml==5.4`. Several versions are old enough that current Python interpreters and operating systems may not accept them without environment changes. The documentation does not state which Python 3 versions are supported. Platform routing is visible in `setup.py`, which imports `distro` and selects a `games` executable directory on Debian, Linux Mint, and Ubuntu. Otherwise, it selects `bin`. The file also imports project code, obtains the release version through `horizons.constants.VERSION`, writes `content/packages/gitversion.txt` when `.git` exists, and uses setuptools commands to prepare a distribution. These are packaging mechanics, but the excerpt does not show successful builds or a complete list of system libraries. The correct first check is consequently platform-specific build compatibility, not an editor's preference for Python syntax. Contributors should confirm interpreter support, native library availability, graphics dependencies, and asset packaging through the linked build guides. Users seeking a simple command-line or browser deployment should not infer that support from the Python language choice; the README describes a desktop game with native engine and GUI dependencies. ## GPL v2, Separate Asset Licenses, and Maintenance Evidence The README states that Unknown Horizons is free software under the GNU General Public License, version 2. The repository metadata does not identify a single overarching license, but the source header in `setup.py` also uses GPL version 2 terms. That supports treating the core program as GPL v2 according to the project's own notices, while still checking the exact files involved in a planned modification or redistribution. Game media are not covered by a single blanket statement in the README. It directs readers to `doc/` for licenses used by music, artwork, sounds, and other resources. This separation affects upgrade work. A source update can include Python code, engine integration, YAML definitions, translations, maps, and assets with different licensing considerations. A contributor should inspect the applicable files in `doc/licenses/` and `doc/` rather than assume that every item under `content/` inherits one treatment. The repository is not archived, and its last push was on 2026-09-30, less than six months before 2026-10-17. That is evidence of recent repository activity, not proof that every platform has a current packaged build or that all dependencies are maintained. The listed releases are older: `2019.1` was published on 2019-01-12, `2019-dev` on 2019-01-13, and `2017.2` on 2017-02-07. Users should therefore distinguish recent commits from the age of formal releases. The README does not document a rollback procedure, release cadence, or upgrade migration guide. ## Unknown Horizons Compared with a Lightweight Strategy Prototype A conventional Python strategy prototype may use a package-managed GUI or terminal interface, keep maps in a simpler in-memory structure, and avoid native engine bindings. Unknown Horizons takes a different approach. It combines a complete game presentation with `fifengine`, `fifechan`, SQLite-backed maps, YAML object definitions, localization resources, optional networking, and platform-specific packaging. The result is better suited to a full colony simulation than to a small library embedded in a lightweight application, but it also has more installation and maintenance surface. Another realistic alternative is a packaged commercial colony builder or a browser strategy title. Those categories avoid source integration, but the available repository information does not support claims about any named product's mechanics, licensing, or system requirements. The meaningful comparison is architectural: Unknown Horizons gives contributors access to a Python codebase and its game data, while a packaged title shifts engine installation to the distributor. It also asks users to evaluate an older release line alongside newer repository commits. For development evaluation, a second alternative is embedding only the economic model in a separate Python service. That would avoid FIFE and `fifechan`, but Unknown Horizons is not documented as a reusable economy service. Its YAML files, GUI integration, map handling, and game loop are designed for the game repository. Adopting the whole project merely to reuse a few simulation concepts would therefore be disproportionate. ## Conclusion Unknown Horizons fits players who want a settlement game centered on taxes, goods, trade, diplomacy, and city planning, as well as Python contributors prepared to handle native FIFE components. It is a poor fit for a lightweight browser game, a modern dependency-minimal Python package, or anyone requiring a documented rollback and current packaged-release path. Before adopting it, verify that the target operating system has compatible `fifengine`, `fifechan`, and, for multiplayer, `pyenet` builds, then confirm that the selected installation route launches correctly with the intended game content. ## FAQ ### How do I install Unknown Horizons? The README directs users to the Downloads section of the Unknown Horizons website for packaged installations. Source users should follow the linked guide for GNU/Linux, Windows, or OS X, because the project also depends on native `fifengine` and `fifechan` components. ### Does Unknown Horizons require multiplayer support to run? No. The README says that `pyenet`, the multiplayer library, can be ignored if multiplayer is not wanted. ### What programming language and storage formats does Unknown Horizons use? The dependency table identifies Python 3 as the main language, SQLite for maps, and YAML for component-based object files. The GUI is provided by `fifechan`, while `fifengine` is a C++ game engine with Python bindings. ## Sources - [Issues](https://github.com/unknown-horizons/unknown-horizons/issues) - [Project website](http://unknown-horizons.org) - [README](https://github.com/unknown-horizons/unknown-horizons/blob/master/README.md) - [Releases](https://github.com/unknown-horizons/unknown-horizons/releases) - [unknown-horizons/unknown-horizons on GitHub](https://github.com/unknown-horizons/unknown-horizons) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/unknown-horizons-unknown-horizons