Sistema de Spawn i Object Pooling

Per a què serveix aquest sistema

Cada projecte Unity que genera enemics, projectils o elements d'escena acaba escrivint el mateix codi de pooling. Una cua de GameObjects inactius, un patró de préstec i devolució, crides disperses a Instantiate i Destroy, i l'estat del pool vivint en un camp de MonoBehaviour que ningú gestiona del tot. Funciona fins que deixa de fer-ho.

El Game Spawner de Serenity mou tot això darrere d'una interfície de servei tipada. La lògica de joc crida Spawn i Despawn sobre tipus lògics. El pool, la referència al prefab i la instanciació del motor viuen a la infraestructura, que és on correspon.

El problema a Unity

Instantiate i Destroy són crides al motor. Quan la lògica de joc les crida directament assumeix una responsabilitat que no hauria de tenir: saber quin prefab fer servir, decidir si existeix un pool, rastrejar instàncies actives i netejar en canviar d'escena. Aquest acoblament fa que la lògica de spawn sigui difícil de provar i fàcil de trencar quan canvia la implementació del pool.

Les biblioteques d'object pooling resolen el problema de rendiment però no el d'arquitectura. El pool continua sent un objecte concret del motor que la lògica de joc ha de referenciar. Canviar l'estratègia de pooling — passar d'una cua simple a una implementació per cub per tipus — continua requerint canvis als consumidors.

Com ho aborda Serenity

La lògica de joc interactua amb IGameSpawnerService, que exposa Spawn, Despawn, DespawnAll i IsActive. Spawn rep un value object SpawnType i retorna un SpawnHandle — un struct opac que identifica la instància mitjançant un GameEntityId sense exposar cap tipus del motor. El handle és l'únic que guarda la lògica de joc. Despawn retorna el handle i el pool decideix què fer-ne.

ISpawnFactory és el port d'aplicació que implementa la infraestructura. Gestiona les crides de motor Create, Destroy i DestroyAll. El pooling es gestiona a través d'entitats PoolBucket al domini, que agrupen handles actius i disponibles per SpawnType. PoolStateSnapshot exposa ActiveCount, AvailableCount i TotalCount per a diagnòstic sense donar als consumidors accés als interns del pool.

Com encaixa a Serenity

Game Spawner viu al namespace Serenity.GameSpawner i segueix l'estructura per capes de la foundation. La capa de Domini defineix SpawnType, SpawnHandle, PoolStateSnapshot i l'entitat PoolBucket. La capa d'Aplicació exposa IGameSpawnerService i el port ISpawnFactory. La capa d'Infraestructura proporciona UnityGameSpawnerService i UnitySpawnFactory, que gestionen la instanciació de prefabs i la cua de pooling real. La instal·lació connecta tot a través de GameSpawnerInstaller i UnityGameSpawnerInstaller.

Game Spawner coopera amb els sistemes Wave i Stage per al spawn en lots temporitzats, amb el sistema Character perquè els personatges generats rebin el seu context d'inicialització, amb el sistema Rail per al posicionament de spawn vinculat a carrils, i amb el sistema Game Session per a la neteja d'àmbit de sessió mitjançant DespawnAll.

Flux de treball pràctic

1. Defineix un SpawnType per a cada categoria lògica d'entitat que necessiti el projecte, com ara enemics, projectils o col·leccionables.
2. Registra prefabs i mides de pool a la configuració de l'instal·lador perquè la infraestructura de Unity sàpiga què crear.
3. Injecta IGameSpawnerService a qualsevol classe de capa d'aplicació que necessiti generar o eliminar entitats.
4. Crida Spawn amb un SpawnType per obtenir un SpawnHandle; conserva el handle per rastrejar la instància.
5. Crida Despawn amb el handle quan l'entitat ja no sigui necessària; el pool s'encarrega de la resta.
6. Crida GetPoolState amb un SpawnType per llegir un PoolStateSnapshot amb finalitats de diagnòstic o ajust.

Què inclou

• IGameSpawnerService amb Spawn, Despawn, DespawnAll i IsActive
• SpawnHandle — struct opac que combina GameEntityId i SpawnType per al rastreig segur d'instàncies
• SpawnType — value object immutable que identifica una categoria lògica d'entitat mitjançant una clau de cadena
• Entitat de domini PoolBucket que gestiona handles actius i disponibles per tipus
• Value object PoolStateSnapshot amb ActiveCount, AvailableCount i TotalCount per a diagnòstic
• Port d'aplicació ISpawnFactory que manté la instanciació del motor fora de la capa de negoci
• UnitySpawnFactory i UnityGameSpawnerService com a implementacions d'infraestructura llestes per usar
• Sobrecàrregues de DespawnAll per a neteja específica per tipus i neteja total de sessió

Quan fer-lo servir

• Projectes que generen entitats repetitives com enemics, bales o efectes i necessiten reutilització controlada d'objectes.
• Jocs en què la lògica de joc ha de romandre desacoblada de les referències a prefabs de Unity i els detalls d'instanciació.
• Bases de codi que necessiten referències d'entitat traçables mitjançant handles en lloc de camps de GameObject dispersos.
• Projectes que s'integren amb els sistemes Wave, Stage o Game Session i necessiten un despawn massiu coordinat.

Sistemes relacionats

• Sistema de Moviment sobre Rails Un servei de rails passiu basat en snapshots que rastreja el progrés normalitzat de 0 a 1 al llarg de camins de nodes amb nom, mantenint els sistemes de moviment, IA i càmera completament desacoblats.
• Gestió de sessions de joc Un servei de sessió centralitzat que és propietari del cicle de vida de cada partida — estat, temps transcorregut i identitat — perquè cap subsistema no l'hagi de duplicar.
• Sistema d'Onades Un spawner d'onades que guionitza qui apareix, on i quan, encadena les onades en sets que avancen sols i les spawneja en punts amb nom de l'escenari que les allotja.
• Sistema de Puntuació Multi-Mètrica Un model de puntuació dinàmic que rastreja qualsevol nombre de mètriques amb nom a través d'un únic servei, retornant instantànies immutables que les regles de joc no han de posseir mai.