you have to get the secret onto the server in the first place, which puts you right back to needing TLS
TLS is great if the thread model is "someone with access to the wires between the client computer and the server computer may sniff the network packets and wants your game password."
This attack does exist -- google "FireSheep" for some hilarious Facebook cookie stealing goodness from a few years back -- and thus it is good to use TLS or DTLS to defend against that.
However, that's not the biggest attack. The biggest attack is when your SQL database gets dumped by some intruder, because of a code vulnerability, or a lost backup, or employee malfeasance, or whatever. While TLS breaking gets you accounts by the ones and twos, the database dump gets you accounts by the millions (assuming it's a high profile target.)
Therefore, the #1 important thing is to store a nonrecoverable hash in the database (no plaintext, no base64, no MD5, and SHA-1 is soon going to be equally bad -- and, you don't want raw hashes, you want a key strengthening function like scrypt or bcrypt.)
the client's established connection can be easily hijacked/snooped.
For people playing your game on public WiFi, this may be true. However, contrary to popular belief, the main threat, outside public WiFi, is not that of snooping networks or even injecting network packets. The main threat is weak passwords that can be brute-force guessed. The second main threat is malware that attacks the client machine. Therefore, it's actually more important you have good account protection and recovery in place -- anything from an actual phone number where actual human beings can be reached, to 2-factor authentication, to server-side smarts that detects irregular logins and protects the accounts.
