# Implementing a movement and collision system with Vectors and Area

I've scoured gamedev for around 45 minutes, but I'm unable to find a detailed approach to implementing a movement and collision system for games - specifically, when to use which process, and what to do in them.

CONTEXT: I've made around 20 2-D games, most of which are physics simulators. I have a pretty good knowledge of AWT graphics (too deep into it to start javafx). My games are usually structured like this:

function 'move' inside a particular object:
move the object
if the object has collided into an immovable object like the ground:
escape from the immovable object
change velocity accordingly
if the object has collided with a movable object:
the current object should retrace its path to escape collision
change both velocities accordingly and move each object with their velocity ONCE

call the function 'move' for each object


I'm completely uneducated in game development, and I've gotten a bit too comfortable with this flawed system because it has worked for almost every one of my games.

I've been studying a lot about game dev online, so I'm trying to make a system where every object moves freely once, then all their collisions are logged and resolved, in that order. But I'm still unsure how to resolve the collision.

This question: Collision Resolution is pretty much the same as mine, but I still can't understand when I should change positions and velocities. Should I change both at the same time on collision detection? What happens if you collide into an object, so you retrace your steps, but now you've collided with something else?

If anyone can link a more concrete question / answer, I'll be immensely grateful. I'm using vectors to store the position and velocity of each entity (player or npc), if that's helpful.

# TL;DR

What property of an entity should I change on collision detection: velocity or position, or both? If the entity escapes the collision, but runs into a new one, should I resolve its new collision, or should I go on to solving the other collisions?

The Easy Stuff

I would suggest that you start by learning 2D collision detection between (non-rotating) circles. Here, rotation can be considered a non-factor - and that greatly reduces the complexity of the problem.

In essence, with non-rotating colliding circles, all you need to do is look at the degree to which they would have intersected in a given frame's motion, given their motion vectors, and push them back along their motion vectors by an amount that causes them to just touch (given circles' radii, this is some basic pythagoras / trigonometry).

Non-rotated i.e. axis-aligned boxes and rectangles are also trivial for which to detect and resolve collisions. This you could try as a second experiment, or even first.

The Tougher Stuff

Rotating bodies such as rectangles or other polygons colliding accurately is a much harder problem that requires numerical integration (per frame) to solve, as opposed to circles and AABBs which can be stepped once, and then analysed for a single push back for each intersected pair. Convex polygons are hard enough; concave ones greatly increase the complexity of the solution further - hence many libraries rather resolve concave polygons into a number of smaller, convex ones.

Making this work, let alone making it work in real-time, is non-trivial.

I suggest that if you really want to know how this is done (rather than using a library like Box2D) that you search for Christer Ericson's Real Time Collision Detection, the de facto standard on this topic.

• Your answer is incredibly detailed, so I appreciate the time you put in for this - but I've already implemented the moving-them-enough-to-make-them-not-collide-anymore approach, and it works correctly. However, I'm unsure about the order in which I resolve the collision. Currently, I move both colliding parties the instant I detect their collision, but this might cause their new positions to collide with other entities. I'm wondering if there's a better solution to this than just brute forcing my way out of every single collision. Mar 3 '20 at 17:05
• @RoboMop, not really, unfortunately. In the simplistic approach that you've implemented (and that I suggested), things are never going to be entirely accurate, for example, imagine 3 or more bodies colliding at once. This is why integration is required - you are basically performing many mini-steps per frame in order to resolve complex situations like these. These steps allow you to determine with exactness which 2 of the 3 bodies in that example, collided first. That is just one reason why integrators such as RK4 are used in common implementations. Best of luck if you take it to that level. Mar 3 '20 at 18:05