Hey Everyone, since there’s been quite a bit of discussion on here about the sounds, I just wanted to chime in from a dev/CEO/user perspective.
Not adding sounds was a decision that sparked a lot of debates internally, especially because of the perceived standard being set after adding two planes with custom sounds. If anything, maybe the 757 shouldn’t have had its own sounds so as to not set that “standard”. There was also a long discussion about this same topic during the 757 development and one of the issues raised was this implicit standard it would set, by releasing two planes in a row with custom sounds.
We’re always trying to find the delicate balance between performance, time to develop, current state of features, plans for next updates and their dependencies, etc…
Since the beginning of the app, we’ve worked in iterations, gradually adding new details, and for this time, the iteration was made on an airplane feature.
It’s not a matter of quantity over quality or even laziness as I’ve seen in the thread. It’s more about a calculated risk/benefit when working on a product with deeply passionate users in addition to what Cameron mentioned here for the sounds in particular.
I’ve seen some questioning the reasons Cam mentioned. The performance aspect makes perfect sense and is part of the risk aspect I mentioned above. If we add another sound set, we don’t know the risks in terms of memory. What if the app starts crashing because of memory usage? Especially in a part like the sound system that we don’t fully control (it’s a third party plugin). Do we remove the sounds? We would have to halt development of other items to investigate and find a solution. It’s not a place we want to be in.
Another aspect is big picture development timeline. I’m talking about features that are core to many others like a new importer for 3D Models we’ll need in a year, a new lighting system, redesigning a system that another developer needs in order to continue their work on another feature. That type of stuff.
At the moment, I’m working on a significant feature which requires quite a bit of my time and focus. I have allocated the same amount of time on the A330 that I typically spend for another airplane, with a couple of added benefits: I was able to get a head start because the flight model had already gone through a rework, and the glass cockpit was mostly reusable from the A320.
For the sounds (and all related bugs and issues that come with adding a feature), when doing the risk/benefit analysis, my vote was more for using one of the high quality sound sets we had for the time being, instead of delaying both the 330 and the other feature I was working on.
In this case, the risk was some disscontempt on the part of the community and the benefit was freeing time to work on that feature and the fact that the users who are less passionate about the sounds can enjoy the A330 now instead of having to wait.
I’ve also read about our communication process and how this could have been communicated earlier. I believe we had plans to to just that but some communication mixup made us miss that part. We’ll try to do better next time.
In general though, I believe we’ve been doing a better job for the past releases about communicating what’s in development but we will always stay behind a line set by our past experience with announcing features that were in development.
I hope this helps shed some light on our decision process.