0
\$\begingroup\$

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?

\$\endgroup\$
  • \$\begingroup\$ Perfect systems don't exist. Do whatever you're comfortable with. It'sll get a burden eventually. \$\endgroup\$ – Bálint Dec 11 '17 at 8:34
  • \$\begingroup\$ 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. \$\endgroup\$ – Sidar Dec 11 '17 at 9:17
  • 2
    \$\begingroup\$ 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. \$\endgroup\$ – Alexandre Vaillancourt Dec 11 '17 at 14:16
  • \$\begingroup\$ @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 \$\endgroup\$ – user102158 Dec 13 '17 at 7:17
  • \$\begingroup\$ @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. \$\endgroup\$ – Charanor Dec 13 '17 at 16:47
2
\$\begingroup\$

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.

\$\endgroup\$
1
\$\begingroup\$

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.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy