I'm currently building an entity component system and I just have one question... Should a system be allowed to render things to the screen?

For example, should I make a SpriteComponent that contains a Sprite, and then create a SpriteRenderSystem that renders the sprite to the screen? Or should rendering entities be managed by something else entirely?

The reason I ask is because I've read in many forums that allowing a system to render is a bad idea. But I just don't understand why this is; If game objects in my game are represented using the ECS, how else would I go about rendering objects to the screen?

  • Perfect systems don't exist. Do whatever you're comfortable with. It'sll get a burden eventually. – Bálint Dec 11 '17 at 8:34
  • Isn't the render system....a system? I'd imagine your system class forwards all of the rendering commands to a render system? You can probably do it directly if you don't have such a setup. – Sidar Dec 11 '17 at 9:17
  • 2
    There is no such thing as the ECS. What is you E, what is your C and what is your S? What do they do and how are they related? There is as many definition of ECS as there are developers. – Alexandre Vaillancourt Dec 11 '17 at 14:16
  • @AlexandreVaillancourt actually no, there are only different definitions of component based architecture, but even then they're just different design patterns. ECS (Entity Component System) is a architectural pattern commonly used in game development programming; en.wikipedia.org/wiki/Entity-component-system – user102158 Dec 13 '17 at 7:17
  • @Mathew There are obviously different interpretations / approaches / meanings of the ECS pattern since your implementation is different from my implementation and from the common implementation where an entity is nothing but an ID and a component only holds data and does not have any functionality. – Charanor Dec 13 '17 at 16:47

This might not be the best approach, but it works for me:

The ECS is used for logical storage and operations only (or almost only).

The design I use is aiming to separate these two concerns as much as possible. Naturally somehow you need to be able to tell any rendering code how to render a given entity, I do that using a component on my entities that stores a graphical representation of the entity. This representation could be a simple sprite, a whole spritesheet, a bunch of triangles, and so forth.

To decide what I render, my ECS has a Camera-System. This system has a certain box in world-space it sees. Any entities that are located in that box and have a representation-component are picked up by the Camera-System, batched and queued for rendering.

The renderer runs, in my case, on another thread and picks up a snapshot of all cameras every frame - then renders it.

You're overthinking this. There is no definitive "good" or "bad", just what works. I've always used a SpriteComponent and a SpriteRenderingSystem. It's the most simple and straight-forward way and it has worked for all of my games. If you feel like it's not the correct thing to do then change it to be whatever you want / need. Just do whatever feels right and whatever works and it will be fine in the end.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.