Where does event-based audio fit in a component-based entity system?

Question

Assuming the underlying low level audio logic is encapsulated in some outside class... what is the best way to add audio effects to a component-based entity framework?

I am taking the approach that entities are just IDs and a type of database is used to associate components with entity IDs. The I can create masks for the systems to query particular types from the database.

So for example for components I might have:

• PositionComponent.
• PhysicsComponent.
• VisualComponent.

And the corresponding systems:

• VisualSystem, which processes visual components, hands off to outside renderer.
• PhysicsSystem, which processes physics, updates position vectors.

So the question is, how best to add audio to this system... or should I even bother? The problem I am having is mapping sounds to actions and when to play sounds.

Here are some approaches I've thought of::

1. Force PhysicsComponents to have a some collision sound field and when a collision occurs, play the sound within the physics system.

2. Same as 1 but instead when a collision is detected add a SoundComponent(sound) to the entity and lets the SoundSystem see that and consume it (so the sound plays once for example). This still means PhysicsComponent would have a sound field. So really this just shifts the playing of audio into a system.

I don't like either of those approaches. They are not very suitable to expanding the game either. Now I would need a field for every possible sound a unit could generate.

Really I think individual entities should dictate which sound to play based on some component attached to them I would assume. The question then becomes how to know when to play that sound.

Sorry if this is all very vague. Any tips appreciated.

Answer 1

You are teetering on the brink of the pit that is "putting everything in the entity system." Not everything needs to be a component, and indeed, many things should not be.

You should strive for separation of concerns where possible: a physics system should not know about the sound system at all. This includes avoiding a "sound to play on collision" field for objects.

Instead, build your physics system such that it exposes callbacks for collisions; a callback can be as simple as a function that has references to the two colliding rigid bodies to as complex as you need.

There is a system in your game that knows about both physics and sound: the "game" class itself, the thing that holds both the "sound system" and the "physics system." Have this game class wire up callbacks from the physics into the game logic, which can understand what sounds to play when two things collide, and play them. Since the game already knows about both systems out of necessity, you introduce no additional coupling. This works perfectly fine in an entity/component system because physics components typically correspond to rigid bodies.

If you need to put SoundComponents in your game, use them for things like controlling whether the entity plays a periodic sound or emits an audio effect (like local sound damping).

Most of the time, component-based entity systems work best when paired with some form of scripting language or other way to drive behavior without recompilation of code. If you have such a thing, I'd recommend giving your "script components" access to at least of subset of the audio API, so that they can request that sounds be played when they determine it's warranted (for example: a script component representing enemy AI that "detects" a player may want to issue a warning growl).

Generally, I find that sounds work best when they are just a service that appropriate components or other systems can access as needed. There's room for things like SoundComponent for limited, simple use cases (like periodic sounds, as mentioned). But if you try to shoehorn all sound activity into components I've found that you often end up with a complex mess of components that's hard to balance for good audio mixing.

Also remember: an entity system is a high level concept. It's higher level than sound or physics, so the components should usually be built on top of the underlaying system and not the other way around (by which I mean it should be theoretically possible to use your physics or audio system without components if you wanted to).

Answer 2

This is just an idea, as I didn't try it out in practice.

What if you use empty components to indicate state, such as IsColliding, IsFired, etc.

In this case, you could have a SoundSystem configured with a map, so that it triggers a sound for each state. Such as:

{(RedBullet, IsFired): "red_fire.wav",
 (BlueBullet, IsFired): "blue_fire.wav",
 (Player, IsCollidingWithPathBlocker): "thump.wav",
 (Player, IsCollidingWithEnemyBullet): "ouch.wav"}

Answer 3

Actually that is easy to achieve.

If you have a collision, create a new entity with position component (for positional sound) and a collision component (maybe with the force as data). Now write a CollisionSoundSystem which deals with that new entity.

And I suggest a decay component and a decay system to get rid of the collision entity in under a second. Maybe you have an EffectSystem as well for some nice hit effects.

I would not mix it too much with traditional OO practices, at least not on the same abstraction level.

In ES, you have to solve things in a different way than in traditional way of programming. Think in therms of an ES.