Relatively secure faster alternative for HTTPS

HTTPS is HTTP over TLS.

If you implement a game, using HTTP is usually not a good idea. The HTTP protocol is designed for requesting documents, not for real-time games. A better idea would be to develop your own protocol directly based on TCP or UDP (UDP is faster while TCP is easier to use, but that's a topic for game development stackexchange) and tunnel it through TLS.

The time-consuming key exchange process only needs to happen once when establishing the connection. When you keep the same connection open during the game, the only latency overhead is caused by encryption and decryption. TLS supports multiple cipher suites (sets of cryptographic algorithms which are used). The choice of cipher suite can be used to find a compromise between performance and security.  

High latency networks take over a second for SSL handshake

There should be no need to do a full handshake for each message exchange. The handshake is only needed at start of the TCP connection, thus just leave the connection open. Then the latency is what you have with any other established TCP connection. If you need even less latency at the cost of possible packet loss or duplication use DTLS, i.e. TLS with datagrams (UDP).

Apart from that HTTP(s) might not be the optimal protocol for use on high latency and low bandwidth connections. The encapsulation of the payload in HTTP request and response alone has a non-trivial overhead (depending on the amount of payload) and if you the often used text based payload (i.e. JSON, XML or similar) only adds more overhead. Binary based data exchange (like protobuf or similar) makes much better use of the available resources.

If you want a connection based on TCP, use TLS. Set up the connection in advance, so you pay the 2 RTT latency once and then never need pay it again. You can use the SPDY extension if you want to reduce the one-time up-front latency cost of initially establishing the connection.

If you want a connection based on UDP, use DTLS. This may reduce even more latency, by eliminating TCP's re-transmissions and other things TCP does that can introduce latency in certain circumstances. Once again, set up the connection in advance, so you pay the 2 RTT latency once and then never need pay it again.