The amount of people who think this is unoptimized because it checkes every single frame is too damn hign. It goes back to the NES era and if the collision checks are just bounding-box overlap checks it's constant time O(1). To everyone stating it should be event based: how do you think the engine knows an event happens? Spoiler alert: by checking it every frame... Those events are syntax sugar. Y'all need to have a look under the hood of engines a bit more. In this case how physics engines work and the sheer amount of math heavy lifting they need to do. Like how a single collision resolution requires 10-20 of geometry-aware collision checks (which is not constant but O(n*m)) per collision per frame on top of accurately keeping track of velocities, forces/acceleration. And yes they do that every frame 😱
O(1) is asymptotic time complexity. That's doesn't mean it's not a poor use of resource. Collision detection overall is a heavy operation when performed every frame. Events are low level checks that usually are optimized by game engines. Yes, In a 3d game, there are many collision checks per frame. But that doesn't mean that processing resources are infinite. Every game should use resources efficiently. That, when paired with a previous video about collision checks while jumping, justifies these comments
Most of the AAA games are guilty of it. Because of ever increasing competitiveness, devs usually completely ignore optimizations. This results in ever increasing demand for beefier GPUs when older ones could've worked just fine
@@simplepotato24 BB checks are literally 1 (in best case) 4 (in worst case) integer comparisons, as opposed to powering up a 2D-Physics engine and using the built in collision events, as most people suggest here. Which under the hood, does exactly the same, but instead of a simple collision check it's a SAT or other much heavier algorithm, that works with every type of polygon. I get what you're saying but on a modern CPU you could literally have a million of those enemies and you would still run at 750fps @3GHz and that is assuming you're only using one CPU core. Premature optimization is a waste of dev time, which they can spend on fixing something that actually matters.
@@powertomatoit is already using a 2d physics engine. Not only that, it is using a generic collision algorithm to check for collisions(which is probably the worst case). My main point is that we can avoid all that and check for only the x coordinates to be within a bound Yes, it would mean that code becomes difficult to manage. But it also means that it becomes easier to scale down to less powerful devices like phones(where we have to worry about battery usage), or even raspberry PIs. I get it that even mobile processors are more than capable of rendering such a game at ridiculous frame rates. But consider that these generic collision checks are used frequently in this game. It's not about premature optimization. It becomes easier to add new levels and features in future without worrying a lot about frame rates and computer specifications
I disagree with a lot of these comments complaining about how this is unoptimized and will cause bad performance. A game engines built in collision check has to run every frame anyway, that’s just the nature of detecting collision.
yes they have to check collisions every frame, but with some other method that doesn’t use this, it would have one less object to detect collisions for
I'd bet money that less than 10% of all these commenters have ever even started an IDE in their entire lives. This is a perfectly fine approach to this solution that's very efficient and flexible.
The way I do this, is to have extra tiles that only collide with enemies and not the player. And I code the enemies to turn around when they hit a block so that automatically works. :) Also, first! XD
@@eboatwright_ Interesting idea, although then you have to place a tile at every edge where an enemy can get to. Not that it's a bad idea, I just prefer a less rigid method where I can just drop an enemy anywhere and it works.
@@paulblart7378 Yeah definitely, the game I implemented this in had really small levels so it wasn't too inconvenient haha, but yeah I make my enemies more robust in my newer projects ^^;
This comment section makes it awfully clear that the loudest people are often the dumbest. As if checking for a couple collision every frame is somehow going to make a 2D pixel platformer slow down on modern day hardware. Big ups for these shorts, I bet they inspire many people even if they don't end up commenting!
you can probably do if statement checks that keeps track of how long it takes for the creature to get from one edge to the other, then simplifies the query to make it work every few 0.1 seconds or whatever it asks. of course youd need to make somthing else for games that have changing surfaces that utilize nav meshes, but i think this is deff probable
The purpose of the short is to inform potential game developers who are into this sort of stuff, it doesn't have to be super optimized just enough to explain to the average viewer
This isn't really expensive at all. Collision checks happen per frame no matter what, the expensive part of the check is the code that runs when a collision occurs. I could have an object in mid-air that has a collider on it. The collider would check to see if it collided with "something" per frame. If it doesn't then the collider check will just move on to the next collider out of the thousands of them it has to check per frame.
@@breadmilkYT That's literally worse than this approach in every single way though? Now you need to run collision checks AND make sure you place invisible objects everywhere! That's super excessive!
In the first example, I’d prefer to add 2 patrol points. I think this is more flexible because the entity just moves from point A to point B. Assuming that no gravity component is added and tiles under the entity never change, I can completely ignore tile collisions for this NPC and only check for player or weapon collisions.
I really wanted to learn this for my game because my AI always gets stuck on polygons and sometimes even in normal flat terrain but I couldn't find any tutorial online smh
You mean ur collider is physical instead of a trigger? (For unity, colliders can either be trigger or not trigger), also you can maybe use a ray cast on two edges of the character to check for collision.
I've recently found an old game project I made in 2017/2018. I'm just a hobbyist and that was an absolute disaster (after that game I tried to make an other unsuccesful game and never more touched the hobby until now). Anyways, the point is that to make this behavior in the enemys, I just made TWO INVISIBLE OBJECTS, one for left side and one for right side, and put them anywhere there was enemys. When they hit the invisible objects, turn around and moves in the opposite direction. Totally unpractical and amateur shit.
can i know , how to actually code the conditions for the query , im dumm i can't figure it out , i try with if statement but the ennemis just start walking back and forth at the end of the platform xD
OMG THX A LOT I STARTED UNITY A FEW WEEKS AGO I ALREADY KNEW LIKE A COUPLE OF THE THINGS TO DO THIS BORROWED SOME CODE FROM MY OTHER CODES IN THE SAME PROJECT AND DID SOME THINGS FOR ENEMY TO MOVE AND CHECK IF ITS GROUNDED AND IT WORKS I CANT BELIEVE IT THX A LOOOOT
Way easier to just compare the location of its side and the location of the side of the platform. Just a simple if statement instead of a whole function that iterates over multiple objects
What? Why? You do realize every piece that code needs to be constantly cycled through line by line anyway, right? Sure there are functions you don't want to call every frame, but a simple 2d collision check is perfectly chill.
![[BAEMON NEWS 7] NEW ALBUM COMING IN](http://i.ytimg.com/vi/wtVeAPimOyo/mqdefault.jpg)
The amount of people who think this is unoptimized because it checkes every single frame is too damn hign. It goes back to the NES era and if the collision checks are just bounding-box overlap checks it's constant time O(1).
To everyone stating it should be event based: how do you think the engine knows an event happens? Spoiler alert: by checking it every frame... Those events are syntax sugar.
Y'all need to have a look under the hood of engines a bit more. In this case how physics engines work and the sheer amount of math heavy lifting they need to do. Like how a single collision resolution requires 10-20 of geometry-aware collision checks (which is not constant but O(n*m)) per collision per frame on top of accurately keeping track of velocities, forces/acceleration. And yes they do that every frame 😱
O(1) is asymptotic time complexity. That's doesn't mean it's not a poor use of resource. Collision detection overall is a heavy operation when performed every frame. Events are low level checks that usually are optimized by game engines. Yes, In a 3d game, there are many collision checks per frame. But that doesn't mean that processing resources are infinite. Every game should use resources efficiently.
That, when paired with a previous video about collision checks while jumping, justifies these comments
Most of the AAA games are guilty of it. Because of ever increasing competitiveness, devs usually completely ignore optimizations. This results in ever increasing demand for beefier GPUs when older ones could've worked just fine
@@simplepotato24 BB checks are literally 1 (in best case) 4 (in worst case) integer comparisons, as opposed to powering up a 2D-Physics engine and using the built in collision events, as most people suggest here. Which under the hood, does exactly the same, but instead of a simple collision check it's a SAT or other much heavier algorithm, that works with every type of polygon.
I get what you're saying but on a modern CPU you could literally have a million of those enemies and you would still run at 750fps @3GHz and that is assuming you're only using one CPU core. Premature optimization is a waste of dev time, which they can spend on fixing something that actually matters.
@@powertomatoit is already using a 2d physics engine. Not only that, it is using a generic collision algorithm to check for collisions(which is probably the worst case). My main point is that we can avoid all that and check for only the x coordinates to be within a bound
Yes, it would mean that code becomes difficult to manage. But it also means that it becomes easier to scale down to less powerful devices like phones(where we have to worry about battery usage), or even raspberry PIs.
I get it that even mobile processors are more than capable of rendering such a game at ridiculous frame rates. But consider that these generic collision checks are used frequently in this game.
It's not about premature optimization. It becomes easier to add new levels and features in future without worrying a lot about frame rates and computer specifications
I disagree with a lot of these comments complaining about how this is unoptimized and will cause bad performance. A game engines built in collision check has to run every frame anyway, that’s just the nature of detecting collision.
yes they have to check collisions every frame, but with some other method that doesn’t use this, it would have one less object to detect collisions for
I'd bet money that less than 10% of all these commenters have ever even started an IDE in their entire lives. This is a perfectly fine approach to this solution that's very efficient and flexible.
Remember, toby fox who made undertales, makes 1000 lines of switch statements and hundreds of if statements, yet he still succeded.
This is why i think red koopas are smarter than regular koopas
The way I do this, is to have extra tiles that only collide with enemies and not the player. And I code the enemies to turn around when they hit a block so that automatically works. :) Also, first! XD
Pretty easy and practical
@@butterflytr3077 Thanks ^^
@@eboatwright_ Interesting idea, although then you have to place a tile at every edge where an enemy can get to. Not that it's a bad idea, I just prefer a less rigid method where I can just drop an enemy anywhere and it works.
@@paulblart7378 Yeah definitely, the game I implemented this in had really small levels so it wasn't too inconvenient haha, but yeah I make my enemies more robust in my newer projects ^^;
This comment section makes it awfully clear that the loudest people are often the dumbest. As if checking for a couple collision every frame is somehow going to make a 2D pixel platformer slow down on modern day hardware.
Big ups for these shorts, I bet they inspire many people even if they don't end up commenting!
I love your Monogame/LOVE2D Tutorial !!
Btw I made a Circle spin with XNA 4.0 ebook I'm pretty happy to learn what's a sprite sheets
based on the 2 shorts ive watched, which both have checks that happen every frame, this is nearly the most unoptimized game ever
you can probably do if statement checks that keeps track of how long it takes for the creature to get from one edge to the other, then simplifies the query to make it work every few 0.1 seconds or whatever it asks. of course youd need to make somthing else for games that have changing surfaces that utilize nav meshes, but i think this is deff probable
The purpose of the short is to inform potential game developers who are into this sort of stuff, it doesn't have to be super optimized just enough to explain to the average viewer
@@benjitb2955You could also just have invisible objects at the edges that tells the enemy to turn around when it touches it
This isn't really expensive at all. Collision checks happen per frame no matter what, the expensive part of the check is the code that runs when a collision occurs.
I could have an object in mid-air that has a collider on it. The collider would check to see if it collided with "something" per frame. If it doesn't then the collider check will just move on to the next collider out of the thousands of them it has to check per frame.
@@breadmilkYT That's literally worse than this approach in every single way though? Now you need to run collision checks AND make sure you place invisible objects everywhere! That's super excessive!
In the first example, I’d prefer to add 2 patrol points. I think this is more flexible because the entity just moves from point A to point B. Assuming that no gravity component is added and tiles under the entity never change, I can completely ignore tile collisions for this NPC and only check for player or weapon collisions.
I really wanted to learn this for my game because my AI always gets stuck on polygons and sometimes even in normal flat terrain but I couldn't find any tutorial online smh
You mean ur collider is physical instead of a trigger? (For unity, colliders can either be trigger or not trigger), also you can maybe use a ray cast on two edges of the character to check for collision.
if;GonnaFall then;don't
Lol true
Nice explanation
I found that left collision is harder to check and you are need to use a tiny gap by tiled map.
Why is it a trick? How else would you do that?
Green koopa:
I've recently found an old game project I made in 2017/2018. I'm just a hobbyist and that was an absolute disaster (after that game I tried to make an other unsuccesful game and never more touched the hobby until now). Anyways, the point is that to make this behavior in the enemys, I just made TWO INVISIBLE OBJECTS, one for left side and one for right side, and put them anywhere there was enemys. When they hit the invisible objects, turn around and moves in the opposite direction. Totally unpractical and amateur shit.
I use godot which has is_grounded build into the CharacterBody2D by its basically the same under the hood
Thanks.
can i know , how to actually code the conditions for the query , im dumm i can't figure it out , i try with if statement but the ennemis just start walking back and forth at the end of the platform xD
What is more heavy to the engine, this or the use of raycasts?
How can I solve if I have a limited resource machine and I need to use a rectangular collision area in the main character? Any hints?
Not sure what a "limited resource machine" is. Do you mean finite state machine? And you'll have to elaborate because I'm not sure what you're asking.
please make more of these, im new to this stuff, and these are helping me.
Explained simply for everyone and new friendly thx
Heyy I just wanted to know which language is this . I'm new to game dev
Question, is this more efficient that raycasts?
It works, and optimization seems like a bit of a non-issue. Don't see the problem here lmao
Did you use Raycasting or just Colliders?
Any of them works but I think raycast is the standard
UPD no this doesnt lag i was wrong
develover: does this
also delveloper: why my game is so big and lags on my nasa supercomputer
Instead of complaining please share a better solution
???
Game name?
why no raycasts?
Raycast?
OMG THX A LOT I STARTED UNITY A FEW WEEKS AGO I ALREADY KNEW LIKE A COUPLE OF THE THINGS TO DO THIS BORROWED SOME CODE FROM MY OTHER CODES IN THE SAME PROJECT AND DID SOME THINGS FOR ENEMY TO MOVE AND CHECK IF ITS GROUNDED AND IT WORKS I CANT BELIEVE IT THX A LOOOOT
Im sorry but what is this engine?
Godot
Way easier to just compare the location of its side and the location of the side of the platform. Just a simple if statement instead of a whole function that iterates over multiple objects
That's too smart for me, i would do raycasts
How to rot your computer in 2 easy steps
What? Why? You do realize every piece that code needs to be constantly cycled through line by line anyway, right? Sure there are functions you don't want to call every frame, but a simple 2d collision check is perfectly chill.
this is a certified if !place_free(x,y) moment