How Checking works in Genesis

[chaos]

For those who don't want to watch me ramble for over an hour on my stream (btw stream is here - https://www.twitch.tv/videos/2120586640)

Using the source code from 92 (Link - NHL Hockey Source Code), we are now able to find out how things work a lot easier than finding a needle in a haystack like we had done in the past. NHL94 has improved upon 92, but much of the code is the same (with some refinements and added things, like bonuses). The most important thing is we have an idea how the RAM is laid out (basically all the variables for the game).

 

How does checking work in 94?

Weight is involved. Where you are on the rink is involved (You're getting checked against the boards? You're getting knocked down). Checking rating is involved. Also, impact value is involved (how hard you are hitting depending on your velocity and your opponents velocity, and the distance between the 2 of you). Are you controlling the player checking, or is the AI?

Also, the weight bug (lets lighter players check heavier players, regardless of a lot of factors above) - 

 

 

Here's the checking formula for 94:

Check if checking player is in checking animation
If impact value is more than 20 decimal, the check will initiate. If not, there will only be momentum transferred between the 2.

Starting value for calculation (120 decimal or 240 decimal if player controlled)

- Subtract (Wgt * 8) of player checking
- Add (Wgt * 8) of player being checked
- Divide total by 2
- Check if player will hit the wall (see below)
- Subtract impact value

- If the total is 0 or negative, proceed to knock down.
- If total is positive, then check if player will hit wall. If he will, proceed to knock down.

- If total was positive, and player is not near a wall, then randomize the result from above (the RNG will choose a number >= 0 and < result from above)

- Load the checking attribute (which is Chk rating * 5 + bonuses (Hot/Cold and 3rd Period Bonus). Divide it by 2 (Value will be between 0 and 15)
- Next, subtract Checking value from above from the RNG result. If the answer is <= 0, then proceed to knock down. If positive, then check Agression attribute and see if there will be a penalty from the hit.

Knock down section also checks for penalty from contact, but there is slightly less of a chance of a penalty compared to them not getting knocked down. After this part of the code, it will check for toddle (related to stickhandling).

 

This checking formula is almost the same as it is in 92, except for the fact that some math is different (there's no bonuses, attributes are on a 0-15 scale instead of 0-6), the starting value for ALL checks is 60 decimal. In 94, the attributes are stored in RAM with a 0-30 scale (which is why you see a divide by 2 in a few places here).

What's the weight bug problem?  Lighter player can check heavier players with ease, when player controlled. This is because of the large boost given to the starting value. The subtracting and adding of the weight in this formula is done "byte" size, which means that value can never be over 255, it will overflow and 256 = 0 (it will start over at 0). Because of this, the rest of the calculation is pretty much thrown out the window (impact value will play a very small role in a weight bug check).

 

So how to fix the weight bug? Remove the boost to the starting value when player controlled. 

I believe this may have been left in during testing, since the formula itself is almost the save as in 92. If the starting value was set to 120 decimal for both AI and player controlled checks, we would see much more "realistic" results. Weight difference won't be a huge factor anymore (still a bit of a factor), but impact and checking attribute would play more of a role. 

 

What's impact value?

This is something I was able to figure out using the source code. The game tracks the velocity of the players (speed + direction). When it senses 2 players are close enough for contact, it will calculate a transfer of momentum between the players (when players hit, they slow down, bump each other back, etc). So it will calculate impact based on the velocity of both players, and the distance between them. The players speed is controlled by their acceleration, which in turn is controlled by Wgt and Agl attributes. So the faster a player is going, the more impact they will cause. If 2 skaters are skating at each other, the impact will be higher. If a player getting checked is skating away from the checker, the impact will be lower. If you hit the player near the end of your speed burst, the impact may be lower (not going as fast as you originally were). 

Funny thing is even with the weight bug, its actually harder for Theo Fleury (3 wgt) to check Marty McSorley (14 wgt), than it would be for him to check someone like Mats Sundin (7 wgt). He needs some impact to check Marty, where as with Mats, as long as he meets the minimum impact value to initiate the checking calculation, hes knocking him down.

Here are some examples with weight and impact:

4 wgt checking (player controlled) a 10 wgt with minimal impact just makes it to the knock down phase (-4). 4 wgt AI player can do it with a ton of impact though (and some RNG luck).

 

Closer weights here. 5 wgt AI checking a 7 wgt player with 50 impact value can definitely have a shot with some RNG luck (RNG result would be between 0 and 18 here), then subtracting the Checking attribute (0-15 scale after divide by 2). 

 

Marty McSorley might be able to survive this check from Theo Fleury with the right RNG and minimal impact.

 

AI controlled Mario Lemieux might struggle knocking down Mike Gartner with low impact. Gotta get a good RNG roll (low value here).

[segathon]

WOW!  Well done

[AdamCatalyst]

How does altering the RNG variance affect this?

 

[chaos]

7 hours ago, AdamCatalyst said:

How does altering the RNG variance affect this?

 

The RNG function needs a value sent to it and returns a result. In the Hot/Cold thread, you are only changing the value being sent to the RNG function for Hot/Cold.

The RNG function has 2 different ways it can be used:

- Sending it a value, and it will give a result of (- value <= result < value)

- Sending it a value and it will give a result of ( 0 <= result < value)

 

Hot/Cold uses the first way, Checking is using it the second way. The RNG function is used all over the place. 

[AdamCatalyst]

Thanks for explaining!

[AdamCatalyst]

Could it be a potential alternative weight-bug fix to change the starting bonus value for a user controlled player from 240 to 120? And if so, do you have a sense of where that 240 might be in the assembled code?

[chaos]

4 hours ago, AdamCatalyst said:

Could it be a potential alternative weight-bug fix to change the starting bonus value for a user controlled player from 240 to 120? And if so, do you have a sense of where that 240 might be in the assembled code?

Yes, it would make (in my opinion) checking the way the game was intended. 

You can change 0x13D70 and 71 from E3 40 to 4E 71 (No Operation). This would overwrite the step where it makes it 240

[AdamCatalyst]

16 hours ago, chaos said:

Yes, it would make (in my opinion) checking the way the game was intended. 

You can change 0x13D70 and 71 from E3 40 to 4E 71 (No Operation). This would overwrite the step where it makes it 240

Thanks for this! Going to start play testing this mod. I certainly agree with your inference, that this may have been what was intended, and at the very least, seems to revert the logic to be similar enough to '92.

[AdamCatalyst]

On 5/7/2024 at 1:15 PM, AdamCatalyst said:

Thanks for this! Going to start play testing this mod. I certainly agree with your inference, that this may have been what was intended, and at the very least, seems to revert the logic to be similar enough to '92.

@chaos This may be a daft question, but lately I've been play testing the above fix, and I'm struggling to tell if it is working as intended. Any quick thoughts on an experiment to prove it's behaving as we'd hope?

[chaos]

2 hours ago, AdamCatalyst said:

@chaos This may be a daft question, but lately I've been play testing the above fix, and I'm struggling to tell if it is working as intended. Any quick thoughts on an experiment to prove it's behaving as we'd hope?

Should be much harder for lighter guys to check heavier guys. Heavier guys should be able to check lighter guys

[AdamCatalyst]

I don't know where my brain is at. Just change the ratings on some players, all min or max weight. Should be pretty clear. Thanks man. And Happy New Years to you!

[AdamCatalyst]

An Experiment

Hey man, so I've been playing with the aforementioned fix, and ran a few tests this morning. I thought you might be interested in the results.
 

---

Methods

Six different demos were run with the Control Group, three different demos Run with the Checking group, three different demos run wth the Weight group.

Control Group

• using my v3.0 Beta.
• demo mode.
• using default teams of EDM & FLA (YES, I know the was a mistake, should have been same team vs same team)
• 5 minutes
• Penalties ON
• Line changes OFF

Checking Group

• Set EDM to 0 Checking for every player
• Set FLA to 15 checking for each player.
• No other changes from Control Group.

Weight Group

• Set EDM to 0 Weight for every player
• FLA to 15 Weight for each player.
• No other changes from Control Group.
    

---

Results

Control Group

44 EDM Body Checks

49 FLA Body Checks
 

Checking Group

04 EDM Body Checks

58 FLA Body Checks
 

Weight Group

09 EDM Body Checks

31 FLA Body Checks

 

---

Conclusion 

Chaos's inferences seem spot-on. With the restored code, the Control Group had an asymmetry in Body Checks Thrown of approximately 1 to 1.11. Weight attribute asymmetry had a substantial effect, changing this ration to 1 to 3.44 (~300% increase). Checking attribute asymmetry had a massive effect on Body Checks asymmetry, changing the ratio to 1 to 14.50 (~1300% increase). While the experiment had a less than ideal sample size, and more variables could have been controlled, the effect size is substantial enough to confirm that this fix works as described by Chaos. However, because the sample size was so small, do not infer anything else from these numbers, regarding total checks per game, etc.

 

---

Appendix

Control Group screen-caps.

 

Checking Group (top row) / Weight Group (bottom row).

[smozoma]

On 5/6/2024 at 8:37 PM, chaos said:

Yes, it would make (in my opinion) checking the way the game was intended. 

You can change 0x13D70 and 71 from E3 40 to 4E 71 (No Operation). This would overwrite the step where it makes it 240

Agreed, my original fix was wrong. This new fix also fixes(eliminates) the CB check, right?

[AdamCatalyst]

33 minutes ago, smozoma said:

Agreed, my original fix was wrong. This new fix also fixes(eliminates) the CB check, right?

Your improved weight bug fix wasn't wrong, it was the best solution we had for nearly two decades, improving the quality of countless games played.
 

Just because I am trying to understand code better, some hypothetical questions. Here is the original code.

082B 0003 0062 6700 0004 E340

The C B bug fix removed the branch after the Test.

082B 0003 0062 4E71 4E71 E340

 

The new weight bug fix removes the Bit Shift that doubles the value from 120 to 240.

082B 0003 0062 6700 0004 4E71

 

If I understand correctly, couldn't all this code be changed to No-Op?

Edited January 6 by AdamCatalyst

[chaos]

2 hours ago, AdamCatalyst said:

Your improved weight bug fix wasn't wrong, it was the best solution we had for nearly two decades, improving the quality of countless games played.
 

Just because I am trying to understand code better, some hypothetical questions. Here is the original code.

082B 0003 0062 6700 0004 E340

The C B bug fix removed the branch after the Test.

082B 0003 0062 4E71 4E71 E340

 

The new weight bug fix removes the Bit Shift that doubles the value from 120 to 240.

082B 0003 0062 6700 0004 4E71

 

If I understand correctly, couldn't all this code be changed to No-Op?

What the CB check fix does is just make all checks starting with the 240 base value.

The fix above removing the bit shift makes all checks use the 120 value.

You can 4E71 all of that if you want, and get the same effect as removing the bit shift

 

[chaos]

3 hours ago, smozoma said:

Agreed, my original fix was wrong. This new fix also fixes(eliminates) the CB check, right?

It would just make everything like a CB check, since CPU and player would use the 120 decimal as a base instead of the 240 for the player.

Also, lighter wgt players can still have a chance of knocking down heavier players if checking at speed. This would increase the impact of the check, and also use the Chk rating and RNG.

[AdamCatalyst]

Thanks for clarifying!

[von Ozbourne]

All this cool talk about new found knowledge and... Is it just me wondering if I can exploit this to make the CPU controlled players even more likely to throw the body?

[AdamCatalyst]

Almost certainly, yes. Feed Claude.ai the code, and I suspect it will be able to isolate a key variable or equation that you can manipulate.