4

I am using an entity system for my hobby game, specifically the Behaviour / Attribute model discussed in Radical Entertainment's Theory and Practice of Game Object Component Architecture presentation.

I have read discussions of this model here and here and I believe I understand it except for a specific case:

Say I am developing a top-down game that has has multiple units (entities) on screen. Each unit can be selected, which outlines the unit with a green box. Think Starcraft, where you can select units and then issue an order.

At the moment I have the classic RenderBehaviour which simply draws the entity. I now want to add a SelectableBehaviour. The SelectableBehaviour will have "logic" responsibilities such as ensuring the unit can be selected, deselecting the unit under certain circumstances (death events), etc.

My problem, essentially, is who is responsible for drawing the green outline around the unit when it is selected - the render behaviour, or the selectable behaviour?

I am trying to follow what the presentation says, which is that Behaviours should be very generic in their responsibilities. If possible I do not want to add code into the RenderBehaviour that says "if entity has selectable behaviour" because now my behaviour is no longer generic - in fact, this exact scenario is mentioned on slide 16 of the presentation (but it just says "don't do it").

I am basically being mindful of mixing "presentation with logic". The only thing I can think of at the moment is to have another behaviour that is responsible for rendering the select box.

I understand there are no hard and fast rules regarding entity systems but I am curious to hear how this can be handled neatly.

Community
  • 1
Ben J
  • 143
  • 3
  • A traditional entity system separates logic from data. If you had "systems" which update your entities, which have specific components (data) attached to them, then it might be a bit easier to organise. But, in my opinion, I would probably split rendering and game logic entirely, i.e. no RenderBehaviour classes that draw themselves; leave that to the renderer. Then again, I'm not sure how you would handle that in your entity system. – miguel.martin Jan 12 '13 at 04:10
  • In my game i do it by creating new entity that has same position and that has renderbehavior component that draws green rectangle. And that new entity is created by when unit entity is selected. – Kikaimaru Jan 12 '13 at 19:20

2 Answers2

4

The specifics of a component-based system or even entity system have little to do with the answer to this question.

A renderer takes data describing the renderable objects in your scene, culls the ones not currently visible to the camera, and then submits the necessary drawing commands to the GPU to visualize the scene.

The key part of that is "data describing the renderable objects." If you have selection indicators of some kind around an object, you create a new renderable object representing that indicator. You have a mesh or particle effect to represent selection. You do not change the selected object to be selected, but rather create a second object at the same position that is the selection.

If your engine supports parenting (attaching one object to another), you would do this by letting your selection behavior create the child object when the unit becomes selected and then destroying the selection object when the unit is deselected.

The rendering hence has zero logic involved about rendering selections, when to render selections, how to render selections, or so on. The renderer just renders all renderable objects. When a unit is selected, there is a new renderable object, so the renderer naturally renders that new object. When the unit is deselected, that goes away, and the renderer stops drawing it. Absolutely no new logic involved in at all anywhere involving graphics.

Note also that no behavior is responsible for rendering anything. That is not how a properly architected efficient modern GPU-accelerated graphics engine works. It is purely data-driven. The behavior cannot know how to properly render anything, because the behavior is not running with all the knowledge the renderer has internally. The behavior does not know how to batch geometry. The behavior does not know how stream in content or control LOD. The behavior does not know how to optimize particles vs static objects vs skinned meshes. The behavior does not know how or when to sort translucent objects vs opaque objects. The behavior at absolute best can just submit a work item to the render queue for a specific mesh/material/shader, which in turn is exactly what creating a new object with a renderable component does (because every renderable component in the scene is implicitly a work item in the render queue each frame).

If you need actual line drawing around units rather than a (much nicer looking) textured quad or particle effect, simply create some new renderable components for representing bounding boxes. Again letting the renderer properly optimize those by batching together all the visible bounding boxes into a single line batch for the GPU.

Sean Middleditch
  • 41,807
  • 4
  • 89
  • 132
2

I would follow Sean's advice and consider a separate entity for this type of renderable effect. You simply attach this new entity as a child to the avatar entity when a selection occurs and remove it when the selection stops. We do similar things like this for highlight/hover effects as well.

In fact since you can only highlight/target a single object at a time in gameplay mode, we preallocate those special entities when the world gets initialized. They are merely hidden until needed. Once needed, they get attached to the right parent, visibility flag toggled. To remove, just detach, set not visible.

Naros
  • 2,012
  • 10
  • 13