Hi there, my name is Oles Dibrivniy, and I'm a Unity Developer at . We create products at the intersection of EdTech and GameDev — apps and web products for children's development. Now our products have more than four million users. Keiki If someone asks you while job interview about the programming patterns you use in game development, one of the first things you should mention is ObjectPool. It is based on an elementary principle: after completing its task, the object is not deleted but moved to a separate environment and can be retrieved and reused. This pattern directly affects the user's perception of the app, that's why it is crucial. It should be the basis of 99% of game projects' optimization. This article may not be relevant for programming gurus but for beginners vice versa. Here I will use examples to explain why this pattern is essential. How do things go without ObjectPool? First, we'll analyze the project case without ObjectPool, starting with the setting. We have a relatively simple scene with the protagonist and two enemies throwing fireballs: Let's consider what the fireball itself will look like. The fields and will be responsible for the fireballs' movement; the method will work after a collision — the object with the FireBall component will be destroyed: 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 } The enemy will also look quite 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 } You can call the method from any point in your project or animation events. We have the following flow: the enemy created a fireball and launched it in the direction of his gaze. The fireball is destroyed by reaching the first obstacle on the way. Cast This approach seems optimal, but it is one of the worst options. Let's analyze everything point by point: and are expensive operations: calling them every few seconds causes delays and lags. This is especially noticeable when working with gadgets like smartphones, where saving every byte of memory is necessary. You can open the Unity Profiler and type Instantiate in the search field of the Hierarchy window to see how "painful" these operations are for the game. There will be the following: 1. Inefficient use of the CPU and memory of the device. Instantiate Destroy Sure, I’ve increased the number of fireballs created by each enemy at a time to 500 to maximize the dramatic effect. However, it's easy to imagine projects with even more constantly created and deleted objects — especially when dealing with UI elements or particles. These processes occur constantly in runtime. The player may experience a noticeable drop in frames due to the constant memory allocation after you spawn hundreds of objects on the stage. The method removes the game object from the scene, sending it to the garbage collector. You have no control over when or how the collector processes it. By the way, is very sneaky. It deletes the game object itself, but its components can continue to live separately. This may happen if another object is linked to this component. For example, it may be a subscription to a certain event. 2. Everything you've created must be destroyed and cleaned. Destroy Destroy Different classes are responsible for creating and destroying an object, and dozens of them can be in the project. Finding what and where is created or deleted isn't a trivial task sometimes — and I'm silent about controlling objects in the hierarchy now. 3. Code control. Let's integrate ObjectPool into the project! After defining the problem, let's move on to its solution. As I mentioned earlier, the principle of the ObjectPool pattern operation is simple: after finishing work with the object, it is not deleted but hides in the "pool." The object can be retrieved and reused from it: One entity will be responsible for creating, reusing, and destroying an object — we'll call it . We can make it look like this to work with a fireball: 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 } The list appears in this code. We will store the created fireballs that have done their work there. The enemy will now look like this: _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 } The root of our problem: how can we return the fireball to the pool? We can't rely on the enemy; he does not know when the fireball will be destroyed. We also don't want to give fireball knowledge about , because it will create unnecessary connections. ObjectPool I hope you've noticed that I made the method private. Therefore, we will use one of the basic C# patterns — observer, and its implementation — . The fireball will look like this now: 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 } will subscribe to the event after passing the object to the world: 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 } It remains to hang the Object Pool on the object with the component — congratulations! The garbage collector will rest until you move to another scene or close the game. We have ObjectPool in its basic implementation, but we can improve it. Enemy Interfaces and generics: the perfect match to ObjectPool The isn't the only object type we'll run through the object pool. You must write a separate for each to work with other types. This will expand the code base and make the code less readable. So, let's use imitations and generics. FireBall ObjectPool Each object we run through the must be bound to a specific type. They must be processed independently of the particular implementation. Keeping the basic inheritance hierarchy of the objects that the pool will process is essential. They will inherit from , at least. Let's use the IPoolable interface: ObjectPool MonoBehaviour public interface IPoolable 2 { 3 GameObject GameObject { get ; } 4 event Action<IPoolable> Destroyed; 5 void Reset (); 6 } We inherit from it: 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 } The last task is to teach to work with any objects. IPoolable will not be enough because Instantiate can only create a copy of the object with the property. We will use ; each such object inherits from this class. is also inherited from it. As a result, we will get the following : 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 } Now we can create an for any object that fulfills the conditions of inheritance from and IPoolable. I removed the inheritance from , thus reducing the number of components we will hang on objects. ObjectPool Component ObjectPool MonoBehaviour There is a problem that needs to be solved. Several enemies can be on the stage at the same time, and each of them spawns the same fireballs. It would be great if they all went through the same — there can never be too much resource savings! Having one class ask for a specific object type is also quite convenient. Such a class will take over the object's generation, control, and eventual disposal. This option is the best choice as managing every individually in the project is challenging. ObjectPool ObjectPool To complete the basic requirements of , we need to generate a set number of objects when the scene loads. To avoid any resource consumption issues, we will include a loading window. Let's start implementing this now. ObjectPool We will create an additional entity in the final implementation of . This class will control work with objects created from one prefab: 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 will have additional features: 1. Tracking the objects we have released into the world so that, if necessary, they can be destroyed or returned to the pool at a specific moment; 2. Generating a predetermined quantity of free objects. Finally, let's create an ObjectPool that will meet all our needs and completely take over the control and generation of objects: 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 } The use of Singleton may catch your eye — it is only an example. You can customize the usage in your project — it can be running through constructors or injection through Zenject. ObjectPool We have the final version of our method in : 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 } We get an object of the type we need for processing immediately because of using generic. will group internal tasks according to the prefab — if there are several with the component, the pool will process them correctly and give you the right one. This approach will help generate any object for the game scene. ObjectPool FireBall However, be careful when working with UI elements: when moving an object between parent transforms with different , the of the object itself will change. If you have an adaptive UI in your project, transforms with the canvas component will change their depending on the extension. I advise you to do this simple operation: localScale localScale localScale poolable.GameObject.transform.localScale = Vector2. on e ; You can use 3 scripts in other options: , , and . So feel free to add them to your project and use the Object Pool pattern for 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

이 오디오는 이야기의 원래 언어로 제작되었습니다!

ObjectPool 패턴을 사용하여 게임 프로젝트를 향상하는 방법(Unity 가이드)

About Author

코멘트

태그 걸기

이 기사는 다음에서 발표되었습니다.

Related Stories

볼츠만 뇌 이론에 대한 간략한 소개

AI의 힘을 발휘하세요. 최첨단 기술의 체계적 검토: 개요 및 소개

보이지 않는 레이어: 사용자 인터뷰가 대체할 수 없는 자산인 이유

사용자 중심의 암호화 제품 만들기: 고객 피드백의 중요성

볼츠만 뇌 이론에 대한 간략한 소개

AI의 힘을 발휘하세요. 최첨단 기술의 체계적 검토: 개요 및 소개

보이지 않는 레이어: 사용자 인터뷰가 대체할 수 없는 자산인 이유

사용자 중심의 암호화 제품 만들기: 고객 피드백의 중요성

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps