Open mattkerlogue opened 2 years ago
Given how many times the file name is being defined in the code I suggest splitting the file name generation code into its own separate function e.g.:
.get_tamRgo_file <- function() {
file.path(tools::R_user_dir("tamRgo", which = "data"), "tamRgo_genome.rds")
}
You could also add in a validation check:
.get_tamRgo_file <- function() {
my_tamRgo <- file.path(tools::R_user_dir("tamRgo", which = "data"), "tamRgo_genome.rds")
if (!file.exists(my_tamRgo)) {
stop("No TamRgo found on this computer")
} else {
return(my_tamRgo)
}
}
Appreciate that tools::R_user_dir("tamRgo", which = "data")
puts the file in a folder specific to the package, but in the case of exchange it might be better than folk just sharing things called blueprint.rds
. Specifically thinking in the event sharing isn't solely in the form of plain text (i.e. directly sharing the base RDS file), though in which case I suspect you'd write an export file function to give it a particular name (e.g. tamRgo_KEVIN_20221008.rds
.
@mattkerlogue: Aye, agree on simplifying current blueprint gathering function. Definitely some refactoring to apply here. I was thinking about this in terms of checks previously (see #12), but I think there's definitely scope for extending utils.R to cover a lot more of the generalised tasks, like fetching blueprints, etc.
And yes, you're right, initially I was thinking in terms of 'oh, this file is being saved within the {tamRgo} files, so i don't need to think too hard about what the actual file is called', but I think some more specificity cannot hurt.
Part of me wants to force some old-school limitations. For example, pet name, which I think I set artificially to 8 characters only. Another forced limitation would be to have only one pet at a time, so the blueprint filename wouldn't matter that much; any new pet overwrites the old one. I think this is a nice psychological thing; this is your pet, would you be so heartless as to replace them? But maybe it would be fun to have like 'save slots' so you can have 'up to three' pets or whatever.
(Of course, none of this matters, because it's a proof of concept that no-one will ever play, lol. Although my sweet KEVIN has reached 19 days old and I love him and cannot let him reach a state of unalive.)
Another forced limitation would be to have only one pet at a time … this is your pet, would you be so heartless as to replace them? … 'up to three' pets
This also presumes your concept of battle is limited to one-on-one battles.
Hold your ~horses~ cats; {tamRgo} pets can't even become unalive yet! 🙃
bp$alive <- FALSE
Or:
bp$dead$is_dead <- TRUE
bp$dead$cause <- sample(
c(
"hunger", # unfed for X days
"despair", # 0 happiness for X days
"dysentery", # unclean for X days
"killed"), # died in battle
1)
Listen, the {tamRgo} repo is a serious place with well-structured discussion; you just going to ignore #23?
Also I like the idea of:
bitflip <- FALSE
if (solarflare) bitflip <- sample(c(TRUE, FALSE), 1)
if (bitflip) bp$is_alive <- FALSE
you just going to ignore #23
Hah. My apologies for not having undertaken a comprehensive survey of all extant issues.
Suggest making
blueprint.rds
file name more explicitly linked to the package. It's unlikely you're going to run into conflicts butblueprint.rds
is a fairly generic name. SuggesttamRgo_blueprint.rds
, or perhaps something more connected to the game concept such astamRgo_genome.rds
ortamRgo_egg.rds
.https://github.com/matt-dray/tamRgo/blob/2c246bfc017428c2075ffdfa756db4d45e76c090/R/blueprints.R#L133
https://github.com/matt-dray/tamRgo/blob/2c246bfc017428c2075ffdfa756db4d45e76c090/R/blueprints.R#L204
https://github.com/matt-dray/tamRgo/blob/2c246bfc017428c2075ffdfa756db4d45e76c090/R/utils.R#L18
https://github.com/matt-dray/tamRgo/blob/fc0d639868503c5d04b82afeec772722856308b3/R/zzz.R#L4
https://github.com/matt-dray/tamRgo/blob/2c246bfc017428c2075ffdfa756db4d45e76c090/R/interact.R#L173
https://github.com/matt-dray/tamRgo/blob/5c7601cbdb3614bdd99780bde6ae98e242e75f9e/R/update.R#L39