Ok

En poursuivant votre navigation sur ce site, vous acceptez l'utilisation de cookies. Ces derniers assurent le bon fonctionnement de nos services. En savoir plus.

01/10/2009

Data driven engines, data driven bugs...

La plupart des moteurs de jeu modernes sont dit “data driven” i.e la majorité de l’expérience de jeu est défini par les données, pas par le code.

 

 

Evidemment, c’est beaucoup plus facile à dire qu’à faire.

 

 

Déjà, ces données doivent provenir de quelque part, et emmener ces données dans le jeu est le rôle principal du pipeline. Il y a 3 façons de produire les données qui vont composer une asset : par production avec un outil « externe » (3DSMax, Maya…), par production avec un éditeur interne (en général, l’éditeur de jeu), ou enfin par production automatisé de type batch (génération des light map ou du mesh de navigation, etc etc).

 

 

Jusqu’ici, tout va bien.

 

 

Le hic, c’est que comme le moteur est data driven, beaucoup de bugs ou de problèmes sont data driven aussi. En d’autres termes, il est plus ou moins aisé de créer des cas pathologiques, des problèmes de performances ou encore de réels bugs complexes dus à l’interaction entre ces données.

 

 

Du coup, quand on a identifié un de ces problèmes, on a souvent besoin de pouvoir remonter à la donnée source qui a produit l’asset. C’est l’une des qualités premières d’un bon pipeline que de simplifier ce travail d’investigation.

 

 

Et évidemment, ce n’est pas si simple que ça, car il n’y a pas une relation unitaire entre une asset donnée et un fichier source.

 

 

Un fichier source peut par exemple générer plusieurs assets. Il est ainsi fréquent que les animateurs stockent leurs animations dans un seul fichier pour Motion Builder afin de simplifier leur travail. Du coup, un fichier source va permettre de générer N animations, ces N animations pouvant parfois être utilisé dans M banques d’animations.

 

 

Le problème inverse existe aussi : une asset peut parfaitement être le produit de l’interaction entre plusieurs données. Par exemple, une texture compressée est le produit d’une texture d’origine et d’un fichier de configuration de compression. La qualité d’un mesh de navigation résulte de l’interaction entre les éléments de collisions et les informations de design posés dans tout un niveau.

 

 

Ces considérations de dérivations (retrouver le ou les sources qui ont produits l’assets), de dépendances (lister toutes les assets qui dépendent les unes des autres) ou d’interactions (retrouver les assets qui peuvent influer sur la production ou le comportement d’une asset donnée) forment le cœur des problèmes « data driven ».

 

 

Il n’y a pas de solutions idéales, mais il y a des outils et des process qui peuvent aider à se dépatouiller.

 

 

- Etre à même de tracer l’origine d’une assets, les différentes dépendances directes ou indirectes pour cette asset, et l’historique des fichiers sources concernés.

 

 

- Pouvoir reconstituer facilement tout ce qui a participé à la création d’une asset à un instant T donnée, ce qui signifie de pouvoir retrouver toutes les sources ainsi que tout les process qui ont participé à la création de l’asset.

 

 

- Permettre de versionner les assets, en autorisant (ou pas, voir au cas par cas) la rétro compatibilité. Permettre aussi de synchroniser ces versions afin de « labelliser » un ensemble d’assets et de fichiers sources pour archivage et/ou récupération postérieure.

 

 

- Etablir des mécaniques permettant d’identifier « gracieusement » les données manquantes ou mal formées : assets par défaut ou de secours permettant au runtime de continuer à fonctionner malgré une erreur dans une donnée, log et emailing automatisé, machine de tests unitaires ou de tests de stress…

 

 

L’essentiel, c’est de garder le contrôle sur ce qui va constituer le corps du jeu. Personne n’a envie de se retrouver à rechercher en vain un fichier 3dsmax contenant la modélisation d’un personnage qui a été ajouté 6 mois plus tôt. De même, découvrir par hasard une dépendance caché entre deux types d’assets disjoints peut être fatal à la bonne humeur quand on a nettoyé l’une de ces assets ^_^

14:28 Publié dans Code | Lien permanent | Commentaires (18)

Commentaires

Billet très intéressant Daz, merci. Ca parait évident mais comme toute évidence, c'est simple quand c'est clairement expliqué, comme ici.

Écrit par : Mickaël | 01/10/2009

Hmm je rajouterais :
- la possibilité pour le gus qui fait un asset de pouvoir le tester de suite avant de le remonter sur l'outil de versionning. Avec le process ad hoc pour "inciter" (batte de baseball, coup de poing américain) le gus a bien vérifier avant de remonter les datas.

- un serveur de build automatisé qui crache de la rom quand il y a changement sur l'outil de versionning avec mailling automatique du merdage aux responsables (voir à la DRH pour établir le solde de tout compte).

- avoir une tolérance à l'erreur afin de pas bloquer tous le monde en cas de foirage (parce que des gens qui ont plus rien à faire pourraient passer à des activités physiques impliquant le fautif).

- et si l'équipe dépasse une certaine taille, utiliser du versioning distribué afin d'avoir une organisation lieutenant / master pour la validation / intégration des assets avec même pourquoi pas un repository de staging et stable. Voir par exemple sur ce point l'organisation du dev du kernel linux avec git.

Écrit par : whirly | 01/10/2009

En fait moi je dis vive le travail solo ;D.
Sinon c'est marrant mais c'est souvent les graphistes qui causent les problèmes. Sinon avec de bons outils et une bonne méthodologie/suivi tu évites beaucoup d'écueils. Au début notre Middleware interne ne supportait pas le control+Z et je trouvais ça un enfer, et puis je me suis rendu compte que c'était génial car au final les petits gars à force de foirer/refaire/foirer/refaire/foirer devenait hyper bons et attentifs.

Écrit par : Pedro | 02/10/2009

Whirly, tu cites Git, tu m'intéresses.

J'ai commencé à faire des tests avec du versionning distribué. Ces outils (que j'utilise pour des projets hors bureau) disent généralement dans leur documentation (après en avoir mis des tartines sur le faite que c'était les meilleurs et que le centralisé, c'était une vaste blague préhistorique) qu'ils ne sont pas vraiment taillé pour les données binaires un peu importantes.

Et mes premiers tests (l'année dernière je crois) avait en effet réussi a faire crasher git, mercurial et bazaar sur un simple import de données de jeu.

(niveau code, pas de soucis).

Or, je vois l'intérêt que pourrait avoir la décentralisation dans une équipe, donc je n'ai pas encore lâché l'affaire.

Si tu utilises en production, ça m'intéresse.

Écrit par : Mokona | 02/10/2009

Je crois que tu touches au coeur du problème Whirly, et tes conseils sont bons...

Bon, j'admets que le poing américain, c'est un peu extrême quand même. Tu as essayer le bottin, ou simplement les chaises électriques ? Il y a aussi les retenues sur salaires, ou la simple auto flagelation verbale en public. Ca laisse moins de traces ^_^

Blagues à part, le versionning et l'historique des fichiers binaires posent de très sérieux problèmes. C'est aussi pour ça que les fichiers au format texte sont populaires comme format intermédiaire dans les pipelines, mais ça n'est pas toujours possible.

Nous, on utilise Perforce pour tout ça - qui est un système centralisé du bon vieux type dinosaure ;-) - et ça marche "pas si mal" que ça, enfin, au sens où les artistes sont habituées à faire des contorsions cérébrales pour arriver à l'utiliser.

J'ai aussi vu Alienbrain à l'œuvre, mais là, j'avoue ne pas en avoir gardé un souvenir glorieux.

Par contre, je n'ai pas beaucoup d'expérience avec les base décentralisé de type GIT. Je sais que c'est à la mode, et c'est à peu près tout.

Whirly va peut être nous en dire plus ^_^

Écrit par : Daz | 02/10/2009

Quelqu'un peut expliquer pour les novices ce qu'est la différence entre un système de versioning centralisé et un système décentralisé?

Je sais ce qu'est un système de versioning, je vois ce dont on parle quand on dit que quelque chose est centralisé/décentralisé, mais le mariage des deux, j'ai un peu de mal.

Écrit par : Mickaël | 02/10/2009

Dans un système centralisé (Perforce, Subversion), il y a un serveur central qui a la base de code. Chaque utilisateur peut travailler dessus, récupérer les données, modifier,... Toutes les opérations sont gérées par le serveur, en particulier les branches y sont forcément présentes.

On peut éventuellement avoir plusieurs instances, plusieurs bases, mais elles ne savent pas communiquer entre elles.

Dans un système décentralisé, le tronc central, la base officielle, n'est qu'un choix "arbitraire", il n'y a pas, du point de vue du système, de serveur central. Chacun a donc son dépôt sur son poste sur lequel il travaille, sur lequel il peut faire des branches sans gêner les autres et, surtout, il peut regarder les branches des autres, publier les siennes merger et faire merger des modifications sans impacter le tronc officiel et sans nécessité de faire gérer ses branches par ce serveur.

Un gros défaut du décentralisé, surtout avec nos grosses données binaires, c'est que l'historique étant dupliqué sur chaque poste, il vaut mieux avoir de gros disques.

Un autre problème dans notre métier, c'est l'impossibilité de faire des locks de fichiers. Or les artistes sont habitués à travailler en lockant leurs ressources (souvent binaire est nettement plus difficilement mergeable que du code). Il faut remplacer ça par des règles d'équipe.

Par contre, si la base centrale tombe, ça ne gêne pas la production.

On peut aussi imaginer des processus d'intégration à base de build machine beaucoup plus flexibles qu'avec une base centrale (et moins coûteux en matériel car ne nécessitant pas un gros serveur avec un gros tuyaux)

Bon, il y a encore de quoi en parler pendant quelques pages...

Écrit par : Mokona | 02/10/2009

Alors Whirly va parler pas la peine de continuer à me mettre cette lampe de bureau dans la tronche.

Pour l'instant nous avons passé le cap des tests et nous sommes dans la phase de mise en production de Git. En gros nous avons passé le développement de Turn (notre superbe jeu iPhone, si si) sous Git pour la simple raison qu'on fait un épisode 1 & 2 en plus de la version lite, le tout sur 3 plateformes et que donc ça va brancher !

Je pourrais donc vous faire un compte rendu détaillé à la fin. On va dire qu'une des raisons principales du passage à Git c'est le branching et surtout la possibilité de bosser sur une features, la mettre de côté l'espace de 2h le temps de faire un fix sur la version en cours d'utilisation pour rebasculer juste derrière sur votre feature. L'aspect du travail en déconnecté peut aussi être sympa du moins jusqu'à ce que la SNCF met le wifi dans les trains. Effectivement on pourrait en noircir des pages.

Après il faut dire qu'il y a un an de ça, j'avais déjà fait une première eval de Git et c'était pas glorieux, genre pendant l'utilisation tu entendais la musique de McGyver dans le fond. A présent on commence à avoir du TortoiseGit et ce genre de truc qui permettent de faire utiliser ça même par du graphiste unijambiste (

Écrit par : Whirly | 02/10/2009

Moi la difficulté que j'ai dans ce genre de choses est liée à la différence entre les fichiers sources et les fichiers exportés. En gros je cherche depuis longtemps un soft qui permettent de packager le tout en gros tu aurais un truc qui dirait:
machinquibouge_bg.png ------> machinquibouge.psd
machinquibouge_item_1.png ------> machinquibouge.psd

le truc c'est que le version de fichiers genre les .psd c'est merdique il y a un truc qui s'appelle version cue mais j'ai jamais réussi à le faire utiliser efficacement.
Il y a aussi un truc que j'ai jamais réussi à résoudre c'est comment gérer des datas non importante mais lié à un projet. Par exemple mes GD adore faire du benchmark et blinde le svn de screenshots, docs, liens etc.... cependant ces fichiers n'ont pas besoin d'être versionné mais il ont besoin d'être stocké dans le dossier du projet. L'autre point important est les merge genre un txt ou xml ça merge bien, un .doc ou un docx non encore moins les xls alors que le csv merge parfaitement.
Mais bon j'avoue que je n'y connais pas grand chose car je suis d'un graphiste unijambiste :S

Écrit par : Pedro | 02/10/2009

Ben déjà chez toi ils sont pas convaincu qu'utiliser un controlleur de code source ça soit utile.

La différenciation entre fichiers sources et exportés il n'y a même pas à en faire, c'est pour ça qu'on a créé les serveurs de build. Ou alors tu peux écrire un post commit hook sur le serveur subversion qui va chopper les informations dans les meta du fichier commité pour voir s'il faut faire une transformation dessus. Reste qu'il y a toujours des data qui doivent être manipulé à la main ; l'objectif principal c'est de réduire ce nombre à zéro. Mais bon Ingenieur Build c'est un métier ;)

Les trucs qui ont pas besoin d'être versionné tu fais un joli répertoire partagé avec ça dessus, et tu t'arranges quand même pour que ton process de backup sauvegarde ce répertoire (t'as bien un process de backup hein ?)

Un XML ça merge pas forcément bien, d'ailleurs de base l'outil de merge connait pas la sémantique de tes données. Le seul truc c'est qu'il est plus simple de merger des fichiers textes que des binaires parce que là l'humain peut s'y retrouver.

Un bémol néanmoins, avec une version récente de tortoiseSVN il peut faire des diffs sur les .doc et autre xls en lançant directement office.

Écrit par : whirly | 03/10/2009

Merci pour les explications !

Écrit par : Mickaël | 03/10/2009

Pedro, tu devrais forcer tes GDs à utiliser un wiki et leur désinstaller Microsoft Office de force :)

Écrit par : channie | 03/10/2009

Pour avoir mis cette stratégie en place dans ma boite (Office -> Wiki) il y a une grosse barrière à passer, je peux ainsi citer :
- être sur qu'on va pas leur faire apprendre un langage de markup pour faire un quelconque truc (et là souvent les wiki niveau éditeur wysiwyg c'est la dèche).
- pouvoir facilement coller des images, là aussi niveau pièce jointe c'est vraiment un truc sur lesquels les wiki sont pas très fort.

Ca laisse clairement de la place pour vendre du wiki avancé aux entreprises.

Écrit par : Whirly | 04/10/2009

@Whirly : merci pour le retour.

Écrit par : Mokona | 05/10/2009

Clair, très instructifs.

En parlant de Wiki, j'ai eu une excellente expérience avec Confluence ^_^

Écrit par : Daz | 06/10/2009

ahh! ca parle de Git :)

J'ai poste, sur mon blog, quelques commentaires sur mercurial (hg pour les intimes) que j'utilise depuis maintenant un peu plus d'un an.
Pour faire court : j'en suis tres content, tant en ligne de commande qu'avec l'interface windows qu'est tortoisehg. de vieux posts sur mon blog parlent de l'integration avec cc.rb (cruise control pour ruby) et "ca marche".

Pour ce qui est des chiffres : la base fait 3.67GB repartis en quelques 80 000 fichiers (ce qui n'est pas enorme, mais bon...).
Je travaille sur 3 branches en continu, mais plusieurs 10ene ont ete cree et remergee definitivement. Le changelog indique quelques 100 ene de commits.
Je n'ai jamais eu de probleme lies a la taille de fichiers le plus gros faisant environ 150 Mo (c est pas la mort non plus).
Mercurial tiens le coup sous des commit de plusieurs 1 000 de fichiers totalisant plusieurs 100 ene de MB, jamais eu de probleme de ce cote la.

Le seul probleme qui m'a vraiment fait peur et un merge de deux branche (dont une partielle) que mercurial n'arrivait plus a faire : il pensait que tous les fichiers manquant de la branche partielle avaient ete effaces.
J'ai du exporter des patch et les reimporter en changeant le base path du commit : aucune perte de donnees n'est arrive dans ces temps de crise ;)

Pour le reste "ca marche". Ce n'est pas une base de production attaquee par des centaines de personnes mais je pense que Git, tout comme mercurial, s'en sortent tres bien pour ca.

Ca se combine assez bien avec perforce et il est possible de maintenir en sync des repository hg et p4 a l'aide d'un script. Resultat je pense que l'utiliser en complement d'un serveur centralise peut etre une bonne idee.

Voila pour mon experience avec les scm distribues... j'espere que ca sera utile pour certains d'entre vous.

A+
Gab'

Écrit par : Gabriel Ware | 07/10/2009

Et pas de soucis, que ce soit avec Git ou Hg avec Tortoise ?

J'ai l'impression qu'il met un temps fou à mettre à jour les petits icônes dans l'explorer et que parfois, ça fait juste planter l'explorer... (encore une fois, tests vites faits l'année dernière).

La synchro P4/HG (ou autre) peut-être pas mal intéressante, surtout sur la partie programmation, où l'on a parfois envie de se passer des choses sans se synchroniser complètement.

Écrit par : Mokona | 07/10/2009

Mon experience tortoisehg :
- il y a un an et des brouettes, soft pas tellement exploitable, ralentissements / crash / interface pas geniale
- aujourd'hui : soft plutot bon, interface intuitive, pas de ralentissement d'explorer, interface pas tres rapide en regle generale, carrement lente si on a beaucoup de fichiers pending.

Personnellement j'utilise tortoisehg quotidiennement depuis quelques mois (2 ou 3 ... oui du coup ca fait quelques ;) ), pas de probleme majeur avec. Me suffit et n'ai pas de whish autre que "si ca pouvait rafraichir plus vite quand je click sur update ca serait parfait" :)

oui j'aime bien l'idee de la synchro p4/hg, surtout que de ce que j ai compris cela concerve l'historique de commit hg, qui est souvent beaucoup plus atomique qu'avec les scm centraux (ou on fait tres attention a ce qui est commit et donc on a tendance a retarder le commit, ce qui est mal).

Écrit par : Gabriel Ware | 07/10/2009

Les commentaires sont fermés.