Feature: Add badge boost flag in data.json#3
Conversation
emilyploszaj
left a comment
emilyploszaj
left a comment
There was a problem hiding this comment.
Couple nits, going in the right direction. Currently we're hardcoded for gen 2 badge boost but I think that's probably fine to start with? No need to overdevelop features when more pressing things could be focused on.
| ]); | ||
|
|
||
| //ADD GENERAL FLAGS OBJECT TO GLOBAL VARIABLES | ||
| const game_general_flags = { |
There was a problem hiding this comment.
Might be better to go with a shorter name? I imagine flags will be used all over the codebase so something like flags would probably same some time.
There was a problem hiding this comment.
Got it, I tend to use longer names to avoid comments but, in this case, I used both of them. I'll try to use shorter names from now on.
|
|
||
| //ADD GENERAL FLAGS TO DATA PARSE | ||
| const feature_flags = j.feature_flags; | ||
| game_general_flags.badge_boost = feature_flags.badge_boost; |
There was a problem hiding this comment.
This is good for now but in the future we might want to go with a more general case parsing solution, what do you think?
There was a problem hiding this comment.
I think the parsing is fine, every data.json file will have a series of specific parameters that define how the calc should behave. Documentation of the parsing part should be the first one imo.
| "bonemerang", "double-hit", "double-kick", "twineedle" | ||
| ]); | ||
|
|
||
| //ADD GENERAL FLAGS OBJECT TO GLOBAL VARIABLES |
There was a problem hiding this comment.
nit: space before comment text
| } | ||
| if (defenderBoost && special && badges >= specialBadges) { | ||
| d = parseInt(d * 1.125); | ||
|
|
There was a problem hiding this comment.
nit: no double blank lines in method bodies
| @@ -1,4 +1,8 @@ | |||
| { | |||
|
|
|||
|
I agree with the comments. But now that I think about it, badge_boost flag should not be a boolean type. It should be three types:
WDYT? |
|
Also, I think the roadmap of the general calc should be first define the flags and apply them to the code, and then implement the other cases that are not right now in the CK+ calc. |
|
We could have a more general badge boost solution to accommodate rom hacks. For instance: "badge_boost": [
{
"badges": 2,
"type": "dark",
"multiplier": 1.5
},
{
"badges": 6,
"stat": "spa",
"multiplier": 0.5
}
]Doesn't even necessarily have to be a flag, could just be a field where empty is equivalent to "no boosts". I think your roadmap makes sense. |
2 participants
Add badge boost flag to data.json
Implement conditions in the calc weather or not should be considered
Add feature_flags object to data.json for future compatibility