When attempting to use the primary and secondary damage JSON files in the game, it has been observed that they contain errors and do not match the column numbers provided in the CSV files. This results in incorrect placement of values and an error during the import process.

Additionally, there is no clear documentation or process for generating these JSON files from the source CSV files. This makes it difficult for game balancers to make changes to the CSV files and generate new JSON files with the updated values.

To address this issue, it would be beneficial to enhance the generation of these JSON files so that they accurately reflect the column numbers in the CSV files. It would also be helpful to provide clear instructions on how to generate these JSON files from the source CSV files.

The Godot project is configured to emit errors when optional typing is not used. Therefore, it is important to check for this and all other Godot-related errors in every pull request (actions).

This might be helpful: https://github.com/abarichello/godot-ci

The first step for foundation is to replace all one-seat licensed assets with CC0 placeholders and transform the entire game from 3D to 2D. After these initial steps, I will be able to upload the project to this repository, allowing us to commence work on it (more steps to follow).

• Replace all sound assets with CC0 ones.
• Replace music assets with CC0 ones.
• Replace current UI theme with Godot standard one.
• Replace game title.
• Change the game to 2D.

Currently, dictionary keys are being used to represent types (type.tres). However, properties might be a better choice, as they offer improved code completion and maintainability. By using properties instead of keys, we can reduce the likelihood of errors and make the code easier to understand and modify.

To implement this change, it is proposed to create a property abstraction layer on top of the generated dictionaries and replacing all instances of dictionary calls for types in the codebase. This abstraction layer could be implemented in types.tres

Depends on #43

Currently Nakama does not publish their docker images for arm64. I have created a setup that works by loading the binary directly from their release, however would be good to update either with our own docker registry image or even better with an official arm64 image from nakama.

I have created an issue on their repo:
heroiclabs/nakama#1160

When a new tag version is created (master branch), the game should be automatically deployed to the release section.
https://github.com/abarichello/godot-ci

Also having continuous integration builds available as artifacts would be a nice feature.

We need to define the file structure for saving the map, and being able to send it to the server and share between instances. This issue is created as a way to write down proposals and requirements accessible for everybody. At some moment some discord meeting will be created to finalize the decision.

What needs to be save:

1. The size of the map (yeah, I know, seems obvious)
2. The terrain tiles
3. Owner of the building
4. Units and his owner

Open questions:

• Did we wish to simply consider a map as a snapshot of a match?
  This will allow things like start a match with a building half captured, to compensate the first turn advantage, in that case, the file format maybe can be the same as the one to synchronize with the server

Please add proposals as comments.

Currently, creating a new tag in the repository triggers the automatic creation of a new GitHub release. However, the release description is currently empty. To improve transparency and provide better context for each release, it would be beneficial to automatically generate the release notes from the conventional commit messages that were used to create the tag. This will allow users to easily understand what changes are included in each release.

A possible implementation could be done here:

Hi,

I just opened the project in godot, and I've got the following missing dependency:

In our game, there is currently no clear way to see if a transport unit (APCs, Lander, T-Copter...) is carrying another unit.

Proposal:

• Add a small icon next to the unit's name or health number that indicates whether it is carrying something or not.
• This can be done in the logic/game/ui/unit_stats.tscn scene.
• The icon can be used as a template and doesn't have to be final, like the lock icon from the sprite sheet:

The current Godot version still generates errors when running in headless mode. A new error has arisen at the SCRIPT level, triggering type checking and resulting in a negative pipeline result. Currently, I am ignoring this error. The question is whether we should deactivate the type check until Godot no longer produces such errors in newer versions, or if we should add an exception so that these specific errors do not affect the pipeline.

Let's test!

In order to streamline the credit generation process for the game, we need to implement a new system that utilizes a .cvs (Comma Separated Values) file. This will allow us to easily update and manage the credits within the game.

The system should be able to read the .cvs file, parse the data, and use it to generate the appropriate credits for the game. It is important that this system is flexible and easy to maintain, as we may need to make updates to the credit values in the future.

The .cvs file containing the credit data should be placed in the following directory: res://doc/credits.cvs

Once the credits have been generated from the .csv file, they can be stored as a text asset under the level named menu in the following path Menu -> Credits -> Panel ScrollContainer -> RichTextLabel

The credit values should be generated as soon as the editor is launched: https://docs.godotengine.org/en/stable/tutorials/plugins/running_code_in_the_editor.html

The structure of the credit.csv file should be such that each row represents an entry, and the following columns should be provided:

• Name / Author String: The name of the author or creator of the entry or provided assets.
• Title / Provided Assets String
• External Flag
• URL to a landing page / Source URL String: The original source of the provided assets, if they were created external.
• Description String: A brief description of the entry or provided assets. (external)
• Date Added Date/Datetime: The date on which the entry was added to the file.
• Last Updated Date/Datetime: The date on which the entry was last updated in the file.
• License String: Information about the license under which the provided assets are made available, if applicable. (external)

Which information should also be generated for in-game view needs to be discussed with the UI team.

The current movement of units is in a linear transition. Godot offers multiple transition modes through the use of Tweens.

One transition that is appealing to Mangs is the cubic transition with ease in out (top right in the animation). We should consider incorporating this type of transition in all possible animations, as long as we receive approval from the artists.

This issue focuses on the movement of units and can be reworked using a PathFollow2D, tweening, and interpolating the unit offset (property of PathFollow2D).

• When a player selects a submarine, they will have the option to "dive" in addition to the regular movement and attack actions.
• When a submarine dives, it becomes hidden from the enemy's view and cannot be targeted or attacked.
• The submarine is only visible again when an enemy unit is next to it, at which point it can be attacked as normal.
• While submerged, the submarine's turn fuel consumption should be changed to the "hidden_turn_fuel" value.
• In the unit stats the value is_hidden should be set
• When a submarine is submerged, it gains the ability to emerge on the surface again, losing its hidden state.
• This should also work with other stealth units.

EDIT: Linting is throwing an exception, so we will set aside the gdscript toolkit until this issue is fixed: Scony/godot-gdscript-toolkit#191

As part of our development process, it is important that we maintain clean and consistent code. To help with this, we would like to implement a linter as part of our continuous integration (CI) pipeline. This will ensure that all code changes are checked for syntax errors and style issues before they are merged into the main branch.

• Enhance current code to pass linting tests
• Add linting checks as part of our CI pipeline, so that all pull requests are checked for linting errors before they can be merged

https://github.com/Scony/godot-gdscript-toolkit

The linting should allow private function calls outside of its class because it is blocking calls like super._pressed() (private-method-call)

Currently, game exports a web version for every push and pull request directly to the root folder of the GitHub page. This setup can lead to confusion between release (public) and artifact (internal) versions of the game.

To improve organization and clarity, it is suggested to update the release process as follows:

1. Create a new subfolder within the GitHub page for storing web export artifacts generated from push and pull request events.
2. Modify the release process to perform the web export to the root folder of the GitHub page (only when a tag is created), signifying an official game release version.

This change will ensure that the root folder contains only the most recent stable release version for public use, while the subfolder holds all intermediate artifact versions for internal testing and development purposes.

As part of our continuous integration and delivery pipeline for our game, we currently create artifacts for pushes and pull requests. However, we are missing the step of adding these releases to the releases page on GitHub upon pushing a tag.

Currently, the web export of our Godot game is not automatically deployed to a GitHub page when new code is pushed. This makes it inconvenient for testers and players to access the latest version of the game.

To solve this issue, we could implement an automated build and deployment process that pushes the web export to a GitHub Pages site each time changes are merged into the main branch.

Currently, to create a map, one has to place nodes directly into the scene. This process should be enhanced by implementing the use of Godot's tiled map editor. The new system should have the capability to automatically choose the correct tile based on the neighboring tiles, while still retaining all the information that a tile needs to provide.

Todos

• Tile Map auto tiling
• Tile Map to Map: Map generation while using tile map (visible game map and hidden tile map autotile logic)
• Map to Tile Map: Allow existing maps to be edited, generating the corresponding tile map for editing tiles with autotiling
• Map to JSON: Enable saving a map state as JSON to a file (and in the future send it to the server for synchronization)
• JSON to Map: Implement loading a map file (and receiving one from the server in the future)

I spoke with Ephraim225, who provided some good suggestions for the map editor that should be implemented:

• Implement the ability to set statis for units (e.g. health, river flow direction, AI behavior)
• Add regional copy-and-paste functionality based on https://github.com/joaofrancese/awsmaped
• Incorporate line, circle, and square tools based on https://github.com/joaofrancese/awsmaped
• Provide the option to place individual tiles without automatic tiling
• Add a setting for roads to connect to buildings while placing tiles

When building artifacts for our game, it is important to ensure that the version of the game being built is accurately reflected in the artifact. Currently, the game version is not automatically updated during the build process to reflect the current commit hash. This can lead to confusion and discrepancies between the version reported by the game and the actual version of the code used to build it.

Additionally, when generating a release, the game version should be automatically updated to reflect the tag being used.

To address this issue, I propose implementing the following changes:

1. Automatically update the game version to the current commit hash during artifact build process.
2. Automatically update the game version to the used tag during release generation.

1. Add a new state in the Finite State Machine (FSM) called "CONSUMING" which should be placed after the "REPAIRING" state.
2. In the "CONSUMING" state, units with a turn_fuel or hidden_turn_fuel (submarines when they are submerged) value greater than 0 should consume fuel according to their respective values (when the player starts their round).

The client should use the types placed in the "/type" folder as lookup tables. This modification will replace the current property resources, such as unit properties and terrain properties. The final structure should be located within the "client" folder, as Godot uses this as its relative starting path.

This issue aims to implement an auto-updater feature directly the Godot game. The updater will run when the game starts, checking if the current version is older than the one available on GitHub releases site. If a new version is found, the updater will prompt the user for permission to download and replace the existing executable with the latest version, then restart the game.

The updater should also detect the specific system (e.g., iOS, Android) it's running on. In cases where self-updating isn't possible, the updater will simply notify users that a new version is available. This could also be helpful for a Steam release, as automatic updates are already provided.

The following links may be helpful for implementation:

• OS.set_restart_on_exit
• OS.create_instance
• OS.get_executable_path

The current workflows being utilized contain a number of repetitive steps, which can make them difficult to read and maintain over time.

1. Identify the most common repetitive steps across our workflows.
2. Determine whether these steps can be consolidated or refactored into reusable components or functions.
3. Implement the changes and thoroughly test the updated workflows to ensure they function as intended.

To implement this feature, I propose adding an additional boolean value called "can_destroy_on_empty_fuel" to the unit types in our codebase. This value would determine whether a unit is destroyed or not when its fuel reaches 0.

1. Add the "can_destroy_on_empty_fuel" boolean value to the unit types in our codebase.
2. Modify the unit logic to check if the "can_destroy_on_empty_fuel" value is true when the unit's fuel reaches 0. This should be implemented in the FSM phase "CONSUMING".
3. If the value is true, destroy the unit.

Depends on #52

With this P/R: #59 after some change of name in a variable that was not changed in all the instances, we detect that our current pipeline is not validating the shaders.

Will be good to add a pipeline that can typecheck the shaders, to avoid merging errors into the master, for the moment, we can only relay on the 4 eyes principle.

I have encountered an issue where the shader used for coloring units and terrains is not working as expected when exporting the project to a web format. I tested it in Firefox and Chromium:

As you can see, the units and buildings are all in their respective sprite colors.

The game is currently missing several units, including air and naval units. These can be implemented along with their appropriate buildings using the new type system #11 and the images already present in the project.