One side project I am working on right now is a 2d space shooter I am developing with my son. The idea is to have top down look, have each player control some kind of ship and fly in an enclosed area filled with space debris and shot opponents. An important aspect of this game is that the space debris can be moved around the arena and used creatively to capture opponents, prevent them from achieving their goals, etc.
As part of the project I was thinking we will skip game engine altogether because I wanted to teach my son a bit more about how to structure the application, etc. I thought in future we would use a ready game engine but at least once we would go through the exercise of implementing everything.
Everything was fine until we approached the problem of collision detection and handling. That's when things went downhill pretty quickly. Even with my theoretical math background I was soon consumed with just enormous amount of corner cases and finally decided to relent and use Box2d for this.
I am not a professional game developer, but I have over 20 years of development experience + math background and I still made the mistake of underestimating the problem. It really seems easy problem when you state it and just becomes exponentially more and more complex as you start digging into details.
Did your game require realistic physics collisions? If not, this might be unnecessary complexity. Almost no 2D shoot'em up game before 2000, and very few afterwards, go this route. Here's the common method to make a shmup with very simple rectangle comparisons:
But if your space debris objects are supposed to collide and agglomerate realistically, and if the player ships are supposed to have difficulty pushing a cluster of heavy objects out of the way, then using a physics library is sensible.
The point is you fly in a small spaceship in an arena, you hide behind obstacles, you shoot with a small variety of weapons and you use your weapons to either shoot the enemy directly or rearrange the map to make life difficult for your them. The collisions need to be realistic because you need to be able to predict what is going to happen when you hit things a certain way.
It is just a concept we are playing with.
Another part of that concept is that this game is meant for small kids that can't read. There is not a single letter or digit in the entire game. No menu. You just start the controller and get immediately pulled into the game.
And another feature is we wanted the game fun because the control feel fun and immediate. So we are experimenting a lot with what it means for the controls to be enjoyable.
Did you come across Verlet Integration [1]? It is quite convincing and usable for a lot of use cases, and is actually quite simple. I surprised myself when I was able to create a basic physics systems in a couple of hours with this great tutorial [2].
As part of the project I was thinking we will skip game engine altogether because I wanted to teach my son a bit more about how to structure the application, etc. I thought in future we would use a ready game engine but at least once we would go through the exercise of implementing everything.
Everything was fine until we approached the problem of collision detection and handling. That's when things went downhill pretty quickly. Even with my theoretical math background I was soon consumed with just enormous amount of corner cases and finally decided to relent and use Box2d for this.
I am not a professional game developer, but I have over 20 years of development experience + math background and I still made the mistake of underestimating the problem. It really seems easy problem when you state it and just becomes exponentially more and more complex as you start digging into details.