O equilíbrio tanto no aplicativo de design de som/música FMOD Studio quanto na API que o acompanha é bem avaliado em termos de simplicidade versus complexidade. O design de som e música realmente simples não leva tempo algum, e um motor de som em tempo de execução simples baseado na API é igualmente simples de codificar. Eventos de som complexos, posicionamento 3D (com comportamentos de atenuação personalizáveis) e trilhas de música interativas sofisticadas podem ser projetados e testados no aplicativo. Admitidamente, isso requer um pouco mais de conhecimento técnico, mas não há necessidade de conhecimento de programação em C++ para alcançar isso. O aplicativo também pode se conectar a um jogo em execução ao vivo para ajustar comportamentos em resposta aos dados reais do jogo, o que é inestimável. Motores de som mais complexos usando a API também são altamente personalizáveis. A API é simples de usar e o fórum de suporte é muito ativo, frequentado pelos próprios engenheiros da Firelight Technology (em vez de representantes apenas para triagem de problemas). Eles são muito responsivos, na minha experiência, e estão claramente empenhados em fazer do FMOD o melhor possível. Finalmente, tendo usado o aplicativo FMOD Studio desde seu lançamento inicial, fiquei impressionado com o processo de engenharia (de um ponto de vista externo) onde o aplicativo inicial era super básico, mas se desenvolveu ao longo do tempo. Há uma forte sensação de que seus processos internos para priorização de roadmap e QA estão funcionando bem (presumivelmente envolvendo testes automatizados extensivos, dado o número muito pequeno de regressões que experimentei). Recursos foram adicionados à medida que o aplicativo FMOD Studio e a versão da API foram incrementados e geralmente são compatíveis com versões anteriores. Análise coletada por e hospedada no G2.com.
Mencionei em meus comentários positivos sobre as atualizações tanto do aplicativo FMOD Studio quanto da API serem "geralmente compatíveis com versões anteriores". Isso é menos um ponto negativo, mas algo a se estar ciente ao escolher o FMOD Studio como seu middleware de áudio. A equipe do FMOD é ótima em tentar manter essa compatibilidade, mas às vezes na engenharia de software chega um ponto em que uma mudança disruptiva é, infelizmente, um mal necessário! Devido à forma como o FMOD Studio é desenvolvido, melhorado (e como as correções de bugs são aplicadas), talvez a única abordagem racional ao adotá-lo seja sempre manter-se o mais atualizado possível (em vez de se ater a uma versão específica de lançamento para um projeto). Você precisa estar ciente disso em seus próprios processos de gerenciamento de projetos e recomendaria incluir uma estratégia para atualizar mudanças disruptivas à medida que acontecem, em vez de acumular sua própria dívida técnica. Isso é bastante simples de fazer se você trabalhar de forma Ágil, especialmente porque os lançamentos das atualizações do FMOD estão em um cronograma previsível. Como eu disse, o FMOD parece respeitar esse problema e evita mudanças disruptivas, elas são bastante raras na minha experiência. Como exemplos, pode haver momentos em que todos os projetos .fspro precisem ser atualizados e migrados para uma nova versão (claramente isso impacta o trabalho de suas equipes de som e música). No lado da engenharia e QA, pode haver mudanças disruptivas na API, mas estas parecem ser (e não me lembro de uma exceção) do tipo em que a compilação simplesmente falha e o código precisa ser ajustado de acordo (ou seja, isso é uma espécie de coisa boa!!), em vez de mudanças sutis de comportamento que poderiam passar despercebidas por seus processos de QA. A menos que você tenha uma estratégia de teste realmente robusta (ou seja, cobertura total). Análise coletada por e hospedada no G2.com.
