Pausing the debugger at random times isn't guaranteed to catch the code you're targeting in the process of performing an operation. You'll want to specifically set breakpoints on line numbers in code in order to catch that code in action and observe the state of the variables. If you're unsure about what code to observe, then you can use the "Stack Trace" tab by selecting the server submission in the "Network" tab to walk backwards through the functions that were called prior to submitting. In the case of the Wheel of Monotony, the call stack should end in jQuery, but a few steps back should land you in wheelgame.js. That's where you need to be inserting breakpoints if you'd like to observe the wheel's inner workings. You can also use the inspector in your developer tools to find elements in the page that interact with the wheel, like the "Spin the Wheel" button, then check which events are tied to that element. The same is true with any code that you're unfamiliar with: try to find the action that sets the code in motion, then work from that.
You can't navigate to the url on its own to execute the wheel actions. You need to recreate the POST process that I mentioned previously in
(you need an account to see links).
You can replicate the playGame class in a number of different ways. For example, you can intercept the load request for wheelgame.js, load it in yourself as plain text, inject your own code into it to manipulate the functions, then execute the code as though it had been loaded normally. That would give you direct control of every action the wheel performs. It's a good option if you want to have direct interaction with the parts of the code that render the wheel actions visually.
The easier option would be to trigger a click event on the button that starts the spin action, but given that you've been asking a lot of technical questions about the code, I'm not sure if that's what you're going for.