A simple collision approach

Collision is one of the core elements in game-development. Without collision we weren’t able to bring the most simple games to life. But there are a LOT of ways to start dealing with this particular problem since it’s not as simple as it sounds.

Possible complications:

  • We have to figure out who is colliding with each other
  • We have to specify who is allowed to interact with each other
  • We need a system which is not to complicated to expand
  • How detailed will our collision be?
  • How much performance can we sacrifice for convenience?

These are just some of the problems and questions you might face if you are dealing with this particular problem.

The big engines solved this very well with some interesting approaches, but this article is going to show, how one COULD!!! implement an own 2D collision approach.

I will try to focus on the theoretical part of the idea and how the idea works instead of coding everything into the last detail.

There will be a bit of code, some explanation, some code… aaand so on.

Ok let’s start. First of all I will implement a little helper class to deal with coordinates:

struct Vector2
{
 Vector2(int x = 0, int y = 0)
 : X(x), Y(y)
 {}

 int X;
 int Y;
};

static const Vector2 Origin;

Vector2 contains two int values, our X and our Y position. This class can be used to represent points as well as motions in a 2D space (I am going to presuppose that you guys are familiar with vectors in math). Our Origin is our base-Vector2 with a position of (0|0).

Now we need something which holds the info where our “collidable” begins/ends. We could save this information directly in our Actor (you will see later) but I prefer to outsource such kind of functionality to other components. We will implement a BaseCollisionBody from which we can inherit different CollisionBodies (like squares/circles) so we can easily change the collision body for our later Actors.

class CollisionBody
{
public:
 virtual bool IsCollidingWith(CollisionBody* target) = 0;
 virtual bool Contains(Vector2 pos)= 0;

 std::vector<Vector2>& GetBorderPositions()
 {
  return m_Points;
 }

 virtual ~CollisionBody(){}

 virtual void Move(Vector2 motion)
 {
  for (auto point : m_Points)
  {
   point.X += motion.X;
   point.Y += motion.Y;
  }
 }

private:
 std::vector<Vector2> m_Points;
};

This is our BaseBody. We got an IsCollidingWith() pure virtual function which will allow us to check if two Bodies are colliding with each other. We got a dynamic array which stores our border points so we can implement different forms with a different number of points. Futhermore we got a Contains() function which will later on implement the functionality to check if a point is contained by our body. Last but not least we got a Move() function which allows us to move our body.

Now we need at least one specified CollisionBody to cover the form of a sprite where we want to add collision to. I decided to go with a square.

class SquareCollisionBody : public CollisionBody
{
public:
 SquareCollisionBody(Vector2 position, int sideLength)
 {
 Vector2 pointA = position;

 pointA.X -= sideLength / 2;
 pointA.Y -= sideLength / 2;

 Vector2 pointB = position;

 pointB.X += sideLength / 2;
 pointB.Y -= sideLength / 2;

 Vector2 pointC = position;

 pointC.X += sideLength / 2;
 pointC.Y += sideLength / 2;

 Vector2 pointD = position;

 pointD.X -= sideLength / 2;
 pointD.Y += sideLength / 2;

 GetBorderPositions().push_back(pointA);
 GetBorderPositions().push_back(pointB);
 GetBorderPositions().push_back(pointC);
 GetBorderPositions().push_back(pointD);
 }

 bool IsCollidingWith(CollisionBody* target)
 {
  std::vector<Vector2>& targetPoints = target->GetBorderPositions();

  bool areColliding = false;

  for (unsigned int currentPoint = 0; targetPoints.size() > currentPoint; ++currentPoint)
  {
   Vector2 point = targetPoints.at(currentPoint);

   if (Contains(point)
   {
    areColliding = true;
    break;
   }
  }

  if(!areColliding)
  {
    bool condition1 = target->Contains(pointA) || target->Contains(pointB);
    bool condition2 = target->Contains(pointC) || target->Contains(pointD);

    areColliding = condition1 || condition2;
  }

  return areColliding;
 }

 bool Contains(Vector2 point)
 {
  Vector2 pointA = GetBorderPositions().at(0);
  Vector2 pointB = GetBorderPositions().at(1);
  Vector2 pointC = GetBorderPositions().at(2);
  Vector2 pointD = GetBorderPositions().at(3);

  if (point.X >= pointA.X && point.X <= pointB.X && point.Y >= pointA.Y && point.Y <= pointD.Y)
  {
   return true;
  }

  return false;
 }

private:
};

Ok, here we go, that’s our SquareBody implementation. In the constructor we are setting four points A(upper left), B(upper right), C(lower right) and D(lower left) and then we add them to our BaseBody::m_Points vector. We only need those four points to recognize if our square is colliding with something since we can simply check if one of the points is contained in our square. This leads to our simple two functions we are implementing for our BaseClass, Contains & IsCollidingWith. I don’t think I will have to explain those since they are quite simple. (And yes one could do this better, but this will suit our needs for this example)

The next class we will create is our Actor. I added some functions to the actor as placeholder which will give you a little view of how the class might work later. I won’t deal with these placeholders. Our Actor class will serve as base class for our other interactive classes like Character (Actors which have animations or can be moved around or which will be possessed by the AI later), EnviromentActors (Stones, Barriers etc…) or even projectiles.

class Actor
{
public:
 enum Type
 {
  actor,
  character,
  projectile,
  enviroment,
  background
 };

 class CollisionProperties
 {
 public:
  CollisionProperties(Actor::Type myType, CollisionBody* body, int n, ...)
  : m_CollisionBody(body)
  {
   va_list params;
   va_start(params, n);
 
   for (int currentArg = 0; currentArg < n; ++currentArg)
   {
     m_TypesToInteract.push_back(va_arg(params, Actor::Type));
   }
   va_end(params);
  }

  ~CollisionProperties()
  {
   if (m_CollisionBody != nullptr)
   {
    delete
    m_CollisionBody = nullptr;
   }
  }

  bool CanCollideWith(Type collisionType) const
  {
   return m_TypesToInteract.end() != std::find(m_TypesToInteract.begin(), m_TypesToInteract.end(), collisionType);
  }

  bool IsColliding(Actor* target) const
  {
   if (m_CollisionBody != nullptr)
   {
    const Actor::CollisionProperties& props = target->GetCollisionProps();

    if (CanCollideWith(props.m_CollisionType))
    {
     return
    }
   }
   return false;
  }

  void Move(Vector2 motion)
  {
   m_CollisionBody->Move(motion);
  }

private:
  Actor::Type m_CollisionType;
  CollisionBody* m_CollisionBody;
  std::vector<Actor::Type> m_TypesToInteract;
 };

 Actor(Actor::CollisionProperties* props, Vector2 position)
 : m_CollisionProps(props), m_Position(position)
 {}

 virtual ~Actor()
 {
  if (m_CollisionProps != nullptr)
  {
   delete m_CollisionProps;
   m_CollisionProps = nullptr;
  }
 }

 virtual bool IsColliding(Actor* actor)
 {
  return m_CollisionProps->IsColliding(actor);
 }

 virtual void Move(Vector2 motion)
 {
  m_CollisionProps->Move(motion);
  m_Position.X += motion.X;
  m_Position.Y += motion.Y;
 }

 virtual void Update()
 {
 //Some Stuff...
 }

 virtual void Draw()
 {
 //Some Stuff...
 }

 virtual const CollisionProperties& GetCollisionProps() const
 {
  return *m_CollisionProps;
 }

private:
 //...
 //Some Stuff...
 //...

 CollisionProperties* m_CollisionProps;
 Vector2              m_Position;
};

So this is our actor. Our actor contains a subclass CollisionProperties which will handle the collision for the actor. The properties class contains an Actor::Type member which specifies, which kind of actor we got (environment etc. see the enum) as well as the CollisionBody and a vector which contains the collision types, our actor can interact with. Our Actor is basically calling the functions we already implemented in our CollisionBody with the little difference that we can specify in our m_TypesToInteract which kind of collisions shall be ignored by our later implemented inherited subactors.

Let’s take a character for instance:

class Character : public Actor
{
 Character(const std::string& name, CollisionBody* body)
 : Actor(new Actor::CollisionProperties(Actor::character, body, 3, Actor::character, Actor::enviroment, Actor::projectile), Origin), m_CharacterName(name)
 {}

 std::string m_CharacterName; 
};

This class get’s all its features like update, draw and move from our Actor class, but it specifies which kind of actor(Actor::character) we got and which classes can collide with our character (other characters, environment actors and projectiles). This class got close to all functionalities a character needs (motion, collision, updates etc) but it remains pretty slim by now.

Okay that was a whole lot of stuff. Now we got close to all components we need for our collision together. There are only a few little things missing:

A little event class and an inherited collision event.

class Event
{
public:
 enum Type
 {
 collision
 //...
 //Some Others...
 //
 };

Event(Type type)
 : m_EventType(type)
 {}

Type GetEventType()
 {
 return m_EventType;
 }

private:
 Type m_EventType;
};

class CollisionEvent : public Event
{
public:
 CollisionEvent(Actor* a, Actor* b)
 : Event(Event::collision), m_ParticipantA(a), m_ParticipantB(b)
 {}

Actor* GetPA()
 {
 return m_ParticipantA;
 }

Actor* GetPB()
 {
 return m_ParticipantB;
 }

private:
 Actor* m_ParticipantA;
 Actor* m_ParticipantB;
};

Since you are pretty smart guys, I am pretty sure I won’t have to explain this classes to you because they are actually pretty simple so I will go on with a simple usage example of the collision eco system we just created. I will leave or actor/character creation and focus on the collection of collision events per frame.

class Engine
{
public:
 void Play()
 {
 while (m_Running)
 {
 Collision();
 Update();
 Draw();
 Present();
 }
 }
private:
 void Collision()
 {
 for (unsigned int currentActorA = 0; m_ActorPipeline.size() > currentActorA; ++currentActorA)
 {
 if (m_ActorPipeline.size() < 2)
 {
 return;
 }

for (unsigned int currentActorB = currentActorA; m_ActorPipeline.size() > currentActorB; ++currentActorB)
 {
 Actor* a = m_ActorPipeline.at(currentActorA);
 Actor* b = m_ActorPipeline.at(currentActorB);

if (a != b && a->IsColliding(b))
 {
 m_EventPipeline.push_back(new CollisionEvent(a, b));
 }
 }
 }
 }

void Update()
 {
 std::for_each(m_ActorPipeline.begin(), m_ActorPipeline.end(), [](Actor* actor)->void{actor->Update(); });
 }

void Draw()
 {
 std::for_each(m_ActorPipeline.begin(), m_ActorPipeline.end(), [](Actor* actor)->void{actor->Draw(); });
 }

void Present()
 {
 //Some Stuff...
 }

 //...
 //Some Stuff...
 //...

 std::vector<Actor*> m_ActorPipeline;
 std::vector<Event*> m_EventPipeline;

bool m_Running;
};

Okay, what do we got here. An Update() function, a draw function and our present function. Pretty basic if you ask me so I am going to leave them out. Collision().. well, that’s the interesting part. In this function we are handling our collision and there we will create our CollisionEvents and add them to our EventPipeline.

Basically we are iterating through out actor pipeline and we check our actors for collisions. If we detect a collision (remember, we specify which kind of actor may collide with which other types.), we will save a CollisionEvent with the two participating actors to our EventPipeline. What you will do with them from there on is no longer my concern since that is not part of this tutorial/article 😉

Puh, that was a whole lot of info I pushed out there. I hope some of you can get some helpful information out of this article. But hey, I know there is a lot of optimization potential in this code but optimal performance wasn’t the goal I wanted to archive with that.

The thing I like most about this approach is the little effort you will have to put into changing this one into a concurrent environment. Basically you have two ways of doing this:

First (and less effective way): You could create a task for every collision check and hand this task over to a thread pool to collect the results in future objects and process them later.

Second: You could add a pipeline for every type of collision object that you have a pipeline for environment actors, one for projectile actors and for each pipeline an own EventPipeline and so on. This way you could process one pipelines per thread and merge the events together in the end. (That’s how I would handle this, but I would handle the collision threads in a pool anyway.)

I hope you liked today’s post, that’s all for today. Have a nice day/evening whatever 😉

Advertisements

Concurrency the little bitch

Hey folks, todays post will feature some ideas, advises and conclusions about task-based concurrency programming (mostly in C++).

First of all, what actually is task-based concurrency? If it comes to threading there are basically two and a half approaches you can choose from: multithreading, multitasking, – multiprocessing.

Multithreading: This approach relies on multiple threads on which the developer can spread his workloads to reach an even resource usage and optimal performance. This approach is very low-level and requires a lot of knowledge and care of the person who is coordinating the threads. He always have to know: How many threads do I have, which threads are doing what and also (he better knows) where his threads are running. (On which cpu core for instance)

Multitasking: This one is a more high-level approach. There are some ways to get things done here. The first way: thread pooling. The developer initializes a pool of threads which keep active after they finished their work so he can pass them tasks and don’t have to create new threads all over. He (usually) don’t knows which thread is executing which task (and he also doesn’t care about it) since he just queues tasks up in the pool and the pool decides where they are going. The Second way: One could use wrappers like C++ std::async. Asyncs are (kind of) used like a thread pool. There is simply one difference. Not the developer but the “std::async framework” decides where or how the tasks are executed. If you hand a task to a std::async it could also be executed on the same thread where the result is required until you don’t explicitly tell the async object to behave another way.

Multiprocessing: You spawn multiple processes and let them communicate with each other. You are (kind of) running multiple programs wich do multiple tasks.

I will focus on multithreading/tasking in this post since I have little to no experience with multiprocessing.

Okay, this might sound like you have very little differences from multithreading to multitasking with the exception that multithreading seems to be more work. And in some way, this is actually not to far away from reality. But, and here is the point, there are reasons for both to exist.

A Realworld example for multithreading:

MessageLoop and GUI/Game thread. Let’s consider we have the following code:msgloop_m

We have our main thread which is basically our main function and we have our game thread, which is spawned and will run until the main thread exits it. The only communication between the two threads is managed through the function calls on the game object and the join on the game thread.

And an example for multitasking:update_m

We have our game thread which does some logic and which is containing the game loop ( run() ) and a thread pool which is executing little independent tasks (in this case updating actors) which won’t report back to the game thread.

Alright, let’s see: On our msgloop/gamethread example exactly know which thread is dealing with which piece of work (main() with the msg loop, gameThread with the gameloop). But how does is look for the update example? Well, until we try to figure out which thread of our pool is executing which task we would have to call any kind of thread identification from our task, so simple we don’t know who is who.

And these two examples are good for two things: Giving you guys an example where which approach may fit and giving you an example how these approaches are working.

In example one each thread executes some work completely independent from each other and sometimes they communicate to trigger actions on the other one which is basically a simple event handling pattern.

In example two one thread is creating tasks, the others are just “consuming” the tasks the game thread generates. That’s why it’s called the producer-consumer pattern.

Both of those patterns are suited for different use cases as you might recognize. The first pattern is very handy if it comes to things like controls or long-term work wich can be handled parallel or any kind of input loop or audio output, the producer-consumer pattern on the other hand is better suited if you need some small pieces of independent work to be done in parallel to the work of your long running other threads, like drawing, animation updates or simple outputs.

The p-c-pattern benefits a lot from lock free tasks but suffers even more if you need to synchronize the tasks you are pooling, since if you are locking a pool thread, you also lock some future tasks from being executed while you can easily create a new worker thread if you are managing your thread lifetimes on your own.

The best performance you can reach with a thread pool depends on the continuous and spike free stream of tasks you assign to your pool. Let’s display this in a little image:

queue_opt

In this image we got 4 pool threads which are executing work and 4 more tasks which are queued up. The next step would be each thread would grab one tasks and the queue would be empty again (or 4 more tasks could be queued). Pretty optimal isn’t it? All work is getting done fast and clean.

And this is the way you won’t like it:queue_erro

Again, 4 threads, but this time there are 6 tasks scheduled. Now let’s consider 4 are executed, 2 remain in the queue 5 more are getting added. As you might recognize (easy calculation 6 – 4 + 5 = 7) now we got 7 threads in the queue. And that’s the danger with pooling up threads and using task queues. If you throw too much work at a pool which is to small you will generate a growing backlog which will hurt your performance pretty bad. And that’s the reason why the std::async object has the option to spawn additional threads. Basically it’s the hybrid from pool to thread. I personally don’t like it too much since the standard constructor does not guarantee a parallel execution. Nevertheless, with some tricks (like the launch flag) it can get pretty handy since (at least the MSVC++ version) internally relies on a thread pool with the option to spawn a new thread if the pool is under heavy load. I have to admit, I did what each professional programmer would call bad style and implemented my own one with my own rules so I basically know how it will behave since I feel pretty confident with C++ as such but well that’s nothing I can recommend to others…

Ok, that was tasking, threading on the other hand needs a lot of synchronization to work well and sometimes it might be better for your performance since you don’t have to rely on such high-level constructs like async or pools, but well… it’s pain in the ass to get it working as intended. Your parallelization is good as long as you don’t need to access resources from multiple threads but even then, you won’t block other threads from spawning. You always have to remember: If you try to access a locked item, actually your program gets serial instead of parallel. The trick is to get your work lock free and good timed. Try to split task well thought to threads to minimize data sharing between threads and you will se a huge gain.

Usually I would hand you a picture about regular threading now but this time I decided to simply leave it be since in my opinion you can imagine it pretty well your self.

Try this. You got a railway with a crossing in the middle where the rails change the sides. (Don’t ask why, they simply do.) Now you have a train on each of the rails. Well, one of them will have to wait until the other one is passed since they don’t want to crash. And that’s exactly what your locks do. Now imagine you would do those change-of-side very often. The trains would take a lot longer to the end of the track if they would try to go parallel as they would do if they would go one after another since both could go, none of them had to wait.

Super beautiful metaphor of mine with one simple conclusion. Sometime it’s better to go for single threaded application instead of forcing threading into a super complicated program with a lot of locking work to do.

 

I hope this one were helpful to some of you. If you have any ideas, suggestions or criticism, feel free to comment.