"testCollision" is a very poor name for a function that does much more: You're not just testing if a collision occurred; You're modifying game state, and this should be reflected in the function name.
You're right - `testCollision` is a misleading name. I'll address this in a future video.
The erase + remove_if + lambda combo used to remove destroyed bricks is a good showcase of new C++ 11 features, but I think you overstate the performance aspect: At most, you can remove 3 bricks at the same time (and that would be an extremely rare event), so the "block remove" optimization features offered by erase are basically irrelevant here.
True, the performance aspect may be irrelevant in a game like this one, but it's still the way to go, in my opinion. It's a scalable approach that works with any type of game: what if an user tries to make a shoot'em'up game after watching the tutorial? Erase-remove_if will work great.
The whole "frame time" segment should have been left out, in my opinion, because, as you yourself explained, it leads to a pretty absurd situation, where a slower machine has to do more work, so ... Is that really a solution?
If you are referring to the part before the "time slices": I included that part to show the train of thought that brought me to using slices.
If you are referring to "time slices" themselves: it's not "a solution", but it's the "best solution", in my opinion. It has been used a lot in the past, and even if there are some drawbacks it's a lot better than scaling movements/actions with frametime.
Take a look at these links for more information:
I don't see the point of replacing the content of main with Game::run. That seems like needless indirection.
It's good to have a Game structure that encapsulates your gamestate, but there's no reason why your high-level flow can't stay in main.
As I said in the video, it's not a global solution, but it's what works for me. I like my code to be as structured and abstracted as possible.
While having a `Game::run` may be totally unnecessary for an Arkanoid clone, I was going for a more scalable approach: the `Game` class design works well in larger games (especially when dividing the `Game` class itself in `GameWindow` and `GameState`).
Thanks again for the criticism. I really enjoy reading other people's opinions and improving my videos/knowledge.
Also, your YouTube videos are really interesting!