Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am attempting to implement collisions for my truck game, where the truck can drive around the world and hit walls surrounding the level and various randomly placed walls within the level. I am able to get direct collisions working correctly. However, it is getting very complicated and tricky very quickly.

I am trying to accommodate various other collisions such as when a truck is against the wall then turns an adjacent direction or when they reverse into a wall. Both of these result in a slight collision as the image of the truck flips around to the direction the player wants to move. All of this has resulted in a whole lot of if statements to check how I should be fixing the collision. This in turn makes the player jump to random locations and "teleport" around corners, etc.

The rest of my game is fine, I am not completely new to game development or C# for that matter. It's just the logic of collisions. Any ideas on how I can approach this?

Image of the collisions I am trying to resolve:

share|improve this question
It might help to view this:… and see how they handle collisions. – CobaltHex Oct 31 '12 at 3:12
possible duplicate of Collision resolution in case of collision with multiple objects – Byte56 Oct 31 '12 at 15:10
up vote 1 down vote accepted

If your code is turning into spaghetti, it might be that you are trying to build logic to explain something that is unexplainable. I'm guessing about your code (hint, you should post it), but I have a good guess: your collision changes your objects' position/orientation, which changes how it collides, which may trigger more position changes, etc. That will rapidly turn into very strange behavior (like jumping and teleporting, for example).

Solving this will probably take a fair bit of refactoring, but it is for the best. You should try to segregate the logic which determines a collision from the logic that corrects a collision. You should also make sure that there is no strange loop of feedback like I described above; detect a collision, then guarantee that that collision is resolved. A collision correction that results in more collision is not a solution. The process should be

  1. Detect a collision
  2. Find a solution to fix it, repeat until solution actually works
  3. Apply solution and resolve collision. Do not go back to step 1 until something else changes.

A good exercise might be trying to make a flow diagram of the process. If you can't draw it using the basic structures (a straight line, a branch/join, and a single-entry/single-exit loop), then you don't have a good design.

If you can invest the time, I would reccomend this lecture from a pretty great cSci professor on the subject of writing analyzable code. It explains the general answer to the question "why doesn't my code work or make any sense?"

share|improve this answer
Can I get a comment or alternate answer to go with my down vote? – Seth Battin Oct 31 '12 at 14:12
Probably because it's not directly answering the question. Though I think it's probably the type of answer the OP needs. – Byte56 Oct 31 '12 at 15:11
+1 for "If your code is turning into spaghetti, it might be that you are trying to build logic to explain something that is unexplainable.", that's probably true 99% of the time. – pwny Oct 31 '12 at 20:10

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.