- Project goals
- How to contribute
- Requirements to contribute
- Setting up the development environment
- Coding guidelines
-
Right now the main objective is to port over the original project's existing feature set and assets and make a playable version out of it.
-
The secondary goal will be to expand it to completion and add features entirely missing in the original, like military and the higher town tiers.
-
The third stage involves reevaluating the existing content for potential asset rework, upscaled graphics, rebalancing etc.
However, contributors are not obligated to strictly follow this order; it's first of all a lineup to point out the priorities from high to low. You're free to contribute anything valuable to the project and depending on its complexity and current relevance it will be merged now or at a later stage of the game.
To contribute to the project, get started by checking the current issues or add a new one for bug reports and suggestions. Also, as this is a complete rewrite, it is basically possible to apply improvements on certain aspects of the game from the start on whenever it makes sense. That said, if you know and love the original title and are well familiar with its in and outs, we'd appreciate your opinion on the current gameplay mechanics and economic balances. To discuss more directly with other contributors, visit our Discord server.
At the point of this writing, the Godot port is in an early experimental state with no playable content and therefore no release date set in stone.
For that reason, please check out the original project which bears a decade long active development history with tons of implemented features and will provide you a better insight on the desired look and feel than any textual explanation could do (even more so if being unfamiliar with RTS games). Besides you should be able to grab existing logic and convert it appropriately for the Godot/GDScript style.
This project is based on the Godot Engine using a Python-like scripting language. To learn more about it, get started at the official docs.
For further learning resources made by individual creators, you can find a rich overview of qualitative material enlisted here.
A valuable source of information specifically for this project would be RTS-specific Godot material.
- Fork https://github.com/unknown-horizons/godot-port.
- Clone the fork locally.
- Download Godot 4.x.x, at least the standard version required.
- Launch the Godot executable.
- Import project, search the Unknown Horizons directory, select
project.godot
. - Open the project from the project manager overview.
For the most part, the code style follows the official GDScript style guide.
Rules different from the official style and additional remarks:
class_name
(if present) succeeds theextends
line. Think of it like "include the base class, and now add the following additional logic under the name ofclass_name
":
extends Node
class_name InheritedNode
- Static typing. Everytime, everywhere. Use explicit types or infer the type. In most cases, inferring with
:=
should be fine unless the exact type is indeterminable at compile-time. Make type casts whenever useful. This will make the code overall less prone to errors. Custom signals (as of now) are dynamically typed only, so at least we will make it "static" to the developer by the following convention:
signal notification(message_type, message_text) # int, String
- Some methods return values that may be irrelevant depending on your use case, like
SceneTree.change_scene_to()
orObject.connect()
. To suppress the warning dispatched by those, hit the[Ignore]
button next to the warning message in Godot's warnings overview. This generates a specific line to explicitly acknowledge this circumstance. Indent it above the involved method call. That should look like this:
#warning-ignore:return_value_discarded
get_tree().change_scene_to(_scenes[scene])
- For warnings about unused method parameters however, prepend the parameter(s) in question with an underscore like this:
func _process(_delta: float) -> void:
pass
- Generally, one line break is to be placed where it says two in the official guide.
As always, there may be an exception from the rule, but those should be kept to a minimum and be reasonable.