Object-Pool-Lebenszyklen: Wiederverwendung ohne veralteten Zustand

Wiederverwendung erzeugt einen Lebenszyklus

Pooling hält Objekte für die spätere Nutzung vor, statt jede Instanz immer wieder neu zu erzeugen und zu verwerfen. Mit dem vorgehaltenen Speicher bleibt jedoch auch alter Zustand erhalten, sofern er nicht zurückgesetzt wird. Nystroms Darstellung des Object-Pool-Musters hebt Initialisierung, Kapazitätsentscheide und Referenzen hervor, die inaktive Objekte halten. [1] Ein Pool sollte daher einen Lebenszyklus-Vertrag bereitstellen und nicht bloss eine Sammlung von Instanzen sein.

Entnahme und Rückgabe

Erzeugung, Entnahme, Rückgabe und endgültige Zerstörung voneinander trennen. Die Pool-Schnittstellen von Unity bieten dafür Callbacks; die Implementierung unterscheidet ausserdem aktive von inaktiven Objekten und zerstört überzählige zurückgegebene Instanzen. [2] Eine Obergrenze für den inaktiven Speicher ist nicht automatisch eine Obergrenze für gleichzeitig aktive Spielobjekte. Ist ein Limit für Spielobjekte erforderlich, muss es separat durchgesetzt werden.

Durchgespieltes Beispiel

Ein veranschaulichender Projektil-Pool enthält einen Slot mit der Kennung (slot = 7, generation = 12). Der Pool feuert ein Projektil ab und nimmt den Slot nach dem Aufprall zurück. Bei der nächsten Entnahme wird die Generation auf 13 erhöht; Besitzer, Schaden, Geschwindigkeit, verbleibende Lebensdauer, Kollisionsfilter und visuelle Spuren werden zurückgesetzt.

Ein verzögerter Timer des vorherigen Projektils verweist noch auf (7, 12). Bevor sein Callback ausgeführt wird, Generation und Aktivstatus des Handles mit dem Pool abgleichen. Der Aufruf wird abgewiesen, weil die aktuelle Lebensspanne (7, 13) ist. Eine Objektreferenz ungleich null würde diese Lebensspannen allein nicht unterscheiden und könnte das neue Projektil zerstören.

Generationen-Handles benötigen eine explizite Regel für den Überlauf und ersetzen die Besitzverhältnisse nicht. Ein Besitzer bleibt dafür verantwortlich, die Instanz genau einmal zurückzugeben. Andere Systeme halten lediglich begrenzte Beobachtungen oder validierte Handles.

Ablauf der Implementierung

Aus den veränderlichen Feldern und den externen Registrierungen eine Checkliste für das Zurücksetzen erstellen. Bei der Rückgabe Events abmelden, Timer abbrechen, Besitzverknüpfungen lösen und gehaltene Referenzen löschen. Die nächste Lebensspanne vollständig initialisieren, bevor das Objekt für Kollision oder Rendering sichtbar wird. Dabei Engine-Callbacks berücksichtigen, die schon die Aktivierung selbst auslösen kann.

Das Verhalten bei Erschöpfung festlegen: einen rein kosmetischen Spawn ablehnen, innerhalb eines Budgets wachsen oder Kapazität für kritische Objekte reservieren. Ein aktives Spielobjekt nicht stillschweigend einziehen, es sei denn, dieses Verhalten gehört zum Design. Entnahmen, Rückgaben, Höchststand aktiver Objekte, vorgehaltenen Speicher und Allokations-Fallbacks erfassen.

Grenzen und Verifikation

Pooling kann den vorgehaltenen Speicher erhöhen und Kosten in den Aufwand für das Zurücksetzen verlagern. Simulation, Draw Calls und Updates pro Objekt entfallen dadurch nicht. Vor dem Pooling von Objekten, die günstig und selten zu erzeugen sind, eine repräsentative Last messen.

Wiederverwendung nach jedem Austrittspfad testen: normales Ablaufen, Kollision, Szenenwechsel, Abbruch und fehlgeschlagene Initialisierung. Doppelte Rückgabe und verzögerte Callbacks gezielt prüfen. Sicherstellen, dass ein inaktives Objekt weder weiter Schaden verursachen noch eine ganze entladene Szene am Leben halten kann. Die Korrektheit des Lebenszyklus sollte auch dann nachprüfbar bleiben, wenn Pooling keinen Leistungsgewinn bringt.

Quellen

[1] Object Pool — Robert Nystrom, Game Programming Patterns.

[2] Unity object-pool implementation — Unity Technologies.