Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Game initialisation from the application #34

Merged
merged 12 commits into from
Jun 13, 2024
Merged

Conversation

juliendiot42
Copy link
Collaborator

I am sorry this is a rather big PR but a lot of refactoring had been necessary to implement that. (And I took the opportunity to make the code cleaner).

This PR implement a way to initialise the game from the application so that user do not have to manually run the plantbreedgame_setup.Rmd file.

NOTE: for now user cannot specify the initialisation parameters, but this will be implemented soon.

@timflutre, I do not expect a complete review as it is quite big, and nothing seems to broke (thanks to the tests). However, I made one small change that I would like you to be aware of:
Before in the "theory menu" some boundaries of the inputs were specified using the game constants (mu.trait1, sigma.p2.trait1). Now since those values may not exist if the game is not initialised, I used fixed values instead (it was much easier to implement, and I use the same as what is in plantbreedgame_setup.Rmd).
That mean now the theory tab and the game's constant are disconnected.

Personally I think it is OK like that. I think that if this is just the "theory" there is no reason to have this linked to the actual game values. But if you would like it to be the case I can take some time to implement it, (or I can explicitly mention that the values are not related to the game).

Some fuctions was previously in `rutilstimflutre` package but it would be more
convinient to have there here in order to maintain them more
efficiently.
Befor this commit, the games "constants" was accessed through a global
variable (and used in both UI and server parts).

The problem with this design is that those values may not be updated if changed in
the data-base. (this is not currently possible but it is planned to be
implemented).

I have refactor so that those values are always read from the DB.

When those constants are used in "calculations" they are requested to
the DB with `getBreedingGameConstant()`

When those constants are shown in the UI, a "shiny module is used" to
ease the developement (cf. `./src/fun/constants_module.R`). All the
"servers outputs" for those values are defined in `src/server/server_constants.R`.
The setup script add only add (or overwrite) new files/data to this folder.
So if it already exists the resulting data may contain the previous content of
the folder, which do not correspond to a "fresh game session".
Now when a breeders are added/deleted, the breeders lists automatically
updates to show the correct list. No need to reload the page anymore.

The desing used to make that can serve a a base for similar behaviour in
the future.
This helps to modify the db requests behaviour accross the entire app.
- `db_get_request` is for SELECT request
- `db_execute_request` is for the orther requests
To avoid the error:
The `name` provided ('user-o') does not correspond to a known icon
For that some refactoring had to be done, mainly about the UI loading of
the menus that cannot be used if the game is not initialised.
With this feature, the admin can initialise (or re-initialise) the game
from the app directly.
@timflutre timflutre merged commit 235fa98 into master Jun 13, 2024
2 checks passed
@timflutre
Copy link
Owner

Ok for me. That's cool that the code keeps living so much, good job @juliendiot42 !

@juliendiot42 juliendiot42 deleted the game_initialisation branch June 25, 2024 04:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants