althack-project / althack Goto Github PK

Right now, a rather old Sphinx version is used to build the Read the Docs documentation (version 1.8.5). This requires several upstream dependencies to be defined as specific (old) versions. This should be fixed to use the most up to date Sphinx version.

At the same time, a static .readthedocs.yaml should be created to make sure we don't suffer from upstream version changes in the RTD builders.

To measure code coverage (once unit tests are available), code coverage tooling needs to be set up.

Accounts need to be implemented on the backend and frontend.

The current canvas position is adjusted based on UI interaction inside MainWindow::canvas(). The other side of the interaction (i.e., passing in what position to use for drawing) should also be inside canvas() to keep the same logic in one place.

https://github.com/fairlight1337/althack/blob/59f5504d678770344c4d78b6b8e01c290ce9eb22/src/althack/main_window.cpp#L164

Is your feature request related to a problem? Please describe.
A programmatic frontend layer is required to coordinate communication with the backend, and to hold the state of the game.

Describe the solution you'd like
Ad a frontend layer that connects to the known backend layer and serves as an I/O interface to the UI.

To follow top of the line coding standards, clang-tidy needs to be integrated into the CMake build process.
Implausible (for the project) settings need to be deactivated, but the majority of checks should be enabled and passing.

Nodes on the canvas represent accounts, entities, or other game mechanics on the same level. They can be connected to each other and allow interaction between one another.

An abstract base node type as well as a concrete Fund Account node type need to be implemented on the backend and the frontend.
The Fund Account type needs to have a Provider field (denoting who the fund managing entity is, such as a bank, an online service, a blockchain provider, or similar), an account identifier field, and an amount field alongside the currency it represents.

The AccountNode class keeps causing compiler warnings because some of its constructor initialized variables aren't order of definition. The order of these initializations (or of the variables) needs to be adjusted accordingly.

The libconfig++ configuration library is already integrated into the main AltHack application. To make it useful, concrete config settings need to be included.

For now, this should include the database filename of the server backend database. With this, the required generic interfaces for more settings should be established.

To give users and developers a glimpse of what is planned beyond TD1, the development roadmap needs to be detailed out.
This should cover:

• Scope of TD1
• Potential scope of TD2
• Potential scope of the first alpha release
• Features planned further out that do not yet have a release they are attached to

This should be documented in the main README.md file.

The UI should feature an easily accessible switch to change the general theme sentiment from light to dark, and vice versa. The current state should be reflected by the same control widget.

All classes are documented as part of TD1. This needs to be done on a class member level, and should be available via Doxygen documentation tags. Parameters, return values, and descriptions are documented.

The CONTRIBUTING file should contain guidelines on general mode of collaboration within the project, answers to licensing questions, code style, and how to deal with issues at large.

It should outline for any contributor what their contribution is being used for, how it will be licensed, and what level of involvement is expected from them.

Is your feature request related to a problem? Please describe.
Currently, the project cannot be cross-compiled for Windows. It should be compilable on Linux and Windows alike, with the same resulting game application (functionally, not on binary level).

Describe the solution you'd like
Extend the CMake configuration and the documentation to allow cross-compilation for Windows if so desired, and retain the original Linux build capabiities.

Describe the bug
The current clang-tidy configuration should be improved as it

• still produces warnings that should be fixed
• should be configured through a dedicated configuration file rather than hosting its config in a CMake variable

Both issues are more of a clean-up measure, but should improve both, compilation output readability (and conciseness) and clarity of the current configuration. Many issues stem from system headers, too - this should possibly fixed by ignoring them entirely.

To Reproduce
Just compile in a clean environment - many issues will be shown.

Expected behavior
No remaining clang-tidy issues (if possible) when doing a clean compile.

Any relevant game nodes need to be displayed on the game canvas.
Nodes need to be draggable, should reflect their relevant internal state visually, and need to be placeable and removable via UI interaction.

Read the Docs is configured, and the relevant base documentation is present in the AltHack repo. What exactly is documented there for TD1 is to be determined, but should at least entail:

• Build instructions
• Command line options for the main application
• Expected behavior of TD1
• Architecture of the application
• A base demonstration of what TD1 is capable of

The play area canvas allows to connect nodes to one another. This should happen via ports on nodes. The ports need to be typed, meaning not all node ports can be connected to all other ports, but only to matching ones.

Two distinctions for possible connections need to be made:

• Port type
• In/Out port (out only connects to in, m:n mappings)

The connections themselves need to be typed as well to denote what the available/intended characteristics are for each connection.

Any two or more accounts should be switchable. An active account needs to reinitialize the game state when switched to.

The server backend requires a database to store data persistently. This includes, but is not limited to:

• Player accounts
• Dynamic settings data
• Game state

The database should be file-based for local storage and easy backup, and should be universal enough to accommodate yet to be defined data layouts.

Backends need to be properly integrated into an asynchronous scheduling cycle to not block or be blocked by the UI thread.