My Problem With Collisions

Ever since I started my journey in the lower-level stage of game programming, collisions have been the bane of my existence. Even when I used Unity, I had problems with organizing collisions. But I really felt the pain of collisions when I delved deep into game programming. I even once quit making games from scratch entirely and decided to use Godot twice just because of collisions. I ultimately went back and decided to give collisions another try but it still was difficult. Every time I decide to make a proper game that isn't a clone of a classic game like Pong or Space Invader, I always give up when collisions come around. I always stand up and tell myself that I'll do it this time but I just end up suffering for a week and then giving up. I decided to learn Rust just to procrastinate collisions on a game I was working on. I don't regret learning Rust, of course, I still learned something at the end of the day. However, I eventually decided against using Rust (that's a new article idea right there) which, in my eyes at least, was just a waste of time. But why? Why are collisions so hard for me? Well, my friend, it's simple: I slept during math classes.

Geometry and trigonometry are the most important concepts you should learn if you want to delve deep into the lower-level game programming environment. You will benefit a lot from learning them. Collisions, rendering, and even gameplay code will require you to have geometry and trigonometry knowledge. They are very important subjects every game programmer should know about. And, as you can see, I'm suffering currently because I dismissed them as being nothing more than stupid concepts I'll never use in my life.

That's why engines exist. To make you not care about these concepts. The engine takes care of all of these things for you. You don't have to worry about anything. If you just want to make games and you're not a programmer by trade, then who cares? Let the engine do these things for you. But, if you are a programmer by trade then you have to... no, need to learn these concepts. They are fundamentals. Always learn the fundamentals. Even if these fundamentals will make you gouge out your brain from your ear holes, you still need the fundamentals.

"Alright then," you might say, "why not use a physics engine?" That's a good question, my friend. Truly, why don't I use a physics engine?

The Anatomy Of A Physics Engine

Physics engines are plenty. Box2D, Chipmunk, Physac, Bullet, and Havoc are just some of the physics engines that are out there. Every game engine out there has a physics engine running under the hood, be it a custom or third-party physics engine. There's a physics engine for both 2D and 3D. But what are physics engines? If you made a player character stop after hitting a tile does that mean you made a physics engine? Well, the short answer is no. Physics engines are much more than basic collisions. Physics engines are what they sound like they try to simulate real-world physics. They have a range of functionalities. Rigid bodies, chains, cloth physics, car physics, hair physics, and many many more. They try their best to simulate real-life physics just like the one that Issac Newton guy made up. Of course, not everything that happens in real life gets replicated one-to-one in games. That's why the word simulate is there. They aren't trying to make a replica of real-world physics, rather, they try to make the player feel as though the physics are real.

Even though it might seem shocking, the most crucial part of a physics engine isn't actually the physics, it's actually the optimizing that occurs under the hood to be able to handle potentially multiple bodies colliding and bouncing with each other. The physics are all there. They are all just formulas you can find on Wikipedia, articles, scientific papers, or books. You can find YouTube videos of physics professors explaining the concepts to you. However, making sure that the game runs on a smooth 60 FPS despite there being one thousand bodies actively colliding with each other is something you cannot find so easily. Usually, these physics engines break the bodies up into a quadtree or some other kind of data structure. The bodies only check collisions with other bodies that have a possibility of colliding with them. If a body is on one end of a map and another body is on the other end, then there is absolutely no use in checking for collisions between these two bodies since, obviously, they will never collide, or at least not in this frame. But that's not the only optimization a physics engine will have to do. There are also the complex and computationally heavy calculations the physics engine will have to make. These calculations are filled with sines, cosines, tangents, and many more expensive operations that need to be carried out. How could a physics engine make all of these calculations while steadily keeping a smooth frame rate? That's the difficult part of a physics engine. Not the physics formulas but the optimizations it has to make.

But why am I telling you all of this? Why is the anatomy of a physics engine relevant to what this article is about? Because you need to understand how big of a package a physics engine is.

Why You Should And Shouldn't Use A Physics Engine

If you decided to make a game where the main focus is the physics then you have to use a physics engine. Games like Gish or Angry Birds have too many physics elements in them, making them perfect candidates for games that need a physics engine. The main draw of those games is that the character moves (or flies in the case of Angry Birds) using physics simulations. In these games, the characters move in a very satisfying manner all thanks to the physics engine. Car games where tires and car pieces fly all over the place after a collision are also another example of games that simply need a physics engine. The developers of those games had to either make their own physics engine or use a third-party one like Box2D or Havoc. While making a physics engine is a very fun-sounding idea, making it in the middle of making your game is not a very fun-sounding idea. A game where the main draw is satisfying physics just simply needs a robust and optimized physics engine. There are just too many edge cases and calculations these games would have to handle if they weren't using a physics engine. Let the math do the physics, not you.

But what if you're not making a physics-focused game? What if you just want to make a simple 2D top-down RPG like Zelda or Earthbound. "Physics" in these games is only collision-based. Check if a character is colliding with an entity, if that entity is static then stop the character from moving on that axis, and that's it. The only "physics" that matters in these games is stopping the player or any other character from walking over a static tile. Perhaps there's a knockback effect when the player hits the enemy or when the enemy hits the player but that can be accounted for. It can easily be programmed by hand. Do you need a physics engine in that case? Of course not! That's the reason I explained to you the anatomy of a physics engine before. I wanted to let you know that integrating a whole physics engine just for a simple, "stop the player if they collide with a rock" is just way too much. It's an overkill. A physics engine is so much more than just a collision resolution tool. It's a whole-ass engine. It can handle sooooo many edge cases. Again, if making a "physics game" is your intention, then, by all means, use a physics engine. But if all you care about is basic collision resolution between a static tile and a "moving" entity then a physics engine is just way too much.

"But wait," you say, "aren't you using a physics engine?" Well of course I am! I'm using Box2D in particular. Why? Because I'm a hypocrite!

Why Am I Using Box2D?

Box2D is the physics engine I decided to use because I have the most "experience" with it. I never use it to finish a game but I still dabbled in it a lot to know enough about how it works. I tried to use other 2D physics engines of course but none of them quenched my lust as much as Box2D did. However, that still doesn't answer the question: why am I using a physics engine? Am I trying to make a "physics-based" game?

If you read the first devlog then you would know that Our Only Hope is far from a physics-based game. It's way simpler than that. As discussed before, however, I always had a problem with collisions in my past games and this game is no different. I tried, in a small prototype of the game, to make collisions work without a physics engine but what I discovered was that I was going to spend too much time on it and I wanted to finish this game before the end of October. That's the personal deadline I set for myself. However, one day when I didn't particularly feel like working on the game, I decided to jump into an empty project and try my hands at collisions once again. And, in a surprising turn of events, I actually managed to pull it off. I had two rigid bodies colliding with each other and made static vs rigid body collision resolution work as well. The code wasn't the best and it needed a lot of optimizing but it didn't matter as I had made an accomplishment that I never thought I would make. I now have an example of how to do collision resolution. However, I could not put it in the actual game. At that point, I was too deep into the Box2D rabbit hole. If I had decided to abandon Box2D and go with my implementation of collision resolution, then I would have added at least another week or two into the project's lifetime. That might seem trivial but it wasn't. If I decide to abandon a system in favor of a better and more robust system than the one I had just made, then I would never finish this game. If I changed the physics system why not change the camera system as well? I always hated the scene system why not change that as well? I don't like how Raylib handles audio then why not make a 2D audio framework? The examples might be too extreme but you get the point. Programming at such a low level will make you get your hands dirty a lot. You would have to touch so many horrible and disgusting things in your journey (like math, YUCK!). So, having a tool like Box2D which makes you forget about a major part of the game's infrastructure is a great thing. It will save you time for the time being and it will help you get to the parts that you like faster.

Simply put, I used Box2D because I wanted to finish this game. I wanted to make this game in 2 months with no excuses. There are a lot of other things in this game that I've never implemented before and if I had to think about another big problem like collisions (a problem I never solved up to that point), I would have probably quit the project immediately just how I quit the other projects in the past. It's weird to say, but it's true. Box2D was a deal-breaker. I would have either not used it and risked abandoning the project or used it and put up with the extra load it carried. My choice was obvious. I did not want to put this project on the shelf just like its brothers and sisters. I wanted to finish it.

Even though Box2D is a great tool and it did help me a lot and saved me a lot of time, I would probably never use it again.

Why I'll Never Use Box2D Again

There's a reason why I never finished a game with Box2D before. It's a great tool, of course. It's robust and very well-optimized. There are also a lot of games that used Box2D throughout the years. However, despite that, I never had a use for it. I never made a physics-based game before and, while it does sound fun, I don't have the intention of ever making a physics-based game. The collisions in my game are always very simple. Collisions that are more akin to older 2D games like Metal Gear, Castlevania, Metroid, and the like. That's all I need and all that I require. Despite that, I still went with Box2D as discussed before.

This project, as you can tell, is very small. It's a game that can be made in a month with no external help. Very simple and very small. Deciding to bring Box2D into the project was a difficult decision to make. As said before, physics engines carry a lot of weight. They aren't behemoths per se, but they are still big. And what made it even worse was my usage of Box2D. Right now, as it stands, I only use Box2D for basic collision resolution. That's it. Nothing more. Gravity is turned off since this is a top-down game. There's no need for gravity in a top-down game obviously. The reason why I decided to leave game engines and develop games from scratch is because I thought that using a game engine--an engine that has a lot of features you will not need--was overkill for the games I wanted to make. Despite that, I still have the same problem but just on a smaller scale.

But that's not the only problem. Box2D has a lot of nuances that make me want to kill Jeff Bezos. For example, Box2D uses real-world measurements as its unit system. Not pixels but meters and kilograms. This means any value you pass into Box2D will need to be converted into meters and any value you receive from Box2D will need to be converted into pixels. I understand it's perhaps better for the calculations but it can get very annoying when working with it. Besides that, there are a lot of little problems that Box2D has. For example, you need to have at least one class that inherits from a b2ContactListener class in order to know which bodies collided with whom. That might not seem like a problem but if you're trying not to use any OOP features then it can be annoying having only one part of your codebase using OOP while everything else is using a different paradigm. That's the reason Our Only Hope is object-oriented. I wanted to use the b2ContactListener class but I also wanted a consistent paradigm for the codebase. But then there's the Ghost vertices problem that Box2D has. Which I won't go into here.

Despite the nuances, Box2D is still like any other tool. It has its pros and cons. No tool out there is perfect and Box2D is no different. You are the one who has to decide if the tool is perfect for your needs or not. They're your problems and you're the only one who will need to decide on which tool is the best for the job. Just remember to always make those games no matter the tool you're using. If the tools help you to make your game, then go ahead. Even though if that tool doesn't make the game-creation process faster but you still enjoy it, then why not? Just make games and enjoy it.

Huzzah!