codename-recon / codename-recon Goto Github PK
View Code? Open in Web Editor NEWCodename: Recon - Turn-based strategy game
License: GNU General Public License v3.0
Codename: Recon - Turn-based strategy game
License: GNU General Public License v3.0
Previewing movement ranges and firing ranges is a base feature of all AW games.
Movement is previewed by selecting the unit (A in OG, left-click in project) and moving the cursor will preview the possible paths that unit can take. Enemy units can also be selected by the player, but not commanded.
Firing range is previewed by holding "cancel" on a unit (B in OG, right-click in project) and will highlight all positions that unit can fire on until the button is released.
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.
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:
In our game, there is currently no clear way to see if a transport unit (APCs, Lander, T-Copter...) is carrying another unit.
Proposal:
logic/game/ui/unit_stats.tscn
scene.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).
Describe the bug
The first time that you start editing the godot project it fails because some error on the menu.tscn
To Reproduce
Steps to reproduce the behavior:
Expected behavior
It loads fine the first time
Additional context
I think we have some issues in the pipeline, that is related to that, with the new --import flag, we need to run it two times to fix the problems, otherwise, is complaining about some resources of the menu.tscn
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.
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.
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
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.
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:
Open questions:
Please add proposals as comments.
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
The current workflows being utilized contain a number of repetitive steps, which can make them difficult to read and maintain over time.
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.
I spoke with Ephraim225, who provided some good suggestions for the map editor that should be implemented:
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:
Codename-Recon/.github/workflows/client-releases.yaml
Lines 61 to 62 in 39309e1
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.
Depends on #52
Is your feature request related to a problem? Please describe.
At present, the game lacks following mechanic: 10% attack increase with Communication Tower (Com Tower).
Describe the solution you'd like
This feature allows players to capture Com Tower buildings, granting a 10% increase in attack damage to their units. However, upon losing control of the Com Tower, the attack boost is forfeited. Notably, this effect can stack, with each captured Com Tower providing an additional 10% attack boost. Com Towers do not repair or refuel units. To integrate none repair and none refuel mechanics into the game, additional boolean properties need to be incorporated into the types of terrains.
Describe alternatives you've considered
None.
Additional context
The communication towers are already in the game as regular buildings. However, they don't currently have the attack boost mechanic implemented.
Describe the bug
The tank's animation of getting hit is acting like the animation of "Idle's injured", and not of receiving damage.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
It's supposed to move aside and go back to it's original position (like taking impact on hit).
Desktop (please complete the following information):
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.
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:
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.
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:
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:
Which information should also be generated for in-game view needs to be discussed with the UI team.
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
Is your feature request related to a problem? Please describe.
Currently, when unloading units from a lander that holds two units, the game mechanics dictate that the first entered unit is automatically unloaded, with the second unit following suit on the subsequent round.
Upon unloading units from a lander, the game UI should display a selection mechanism where players can choose the unit they wish to deploy first. This selection should occur prior to specifying the landing tile for the chosen unit.
Describe the solution you'd like
Introduce a user interface (UI) feature that enables players to select which unit they want to unload from the lander before designating the landing tile.
Describe alternatives you've considered
None.
Additional context
None.
Is your feature request related to a problem? Please describe.
The current iteration of the game lacks a crucial strategic element - the fog of war mechanic.
Describe the solution you'd like
Corrected text: This mechanic should be implemented as an additional mode.
vision
parameter.Describe alternatives you've considered
None.
Additional context
Depends on:
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.
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).
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.
Let's test!
Describe the bug
The Tank's sprite don't have the highlight color it's supposed to have.
To Reproduce
Expected behavior
There was supposed to have 3 shades of the (team) color at the tank. As opposed to only 2 (which is the "default" for the infantry units)
Desktop (please complete the following information):
Depends on:
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.
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)
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.