Hello, my name is Duarte.
I'd love to discuss this with you in detail, but this is the particular way I'd create this platform for you.
A .Net Core backend, for portability would serve as the main API, which clients talk to when something needs to happen. Be it list games, start a new game, etc...
Assuming the game logic is quite complex and with scalability in mind, there's no way the game server can be the same as the API, the .Net Core backend. So we need a game server and a game client. Due to the open-source nature, verified portability and stability I'd recommend Godot.
The .Net Core API now has the responsibility of spawning game servers when necessary, to host games. If the game rules are simple enough, maybe we can place them into threads and have them run as background services inside the .Net Core application. This is unlikely. A messaging queue will be necessary to transmit this information and spawn the given processes in the appropriate place. Apache Kafka comes to mind, assuming you want to horizontally scale this application(skipping this step makes it impossible).
This creates a new problem, how do you load in the game? It's 99% going to be HTML5 canvas, so why not skip the HTML part and do the whole thing on the client? Ok then. We actually solved another problem by doing this. Suddenly we have an app that works on windows, macos, linux, on the web, on iOS and Android with the same codebase, talking to the same API.
...
Word Limit. Please reach out.