Comment j'ai patché l'univers

Il y a beaucoup d'articles sur le développement de jeux sur Habré, mais parmi eux il y a très peu d'articles qui se rapportent à des sujets «en coulisses». L'un de ces sujets est l'organisation de la livraison du jeu à un grand nombre d'utilisateurs depuis longtemps (un, deux, trois). Malgré le fait que pour certains la tâche puisse sembler futile, j'ai décidé de partager mon expérience de marche du râteau dans cette affaire pour un projet spécifique. Toute personne intéressée - s'il vous plaît.

Une petite digression sur la divulgation d'informations. La plupart des entreprises sont très jalouses que la «cuisine intérieure» ne devienne pas accessible au grand public. Pourquoi - je ne sais pas, mais qu'est-ce que - c'est. Dans ce projet particulier - The Universim - j'ai eu de la chance et le PDG de Crytivo Inc. (anciennement Crytivo Games Inc.) Alex Wallet s'est avéré absolument sain d'esprit dans une telle affaire, j'ai donc l'occasion de partager mon expérience avec les autres.

Un peu de patcher en soi

Je participe au développement de jeux depuis longtemps. Dans certains - en tant que concepteur de jeux et programmeur, dans certains - en tant que fusion d'un administrateur système et d'un programmeur (je n'aime pas le terme «devops», car il ne reflète pas exactement l'essence des tâches que j'exécute dans de tels projets).

Fin 2013 (l'horreur du temps qui passe), j'ai pensé à proposer de nouvelles versions (builds) aux utilisateurs. Bien sûr, à cette époque, il y avait de nombreuses solutions pour une telle tâche, mais le désir de fabriquer un produit et le désir de «construction de vélos» ont gagné. De plus, je voulais apprendre le C # plus profondément - j'ai donc décidé de créer mon propre patcher. Pour l'avenir, je dirai que le projet a été un succès, plus d'une dizaine d'entreprises l'ont utilisé et l'utilisent dans leurs projets, certaines ont demandé de réaliser une version prenant en compte exactement leurs souhaits.

La solution classique consiste à créer des packages delta (ou diffs) d'une version à l'autre. Cependant, cette approche n'est pas pratique pour les joueurs et les développeurs de testeurs - dans un cas, pour obtenir la dernière version du jeu, vous devez parcourir toute la chaîne des mises à jour. C'est-à-dire le joueur doit rassembler séquentiellement une certaine quantité de données qu'il (a) n'utilisera jamais, et le développeur de stocker sur son serveur (ou serveurs) un tas de données obsolètes dont certains des joueurs pourraient avoir besoin une fois.

Dans un autre cas, vous devez télécharger le correctif pour votre version au plus tard, mais le développeur doit garder tout ce zoo de correctifs à la maison. Certaines implémentations de systèmes de correctifs nécessitent certains logiciels et une certaine logique sur les serveurs - ce qui crée également un casse-tête supplémentaire pour les développeurs. De plus, les développeurs de jeux ne veulent souvent rien faire qui ne soit directement lié au développement du jeu lui-même. Je dirai même plus - la plupart ne sont pas des spécialistes capables de configurer des serveurs pour la distribution de contenu - ce n'est tout simplement pas leur domaine d'activité.

Avec tout cela à l'esprit, je voulais trouver une solution qui serait aussi simple que possible pour les utilisateurs (qui veulent jouer plus vite et ne pas danser avec des correctifs de différentes versions), ainsi que pour les développeurs qui ont besoin d'écrire un jeu sans savoir quoi et pourquoi non mis à jour par le prochain utilisateur.

Connaissant le fonctionnement de certains protocoles de synchronisation des données - lorsque les données sont analysées sur le client et que seules les modifications du serveur sont transmises - j'ai décidé d'utiliser la même approche.
De plus, en pratique, de version en version tout au long de la période de développement, de nombreux fichiers de jeu changent légèrement - la texture est là, le modèle lui-même, quelques sons.

En conséquence, il semblait logique de considérer chaque fichier dans le répertoire du jeu comme un ensemble de blocs de données. À la sortie de la prochaine version, la construction du jeu est analysée, une carte de blocs est créée et les fichiers du jeu eux-mêmes sont compressés bloc par bloc. Le client analyse les blocs existants et seule la différence est téléchargée.

Initialement, le patcher était prévu comme module dans Unity3D, cependant, un détail désagréable est apparu qui m'a fait reconsidérer cela. Le fait est que Unity3D est une application (moteur) totalement indépendante de votre code. Et pendant que le moteur fonctionne, tout un tas de fichiers sont ouverts, ce qui crée des problèmes lorsque vous souhaitez les mettre à jour.

Dans les systèmes de type Unix, l'écrasement d'un fichier ouvert (sauf s'il est spécifiquement verrouillé) ne pose aucun problème, mais sous Windows, sans danser avec un tambourin, une telle «feinte avec des oreilles» ne fonctionne pas. C'est pourquoi j'ai créé le patcher comme une application distincte qui ne charge que des bibliothèques système. De fait, le patcher lui-même s'est avéré être un utilitaire complètement indépendant du moteur Unity3D, ce qui n'a cependant pas empêché de l'ajouter au magasin Unity3D.

Algorithme Patcher

Ainsi, les développeurs publient de nouvelles versions avec une certaine fréquence. Les joueurs veulent obtenir ces versions. L'objectif du développeur est de fournir ce processus à un coût minimal et avec un minimum de maux de tête pour les joueurs.

Du développeur

Lors de la préparation d'un patch, l'algorithme des actions du patcher ressemble à ceci:

○ Créez une arborescence de fichiers de jeu avec leurs attributs et les sommes de contrôle SHA512
○ Pour chaque fichier:
► Divisez le contenu en blocs.
► Enregistrez la somme de contrôle SHA256.
► Compressez un bloc et ajoutez-le à la carte des blocs de fichiers.
► Enregistrez l'adresse du bloc dans l'index.
○ Enregistrez l'arborescence des fichiers avec leurs sommes de contrôle.
○ Enregistrez le fichier de données de version.

Le développeur doit télécharger les fichiers reçus sur le serveur.

Côté joueur

Sur le client, le patcher effectue les opérations suivantes:
○ Se copie dans un fichier avec un nom différent. Cela mettra à jour le fichier exécutable du patcher si nécessaire. Le contrôle est ensuite transféré sur la copie et l'original est terminé.
○ Téléchargez le fichier de version et comparez-le avec le fichier de version local.
○ Si la comparaison n'a pas révélé de différence - vous pouvez jouer, nous avons la dernière version. S'il y a une différence, passez à l'élément suivant.
○ Téléchargez une arborescence de fichiers avec leurs sommes de contrôle.
○ Pour chaque fichier dans l'arborescence du serveur:
► S'il y a un fichier, il considère sa somme de contrôle (SHA512). Sinon, il le considère comme étant vide, (c'est-à-dire composé de zéros solides) et considère également sa somme de contrôle.
► Si la somme du fichier local ne correspond pas à la somme de contrôle du fichier de la dernière version:
► Crée une carte de blocs locale et la compare avec la carte de blocs du serveur.
► Pour chaque bloc local qui diffère du bloc distant, il télécharge un bloc compressé depuis le serveur et l'écrase localement.
○ S'il n'y a aucune erreur, met à jour le fichier de version.

J'ai fait la taille du bloc de données un multiple de 1024 octets, après un certain nombre de tests, j'ai décidé qu'il était plus facile de fonctionner avec des blocs de 64 Ko. Bien que l'universalité du code demeure:

#region DQPatcher class public class DQPatcher { // some internal constants // 1 minute timeout by default private const int DEFAULT_NETWORK_TIMEOUT = 60000; // maximum number of compressed blocks, which we will download at once private const UInt16 MAX_COMPRESSED_BLOCKS = 1000; // default block size, you can use range from 4k to 64k, //depending on average size of your files in the project tree private const uint DEFAULT_BLOCK_SIZE = 64 * 1024; ... #region public constants and vars section // X * 1024 bytes by default for patch creation public static uint blockSize = DEFAULT_BLOCK_SIZE; ... #endregion .... 

Si vous réduisez les blocs, le client requiert moins de modifications lorsque les modifications elles-mêmes sont peu nombreuses. Cependant, un autre problème se pose - la taille du fichier d'index augmente inversement avec la diminution de la taille du bloc - c'est-à-dire si nous fonctionnons avec des blocs de 8 Ko, le fichier d'index sera 8 fois plus grand qu'avec des blocs de 64 Ko.

J'ai choisi SHA256 / 512 pour les fichiers et les blocs à partir des considérations suivantes: la vitesse diffère légèrement par rapport au (obsolète) MD5 / SHA128, mais vous devez toujours lire les blocs et les fichiers. Et la probabilité de collisions avec SHA256 / 512 est nettement moindre qu'avec MD5 / SHA128. Être complètement ennuyeux - c'est dans ce cas, mais il est si petit que cette probabilité peut être négligée.

De plus, le client prend en compte les points suivants:
► Les blocs de données peuvent être déplacés dans différentes versions, c'est-à-dire localement, nous avons le bloc numéro 10, et sur le serveur, nous avons le bloc numéro 12, ou vice versa. Ceci est pris en compte afin de ne pas télécharger de données supplémentaires.
► Les blocs ne sont pas demandés un par un, mais en groupes - le client essaie de combiner les plages des blocs nécessaires et les demande au serveur en utilisant l'en-tête Range. Cela minimise également la charge du serveur:

 // get compressed remote blocks of data and return it to the caller // Note: we always operating with compressed data, so all offsets are in the _compressed_ data file!! // Throw an exception, if fetching compressed blocks failed public byte[] GetRemoteBlocks(string remoteName, UInt64 startByteRange, UInt64 endByteRange) { if (verboseOutput) Console.Error.WriteLine("Getting partial content for [" + remoteName + "]"); if (verboseOutput) Console.Error.WriteLine("Range is [" + startByteRange + "-" + endByteRange + "]"); int bufferSize = 1024; byte[] remoteData; byte[] buffer = new byte[bufferSize]; HttpWebRequest httpRequest = (HttpWebRequest)WebRequest.Create(remoteName); httpRequest.KeepAlive = true; httpRequest.AddRange((int)startByteRange, (int)endByteRange); httpRequest.Method = WebRequestMethods.Http.Get; httpRequest.ReadWriteTimeout = this.networkTimeout; try { // Get back the HTTP response for web server HttpWebResponse httpResponse = (HttpWebResponse)httpRequest.GetResponse(); if (verboseOutput) Console.Error.WriteLine("Got partial content length: " + httpResponse.ContentLength); remoteData = new byte[httpResponse.ContentLength]; Stream httpResponseStream = httpResponse.GetResponseStream(); if (!((httpResponse.StatusCode == HttpStatusCode.OK) || (httpResponse.StatusCode == HttpStatusCode.PartialContent))) // rise an exception, we expect partial content here { RemoteDataDownloadingException pe = new RemoteDataDownloadingException("While getting remote blocks:\n" + httpResponse.StatusDescription); throw pe; } int bytesRead = 0; int rOffset = 0; while ((bytesRead = httpResponseStream.Read(buffer, 0, bufferSize)) > 0) { // if(verboseOutput) Console.Error.WriteLine("Got ["+bytesRead+"] bytes of remote data block."); Array.Copy(buffer, 0, remoteData, rOffset, bytesRead); rOffset += bytesRead; } if (verboseOutput) Console.Error.WriteLine("Total got: [" + rOffset + "] bytes"); httpResponse.Close(); } catch (Exception ex) { if (verboseOutput) Console.Error.WriteLine(ex.ToString()); PatchException pe = new PatchException("Unable to fetch URI " + remoteName, ex); throw pe; } return remoteData; } 

Bien sûr, il s'est avéré que le client peut être interrompu à tout moment et lors du lancement ultérieur, il poursuivra de facto son travail et ne téléchargera pas tout à partir de zéro.

Ici vous pouvez regarder une vidéo illustrant le travail du patcher sur le projet d'exemple Angry Bots:

À propos de l'organisation du patch de l'univers du jeu

En septembre 2015, Alex Koshelkov m'a contacté et m'a proposé de rejoindre le projet - ils avaient besoin d'une solution qui fournirait à 30 000 (avec une queue) de joueurs des mises à jour mensuelles. La taille initiale du jeu dans l'archive est de 600 mégaoctets. Avant de me contacter, il y avait eu des tentatives de faire votre propre version en utilisant Electron, mais tout s'est heurté au même problème de fichiers ouverts (à propos, la version actuelle d'Electron peut le faire) et quelques autres. De plus, aucun des développeurs n'a compris comment tout cela fonctionnerait - ils m'ont fourni plusieurs conceptions de vélos, la partie serveur était complètement absente - ils voulaient le faire après que toutes les autres tâches aient été résolues.

En outre, il était nécessaire de résoudre le problème de la prévention de la fuite des clés des joueurs - le fait est que les clés étaient destinées à la plate-forme Steam, bien que le jeu lui-même sur Steam ne soit pas encore accessible au public. La distribution du jeu était strictement requise par la clé - bien que les joueurs puissent partager la clé du jeu avec des amis, cela pourrait être négligé, car si le jeu apparaissait sur Steam, la clé ne pouvait être activée qu'une seule fois.

Dans la version normale du patcher, l'arborescence des données du patch ressemble à ceci:

 ./
 | - linux
 |  | - 1.0.0
 |  `- version.txt
 | - macosx
 |  | - 1.0.0
 |  `- version.txt
 `- fenêtres
     | - 1.0.0
     `- version.txt

Je devais m'assurer que seuls ceux avec la bonne clé avaient accès.

J'ai trouvé la solution suivante - pour chaque clé, nous obtenons son hachage (SHA1), puis nous l'utilisons comme chemin d'accès aux données de patch sur le serveur. Sur le serveur, nous transférons les données du correctif à un niveau supérieur à docroot et ajoutons des liens symboliques au répertoire avec les données du correctif dans le docroot lui-même. Les liens symboliques ont les mêmes noms que les hachages de touches, uniquement divisés en plusieurs niveaux (pour faciliter le fonctionnement du système de fichiers), c'est-à-dire le hachage 0f99e50314d63c30271 ... ... ade71963e7ff sera représenté comme

 ./0f/99/e5/0314d63c30271.....ade71963e7ff -----> / full / path / to / patch-data /.

Ainsi, il n'est pas nécessaire de distribuer les clés elles-mêmes à quelqu'un qui prendra en charge les serveurs de mise à jour - il suffit de transférer leurs hachages, qui sont absolument inutiles aux joueurs eux-mêmes.

Pour ajouter de nouvelles clés (ou supprimer les anciennes) - ajoutez / supprimez simplement le lien symbolique correspondant.

Avec cette implémentation, la vérification de la clé elle-même n'est évidemment effectuée nulle part; la réception de 404 erreurs sur le client indique que la clé est incorrecte (ou a été désactivée).

Il convient de noter que l'accès aux clés n'est pas une protection DRM à part entière - ce ne sont que des restrictions au stade des tests alpha et bêta (fermés). Et la recherche est facilement interrompue par le biais du serveur Web lui-même (au moins dans Nginx, que j'utilise).

Au cours du mois de lancement, seulement 2,5 To de trafic ont été livrés le premier jour seulement, et les jours suivants, environ le même montant est distribué en moyenne par mois:



Par conséquent, si vous prévoyez de distribuer beaucoup de contenu - il est préférable de calculer à l'avance combien cela vous coûtera. Selon des observations personnelles - le trafic le moins cher des hébergeurs européens, le plus cher (je dirais «or») d'Amazon et de Google.

En pratique, les économies de trafic par an en moyenne chez The Universim sont énormes - comparez les chiffres ci-dessus. Bien sûr, si l'utilisateur n'a pas de jeu du tout ou s'il est très obsolète, un miracle ne se produira pas et il devra télécharger beaucoup de données depuis le serveur - si à partir de zéro, alors un peu plus que le jeu ne prend dans les archives. Cependant, avec les mises à jour mensuelles, les choses vont vraiment bien. En moins de 6 mois, le miroir américain a donné un peu plus de 10 To de trafic, sans l'utilisation d'un patcher, cette valeur aurait considérablement augmenté.

Voici à quoi ressemble le trafic annuel du projet:



Quelques mots sur le "rake" le plus mémorable que nous avons dû franchir dans le processus de travail sur un patcher personnalisé pour le jeu "The Universim":

● Le plus gros problème m'attendait des antivirus. Eh bien, ils n'aiment pas les applications qui téléchargent quelque chose sur Internet, modifient les fichiers (y compris les fichiers exécutables), puis essaient également d'exécuter les fichiers téléchargés. Certains antivirus ne bloquaient pas seulement l'accès aux fichiers locaux - ils bloquaient également les appels au serveur de mise à jour eux-mêmes, pénétrant directement dans les données téléchargées par le client. La solution était d'utiliser une signature numérique valide pour le patcher - cela réduit considérablement la paranoïa des antivirus et l'utilisation du protocole HTTPS au lieu de HTTP - élimine rapidement certaines des erreurs associées à la curiosité des antivirus.

● Mise à jour des progrès. De nombreux utilisateurs (et clients) souhaitent voir la progression de la mise à jour. Il faut improviser, car il n'est pas toujours possible de montrer de manière fiable les progrès sans avoir à faire un travail supplémentaire. Oui, et l'heure exacte de la fin du processus de correction ne peut pas non plus être affichée, car le correctif lui-même ne dispose pas de données sur les fichiers qui doivent être mis à jour à l'avance.

● Un grand nombre d'utilisateurs des États-Unis ont des vitesses de connexion à des serveurs européens pas très élevées. La migration du serveur de mise à jour vers les États-Unis a résolu ce problème. Pour les utilisateurs d'autres continents, nous avons quitté le serveur en Allemagne. Soit dit en passant, le trafic aux États-Unis est beaucoup plus cher qu'européen, dans certains cas - plusieurs dizaines de fois.

● Apple n'est pas très à l'aise avec cette méthode d'installation des applications. Politique officielle - les applications doivent être installées uniquement à partir de leur magasin. Mais le problème est que les applications aux étapes de test alpha et bêta ne sont pas autorisées dans le magasin. Et plus encore, il n'y a rien à dire sur la vente d'applications brutes d'accès anticipé. Par conséquent, vous devez écrire des instructions sur la façon de danser sur les coquelicots. L'option avec AppAnnie (alors ils étaient encore indépendants) n'a pas été envisagée en raison de la limite du nombre de testeurs.

● La mise en réseau est assez imprévisible. Pour que l'application ne renonce pas immédiatement, j'ai dû entrer un compteur d'erreurs. 9 exceptions détectées vous permettent de dire fermement à l'utilisateur qu'il a des problèmes avec le réseau.

● Les systèmes d'exploitation 32 bits ont des restrictions sur la taille des fichiers affichés en mémoire (Memory Mapped Files - MMF) pour chaque thread d'exécution et pour le processus dans son ensemble. Les premières versions du patcher utilisaient MMF pour accélérer le travail, mais comme les fichiers de ressources de jeu peuvent être énormes, j'ai dû abandonner cette approche et utiliser des flux de fichiers ordinaires. Soit dit en passant, une perte de performances spéciale n'a pas été observée, probablement en raison de la lecture proactive du système d'exploitation.

● Vous devez être prêt à ce que les utilisateurs se plaignent. Peu importe la qualité de votre produit, il y en aura toujours qui ne seront pas satisfaits. Et plus il y a d'utilisateurs de votre produit (dans le cas de l'Universim, il y en a plus de 50 000 en ce moment) - plus vous aurez de plaintes quantitativement. En pourcentage, c'est un très petit nombre, mais en termes quantitatifs ...

Bien que le projet dans son ensemble ait été un succès, il présente certains inconvénients:

● Même si j'ai initialement retiré toute la logique principale séparément, la partie GUI est différente dans l'implémentation pour MAC et Windows. La version Linux n'a pas causé de problèmes - tous les problèmes étaient principalement liés à l'utilisation d'une construction monolithique qui ne nécessitait pas l'environnement d'exécution mono - MRE. Mais comme vous avez besoin d'une licence supplémentaire pour distribuer de tels fichiers exécutables, il a été décidé d'abandonner les versions monolithiques et de simplement exiger MRE. La version Linux ne diffère de la version Windows que par la prise en charge des attributs de fichier spécifiques aux systèmes * nix. Pour mon deuxième projet, qui sera plus qu'un simple patcher, je prévois d'utiliser une approche modulaire sous la forme d'un processus noyau qui s'exécute en arrière-plan et permet de tout gérer sur l'interface locale. Et le contrôle lui-même peut être effectué à partir d'une application basée sur Electron et similaires (ou simplement à partir d'un navigateur). Avec n'importe quelle petite chose. Avant de parler de la taille de la distribution de ces applications - regardez la taille des jeux. Les versions de démonstration (!!!) de certains occupent 5 gigaoctets ou plus dans l'archive (!!!).

● Les structures utilisées actuellement ne permettent pas d'économiser de l'espace lorsque le jeu est publié pour 3 plates-formes - de facto, vous devez conserver 3 copies de données presque identiques, bien que compressées.

● La version actuelle du patcher ne met pas en cache son travail - chaque fois que toutes les sommes de contrôle de tous les fichiers sont recalculées. Il serait possible de réduire considérablement le temps si le patcher mettait en cache les résultats des fichiers déjà présents sur le client. Mais il y a un dilemme - si le fichier est endommagé (ou manquant), mais l'entrée de cache pour ce fichier est enregistrée, le patcher l'ignorera, ce qui entraînera des problèmes.

● La version actuelle ne peut pas fonctionner simultanément avec plusieurs serveurs (sauf si vous effectuez un Round-robin en utilisant DNS) - je voudrais passer à une technologie de type torrent afin que vous puissiez utiliser plusieurs serveurs en même temps. Il n'est pas question d'utiliser les clients comme source de données, car cela pose de nombreux problèmes juridiques et il est plus facile de refuser dès le départ.

● Si vous souhaitez restreindre l'accès aux mises à jour, cette logique devra être implémentée indépendamment. En fait, cela peut difficilement être qualifié d'inconvénient, car chacun peut avoir ses propres souhaits concernant les restrictions. La restriction de clé la plus simple - sans aucune partie serveur - est rendue assez simple, comme je l'ai montré ci-dessus.

● Un correctif est créé pour un seul projet à la fois. Si vous souhaitez créer quelque chose de similaire à Steam, un système complet de distribution de contenu est déjà requis. Et c'est un projet d'un niveau complètement différent.

Je prévois de mettre moi-même le patcher dans le domaine public après la mise en œuvre de la «deuxième génération» - un système de livraison de contenu de jeu qui comprendra non seulement le patcher évolué, mais aussi un module de télémétrie (car les développeurs doivent savoir ce que font les joueurs), Module Cloud Save et quelques autres modules.

Si vous avez un projet à but non lucratif et avez besoin d'un patcher, écrivez-moi les détails de votre projet et je vous en donnerai une copie gratuitement. Il n'y aura pas de liens ici, car ce n'est pas le hub «I PR».

Je me ferai un plaisir de répondre à vos questions.