blueprint filename

[mattkerlogue]

Suggest making blueprint.rds file name more explicitly linked to the package. It's unlikely you're going to run into conflicts but blueprint.rds is a fairly generic name. Suggest tamRgo_blueprint.rds, or perhaps something more connected to the game concept such as tamRgo_genome.rds or tamRgo_egg.rds.

tamRgo/R/blueprints.R

Line 133 in 2c246bf

data_file <- file.path(data_dir, "blueprint.rds")

tamRgo/R/blueprints.R

Line 204 in 2c246bf

data_file <- file.path(data_dir, "blueprint.rds")

tamRgo/R/utils.R

Line 18 in 2c246bf

data_file <- file.path(data_dir, "blueprint.rds")

tamRgo/R/zzz.R

Line 4 in fc0d639

data_file <- file.path(data_dir, "blueprint.rds")

tamRgo/R/interact.R

Line 173 in 2c246bf

file.path(tools::R_user_dir("tamRgo", which = "data"), "blueprint.rds")

tamRgo/R/update.R

Line 39 in 5c7601c

data_file <- file.path(data_dir, "blueprint.rds")

[mattkerlogue]

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)
  }
}

[mattkerlogue]

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.

[matt-dray]

@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.)

[mattkerlogue]

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.

[matt-dray]

Hold your horses cats; {tamRgo} pets can't even become unalive yet! 🙃

[mattkerlogue]

bp$alive <- FALSE

[mattkerlogue]

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)

[matt-dray]

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

[mattkerlogue]

you just going to ignore #23

Hah. My apologies for not having undertaken a comprehensive survey of all extant issues.