You are viewing...

Celice, part 4

Updated on April 24, 2013 at the 18th 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. If you have missed the past parts of this, then look for the Celice tag at the bottom of the post and start from there.

Animations in 2D games are basically sequences of images for the purpose of simulating an event such as movement in a way that is appealing to the visual/emotional senses. In Celice, animation is tied to an entity and swaps out the entity's image in favor of another in a spritesheet to create the effect that we want. It is very simple because it is a simple idea that involves a spritesheet, positions on the spritesheet, and the change of the current entity's image. A good example is in Fire Emblem, where the units images are always being swapped at regular intervals to create movement/idle effect (hands going up and down) for all units. There are different kinds of animations you want displayed when the unit is IDLE/Attacking/etc., so the animations are dependent on the state of an entity.

EventSequence is a System where entities that are involved in an Event Sequence are subjected to the behaviors defined by the current sequence. Think of game where the level ends and entities start moving without your input or when an entity is moving on a path to a certain place. This is a system that builds that idea and follows a defined structure to execute these sequences, so that you don't have to build your own way. The final goal for this is that you are able to build behavior in a sequence and all the interactions and pass that into the Event sequence along with all the entities involved and watch things go. I'm not sure if it should work like a transaction though where if the sequence can't complete that the entities should rollback to their starting positions/attributes. Maybe some callbacks can be provided for that kind of failure.

Finally, an Entity Loader is a cache of entities and their components, so that you can load entities by an entity key. You add an entity key and its component strings, then load it whenever. It works like an Entity Factory in a way, but not exactly because its main function is to store a map of entity keys and components. Creation of an entity is delegated to the CQuery object. Loading from an external source is also provided. This is ideal for games where you don't want to load every entity key on the spot in a way to hide some information from advanced players.

I think it is worthwhile to mention that an entity pool is something that I'm considering because entities could be stored in a cache and then reused for other entities of a similar kind, so we don't throw away memory. Entities are similar if they have a similar set of components, which makes sense given there is nothing else that composes an entity. Background tiles are good candidates for taking advantage of pooling instead of using 'new' a ton of times in the game's lifecycle. Since the CQuery object is the point of interest for creating Entities, it is an ideal place to put an entity pool.

I think this may be enough features for a v0.1 release. I have plans to take advantage of these features in example games such as an arcade space shooter, possibly a pac-man look alike, pong and maybe an small adventure game. The examples need to showcase some of the power of the abstractions, so fun games like these are great examples.
You just read "Celice, part 4". Please share if you liked it!
You can read more recent posts here.