What I'm wondering about...

AlwaysInAGoodShape

I'm of the opinion that the Devs did a lot of great things in the last patch; From the perk-rework incentive to addressing the perk visibility in the endgame lobby.

As someone who is concerned on what the Devs spend their time on, I'm wondering the following;

When it comes to making perks more viable, many times the structure of the perk or else isn't the problem (where as in the Legion's case it is). In these cases all that needed to happen was to change certain variables.
If the Devs wanted to add the BP bonus, the structure for that code is already in the game and would've been easily applied.

Why choose to completely redo something and spending multiple hours on rewriting the code and debugging, instead of just changing the numbers, costing you about 20 seconds of time?

tt_ivi_99

Code lines are really complex.

I remember when I was in high school I had a teacher who told me that a single "." or "-" could change the code line completely.

Maybe the code line for the BP bonus is just two words and the code line to actually activate that BP bonus is way more complex. Ex:

"BP bonus activates" = Code line 1.
"BP bonus can be activated when x amount of survivors are working on the same gen." = Code line 2.

That second code line is completely different from any code line of a different perk (like Distressing) therefore they have to write it from the start.

Keep in mind that any wrong letter in a code line can result in big problems.

AlwaysInAGoodShape

@tt_ivi_99

Yes, we're talking about the bonus BP here. The bugs came from the initial part.

They probably have some sort of increasing BP method
IncreaseBP()
They are probably able to refer to which category needs increasing with a single reference and set up the conditions for that to happen (which is equipping the perk.
The only thing that needs changing about the distressing code is changing the condition to equipping Prove Thyself while performing a coop, change the numbers, change the categories.
It can be that their code is not as well-structured, but those 3 variables should be the main 3 things.

---

Now the main thought comes of course from the core part of prove-thyself. This should in any possible case be as easy as changing a few numbers in the script, unless I'm missing something.

weirdkid5

God I'm already dealing with programming enough in college, can we not do it here too lmao

SadonicShadow

@weirdkid5 said:
God I'm already dealing with programming enough in college, can we not do it here too lmao

My hats are off to anyone that tries to learn programming. It looks like an exercise in frustration. I want to get into Network Administration Program at my local college and they require Introduction to Object Oriented Programming which i was told was Java. Sure as ######### not looking forward to it.

tt_ivi_99

AlwaysInAGoodShape said:

@tt_ivi_99

Yes, we're talking about the bonus BP here. The bugs came from the initial part.

They probably have some sort of increasing BP method
IncreaseBP()
They are probably able to refer to which category needs increasing with a single reference and set up the conditions for that to happen (which is equipping the perk.
The only thing that needs changing about the distressing code is changing the condition to equipping Prove Thyself while performing a coop, change the numbers, change the categories.
It can be that their code is not as well-structured, but those 3 variables should be the main 3 things.

---

Now the main thought comes of course from the core part of prove-thyself. This should in any possible case be as easy as changing a few numbers in the script, unless I'm missing something.

It doesnt necessarily have to come from the first part, It could be a problem from the second code line as well.

If the entire code line was scripted as:

Code line 1: "Each time someone equips Prove Thyself, additional BP are provided"

Code line 2 (if code line 1 is applied): "At least 2 or more survivors must be working on the same gen to activate a 100% of additional BP.

Maybe the percentage of BP is in the second code line.

I dont remember very well how It works with more that 2 options but I do remember that one code line is for activation and the other is the actual rule of when it should be activated or not.

Or maybe it's a completely different problem that relies on the game not being able to properly read those code lines because there are other code lines that negate them or even change the way they work in some kind of way (preference most likely).

PigNRun

SadonicShadow said:

@weirdkid5 said:
God I'm already dealing with programming enough in college, can we not do it here too lmao

My hats are off to anyone that tries to learn programming. It looks like an exercise in frustration. I want to get into Network Administration Program at my local college and they require Introduction to Object Oriented Programming which i was told was Java. Sure as ######### not looking forward to it.

As someone with a few years of experience with Java, I can say its not too bad. Big assignments are usually the one frustrating part of it.

AlwaysInAGoodShape

@tt_ivi_09

Let's say that every perk is basically a boolean and a method

Pseudo code:

bool proveThyself = false //by default and becomes true open that player equipping their perk.
void ProveThyself() //

If proveThyself == true

ProveThyself(){
GenEfficiencyMechanicPerPlayer(false) //Enables slower generator repair speed when true.

switch
case: tier 1 
coopScoreMultiplier += 0.5 //break etc
case: tier 2
coopScoreMultiplier += 0.75
default
coopScoreMultiplier += 1}

This function is called at the Start() of the match

As you can see, the generator speed and BP are as separable as can(/should) be.

thesuicidefox

My guess is that it would just be a copy/paste of Leader. That's why they changed both, so they both have a unique purpose in the game. Like why have 2 perks that are basically the same thing?

Tweaking numbers doesn't always solve problems the way you think it would. Sometimes a redesign is a better option.

AlwaysInAGoodShape

@thesuicidefox said:
My guess is that it would just be a copy/paste of Leader. That's why they changed both, so they both have a unique purpose in the game. Like why have 2 perks that are basically the same thing?

Tweaking numbers doesn't always solve problems the way you think it would. Sometimes a redesign is a better option.

The only change is that you don't buff your teammates now when they aren't sitting on the gen, but this is barely a factor most of the times. (normally this is the 2 seconds you run towards the gen, which have now been negated.

People double running the perk could've been negated with probably 1 if statement if they really wanted only 1 person running the perk.

thesuicidefox

@AlwaysInAGoodShape said:
People double running the perk could've been negated with probably 1 if statement if they really wanted only 1 person running the perk.

"1 if statement" You don't know much about programming do you? Or game design for that matter.

PT isn't that great by itself but if multiple survivors use it then it's quite strong. Again it's to cut down on redundancy. They wanted PT and Leader to be distinct perks. IMO they failed with Leader, but PT is actually worth using now. You can throw numbers around all you want, but doing math on paper =/= practical use in game. It might be a minor speed increase but it adds up, again especially if more than 1 of you have it.

AlwaysInAGoodShape

@thesuicidefox

There isn't much redesign here. They mainly added BP and rewrote their code where it wasn't necessary.

You don't know much about programming do you? Or game design for that matter.

Surely more than you do.

Leader adds nothing to the conversation here. PT was barely changed. Number buffs mainly while managing to break the code.

thesuicidefox

@AlwaysInAGoodShape said:
"You don't know much about programming do you? Or game design for that matter."
Surely more than you do.

...

@AlwaysInAGoodShape said:
People double running the perk could've been negated with probably 1 if statement if they really wanted only 1 person running the perk.

This statement here tells me otherwise. It's never that simple.

AlwaysInAGoodShape

@thesuicidefox

This statement here tells me otherwise. It's never that simple.

It's close to being that simple. Of course such a statement is going to have something within the blocks.

thesuicidefox

@AlwaysInAGoodShape said:
@thesuicidefox

This statement here tells me otherwise. It's never that simple.

It's close to being that simple. Of course such a statement is going to have something within the blocks.

If you say so...

Fact is changing numbers doesn't address the redundancy of the perks. Redundancy in game design is generally a bad thing. You want every piece of your game to be unique and different from every other piece.

Again, math and numbers are not the only things that matter.