Applefruit said:
I would like to know what is actually needed in terms of technology to build an online game.
The barest bare minimum, you need a computer with a publicly reachable IP address. Anything you implement beyond that is good, but not essential.
What you decide to implement beyond that is a matter of scope and scale. You can build enormous infrastructure on the backend, you can build tiny services, you can build anything in between.
Businesses usually rely on major providers and libraries so they don't need to spend their time and effort re-inventing the wheel.
Applefruit said:
1 - I've made an API with .net core and a login system, so my client logs in and receives an authentication token. Now I would like my user to pick a world where he should connect to a game server, how should the game server be aware of his authentication code? Should the API have a connection to the world?
So you'll need game servers, whatever that means in the context of your game. For small hobby projects there's nothing wrong with it being in a single program. For larger projects that need to scale up with more users, it can mean that you have dedicated instances or instances on AWS or Google Cloud or a Kubernetes cluster or something else.
Assuming they're built as different servers, your game servers will contact your authentication server, and using a secure connection (often established with a shared secret between servers) verify that the authentication token is valid. There are a bunch of ‘best practices’ to keep the tokens safe and secure, like not basing them on any real information like account IDs and passwords, expiring them rapidly or making them single use, etc. Ultimately one of your servers issues a token to the client over a secure connection, the client gives the token to another server over a different secure connection, the new server verifies the token's validity, and the connection is verified.
As for how you pick the worlds and server, you'll need something that serves as a hub for when players enter and figure out what games are available. It could be the same service the client sees to log in, or it could be some other service you run. It will need to do something to coordinate what games you have available, possibly spawning or making available game servers, possibly connecting to matchmaking, or doing whatever additional work your game design needs.
There is no universal standard, but there are a bunch of common solutions. If you were using a game engine like Unity or Unreal I'd recommend reviewing systems based on the interfaces they provide, but as you're rolling your own code yourself, you'll be on your own there.
Applefruit said:
2 - A user is walking around in my game server and he picks up an item, it's added to his inventory and now I would like to inform the database this user has an item, and right now I'm using .net core for that with the EntityFramework which I would like to remain using. Would the server make a call to the .net core API as well?
Again, it depends. Often it is done periodically to avoid the costs of frequent writes, and ultimately the details depend on the game design and the system.
For a small game with a very small, non-scaling server, you could write to it directly from your server program. This won't scale, but for a hobby project that will never be commercial and must be low cost, it can be the best solution.
For many games there are several servers and services involved. The game server (not the clients) handle the processing of users running around in the world doing whatever they do. Never trust the client, validate everything on the servers. Depending on the nature of the interaction, you'll have the game server notify the account server to update the account data. If it's a transaction, such as two players exchanging money for goods, you'll need to use a little bit of locking to ensure the transaction is valid for both players and submitted simultaneously. It is a solved problem in databases, there are things like “ACID” guarantees and transactional boundaries, but you as the programmer need to write code that follows the rules.
The game server would write that data out to the data backend periodically often at regular intervals during gameplay, and also at special events like special transactions, high value loot drops, and logging out. Details depend entirely on what the game and implementation need. Some only write the information out after a match is complete. Others write information frequently as the player takes actions on the world.
Note that there are a bunch of existing systems and services out there that provide their own variations of all the technology you've asked about. As you're already in .net, you might consider Microsoft's PlayFab SDK. Or you might prefer GameSparks if you're using Amazon services. Or Firebase if you're using Google services. Or Braincloud, or Loot Locker, or Photon Cloud or so many others. They do the account handling including verification, account recovery, and authentication with major services like through Google / Gmail or through Steam or through Facebook. They handle storage of the data for the account and the individual game. They also have options that allow them to scale with large user counts, or to stay small. Each one has their own pros and cons, and their own fee schedules.
Using an existing library won't get you custom internals, but they're already built and debugged and many game companies already rely on them. If your goal is to write games and you want something that scales, it is often faster and easier to rely on their solutions instead of rolling your own.
