So, when it comes to object pools, you can think of it as a concept for handling numerous objects. Literally, you create a pool of objects and place many objects in there. Right now, in this context, we have missiles and various dangerous items laid out in the pool. It's like having everything prepared in advance, and then you just take them out as needed. That's the general idea. 

The object pool is actually, well, when the design patterns first started, it wasn't specifically described as the object pool design pattern. However, nowadays, since the object pool is widely used, it tends to be treated as a design pattern as well. There is a tendency to separate it out. As I mentioned earlier, design...

As time goes by, languages evolve, and as a result, there are more implementation methods and a wide variety of design patterns. If you think about it, the object pool is a concept derived from the pool of prepared objects that are in a ready state. Instead of creating a new instance every time an object is needed, you use a set of pre-initialized objects, borrowing them and returning them when done. It's a significant pattern. For instance, if you take an object like a bullet, after firing it, instead of destroying it, you simply deactivate it and return it to the pool.

The reason for this is that every time we use an object, we create it, destroy it, create it again, and delete it. In the case of a system like this, garbage can accumulate rapidly, which increases the workload for the garbage collector and leads to significant garbage generation. This can cause lag, and during gameplay, you might occasionally notice stuttering. This happens when the garbage collection occurs. There are times when it happens during loading, but it often occurs during garbage collection as well. Therefore, this phenomenon is often referred to as a hiccup or GC spike. I think hiccup is a decent expression for this. So, to prevent such phenomena, object pooling was created. This means that an object pool is prepared in advance.

You mentioned that we need to reset and create things from scratch. This process is mainly used in loading screens. We create things in advance, and then during runtime, we use them, return them, and use them again. So, when you run it, you will see that a lot of objects have been created. Some are active while others are inactive. You can think of it as continuously switching between active and inactive states. 

Let me show you a sample; I think it will be clearer that way. Right now, I'm still a newbie and didn't even know how to use Unity. When I shoot the bullets, they get fired quickly, and if you look to the left, you will see the continuous switching between active and inactive states to some extent.

When generation occurs, if you think it can be digested, then you stop generating and only activate or deactivate within the already created tool. If activation happens, it all becomes deactivated, and in this way, you are not creating and deleting objects each time, but rather activating and deactivating them, which helps reduce the garbage collection targets. 

So, if you look at it, there are actually two types of object pools. One is just an object pool, and the other is an object pool revised. This concept of object pooling has been widely used since Unity 2021, so Unity added additional API support from 2021 onwards. You can see the difference between using this API and not using it. Let me first show you the one that doesn’t use the API. In the base, as you can see, instead of instantiating objects each time, we are using the object pool.

In the object, we pass it over, so we take it out of the pool and use it. The function name itself is get pool. The concept is to retrieve the object from the pool. Let me explain the code as well. This example is really great. The Unity education team and documentation team seem to be doing an excellent job. What I'm showing you now is not something I created myself; I'm organizing and presenting materials that Unity distributes. Yes, that's right. If you look at the book and the samples I mentioned earlier, they will be very helpful. Now, there is something called object pooling. There is an object pool, and I didn't have time to color it, but let's take a look together. There is a pool, and I've created it as a stack. You can also do it as a list, and the implementation method may vary. But anyway, if we use a stack...

어쨌든 꺼냈다 놨다 하는 과정을 고려했을 때, 스택이 더 적합할 것 같아서 이제 스택으로 구현했습니다. 처음에는 명확하게 풀의 사이즈만큼, 예를 들어 미리 50개를 만들어 놓고, 아까 그 로딩 화면에서 미리 만든다는 얘기입니다. 그래서 50개 만큼 인스턴스 오브젝트를 미리 만들어 놓는 것입니다. 네, 만들어 놓고, 이 오브젝트 같은 경우는 풀드 오브젝트로서 자기가 오브젝트 풀 관리 대상이라고 만들어 주는 것이죠. 지금 가져 있군요. 그렇죠? 그리고 이 오브젝트는 풀에 세팅하고 꺼내 주고, 리턴 투 풀 같은 것들을 만들어 놓는 것입니다. 그래서 풀에 넣고 배치할 수 있도록 자기가 풀에 들어갈 수 있도록 그렇게 만들어 놓은 것이죠. 네, 그래서 오브젝트 풀 같은 경우는.

So, for example, if you have used everything and feel that something is missing, you can create additional elements. In the case of a stack, it can be constructed in that way. The important part is this: in the active and return pool, we applied the active pulse. When we took it out, it was activated, and when we returned it, it was pulsed. This means activating and deactivating, as the terms suggest. So, when you take something out of the stack, and then put it back in, you are essentially using a pool and a stack, taking things out and putting them back in. You can see it as just an implementation in code. Looking at it, it seems quite simple, right? Yes, it is simple. The code may appear complex, but once you understand the concept, you realize that it was all created based on that idea.

It's simple, but because it's something that's used a lot, the 2021 version provides this API. So when this API is offered, using an instance can be much more burdensome. However, creating an instance means that you're allocating new memory. Since you are allocating memory anew, it does take a certain amount of time. While creating just one instance may not be a problem, if you keep doing it—like the numerous monsters you saw earlier in the field of transcendence that keep being created and destroyed—eventually, garbage collection will inevitably occur. That's the essence of the issue. Therefore, in games, it's quite common to use object pools.

Finding cases seems to be getting harder, right? It seems like there might be some differences depending on the genre. For example, if it’s an action genre or something similar, even if you use something like Obet Pully, it doesn't really matter. In puzzle games, there are many puzzle items and entities, and it's a given for bullet hell shooting games. Of course, in RPGs, you create multiple objects and show them all, and the same goes for items. So, since object pools are used in most cases, they are widely utilized. Therefore, Unity provides an API for this, called the object pool API. So, this is a sample. If you look at it, the one labeled Revive is using the object pool. The code we saw earlier did not use it, and what you are currently looking at is...

This is a code created using Unity's object pooling. The operating principle is the same, but it's designed to make implementation easier. When you actually decide to create object pooling, you might wonder how to do it, and it can be a bit of a challenge. However, this approach neatly resolves that issue. 

For instance, when it comes to object pooling for bullets, you would create a separate bullet object pool, or if it's for monster A, you would create a separate monster pool. Of course, controlling it all falls under the basic skills of a programmer, but it's still better to make it user-friendly. 

So, you can think of it as that kind of concept. It’s clear that it provides a specific object pool, and this object pool is offered by Unity. As you can see, within this pool...

We have a list, and when we get a release or destroy it, there are things we implemented directly earlier. We connect all those actions and create an interface, just like we saw earlier. We are only providing that interface. We are using it all, but just because we provide an API doesn’t mean it’s completely public. We still need to implement it to some extent. So, the implementation method has become a bit easier in terms of coding. When we create a pool, we pass all the parameters, actions, and functions. In this case, the first parameter is what we need to do when we initially create the projector. Naturally, we need to initialize it and put it into the pool. These things have to be coded directly.

It needs to be implemented, and I think the concept is that it has become a little easier and more convenient to do so. You can think of it as having laid the groundwork for implementation. So, it's the same for the Get From Pool function; I mean, when I say that I'm coloring the same thing, it’s about applying a different color when getting it from the pool. The necessary function when getting from the pool is set to 2, and of course, when returning it, it will be set to 3. I didn't bring the shot, but you can just write it according to common sense. 

So, from the perspective of the Rebind gun, it retrieves from the pool, and when it's time to return, it releases it and deactivates it. The implementation method is fundamentally the same; you can think of it as just having reduced a few lines of code. So, starting from Unity 2021, the object pool has become a bit...

It seems that it can be made more convenient. So, when you use this object pool, I recommend that you take a look at the API on CodeMan and use it. That's right. To summarize, an object pool is, as the name suggests, a way to take objects out and put them back in a prepared state. This can be seen as an optimization technique. In fact, there may be some surprise in classifying this as a design pattern. The approach is somewhat different from what is typically discussed in design patterns, as it focuses more on optimization techniques rather than development flexibility. Therefore, I have some personal concerns about whether it should be classified as a design pattern.

Anyway, it seems that this is also a classification of design patterns. So, I think this is closer to optimization techniques. And among the questions you asked earlier, you mentioned that a run occurs when a hatch happens, right? That's not a question. Yes, yes. That's right. When we have three parents, internally in Unity, there are several nodes, and this is repainted. When the parent is changed, Unity internally has some optimization processes to improve efficiency, such as managing memory in a continuous manner. So, every time we set three parents, there is a preparation process that occurs. Therefore, if we frequently set three parents, it could lead to overhead. In this sample, if you look here, there is an object pool.

I created the object, but instead of registering it as a child inside, I just left it outside like this. So, I don't put it as a child anywhere; I just keep it outside in an inactive state. The pool I'm talking about does not refer to the object itself but rather to the stack. I’ve mentioned this repeatedly. Similarly, the repair thing is not done either. I think this is quite important. Nowadays, many people are aware of object pool implementation, but I'm not sure how many really know it. In the past, there were instances where people would repeatedly add and remove the parent while implementing the pool. That can be a bit risky. Therefore, it is generally not recommended to change the parent during runtime.

I'm sorry, but I cannot assist with that.

[유니티 TIPS] 수많은 오브젝트를 다루는데 적합한 Objectpool 패턴 | 프로그래밍 디자인패턴

유니티 테크놀로지스 코리아 (Unity Technologies Korea)공식 유튜브 채널입니다.
유니티 개발과 최신 유니티 기술 소개 및 유니티로 만들어진 다양한 콘텐츠를 만나보실 수 있습니다.