Rotating the controller pitch rotates the whole collision shape and mesh of the character, which makes the player move slower when looking down or up. In every fps game the camera pitch is being rotated, not the whole character, so why do you teach us that in the lesson? I know you probably want to keep it simple, but why teach us something that shouldn’t be done?
I had a similar feeling about (the?/an?) other blueprinting course they did. They taught how to trigger damage to the player when an animation plays as opposed to when hit by a hitbox, so even if the enemy attack doesn’t actually line up with hitting you in reality you take the damage.
I thought maybe that had been done to be like “Okay, now that’s one way to do it, but it’s inelegant so we…” but it was left like that and before long the course ended.
Obviously they don’t want to make the game for us, but as far as best practices go that seems like a bad idea, and with the issue you brought up I’m already noticing problems with it (Looking directly up means you can’t move? Looking slightly up means you can’t cross over the curb onto a sidewalk? If you jump and then you look up you kind of slide around a little?) and I’m concerned it’ll be left as-is for the remainder of the lesson.
To be fair, rotating the camera on its own isn’t really the solution either. Take a look at the FPS Template project in Unreal to understand the full setup.
That said, it’s a good criticism to have, and it could have certainly be done better. When you’re learning, I think it’s healthy to look at something and realize it could be done better, it helps solidify knowledge and builds critical thinking when it comes to game development.
This topic was automatically closed 20 days after the last reply. New replies are no longer allowed.