unknown-horizons / godot-port

Unknown Horizons Godot Engine Port

We are looking for developers for our Godot Engine port. We want to port it because our current engine is basically dead. The used GUI library is also dead with a lot of issues. We really love our game and the community loves it too.

We are looking for:

• Mainly, Godot programmers.
• A graphics artist would be handy. For new assets but also to potentially rework existing graphical content. We have a lot of blender files.
• Later, a sound effects and music creator would be nice too.
• A design document writer would be really nice as well, so that our wiki could get a lot of more information.

---

Unknown Horizons is a 2D real time strategy simulation with an emphasis on economy and city building. Expand your small settlement to a strong and wealthy colony, collect taxes and supply your inhabitants with valuable goods. Increase your power with a well balanced economy and with strategic trade and diplomacy.

Find more information about Unknown Horizons on our website.

Contributing

This project is based on Godot 4. Get it from https://godotengine.org/download/, open the executable, import the project and you are good to go for developing and playtesting. No compilation needed!

Also consulate CONTRIBUTING.md for the project goals and further instructions regarding the setup and coding-related instructions. 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.

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.

Community

Type	Where?
Discord	https://discord.gg/VX6m2ZX
Bug Tracker	https://github.com/unknown-horizons/godot-port/issues
IRC Channel	irc://irc.libera.chat/unknown-horizons
Web IRC Link	https://kiwiirc.com/nextclient/irc.libera.chat/#unknown-horizons
Forum	https://forum.freegamedev.net/viewforum.php?f=100

License

This game is free software. It uses the GNU General Public License, version 2. The licenses used for music, artwork, sounds, etc. can be found here.

godot-port's Issues

System to store object specific data.

We need to think about how want to store data for objects, for example ships, warhouse and maybe other objects need to have an inventory.
The old UH used an entity component system for that, meaning that each object/entity had a dynamic list of components that defined what they can do. I'd like to have something that works at least similar but fits with godots system.

Object animation/rotation.

The current gfx of UH were made for a purely 2D engine. The animations are splitted into 4 (buildings) and 8 (units) directions respectively. The engine would take care of using the correct direction path for the given rotation of an object.

We need to find a way to either use the current prerendered images with godot or, since we have the original blender files available, reexport the graphics in a way that they are better usable with godot.

For the first we need to either find or make a class/script that can calculate the image to be used for any given angle.

For the second we would need to evaluate what we can actually do with the current blender files.

Unable to build

Hi,

I installed Godot from official website and placed it in .local/bin/Godot/3.1/Godot as deduced from build script, ran build.sh on Mint 19 and got errors. Can you try to create a simple Travis CI to provide example environment?

I won't promise any contributions at this point, but I worked at Flying Wild Hog, love Anno series and wanted to learn Godot anyway, so maybe...

Port the .po files from old repo to the new one.

We need to port the translations from the old repo to the new one. That we can archive the old repo and change weblate to the new repo.

Porting to Godot - a few beginner's questions

Hello,

I am still very unexperienced with programming, GitHub etc., but willing to learn. Most of you may know that there is a forum for porting Unknown Hirozons to Godot at FreeGameDev. Since I do my first steps with Godot, I came across a few hurdles, I asked questions about. Julius over at FreeGameDev suggested that I oppen an issue here with the link to that thread of mine, so maybe some more interested people could have a look, give some hints etc. Thank you so much for your patience with me.

Here is the link to the forum thread:
https://forum.freegamedev.net/viewtopic.php?f=100&t=14356

Use GDQuests code guidelines?

GDQuest has made some cool guidelines for GDscript / Godot in general I think we could use:
https://github.com/GDquest/kickstarter-quest-3/blob/4765997a54413022ff5c1a4e29eaf7b31f8ceaa6/docs/code-guidelines.md
I find them super useful for collaborating and also just for my own projects. They are meant for 3.1, but maybe we can use them when we switch to that version.

Port the ingame HUD

Port the Ingame HUD to Godot version.

@artism90 want to work on that.

Ship enhancements

• UI menu for all actions (can be a placeholder for now but with working code)

• trade/exchange: trade or exchange cargo with a warehouse in range (depending on who's the warehouse belongs to)

• attack action: shoot in intervals when in range, make the other ship take damage and sink it if no HP left (similar for buildings at coast)

• escort/follow action: follow/protect the selected ship, attack anyone who attacks the escorted ship. If several units are escorting the ship, make them take a reasonable group formation around it.

• patrol action: put two or more waypoints to visit repeatedly

• move by waypoints: to avoid dangers, go by a specifically defined route

• sell ship: sell ship for a fixed price or put it on an auction(?)

• self-destruction: play a nice sink animation and remove the ship afterwards

Unit feature requirements

Requirements for each unit type to reach feature completeness. Each check box can be seen as a single task. Some tasks are compounds of a more comprehensive logic and may depend on each other. The descriptions contain pseudo code to give an idea on possibly relevant data to be implemented code-wise.

If a task involves interaction with another unit, the kind or subset of units is explicitly specified in there. In case it is not obvious, see the definition part below.

Balancing aspects like explicit values for ranges etc. are deliberately omitted to keep focus on the actual mechanics.

Definition:

• Unit: Any moveable unit
• Land unit: Any unit on land
• Land troop: Military land unit
• Ship: Any amphibic unit

Feel free to share your thoughts and add suggestions or point out edge cases to be taken into account.

Unit behavior to be implemented

General behavior for all units

• Move in a route within an A* grid.
• Mark/Unmark occupied_tiles = prevent units overlapping with each other.
• Push forcefully idling units away if path blocking (especially relevant when trying to reach a warehouse in a tight spot).
• Always push own and non-hostile units.
• Never push hostile units.

Player-controlled land units

Land merchant

• Destroy itself if health == 0.

User actions

• Moving as a single unit: Just move to the destination point.
• Trade/Exchange: Trade or exchange cargo with a non-hostile warehouse_in_range.
• Trade route: to be determined

Melee unit

• work in progress, to be determined

Ranged unit

• work in progress, to be determined

Player-controlled ships

Huker (transport ship)

• Moving as a single unit: Just move to the destination point.
• Moving as a group of units: Take an appropriate group formation.
• Switch the group formation accordingly to the user choice.
• Have a stance of defensive | offensive. Defensive = Hold position when attacked. Offensive = Chase opponent to a certain extent and return to original position.
• Destroy itself if health == 0.

User actions

• Trade/Exchange: Trade or exchange cargo with a non-hostile warehouse_in_range.
• Trade route: to be determined
• Attack action: Stand and shoot after each cooldown timeout when hostile_target.is_in_range(), make the target (Ship | LandUnit | Building) take damage.
• Escort/Follow action: Protect the selected unit, attack anyone who attacks it. If several units are escorting, make it take a reasonable group formation around it.
• Move by waypoints: Avoid dangers by going a specifically defined route.
• Patrol action: Put two or more waypoints to visit repeatedly.
• Sell ship: Sell ship for a fixed price.
• Self-destruction: Destroy unit.

Frigate (military ship)

Currently identical to Huker. The main differences lie in the values for storage_slots / storage_capacity and amount_of_cannons, which are not discussed here.

• Moving as a single unit: Just move to the destination point.
• Moving as a group of units: Take an appropriate group formation.
• Switch the group formation accordingly to the user choice.
• Have a stance of defensive | offensive. Defensive = Hold position when attacked. Offensive = Chase opponent to a certain extent and return to original position.
• Destroy itself if health == 0.

User actions

• Trade/Exchange: Trade or exchange cargo with a non-hostile warehouse_in_range.
• Trade route: to be determined
• Attack action: Stand and shoot after each cooldown timeout when hostile_target.is_in_range(), make the target (Ship | LandUnit | Building) take damage.
• Escort/Follow action: Protect the selected unit, attack anyone who attacks it. If several units are escorting, make it take a reasonable group formation around it.
• Move by waypoints: Avoid dangers by going a specifically defined route.
• Patrol action: Put two or more waypoints to visit repeatedly.
• Sell ship: Sell ship for a fixed price.
• Self-destruction: Destroy unit.

Player NPC ships

Fisher

• Move within a certain circular area to a random water tile after required_steps and start fishing, increase resource +1 per interval timeout until max of storage_capacity has reached.
• Don't sail off if hostile_unit.is_in_range().
• If being in sea already, cancel fishing and return home with current_storage so far.
• Send feedback to its owner (fisher building) regarding the reason of return (storage_full, in_danger, ...).
• If the owner (fisher building) gets destroyed, destroy itself as well.

Neutral NPC ships

Free Trader

• Appear for the first time at a random edge of the map border once a warehouse exists.
• Create a linked list of available trade_posts from the closest to farthest warehouse and start a new trading journey to sail for those harbours until everyone has been visited and the journey ends. New warehouses built in the midst of a running session will be added in the next run.
• Navigate to the next warehouse in trade_posts.
• Process trade transactions.
• If trade_posts contains another element, rinse and repeat.
• Leave the map at the closest map edge.
• After an interval of "being abroad", return to the map at a random edge tile and create a new trading journey as described above.

Hostile NPC ships

Pirate

• Has a relationship of hostile | neutral, ranging from 0.0 - 2.0.
  • 0 - 1 hostile - attack if hostile_unit.is_in_range()
  • 1 - 2 neutral - don't initiate attack
• Can be bribed to reduce relationship to rivalising faction, with a random chance for the affected faction to find out about the briber and damage their mutual relationship.
• Regularly patrol over waypoints, randomly created within a subset of the entire GridMap. The subset consists of all GridMap tiles with an appropriate distance to civilized area (settled islands and player territory in general). That said, the more the player expands, the farther the pirate has to retreat to stay in "calm waters".
• Irregularly patrol over specific hotspots. Those spots are determined based on where general ship movement has been most frequent recently. Each tile on the map has a weight_of_interest which becomes "hotter" the more often it is passed by a ship and "cools down" the longer any activity is absent.
• If hostile_unit.is_in_range(), attack.
• If falls below minimum_health_threshold, retreat.
• Destroy itself if health == 0.

Why porting?

I like to question the motivation behind the “port” (which actually looks like a near-complete start from scratch) to Godot.

OK, the libs you use might be outdated and no longer maintained. But the question is: Is it really so bad?

What are the specific problems with the libraries you use? Is there any problem in the libs that is a complete showstopper and can't be worked around at all? Is working with the libraries so painful that proceeding programming can not be continued? Frankly, I doubt that. Even if there are serious problems, I doubt that any problem is so bad that the game cannot be finished at all.

The fact is, the current UH (2019.1) is already pretty far-depeloped and very functional and playable. I have played it, and had a blast! :) If the libraries are really that bad, I wonder how UH could possibly have made it so far already.

The problem I see with this move is that you're throwing away a lot of work and reset yourselves back to square one. All the work you have done to create Unknown Horizons … it's all for nothing. The work you will invest into the Godot “port” is work in which the project will not advance at all. You will spent a LONG time in repeating work that you have already all done (possibly also repeating old bugs that were already fixed before). Would the decision to go Godot have been in an earlier stage, where not much functionality was implemented, it would have made more sense, but now, at this fairly advanced stage, I'm afraid it's probably just too late.

Also, I see there's no actual Godot code written yet. It appears to me this idea of the Godot “port” is a non-starter. It seems that progress on the project has come to a near-standstill because of this decision, since work on the original project is de facto “forbidden” right now.

I also question why Godot was chosen specifically, seeing that the team probably has no experience in Godot yet (otherwise, you wouldn't ask for help).

Maybe the decision to move to Godot is not a good idea, and should be revised. Julius from FreeGameDev forums is also confused about this decision.

Also: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/

Mention used Godot version in the documentation

I tried to start project with Godot 3.2 and got error. I searched for solution and found missing function was introduced in Godot 3.5 while nowhere mentioned to use that version.

[Proposal] Unit Testing

It is my opinion that testing benefits any programming project. If done correctly in protects against creating and changing code in a way that makes it not work as expected. Unit testing can also be done without any easy way to test the code in the actual program.

A better explanation of unit testing can be found here:

http://gamesfromwithin.com/stepping-through-the-looking-glass-test-driven-game-development-part-1

Therefore I suggest that we take advantage of unit testing as much as possible.

The only unit testing framework for gdscript I found is Gut (https://godotengine.org/asset-library/asset/54),
but it seems to be working fine and has been updated recently. A wiki for it can be found here: https://github.com/bitwes/Gut/wiki

Build our First Building.

• Implement Ships (click to move) #13
• Add Ingame GUI
• Add Warehouse #14

Jj

Add Warehouse into the game

Our first Building should be an Warehouse that could be build from the Ship when there are enough resources.
Only one Warehouse could be build per island of an player. An other Player could build to one on the same island.

Warehouse graphics for Tier 1: https://github.com/unknown-horizons/unknown-horizons/tree/master/content/gfx/buildings/settlers/warehouse/as_warehouse_settler0/idle

Building highlight with cursor is slightly inaccurate

OS/device including version:
ArchLinux rolling release
develop branch

Issue description:
Cursor doesn't really point on building which it points to. It seems like the center is in the middle or at the right bottom of the cursor.

Screenshots of issue:

cursor is small, zoom in

The discord https://discord.gg/VX6m2ZX can't be logged in.

OS/device including version:

Issue description:

I tried severial times, still failed, the verification is so great that I can't be verified as not a robot.

Screenshots of issue:

Try to import our tile grapfics

Try to import our tile graphics that mapper could create an development map.

https://github.com/unknown-horizons/unknown-horizons/tree/master/content/gfx/base/moderate

Non-Discord contributions

Someone asked in FreeGameDev today:

Since it seems to be required for willing contributors to join those channels, i would like to know if they are bridged somewhere non discord.

So, is it true? Is it required to be on Discord to collaborate at all? What will one be missing out when one's not on Discord?

Note: Discord is not FOSS, so it will scare away some potential FOSS contributors.

numbers don't fit für BoxShape4x4 and BoxShape4x4Flat

Hi guys,
I was just browsing the code and noticed something odd with the numbers of the BoxShape thingies:

• BoxShape1x1 has Vector3(0.5, 0.5, 0.5)
• BoxShape2x2 has Vector3(1, 0.5, 1)
• BoxShape4x2 has Vector3(2, 0.5, 1)
• BoxShape6x6 has Vector3(3, 0.5, 3)

However

• BoxShape4x4 only has Vector(1.5, 0.5, 1.5) – shouldn't that be Vector(2, 0.5, 2)? or name it BoxShape3x3?
• analog for BoxShape4x4Flat: Vector3( 1.5, 0.05, 1.5 ) instead of likely Vector3( 2, 0.05, 2 ) or BoxShape3x3Flat

Minimap

Visually

It should support different layers of data overlapping each one on top of the other, with some transparency in between. Minimum four to five layers.

From ground to top:

• 1. Terrain:
  • Water >> blue
  • Ground >> brown
• 2. Territory: Overlay of each player's area of control
• 3. Places of Interest: Anything (static?) in the world that has any relevance to the gameplay (e.g. all existing warehouses to trade with)
• 4. Units: All moving units (most dominantly ships, but ground units likewise)
• 5. Events: Icons for any occuring event (e.g. fire outbreak, "faction has just found settlement", etc.)

Gameplay-wise

Obviously it should be possible to map each point on the minimap to a specific point in the real world (at least roughly) so that it can be used to interact and navigate with.

Action pattern

	Left click	Double left click	Left click and hold	Right click
Terrain/Territory	Jump to location		Jump to location and drag camera in moving direction
Place of Interest	Select entity	Select and jump to entity location
Unit	Select entity	Select and jump to entity location
Event	Jump to location			Discard event (remove icon on minimap)
While in a unit/movement context:	Jump to location			Send unit to destination and act depending on layer (e.g. PoI=>Warehouse: dock/trade)

Additional Remarks

• The minimap should allow zooming for more precise selection and viewing.

Use Godot 3.1?

In Godot 3.1 optional typing and the 'class_name' keyword get added, which are incredibly useful and make it easier to work together. Since it is nearly finished, it could be a good idea to start in 3.1 since upgrading from 3 to 3.1 would make us more work.

EDIT: It also has GLES2 support which might be needed for some devs with older computer or laptops.

Which renderer will be default? GLES 2, GLES 3 or Vulkan?

Now with Godot 3.0.6 we don't have any choice, so for now UH use GLES 3.
When Godot 3.1 will arrive, I would recommend moving immediately to GLES 2.
Even if Godot will support Vulkan, UH should stay with GLES 2.

Changing renderer when project will be advanced, probably will need a lot of work to customize it with it.

Different font sizes

For accessibility it would be good to allow multiple font sized in the text.

In the FIFE version it would be very hard to add this now. (see unknown-horizons/unknown-horizons#2805)
It is probably important to keep this in mind as when designing the gui from the beginning since it will be harder later on.

It is not necessary to allow any arbitrary font size, just 2 or 3 options would be enough

Implement Ships (click to move)

Player ships had overlays with the player color.
Ships movement is click to move.

Idle grafics: https://github.com/unknown-horizons/unknown-horizons/tree/master/content/gfx/units/ships/merchants/as_huker0/idle
Move grafics: https://github.com/unknown-horizons/unknown-horizons/tree/master/content/gfx/units/ships/merchants/as_huker0/move

Overlay:
Idle: https://github.com/unknown-horizons/unknown-horizons/tree/master/content/gfx/units/ships/merchants/as_huker0/color_idle
Move: https://github.com/unknown-horizons/unknown-horizons/tree/master/content/gfx/units/ships/merchants/as_huker0/color_move

port OR rewrite?

how much of the python code will be used for the port? often it's easier to just recreate things using godot's native node system instead of using structures from another language. a complete rewrite will be work-heavy but it's much easier to maintain and it becomes more modular if it's done the godot way from the start.

Create an static testing map.

On the fifengine based we had something like this:

Use instancing for the start menu buttons

It is kinda hard to maintain the menu like this, you have to change the font/scale/design for each one individually.

Archive old repo?

Yesterday I posted a few bugs on https://github.com/unknown-horizons/unknown-horizons. But I didn't know this repository is dead. Sorry for the trouble. But in my defense, I just didn't see it. The notification was hidden for me. I didn't scroll down all the way to the readme to see the message.

The repo description is “Unknown Horizons official code repository http://unknown-horizons.org”, which is now highly misleading.

On http://unknown-horizons.org/get-involved/ all links point to the old repo.

The old repo is not in archive mode. But probably it should be put into archive mode? This is a feature in GitHub that can be activated for any repo. When active, the repo is essentially read-only, with no new issues or PRs being allowed. Also, there's a highly visible yellow warning above archived repos.

Please make the notifications more visible so that fools like me don't spam the old repo ever again.

Create Main Menu

Recreate the old Main Menu:

[Improvements] Compiling Instructions missing (Godot project only)

Essential compilation instructions with Godot are missing.
It is not impossible to find out yourself, but it takes a long time if you have never heard of Godot before.

A more detailed guide on how to compile this with Godot Engine is desired.

UID Godot generation

Currently when using Godot, everything I touch generates uids which are different from existing ones, or from non existent ones. Maybe crawling through project at one point to regenerate uids would help future development, so we don't need to scroll through git changes and choosing which ones to commit.

Alpha Preview Build

Porting unknown-horizons to Godot is a pretty big task and it will take a long time. However, I would love to see very soon a highly experimental alpha-preview-build. Just a build that one can try. It does not have to do much. Even just displaying the menu and a map is fine, but having that build of the early early stage would give user a glimpse into the future of Unknown Horizons and potentially attract new developers.

Singleplayer Start Menu GUI

Thats the style of the old gui: