Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 22 Jan 2011
Offline Last Active Apr 25 2016 11:31 AM

Posts I've Made

In Topic: Space Shooter Enemies

15 April 2016 - 01:24 AM


For complex enemy paths, using Bezier curves and/or splines might be a good starting point.  I made a basic shmup in unity and used bezier curve components from http://catlikecoding.com/unity/tutorials/curves-and-splines/


What I did: Add child objects with the spline component to the enemy spawners. Enemies which need to travel in a path have a "MoveAlongPath" component with a reference to the spline component from the spawner's child object. This reference assignment is done as soon the spawner instantiates the enemy. After that just keep incrementing the spline parameter using a hardcoded or configurable fraction (I went with 1.0/duration, explained on the link above) and get the position vector on the spline using that parameter




In Topic: Dealing with different collision responses in an entity-component system

26 June 2015 - 12:09 AM


I use a method which is similar to tiago's but is extremely simplified. I use Bullet physics as my collision detection system, artemis-cpp for the ECS architecture.


  1. Bullet has a function performDiscreteCollisionDetection() (or stepSimulation() if you want dynamics as well). After calling this, all overlapping pairs (ie colliding objects) will be available in an array that bullet maintains internally.
  2. Loop over this array (note: it's an array of btCollisionObjects so use the userPointer field to get the entity) and add a collided component to the entities in each pair
  3. The collided component in one entity stores the id of the other entity.

Here is the system logic

  • All entities having the collided component as well as a health component will have their health reduced by the amount in the other entity's damage component
  • All entities having the collided component as well as a Damage component will just destroy themselves

For your case, you can store additional info in the collided component, and use that to update the transforms of your entities so they no longer collide.

Ofcourse this might be a poor method to do this, but hopefully you can see how a collision detection system can cooperate with entities and systems.

In Topic: Slow down: Artemis C++ Port & SDL 2

17 April 2015 - 01:49 AM



I'm using artemis-cpp as well. In my case, if the number of entities passes a certain threshold the app starts slowing down. This is on a 4th gen i5 with gtx 860m. I suspect its due to the fact this implementation does not have a proper struct of array approach. Check the addcomponent function in entitymanager.cpp file, in that you can clearly see they use a Bag<component *>. A bag itself defines its array like E *data, where E can be any type. Effectively, you get

Bag<component *> components;
 // which, inside entitymanager, translates to
component **data;

See? Its an array of pointers (EDIT: Its not a technically an array of pointers but a pointer to a pointer. I said array because later its allocated and used as a normal array). Now I may be completely off here but it looks to me that this causes the code to jump around when accessing these pointers, which is what the AoS approach aims to solve. I'm at work so can't try it, but IMO using an array of plain data instead of array of pointers might help.


EDIT2: A bit offtopic, but you can get rid of that if statement by using a delayedEntityProcessingSystem to get rid of branches

In Topic: How should systems pick which entities to process? (Entity Component Systems)

07 April 2015 - 05:04 AM

You could take a look at artemis (C++ port) https://github.com/vinova/Artemis-Cpp .

What they do is similar to how phil_t described it earlier.


  • Each entity has an id, a type bitstring and a system bitstring.
  • Everytime you add a component to an entity, its type string is updated, but not the system string. Also, that entity is added to a "refreshed" array
  • At the start of your main loop, you need to call a loopstart() function ( world.loopStart() ). This function iterates over all the entities in the refreshed array
    • In loopstart, each entity that was refreshed will be acted upon by all the systems registered with the world object
    • For each system, the system's bits will be compared with the entity's type bits ( the system's bit indicates what all components/types will this system act upon)
    • EDIT: The previous point is a bit incorrect. The systems themselves will have a system bit and type bits. The system bit will identify that particular system, while the type bits will identify what all components are required if an entity wants to be acted upon by that system
    • If the entity is interested in that system(i.e. the corresponding type bit(s) is/are set), then its system bitstring will be updated, and that entity will be added to that system's actives list
  • When you call any system's update() method, it will only iterate over the entities in its actives list.
  • The only downside I see here is that your changes to an entity will not be available in the same loop. This is actually a good thing, as explained here

In Topic: Basic enemy design

07 April 2015 - 04:41 AM

How about this ?