Comment fonctionnent les correctifs dans les jeux?

37

Les jeux sur console et sur PC ont parfois des correctifs pour corriger des bugs que les développeurs ont manqués / n'ont pas eu le temps de corriger.

Ma question est comment fonctionnent-ils?

Parfois, les fichiers de correctif ont une taille de quelques mégaoctets. Je ne comprends pas comment un petit fichier peut modifier un programme conforme.

console pc patching MulletDevil
la source
Vous souhaitez modifier un jeu compilé que vous avez créé avec un petit patch?
Wolfdawn
Non, je suis juste intéressé par la théorie derrière cela. Mes jeux sont assez petits pour les recompiler et les redistribuer à nouveau :)
MulletDevil
4
C'est une question intéressante. Ce n'est pas basé sur un problème que vous rencontrez avec la conception de jeux. Il existe également de nombreuses façons de traiter les correctifs de la manière la plus naïve, en remplaçant tous les fichiers modifiés par les plus complexes, en obtenant des instructions pour modifier des éléments spécifiques dans des fichiers existants. Je ne suis pas sûr que cette question convienne à ce site.
Wolfdawn
3
Quelques mégaoctets ne sont pas "petits". Supposons que nous ayons un fichier de trois mégaoctets, soit six mégaoctets de code exécutable, compressé. Supposons que les instructions ont une longueur moyenne de six octets, donc environ un million d'instructions. (Ignorons les données statiques telles que les littéraux de chaîne et tout le reste.) Si une ligne de C correspond à environ dix instructions machine, vous obtenez 100 000 lignes de code. Cela semble suffisant pour le moteur de base d'un jeu. La plupart de la taille de l’installation sera constituée de cartes de texture, d’écrans, de séquences vidéo.
2
quelques mégaoctets peuvent être petits, tout dépend de ce qu’il contient et du pourcentage de la base de code totale qui est. Si, disons, une carte de niveau 3D entière doit être remplacée à cause des formats de fichier choisis, etc., y compris toutes les textures et ce qui ne l'est pas, quelques mégaoctets peuvent être très petits.
Jwenting

Réponses:

30

Il y a plusieurs façons de le faire, le plus simple serait de XOR les deux fichiers et de les compresser (GZIP ou autres). La théorie derrière cela est que nous espérons pouvoir obtenir une grande séquence de zéros (les longues séquences des mêmes valeurs se compressent bien).

Vous pouvez approfondir ce concept et essayer de trouver les zones des deux fichiers où les données sont identiques et les omettre complètement.

Enfin, vous pouvez utiliser la structure de chaque type de fichier à votre avantage. Par exemple, dans un fichier EXE, vous pouvez conditionner chaque méthode individuellement (uniquement celles qui ont été modifiées) et reconstituer vous-même le fichier EXE lors de l'application du correctif; gardez à l’esprit, cependant, que c’est très probable dans le domaine de l’exploitation excessive et que cela ne vaut peut-être pas la peine de faire l’effort (le gain par rapport à un simple abonnement ne justifierait peut-être pas la complexité supplémentaire qui risquerait de se produire à l’état sauvage). Comme autre exemple, vous pouvez utiliser des fichiers diff pour les scripts.

Cependant, la plupart des systèmes de correctifs dans la nature empruntent la voie la plus simple: ils regroupent simplement les fichiers qui ont été modifiés - ils ne tentent pas uniquement de regrouper les modifications au sein de ces fichiers (probablement pour une bonne raison, le contenu du jeu est déjà compressé et la création de correctifs l'entropie ou les données compressées ne fonctionneront pas du tout ).

Jonathan Dickinson
la source
Qu'entendez-vous par package chaque méthode dans un exe individuellement? Est-ce pratique?
Wolfdawn
@ ArthurWulfWhite oui. Pour une maison indépendante, cela ne vaut probablement pas la peine, car cela prendrait énormément de temps et d’efforts (vous devez essentiellement écrire votre propre éditeur de liens) - en tant qu’entreprise spécialisée dans la «technologie de correction», cela en vaudrait vraiment la peine. Tout dépend de la taille du code exécutable - j'ai jeté un coup d'œil à Sacred 2 et il faisait 26 Mo (8 Mo pour l'EXE principal). Un diff binaire pourrait toutefois s'en approcher - c'est néanmoins une idée qui mérite d'être mise en avant (je sais que les CAB obtiennent une bonne compression sur les fichiers EXE car ils tirent parti de la structure).
Jonathan Dickinson
C'est très intéressant. Je suppose que la bande passante étant ce qu’elle est aujourd’hui, minimiser la taille des correctifs de jeu n’est pas un problème majeur. +1 une réponse intéressante et bien pensée.
Wolfdawn
Il n’est pas faisable d’appliquer des méthodes individuelles dans la plupart des jeux. Le compilateur peut avoir une sortie assez différente, même avec de simples modifications de code. Les décisions automatiques en ligne peuvent changer, la structure de la table des symboles peut être modifiée, etc. Les modifications de code modifient également souvent la structure interne de l'API. Les optimisations brouillent déjà la frontière entre les limites des fonctions par rapport à ce que vous voyez dans votre éditeur de code. Les systèmes DRM brouillent également beaucoup l'eau. Les systèmes de correctifs utilisent des différences en gros de remplacement ou binaires et les compressent. Tout ce que vous suggérez est simplement trop fragile pour être expédié dans le monde réel, imo.
Sean Middleditch
2
@SeanMiddleditch Je vais le faire juste pour prouver que c'est possible :).
Jonathan Dickinson
15

Le code exécutable d'un jeu ne réside pas toujours dans l'exécutable, il est souvent divisé en plusieurs bibliothèques dynamiques (par exemple, le jeu, les graphismes et les moteurs de son), l'exécutable réel et éventuellement de nombreux scripts à des fins diverses.

Un correctif peut résoudre des problèmes dans l'une quelconque de ces parties sans garantir de modification dans chacune d'entre elles.

Une approche différente de celle consistant à remplacer tous les fichiers modifiés pourrait consister à simplement faire un diff binaire sur eux et à ne compacter que les différences réelles à redistribuer.

(Cela ne fonctionnera bien sûr que sur les fichiers dont vous pouvez être sûr qu'ils ne seront pas modifiés par l'utilisateur.)


la source
2
Vous pouvez citer ceci à titre d'exemple: daemonology.net/bsdiff
wolfdawn
2
Bonne réponse pratique. +1
wolfdawn
2

Normalement, ils utilisent un système de diff binaire tiers pour distribuer les correctifs aux données du jeu. Les exécutables sont généralement assez petits pour être distribués de manière triviale.

La plupart des jeux modernes ont des centaines de Mo de données de jeu (principalement des textures, des modèles, des niveaux de données, etc.). Ceux-ci nécessitent des correctifs assez souvent. Autant que je sache, les éditeurs disposent normalement d'une méthode standard pour y parvenir.

Inutile de dire qu'il existe des exemples open-source. Certaines distributions Linux (Fedora?) Utilisent des différences binaires pour leurs correctifs. Vous pouvez les étudier et lire leur code source ou leur documentation.

MarkR
la source
-1

Les diffalgorithmes modernes peuvent efficacement trouver des séquences d’octets communes entre deux fichiers binaires. Sans surprise, si vous y réfléchissez. La compression de fichier repose également sur la recherche de séquences d'octets identiques.

Une fois que vous avez la liste des séquences d'octets identiques, il ne vous reste plus qu'à envoyer les décalages anciens et nouveaux, leur longueur et bien sûr tout ce qui est complètement nouveau. Du côté de la réception, il s’agit alors d’un assemblage simple. Copiez les bits que vous devez conserver de l'ancien fichier, remplissez les nouveaux bits.

La création du patch devient encore plus facile si votre éditeur de liens peut créer un fichier MAP qui répertorie les décalages de chaque fonction du fichier.

MSalters
la source