While I am far from an expert dev, I tend to disagree on the last point when it comes to object pooling specifically. If I know the type of game I am making, I want to know if I am pooling or not from the beginning. It changes code where things die, it changes how I handle any projectile spawning mobs I may have. It has some pretty big branching effects that can be a bit messy to go back and change later. Otherwise I agree that you shouldn't optimize prematurely
Interesting, I think it is probably right when you start as a game dev. Personally, I have always find it quite easy to replace with pooling later on. It might due to fact that I know I might need to pool later so I always have clear way of Initializing / Destroying objects even without pooling.
@@obviousgame It probably depends a lot on the game too. I have mainly came up against pooling in RTS style games. If you destroy an object and instantiate a new one you don't have to worry about much. If you are pooling you need to make sure you are resetting stats and flags. And if things ragdoll on death you need to make sure you are setting them back to their non ragdoll state. It is by no means an impossible refactor, but if I am going to have hundreds of the same object, I pretty much know I am going to be pooling. I feel like it is just a wasted step to try it without. But I am sure there are a lot of situations where that doesnt apply
Never seen this clear content on object pooling before, dude that was amazing thank you very much
The video content was extremely clear, and I appreciate the excellent work you're doing.
Thanks , I hope I continue to deliver simple and clear videos!
thats a great vidéo and a good explanation of what is a pooling system
Thanks, hopefully more to come soon!
so, pool if your game will run on low-end mobile, otherwise it's optional
While I am far from an expert dev, I tend to disagree on the last point when it comes to object pooling specifically. If I know the type of game I am making, I want to know if I am pooling or not from the beginning. It changes code where things die, it changes how I handle any projectile spawning mobs I may have. It has some pretty big branching effects that can be a bit messy to go back and change later. Otherwise I agree that you shouldn't optimize prematurely
Interesting, I think it is probably right when you start as a game dev. Personally, I have always find it quite easy to replace with pooling later on. It might due to fact that I know I might need to pool later so I always have clear way of Initializing / Destroying objects even without pooling.
@@obviousgame It probably depends a lot on the game too. I have mainly came up against pooling in RTS style games. If you destroy an object and instantiate a new one you don't have to worry about much. If you are pooling you need to make sure you are resetting stats and flags. And if things ragdoll on death you need to make sure you are setting them back to their non ragdoll state.
It is by no means an impossible refactor, but if I am going to have hundreds of the same object, I pretty much know I am going to be pooling. I feel like it is just a wasted step to try it without. But I am sure there are a lot of situations where that doesnt apply