Bonjour, je m'appelle Oles Dibrivniy et je suis développeur Unity chez   . Nous créons des produits à l'intersection d'EdTech et de GameDev - des applications et des produits Web pour le développement des enfants. Aujourd'hui, nos produits comptent plus de quatre millions d'utilisateurs. Keiki  Si quelqu'un vous interroge lors d'un entretien d'embauche sur les modèles de programmation que vous utilisez dans le développement de jeux, l'une des premières choses que vous devriez mentionner est ObjectPool. Il repose sur un principe élémentaire : après avoir terminé sa tâche, l'objet n'est pas supprimé mais déplacé dans un environnement séparé et peut être récupéré et réutilisé.  Ce modèle affecte directement la perception de l'application par l'utilisateur, c'est pourquoi il est crucial. Il devrait être la base de 99% de l'optimisation des projets de jeux.  Cet article peut ne pas être pertinent pour les gourous de la programmation mais pour les débutants et vice versa. Ici, je vais utiliser des exemples pour expliquer pourquoi ce modèle est essentiel.  Comment ça se passe sans ObjectPool ?  Dans un premier temps, nous analyserons le cas du projet sans ObjectPool, en commençant par le paramétrage. Nous avons une scène relativement simple avec le protagoniste et deux ennemis lançant des boules de feu :   Considérons à quoi ressemblera la boule de feu elle-même. Les champs  et  sera responsable du mouvement des boules de feu ; le  fonctionnera après une collision — l'objet avec le composant FireBall sera détruit :    Rigidbody2D   _speed   OnTriggerEnter2D                               public class FireBall : MonoBehaviour 2 { 3  [SerializeField] private Rigidbody2D _rigidbody; 4  [SerializeField] private float _speed; 5    
 6  public void FlyInDirection(Vector2 flyDirection) 7  { 8  _rigidbody.velocity = flyDirection * _speed; 9  } 10    
 11  private void OnTriggerEnter2D(Collider2D other) 12  { 13  Destroy(gameObject); 14  } 15 }  L'ennemi aura également l'air assez simple:                          public class Enemy : MonoBehaviour 2 { 3  [SerializeField] private FireBall _fireBall; 4  [SerializeField] private Transform _castPoint; 5    
 6  public void Cast() 7  { 8  FireBall fireBall = Instantiate(_fireBall, _castPoint.position, Quaternion.identity); 9  fireBall.FlyInDirection(transform.right); 10  } 11 }  Vous pouvez appeler le  méthode à partir de n'importe quel point de votre projet ou de vos événements d'animation. Nous avons le flux suivant : l'ennemi crée une boule de feu et la lance dans la direction de son regard. La boule de feu est détruite en atteignant le premier obstacle sur le chemin.   Cast  Cette approche semble optimale, mais c'est l'une des pires options. Analysons tout point par point :    et  sont des opérations coûteuses : les appeler toutes les quelques secondes entraîne des retards et des décalages. Cela est particulièrement visible lorsque vous travaillez avec des gadgets tels que les smartphones, où il est nécessaire de sauvegarder chaque octet de mémoire. Vous pouvez ouvrir le profileur Unity et saisir Instancier dans le champ de recherche de la fenêtre Hiérarchie pour voir à quel point ces opérations sont "douloureuses" pour le jeu. Il y aura ce qui suit :  1. Utilisation inefficace du processeur et de la mémoire de l'appareil.   Instantiate   Destroy  Bien sûr, j'ai augmenté le nombre de boules de feu créées par chaque ennemi à la fois à 500 pour maximiser l'effet dramatique. Cependant, il est facile d'imaginer des projets avec des objets créés et supprimés encore plus constamment, en particulier lorsqu'il s'agit d'éléments ou de particules d'interface utilisateur.  Ces processus se produisent constamment pendant l'exécution. Le joueur peut subir une baisse notable des images en raison de l'allocation constante de mémoire après avoir fait apparaître des centaines d'objets sur la scène.    Le  La méthode supprime l'objet de jeu de la scène et l'envoie au ramasse-miettes. Vous n'avez aucun contrôle sur le moment ou la manière dont le collecteur le traite. D'ailleurs,  est très sournois. Il supprime l'objet de jeu lui-même, mais ses composants peuvent continuer à vivre séparément. Cela peut arriver si un autre objet est lié à ce composant. Par exemple, il peut s'agir d'un abonnement à un certain événement. 2. Tout ce que vous avez créé doit être détruit et nettoyé.   Destroy   Destroy    Différentes classes sont responsables de la création et de la destruction d'un objet, et des dizaines d'entre elles peuvent se trouver dans le projet. Trouver quoi et où est créé ou supprimé n'est parfois pas une tâche triviale - et je suis silencieux sur le contrôle des objets dans la hiérarchie maintenant. 3. Contrôle des codes.  Intégrons ObjectPool dans le projet !  Après avoir défini le problème, passons à sa solution. Comme je l'ai mentionné précédemment, le principe de l'opération de modèle ObjectPool est simple : après avoir terminé le travail avec l'objet, il n'est pas supprimé mais se cache dans le "pool". L'objet peut être récupéré et réutilisé à partir de celui-ci :   Une entité sera responsable de la création, de la réutilisation et de la destruction d'un objet - nous l'appellerons  . Nous pouvons le faire ressembler à ceci pour travailler avec une boule de feu :    ObjectPool                                                                 public class ObjectPool : MonoBehaviour 2 { 3  [SerializeField] private FireBall _fireBallPrefab; 4    
 5  private readonly List <FireBall> _freeFireBalls = new   List <FireBall>(); 6    
 7  public FireBall GetFireBall() 8  { 9  FireBall fireBall; 10         if  (_freeFireBalls.Count > 0 ) 11  { 12  fireBall = _freeFireBalls[ 0 ]; 13  _freeFireBalls. Remove(fireBall); 
 14  } 15         else 
 16  { 17  fireBall = Instantiate(_fireBallPrefab, transform); 18  } 19         return  fireBall; 20  } 21    
 22  private void ReturnFireBall(FireBall fireBall) 23  { 24  _freeFireBalls.Add(fireBall); 25  } 26 }  Le  liste apparaît dans ce code. Nous stockerons les boules de feu créées qui y ont fait leur travail. L'ennemi ressemblera maintenant à ceci :    _freeFireBalls                           public class Enemy : MonoBehaviour 2 { 3  [SerializeField] private ObjectPool _objectPool; 4  [SerializeField] private Transform _castPoint; 5    
 6  public void Cast() 7  { 8  FireBall fireBall = _objectPool.GetFireBall(); 9  fireBall.transform.position = _castPoint.position; 10  fireBall.FlyInDirection(transform.right); 11  } 12 }  La racine de notre problème : comment renvoyer la boule de feu dans la piscine ? Nous ne pouvons pas compter sur l'ennemi; il ne sait pas quand la boule de feu sera détruite. Nous ne voulons pas non plus donner des connaissances boule de feu sur  , car cela créera des connexions inutiles.   ObjectPool  J'espère que vous avez remarqué que j'ai fait le  méthode privée. Par conséquent, nous utiliserons l'un des modèles de base de C# — observer, et son implémentation —   . La boule de feu ressemblera à ceci maintenant :    ReturnFireBall events                                 public class FireBall : MonoBehaviour 2 { 3  [SerializeField] private Rigidbody2D _rigidbody; 4  [SerializeField] private float _speed; 5    
 6  public event Action<FireBall> Destroyed; 7    
 8  public void FlyInDirection(Vector2 flyDirection) 9  { 10  _rigidbody.velocity = flyDirection * _speed; 11  } 12    
 13  private void OnTriggerEnter2D(Collider2D other) 14  { 15  Destroyed?.Invoke(this); 16  } 17 }  souscrira à la  événement après avoir passé l'objet au monde :    ObjectPool   Destroyed                                                                     public class ObjectPool : MonoBehaviour 2 { 3  [SerializeField] private FireBall _fireBallPrefab; 4  private readonly List <FireBall> _freeFireBalls = new   List <FireBall>(); 5    
 6  public FireBall GetFireBall() 7  { 8  FireBall fireBall; 9         if  (_freeFireBalls.Count > 0 ) 10  { 11  fireBall = _freeFireBalls[ 0 ]; 12  _freeFireBalls. Remove(fireBall); 
 13  } 14         else 
 15  { 16  fireBall = Instantiate(_fireBallPrefab, transform); 17  } 18  fireBall.Destroyed += ReturnFireBall; 19         return  fireBall; 20  } 21    
 22  private void ReturnFireBall(FireBall fireBall) 23  { 24  fireBall.Destroyed -= ReturnFireBall; 25  _freeFireBalls.Add(fireBall); 26  } 27 }  Il reste à accrocher l'Object Pool sur l'objet avec le  composant — félicitations ! Le ramasse-miettes se reposera jusqu'à ce que vous passiez à une autre scène ou que vous fermiez le jeu. Nous avons ObjectPool dans son implémentation de base, mais nous pouvons l'améliorer.   Enemy  Interfaces et génériques : le complément parfait à ObjectPool  Le  n'est pas le seul type d'objet que nous exécuterons dans le pool d'objets. Vous devez rédiger un  pour que chacun travaille avec d'autres types. Cela élargira la base de code et rendra le code moins lisible. Alors, utilisons des imitations et des génériques.   FireBall   ObjectPool  Chaque objet que nous parcourons  doit être lié à un type spécifique. Ils doivent être traités indépendamment de l'implémentation particulière. Il est essentiel de conserver la hiérarchie d'héritage de base des objets que le pool traitera. Ils hériteront de  , au moins. Utilisons l'interface IPoolable :    ObjectPool   MonoBehaviour                         public interface IPoolable 2 { 3  GameObject GameObject { get ; } 4  event Action<IPoolable> Destroyed; 5  void Reset (); 6 }  Nous héritons  à partir de cela:    FireBall                                                 public class FireBall : MonoBehaviour, IPoolable 2 { 3  [SerializeField] private Rigidbody2D _rigidbody; 4  [SerializeField] private float _speed; 5  public GameObject GameObject => gameObject; 6    
 7  public event Action<IPoolable> Destroyed; 8    
 9  private void OnTriggerEnter2D(Collider2D other) 10  { 11         Reset (); 12  } 13  public void Reset () 14  { 15  Destroyed?.Invoke(this); 16  } 17    
 18  public void FlyInDirection(Vector2 flyDirection) 19  { 20  _rigidbody.velocity = flyDirection * _speed; 21  } 22 }  La dernière tâche est d'enseigner  travailler avec n'importe quel objet. IPoolable ne suffira pas car Instantiate ne peut créer qu'une copie de l'objet avec le  propriété. Nous utiliserons  ; chacun de ces objets hérite de cette classe.  en est également hérité. En conséquence, nous obtiendrons ce qui suit  :    ObjectPool   gameObject   Component   MonoBehaviour   ObjectPool                                                                                                   public class ObjectPool<T> where T : Component, IPoolable 2 { 3  private readonly List <IPoolable> _freeObjects; 4  private readonly Transform _container; 5  private readonly T _prefab; 6    
 7  public ObjectPool(T prefab) 8  { 9  _freeObjects = new   List <IPoolable>(); 10  _container = new  GameObject().transform; 11  _container. name  = prefab.GameObject. name ; 12  _prefab = prefab; 13  } 14    
 15  public IPoolable GetFreeObject() 16  { 17  IPoolable poolable; 18         if  (_freeObjects.Count > 0 ) 19  { 20  poolable = _freeObjects[ 0 ] as T; 21  _freeObjects. RemoveAt(0); 
 22  } 23         else 
 24  { 25  poolable = Object.Instantiate(_prefab, _container); 26  } 27  poolable.GameObject.SetActive(true); 28  poolable.Destroyed += ReturnToPool; 29         return  poolable; 30  } 31    
 32  private void ReturnToPool(IPoolable poolable) 33  { 34  _freeObjects.Add(poolable); 35  poolable.Destroyed -= ReturnToPool; 36  poolable.GameObject.SetActive(false); 37  poolable.GameObject.transform.SetParent(_container); 38  } 39 }  Nous pouvons maintenant créer un  pour tout objet remplissant les conditions d'héritage de  et IPoolable. j'ai enlevé le  héritage de  , réduisant ainsi le nombre de composants que nous accrocherons aux objets.   ObjectPool   Component   ObjectPool   MonoBehaviour  Il y a un problème qui doit être résolu. Plusieurs ennemis peuvent être sur scène en même temps, et chacun d'eux engendre les mêmes boules de feu. Ce serait bien s'ils traversaient tous la même chose  — il n'y a jamais trop d'économies de ressources ! Avoir une classe demandant un type d'objet spécifique est également très pratique. Une telle classe prendra en charge la génération, le contrôle et l'élimination éventuelle de l'objet. Cette option est le meilleur choix car la gestion de chaque  individuellement dans le projet est un défi.   ObjectPool   ObjectPool  Pour compléter les exigences de base de  , nous devons générer un nombre défini d'objets lors du chargement de la scène. Pour éviter tout problème de consommation de ressources, nous inclurons une fenêtre de chargement. Commençons à mettre cela en œuvre maintenant.   ObjectPool  Nous allons créer une entité supplémentaire  dans la mise en œuvre finale de  . Cette classe contrôlera le travail avec des objets créés à partir d'un préfabriqué :    PoolTask   ObjectPool                                                                                                                                                       public class PoolTask 2 { 3  private readonly List <IPoolable> _freeObjects; 4  private readonly List <IPoolable> _objectsInUse; 5  private readonly Transform _container; 6    
 7  public PoolTask(Transform container) 8  { 9  _container = container; 10  _objectsInUse = new   List <IPoolable>(); 11  _freeObjects = new   List <IPoolable>(); 12  } 13    
 14  public void CreateFreeObjects<T>(T prefab, int  count) where T : Component, IPoolable 15  { 16         for  (var i = 0 ; i < count; i++) 17  { 18  var poolable = Object.Instantiate(prefab, _container); 19  _freeObjects.Add(poolable); 20  } 21  } 22    
 23  public T GetFreeObject<T>(T prefab) where T : Component, IPoolable 24  { 25  T poolable; 26         if  (_freeObjects.Count > 0 ) 27  { 28  poolable = _freeObjects[ 0 ] as T; 29  _freeObjects. RemoveAt(0); 
 30  } 31         else 
 32  { 33  poolable = Object.Instantiate(prefab, _container); 34  } 35  poolable.Destroyed += ReturnToPool; 36  poolable.GameObject.SetActive(true); 37  _objectsInUse.Add(poolable); 38         return  poolable; 39  } 40    
 41  public void ReturnAllObjectsToPool() 42  { 43  foreach (var poolable in _objectsInUse) 44  poolable. Reset (); 45  } 46    
 47  public void Dispose() 48  { 49  foreach (var poolable in _objectsInUse) 50  Object.Destroy(poolable.GameObject); 51        
 52  foreach (var poolable in _freeObjects) 53  Object.Destroy(poolable.GameObject); 54  } 55    
 56  private void ReturnToPool(IPoolable poolable) 57  { 58  _objectsInUse. Remove(poolable); 
 59  _freeObjects.Add(poolable); 60  poolable.Destroyed -= ReturnToPool; 61  poolable.GameObject.SetActive(false); 62  poolable.GameObject.transform.SetParent(_container); 63  } 64 }  PoolTask aura des fonctionnalités supplémentaires :  1. Suivre les objets que nous avons lancés dans le monde afin que, si nécessaire, ils puissent être détruits ou remis dans la piscine à un moment précis ;  2. Génération d'une quantité prédéterminée d'objets libres.  Enfin, créons un ObjectPool qui répondra à tous nos besoins et prendra entièrement en charge le contrôle et la génération des objets :                                                                                                                            public class ObjectPool 2 { 3  private static ObjectPool _instance; 4  public static ObjectPool Instance => _instance ??= new  ObjectPool(); 5    
 6  private readonly Dictionary<Component, PoolTask> _activePoolTasks; 7  private readonly Transform _container; 8   
 9  private ObjectPool() 10  { 11  _activePoolTasks = new  Dictionary<Component, PoolTask>(); 12  _container = new  GameObject().transform; 13  _container. name  = nameof(ObjectPool); 14  } 15    
 16  public void CreateFreeObjects<T>(T prefab, int  count) where T : Component, IPoolable 17  { 18         if (!_activePoolTasks.TryGetValue(prefab, out  var poolTask)) 19  AddTaskToPool(prefab, out  poolTask); 20        
 21  poolTask.CreateFreeObjects(prefab, count); 22  } 23    
 24  public T GetObject<T>(T prefab) where T : Component, IPoolable 25  { 26         if (!_activePoolTasks.TryGetValue(prefab, out  var poolTask)) 27  AddTaskToPool(prefab, out  poolTask); 28         return  poolTask.GetFreeObject(prefab); 29  } 30    
 31  public void Dispose() 32  { 33  foreach (var poolTask in _activePoolTasks.Values) 34  poolTask.Dispose(); 35  } 36    
 37  private void AddTaskToPool<T>(T prefab, out  PoolTask poolTask) where T : Component, IPoolable 38  { 39  var taskContainer = new  GameObject 40  { 41             name  = $ "{prefab.name}_pool" , 42  transform = 43  { 44  parent = _container 45  } 46  }; 47  poolTask = new  PoolTask(taskContainer.transform); 48  _activePoolTasks.Add(prefab, poolTask); 49  } 50 }  L'utilisation de Singleton peut attirer votre attention - ce n'est qu'un exemple. Vous pouvez personnaliser l'utilisation dans votre projet - il peut être en cours d'exécution  via les constructeurs ou l'injection via Zenject.   ObjectPool  Nous avons la version finale de notre  méthode dans  :    Cast   Enemy                           public class Enemy : MonoBehaviour 2 { 3  [SerializeField] private FireBall _prefab; 4  [SerializeField] private Transform _castPoint; 5    
 6  public void Cast() 7  { 8  FireBall fireBall = ObjectPool.Instance.GetObject(_prefab); 9  fireBall.transform.position = _castPoint.position; 10  fireBall.FlyInDirection(transform.right); 11  } 12 }  Nous obtenons un objet du type dont nous avons besoin pour le traitement immédiat en raison de l'utilisation de générique.  regroupera les tâches internes selon le préfabriqué — s'il y en a plusieurs avec le  composant, le pool les traitera correctement et vous donnera le bon. Cette approche aidera à générer n'importe quel objet pour la scène de jeu.   ObjectPool   FireBall  Cependant, soyez prudent lorsque vous travaillez avec des éléments d'interface utilisateur : lors du déplacement d'un objet entre des transformations parent avec des  , le  de l'objet lui-même va changer. Si vous avez une interface utilisateur adaptative dans votre projet, les transformations avec le composant canvas changeront leur  en fonction de l'extension. Je vous conseille de faire cette opération simple :    localScale   localScale   localScale         poolable.GameObject.transform.localScale  = Vector2. on e ;  Vous pouvez utiliser 3 scripts dans d'autres options :  ,  , et  . N'hésitez donc pas à les ajouter à votre projet et à utiliser le pattern Object Pool à 100% !   ObjectPool   PoolTask   IPoolable

The code in this story is for educational purposes. The readers are solely responsible for whatever they build with it.

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

Read My Stories

Cet audio est produit dans la langue originale de l'histoire !

Comment améliorer votre projet de jeu à l'aide du modèle ObjectPool ? (Un guide d'unité)

About Author

COMMENTAIRES

ÉTIQUETTES

CET ARTICLE A ÉTÉ PARU DANS

Related Stories

Vous voulez gagner un concours d’écriture HackerNoon ? Voici ce que recommandent les gagnants du concours #crypto-api

Libérer la puissance de l’IA. Une revue systématique des techniques de pointe : résumé et introduction

Créer des produits cryptographiques centrés sur l'utilisateur : l'importance des retours clients

Croissance des crypto-monnaies : créer des profils d'utilisateurs efficaces

Vous voulez gagner un concours d’écriture HackerNoon ? Voici ce que recommandent les gagnants du concours #crypto-api

Libérer la puissance de l’IA. Une revue systématique des techniques de pointe : résumé et introduction

Créer des produits cryptographiques centrés sur l'utilisateur : l'importance des retours clients

Croissance des crypto-monnaies : créer des profils d'utilisateurs efficaces

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps