Quick question for a developer

[Imzogelmo]

I'm just curious about the Rope enemies. When they align with Link's position, they charge at him with an increased step speed. I can think of 3 ways that it may be done in code, and I'm wondering which way is the correct one:

1. The speed is an addition to the standard step speed; i.e. Step + X.
2. The speed is a multiple of the standard step speed; i.e. Step * X,
3. The speed is a constant value used regardless of Step speed; i.e. just set it to X.

Which one is correct?

[Gleeok]

Without looking at any code (Hey, I'm lazy!) I'd use one of your first two methods. Though a simple addition might not scale very well for faster types. Whatever it is it should be fairly simple with at most one extra step to figure it out ..I don't know, maybe something like this:

override float GetStepSpeed() {
  float s = this.stepSpeed;
  if(this.isCharging) {
    s = this.CalculateTheChargeSpeed(s, this.charge_SomeFloatMember); // return (s * charge); ? 
  }
  return s;
}

That said, ZC enemies used the *super awesome best thing ever "fixed" class™ (courtesy of allegro)* and are confusing to say the least, so you'll have to wait for _L_ to come along and set me straight when he sees this.

[Imzogelmo]

Well, my question is which of the 3 methods is actually used by the fixed class...

However, I agree, if I were coding something like this myself, I'd probably use the second method, as it seems most intuitive and is scalable. Also, if I were coding it myself, I'd make it an adjustable value passed in with a parameter. Still, it would be necessary to explain to the end user whether this parameter were a multiplier or an addition to the base speed, or if it was just an alternative value used in place of the speed when the creature was charging.

[_L_]

To provide an actual response: the Rope walk style currently causes the enemy to dash at Link with a speed of Step + 100.

Whether or not this ought to change to something like Step * 3 is an interesting question. I guess one of the reasons why I went with the former is because you could give an enemy a Step of 0 and then it would nonetheless charge at Link when Link crossed their line of sight. And also, that slower enemies (with a step of 25 or something) would charge Link with a slightly peppy 125 Step instead of a not-quite-so-considerable 75. Admittedly, it means that enemies with a Step of 125 only dash at 225 instead of 375, but to be honest I find Step speeds above 150 to be kind of unpleasant to deal with as Link and more revealing of the artificial limitations of the NES movement styles, so the current system means that really fast enemies' dashes are kept a bit closer to the bounds of reason.

EDIT: Hmm, but I'm reminded of the fact that Armos uses the Walk Attr. value to determine its alternative speed. I guess that could be utilised by the Rope too?

[Nicholas Steel]

Using addition rather then multiplication makes more sense, vastly superior control especially if you can customize how much speed is boosted by.

[Imzogelmo]

That does make sense; I had not considered the case of a 0 Step, which certainly makes option 1 more attractive. However, given that the value could be a negative, it would be possible to create a situation where the enemy would appear frozen in place instead of charging by using the negative of Step as the alternate value.
I suppose that could be done by any of the options with appropriate math, so not a concern so much as an interesting possibility.

[Gleeok]

Actually, now that I think about it a little bit, it makes much more sense to not have a predetermined formula at all. You can never really get the correct ratio of walk to charge speed using any of those methods except in the initial case (rope1 and rope2 enemies). What they should be is two separate vales: step_speed and charge_speed. So...

EDIT: Hmm, but I'm reminded of the fact that Armos uses the Walk Attr. value to determine its alternative speed. I guess that could be utilised by the Rope too?

Yeah.

[Imzogelmo]

Good idea, Gleeok. There's a Walk Attribute, might as well use it. Besides, the parallel with Armos is farily clear.