Is this a secure data exchange scheme for a game?
First of, crypto is hard, and you shouldn't create your own.
Vulnerabilities
Your login seems to suffer from a pass the hash vulnerability. An attacker doesn't need to crack the hash to login, they can just pass the hash, and will be logged in. This defeats the purpose of hashing the password in the first place.
sha512 is not recommended for storing passwords, as it's way too fast. Use something like bcrypt instead.
HTTPS and Encryption
You say that RSA is too expensive. But generally, RSA is only used to exchange a key, which is then used with a much less expensive private key cryptosystem.
As you clarified that you do use HTTPS, it should be noted that you do already use RSA. HTTPS uses RSA or diffie hellman for key exchange and some block or stream cipher for the actual data encryption.
As you use HTTPS, you already have data confidentiality and integrity (and server authentication and optionally client authentication), there is no need for additional encryption on the application level.
Advantages of your scheme?
Your scheme doesn't really seem to serve any purpose. You already are secure from eavesdropping and data tampering via HTTPS (and your scheme wouldn't have prevented it anyways).
So your scheme doesn't seem to be about data exchange so much, as it is about authentication.
Generally, authentication is handled like this:
Login:
- Client sends username and password (plain)
- Server hashes password, and compares hash against hash in db
- Server sends session id back
Other Requests:
- Client sends session id
- Server validates session id
- (optional) when session state changes, server regenerates session id
Your approach is similar, but did introduce the pass the hash vulnerability, and contains a seed, which seems to be unnecessary and thus only complicates the scheme. It also regenerates the session id on each request, which isn't really needed and only seems to cause unnecessary overhead.
... Client sends "login" request with username, hash and seed to the server.
Since the seed is created by the client, the combination of seed and hash effectively form a password equivalent which can be replayed again and again. You are probably trying to implement something similar to Digest Authentication here. But with digest authentication the nonce (i.e. your "seed") is determined by the server and not by the client and thus safe against replay attacks.
Apart from that: you are already using HTTPS which protects the traffic against sniffing and modification. Why build another security mechanism on top of it? Digest authentication is usually used for connections which are not encrypted and has the problem that you need to have the password in clear (or equivalent) at the server. If the connection is already protected against sniffing you don't need extra protection for the password and can send it in clear. This has the advantage that you can store the password then as an irreversible hash at the server.