Samulis

I'll see what I can do! Should have time later this week. Any chance you can provide a screen capture of the attack animation or something similar so I can try to sync to the motions? Or is there no animation yet?

Here's an option using a shell trumpet- ShellTrumpet.wav

It is absolutely no problem to record a new shorter sound if needed too, or create any other type of sound effect (e.g. a deep bell sound or a 'weaker' shorter horn sound perhaps). The link to the dropbox has other example sounds, those two just sounded perhaps most immediately applicable to me (which is probably why they were already used!). Inspiration-wise, AoM of course uses a regular death sound in this case (same as a normal unit, if using the same voice bank), with a voice-over saying "A hero has fallen" as notification. Yes, though the sword sounds were problematic because at the time we were working on changing the way sounds work so that the impact (flesh, wood, stone, etc.) sounds are actually used depending on target. Not sure if that was finished. At the time we compromised by combining impact and swing sounds into single files. There is also the problem of the perceived sound of a sword (metal-on-metal scrape sound) vs. the real sound of a sword (usually just striking a shield). I think the sounds we used were a blend of real sword sound and perceived/"hollywood" sword sound. Perhaps though we should have a new thread to discuss the sword sounds further.

No need; I can take care of creating any sound if needed (just tag me). There are a range of unused attack-alternate sounds which may work (and were recorded with real ancient horns and flutes rather than samples), perhaps one of them would work? e.g. 06-Alt, 09-Alt seem sort of mournful to me. I cannot remember though which one we chose for the game though, and obviously this sound should be different! https://www.dropbox.com/scl/fo/f6ot29y8g0h7w9zi4zyux/AJzOb3kuVNWPyqfuMhy7xSE?rlkey=ojaj28tbanhgsmg0yxp2hhejo&st=tvrfmeo3&dl=0 Attacked_06-Alt.wav Attacked_09-Alt.wav

Sorry for the incredibly late reply! You can send me a message with a link to the files and I can get them cleaned up and implemented.

Ah yeah, a car actually isn't a bad idea if you don't have any quieter place to record since they are usually rather well noise insulated and reasonably dampened aside from the glass as you mention. Maybe a middle seat, and get pretty close to the mic. Of course, be aware of noisy traffic passing by outside or other noises if in a city/town.

Do we have proper translations of all the terms ready? If so, go ahead. It is preferable that: All terms in the list (including recent additions like 'I will capture') are recorded, preferably with multiple takes. The recordings should be done with either a proper XLR studio microphone or at least a decent desktop USB mic. If neither is obtainable, then a cell phone or headset microphone may be used, but this is very much not preferred and much work will be necessary for me to make the audio usable. Also accept that if a cell phone is used to record the audio, your audio may be removed and replaced in the future with a proper recording if that becomes possible. The recordings should be done in the quietest, most "dry" (i.e. least echo) space you can find. Often an interior closet full of clothing and such works best. Be sure any noise sources like fans, air handling, refrigerators, desktop computers, windows, are either turned off/closed or set to their quietest setting. Every single decibel of noise improvement is worth it! The speaker should be about 10-15 cm from the microphone (no more, no less) when talking and should remain in the same exact relative position when delivering each line. The audio should not 'clip', i.e. pass the point '0 dB Full Scale'. The gain/input level shall be set so the loudest audio is at about -6 dB. If there is excessive distortion, noise, or other problems, I may not be able to clean the audio sufficiently for it to be in the game.

Welcome @Saifeddine! Nice to hear you are also in the Boston area, as I am currently. One project I have been considering tackling next is the lack of voice variety in the game. It requires recording a bunch of dialogue in various ancient languages. If this idea interests you, I have been considering working with a local studio to record the dialogue, perhaps with some local students, and could definitely use some help in that regard. If you are interested, I can PM you my Discord details and we can see what can be done. Omri is very much in charge of the actual musical side of things, but as said before, there is room for more works provided they can be adapted to fit the game's sound and style overall while also hitting the mark of the unique culture. The overall sound of the score is not really the same as typical for modern scores, as aspects of it reach back over a decade to when the game was begun, so it is an interesting challenge to write pieces which fit aurally and compositionally. I would deeply encourage at least a few playthroughs of the game with various cultures, or listening to the full soundtrack, before working on anything.

Some input as a non-programmer: My main experience is with Git, primarily using GUI-based tools like Github Desktop. I have not used much of any SVN. I generally think a lot of this comes down to a question of accessibility and features. Obviously with an open source project it is important that it is accessible, even to novices and less-technical people. I think anything that requires command line/text-based use is too advanced for many non-programmer contributors (art/audio), so I would encourage that we consider an option that has some kind of at least somewhat functional GUI-based option. Yes, command line is not really that scary and even a few hours of digging around the file system and doing basic stuff in there is enough for it to become second nature and very simple in retrospect. However, there are many people who are truly afraid of using it or have such a limited understanding of basic command line use that it is genuinely dangerous for them to be poking around on their own. I think the last thing we want is to have to spend a hour or more giving each new contributor a tutorial on how to submit changes. On the other hand, if something is so easy that even a total beginner can contribute to it without any kind of technical hurdle, it may lead to a risk of lower quality code or assets being contributed. In the current state, I feel like the use of SVN acts as a very minor gatekeeper and encourages less experienced potential contributors to spend more time on the forum. I have had occasional issues where people have submitted unusable content in merge requests to projects I have run on GitHub and had to decline them. Regarding sovereignty, I definitely agree that we should maintain some kind of local version, if not the main working version, on servers we control. Although I do not think a place like Github or similar is going to go 'poof!' one day, I have had occasional problems in the past with companies deciding to stop running services I rely on as essential and do not think it is healthy to keep something this large and important in one place, especially one controlled by another party. I can also see how using the same version control system as most mods might be advantageous as well. It might make it easier for those who have just started to get the hang of modding the game to then contribute directly to the game. I'll leave the actual deciding to those of you with more experience, but these are just some thoughts which may help provide a different perspective.

TTS would probably be good for visually impaired players, but I don't imagine there are many of those given how visually-driven RTS' are. Not sure why one would prefer it other than that, as most people read text faster than it is spoken (at least for romance languages). Edit: for things like civic centers under attack and so on, there are sound effects intended to help you identify those already without being as intrusive as a TTS voice. While I potentially support the idea of a voice chat in lobby and of course in multiplayer games, I don't quite understand how the game (or any other system) would calculate "player position" as shown in your example. There are no "player" units in the game, it's not an RPG or FPS, it's an angled top-down RTS. Would it be based on city location? If so, players would spend almost all of the time hard-panned left or right which is not comfortable in headphones, and it would offer a massive unfair advantage to players when trying to find an enemy in the first part of the game; the human ear is sensitive to stereo field changes of less than a degree, so it does not take long to locate an exact position even behind unexplored map. I think it would be better for players to simply be mono, or perhaps locked in a fixed place panned slightly based on which side of the map they are on. Honestly probably the simplest solution might just be to have some sort of integration with a 3rd party voice chat solution like Discord or Mumble or something... that way all that would need to be implemented is a way to add an optional field for users to enter their handles or similar callsign, no need for actual audio infrastructure in the game. I'm not even sure what a built-in voice chat could do any better than such pre-existing solutions.

Yep! 2003-2004 I believe. The engine was also used in an earlier game, Celtic Kings, and a later game which never received a US/English language launch. It seems Haemimont was very interested in tweaking the way the game worked internally, so each game plays rather differently according to the reviews I've read. The minimap is great with the abstraction of the dots. You can see unit flows easily and clicking somewhere on the map drops you out so you can see what it is. Edit: I think the mechanic of the fullscreen mini-map might have been borrowed from the Tactical (?) view in Homeworld (earlyish 3D space RTS).

A rather old RTS and not so easy to run these days, but Nemesis of the Roman Empire, also known as Celtic Kings: The Punic Wars ("TPW"), by Haemimont Games (still around) was one of my favorite games growing up! It's not the most historically accurate in retrospect (mixing Imperial and Republican Roman eras), but still a lot of fun. Came out around 2004 I believe, or around 0 A.D.'s early days. I put together a rather mediocre playthrough with commentary (haven't played in nearly a decade so excuse my rust and poor placement on map!): Interestingly it has both a time period overlap and several core mechanic overlaps with 0 A.D.: Capture of structures is prioritized over destruction (in TPW/NRE, buildings cannot be destroyed at all anyway; gates can be broken down though). Units have levels and gain experience through combat or stationing in a building which gives them experience trickle. Each unit has its own strength, xp, and armor ratings. Units garrisoned in a settlement/structure will fire from its defenses. Each civilization is supposed to feel totally unique, and it definitely does this very well in TPW. Wild animals roam around, including hostiles. But TPW also goes off careening in a totally different direction sometimes: Resources are localized, not unified. Each settlement or structure has its own resource levels, which are sent around the map using mules which carry up to 1000 food or gold each. You can easily set up repeating routes which will run whenever the value reaches over a threshold (100 units of resource). Two-resource economy: food and gold. Food is produced in the rural villages, gold in settlements. The number of population in each controls the rate of production. When you train units, you take pop out of the settlement, meaning gold production drops. You can add more population by sending it from villages, which reduces food production. There is no troop limit, but you can reach a point where you cannot support your army's food consumption, if you do not have enough villages or they are captured. Likewise, if you run too low in population, you will not generate enough gold to train more troops or have enough pop to raise them. Units require food to live and carry a small supply, care must be taken to supply food or an army will starve and become easy prey. You can manually train mules to carry food and attach them to the army. Rather than just armor and damage, units also have a bonus ability, such as dodging the first strike, reflecting damage back to their attacker, each subsequent hit gives more experience or ignores a greater portion of the enemies' armor, and causing a % of the enemy health as bonus damage. This sets up complex relationships much deeper than Rock-Paper-Scissors of traditional RTS, where certain combined-arms relationships are extremely effective (archers knock off more health on full-health, high-health enemies, making them perfect to strike an enemy first so infantry can finish off). The actual damage of a unit is a range (e.g. 18-48), the exact value being determined by the difference in level between the combatant and their enemy. Thus, even heavy units can be overcome by a highly-trained weaker unit. There are no mobile siege units in the game. Instead, 1-10 units can build a stationary siege weapon (ballista, catapult, siege tower) on the map in any location. The weapon then attempts to fire at the target, at a rate set by how many units are stationed inside. Such weapons are very vulnerable to a sally-out, but not vulnerable to fire from towers. Only archers and siege weapons can directly damage buildings. Damage is not used to destroy the building, but rather harm and eventually kill the enemies stationed inside. Once the units inside have been pacified - or they have fled - the army will then attempt to capture the structure. Rather than units being freely formed into formations, they must be 'bonded' to a Hero who will lead them and enforce their formation. The Hero also gives bonus levels and can apply modifiers in battle. Without bonding to a hero, units will fight okay, but they will just sort of wander around without any formation. Heroes are limited to 50 units. Around the map are various special ruins and structures which give benefits. E.g. Ruins contain powerful artifacts which only high level heroes can pick up and use, which can cause damage or heal allies or grant bonus damage/health. Healing wells will heal passing or nearby units regardless of side. Capturable forts, trade outposts, stone outposts, and training outposts each provide benefits and lots of LOS to their owner. Forts slowly convert stationed villagers into macemen, trade outposts convert food into gold, stone outposts gain 8 gold/s interest when at least 2000 gold is placed inside of it, and training outposts behave like barracks in 0 A.D. and give experience trickle to units stationed inside. The cheesiest voice acting ever recorded. Some stuff I really like from TPW I wish was in more RTS: Spacebar brings up FULL SCREEN "mini"-map from which you can issue orders even. Makes the logistics and overview of the battlefield much easier. When entering combat, formations will sort of 'merge' into a battle, finding enemies to fight like in a real melee, and try to push beyond just the closest enemy. Iberian priestesses don't heal but instead gift units experience up to a certain level when a tech is researched. Units in other cultures gain experience by having mock-combat with their buddies. Priests help them to heal while this goes on, though if an enemy attacks it can be disastrous!

I like this suggestion of 'tracer' lines, it was done to great effect in AoE III and many other games. It would be helpful so long as it is not too difficult or graphically expensive. Arrows and javs do have impact sounds, I do not know why they might not be working for you; maybe they are just too quiet. Right now it is just a single dirt impact sound because detection of material impacted is not yet possible and that is the 'safest' sound to use (material-dependent impact is in progress, hopefully for a25). Edit: regarding the bars showing progress of construction, etc. for a building, I think that is not a very elegant solution. In a perfect world, the buildings should imho be animated when working (like some of the later Settlers games), to mitigate immersion-breaking random bars floating over buildings (but that would be a crazy amount of work I reckon). It is also easy to mistake such bars for either capture status or health, which serves to confuse new players and even old players. I found the 'feature' more annoying than helpful when I tried AoE II DE: I'm trained to see a bar above a building in AoE and assume the building just suffered damage, then waste several minutes hunting for a hidden enemy. XD

Just move it out of the subfolder after extracting? Layout should be: (mods} dan-shaders shaders glsl fs & vs files mod.json

Generally I do this kind of folder setup by making a temporary 'staging' folder somewhere and then replicate the folder structure and copy in my files. Once this is done, you can install this as a mod into your own copy of 0 A.D. and instead of directly modifying game assets, you just modify your 'mod' files instead. If you need to add more files to the scope of the mod, just copy them out of the game files and into your mod and modify there. This is very useful for sound stuff at least, where I can A/B test new and old sounds by disabling the mod, no need to uncomment lines or even move around files. I can imagine you might find the approach useful too. I would start with Stan's mod file, extract the contents and/or install it, and then replace the files in the folder structure he's already made for you with the latest files you've updated. Continue work as usual working only in this mod folder, with the mod installed. When you have a new version for people to check out, pack up as a .zip and upload for everyone to try, no need for fancy archive management.

Yes, the issue with languages is primarily that not many people are willing to record the voice over lines, and some languages do not yet even have proper translations. Here is the list of voice actor lines: https://trac.wildfiregames.com/wiki/Audio_Voice_List There is also an old list on the forum and much discussion about which words to use: People contributing translations or voice over lines is most welcome. Even if the voice recording quality is poor, it can still be used to show people who have a better recording setup how to pronounce the lines correctly. However, even the official list is somewhat outdated as features like Capture have been added, which do not have words in the lists.

It's going to sound a lot less dense because the original sounds used lower-fidelity recordings that were centered heavily in mid frequencies. The new sounds were recorded from scratch using professional equipment and so make use of a larger range of human hearing. By definition, it is going to sound less dense. Compromises between authenticity and convenience are important. In the bronze age, sword-on-sword combat was not technically possible due to how poorly bronze holds an edge (it would quickly dull or damage the blade to strike them against metal), so the 'shing' cutting sound is totally unrealistic... however, it does do a very good job making the swords sound different from spears and everyone knows that is the "sword sound", so I added it back into my 2nd draft sounds for a24. Javelins too do not really make such whooshing noises, but it again serves the game. We will probably be increasing the volume of many of these sounds you have commented about for a25. The problem is, the actual sound files themselves are not at a consistent volume level now, so we need to go back and re-process all of the sound files consistently before we start tweaking everything. a24's sound balance was done by ear over the course of a few games I played to get a playable, workable balance, even (and especially) when there are 200 units in a single battle, which can get quite loud. Changes were made to logging/lumbering to ensure it was slightly more consistent and also remained sufficiently different enough from new, much better building sounds. I liked the original lumber sounds too but some of them were very strange sounding; I might go with a hybrid approach, layering the two sets of sounds together, like I did with the sword attack sounds as discussed in the paragraph above. Here are some comparison videos of the lumber and build sounds:

Yes, we're still working on balancing sounds after we fixed some big bugs in the way sounds were being used that resulted in all of the sounds no longer being balanced. Expect more in the SoundsMod github project and of course a25. Unit selection and confirmation sounds have not been adjusted at all since a23, only really gather and combat sounds.

Sound attenuates with distance like real life. The further you zoom out, the quieter things become. Pre-A24 this was not done; 0 A.D. behaved like a 2D game, with all sounds of equal loudness no matter where they were on the screen. This was a basic flaw with 0 A.D. which meant that at far zoom, people mining on the other side of the map would be audible at 100% volume. Not only was this acoustically completely wrong, it caused sound to be extremely cluttered, with a sheer overload of equally loud sounds. You hear mining, but is it the miners right in front of you, or the miners on the other side of the map? Is it the tower in front of you shooting arrows or the enemy TC 1000m away? Now sounds at the top of the screen which are more distant will sound more distant and quieter, which creates a clean and enjoyable separation. The distance attenuation we are using is a fraction of real life, so sounds are audible much further away than they would be in real life, but it is still audible at normal zooms. [[Edit- A quick aside: we could redo the sound attenuation so it attenuates sounds farther from the camera more than closer by the same amount regardless of camera height, meaning the overall sound level would be the same regardless of zoom, but this isn't something we've discussed or explored yet, so I have no idea how good or bad this would be; just a thought.]] Now, I should note we are still working to balance the sounds a bit. There was a major audio bug where certain sounds where playing several duplicate times, which causes them to become greatly amplified (and massively wasted sound channels). This has been fixed, but as a result the balance of audio from before was completely broken. I spent a few hours tweaking sounds to be closer to a good balance, but it will need more work, and that is what a25 and the SoundsMod project is for. My goal with a24 was just to fix the most outdated or flawed sounds and then try to get the balance of sounds at least reasonable, even if not perfect, and I accept that there are sounds that are not quite balanced right yet. One other result is that battles will have a much larger dynamic range. Before the sounds would run out of channels so they would self-limit with more than ~50-60 combatants. Now each unit on each attack should only use one sound so larger battles should be even louder. Here are the old battle sounds, with the same fixed audio engine (i.e. what 0 A.D. would sound like if we kept the sounds the same): Now here are the new battle sounds: Not only are the new sounds to me audibly louder overall, they are also much clearer and less muffled without being irritating. If you want a battle to be immersive, zoom in a bit! Battles cannot be immersive at 500 m... that would be silly. You would not expect a concert to be immersive if you sit in the very back row... you would not expect a TV to be immersive if you're sitting two rooms away. When you play a city builder, you would not expect to hear people chatting on the streets when you zoom out 100's of meters, so I don't get why you expect a battle to be immersive if you zoom out a bunch here... The bow sounds are the same volume as other games, compared to their combat sounds. I compared the sounds to original AoE I-III, the AoE DE's, and a number of my favorite, more obscure historical RTS (Celtic Kings TPW, Empire Earth, Cossacks, etc.) and found that the bow sounds are appropriately less loud than melee weapon sounds. Many games have even quieter bows (like AoE III as Stan said, as well as AoM, which accurately depicts bow impacts as louder than bow shots), while others are about on par with these. In real life, bows are almost silent. They are designed that way intentionally and have been since their invention, because it is a hunting tool first and weapon second. We already are massively exaggerating the sound of bows to make it appeal to the Hollywood idea that bows make some massive whoosh when you fire them, and of course to make it easy to hear them when enemies are attacking which is an essential gameplay mechanic of the sound. I hope this answers some of the questions you have had about the sounds. They are still a work in progress, but the whole point is to improve them. Feedback is definitely welcome but we also have to make sure we are designing the sound without holding onto existing conceptions. It is easy to become stuck in Confirmation Bias, where the more familiar seems better, even when objectively it may not be.

Thanks for the suggestion! This is something I'd like to see too; there are already some existing concessions for off-screen sounds, but they're pretty limited (essentially just, things that sound in the ~200px to the horizontal sides of the screen get played a little quieter). The sound engine we're using is extremely limited: no reverb, no filters, no equalization, no effects of any kind, so everything would need to be done with sound groups and some hackery. All we can do is pretty much play sounds at different volumes and pitches (speeds), at a particular spot on the screen. So, to implement off-screen cues like this we'd need to add a new set of sounds with the reverb et al baked in and code something to determine if a sound is on or off the screen and play the right variant. This is a recipe for a lot of work (and duplicated assets), but we might be able to find a way with maybe just a generic distant battle sound. Our main focus presently is on cleaning up and standardizing the sound assets and their definitions; more or less 'triage' medicine. Most of the sound stuff specifically is from over 9 years ago and the people who did most of it have long left the project I believe, so it's more archaeology than sound design some days. This stuff was coded and designed when I was still scoring Flash games for a living! XD Once the cleanup work is done (I'm hoping for A25), we can start to actually implement new ideas or tweaks.

Just a few thoughts (been following this conversation with interest!)- The modern, end-user-friendly solution for something like you're describing might a game install/update service like Steam or GOG Galaxy. There are many work-in-progress commercial games (M&B II: Bannerlord comes to mind) which pursue a highly-active (near daily) update schedule on such services for their Beta branch, while preserving a monthly 'Main' branch for players seeking a less buggy and more consistent experience; both separate from their internal development branches of course. Granted, we're talking about projects made by teams 5-10x larger than the active dev team on 0 A.D., who are also full-time paid employees of a company, but I digress. In my experience making music software, a not-insignificant number of (non-Linux) users struggle even to do basic things like copy/paste or renaming files. I once sought a simpler solution for sharing FOSS musical sample library projects while in development and even went so far as to advocate the mediocre but relatively simple GUI-based Github Desktop app; yet still the vast majority just preferred to download the .zip from the mirror despite my best efforts and tutorials... so, personal rule of thumb, if setting something up is any harder than 'download thing and click a button', it's not going to fly for many if not most end-users. Even proper GUI-based installers can be problematic for many, especially if they click too quickly through and do not read the steps. I like your suggestion of separating the repos for art and such out. Already many of the original raw game sound effect assets are completely lost to time, so we're stuck with either replacing them outright or working from lossy file formats. Now we mostly do sound development over on a separate Git which functions as a Mod for the game, so a small group of us can iterate quickly on a few ideas (and share them with others) before committing anything to the game itself. Returning to the topic at hand, I think what you are doing looks great so far, especially if combined with the aforementioned new textures. I think the proper solution here would be to fully implement texture maps/keys for metallic as you suggested earlier, rather than trying to auto-detect. That'd probably take an enormous effort, but it is the sort of thing which needs to be done honestly. In the sound department, for A24 we mostly just tried to patch problems up with 'meatball surgery', but for A25 we're already at work on deeper, more fundamental changes to make the sound assets and their implementation consistent and "correct". Keep in mind 0 AD has been in development for well over a decade. There are brilliant, clever implementations of things, and sloppy messy hacks right next to each other in every corner of the game. New features and changes are not checked by a singular Producer or Director, but by the team as a whole- an experience which can seem at times like an inquisition, when the actual intention is to ensure there are no weaknesses in the proposal and that it will provide a suitable foundation for future development. The deeper the change, the more things are at risk, and as a result the game tends to move more slowly the deeper you want to go. It is easy for me to replace a few bad or poorly made sound effects from a decade ago, but when we get into stuff like changing (or fixing!) the way the sound engine works, it takes a lot more planning and discussion to make sure things work and what we leave behind will be workable for many years to come. In my opinion: Having said that, it also means it is fundamentally necessary that any code changes really need to be done the "right" way. Layers of hacks upon hacks is what has caused numerous issues on the project, so I believe it's essential whatever is decided must be done fully and in such a way that it doesn't impede future work. This means in a perfect world, changes shouldn't compensate for, override, assume, or guess about assets or previous work because that creates a feedback cycle of spaghetti going back into spaghetti. Ideally every change should be at the root of the issue, not treating or concealing the symptoms. If I understand your proposal and the architectures involved correctly, that means implementing this requires fixing textures so they give you explicit information on what is metallic, and integrating that in the workflow so all textures present and future have that.

It is the real sound of me cutting a log with an axe actually! It could be deeper and maybe more rotten/cracking sounding, as I was not able to find a very big log, instead using a modest log. I might try again later this year with a large tree branch or a proper tree if I can find one that needs to come down or if a storm blows one down. My thought with stone is to make it more 'flaky' and ring less, so it is more distinct from metal. More like a sandstone/sedimentary rock than the moderately hard rock sound in the game right now. The metal isn't realistic (metals usually appear only as trace elements, usually oxides, within certain types of rock) but it is distinct, so might just get left to make sure people do not confuse metal for stone. Thanks for being specific!

Thanks for your thoughts! Each sound uses both random pitch shifting AND a range of up to 10 randomly chosen variants, each constructed from a combination of unique audio components. I recorded all of the source materials myself, as it is much simpler and faster than digging through CC sounds (and less legal hassle). I've been designing sounds for games (and sample libraries) since 2010 so I have a pretty substantial library of custom recordings I have done to speed this up. For example, here are all the variants of the weapon attack + impact combo sounds (which we are using right now to demonstrate the result, until actual weapon impacts are properly implemented). Each component of the sound (thud, metal, swing noise, handling noise, armor noise, etc.) can be remixed as desired at any time: There are a few problems we are working with at the moment: Many of the original sounds are from before 2010, when the standards and style of sound design was very different. For example, many of the original sounds are of more of an arcade-y or non-realistic style, which was the dominant style of the early to mid 2000's (for example, metallic 'sliding' sword-on-sword noises, which are not how Bronze or Iron Age swords were used or sound). However, now it is expected that games such as this sound more realistic and accurate (e.g. Kingdom Come Deliverance, Mount & Blade II, even something late 2000's like Age of Empires III, versus older games like AoE I/II, Civ III, etc.). Many of the sounds also seemed to come from old sources or poor recordings with low sample rates, for example, many are missing content above 8 or 12 kHz, which is what gives them the 'harsh highs' you described. All of the new 'raw' recordings I am doing are at industry standard 48 kHz/24-bit sample rate and bit depth, using professional recording equipment. It is then very easy to tweak and improve the sounds because no information is missing. Any positional sound effect must be monophonic (single channel) for the sound engine, which greatly limits the 'colors' available, sort of like black and white vs. color photography. Too much reverb for example, and the sound becomes very muddy and 'wrong' sounding. So, we still must be careful with effects and processing! There were issues with the sound code which caused levels of some sounds to be massively off, so we are still tweaking levels to get sounds at correct volumes. For example, just playing through now, goat death sounds are very loud and sword attack sounds are a bit quiet. These are very very easy to tweak though, so we can adjust these a lot! Regardless, these sounds are still in draft form and will certainly see tweaks. There are now at least three qualified sound designers working on these and other new sounds so if all goes well, we will get a lot of nice results. For example, the metal and stone sounds were not done by any of us so have not been tweaked at all yet, and there already are some suggestions by the others to tweak the woodcutting and bow sounds slightly. My general advice with the new sounds is to play through a few games with them, and see if you still feel the same way when you compare back to the old sounds. We are making a big change here so it will be shocking at first to anyone who has played for a while (myself included!). If you or anyone else has more specific feedback (e.g. "I do not like the weapon sounds because of the low metallic part" or "The building sounds seem too dry/thin and low-pitched"), that would be much more helpful for us.

I think it'd always be great to have more folks helping out with sounds. I'm happy to cover the more instrumental stuff (notifications, alarms, etc.), but given the current situation recording foley or more animal sounds or the like is quite difficult. Generally 0 A.D. uses mostly organic sounds (i.e. recorded things) rather than synthesized sounds. There are lots of great open sources of free recorded audio online, such as freesound.org, but I'd always encourage trying to record sounds originally for the project whenever possible.

What about these for the town bell? I don't think it really needs that horn thing in there, but I could add one if needed... TubBells.zip