Ha ha, it is true. The template is a bit involved. Explaining it is a substantial part of the book. Yet, you can focus on the parts you need.
…so that’s a great way to start. You’re not worried about Frames Per Second or Swipe Controls. You’re only focusing on collision detection.
So, once you look at the “jump” script, you can skip large chunks of code. Variables?! You don’t care. It’s a different project. The zoom function? Again, you don’t care, It’s a different project.
The Physics API… well… you might care.
This is known as the Photics-Physics-Bridge. While it looks super confusing, it’s actually meant to make it easier to use the API. But right now… you don’t have to care, as I wasn’t able to simplify (at least not yet) the collision code into the PPB.
Instead, focus on line 177. That’s for running code when a collision event starts.
Note — It also has a friend at line 237, that’s for running code when a collision ends. You probably don’t need that, so you can draw your focus on the block of code at 177-235
Basically, there are collision pairs — there are always two… no more… no less. So you have to identify those pairs. I do this with “custom data attributes”.
If “bodyA” is a sensor and “bodyB” has the “data-ground” attribute, then the condition is “True” it’s OK to jump.
Look at the comments… // A to B …and… // B to A …the pairs are scanned twice, so that a collision event is not missed.
Sure, there’s a lot more to it. That’s why I’m writing the book… 500 pages HA HA …but that’s basically the idea. Instead of changing the value of “window.ground” to true, load up Hower.js to play some sounds, or use Hype’s API to play a scene with a sound. (I recommend the former.)
Is that better?