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.

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

Trop long; Pour lire

Discover Saakuru: Web3 Mass-Adoption with 0-FEES

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

Trop long; Pour lire

Les Dibrivniy

STORY’S CREDIBILITY

Code License

Guide

About Author

ÉTIQUETTES

Languages

CET ARTICLE A ÉTÉ PARU DANS...

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

Trop long; Pour lire

Les Dibrivniy

STORY’S CREDIBILITY

Code License

Guide

About Author

ÉTIQUETTES

Languages

CET ARTICLE A ÉTÉ PARU DANS...

HISTOIRES CONNEXES