In addition to that if you are going to implement logging in from a game client do not ever store something like a userid/username for successful logins in client(even in memory), use sessions as Sid suggested, and send a session id to the client. And also make sure that session id is also hashed & salted so client can't guess someone else's session id. If it's a game and not a website(that user may be using on multiple devices) i'd also prefer to invalidate any other alive sessions after a new login.

Also, to slow down brute force attacks even more, give user a limited tries, like after 3 unsuccessful login attempts, make them wait like 30 seconds before letting them to be able to try another one. Also make sure that timeout is not session/client based so they can't use multiple sessions/clients to overcome the limit, associate that limit with username. After that 30 seconds if they get their password wrong the 4th time make them wait 30(or even more this time) more seconds, don't just give them 3 new tries after that time. Reject their login attempts straight up and do not even check if password matches so that your system does not run that deliberately slow adaptive hashing algorithms. Though, this timeout thing generally used in systems that can't use that deliberately slow algorithms because of limited system resources and high user traffic.(They use faster hashing algorithms but slow down the brute force attacks in other ways than relying on algorithm being slow.)

And as Sid also said (i just want to highlight) do not trust anything that client sends and make sure they are sanitized before even trying to use them anywhere in your system.