Awesome tutorials. I'd really like to see more in-depth (and perhaps opinionated) tutorials on code organization and abstraction. Collision detection is a simple task and it's important to explain how to do this task, but where is the best place to put this game logic to maximize code reuse? In the game's main loop? In the "Sprite" class? In each individual game object? How to deal with other collision types happening at the same time like moving platforms, player and enemy hitboxes, player and enemy projectiles? In what orders things should be done in the main game loop? Questions like these will eventually be answered as the project evolves, so there's no need to rush. I just ask that you, please, share with us a bit of your experience on how the "pieces" fit together in addition to explain what they do individually.
nice idea, thanks for the videos man i did my thing i little differently tho i just do the Dx/Dy update and then check if this move WOULD collide me with anything and if yes i set the speed to zero (this allows me to do 1 pass only instead of 2 for x and y) setting speed to zero might probably be changed to something else in the future but for now it works but great vid nonetheless and I command your dedication and effort for doing the videos
Loving the series so far. Think you can do a similar one on monogame / C# after it is over? One where you build an rpg / some sort of game that is. The series you already have on monogame is great too.
I didn't get the need for two loops/separate axis check, how the teleportation to some other place will happen if we are not changing x when dx is 0 (similiar with y). Btw awesome playlist 💙
hmmm got notification recommended this , no idea how to code in go also first time here (i guess time to learn go from here , btw what are the pros of go , i am comming from a c and java, some gd script and python background)
sprite.X += sprite.DX is very suboptiomal. it should be: sprite.X += sprite.DX * deltaTime and even that would be wrong because of phasing issues, so the real solution would be to divide deltaTime in equally sized, smaller chunks and progressively add that small portion of DX to X and check each time if a phasing happens, which would not be caught otherwise, because from one frame to another, they could swap places with a high enough velocity, without them overlapping as the jump is that great... an optimization to catch this is a dynamically sized bounding box. the bounding box at 0 velocity is simply the normal bounding box. the bounding box at a specific velocity is the area around the sprite, whhere it can go. only do that chunkwise, computationally heavy check when those dynamic boundinb boxes overlap, because then there is the potential for that issue.
Game dev aside, you’re really good at breaking down larger projects / functionality. I’m loving this series!
thank you that means a lot !
They way you describe and break it down is brilliant 👏 very easy to follow 🎉
Awesome tutorials.
I'd really like to see more in-depth (and perhaps opinionated) tutorials on code organization and abstraction.
Collision detection is a simple task and it's important to explain how to do this task, but where is the best place to put this game logic to maximize code reuse? In the game's main loop? In the "Sprite" class? In each individual game object?
How to deal with other collision types happening at the same time like moving platforms, player and enemy hitboxes, player and enemy projectiles?
In what orders things should be done in the main game loop?
Questions like these will eventually be answered as the project evolves, so there's no need to rush. I just ask that you, please, share with us a bit of your experience on how the "pieces" fit together in addition to explain what they do individually.
nice idea, thanks for the videos man
i did my thing i little differently tho
i just do the Dx/Dy update and then check if this move WOULD collide me with anything and if yes i set the speed to zero (this allows me to do 1 pass only instead of 2 for x and y)
setting speed to zero might probably be changed to something else in the future but for now it works
but great vid nonetheless and I command your dedication and effort for doing the videos
Love this tutorial. Can't wait for the next video. 🙏
I was waiting for so long for the new episode!
High quality content, thanks! 🎉
Loving the series so far. Think you can do a similar one on monogame / C# after it is over? One where you build an rpg / some sort of game that is. The series you already have on monogame is great too.
I didn't get the need for two loops/separate axis check, how the teleportation to some other place will happen if we are not changing x when dx is 0 (similiar with y). Btw awesome playlist 💙
please keep going!
hmmm got notification recommended this , no idea how to code in go also first time here (i guess time to learn go from here , btw what are the pros of go , i am comming from a c and java, some gd script and python background)
You started with vs code, Now your in vim
sprite.X += sprite.DX is very suboptiomal.
it should be:
sprite.X += sprite.DX * deltaTime
and even that would be wrong because of phasing issues, so the real solution would be to divide deltaTime in equally sized, smaller chunks and progressively add that small portion of DX to X and check each time if a phasing happens, which would not be caught otherwise, because from one frame to another, they could swap places with a high enough velocity, without them overlapping as the jump is that great...
an optimization to catch this is a dynamically sized bounding box. the bounding box at 0 velocity is simply the normal bounding box.
the bounding box at a specific velocity is the area around the sprite, whhere it can go.
only do that chunkwise, computationally heavy check when those dynamic boundinb boxes overlap, because then there is the potential for that issue.
Delta time is not necessary because Ebitengine's update function is on a fixed timestep. For more information, read:
github.com/tinne26/tps-vs-fps