11 hours ago, iliqnew said:
I am up to the 'MMO' part
I doubt that. MMO has a meaning, although in the past decade the term is brandished idly, like many other words (e.g. "terrorist") used different from their established meanings.
The term MMO refers to a major inflection point. Supporting a double-digit number of concurrent players isn't difficult. Experienced developers using simple tools can support a few hundred concurrent players easily. But soon you'll hit an inflection point, it no longer becomes easy and cannot be handled by an individual or a small group of people. Supporting several thousand concurrent gets harder. You can't do the work on one machine or a single program, you must spread the work across multiple machines and multiple programs. The work requires multiple teams to distribute the work. Usually this has an inflection point of around 100,000 concurrent users. Then it hits another inflection point, you cannot add new functionality without extreme difficulty. Then you move to MMO, where data must be coordinated across many sites globally, across a large number of systems, across a large number of teams.
Your topics are good and over time you'll need to become familiar with each, but you're best relying on others to do the work.
None of those are beginner-friendly.
11 hours ago, iliqnew said:
For example when a player logs in into his/hers account. Should the server send him/her the whole data related to this particular account (eg. number of avatars and their names, levels, classes, stats, friendlists etc.) or should I do something else?
Not MMO specific. The common term today is a Central Authentication Service (CAS) system, but the logic dates back to the 1960s at least.
In simplest terms, the user logs in and the back-end provides them with a token. The token gets passed around as needed between systems. When the user makes a request associated to their account, the token is validated and requests are allowed or denied based on permission.
As for sending "the whole data", generally minimize network traffic and processing. Don't send something if you don't need it. If the client requests a set of data, send that data if they have access. If the client needs avatar names, classes, stats, provide a way to request it.
There are decades of computer science research on the topic of authentication, security, and proof-keeping. It is a broad field of study.
The topic gets complex quickly. It is generally best to use an existing library rather than write your own. With an existing library you don't need to become expert, you can rely on other experts who dedicate their lives to the field. Pick something that fits the scale of what you need, a system designed for enterprise security (with a team of people managing user accounts) is a bad fit for a staff of 20 developers, and something that works for a staff of 20 is probably a bad fit for someone working on their own.
11 hours ago, iliqnew said:
when ingame should the server and client sync the data dynamicly or only when the data is being updated?
Depends entirely on the system, it should be done when needed and not done when not needed.
Large systems have priorities and caches. Transitory data can be accumulated and stored periodically; your position on the world map is live data that needs to be maintained but doesn't need to be persisted to disk until you hit a save point or transition between zones. If the data is lost for some reason it isn't a problem. Some information needs to be updated more frequently, items collected on the field need to be saved more often but don't need to be written to disk instantly. Some transactions must be complete and finalized before the player can move on, such as players trading objects between each other or cash-based transactions. Sometimes things that are normally at one layer will fall into a higher priority; nobody will mind if a crash causes you to lose common loot collected on the field, but when you defeat the boss and collect the unique item you don't want that data lost due to a crash or data corruption.
Small systems store data in memory and write to disk or an established database library at times they feel are appropriate.
Concurrent processing, distributed storage, and cache consistency are part of another broad field of computer science with decades of CS history. The topic dates back to the earliest computer systems that needed to maintain and reconcile data between business offices.
Like above with authentication, it is generally best to use existing libraries. Pick something that fits the scale of what you actually need. A distributed transaction system capable of millions of transactions per second scaling across multiple sites globally is a bad fit for something that will run on a single machine. Keep data in memory that should be kept in memory. Save to disk or save to SQL databases when that's appropriate, but not when it isn't.
I really want to learn more about the relations between the server program and the avatars' database ingame.
