New answers tagged

1

In general, it depends on the game. You say: The first option seems suited for a LocalPlayerController because that's the naive way you normally read the mouse coordinates in the screen and adjust the deltaYaw and deltaPitch based on the deltaX and deltaY of the mouse. But not on every game you don't. Let us keep in mind that both sound like high level ...


1

The second approach is better in general (with the exception of code that generates a new mesh each frame). The reason is that queueing request allows you to execute them in batch. And that opens plenty of optimizations. For example, use a single render call for many identical meshes. And if you are switching shaders, you can make of the render calls for ...


0

Posting since this might help someone else. Thanks to @Philipp's helpful answer, this is what I ended up with. This organization feels much cleaner! StairMaster feels a little weird since it does not use Start or Update, and StaminaBar had a bit of a race condition where Player was calling Reset() on it before Start() was called, so localScale was being ...


2

Single responsibility principle Every script should do exactly one thing. So when you describe the functionality of a script and you use the word "and" in that description, then that's a sign that it should probably be split up. For example, this script could be documented as "This script spawns the stairs and moves the player and updates the ...


Top 50 recent answers are included