More audio work! Universe update dev dump 2 - [11th of October - 20th]

Posted on November 19th, 2019 08:30 AM EST
Image is of 116-2 Marksman[starmadedock.net], by MeRobo[starmadedock.net].

This is the second universe update dump copied from our official Discord server, in the channel #universe-update-dev-news-dump. To receive universe update news as it happens, join our Discord channel here: Join the StarMade Discord Server![discord.gg]

Previous Discord dumps:

TL;DR

Between the dates of the 11th of October - 20th, the following was done:
  • Continuation of the Audio Engine. Audio Manager's event tracer was completed, events represent an audio asset triggered by the game. Events come with special arguments for spatial properties as well as control indicators for start/stop/onetime.
  • Finished audio asset manager, which has a list of all available sounds. Ability to assign an (audio) asset to either a tag group or individual event ID, e.g. a GUI button sound might be assigned to a GUI button tag group. If we wanted to have one button with a different sound, we'd simple assign an (audio) asset to its individual event ID.
  • Worked on a music manager which will essentially work the same was as the audio asset manager, using the same tag system. It'll be a little different in that the player will have a collection of AudioTags that would describe its current state. E.g. if the player is near its homebase, it'd get the HOME tag, in enemy space the ENEMY tag, flying around would get exploration tags based on location e.g. a PLANET tag. There'd be tags for all sorts, such as pirates, other players, building, mining, factory and so on. We could play a custom soundtrack that suits each activity, adapting to the player's current gameplay. Music will not always be playing, silence is as much a part of the space experience as sound.
What's coming up:
  • Overhaul of the individual block system. Putting all block variants into a better structure (wedges etc.), and an LoD system! LoD (level of detail) system basically decreases the complexity of a 3D object, for StarMade this would simplify a cube mesh to make a low poly representation of chunks. This should drastically increase rendering thoroughput, giving a performance boost and potentially allowing us to scale new planets up a bit.
  • GUI work, most importantly GUI scaling to support larger resolutions.
  • Resource loader refactor (for audio, images, meshes, textures, etc).
  • Write/read overhaul, massive performance increases!

Looking for screenshots!

We're looking for StarMade screenshots to use in promotional materials and on the Steam library/store/news. Post your screenshots here: https://starmadedock.net/threads/screenshots-for-official-use.31422/

From the last post, soundcloud link to our soundtrack in progress: https://soundcloud.com/danieltusjak/sets/starmade-demos-in-progress


--- Below is the more detailed discord posts about development done ---

October 11th

First part of the manager is done, which is the event tracer



next step is to be able to click on events and have the all details.
After that is an audio asset manager (to have a list of all available sounds)
Then the ability to assign an asset to either a tag group or an individual event ID.
After that would be the advanced event handling (start/stop, spacial, etc), as well as more options like volume, range, layered range (multiple asset assignments and playing different sounds depending on range)
No promises, but goal is to finish this by sunday

After that I'll enhance the manager with the music manager which will work the same essentially, using the same tag system but with a different kind of dynamic.
the player itself will have a collection of AudioTags that would describe the players current state:
If the player is close to his home base for example it would get the HOME tag, if they are in enemy space the tag would reflect that as well.
if they flew around a lot, especially into unknown terriory, they would get EXPLORATION, and tags on location like PLANET etc
If they fight they would get a FIGHT tag for a while, plus another tag on what they were fighting against e.g. PIRATE or PLAYER
More tags would be BUILDING, MINING, FACTORY, etc

The actual music playlist would then adapt depending on what tags the player currently has. it would also keep track so that songs are not repeated too much.

Music wont be constantly playing, too.


October 12th

Alright, most of the structure work is done. The data is structures into 4 data structures:

* AudioEvents: as explained above these represent an audio event triggered by the game. They come with arguments for spatial properties as well as control indicators for start/stop/onetime

* AudioAssignment: Comes in 2 types (TAGS, MANUAL). An assignment holds a AudioAsset and AudioSetting. One assignment can be assigned to multiple AudioEvents. Each AudioEvent holds an AudioAssignmentID which holds the type as well as a reference to the assignment. These are resolved on startup from the config so access is in constant time.

* AudioAsset: This represents an interface for anything that can play/stop. Be it an mp3, ogg, wav, etc doesn't matter. An audio asset can also be a composition of multiple assets for layered audio. They also determine the resource loading way (preload/streaming)

* AudioSetting: Is part of an assignment and determines the play settings for the audio (loop, volume, start/end times, radius, pitch)

On startup all events are read from config as well as all assignments. They are then resolved so each event has an assignment (they get type "none" if nothing is assign, but default is play by tag)

The assets are read from config as well and cross referenced with the resource loader, so the sound files can be loaded. I likely give assets a different kind of tag to be able to load just GUI for the main menu for example).
So when an audio event is fired, the audio controller looks up the event and with that the assignment. This, together with the event arguments are then processed.
If it's a GUI sound, the assignment will reflect that (play for client at a constant volume independent from location)
if it's a spatial sound the argument will contain a reference to location.
if it's a looping spatial sound it will also keep track of the object it was spawned on, so it can be ended by a second "stop" event.

October 13th



the event manager is mostly done.
can now filter fired audio events (to for example only list events that dont have a sound attached to them yet).
The rest is relatively selfexplanitory.
you can use a tag assignment, an individual assignment, or you can turn sound off for this event.
If you change the event by tag, all events using that assignment use that change.


October 14th





Alrighty. The manager is mostly done. Just have to implement some smaller things.

Essentially, audio assets are now meta, but can be created automatically from a directoy.
each asset can then be edited directly (the way it is loaded, basic volume)

When an event plays, the actual volume would be the volume of the event times the asset volume and optionally the spatial volume.

Audio assets can be just dragged onto the asset fields of an event.

The asset loading is somewhat self-aware in that if you add new files or move files it will try to reuse the existing data using file hash codes.


October 15th

Integrating the system into the new Audio System I have already done. When finished you will be able to test audio, as well as different paramaters on the fly. The sounds would be handled just like it would be ingame so it's all fully setup at that point.


October 16th



we got sound. spatial and effects are working well.
spatial only works with mono (since it has to be a singular point source), so im working on a converter in the meta data, so you can just switch mono on/off depending on what you use a sound for.

October 17th

had to do some general fixing for the config load/save, since this whole data structure has become quite complex. It will pay off big time in time saving from here, though.
Might still need another view with all possible evens listed, to get a good idea on how many events still need a sound attached.


October 18th



Working on music now. Essentially every track gets tags
The client will emit tags dependent on the player's state
the music with the most common tags will play next. Tags have a refresh time and a max time they can be active
if more than one track is selected for the same set of active tags, the track that wasnt played recent is played
I hope the whole sound system is finished by sunday.
Next up is the overhaul of the individual block system. Putting all block variants into a better structure (wedges, etc), as well as the LoD system, since everything is very spread out at the moment and it's hard to track bugs. Stuff like this usually happens when you dont plan for extensions of a system (since this system was very early on). This whole overhault will hopefully not take long, since it's mainly refactoring existing stuff.


October 19th

Alrighty. Code has all the music tags and the system is almost ready to go (will still need to import the actual music, but that is just a matter of copying the files and clicking on checkboxes)


October 20th

Implementing Audio Mixers and submixers, so volume can be managed. This lead to a complete refactoring of the settings system upgrading to a new system I have prepared eariler that year. My IDE is giving me some problem randomly crashing and freezing but i'll get it under control. [/url]


Click here for the source of this article RSS Feed

Share This Article