Ceci est le guide d'utilisation de SteamPipe, l'outil de Valve pour la livraison de contenu sur Steam. Pour en savoir plus sur les pratiques recommandées pour une mise à jour de votre jeu, veuillez consulter
Bonnes pratiques pour les mises à jour de votre jeu.
Introduction au système de contenu SteamPipe
SteamPipe constitue le système de contenu de jeu/d'application alimentant Steam. SteamPipe inclut les fonctionnalités suivantes.
- Livraison de contenu efficace et rapide.
- Branches « bêta » publiques et privées, permettant de tester plusieurs versions.
- Gestion des versions simple et basée sur le Web : sortez une nouvelle version ou revenez à une ancienne en quelques clics.
- Capacité de voir la taille de mise à jour d'une version avant de la mettre en ligne.
- Capacité de partage du contenu entre plusieurs applications.
- Capacité à créer des disques d'installation en utilisant du contenu public ou en bêta.
- Les jeux ou applications sont toujours disponibles hors ligne même après qu'une mise à jour a démarré.
- Tout le contenu est toujours chiffré, et les versions non actives sont invisibles de la clientèle.
- Un Serveur de contenu local SteamPipe pouvant être utilisé durant le développement.
REMARQUE : il existe des concepts faisant partie intégrante de SteamPipe, et nous vous recommandons de vous familiariser avec ceux-ci en consultant l'article de la documentation
Applications avant de commencer. Acquérir ne serait-ce que quelques connaissances de base quant à cette logique de fonctionnement vous sera très utile lorsque vous publierez votre produit sur Steam.
Structure du contenu de jeu : bonnes pratiques
SteamPipe a été conçu pour une prise en charge optimale du téléchargement d'installation initial d'un jeu ou de l'application de correctifs lors de mises à jour. Il fonctionne généralement bien avec une grande variété de structures de contenu de jeu. Cependant, il est important de connaitre certaines choses pour en optimiser les performances et éviter des situations contreproductives.
Remarque : si votre jeu utilise le moteur
Unreal Engine, veuillez consulter les remarques relatives à ces paquets à la fin de cette section.
SteamPipe commence par diviser chaque fichier en morceaux d'environ un mégaoctet (Mo) chacun. Chaque morceau est ensuite compressé et chiffré avant d'être distribué par le système de livraison de contenu Steam. Il reste compressé et chiffré jusqu'à ce qu'il soit téléchargé sur chaque client, où il est déchiffré et décompressé pour être placé dans le(s) bon(s) fichier(s).
Quand SteamPipe traite une mise à jour d'un jeu existant, il recherche tous les morceaux qui correspondent potentiellement à la version précédente du jeu. Ainsi en principe, seules les nouvelles portions ou celles qui ont été modifiées sont découpées en « nouveaux » morceaux, et ceux-ci seront les seuls éléments à être téléchargés pour la mise à jour du jeu.
De nombreux moteurs de jeu utilisent des fichiers « paquets » pour réunir les ressources graphiques d'un jeu et améliorer les temps de chargement grâce à un accès au disque plus efficace. En général, ceci fonctionne bien avec SteamPipe. Cependant, certains systèmes de paquets utilisent ou permettent certaines fonctionnalités qui peuvent poser problème. Celles-ci peuvent entrainer des mises à jour plus grosses que nécessaire. Elles peuvent aussi déboucher sur des téléchargements rapides, mais un processus de mise à jour laborieux dû à la grande quantité nécessaire d'E/S sur le disque local.
Si votre jeu utilise des paquets, veuillez consulter ces recommandations générales.
- Vérifiez que les ressources modifiées se trouvant à l'intérieur du paquet ont été autant que possible traduites ou adaptées aux marchés locaux.
- Évitez de chambouler l'ordre des ressources dans le paquet.
- Limitez la taille du paquet.
- Groupez les ressources par niveau/domaine/fonctionnalité dans leurs propres paquets dédiés et pensez à ajouter de nouveaux paquets pour les mises à jour, au lieu de modifier les paquets existants.
- N'incluez pas de noms des archives originales ni d'estampilles temporelles des archives/versions précédentes pour aucune des ressources.
La première mention ci-dessus correspond à l'incidence des octets modifiés dans une archive quand une seule ressource a été changée. Le scénario idéal serait que les données de cette ressource aient été modifiées au même endroit dans le paquet, et/ou que celle-ci y prenne plus ou moins de place. SteamPipe crée alors seulement de nouveaux morceaux pour les portions du fichier qui contiennent les données de la ressource. Toutefois, tous les paquets nécessitent aussi une sorte de table des matières afin que le moteur de jeu puisse localiser les données de la ressource. La structure de cette table des matières peut avoir un impact important sur les performances de SteamPipe en mode application de correctifs. Pour bien faire, il devrait y avoir une table des matières ou une arborescence des matières près du début et de la fin de l'archive. Parce que d'autres ressources risquent de voir leur position changer en nombre d'octets dans le fichier, leurs entrées dans la table des matières seront elles aussi modifiées. Dans cette situation, SteamPipe va créer de nouveaux morceaux pour les données de la ressource changée et pour les portions modifiées de la table des matières.
Nous avons cependant remarqué que dans certains moteurs de jeu, les informations liées à la table des matières sont éparpillées dans toute l'archive. Pire encore, elles utilisent des valeurs absolues pour le décalage d'octets. Ainsi, si la taille d'une ressource de 3 450 octets augmente de 8 octets, alors les valeurs de décalage pour toutes les ressources qui la suivent vont être modifiées. Même si chaque valeur de décalage ne fait que 4 ou 8 octets de grandeur, la modification d'un nombre à 8 octets provoquera la création d'un nouveau morceau de 1 Mo par SteamPipe. Ceci peut entrainer des effets catastrophiques quand le changement de quelques petites ressources dans un paquet impose aux clients de télécharger plus de la moitié de l'archive entière à mettre à jour. Si vous pensez ou soupçonnez que la structure de votre paquet provoque ce problème, veuillez contacter Valve au plus vite. Nous avons un algorithme de génération de version différent qui pourra peut-être permettre de réduire le problème, malgré quelques inconvénients.
De plus, SteamPipe ne reconnait pas les points de démarcation des ressources dans un paquet. Si des ressources plus petites qu'un mégaoctet sont déplacées, SteamPipe risque de ne pas pouvoir détecter ce réagencement, car les morceaux d'un mégaoctet déterminés précédemment ne seront plus présents dans l'archive. Par conséquent, si lors de l'élaboration de la mise à jour pour votre jeu, vous souhaitez optimiser les temps de chargement en réagençant les ressources dans le paquet, n'oubliez pas que cela risque d'alourdir le téléchargement. Nous ne recommandons de suivre cette voie que si cela mène à des performances notablement améliorées.
Ensuite, pour mettre à jour le paquet sur l'appareil du client, SteamPipe crée une nouvelle version à côté de l'ancienne. Quand tous les fichiers sont créés, il « engage » la mise à jour en supprimant les anciens fichiers pour les remplacer par les nouveaux. Cela signifie que pour mettre à jour un paquet de 25 Go, SteamPipe crée systématiquement un nouveau fichier de 25 Go. Si la mise à jour ne nécessite que 10 octets pour modifier le fichier, SteamPipe devra copier presque l'intégralité des 25 Go de l'archive dans le nouveau fichier. En fonction du matériel de stockage du client, cette opération peut s'avérer très lente. C'est pourquoi nous recommandons de suivre les deux points suivants.
Premièrement, limitez la taille des paquets. Un ou deux gigaoctets (Go) suffisent probablement. Ceci est plus que suffisant pour permettre une lecture efficace par le disque quand le jeu se charge.
Deuxièmement, limitez la place que prennent les ressources dans chaque fichier du paquet. Par exemple, un seul niveau de jeu, ou une fonctionnalité indébloquable suffit pour un fichier. Ainsi, les mises à jour qui ciblent des sections spécifiques de votre jeu ne provoquent pas la duplication de données d'autres sections dans d'autres zones du PC client. Quand vous ajoutez de nouvelles fonctionnalités, niveaux ou autre, il est recommandé de les placer dans leurs propres fichiers de paquet. Les clients qui téléchargeront cette mise à jour n'auront qu'à effectuer un simple téléchargement des nouveaux fichiers et éviteront les problèmes d'archives modifiées mentionnés plus haut.
Si vous nourrissez le moindre doute, utilisez un outil comme Beyond Compare mettant en exergue les différences entre des fichiers binaires en local, vous permettant ainsi de comparer vos fichiers de paquet. Veuillez vérifier que les différences rapportées sont de taille appropriée pour les ressources modifiées, et qu'il n'y a pas des dizaines, voire des centaines de petites modifications éparpillées dans le fichier. Si ce que vous voyez n'est pas le résultat attendu, vérifiez les paramètres de l'outil des fichiers paquets.
Compression : Steam compresse toutes les données pour le chargement/stockage/téléchargement de toutes les données, c'est pourquoi nous déconseillons l'utilisation de techniques de compression générale pour les paquets. Cependant, si la taille de votre jeu sur disque vous inquiète, il n'est pas interdit d'utiliser la compression pour les fichiers paquets. Cela fonctionnera correctement avec SteamPipe à la condition que les critères suivants soient respectés. Plus précisément, vous devez vous assurer que la compression soit effectuée séparément pour chaque ressource autant que possible. Toute compression qui traverse les points de démarcation des ressources dissémine les modifications et oblige les clients à télécharger plus de données que nécessaire.
Cryptage : tout comme la compression, il est très probablement superflu et comporte les mêmes risques que ceux mentionnés ci-dessus.
En suivant ces règles, vous pourrez réduire la taille de vos correctifs, et permettre au public de ne télécharger que le nouveau contenu. Votre clientèle vous en saura gré, et vous pourrez également publier plus de mises à jour, augmentant ainsi la qualité de votre produit.
Si vous pensez que l'empaquetage de votre jeu comporte des problèmes de compatibilité avec le processus de mise à jour de SteamPipe, veuillez contacter Valve. Nous étudierons comment activer certaines fonctionnalités avancées pour vous aider.
Unreal Engine – Remarques spécifiques
Certaines versions d'Unreal Engine utilisent l'« alignement de remplissage » (padding alignment) de la ressource pour les paquets qui peuvent avoir un impact très important sur la taille des mises à jour de SteamPipe. Cet alignement peut entrainer des décalages en cascade des ressources lors de la création de nouvelles versions, en particulier si la compression des paquets est activée. En utilisant un alignement de remplissage de 1 Mo (1 048 576 octets), on s'assure que les réalignements décaleront les ressources selon un multiple de la même taille de bloc que celle utilisée par SteamPipe pour les calculs de delta.
Par exemple, pour modifier ou spécifier l'alignement du remplissage pendant la phase de « cuisson » (cooking en anglais) des fichiers du paquet du jeu, vous devez modifier une ligne dans le fichier
UnrealEngine/Engine/Source/Programs/AutomationTool/Win/WinPlatform.Automation.cs
. Ce fichier contient la fonction
GetPlatformPakCommandLine
. Au sein de cette dernière, changez cette ligne :
string PakParams = " -patchpaddingalign=2048";
en
string PakParams = " -patchpaddingalign=1048576 -blocksize=1048576";
Grâce à ce changement, vous serez en mesure de compresser le paquet de fichiers tout en gardant un comportement optimisé pour SteamPipe.
Unreal Engine est une marque d'Epic et une marque déposée aux États-Unis et dans le monde.Tutoriel vidéo Steamworks : créer votre jeu dans SteamPipe
Ce tutoriel présente SteamPipe et décrit les étapes nécessaires à la création d'une application modèle pour Steam au moyen des outils Steamworks.
https://www.youtube.com/watch?v=SoNH-v6aU9QTutoriel vidéo Steamworks : ajouter des plateformes et des langues
Ce tutoriel vous explique comment ajouter des plateformes et des langues à votre jeu en ajoutant des dépôts supplémentaires à votre application.
https://www.youtube.com/watch?v=PShS32hcingDétails techniques SteamPipe
SteamPipe utilise le protocole HTTP pour toute livraison de contenu. Les téléchargements étant considérés comme un flux de données classique, tout cache HTTP tiers entre le client et les serveurs Steam augmentera le débit du téléchargement. Le contenu peut être hébergé par des services de RDC (réseau de distribution de contenu) externes, qui peuvent être facilement ajoutés à notre réseau de contenu. La plupart des pare-feux destinés au grand public autorisent les échanges de flux HTTP et ne bloqueront donc pas les téléchargements.
SteamPipe dispose d'un algorithme de mise à jour optimisé basé sur les différences binaires. Celui-ci change uniquement les portions de fichiers modifiées par rapport au contenu existant. Lorsque ce contenu est mis à jour, seules ces différences doivent être envoyées. Ainsi, la clientèle et les équipes de développement bénéficient ensemble de transferts de données plus légers et plus rapides. La plupart de nos partenaires ne voient pas la nécessité d'utiliser un
Serveur de contenu local SteamPipe puisqu'il est aisé de corriger les builds d'application sur les branches privées.
Compte de build Steam
Avant de pouvoir créer des builds sur Steam, vous devez posséder un compte Steam dans votre compte Steamworks où les permissions pour « Modifier les métadonnées de l'application » et « Publier les changements de l'app sur Steam » sont données. Pour des raisons de sécurité, il est recommandé de posséder un compte dédié au build disposant uniquement de ces permissions. Pour cela, vous pouvez créer un nouveau compte Steam sur :
https://store.steampowered.com/join.
Toute personne administratrice de votre compte Steamworks peut ajouter un compte Steam et donner les permissions nécessaires. Plus d'informations à ce sujet sont disponibles dans l'article de la documentation
Gérer votre compte Steamworks. Voici un exemple de ce à quoi peut ressembler un tel compte :
Remarque : si un compte Steam décide de mettre en ligne un build pour une application publiée, il devra fournir le numéro de téléphone ou l'application Steam Mobile qui lui sont associés. Ces méthodes seront utilisées pour confirmer la mise en ligne d'un build pour une application publiée. De plus, si le compte Steam effectue des modifications relatives à sa sécurité (changement d'e-mail, de numéro de téléphone, etc.), vous devrez attendre 3 jours avant de pouvoir mettre en ligne le build d'une application publiée. Cette mesure a été mise en place afin d'empêcher que des comptes compromis puissent gérer les builds publiés de votre application.
Paramétrage d'origine pour les nouvelles applications SteamPipe
Suivez ces étapes afin de paramétrer de nouvelles applications SteamPipe.
- Identifiez l'ID de votre application (cette information est disponible en sélectionnant votre application sur votre page d'accueil de Steamworks)
- Allez sur la page des paramètres généraux d'installation pour votre application.
- Définissez au moins une option de démarrage (chemin et éventuellement tout argument nécessaire au démarrage). Passez votre souris sur le (?) pour en apprendre plus sur chaque champ de saisie.
L'exemple ci-dessous illustre 5 options de démarrage : 2 pour Windows, 2 pour macOS et une pour Linux.
L'option de démarrage n° 3 n'illustrera que le cas sur Windows où la personne possède aussi le DLC spécifié.
- Rendez-vous sur la page des dépôts et ajoutez les dépôts nécessaires à cette application. Un dépôt est peut-être déjà configuré par défaut pour votre application.
- Cliquez sur le dépôt par défaut et changez son nom en un nom correct et identifiable (tel que « Contenu de base » ou encore « Contenu Windows »).
- À moins qu'il ne s'agisse d'un dépôt d'une langue spécifique, laissez le réglage de langue sur [Toutes les langues].
- À moins qu'il ne s'agisse d'un dépôt relatif à un système d'exploitation spécifique, laissez le réglage de système d'exploitation sur [Tous les OS] (si l'application est tout-en-une, ou uniquement conçue pour PC ou pour Mac, laissez également le réglage [Tous les OS]). Renseignez simplement en cas de dépôt relatif à un système d'exploitation en particulier.
- Cliquez sur Ajouter un nouveau dépôt pour créer des dépôts supplémentaires.
- Cliquez sur Sauvegarder les modifications pour sauvegarder toute modification effectuée.
- Une fois vos dépôts définis, publiez les modifications effectuées depuis la page de publication.
- Vos dépôts modifiés devront être inclus dans un package pour que vous en soyez propriétaire. Chaque jeu sur Steam devrait avoir un package de type « Developer Comp », automatiquement distribué à tous les comptes listés dans votre groupe de publication.
Vous pouvez ajouter de nouveaux dépôts à ce package (et/ou à d'autres packages nécessitant ces dépôts) sur la page des packages et DLC associés.
Remarque : si votre exécutable se trouve dans un sous-dossier du répertoire d'installation principal, ajoutez le nom du sous-dossier dans le champ « Exécutable ». N'utilisez pas de barres obliques ni de points.
Remarque concernant la plateforme : comme indiqué plus haut, il est possible de démarrer les applications macOS soit à partir d'un bundle d'application (Game.app) ou d'un script/binaire (Game.app/Contents/MacOS/Game). En général, le format du bundle d'application est préférable, puisqu'il permet à macOS de déterminer plus correctement les paramètres de démarrage comme si le jeu était lancé manuellement à l'extérieur de Steam.
Paramétrer le kit de développement pour les téléchargements SteamPipe
Téléchargez et décompressez la dernière version du SDK Steamworks sur l'ordinateur que vous prévoyez d'utiliser pour mettre en ligne les builds.
Les outils SteamPipe se trouvent dans le kit de développement, à l'intérieur du répertoire
tools
(et des deux sous-répertoires concernés).
Le répertoire
ContentBuilder
contiendra votre jeu et les outils de SteamPipe. Le répertoire comprend les sous-répertoires suivants.
- builder : ce répertoire ne contient initialement que steamcmd.exe, qui constitue la version ligne de commande de Steam.
- builder_linux : version Linux de steamcmd.
- builder_osx : version macOS de steamcmd.
- content : ce répertoire contient tous les fichiers du jeu destinés à être intégrés dans les dépôts.
- output : ce répertoire constitue l'emplacement de destination des journaux de build, du cache des fichiers morcelés, et de la sortie intermédiaire. REMARQUE : ce répertoire peut être vidé ou supprimé à tout moment, mais sa suppression rallongera le temps nécessaire à la prochaine mise en ligne.
- scripts : ce répertoire constitue l'emplacement des scripts de builds destinés à créer les dépôts du jeu.
Il est recommandé d'exécuter une première fois steamcmd.exe directement dans le dossier « builder » correspondant à votre plateforme afin d'amorcer votre système de build. Ce procédé devrait remplir le répertoire « builder » avec tous les fichiers nécessaires à la création de dépôts.
Le répertoire
ContentServer
contient les outils nécessaires à l'exploitation de votre propre
Serveur de contenu local SteamPipe, le cas échéant.
SteamCmd sur macOS
Les étapes suivantes sont nécessaires pour activer SteamCmd sur macOS :
- depuis le terminal, accédez au dossier tools\ContentBuilder\builder_osx ;
- exécutez chmod +x steamcmd ;
- saisissez bash ./steamcmd.sh ;
- SteamCmd s'exécutera alors et sera mis à jour, ensuite l'invite de commande SteamCmd s'affichera ;
- saisissez « exit » et appuyez sur Entrée afin de quitter l'invite.
Vous pouvez ensuite vous référer au reste de la documentation (en remplaçant les chemins d'accès en conséquence) pour créer des dépôts et des fichiers de configuration d'application afin de mettre en ligne votre contenu sur Steam.
Créer des fichiers de configuration de build SteamPipe
Afin de mettre en ligne les répertoires pour votre application avec SteamPipe, vous devez créer des scripts décrivant votre build et les dépôts qui s'y trouvent. Les scripts montrés en exemple ici se trouvent dans le répertoire
Tools\ContentBuilder\scripts
dans le SDK Steamworks.
Outil d'interface graphique SteamPipe
Si vous utilisez Windows et que vous préférez utiliser une interface graphique pour créer ces fichiers de configuration et mettre vos builds en ligne, vous pouvez utiliser l'interface SteamPipe, disponible dans le dossier « tools » du SDK Steamworks. Dans le dossier compressé, vous trouverez des indications supplémentaires sur son fonctionnement.
Même si vous choisissez d'utiliser l'outil d'interface graphique, il est recommandé de lire les chapitres suivants afin de vous familiariser avec le fonctionnement du système SteamPipe.
Script de build simple
Commençons avec un script de build aussi simple que possible. Dans notre exemple, nous avons un jeu (AppID 1000) contenant un dépôt (DepotID 1001) et nous souhaitons mettre en ligne tous les fichiers se trouvant dans un répertoire de contenu, ainsi que tous ses sous-répertoires. À cet effet, il nous faut seulement un script de build. Regardez le répertoire
"simple_app_build.vdf"
, inclus dans le SKD :
"AppBuild"
{
"AppID" "1000" // Votre AppID.
"Desc" "This is a simple build script" // Description interne de ce build.
"ContentRoot" "..\content\" // Répertoire de contenu racine, en fonction de l'emplacement de ce dossier.
"BuildOutput" "..\output\" // Dossier de sortie du build pour ses journaux et ses fichiers de cache.
"Depots"
{
"1001" // Votre ID de dépôt.
{
"FileMapping"
{
"LocalPath" "*" // Tous les fichiers du répertoire de contenu racine.
"DepotPath" "." // Mappés dans la racine du dépôt.
"recursive" "1" // Inclut tous les sous-répertoires.
}
}
}
}
Ajustez l'AppID et l'ID de dépôt de votre jeu si besoin. Pour démarrer un build, vous devez exécuter steamcmd et passer quelques paramètres :
tools\ContentBuilder\builder\steamcmd.exe +login <account_name> <password> +run_app_build ..\scripts\simple_app_build.vdf +quit
Un build SteamPipe comprend les étapes suivantes.
- steamcmd.exe s'actualisera tout seul avec la dernière mise à jour.
- steamcmd.exe se connecte à l'interface Steam à l'aide du compte de build Steam renseigné.
- Le démarrage de création de l'application est inscrit sur le MDS (serveur de dépôt maitre), qui s'assure que le compte dispose des privilèges nécessaires à la modification de l'application.
- Une liste de fichiers est générée pour chaque dépôt inclus dans le build de l'application ; celle-ci est basée sur les fichiers du répertoire de contenu et sur les règles de filtrage définies dans le fichier de configuration de création de dépôt.
- Chaque fichier est scanné et divisé en morceaux d'environ 1 Mo. Si le dépôt a déjà été créé, ce partitionnement modifiera aussi peu de morceaux que possible.
- Les morceaux nouvellement créés sont compressés, chiffrés, puis téléchargés vers le MDS.
- Un ultime manifeste est généré pour cette version de dépôt. Chaque manifeste est identifié par un ID de manifeste unique à 64 bits.
- Une fois tous les dépôts traités, le MDS finalise le build et lui assigne un ID de build global.
- Une fois le build terminé, des fichiers d'extension .csm et .csd peuvent se trouver dans le fichier de sortie du build. Ils sont temporaires et peuvent être supprimés. Toutefois, les conserver permettra d'accélérer les prochains builds.
Quand le build est fin prêt, il va apparaitre sur la page des builds de votre application. Dans ce cas-ci, ici :
https://partner.steamgames.com/apps/builds/1000. Placez-y le build pour la branche par défaut ou n'importe quelle branche bêta. Les utilisatrices et les utilisateurs pourront télécharger cette mise à jour en quelques minutes.
Scripts de builds avancés
Si votre application comporte beaucoup de dépôts aux règles de mapping de fichiers complexes, vous pouvez créer un script de build de construction de dépôt pour chaque dépôt, qui sera référencé par le script de création de l'application. Regardons d'abord les paramètres disponibles dans le script de création de l'application.
-
AppID :
AppID de votre jeu ; le compte partenaire Steam chargé du chargement doit avoir les privilèges « Modifier les métadonnées de l'app ».
-
Desc
: la description n'est visible que pour vous dans la section « Vos builds » dans l'onglet « Application » du panneau d'administration. Ceci peut être changé à tout moment après le chargement d'un build sur votre page « Vos builds ».
-
ContentRoot :
dossier racine des fichiers de votre jeu, il peut constituer un chemin absolu ou être relatif au fichier de script de build.
-
BuildOutput :
ce répertoire constitue l'emplacement de destination des journaux de build, du cache des fichiers morcelés, et de la sortie intermédiaire. Pour des performances optimales, utilisez un disque séparé pour la sortie de votre build. Ceci divise la charge de travail des E/S, ce qui permet au disque racine du contenu de prendre en charge les demandes de lecture et au disque de sortie de se charger des demandes d'écriture.
-
Preview :
ce type de build ne produit que des journaux d'évènements et un manifeste des fichiers dans le dossier de sortie du build. Créer des aperçus de builds est une bonne façon d'itérer sur vos scripts de mise en ligne et de vérifier que les configurations, filtres et propriétés de vos fichiers fonctionnent correctement.
-
Local :
définissez ce paramètre sur le chemin htdocs de votre Serveur de contenu local SteamPipe. Les builds de serveurs de contenu local (LCS) permettent la mise en ligne sur votre propre serveur HTTP et le test de l'installation de votre jeu à l'aide du client Steam.
-
SetLive :
nom de la branche bêta qui sera publiée automatiquement après succès du build, aucun succès s'il reste vide. Veuillez noter que la branche « par défaut » ne peut pas être publiée automatiquement. Pour le faire, rendez-vous dans le panneau d'administration de l'application.
-
Depots :
cette section contient toutes les configurations de vos fichiers, ainsi que leurs filtres et propriétés pour chaque dépôt, ou elle fait référence à un fichier de script séparé pour chacun.
Cet exemple de script de création d'application
"app_build_1000.vdf"
utilise toutes les options :
"AppBuild"
{
"AppID" "1000" // Votre AppID.
"Desc" "Your build description here" // Description interne de ce build.
"Preview" "1" // Le définit comme build d'aperçu, rien ne sera mis en ligne.
"Local" "..\..\ContentServer\htdocs" // Met le contenu sur le serveur de contenu local au lieu de le mettre en ligne sur Steam.
"SetLive" "AlphaTest" // Publie ce build sur une branche bêta.
"ContentRoot" "..\content\" // Répertoire racine du contenu lié à ce dossier de script.
"BuildOutput" "D:\build_output\" // Met le cache du build et les fichiers journaux sur un lecteur différent pour une meilleure optimisation.
"Depots"
{
// Les instructions de configuration des fichiers pour chaque dépôt sont dans des fichiers de script séparés.
"1001" "depot_build_1001.vdf"
"1002" "depot_build_1002.vdf"
}
}
Ce script de génération d'application fait référence à deux fichiers de script de création de dépôts qui spécifient toutes les configurations des fichiers et leurs propriétés. Les instructions suivantes peuvent être consultées dans un script de création de dépôt (et aussi si la section est directement incluse dans le script de création d'application).
-
DepotID
: l'ID du dépôt pour cette section.
-
ContentRoot
: vous permet facultativement de remplacer le répertoire ContentRoot du script de création de l'application dépôt par dépôt.
-
FileMapping
: mappe un fichier unique ou un ensemble de fichiers depuis la racine de contenu local jusqu'à votre dépôt. De multiples mappings de fichiers peuvent ajouter des fichiers au dépôt. Le paramètre LocalPath
est un chemin relatif jusqu'au répertoire de contenu racine et peut contenir des caractères de remplacement comme « ? » ou « * ». Il s'appliquera aussi aux fichiers correspondants dans les sous-répertoires si Recursive
est activé. Le paramètre DepotPath
indique où les fichiers sélectionnés devraient apparaitre dans le dépôt (utilisez uniquement « . » si aucun mapping spécial n'est demandé).
-
FileExclusion
: exclut à nouveau les fichiers mappés et peut aussi contenir des caractères de remplacement comme « ? » ou « * ».
-
InstallScript
: marque un fichier comme script d'installation et signe le fichier pendant le processus de génération. Le client Steam sait comment les exécuter pour toutes les applications installant ce dépôt.
-
FileProperties
: marque un fichier avec des indicateurs spéciaux.
-
userconfig
: ce fichier est modifié par le jeu ou la personne qui l'utilise. Il ne peut être écrasé par une mise à jour et ne déclenchera pas d'erreur de vérification s'il est différent des versions antérieures du fichier.
-
versionedconfig
: similaire à userconfig, cependant si le dossier est mis à jour dans le dépôt, il sera remplacé localement quand le jeu se mettra à jour. Ne mettez à jour le fichier dans le dépôt que quand il y a une modification de format ou un correctif qui doivent être appliqués.
Exemple de script de création de dépôt
depot_build_1002.vdf
qui illustre l'utilisation de toutes les options :
"DepotBuild"
{
"DepotID" "1002"
"ContentRoot" "C:\content\depot1002" // Remplace ContentRoot du script de création de l'application.
"FileMapping"
{
// Tous les fichiers et répertoires source dans ".\bin" seront mappés dans le répertoire ".\executables" dans le dépôt.
"LocalPath" "bin\*"
"DepotPath" "executables\"
"Recursive" "1" // Inclut tous les sous-répertoires.
}
"FileMapping"
{
// Remplace les fichiers audio dans \\audio avec les versions allemandes.
"LocalPath" "localization\german\audio\*"
"DepotPath" "audio\"
}
"FileMapping"
{
// Copie le script d'installation pour la version allemande dans le répertoire du dépôt racine.
"LocalPath" "localization\german\german_installscript.vdf"
"DepotPath" "."
}
"FileExclusion" "bin\server.exe" // Exclut ce fichier.
"FileExclusion" "*.pdb" // Exclut tous les fichiers .PDB partout.
"FileExclusion" "bin\tools*" // Exclut tous les fichiers sous bin\tools\.
"InstallScript" "localization\german\german_installscript.vdf"
"FileProperties"
{
"LocalPath" "bin\setup.cfg"
"Attributes" "userconfig" // Ce fichier sera modifié pendant l'exécution.
}
}
REMARQUE : vous pouvez renommer ces scripts à votre guise, mais nous utilisons les noms
app_build_<AppID>
et
depot_build_<DepotID>
par souci de cohérence. Si vous prévoyez de créer des applications sur cette machine, créer des sous-répertoires dans le répertoire « scripts » pour chaque application pourrait s'avérer utile, afin de faciliter l'organisation des scripts de chaque application.
Utilisation de SteamPipe dans un environnement CI/CD
Afin de configurer steamcmd pour une intégration continue, sur un ordinateur ou encore sur un ordinateur virtuel dont l'image sera recréée fréquemment, il est nécessaire d'inclure le fichier de configuration contenant le jeton de connexion. Veuillez suivre ces étapes pour que votre jeton de connexion initial soit bien sauvegardé.
- Exécutez « steamcmd.exe + login "nom du compte" » sur l'ordinateur qui va réaliser le build.
- Saisissez votre mot de passe et le jeton SteamGuard.
- Tapez « info ». Votre compte devrait alors apparaitre comme connecté.
- Tapez « quit ».
- Lors de futurs lancements, ne saisissez pas de mot de passe. Lancez tout simplement « steamcmd.exe +login <username> ».
- Assurez-vous que le fichier de configuration enregistré dans <Steam>\config\config.vdf est bien sauvegardé et conservé entre chaque lancement, car ce fichier peut être mis à jour après une connexion réussie.
REMARQUE : si vous effectuez une nouvelle connexion et entrez votre mot de passe, un nouveau jeton SteamGuard sera alors créé et sera nécessaire pour vous connecter.
Gérer les mises à jour
Après la publication de votre application, votre clientèle recevra le build signalé comme étant celui par défaut. Lors de la mise en ligne d'un nouveau build, il est préférable de le tester avant de le mettre à disposition du public. Pour plus d'informations sur ce procédé, consultez :
Tester sur Steam.
Débogage des problèmes de build
Si votre build a échoué, vous devriez trouver dans le répertoire de sortie (et non dans la console où a été exécuté le script) des informations relatives aux erreurs rencontrées. Des informations sur la plupart des erreurs sont stockées dans les fichiers *.log.
Vous pouvez utiliser les commandes du client Steam et fichiers client suivants pour procéder au débogage.
-
"app_status [appid]"
: affiche le statut actuel de l'application sur ce client.
-
"app_info_print [appid]"
: affiche la configuration actuelle de Steamworks pour ce jeu (dépôts, options de démarrage, etc.).
-
"app_config_print [appid]"
: affiche la configuration actuelle de l'utilisateur ou de l'utilisatrice pour ce jeu (langue sélectionnée, répertoire d'installation, etc.).
-
file "logs\content_log.txt"
: répertorie toutes les opérations de SteamPipe et leurs erreurs.
-
file "steamapps\appmanifest_[appid].acf"
: affiche le statut actuel de l'installation pour cette application (KeyValues).
Créer des disques d'installation destinés à la vente
Afin de créer des disques d'installation pour les jeux SteamPipe, vous devez commencer par configurer un fichier de projet de build.
Dans cet exemple, il s'agit du fichier SKU nommé « sku_goldmaster.txt » :
"sku"
{
"name" "Test Game Installer"
"appid" "202930"
"disk_size_mb" "640"
"included_depots"
{
"1" "202931"
"2" "202932"
}
}
Gardez à l'esprit les conseils supplémentaires ci-dessous.
Créer en option un programme d'installation destiné à la vente à partir d'une version bêta
Le procédé décrit ci-dessus permet la création d'un programme d'installation destiné à la vente, basé sur la version par défaut. Si vous avez besoin de créer un programme d'installation basé sur une version différente (bêta), vous devez d'abord créer une version bêta nommée « baseline ». Utilisez ensuite les commandes suivantes afin de créer à partir de la version bêta nommée « baseline » :
build_installer <project file> <target folder> <beta key> <beta pwd>
steamcmd ex: build_installer sku_goldmaster.txt "D:\retail_disks" baseline superSecret
script ex: steamcmd.exe +login user_name password +build_installer "..\Build\GameDataSku.txt" c:\destination beta_key beta_password +exit
Installer un DLC à partir d'un programme d'installation
Dans certaines circonstances, vous pouvez avoir besoin de créer un programme d'installation dédié à la vente comprenant également les DLC. Le procédé nécessaire à la création d'un programme d'installation s'en trouvera légèrement modifié.
Dans « sku_goldmaster.txt », intégrez les AppID des DLC dans la section « included_depots ». Une fois le processus « build_installer » exécuté, trouvez le fichier sku.sis généré pour le programme d'installation et ouvrez-le dans un éditeur de texte.
Ajoutez l'AppID du DLC dans la section « apps ». Par exemple, un jeu dont l'AppID serait 1000 et l'AppID du DLC serait 1010 nécessiterait les modifications suivantes de la section « apps » :
"apps"
{
"0" "1000"
"1" "1010"
}
Ainsi, Steam sera en mesure de vérifier si le compte Steam possède déjà le DLC, et de lui demander une clé si ce n'est pas le cas.
Créer un programme d'installation destiné à la vente pour des AppID multiples sur un seul disque ou package d'installation
Découvrez comment créer un GM comprenant de multiples applications SteamPipe. Créez les programmes d'installation d'application un par un tout en leur désignant le même dossier de sortie. Chaque build sera fusionné avec l'image d'installation existante.
Personnaliser un disque d'installation
Consultez l'article de la documentation intitulé
Personnaliser un gold master pour obtenir plus de détails sur la personnalisation de votre disque d'installation.
Précharger des jeux avant leur sortie
Par défaut, le contenu est toujours chiffré sur les disques destinés à la vente et les serveurs de contenu. Passer un jeu en mode de préchargement signifie que celles et ceux qui le possèdent peuvent télécharger le contenu qui reste crypté sur leur disque sans être jouable. Quand le jeu sortira officiellement, Steam décryptera le contenu préchargé et son propriétaire pourra jouer au jeu.
Basculer un jeu en mode préchargement est recommandé dans les cas suivants :
- envoi de disques avec des clés de produit destinés à la vente avant la publication effective du jeu (piratage dès le premier jour) ;
- jeux proposés au préachat et qui font plus de 20 Go.
Veuillez envoyer un ticket au service de publication de Steam si vous pensez que votre jeu nécessite un préchargement.
Créer des DLC
Les DLC sont créés sous la forme de dépôts du jeu de base. Consultez l'article
Dépôts de la documentation pour en savoir plus.
Dépannage de SteamPipe
« Login Failure: Account Login Denied Failed » lors de la connexion via steamcmd
Cause : SteamGuard empêche probablement la connexion. Solution :
- regardez si vous trouvez un e-mail du Support Steam dans la boite associée au compte avec lequel vous essayez de vous connecter et copiez le code présent dans l'e-mail ;
- exécutez la steamcmd suivante :
set_steam_guard_code<code>
;
- réessayez de vous connecter depuis la steamcmd :
Steam>login <buildaccount> <password>
.
Dépannage général des problèmes de téléchargement
- Redémarrez votre ordinateur, modem, routeur, etc.
- Vérifiez les paramètres du pare-feu. Le nouveau système nécessite l'ouverture du port 80 (HTTP) et de tous les autres ports Steam, dont la liste se trouve ici.
- Désactivez temporairement les programmes antivirus ou antispam locaux.
- Vérifiez la région de téléchargement dans Paramètres → Téléchargements. Celle-ci devrait correspondre à votre emplacement actuel.
- Arrêtez le téléchargement, désinstallez, puis réinstallez le jeu (nettoyez le cache du manifeste).
- Quittez Steam, supprimez les dossiers « appcache » et « depotcache » dans votre répertoire d'installation Steam.
- Essayez de définir une région de téléchargement Steam éloignée de la vôtre. Cela peut résoudre le problème si le serveur le plus proche transmet des données erronées.
Mes builds pour Mac et/ou Linux n'installent pas de fichiers. Pourquoi ?
Si vous testez l'installation de votre jeu ou application via Steam sur des plateformes différentes, il peut arriver que votre build s'installe correctement sur Windows mais ne produise aucun fichier sur Mac ou Linux, même si SteamPipe est paramétré pour la mise en ligne de dépôts sur ces plateformes. Il existe une étape, fréquemment oubliée, qui consiste à ajouter vos dépôts alternatifs au package en cours de déploiement. Vous pouvez vérifier quels dépôts sont inclus dans le package grâce à la procédure suivante.
- Rendez-vous sur la page Admin. de l'app.
- Dans la section « Voir les articles associés », cliquez sur Packages, DLC, démos et outils associés.
- Cliquez sur le titre du package que vous essayez de télécharger.
- Vérifiez la section Dépôts inclus.
- Utilisez la fonction Ajouter/supprimer des dépôts pour vous assurer que les dépôts associés au package sont les bons.
Certains fils de discussion (en anglais) peuvent également vous être utiles :
Exécuter steamcmd.exe provoque l'erreur suivante : « SteamUpdater : erreur : Steam doit être en ligne pour effectuer la mise à jour. Vérifiez votre connexion réseau puis réessayez. »
Solution : dirigez-vous vers
Options Internet →
Connexions →
Paramètres réseau et cochez
Détecter automatiquement les paramètres de connexion.
Exécuter le build de l'application provoque l'erreur suivante : « ERROR! Failed 'DepotBuild for scriptname.vdf' - status = 6 ».
Le problème peut avoir plusieurs origines.
- Le compte n'a pas la permission requise par l'application.
- Vérifiez que l'AppID est correct dans « app_build.vdf ».
- Vérifiez que le compte de build a les permissions requises par l'AppID.
- Steamcmd ne trouve pas le contenu du dépôt.
- Vérifiez que la valeur « contentroot » dans le script « app_build » correspond à un chemin d'accès valable par rapport à l'emplacement du fichier de script.
- Vérifiez que la valeur « LocalPath » dans le script « depot_build » correspond à un chemin d'accès valable par rapport à celui du script « app_build ». Vérifiez que le chemin d'accès mène bien à du contenu.
Exécuter le build de l'application provoque l'erreur suivante : « ERROR! Failed to get application info for app NNNNN (check login and subscription) »
Cela signifie que Steam ne parvient pas à accéder aux informations relatives à l'application, soit parce qu'elles n'existent pas, soit parce que l'utilisateur ou l'utilisatrice n'a pas accès à l'application.
- Vérifiez que NNNNN est bien l'ID qui vous a été assigné pour l'application.
- Vérifiez que l'AppID est correct dans « app_build.vdf ».
- S'il s'agit d'un nouvel AppID, vérifiez que la configuration sur la page « Admin. de l'app » de Steamworks a été publiée. Les nouvelles applications devraient comporter un répertoire d'installation de SteamPipe et un dépôt. Pour y accéder, cliquez sur « Modifier les paramètres Steamworks » : le répertoire d'installation est situé dans la rubrique « Installation générale » sous l'onglet « Installation » et le dépôt est dans la rubrique « Dépôts » de l'onglet « SteamPipe ». La publication des changements s'effectue dans l'onglet « Publier ».
- Si tout est en ordre, vérifiez que votre compte possède l'AppID.
« An error occurred while installing [AppName] (Invalid content configuration) » au moment du lancement
Le problème peut avoir plusieurs origines.
- Aucun build n'est activé dans la branche à partir de laquelle vous essayez de l'installer.
Solution : activez votre build dans une branche en vous rendant sur https://partner.steamgames.com/apps/builds/<YourGameAppId> et sélectionnez cette branche dans le client Steam (comme spécifié ici).
- Options de lancement du jeu non valides.
Solution : vérifiez les options de lancement dans l'onglet d'installation sur la page d'administration Steamworks de votre jeu
https://partner.steamgames.com/apps/config/<YourGameAppId>.
- Vous ne possédez pas les ID de dépôt relatifs au jeu.
Solution : assurez-vous que les dépôts nécessaires sont présents dans l'abonnement de développement (pour plus de détails, consultez Modifier des packages).
Je ne me souviens pas d'une commande steamcmd ou de son fonctionnement
Utilisez la commande « find » dans steamcmd afin de rechercher une commande steamcmd. Elle établira une correspondance partielle avec le nom de la commande et affichera la syntaxe de la commande.
Steam>find build_installer
ConVars:
Commands:
build_installer : <project file> <target folder> <beta key> <beta pwd>