Create a writeup of my implementation approach Welcome to my upcoming ambience system project that generates dynamic ambience "Adds" by querying the player's surroundings, then decides which sound is most appropriate to play based on logic in Unreal and Wwise. For this project I have defined ambience "Adds" as sounds in an ambience system that have a place in the world and "add" to the background ambience: the squeak of a bat in a cave, the sparkle of some magical butterflies, or the wind blowing through some tall grass. Other methods I have seen for creating these kinds of systems require the audio implementer to manually place audio emitters everywhere they want an Add to be in the world. Even if you use prefabs this can be a very tedious process, and leads to more objects than necessary in a given environment. This project seeks to eliminate this problem by having the sounds be generated dynamically at runtime around the player instead. The “Adds” system works by periodically sending a "hedgehog" of raycasts out of the player (the red lines in the first screenshot), and choosing a point that hit an object in the surrounding environment. The ambience system then decides which sound container to play based on the following criteria: the biome the player is in, the object hit, and the height of the point hit relative to the player. These factors influence switches and states in Wwise, making the implementation in Unreal simpler. Unreal then chooses whether to play an Accent Add (a general sound based on the biome), a Detail Add (an object specific sound based on the object name and biome), or a Creature Add (an animal sound based on the biome and height of the point hit relative to the player). For example, hitting a tree in a forest biome would result in the playback of either: 1. A forest Accent Add, such a gust of wind 2. A tree Detail Add, such as tree creaks or branches rustling 3. A forest Creature Add. If the hit is at the base of a tree, then a mouse could scurry across the ground. If the hit is at the top of a tree a bird could sing in the branches. All of this logic without a single emitter placed yet! Then Unreal can decide which sound to play, spawn a single emitter at the point hit (the pink sphere in the first screenshot) and play the appropriate container, deleting the emitter object after the sound had finished playing. This system is meant for open world games, where the environments are huge and the amount of repeated objects or objects with similar names is similarly large. The system is not suited for sounds that convey very important information to the player. It requires keeping an updated list of strings for each biome for objects with unique Adds, which is a bit unwieldy and could impact performance if the list gets too long. However, with a consistent naming convention for objects this problem can be minimized as the system checks if the name of the object hit contains a keyword (such as “tree” or “fence”) when deciding which detail to select. This system allows for a lot of flexibility when it comes to the nature of sounds played. Because it is based on the object hit, it allows for very detailed sounds, and adding these details to every similar object in a level is as simple as adding the name of the object to a list. Because the emitter object is spawned and not on an object already, having special emitter objects with bespoke spatial behaviors is simple to implement, such as a bird flying away from the player or a mouse scurrying across the ground. It allows for audio designers to easily create a random system, tweaking the random chances and frequency of ambience Adds as desired. While I built this system in Unreal and Wwise, such a system is not so different to implement in other engines and middleware. This project aims to eliminate some of the tedious work sometimes involved in audio implementation, and seeks to piggyback off of the work already being done in other departments, such as object naming conventions and level design. It encourages a collaborative environment, where level and game designers can add new biomes or features without the risk of incurring an overwhelming new batch of tedious tasks for the audio team.