How to write a real-time online game? Methodology, patterns, articles?

Question

C++ / C#

Good day, dear,
I will write the server part in c ++ (the solution may change towards nodejs due to the lowest syntax threshold), but I'm more interested not so much in the subtleties of the language itself as in methods and techniques.
I'm interested in the methodology and patterns for creating the logical structure of a real-time online game.
This will help me get off to a fast start and provide easy post development and support.
I do not want to step on a rake, creating wheels, so I ask you to help me sort out the basics.
I think it's worth considering the issue in layers, so I decided to divide the question I'm interested in into subparagraphs:
1. What is the best way to open a socket?
2. What kind of data is best transmitted over the socket and in what form? (smallest size, performance)
3. What to store in the server's RAM, what to store in the database?
4. Which database is best? SQL / noSQL / Relational / Object-relational?
5. Does it make sense to use caching? Or RAM + DB will come down.
Sincerely, Adventurer.

Answer 1

You ask more or less the right questions, but there are no right answers to them. Each case is very individual and a short answer is indispensable here, lectures with tons of theory are needed here. I once wrote games: php (api) + flash (client) + C++ (server) + mysql (database) + memcache (cache), php (api) + python gevent (server) + mongodb (database) + redis (cache) + html5 (client), nodejs (server) + html5 (client) + redis (cache) + postgresql (database). All of them were quite productive. Such a variety of technologies was partly due to my curiosity (the project on nodejs wrote for myself).
In general, trying to answer your questions:
1. It's not entirely clear what you mean. Refine your question.
2. It is best to send all client actions to the server and calculate on the server to make it impossible to fake the results of actions, but this leads to an increase in the load on the server. Protocol - I like bson with ready-made libraries, clear format and small size. But again, I used it only in the second project, in other places I created my own bikes, which for specific cases were the most effective (in my opinion)
3. Store in the database everything that should not disappear between games (relatively speaking, after turning off the server ;)), in RAM to duplicate everything ideally (to get rid of disk read operations).
4. Depends on the needs. Postgresql\mysql are more traditional. Mongodb - fashionable) If you understand that in your game you can survive the limitations of mongodb (for example, the lack of transactions) - use it, it is very convenient for storing game states. If you're not sure, use traditional relationals.
5. Caching is essentially the movement of data from the database to RAM. Moreover, it moves in such a way that the speed of sampling from RAM does not depend on the amount of data. These are called hash tables.
In general, no offense, but judging by your questions, you need to seriously tighten up the theory before taking on a serious game. Writing the server side in C++ is cool if you know it perfectly. In general, you will not get a big profit, since the speed of C ++ is manifested in number grinders. And the game server is basically read / write operations that will be the same in almost any modern language and their speed depends more on the built architecture.
My recommendations: read about blocking/non-blocking sockets, multithreading, data structures, design patterns, query optimization (including data normalization and denormalization), caching. In parallel with this, you can make a simple chat, gradually improving and optimizing it. Thus, you will acquire both theory and practice. After that, you can make some simple game.

Answer 2

The best answer for a topic starter is just get started. Everything is bad with theory, but with fantasy everything is fine and it's really great. As @Kazmiruk said , he also had bicycles in the beginning, so that's where we should start. However, one point was not quite clearly highlighted here. An online game is a LOT of graphics. If its quality is poor, then few people will play, with rare exceptions, such as minecraft, but there the author thought hard about how to compensate for this shortcoming and turned it into a feature.
And if you look at things realistically, then at the moment, it’s too early for you to create a working implementation, oh, how you need to tighten up theory and practice. If I were you, I would do this: make the first version and gradually improve. If you don't, then it's not time for such things.

Answer 3

It strongly seems to me that you first of all need to understand / tell us what exactly you are going to write, and only then - you may be offered certain solutions.
Depending on what you will do - what kind of "real-time server game" you will have - the techniques or methods that will best suit you will depend on this.
And what do you mean by "realtime"?
Do you understand that if 2 chess players are limited by the regulations - they say make a move once a minute and always strictly every other minute - then this will also be a _real-time game_? "realtime chess with a period of 1 minute". Will this suit you?
on the other hand, let's say - a server for quake - should live on completely different principles.
on the third hand - with an abundance of players - the Kvakov server will start to lag, but EVE-online, as it was already written somewhere - ... will slow down time.
What is perfect in one case may not work in another. First, build a logical model of your game, entities, objects, the principles of their interaction with each other, determine the requirements for speed, then begin to imagine how clients and the server will interact and what picture of the world will they support?
for example, if you have a platformer, then understand how your personas will interact and what will influence it. For example - if he shoots at everyone - this is one thing. And if it can be blown away by the wind, and in such a way that another character generates, this is already another. But what if the data from one of the clients came later than required? how will the synchronization problems be solved? what to do if one player shoots at a place where his client shows that another player is standing, and the server thinks that the player has long since fled?
and then build from this and what you know certain architectural mechanisms and choose patterns.
In general the task strongly global - in that form as the question is set.
Maybe you should try to start with something simpler? because if you ask a question about "how to open a socket" (technological instrumental question) - but have a poor idea of ​​​​what to do if "out of sync" starts (these are the concepts of the logic of the server-client distributed system) - then it might be worth starting with something simpler ?
for example, make a server for which turn-based game?

Answer 4

No matter how “correctly” you plan, it will break anyway :) Therefore, if the project is interesting, you can shit-code until you make a demo version with minimal functionality, and then go to kickstarter or Steam early access and finish the product with the hands of professionals :) (with the money raised)
but about the questions first before asking them, you need to know at least what @dplsoft is talking about , without this fundamental knowledge, so to speak, it’s better not to take on such an undertaking.

Answer 5

I wrote a comet server in C++ it's not a game but the server side would have some common features.
As a database, I used Redis very much. I wrote my client
for it. I process incoming connections in several threads using epoll, in one thread I accept all connections and distribute the already accepted connections equally to the rest of the threads so that they process messages.
In general, the performance pleases.