This is great. I've been using my own version of this for couple of years and it's almost the same as this. I was tired of complex MonoBehaviour solutions and I did simple but flexible option with func delegate with Get/Release to handle it basically from anywhere in your code. This allows you to have your own script, as you already have (probably with Instantiate), just reference to the prefab and viola, spawn it with Pool instead.
Been using this for a good while. Though I believe the last I've used it, I wish the feature calling 'clear' on the pool collection to just auto releases them all back to the pool than to destroy.
Hard coded dependency here, unfortunately. Projectile should not ever know about the object pool. Instead a very simple way to add an OnCompleted or OnFinished event to the projectile and assign any custom method to it there from the code where the projectile is instantiated. This way it can be kept clean. Though the ObjectPool API is a great to have tool. Thank you.
Is there a cleaner way to return the Projectile to the pool? Given the provided setup, Projectile would throw an error outside of a pooled context. There's also no indicator for those using the Projectile class that its ObjectPool variable must be set prior to use. Maybe a better solution would be to define a "OnDeactivate" event on the Projectile, which is called at the end of that coroutine. The CreateProjectile method would then subscribe to the event in a way where Release is called when it triggers. Now the Gun class completely manages the lifetime of the projectile, and the projectile is free to be used in any context.
@@AmaroLoopsCorrection, 'private' type is when you don't want other scripts to sneak on it, but it's not visible in editor, serialized field shows it in editor and keeping it isolated
@@JackMartison ye thats basically what i mean but the types they show in video are already private serialize fields so i didnt include that information
Hmm, I would have thought it should be the object's responsibility to activate or deactivate itself. Calling "SetActive()" etc inside the gun breaks separation of concerns I think. The bullet I'd expect to have an interface to implement these per object?
an Object pool? When you create and destroy objects, constantly, such as bullets or horde enemies, it is very SLOW as it generates garbage and kills performance. moving, activating, and disabling gameobjects is much faster at scale.
It's a simple way to have a relatively stable fire rate. It's only the ...Down/Up variants of the input methods you should never use in FixedUpdate due to high risk of missing the occurence.
@@MiTheMer This is not quite right. Fire rates in Update are done with Time.DeltaTime. Since FixedUpdate is, well, fixed, Time.DeltaTime = Time.Time. Also, FixedUpdate is when the physics engine runs. All collisions happen during FixedUpdate. So, for a simplified example, if Update is running at 60fps, and FixedUpdate is running at 30fps, even if you check for collisions during Update, they still only happend at 30fps. As for missing collisions, that has nothing to do with the input method and everything to do with the speed of the projectile. If a projectile is moving the equivalent of 20fps, any detection method will do. However, if it's moving at 250fps, a little coding is needed. One way I've seen is to use a raycast to determine point of impact, move the projectile to that point, and then have the physics engine do its thing and calculate what happens next. If you don't need to see the projectile after the hit, many games just use raycast and call it a day. To try and make things a little clearer, many games use the following pattern. Update - To get inputs, such as movement, the fire button and so on. FixedUpdate - To check for collisions and calculate things like if the player was knocked down or knocked back. LateUpdate - Now is when things are actually moved. Note that you can't do this sooner, because FixedeUpdate needs to determine where things will be moved to. Sorry for the mini tutorial. Hopefully it helped.
i do not like the fact that the bulletObject calls the GetComponent API in fixedupdate. it's a very bad practice and will lead to issues. instead that should be changed to have a cached rigidbody.
These OOP patterns are useless to create a large open-world multiplayer game with C#, because the performance will always be much slower than DOTS or C++
@@eyellen Nope, C++ is always faster because the machine doesn't need to interpret the strongly-typed language. This is why big software houses and plug-in developers always use C++ to create their products
C++ is not a panacea, you will still have bad performance if you write bad code even if you're writing machine codes. Each language is good for their purpose and C++ is often chosen in gamedev because it's faster language but it doesn't mean using C++ solves all of your problems, well written C# game cab be more performant than bad written C++ game
@@eyellen The same algorithm will work faster with C++ than C#. Unity just chose C# to make scripting faster, because C++ takes a longer time to compile. If C# was performant enough to create a large open-world multiplayer game with millions of animated objects, Unity wouldn't have created DOTS
the worst IDE that can exist, if I mean visual, both the code and the community; You have to see how many complaints there are about this garbage everywhere and the fact is that Bill's sick person selling his Win 11 makes it slower to program on 5-year-old computers so they buy the new computers because the old ones don't have any use for it. win 11; The code does not auto complete, Unity seems lost, lag and a white screen in visual. bad unity garbage.
what are you talking about? "The code does not auto complete" just sounds like someone didn't setup VS properly. "bad unity garbage" Also VS has nothing to do with Unity, if you want to hate the IDE then blame Microsoft.
Thank You for making this Programing Patterns (for videogames) series.
This is great. I've been using my own version of this for couple of years and it's almost the same as this. I was tired of complex MonoBehaviour solutions and I did simple but flexible option with func delegate with Get/Release to handle it basically from anywhere in your code. This allows you to have your own script, as you already have (probably with Instantiate), just reference to the prefab and viola, spawn it with Pool instead.
Wonderful new API. Thanks to the devs for adding this.
I've been using this for quite sometime now great feature
I was actually about to program my own, thank you xd
this is good tutorial from unity XD
This is kinda cool, probably works better then when i coded it myself 😂
Been using this for a good while. Though I believe the last I've used it, I wish the feature calling 'clear' on the pool collection to just auto releases them all back to the pool than to destroy.
Awesome! I didn't know of the existence of ObjectPool.
Thanks!
Hard coded dependency here, unfortunately. Projectile should not ever know about the object pool. Instead a very simple way to add an OnCompleted or OnFinished event to the projectile and assign any custom method to it there from the code where the projectile is instantiated. This way it can be kept clean. Though the ObjectPool API is a great to have tool. Thank you.
Is there a cleaner way to return the Projectile to the pool? Given the provided setup, Projectile would throw an error outside of a pooled context. There's also no indicator for those using the Projectile class that its ObjectPool variable must be set prior to use.
Maybe a better solution would be to define a "OnDeactivate" event on the Projectile, which is called at the end of that coroutine. The CreateProjectile method would then subscribe to the event in a way where Release is called when it triggers. Now the Gun class completely manages the lifetime of the projectile, and the projectile is free to be used in any context.
TaroDev shows a method that is very similar to this one. It's also similar to what I do.
Thanks a lot!
when do you use the serialize field and what is it used for?
also the pooling looks very helpful thank you for that
You use serialize field to be able to set a type in the unity editor, but not make it available to use from another script
@@AmaroLoops thank you
@@anim_atix885 no worries
@@AmaroLoopsCorrection, 'private' type is when you don't want other scripts to sneak on it, but it's not visible in editor, serialized field shows it in editor and keeping it isolated
@@JackMartison ye thats basically what i mean but the types they show in video are already private serialize fields so i didnt include that information
Where is the interface keyword in the IObjectPool declaration? Was it a mistake or am I missing something?
Thx♥♥♥
Hmm, I would have thought it should be the object's responsibility to activate or deactivate itself. Calling "SetActive()" etc inside the gun breaks separation of concerns I think. The bullet I'd expect to have an interface to implement these per object?
❤❤
Do we need to import some sort of pakage from asset store to use Object Pool APi ?
No, it's included starting with 2021
@@MiTheMer got it thanks 😊
You didn't really explain why we would do this. Is there some savings on transfer of information?
an Object pool? When you create and destroy objects, constantly, such as bullets or horde enemies, it is very SLOW as it generates garbage and kills performance. moving, activating, and disabling gameobjects is much faster at scale.
Nice
Why get input from fixed update tho
It's a simple way to have a relatively stable fire rate. It's only the ...Down/Up variants of the input methods you should never use in FixedUpdate due to high risk of missing the occurence.
@@MiTheMer This is not quite right. Fire rates in Update are done with Time.DeltaTime. Since FixedUpdate is, well, fixed, Time.DeltaTime = Time.Time. Also, FixedUpdate is when the physics engine runs. All collisions happen during FixedUpdate. So, for a simplified example, if Update is running at 60fps, and FixedUpdate is running at 30fps, even if you check for collisions during Update, they still only happend at 30fps.
As for missing collisions, that has nothing to do with the input method and everything to do with the speed of the projectile. If a projectile is moving the equivalent of 20fps, any detection method will do. However, if it's moving at 250fps, a little coding is needed. One way I've seen is to use a raycast to determine point of impact, move the projectile to that point, and then have the physics engine do its thing and calculate what happens next. If you don't need to see the projectile after the hit, many games just use raycast and call it a day.
To try and make things a little clearer, many games use the following pattern.
Update - To get inputs, such as movement, the fire button and so on.
FixedUpdate - To check for collisions and calculate things like if the player was knocked down or knocked back.
LateUpdate - Now is when things are actually moved. Note that you can't do this sooner, because FixedeUpdate needs to determine where things will be moved to.
Sorry for the mini tutorial. Hopefully it helped.
i do not like the fact that the bulletObject calls the GetComponent API in fixedupdate. it's a very bad practice and will lead to issues. instead that should be changed to have a cached rigidbody.
where is unity 6 is 2024
love me some anime girls in thumbnail
it takes
two frinds pass
667
These OOP patterns are useless to create a large open-world multiplayer game with C#, because the performance will always be much slower than DOTS or C++
Are you sure?
Algorithms are >>> than language execution speed etc.
Try bubble sort in python and C++, the performance will be similarly awful
@@eyellen Nope, C++ is always faster because the machine doesn't need to interpret the strongly-typed language. This is why big software houses and plug-in developers always use C++ to create their products
@@containedhurricane That's what IL2CPP is for.
C++ is not a panacea, you will still have bad performance if you write bad code even if you're writing machine codes. Each language is good for their purpose and C++ is often chosen in gamedev because it's faster language but it doesn't mean using C++ solves all of your problems, well written C# game cab be more performant than bad written C++ game
@@eyellen The same algorithm will work faster with C++ than C#. Unity just chose C# to make scripting faster, because C++ takes a longer time to compile. If C# was performant enough to create a large open-world multiplayer game with millions of animated objects, Unity wouldn't have created DOTS
the worst IDE that can exist, if I mean visual, both the code and the community; You have to see how many complaints there are about this garbage everywhere and the fact is that Bill's sick person selling his Win 11 makes it slower to program on 5-year-old computers so they buy the new computers because the old ones don't have any use for it. win 11; The code does not auto complete, Unity seems lost, lag and a white screen in visual. bad unity garbage.
what are you talking about? "The code does not auto complete" just sounds like someone didn't setup VS properly. "bad unity garbage" Also VS has nothing to do with Unity, if you want to hate the IDE then blame Microsoft.
Your CEO sucks. Get his greedy little hands out of others bank accounts and make him grow up.
John Riccitiello was replaced by Jim Whitehurs in October