Assuming a 2D world, break it into two separate scaling operations. Scale the world’s x axis by the character’s width, and then the world’s y axis by the character’s height.

Note that this trick only worlds with convex geometry. So a concave shape needs to be broken into convex parts. This is one of the reasons why Quake and its kind force level designers to use convex brushes when making maps.

But it does allow you to easily calculate when the character hits the wall during collision updates as a line verses plane intersection test. No more fast moving players getting outside the world between collision updates.

The thing is they do. When many games notice you’re outside the map they warp you back in. And it’s these “Oh shit get the player back in the game” hacks that are the source of many glitches.

Just think of HL2, if an NPC gets stuck under/in/on/whatever an object they warp to the next bit of the story. The speedrunners noticed this and abused it to get through the in-game cutscenes.

It gets trickier if your building blocks are arbitrarily shaped, like Quake’s are. If I recall correctly, Quake has three hard-coded collision hulls to support three sizes of moving object, all perfect cubes. A testament to how much you can simplify without anyone noticing.

Collision detection is so much fun. Now add rigid body dynamics :)

I do still watch them occassionally, and they are still good for a chuckle, and it’s not that he’s terrible at judging games either, but I can only stomach so much of the snark.

Incidently, despite them being VERY good, in both plot, art style, and programing, he’s disowned them, saying that as far as he cares he’s never made them.

Our solution… make the walls thicker. *Cough*

You reckon this’ll change the way you review regular games?

I did the simple box thing as soon as I’d figured out basic collision, and it was good. But it was abstract, and I needed to know if this made sense and felt right for a human. I didn’t wanna start making levels for this movement system before I knew it worked.

Again, I’m still a very green coder, and have yet to even start work on anything more complicated than a simple text adventure, but I like to think that my input might still be valuable.

I know I will take those fundamental laws to heart from now on. I guess it’s good to get input from others, because as well developed and thought-out your point of view is, there still might be something hiding that someone standing a few feet (Or yards, meters, miles, etc) to your side will see as a glaringly obvious thing.

The funny thing is that you end up being proud of a system, a few lines of code, that no one ever knew was needed. And it can be easy to forget you have to test if it is actually fun.

I recommend breaking all coding challenges into tiny pieces, especially when you think you already know all the steps to take, so you can quickly iterate and easily spot problems that could be impossible to find in a big program. It also allows you to test for fun more often.

Have fun!

Please believe me when I tell you this is exactly backwards. Your top priority needs to be making the gameplay fun. That way you can make huge sweeping changes to the design without it being a big deal. When your collision detection is awesome but you realize it would be more fun if he could pass through walls like they were jelly, just the thought of ripping all that code out is going to kill your enthusiasm. If collisions are really, truly vital to your gameplay, stick with the easiest square bounding box you can for now.

I know the bugs stick out like a sore thumb, but it will be so much easier to fix them the right way once you’ve actually decided on the design. Full disclosure: I haven’t finished any of the games I’ve started, because I don’t listen to my own advice.

“I have to code this bit again? Ffff-“