To expand on @MechMK1 point "depends on your skill level"
What this means is it is possible, while non-trivial the means is quite simple to explain in a SO answer and not easy to do in reality.
While TLS is designed to have all data readable by endpoints including any 'endpoint' you add into a communication channel, it is important to realise that TLS endpoints are designed to prevent packet modification.
To put it another way, TLS connections being sent to a server you do not control, from a client you do not control, must maintain integrity of the packet. The data the receiver (server) processes must be cryptographicly verifiable to be complete unmodified from the packets the sender (game) actually sent.
Now we have described TLS is designed for integrity, as mentioned above TLS is not designed for confidentiality. I.e. if you add a network device (like security devices) into a communication channel, it is possible by-design to read the contents of all TLS traffic (with a few caveats).
The hardest one is TLS1.3;
This uses ephemeral keys negotiated by both the server and teh client, i.e. before every communication a server generates a public key using a private key it has that never leaves its endpoint (so you never see it on a client side), then the client generates a public key using it's own private key that never gets sent to the server and uses the server public key to encrypt the client public key and send it to the server. The server (and only the server) now can decrypt the client public key using it's own server private key.
This means the client public key is used to encrypt the data for this communication in such a way that the client using it's own client private key can decrypt the server sent data.
As an 'endpoint' for TLS1.3 you must have some way to access a server private key and a client private key, this is how security devices must operate, and are able to do eavesdropping for security purposes.
The next communication will have to do this exchange again, ergo ephemeral key exchange. And this is the only option for TLS1.3
A simplified description of TLS1.3 key logging, i.e. not only done on a client.
Now the next one is TLS1.2;
This will depend on the cipher negotiated. If a cipher that uses ephemeral keys is used the TLS1.3 is also an appropriate summary.
Other ciphers will allow you to symmetric cryptography which means a shared session key is used, for browser they're typically stored to:
- Windows: C:\Users<user>\Desktop\sslkeylog.txt
- Mac: /Users//sslkeyfile
- Linux: /home//sslkeyfile
Some ciphers used for TLS1.2 and earlier TLS versions even allow what are called null ciphers, again not trivial but these essentially permit eavesdropping with far less complexity.
The most interesting caveat is some servers will allow you to force the use of certain ciphers, even allow you to negotiate from the client a lower TLS protocol.
The last caveat is some servers are misconfigured, or as I like to point out, configured for optimisations of insecurity. I.e. even with TLS1.3 is it ubiquitous (not just common, more common than common) to see symmetric session keys in use, because it is faster but makes eavesdropping possible in TLS1.3 when the entire reason for TLS1.3 to exist was to avoid shared secrets entirely.
I don't like to shut down people who ask questions and tell you that you're lacking fundamental knowledge, because this is Stack Overflow and answering those types of questions is entirely the point of this community. I encourage you to take the above topics and do your own investigations and please ask more questions on Stack Overflow as you progress on your learning journey, don't be discouraged by the previous answer that is not what this community is about.