We are still trying to figure out how to properly work with ECS, still unsure about what makes a good System in an ECS. So far we are following two rules:
- “A System that does more than one thing can be probably divided into many Systems”, which follows the SRP (single responsibility principle)
- “If a piece of code appears in more than one System, it’s probably a System on its own”, which follows the DRY principle (Don’t Repeat Yourself, avoid code duplication).
Both or which are two key software principles anyway, so it probably won’t hurt.
Following #1, we separated the system that was previously responsible for rotations and movement into SpaceFlightSystem, which just updates velocities and an entity’s position in three dimensions, and HeadingSystem, which is now responsible for rotations. We also keep track of user input in separate systems and components (flight & heading), so we are able to control entities that move and rotate (spaceships), but also those that don’t move but rotate… like turrets. Here’s an early test:
We also decided that many entities would be interested in ‘going somewhere while heading toward somewhere else’, an action shared by behaviours like traveling, patrolling, chasing or surrounding an enemy. Thus the ApproachManeuverComponent & System were born, which we tested spawning a tracking missile:
A bit of code refactoring allowed us to simplify the way we check and fetch entity components thanks to C#’s TYPE class. But we’ll write about that when we are sure our ECS implementation makes sense, if that ever happens.
Finally, we took some basic graph theory and built a rough small random galaxy generator. By finding the minimum spanning tree of a bunch of randomly placed star systems and forcing a few cycles and some angle constraints we create the layout the galaxies we will traverse in our quest!
