Le blog Games from Within de Noel Llopis a récemment abordé ce sujet dans la publication "Remote Game Editing" . Le premier paragraphe:
Je suis depuis longtemps un fan des durées de jeu minimales. Tout ce qui peut être fait hors ligne ou dans un outil distinct doit être hors du runtime. Cela laisse l'architecture et le code du jeu très simples et simples .
(L'article est une lecture fortement recommandée, comme avec la plupart des trucs de Noel, que vous soyez d'accord à 100% ou non.)
Je crois que la clé ici est de garder la complexité en dehors du moteur. Vous pouvez toujours avoir de la flexibilité, mais c'est de la flexibilité dans le pipeline de contenu. Et vous obtenez de meilleures performances en ne passant pas de temps à convertir et à déplacer des données.
De meilleures performances peuvent se traduire par une réduction du temps d'itération, étrangement, malgré la perte de certaines des capacités d'édition dans le moteur: il est plus facile d'essayer quelque chose si vous pouvez charger le jeu en une seconde.
L'adoption de certains des principes de la « philosophie unix » vous aidera à garder votre chaîne d'outils flexible: un petit pipeline modulaire.
Ma philosophie personnelle: cuire autant de données que possible hors ligne, mais fournir un support moteur pour recevoir de nouvelles données cuites à tout moment. (Notez que ces nouvelles données n'ont pas besoin d'entrer en jeu jusqu'à un moment opportun: le bouton "rafraîchir" est enfoncé, le niveau suivant commence, vous passez à une nouvelle zone, peu importe. La clé est de trouver le point idéal qui minimise temps d'itération avec un minimum de complexité de code et d'effort de codage.)
Dans notre entreprise, la plupart de nos outils destinés aux artistes / concepteurs sont axés sur les problèmes d'interface utilisateur: facilité de manipulation des actifs uniques ou de leurs lots, etc. Parfois, ce ne sont que des outils tiers comme Photoshop ou 3DS Max. Ces outils exportent vers un format intermédiaire (souvent xml qui fait référence aux données binaires source, mais pas toujours). Le format intermédiaire est repris par un outil backend "data make", qui le transforme en quelque chose d'utile et de rapide à charger pour la plate-forme cible.
La portabilité est obtenue en ajoutant des outils de création de données backend supplémentaires ou en étendant les outils de création de données backend existants, ce qui présente l'avantage supplémentaire d'être invisible pour les créateurs de contenu.
Maintenant, avec une bonne création de données incrémentielles, vous pouvez avoir des modifications au format cuit en quelques secondes; votre moteur peut spider, ou un outil peut spider, puis ceux-ci apparaîtront dans votre système de ressources, prêts à être rechargés quand cela sera pratique.
Les outils - en particulier les données de backend font des outils - sont souvent plus bâclés et plus bogues que le code moteur. C'est OK, car ils sont plus faciles à refactoriser / réécrire, étendre et tester; vous avez des spécifications pour leur comportement et il est assez facile de les tester unitairement par rapport à un code moteur.
Mes opinions sur vos questions:
Le moteur doit-il être capable de charger différents formats d'image? Un chargeur uniquement TGA est un code assez facile à manipuler.
(À part: même si vous utilisez un décodeur TGA dans le moteur, ne le codez pas manuellement. Vous demandez juste des problèmes - il y a beaucoup de subtilités avec la plupart des formats d'image et beaucoup d'outils qui n'adhèrent pas exactement au format probablement sous-spécifié. Il vaut mieux trouver le code de bibliothèque existant et bien testé pour le traitement d'image.)
Je voudrais que l'outil convertisse ici de TGA en quel que soit votre format de texture interne, plus des métadonnées.
Et les formats audio? Est-il possible de ne prendre en charge que le chargement de fichiers wav? Qu'en est-il des fichiers de musique ambiante qui sont souvent énormes.
Nous utilisons ici trois formats: musique suivie (.xm), ADPCM (.wav) et Speex (.spx). C'est principalement parce que nous sommes sur des ordinateurs de poche, et ces formats sont très légers à décoder.
Le moteur doit-il être capable d'analyser TTF dynamique et de générer un atlas? Emballage de texture.
L'atlasing est un problème difficile: consultez les réponses à vos questions récentes . Cela vaut presque toujours la peine de le faire hors ligne.
De plus, vous pouvez transformer les métadonnées par caractère en une structure cuite au code de chargement presque nul.
En terminant, vous pouvez nettoyer et empaqueter ce pipeline avec votre jeu, pour la communauté des mods. Vous pouvez toujours ajouter plus de formats source. Et rien ne vous empêche de combler l'écart entre les outils de création de contenu et le moteur dans des cas spécifiques; nous espérons que votre code de création de données et votre code araignée / transfert pourront être refactorisés dans des bibliothèques qui pourraient éventuellement être utilisées directement par les outils de création de contenu dans certains cas. Mais je ne ferais pas de cela mon premier objectif, nécessairement ... Sachez simplement que ce sera un objectif final et laissez cela influencer un peu votre conception, et optez d'abord pour les fruits bas.
En tant que mise à jour, vous pouvez envisager d'utiliser le format de fichier KTX pour les textures. Il a l'avantage d'être principalement «lu structet utilisé» pour la plupart des cas d'utilisation de GL (et d'après vos commentaires, il semble que vous visiez GL) tout en étant flexible et bien défini.
La surcharge de l'en-tête KTX peut être un peu élevée pour les données entièrement cuites, en fonction de votre cible, et vous voudrez peut-être renoncer à la prise en charge du swap endian, en fonction de votre cas d'utilisation ... mais cela vaut certainement au moins le coup d'œil pour des considérations de conception.