What risks am I taking by using an http site to play a video game that just records mouse events?
Yes, there is a risk.
HTTPS ensures not just confidentiality, but also integrity and authenticity. As such, an attacker could hijack the connection between you and the server and inject malicious JavaScript into your session.
How likely is that to happen?
Depends on how you connect to the server. If you are in your own home, then the likelihood is not very big. It's a risk still, don't get me wrong, but I don't want to cause unnecessary paranoia.
On the other hand, if you connect to a public access point (e.g. "free McDonald's Wifi"), then the chance of this happening is much much higher.
How severe is this?
Since there is no sensitive data there, the "usual" things like credential stealing or session hijacking are not applicable. However, depending on how determined the attacker is, they might redirect you to other malicious domains, exploit browser vulnerabilities, get you to download stuff or even get you to disclose credentials for other services (e.g. "Log in with your Google, Twitter or Facebook account to play").
As Eilon has pointed out in the comments, another potentially unwanted side-effect is that your ISP can tamper with the website you use. Some ISPs do this for arguably benign purposes, such as stripping whitespace off the HTML document before sending it to you, while others do more "intrusive" changes, such as compressing images, or even injecting advertisements into the website. While this is not a security-risk per se, it is unwanted behavior that can most effectively be combatted by using HTTPS.
Does that mean you should stop playing?
That depends completely on your risk appetite and whether or not the upsides outweigh the downsides for you personally.
Attacker-controlled javascript within browser sandbox
If you don't have any sensitive or valuable data or inputs within that site, the main risk IMHO is that since it uses HTTP, an attacker can impersonate the site owner and inject malicious javascript. The damage that it can do is limited by the browser sandbox, but it does create at least the following risks:
- Silent redirect to a spoofed page
One crude but effective approach for phishing is to wait for when the tab has become inactive, and then redirect to a spoofed phishing page saying something like 'Your e-mail/facebook/whatever session is expired, please log in again' - if the user has many stale tabs (and many do), then they can legitimately believe that they actually did have that service open there, and that it did just expire, and enter their credentials there.
- Enumeration and exploitation of local resources
Such Javascript can try and make network connections that would be otherwise prevented by a firewall or simple NAT on your home router, since they are not coming directly from the attacker but from the user workstation. For example, the open source BeEF toolkit (https://beefproject.com/) has some proof of concept modules that try to explore that. If you have unsecure services in your local network accessible via http (for example, a vulnerable local application or a printer or router config page) but not accessible from the public internet, malicious javascript can take you there.
- Breaking out of the sandbox
Every now and then, there are browser vulnerabilities that would allow malicious javascript (or other website-supplied content) to 'break out of the sandbox' and achieve arbitrary code execution. Those are rare, but they do exist.
It's worth noting that all these are things that can be done by any website you visit - so the usage of http does not create an additional risk compared to visiting a https page that's hosted by someone you don't trust. So if you feel comfortable opening random links on the internet containing fun stuff, then this is within your risk profile; but if you'd want to limit your browsing to specific well-known, somewhat trusted sites, then the usage of http means that perhaps you'll get not necessarily the site you intended but someone impersonating that.