You are viewing...

Celice, part 3

Updated on April 14, 2013 at the 20th hour
Posted under:

DISCLAIMER: All views are considered my own and you should not draw any conclusions on associates.

Celice is an ECS with a modular game engine. One of the goals for awhile has been to figure out how to register and resolve interactions between two entities. This is critical for collision detection resolution among other resolvers.

Think about it this way, a ship in a game fires a bullet, which is basically an entity initialized with a velocity and other attributes. Imagine this bullet hits an enemy, a collision detection system detects this and adds the collision information to the entity. A collision resolver then looks at this information and decides what to do from the information. The resolver has the intended behavior.

That's how I modeled the interactions system in Celice. It works pretty well, except for one among many other cases I will find: collision with two entities and doubling the behavior. That means hitting a wall where there are two entities of the wall (see EX. 1) means a blowback of two instead of one. I need to figure out a way to handle it with the behavior part itself. Maybe have the 'physics' behavior add to some value that will set the blowback after all collisions are marked resolved for an entity, to remove the duplicity of behavior.

EX.: Image the two dots connecting to form a wall and the arrow as the entity colliding with them. :<-

The result should be :|<-, bit instead it is : |<- because of the double blowback.


I think the interactions system is pretty powerful. It scales out to all entities with a particular interaction class (think css class) and entity state. You register a behavior with the system with the two states and two classes involved in the interaction and viola, the behavior is used for all entities as needed removing the need add behaviors to entities themselves.

One concern has been to figure out if entities should be allowed to contain different interaction classes, but the problem I find is how to handle the conflicting behaviors that are set for each interaction class. You may have to duplicate the callback by rewriting or if you have the states and classes of a behavior, then you can retrieve the callback associated and reference that instead. I think it is one of those pick your poison situations rather than impose a way to allow same behaviors in different interactions.

Celice has been pretty interesting, but pretty slow development from my perspective and at the same time thoughtful as well. I have a good feature list, but the core v0.1 list is solid. Next up is sprite animation and event sequences. See ya then.
You just read "Celice, part 3". Please share if you liked it!
You can read more recent posts here.