I'm currently trying to make a 2D platformer in Monogame in the style of Castlevania. I wanted to try out using an Entity-Component-System organized game so I implemented a pretty rudimentary ECS that's working well for my purposes. Instead, I'm having some trouble actually thinking of how to divide the logic into systems and components.

For example, when I'm creating the motion-aspects of a character (moving, walking, falling, jumping, etc.) I'm having trouble deciding how I should split the logic, especially when considering how to switch between the animations for each movement state. Should I create a component for each movement type (WalkingComponent, FallingComponent, JumpingComponent, etc.) or should I just have two components (HorizontalMotionComponent, VerticalMotionComponent)?

In a broader sense, does anyone have any tips on how to organize logic into components and decide what components to create?

Should I create a component for each movement type (WalkingComponent, FallingComponent, JumpingComponent, etc.) or should I just have two components (HorizontalMotionComponent, VerticalMotionComponent)?

Just have one component: MotionComponent, that specifies the entity's velocity. Why would you separate horizontal and vertical?

Then maybe have some PlayerController component that is responsible for knowing when the player is jumping or running, and poking the Motion and Animation components so that the correct motion and animations are applied.

Would there not be a problem having a component (PlayerController) having references to another component? Shouldn't that be done via a system? Or are you suggesting that I have a playercontroller component that would having properties like running, jumping, falling etc and create a system that would update the animation component based on the motion and playercontroller?

Shouldn't that be done via a system?

The idea that there is "one correct way" to implement an entity system, with or without components, is wrong. If your design calls for this kind of association being done via something called a system, sure. But valid designs exist that don't involve anything called "systems" as well, and the beauty of the design being yours is that you can change it.

And you should: your designs and your code should suit your needs, not some arbitrary "ECS" dogma you read about on the internet.

Shouldn't that be done via a system?

The idea that there is "one correct way" to implement an entity system, with or without components, is wrong. If your design calls for this kind of association being done via something called a system, sure. But valid designs exist that don't involve anything called "systems" as well, and the beauty of the design being yours is that you can change it.

And you should: your designs and your code should suit your needs, not some arbitrary "ECS" dogma you read about on the internet.

That's a good point. Thanks. I'll be sure to experiment more. I guess I'm just trying to see what others do with ECS so I can try those methods out and see which works for me.

If you want the logic done in a system, then you can simply have a motionSystem and an AnimateSystem, where the motionSystem has access to the PhysicalComponent of the player (anything related to a physical property of a player, velocity, position, mass, angle, etc.), a InputComponent which, tells you what input buttons are being pressed (up and right), and a playerComponent which has the specifics about the player (stats, power-ups, etc.).

The animateSystem has access to the PhysicalComponent, AnimateComponent and playerComponent, and it determines what sprite to draw (mid-run, possibly glowing if the player has a shield upgrade), etc.

That's just one quick thought I had, but hopefully it gets you thinking about other ways to do this.

That's a really good way of thinking about it! I think I see where you're coming from, thanks!