The crux of the issue is that we use OnTriggerExit2D and OnTriggerEnter2D to detect when a hold is grabbed. This made collision detection easy for us but makes it hard to nicely abstract for an SDK. The problem is that if the developer extends the ClimbingHold class and overrides the OnTrigger functions, the code we used for smoothing/correct collision detection might get overridden.
To counteract this, I placed the logic of the smoothing/collision detection in functions ShouldRegisterHoldGrabbed and ShouldRegisterHoldReleased. The base class (ClimbingHold) calls these functions in the OnTrigger functions. This means, for example, if a developer chooses to only override OnTriggerEnter2D, smoothing will still work because the correct code is still being called in OnTriggerExit2D. The downside is the developer must call the ShouldRegisterHold functions in the OnTrigger functions if they choose to override the functions.
In an ideal world, a developer would simply have to implement a function such as HoldGrabbed and this would get called automatically on collision. Something like this could be done with an abstract class that forces the developer to implement these functions. The downside is that the developer would be forced to implement HoldGrabbed and HoldReleased even if they didn't want too. Assuming internally we called these functions from the OnTrigger functions, this approach would also still face the issue of the developer overriding the OnTrigger functions which I believe is something we want to allow.
I think truly mimicking the behavior of the OnTrigger functions would require building up some more serious abstractions (such as we register 'holds' with some central authority that can dispatch the HoldGrabbed call to the correct hold) and probably isn't worth it for this project.
patxu
commented
7 years ago
This is an attempt at climbing hold abstraction.
The crux of the issue is that we use
OnTriggerExit2DandOnTriggerEnter2Dto detect when a hold is grabbed. This made collision detection easy for us but makes it hard to nicely abstract for an SDK. The problem is that if the developer extends theClimbingHoldclass and overrides theOnTriggerfunctions, the code we used for smoothing/correct collision detection might get overridden.To counteract this, I placed the logic of the smoothing/collision detection in functions
ShouldRegisterHoldGrabbedandShouldRegisterHoldReleased. The base class (ClimbingHold) calls these functions in theOnTriggerfunctions. This means, for example, if a developer chooses to only overrideOnTriggerEnter2D, smoothing will still work because the correct code is still being called inOnTriggerExit2D. The downside is the developer must call theShouldRegisterHoldfunctions in theOnTriggerfunctions if they choose to override the functions.In an ideal world, a developer would simply have to implement a function such as
HoldGrabbedand this would get called automatically on collision. Something like this could be done with an abstract class that forces the developer to implement these functions. The downside is that the developer would be forced to implementHoldGrabbedandHoldReleasedeven if they didn't want too. Assuming internally we called these functions from theOnTriggerfunctions, this approach would also still face the issue of the developer overriding theOnTriggerfunctions which I believe is something we want to allow.I think truly mimicking the behavior of the
OnTriggerfunctions would require building up some more serious abstractions (such as we register 'holds' with some central authority that can dispatch theHoldGrabbedcall to the correct hold) and probably isn't worth it for this project.-David