If the player is able to install a new root certificate on their computer that your game will trust, they can use mitmproxy or some other HTTPS intercepting proxy to observe any communication between your game and the server.

Basically, the way such proxies work is that they pretend to be the server your game (or a browser) tries to connect to, and can do so by presenting a dynamically generated certificate saying so, signed by the proxy's own root certificate. Obviously, for this to work, the user needs to tell their system (and specifically Unity) to trust this custom root certificate. But if they can do that, then Unity will happily accept the proxy's claim that it is indeed your server, since it sees a valid signed certificate saying so.

I don't know enough about Unity's HTTPS implementation to say for sure whether adding custom root certificates like that is possible. But, in the absence of certain knowledge that it's not, I would assume that it most likely is. In particular, if Unity just delegates certificate management to your OS, then adding the custom root certificate to the OS list of trusted roots (which any user with administrator privileges can generally do) will make Unity also trust it.

You might be able to prevent this attack by implementing some form of certificate pinning, so that your game knows what the legitimate server's certificate is supposed to look like, and refuses to communicate with a server presenting some other certificate, even if it's signed by what the user's OS considers a trusted root. But that may be non-trivial to set up.

(Also, even if you can prevent this particular attack, the player might still be able to intercept your data before it is sent over HTTPS e.g. by attaching a debugger to your game or by monkey-patching the Unity API used to transmit the data some other way. In general, it's very hard to stop a sufficiently skilled and motivated user from finding out what your software does as long as it's running on their computer.)