On-demand-Installation für Spiele

  • Artikel

In diesem technischen Artikel werden zwei Techniken erläutert: die On-demand-Installation und die Hintergrundinstallation mit dem Windows Installer. Spiele können diese Installationstechniken nutzen, um Spieler*innen durch reduzierte Installationszeiten ein besseres und angenehmeres Spielerlebnis zu bieten.

Überblick

Schon lange ist die Installation ein Teil computerbasierter Anwendungen. Die meisten Anwendungen erfordern heutzutage zunächst eine Installation auf der lokalen Festplatte der Benutzer*innen, bevor sie verwendet werden können. Computerspiele stellen dabei keine Ausnahme dar: Nach dem Kauf eines Microsoft Windows-Spiels müssen Benutzer*innen zunächst einen Installationsprozess durchführen, bei dem die erforderlichen Dateien auf die Festplatte kopiert werden, bevor sie das Spiel ausführen können. Dabei handelt es sich in der Regel um einen langwierigen Installationsprozess, der bis zu einer Stunde in Anspruch nehmen kann. Die Installationszeit ist ein Faktor, der Konsolenspiele für einige Spieler*innen attraktiver macht als computerbasierte Spiele, da sie ein Konsolenspiel direkt nach dem Einlegen der Spieldisc spielen können. Die in diesem Artikel erläuterten Technologien versuchen, diesen Zustand durch drastisch reduzierte Installationszeiten zu verbessern.

Üblicherweise erfordern Spiele vor dem Start die Installation aller oder der meisten Dateien. Für eine On-demand-Installation müssen die Spielressourcen modular sein. Das bedeutet, dass Entwickler*innen die Ressourcen der Anwendung (Grafik, Audio usw.) in Komponenten aufteilen müssen. Jede Komponente stellt eine Ressourcengruppe dar, die als Einheit installiert oder entfernt werden kann. Daraufhin definieren Spieleentwickler*innen ein oder mehrere Features – in der Regel eins oder mehrere pro Level oder Zone. Jedes Feature einer Anwendung gibt eine Reihe von Komponenten an, die für die Ausführung dieses bestimmten Features erforderlich sind. Bei der Installation einer Anwendung können ihre Features folgendermaßen gekennzeichnet werden: als „installiert“ (Komponenten, die während der Installation auf die lokale Festplatte kopiert werden) oder als „angekündigt“ (Komponenten, die nach der Erstinstallation auf die lokale Festplatte kopiert werden, sobald die Anwendung dieses Feature verwendet). Spielentwickler*innen können die Installationszeit verkürzen, indem sie das Spiel so entwerfen, dass es mit einer minimalen Anzahl installierter Features gestartet und ausgeführt werden kann. Die restlichen Features können als „angekündigt“ gekennzeichnet und bei Bedarf installiert werden, sobald die Anwendung die Funktionen dieser Features tatsächlich benötigt.

Spiele können den Windows Installer aufrufen, um ein bestimmtes Feature zu installieren, das möglicherweise nicht installiert wurde. Für eine Hintergrundinstallation kann ein Arbeitsthread verwendet werden, um die Aufrufe an das Installationsprogramm auszuführen, während der primäre Thread weiterhin die Logik des Spiels verarbeitet und seine Grafik rendert. Dadurch werden installationsbedingte Unterbrechungen während des Spielens minimiert. Das Spiel kann die Installation jederzeit initiieren. Da die Installation jedoch Prozessorzyklen beansprucht, empfiehlt es sich in der Regel nicht, die Installation auszuführen, während der primäre Thread einen hohen Leistungsbedarf aufweist, beispielsweise wenn Benutzer*innen sich gerade mitten im Gefecht befinden. Die folgenden Situationen stellen möglicherweise einen guten Zeitpunkt für die Installation dar: wenn sich Benutzer*innen im Spielmenü befinden, wenn das Spiel angehalten oder minimiert wird oder wenn das Einführungsvideo oder Videosequenzen eingeblendet werden.

Unterstützung durch Patchen

Die meisten Spiele müssen heutzutage auch nach ihrer Veröffentlichung aktualisiert werden, wenn Fehler behoben und neue Features hinzugefügt werden. Oftmals müssen Spiele zum Aktualisieren gepatcht werden. Dabei handelt es sich üblicherweise um ein unkompliziertes Verfahren für Spiele. Da alle erforderlichen Dateien auf der Festplatte von Benutzer*innen installiert sind, umfasst das Patchen eines Spiels das Kopieren überarbeiteter Dateien auf die Festplatte sowie das Überschreiben vorhandener Dateien. Bei der On-demand-Installation werden nicht alle Dateien während des Patchens installiert und kopiert. Daher kann der Patcher keine aktualisierten Dateien einfach in den Spielordner schreiben.

Der Windows Installer verfügt über Features, die die On-demand-Installation zum Patchen von Anwendungen verwenden. Beim Patchen wird der Patch durch das Installationsprogramm auf dem System zwischengespeichert. Dieses Feature eignet sich gut für Patches mit kleinen Änderungen. Die ursprünglich freigegebenen Dateien müssen sich während des Patchens nicht mehr auf dem Datenträger befinden, wodurch diese Dateien als „angekündigt“ markiert werden können. Wenn die Anwendung zu einem späteren Zeitpunkt ausgeführt wird und auf die Dateien zugreifen muss, installiert das Installationsprogramm die neueste Version dieser Dateien, indem es die ursprünglich veröffentlichte Version von den Medien (z. B. CDs) kopiert und den Patch nach dem Lesen der gespeicherten Patchdaten anwendet.

Beispiel: InstallOnDemand-SDK

Im Beispiel „On-demand-Installation für Spiele“ werden die in diesem Artikel erläuterten On-demand-Installationstechniken veranschaulicht. Im Gegensatz zu anderen Beispielen kann die On-demand-Installation für Spiele nicht direkt über den Beispielbrowser ausgeführt werden. Da das Beispiel den Windows Installer zur Verwaltung der Installation verwendet, muss es in der Datenbank für installierte Anwendungen des Installationsprogramms enthalten sein.

So starten Sie das Beispiel:

  1. Verwenden Sie im Beispielbrowser die Verknüpfung „Projekt installieren“, um die Beispieldateien in einen Ordner zu kopieren.
  2. Doppelklicken Sie auf „InstallOnDemand.msi“, um das Beispiel zu installieren.
  3. Wählen Sie „Standardinstallation“ aus.
  4. Starten Sie das Beispiel, indem Sie die Datei „InstallOnDemand.exe“ im installierten Ordner (in der Regel „Programme\InstallOnDemand“) oder sie im Startmenü über „Programme“ starten.

Bei „InstallOnDemand.msi“ handelt es sich um eine Datenbank, die vom Installationsprogramm erkannt wird. Sie definiert den gesamten Installationsprozess, unter anderem die Verzeichnisstruktur, was kopiert und nicht kopiert wird, welche Ressourcen zusammen kopiert werden, welche Registrierungswerte geschrieben werden sollen und welche Verknüpfungen erstellt werden sollen.

Beim Starten spielt das Beispiel eine Einführungssequenz ab. Spieler*innen können diese beenden und über die ESC-Taste ins Hauptmenü gelangen. Nach der Einführung können Spieler*innen ein neues Spiel starten, indem sie einen Charakternamen eingeben und Attribute auswählen. Bevor das Beispiel die Einführungssequenz abspielt, ruft das Beispiel eine Funktion des Installationsprogramms auf, die überprüft, ob das Feature für Level 1 installiert ist. Wenn das Feature für Level 1 nicht installiert wurde, verwendet das Beispiel einen Hintergrundthread, um das Installationsprogramm anzuweisen, das Spiel zu installieren, während der primäre Thread beispielsweise die Einführungssequenz abspielt, das Menü rendert oder Spieler*innen bei der Charaktererstellung begleitet. Dies unterscheidet sich von der herkömmlichen Spielinstallation insofern, als Benutzer*innen während der Installation im Spiel damit beschäftigt sind, die Einführungssequenz anzusehen oder einen neuen Charakter zu erstellen. Nach der Charaktererstellung lädt das Beispiel die Ressourcen für Level 1.

Auf der rechten Seite des Beispielbildschirms sind fünf Schaltflächen als „Play Level 1“ bis „Play Level 5“ gekennzeichnet. Diese Schaltflächen simulieren den Abschluss des aktuellen Levels und den Aufstieg zum nächsten. Durch das Klicken auf eine dieser Schaltflächen wird ein Statistikbildschirm mit Informationen über das soeben abgeschlossene Level angezeigt. Außerdem benötigt das Beispiel diese Zeit, um das Installationsprogramm anzuweisen, das nächste Level zu überprüfen und zu installieren, sofern es noch nicht installiert wurde. Die Installation wird ausgeführt, während die Spieler*innen den Statistikbildschirm lesen. Wenn Benutzer*innen auf „OK“ klicken, um das nächste Level zu betreten, sind alle Ressourcen des Levels installiert und können geladen werden.

Features und Komponenten des Beispiels

Üblicherweise erfordern Spiele vor dem Start die Installation aller oder der meisten Dateien. Für eine On-demand-Installation müssen die Spielressourcen modular sein. Das bedeutet, dass Entwickler*innen die Ressourcen der Anwendung (Grafik, Audio usw.) in Komponenten aufteilen müssen. Jede Komponente stellt eine Ressourcengruppe dar, die als Einheit installiert oder entfernt werden kann. Daraufhin definieren Spieleentwickler*innen ein oder mehrere Features – in der Regel eins oder mehrere pro Level oder Zone. Jedes Feature einer Anwendung gibt eine Reihe von Komponenten an, die für die Ausführung dieses bestimmten Features erforderlich sind. Bei der Installation einer Anwendung können ihre Features folgendermaßen gekennzeichnet werden: als „installiert“ (Komponenten, die während der Installation auf die lokale Festplatte kopiert werden) oder als „angekündigt“ (Komponenten, die auf die lokale Festplatte kopiert werden, sobald die Anwendung dieses Feature zu einem späteren Zeitpunkt verwendet). Spielentwickler*innen können die Installationszeit verkürzen, indem sie das Spiel so entwerfen, dass es mit einer minimalen Anzahl installierter Features gestartet und ausgeführt werden kann. Die restlichen Features können als „angekündigt“ gekennzeichnet und bei Bedarf installiert werden, sobald die Anwendung die Funktionen dieser Features tatsächlich benötigt.

In der folgenden Tabelle werden die sechs vom Beispiel definierten Features der obersten Ebene aufgeführt.

Funktionsname Funktionalität Komponenten Dateien
Core Dieses Feature schließt Ressourcen ein, die unabhängig vom Level jederzeit erforderlich sind. Diese Ressourcen umfassen ausführbare Beispieldateien, für die Einführungssequenz sowie den Ladebildschirm erforderliche Medien und die FX-Datei, die das gesamte Beispiel rendert. Core InstallOnDemand.exe, InstallOnDemand.fx, Loading.bmp, Level.x
Core (Siehe oben) CoreUI Media\UI\dxutcontrols.dds, Media\UI\DXUTShared.fx, Media\UI\arrow.x
Core (Siehe oben) CoreMisc Media\Misc\seafloor.x, Media\Misc\seafloor.bmp
Core (Siehe oben) CoreSpeeder Media\PRT Demo\LandShark.x, Media\PRT Demo\speeder_diff.jpg
Core (Siehe oben) CoreReg N/v (Registrierungswert)
Level1 Dieses Feature stellt Ressourcen bereit, die von Level 1 verwendet werden. Level1 Level1.jpg
Level1 (Siehe oben) L1Skybox Media\Light Probes\galileo_cross.dds
Level2 Dieses Feature stellt Ressourcen bereit, die von Level 2 verwendet werden. Level2 Level2.jpg
Level2 (Siehe oben) L2Skybox Media\Light Probes\grace_cross.dds
Level3 Dieses Feature stellt Ressourcen bereit, die von Level 3 verwendet werden. Level3 Level3.jpg
Level3 (Siehe oben) L3Skybox Media\Light Probes\rnl_cross.dds
Level4 Dieses Feature stellt Ressourcen bereit, die von Level 4 verwendet werden. Level4 Level4.jpg
Level4 (Siehe oben) L4Skybox Media\Light Probes\stpeters_cross.dds
Ebene5 Dieses Feature stellt Ressourcen bereit, die von Level 5 verwendet werden. Ebene5 Level5.jpg
Ebene5 (Siehe oben) L5Skybox Media\Light Probes\uffizi_cross.dds

 

Die Features „Level1“ bis „Level5“ verfügen über zusätzliche Unterfeatures, die Dateien enthalten, die nicht direkt vom Beispiel verwendet werden. Die Dateien dieser Unterfeatures wurden hinzugefügt, damit die Installation länger dauert. Dies dient zur Veranschaulichung des laufenden Installationsvorgangs, der während der Ausführung des Beispiels im Hintergrund ausgeführt wird.

In der folgenden Tabelle werden die Unterfeatures aufgeführt.

Funktion Unterfeatures Dateien
Level1 L1PH1, L1PH2, L1PH3, L1PH4, L1PH5 Level1 Placeholder Data\L1PH1.dat Level1 Placeholder Data\L1PH2.dat Level1 Placeholder Data\L1PH3.dat Level1 Placeholder Data\L1PH4.dat Level1 Placeholder Data\L1PH5.dat
Level2 L2PH1, L2PH2, L2PH3, L2PH4, L2PH5 Level2 Placeholder Data\L2PH1.dat Level2 Placeholder Data\L2PH2.dat Level2 Placeholder Data\L2PH3.dat Level2 Placeholder Data\L2PH4.dat Level2 Placeholder Data\L2PH5.dat
Level3 L3PH1, L3PH2, L3PH3, L3PH4, L3PH5 Level3 Placeholder Data\L3PH1.dat Level3 Placeholder Data\L3PH2.dat Level3 Placeholder Data\L3PH3.dat Level3 Placeholder Data\L3PH4.dat Level3 Placeholder Data\L3PH5.dat
Level4 L4PH1, L4PH2, L4PH3, L4PH4, L4PH5 Level4 Placeholder Data\L4PH1.dat Level4 Placeholder Data\L4PH2.dat Level4 Placeholder Data\L4PH3.dat Level4 Placeholder Data\L4PH4.dat Level4 Placeholder Data\L4PH5.dat
Ebene5 L5PH1, L5PH2, L5PH3, L5PH4, L5PH5 Level5 Placeholder Data\L5PH1.dat Level5 Placeholder Data\L5PH2.dat Level5 Placeholder Data\L5PH3.dat Level5 Placeholder Data\L5PH4.dat Level5 Placeholder Data\L5PH5.dat

 

Während der Installation sollte das Hauptfeature als „installiert“ und alle anderen Features als „angekündigt“ gekennzeichnet werden. Die Zeit, die Spieler*innen auf den Start des Spiels warten müssen, wird erheblich reduziert, wenn lediglich eines der sechs Features installiert wird.

Installation

Der Windows Installer bietet Anwendungen einen Mechanismus, mit dem sie die Installation von als „angekündigt“ markierten Features anfordern können. Bei diesem Mechanismus handelt es sich jedoch um einen synchronen API-Aufruf (Application Programming Interface, Anwendungsprogrammierschnittstelle). Das bedeutet, dass die Anwendung innerhalb des Aufrufs warten muss, bis die Installation abgeschlossen ist. Für eine Hintergrundinstallation ist ein Arbeitsthread erforderlich, damit der Hauptanwendungsthread andere wichtige Aufgaben wie das Rendern auf dem Bildschirm ausführen kann, um Spieler*innen weiterhin visuelles Feedback zu geben.

Während der Beispielausführung können drei Installationszustände auftreten: aktive Installation, passive Installation und keine Installation.

  • Bei der aktiven Installation handelt es sich um eine Anforderung, die vom Beispiel initiiert wird, wenn es auf Ressourcen zugreifen oder Ressourcen laden muss, die von einem oder mehreren Features bereitgestellt werden. Das Beispiel initiiert die aktive Installation, wenn es den Vorgang nicht fortsetzen kann, bis die Ressource installiert wurde.
  • Die passive Installation wird initiiert, wenn das Beispiel keine wichtigen Aufgabe ausführt, beispielsweise wenn sich Spieler*innen in einem Menü befinden oder eine Videosequenz ansehen. In diesem Fall überprüft der Arbeitsthread, ob ein Feature des Beispiels noch als „angekündigt“ markiert ist. Wenn er eines finden kann, ruft er das Installationsprogramm auf, um dieses Feature zu installieren. Dieser Vorgang wird wiederholt, bis jedes Feature des Beispiels installiert ist. Im Grunde verwendet die passive Installation zusätzliche Prozessorzyklen, um die Installation im Hintergrund auszuführen, wenn diese das Hauptbeispiel am wenigsten beeinträchtigt.
  • Es wird keine Installation ausgeführt, wenn Spieler*innen aktiv in das Spielgeschehen vertieft sind. Dadurch wird ein Einbruch der Bildwiederholungsrate verhindert, der das Benutzererlebnis stören würde.

Im Beispiel wird eine CMsiUtil-Klasse definiert, um alle installationsbezogenen Aufgaben zu verarbeiten. Im Grunde verwendet die CMsiUtil-Klasse einen Arbeitsthread, der das Installationsprogramm aufruft, um die Features des Beispiels in einer Schleife zu installieren. Die Klasse verfügt über zwei Warteschlangen, die Installationsanforderungen speichern: eine Warteschlange mit hoher Priorität für die aktive Installation und eine mit niedriger Priorität für die passive Installation. Während der Initialisierung listet die Klasse alle Features des Produkts auf und fügt diese der Warteschlange für die passive Installation hinzu. Da das gesamte Produkt auf diese Weise in die Warteschlange eingereiht wird, wird schließlich das gesamte Produkt installiert, wenn das Beispiel über genügend freie Prozessorzyklen verfügt.

Wenn das Beispiel eine aktive Installation anfordern muss, kann es CMsiUtil::UseFeatureSet() aufrufen und den Namen des Features der obersten Ebene übergeben. Die UseFeatureSet()-Methode reiht das angeforderte Feature und alle Unterfeatures in die Warteschlange der aktiven Installation ein, damit der Arbeitsthread diese installieren kann.

Während der Ausführung einer Installationsanforderung überprüft der Arbeitsthread die Warteschlangen der aktiven und passiven Installation, um festzustellen, ob eine der Warteschlangen zusätzliche Anforderungen enthält. Jedes Mal, wenn der Thread eine Anforderung findet, ruft er die API des Installationsprogramms auf, um die tatsächliche Installation auszuführen. Sobald beide Warteschlangen leer sind, wechselt der Arbeitsthread mit einem WaitForSingleObject-Aufruf in den Ruhezustand. Da das gesamte Produkt während der Initialisierung in die Warteschlange für die passive Installation eingereiht wird, bedeutet eine leere Warteschlange, dass das gesamte Produkt installiert wurde.

Das Beispiel ruft CMsiUtil::EnablePassiveInstall() auf, um die passive Installation zu aktivieren oder zu deaktivieren. EnablePassiveInstall(true) erhöht die Aktivierungsanzahl für die passive Installation, und EnablePassiveInstall(false) verringert sie. Wenn die Anzahl der Aktivierungen größer als null ist, verarbeitet die Klasse die Warteschlange für die passive Installation. Das Beispiel lässt eine passive Installation unter der folgenden Bedingungen zu:

  • Benutzer*innen sehen sich die anfängliche Einführungssequenz an.
  • Benutzer*innen navigieren im Beispielmenü.
  • Benutzer*innen zeigen die Statistiken am Ende eines Levels an.
  • Die Beispielanwendung wechselt vom Vordergrund zum Hintergrund.

Die CMsiUtil-Methoden werden unten aufgeführt:

Methode Beschreibung
AbortAllRequests Diese Methode bricht die aktuelle Installation ab und leert die Anforderungswarteschlange der aktiven Installation.
AbortCurrentRequest Diese Methode bricht die laufende Installation ab. Der Arbeitsthread verarbeitet dann die nächste Anforderung in der Warteschlange, sofern eine vorhanden ist.
EnablePassiveInstall Diese Methode erhöht oder verringert die Aktivierungsanzahl für die passive Installation. Das Beispiel verwendet diesen Aufruf, um zu steuern, wann die passive Installation möglich ist und wann sie nicht möglich ist.
GetCurrentFeatureName Diese Methode gibt den Namen des Features zurück, das aktuell installiert wird.
GetFeatureProgress Diese Methode gibt die aktuelle Tickposition für das Feature zurück, das installiert wird.
GetFeatureProgressMax Diese Methode gibt die maximale Anzahl der Statusticks für das Feature zurück, das installiert wird.
Letzten Fehler abrufen Diese Methode sollte verwendet werden, um den Rückgabecode aus der vorherigen Installationsanforderung abzurufen.
GetPassiveProgress Diese Methode gibt die Tickposition der Statusanzeige für die passive Installation zurück.
GetPassiveProgressMax Diese Methode gibt die aktuelle Tickposition sowie die maximale Anzahl von Ticks für die passive Installation zurück. Das Beispiel kann diese zusammen verwenden, um den Gesamtfortschritt der passiven Installation darzustellen.
GetProgress Diese Methode gibt die Tickposition der Statusanzeige für die aktive Installation der Featuregruppe zurück. Sie wird verwendet, wenn das Beispiel die Statusanzeige der Installation rendert. Da der Windows Installer lediglich Statusinformationen für das Feature bereitstellt, das installiert wird, teilt die Methode die Statusanzeige zwischen den angeforderten Features so auf, dass die gesamte Installation weiterhin als eine Aufgabe angezeigt wird.
GetProgressMax Diese Methode gibt die maximale Tickanzahl der Statusanzeigen für die aktive Installation der Featuregruppe zurück. Sie wird verwendet, wenn das Beispiel die Statusanzeige der Installation rendert.
Initialize Diese Methode initialisiert die Klasse mit dem Produkt-GUID (Globally Unique Identifier, eindeutiger Bezeichner). Diese Methode listet außerdem jedes Feature der Anwendung auf, das als „angekündigt“ markiert, jedoch noch nicht installiert wurde. Das Feature wird daraufhin in die Warteschlange für die passive Installation eingereiht, um die passive Installation zu initiieren.
IsInstallInProgress Verwenden Sie diese Methode, um herauszufinden, ob eine aktive Installation verarbeitet wird.
UseFeature Hier bei handelt es sich um eine private Methode, die von UseFeatureSet aufgerufen wird. Sie überprüft, ob ein Feature installiert ist. Wenn das angeforderte Feature installiert ist, wird die Methode zurückgegeben. Wenn das Feature noch nicht installiert ist (als „angekündigt“ markiert), reiht die Methode für den Arbeitsthread eine neue Anforderung für die aktive Installation in die Warteschlange ein und wird dann zurückgegeben. Das optionale Ereignishandle wird signalisiert, wenn die angeforderte Installation abgeschlossen ist.
UseFeatureSet Diese Methode wird vom Beispiel aufgerufen, wenn es auf Funktionen zugreifen muss, die von einem bestimmten Feature oder Unterfeature bereitgestellt werden. Die Methode listet alle Features des Beispiels auf und ruft UseFeature() für Unterfeatures des angegebenen Stammfeatures auf. Das Beispiel kann ein Ereignishandle übergeben, das signalisiert wird, wenn die gesamte Featuregruppe installiert wird. Da alle Features als Gruppe installiert werden, wird das Handle für das letzte Feature angegeben, das von UseFeature() anstelle jedes Features in die Warteschlange eingereiht wird. Dadurch wird das Beispiel einmal benachrichtigt, sobald alle angeforderten Features installiert wurden.
UseProduct Diese Methode reiht eine Anforderung für die aktive Installation in die Warteschlange ein, damit der Arbeitsthread das Installationsprogramm aufruft, um eine vollständige Produktinstallation durchzuführen. Das optionale Ereignishandle wird signalisiert, wenn die angeforderte Installation abgeschlossen ist.

 

Einschränkung

Die aktuelle Version des Installationsprogramms wurde nicht für den gleichzeitigen Zugriff durch mehrere Threads entwickelt. Daher sollten Haupt- und Arbeitsthread das Installationsprogramm nicht gleichzeitig aufrufen. Ein Beispiel für diese Einschränkung tritt im Beispiel auf, wenn der Hauptthread ein Feature anfordert und dann dasselbe Feature erneut anfordert, bevor der Arbeitsthread die Installation abgeschlossen hat. Die zweite Anforderung ruft MsiQueryFeatureState() auf, um überprüfen, ob das angeforderte Feature bereits installiert ist, da das Installationsprogramm möglicherweise angibt, dass das Feature vollständig installiert ist, während der Arbeitsthread die Dateien noch kopiert.

Glücklicherweise kann dieses Problem einfach umgangen werden. CMsiUtil überprüft, ob ein Feature durch den Arbeitsthread installiert wird, bevor Funktionen wie MsiQueryFeatureState() oder MsiUseFeature() aufgerufen werden, um den Installationsstatus des betreffenden Features anzufordern. Beachten Sie, dass diese Einschränkung auch an anderer Stelle zu einem Problem führen kann.

Das Patchen kann sich auf den Computern von Endbenutzer*innen auf die Funktionsfähigkeit der On-demand-Installation auswirken. Wenn Sie einen Patch anwenden, der lediglich Daten enthält, die sich von der vorherigen Version unterscheiden, muss möglicherweise die vorherige Version der aktualisierten Datei installiert werden, um die Änderung anzuwenden. In diesem Fall muss der Patch anfordern, dass das Installationsprogramm die betroffenen als „angekündigt“ markierten Features installiert, bevor das Spiel gepatcht wird.

Das Beispiel wird durch das Starten von „InstallOnDemand.msi“ installiert, da es davon ausgeht, dass der Windows Installer auf dem Computer vorhanden ist. Wenn das Installationsprogramm nicht vorhanden ist, werden MSI-Dateien nicht erkannt und können nicht gestartet werden. Um dieses Problem zu umgehen, sollte die Anwendung für diese Aufgabe ein Installationsprogramm verwenden. Dieses Programm sollte zunächst überprüfen, ob das Installationsprogramm vorhanden ist. Falls es vorhanden ist, sollte das Programm außerdem die Version überprüfen. Wenn die Version die Anforderung der Anwendung nicht erfüllt, sollte das Installationsprogramm den Windows Installer installieren und dann die MSI-Datei starten. Dieser Prozess wird als Bootstrapping bezeichnet. Das Installationsprogramm für Anwendungen, das das Bootstrapping ausführt, wird in der Regel als „Setup.exe“ bezeichnet. Das Beispiel führt kein Bootstrapping aus. Vollständige Details zu Bootstrapping finden Sie jedoch im Windows Installer.

Entwickler*innen sollten außerdem auf die Größe der einzelnen Features in ihren Spielen achten. Beim Abbrechen einer laufenden Installation stellt das Installationsprogramm den Zustand des Computers vor der Installation wieder her. Das bedeutet, dass die Installation des Features vollständig rückgängig gemacht wird und keine Teilinstallation des Features vorhanden ist. Große Features erfordern längere Installationszeiten, wodurch die Wahrscheinlichkeit erhöht wird, dass die Installation unterbrochen und abgebrochen wird, oder dass die Hauptanwendung durch die Installation beeinträchtigt wird. Ein Beispiel hierfür wäre das Aktivieren der passiven Installation, wenn Benutzer*innen das Spielmenü während des Spielens öffnen. Wenn ein Feature installiert wird und die Benutzer*innen weiterspielen, kann das Spiel die passive Installation bis zum Abschluss fortführen oder die passive Installation abbrechen. Beide Szenarios wären für große Features ungeeignet. Wenn das Spiel die Installation eines großen Features bis zum Abschluss fortführt, wird die Renderingleistung des Spiels möglicherweise über einen längeren Zeitraum beeinträchtig. Wenn das Spiel dagegen die Installation abbricht, müssen Benutzer*innen längere Zeit im Menü verbringen, bevor sie weiterspielen können. Entwickler*innen sollten eine ausgewogene Featuregröße ermitteln, die für ihre individuellen Spiele am besten geeignet ist.