O blog Games from Within de Noel Llopis abordou isso recentemente no post "Remote Game Editing" . O parágrafo inicial:
Sou fã de tempos de execução mínimos do jogo. Tudo o que pode ser feito offline ou em uma ferramenta separada, deve ficar fora do tempo de execução. Isso deixa a arquitetura e o código do jogo muito simples e enxuto .
(O artigo é uma leitura altamente recomendada, como na maioria das coisas de Noel, se você concorda 100% ou não.)
Acredito que a chave aqui é manter a complexidade fora do mecanismo. Você ainda pode ter flexibilidade, mas é flexibilidade no pipeline de conteúdo. E você obtém melhor desempenho ao não gastar tempo convertendo e movendo dados.
Estranhamente, um melhor desempenho pode se traduzir em menor tempo de iteração, apesar de perder algumas das habilidades de edição no mecanismo: é mais fácil tentar algo se você puder carregar o jogo em um segundo.
A adoção de alguns dos princípios da " filosofia unix " ajudará você a manter sua cadeia de ferramentas flexível: um pequeno pipeline modular.
Minha filosofia pessoal: coloque o máximo de dados possível offline, mas forneça suporte ao mecanismo para receber novos dados armazenados a qualquer momento. (Observe que esses novos dados não precisam ser reproduzidos até um ponto conveniente: o botão "atualizar" é pressionado, o próximo nível começa, você faz a transição para uma nova área, qualquer que seja. A chave é encontrar o ponto ideal que minimiza tempo de iteração com complexidade mínima de código e esforço de codificação.)
Na nossa empresa, a maioria das nossas ferramentas voltadas para artistas / designers está focada em questões de interface do usuário: facilidade de manipulação de ativos únicos ou lotes deles, etc. Às vezes, são apenas ferramentas de terceiros, como Photoshop ou 3DS Max. Essas ferramentas são exportadas para um formato intermediário (geralmente xml que referencia dados binários de origem, mas nem sempre). O formato intermediário é escolhido por uma ferramenta de "criação de dados" de back-end, que o transforma em algo útil e de carregamento rápido para a plataforma de destino.
A portabilidade é alcançada adicionando ferramentas adicionais de criação de dados de back-end ou expandindo as ferramentas existentes de criação de dados de back-end, o que tem a vantagem adicional de ser invisível para os criadores de conteúdo.
Agora, com a criação de dados incrementais adequados, é possível alterar o formato inicial em segundos; seu mecanismo pode funcionar, ou uma ferramenta pode funcionar, e eles aparecerão no sistema de recursos, prontos para recarregar quando for conveniente.
As ferramentas - especialmente os dados de back-end tornam as ferramentas - geralmente são mais desajeitadas e complicadas do que o código do mecanismo. Tudo bem, porque é mais fácil refatorar / reescrever, estender e testar; você tem especificações para o comportamento delas e é bastante fácil testá-las unitariamente em comparação com algum código do mecanismo.
Minhas opiniões sobre suas perguntas:
O mecanismo deve ser capaz de carregar vários formatos de imagem? Um carregador somente TGA é muito fácil de manusear código.
(Além disso: mesmo se você usar um decodificador TGA no mecanismo, não o codifique manualmente. Você está apenas pedindo problemas - existem muitas sutilezas com a maioria dos formatos de imagem e muitas ferramentas que não aderem exatamente no formato provavelmente subespecificado. É melhor encontrar o código da biblioteca existente e bem testado para o processamento de imagens.)
Gostaria que a ferramenta aqui fosse convertida do TGA para qualquer formato interno de textura, além de metadados.
E quanto aos formatos de áudio? É possível suportar apenas o carregamento de arquivos wav? E os arquivos de música ambiente, que geralmente são enormes.
Aqui usamos três formatos: música rastreada (.xm), ADPCM (.wav) e Speex (.spx). Isso ocorre principalmente porque estamos no computador de mão e esses formatos são muito leves para decodificar.
O mecanismo deve ser capaz de análise TTF dinâmica e geração de atlas? Embalagem de textura.
Atlasing é um problema difícil: veja as respostas de suas perguntas recentes . Quase sempre vale a pena fazer offline.
Além disso, você pode transformar os metadados por caractere em uma estrutura de código de carregamento quase zero.
Para finalizar, você pode limpar e empacotar esse pipeline com o seu jogo, para a comunidade de mods. Você sempre pode adicionar mais formatos de origem. E não há nada que o impeça de preencher a lacuna entre as ferramentas de criação de conteúdo e o mecanismo em casos específicos; esperamos que seu código de processamento de dados e código de transferência / aranha possam ser refatorados em bibliotecas que possam eventualmente ser usadas diretamente pelas ferramentas de criação de conteúdo em alguns casos. Mas eu não faria esse meu primeiro objetivo, necessariamente ... Apenas esteja ciente de que será um objetivo eventual e deixe que isso influencie um pouco o seu design, e escolha primeiro os frutos mais baixos.
Como uma atualização, você pode considerar o uso do Formato de arquivo KTX para texturas. Ele tem a vantagem de ser principalmente "lido structe usado" para a maioria dos casos de GL (e, pelos seus comentários, parece que você estava mirando no GL), embora ainda seja flexível e bem definido.
A sobrecarga do cabeçalho KTX pode ser um pouco alta para dados totalmente integrados, dependendo do seu destino, e você pode querer renunciar ao suporte de troca endian, dependendo do seu caso de uso ... mas é definitivamente pelo menos valioso para considerações de design.