ICE : suite d'outils middleware multi-plate-formes

azsqamenarhyafeubebnmybgbscyhuvihawglelkagudazuiwigyiidgaisesityokkkncakyzh-CNkocohtkukmxhlolalvltlbmkmgmsmlmtmimrmndenenlnopafaplptpsrorusmcebsrstsisdskslsoswsutgthtatetruzukurtlfifrfyhahihmnhrnycssvsngdeoetjwja

PARIS, Juin, 2001.

Le développement de produits interactifs de qualité sur plusieurs plate-formes représente aujourd'hui un investissement significatif dans le coût global d'une production. La technologie est souvent la cause de dépassements de budgets et délais. Pour une description technique de ICE, suivre ce lien.

ICE (Interactive Creative Environment) est le fruit de plus de quatre années de travail des équipes R&D de Quantic Dream.
ICE est un environnement de développement complet intégrant toutes les technologies nécessaires au développement d'un produit interactif 3D temps réel. Ces technologies forment une suite d'outils cohérente et multi plate-forme permettant de diminuer de manière significative les temps et les coûts de production sans compromis sur la qualité.

L'architecture d'ICE est constituée de trois modules principaux :
. ICE 3D :

Un moteur 3D multi plates-formes (PC, PS2, Xbox, Internet) à architecture modulaire. ICE 3D propose toutes les features des moteurs 3D haut de gamme :
- Multi-texturing,
- Shadow-maps,
- Bump/Environment/Specular,
- Ombres portées temps réel,
- Transparence/opacité/particules,
- Radiosité, - Instanciation,
- Level of Detail progressif,
- Portals complexes,
- Communication avec Maya et Max.

Le moteur intègre également des features uniques comme la gestion des NURBS temps réel ou la gestion d'un scene-graph évolué. La communication avec les autres éléments ICE, notamment le Kernel et IAM, est assurée par un puissant système de messages. Bien qu'étant pensé et structuré pour le multi-plate-formes, ICE 3D ne sacrifie pas les performances à la compatibilité. Le moteur propose des portages bas-niveau spécifiques à chaque plate-forme afin de tirer le meilleur parti du hardware.
. ICE Kernel :

Ce noyau multi plates-formes est la pierre angulaire de la technologie ICE. C'est un système d'exploitation propriétaire prenant en charge la gestion des fonctionnalités de base (mémoire, réseau, commandes, streaming, etc.) de manière transparente et efficace pour toutes les plate-formes. ICE Kernel utilise une interface de communication totalement novatrice. Il intègre notamment un système unique de gestion des datas de la production sous forme de base de données. Toutes les données du jeu sont référencées dans une base de données, ce qui permet d'en contrôler le versionnage et d'assurer en permanence leur cohérence.
. IAM :

IAM est un outil de scripting évolué, permettant la gestion par un langage simplifié propriétaire (le "QuanticC++") de tous les évènements survenant dans un univers 3D. Son objectif est en premier lieu de permettre aux game designers eux-mêmes de "scripter" le jeu, de régler le game play ou la mise en scène, sans avoir besoin d'un programmeur. Ce langage puissant repose sur le C++, un langage orienté Objets, et en reprend toutes les caractéristiques dans une version accessible à des non-programmeurs. Un module IA peut par exemple être indifféremment appliqué à un personnage, un objet, une light ou une caméra. Des fonctionnalités évoluées ont également été intégrées, telles qu'un Module Caméra permettant l'enchaînement complexe de caméras temps réel ou un Module Localisation gérant la localisation des dialogues et textes écrits du produits de manière simple et pratique. En faisant porter son effort sur la création d'outils performants, Quantic Dream travaille à optimiser les temps de développements pour les nouvelles consoles sans compromis sur la qualité du produit. Cette architecture évolutive permettra de consacrer plus de temps au réglage du game play, et donc d'améliorer la qualité finale du jeu. Quantic Dream utilisera la technologie ICE pour tous ses prochains produits.

FRANCE:
+33 (0)1 44 64 00 90 info_fr@quanticdream.com

Quantic Dream, Omikron, The Nomad Soul sont des marques déposées et sont les propriétés de la société Quantic Dream.

© 2000 Quantic Dream. Tous droits réservés.

1/ PRESENTATION

1.1 Introduction

Les productions Multimédias deviennent de plus en plus complexes avec des technologies plus lourdes et des équipes plus importantes. Les risques technologiques et financiers sont encore accrus par les exigences des nouvelles plate-formes. Diminuer les temps de production, limiter les risques de dépassements de budgets devient indispensable.

Notre motivation en créant ICE a été de dépasser les simples problématiques d'affichage temps réel et d'assurer le respect des délais et de la qualité au niveau de la production grâce à un environnement de développement complet et cohérent.

En développant cette nouvelle génération de technologies, nos objectifs étaient simples et clairs :

o Développer une technologie en C++ orienté objet en tirant parti de nos expériences précédentes,
o Développer une plate-forme de développement évolutive, extensible et réellement multi plates-formes,
o Développer un frame-work permettant d'intégrer facilement de nouveaux développeurs, d'optimiser leur intégration par une vision globale et commune de la conception / développement,
o D'optimiser le processus de production en réduisant les causes d'erreurs et de problèmes récurrents, d'intégrer une logique de développement au niveau de l'équipe de production tout en simplifiant les processus de validation. En effet, un facteur important de réussite dans une production Multimédia est de détecter le plus tôt possible des situations d'erreurs, d'automatiser le processus de génération des data, ainsi que d'éviter l'aller et retour de données non valides.

1.2 Architecture

La plate-forme de développement ICE est constituée de trois modules : ICE Kernel, ICE 3D et IAM. Ces modules sont conçus pour utiliser et manipuler des données créées par des outils externes commercialisés. Plutôt que de développer des outils propriétaires de modélisation, mapping ou animation, nous avons préféré interfacer ICE avec les outils de référence connus de la plupart des utilisateurs (Maya™ ou 3DS Max™).

Ce découpage en trois modules correspond aux trois niveaux d'abstractions dans le développement de produits multimédias multi plates-forme

Il est important de savoir que ces modules, même s'ils sont clairement indépendants du point de vue de l'abstraction, de leurs fonctionnalités ainsi que de leurs utilisateurs, sont liés par ICE Kernel. Celui-ci, en effet, apporte des solutions efficaces et élégantes à des problèmes de production que nous décrirons plus bas. Les fonctionnalités développées dans ICE Kernel ont été largement utilisées pour améliorer à tous les niveaux l'efficacité de la production.

Nous allons décrire ici un peu plus précisément chaque module et expliquer clairement quelles sont les valeurs ajoutées de notre technologie et les solutions que nous avons apportées pour l'amélioration de la production.

2/ ICE KERNEL

ICE Kernel est la pierre angulaire de notre technologie. C'est non seulement l'API qui nous permet de gérer de façon transparente toutes nos plates-formes cibles, mais c'est aussi et surtout un Operating System.

En voici quelques fonctionnalités multi plates-formes de base :

o Fonctions mémoire de masse performantes (streaming intégré, synchrone, asynchrone, pile de chargement, flux…). Toutes ces fonctionnalités permettant de gérer facilement et très efficacement les accès limités des consoles (CD, DVD, Memory Card…).
o Fonctions mémoires évoluées (memory leak, crash mémoire, pool mémoires…). o Fonctions de rendu (DX8 ou OpenGL, compression des textures par ondelette).
o Gestion sonore (streaming, compression par ondelette, effets spéciaux…).
o Fonctions I/O standardisées. o Réseau. o Console de commande.
o …

ICE Kernel offre deux fonctionnalités majeures particulièrement intéressantes : une interface de communication et une interface de Base de Données.

2.1 Interface de Communication

L'interface de communication est la première pièce maîtresse de notre Operating System.

Son but est multiple, il permet :

- de linker plusieurs modules à l'OS pour lui permettre de les exécuter, de les ordonnancer et de les synchroniser.
- à un objet de s'enregistrer auprès de l'OS pour définir sa portée, ainsi que ses méthodes d'accessibilités. Cet enregistrement étant dynamique.
- de mettre en place un canal de communication entre deux modules et de posséder une gestion évènementielle des méthodes des entités.
- à des modules d'accéder à des objets enregistrés et d'appeler les méthodes associées sans avoir à manipuler l'objet directement.
- de trouver et d'exécuter des méthodes sur des objets enregistrés de manière dynamique. Chaque objet enregistré peut dériver d'un autre objet enregistré et donc bénéficier de ses méthodes s'il ne les surcharge pas lui-même (par le biais d'une table de méthode virtuelle).

Chaque méthode enregistrée peut utiliser comme paramètre entrant ou valeur de retour n'importe quel type de base (booléen, entier, réel, chaîne de caractère, vecteur, matrice…) ou un objet enregistré. Par exemple, si on ajoute un nouveau mode de rendu sous DirectX, il suffit d'enregistrer la commande à l'OS et le module Console retrouvera automatiquement la nouvelle commande et permettra de façon transparente de la détecter et de l'appeler si l'utilisateur le souhaite.

Cette facilité nous permet de créer très facilement des interfaces génériques. Si nous devions trouver une interface et des fonctionnalités similaires, notre interface de communication serait le croisement entre la gestion des fenêtres et des messages Windows et l'interface Automation de Microsoft™.

2.2 Interface de Base de données

La Base de Données est la deuxième pièce maîtresse de notre Operating System. En nous basant sur l'expérience acquise pendant le développement de Nomad Soul, nous avons listé les besoins primordiaux lors de la production de data en parallèle par une grosse équipe de production.

Il nous a semblé nécessaire de :

o Pouvoir contrôler toutes les données générées, leur création, chaque modification à la destruction.
o Assurer que deux décors/objets fabriqués à part une fois réunis ne génèreront pas de problème (conflit de nom par exemple…).
o Etre capable de réutiliser les data déjà produites et pouvoir les rechercher de manière globale.
o Connaître les dépendances entre les entités (telle texture est utilisée par tel objet qui appartient à tel décor…), ceci pour éviter toute suppression ou modification accidentelle qui pourrait entraîner un ralentissement inutile de la production (par exemple si une lumière est utilisée dans un script, sa suppression entraînera automatiquement un problème au niveau du script).
o Permettre à des scripteurs de pouvoir travailler sur des entités en sachant si elles sont effectivement disponibles et à jour.
o Pouvoir savoir quelle quantité de data la production possède, et ce pour chaque projet, pour chaque scène, chaque décor, chaque objet.
o Etre capable de changer facilement le partage de vos données lors de la gestion multi CD et/ou multi support.

Très peu de technologies accèdent à ce niveau de précision. Il existe effectivement des logiciels permettant de gérer des configurations au niveau des fichiers, mais ce sont des outils génériques et comme ils ne travaillent qu'au niveau des fichiers il est impossible de gérer des configurations de données multiples contenues dans un même fichier. Ainsi comment s'assurer qu'il n'existe qu'un seul objet nommé " Porte " dans tous les décors ? Il est indispensable de pouvoir garantir lors de la production, la veille d'une milestone par exemple, qu'en recevant un nouveau décor il n'y aura pas un autre objet " porte " qui invalidera alors le scripting. De la même façon, le scripting associé à un élément important du décor sera invalide si l'objet à été renommé ou supprimé par erreur.

La manière la plus efficace de résoudre ce problème est de gérer une base de données regroupant toutes les informations de bases pour chaque objet au sein de chaque fichier.

Cette base de données permet :

o De voir pour chaque élément son cycle de vie (Création, Modification, Destruction).
o D'avoir pour chaque élément des informations complémentaires (créateur, taille, remarques).
o D'assurer que deux entités ne portent pas le même nom dans tout les projet (ainsi l'exportation des données d'un autre projet se fait en toute tranquillité avec le script associé).
o Rechercher simplement des éléments par type, par nom, par critère quelconque.
o De regarder à tout moment les informations d'un élément (par l'Intranet par exemple).
o D'enregistrer les dépendances dans la base de données (et donc éviter les modifications, suppressions accidentelles ayant des conséquences).
o D'étiqueter un élément contenu dans un fichier.

Cette base de données se recoupe parfaitement avec une base de données de gestion de configuration plus classique travaillant fichier par fichier. De la même façon, sont greffées avec ces bases d'informations des connaissances précises pour chaque élément (par exemple pour une texture : sa largeur, sa hauteur, sa profondeur de bits, des remarques spécifiques, son type : bois, marbre, etc.).
Ces informations précises pouvant aussi bien être remplies de façon automatique ou par un utilisateur.
De plus la gestion de la base de données avec une notion d'espace disque virtuel permet le sharing d'informations (dossiers et/ou fichiers), on obtient alors un outil idéal permettant de tracer chaque donnée générée par la production quel que soit le type de données.

A l'exécution, ces avantages sont cumulés avec l'interface de communication. Ainsi tout objet communicant statique (non créé à l'exécution, mais créé par la production sous un outil comme Maya) sera enregistré dans la base de données, ce qui permet d'obtenir les nouveaux avantages suivants :

o Lors de l'exécution d'une méthode sur un objet qui est référencé mais non chargé, le module de communication s'occupe directement de son chargement sans intervention de l'utilisateur.
o Mise à jour automatique de façon transparente ou non les données binaires de la base de données, ceci permettant d'éviter l'invalidation des tests par des datas non à jour et toute erreur de manipulation. Cette solution permet d'être toujours assuré de travailler sur les bonnes données.

3/ ICE 3D

ICE 3D est un module enregistré auprès de ICE Kernel, il contient l'API communément appelée Moteur 3D. Cette partie effectue les exports des entités des logiciels commerciaux (comme Maya et 3DS Max) sous un scene-graph complexe et évolué, ainsi que son rendu par l'intermédiaire de la partie de rendu de ICE Kernel, le Moteur 3D se chargeant bien évidemment de gérer le scene-graph et tous les nœuds associés.

ICE 3D gère les features suivantes :

o Scene-graph évolué permettant l'instanciation.
o Lights Statiques et Dynamiques illimitées.
o LOD Progressif.
o NURBS avec gestion de coutures.
o Portals complexes.
o Octree.
o Module d'animation complexe (blending, empilage d'animations, messages).
o Animation par zone d'influence.
o Système de particules générique et évolutif.
o Exo-Squelette.
o Lipsync temps réel par Blend-Shape.
o Shadow Map, Light Map, Radiosité.
o Fog Volumique.
o Ombres portées dynamiques.

Chaque entité de ICE 3D est enregistrée auprès du module de communication de ICE Kernel. Ainsi chaque entité peut envoyer et recevoir très facilement des commandes et effectuer un processus de chargement simplifié et contrôlé (centralisé au niveau de l'OS).

La qualité du moteur garantit un excellent rendu avec la simplicité et l'évolutivité d'une interface repensée en profondeur.

ICE 3D est le module qui fournit les principaux objets communicants pour IAM.

ICE 3D est un module multi plate-formes à destination notamment des nouvelles générations de consoles (PS2, Xbox, GameCube) et du PC. Le code bas-niveau est optimisé pour chaque plate-forme afin de tirer le meilleur parti du Hardware et ne pas sacrifier la compatibilité à la performance.

4/ IAM

IAM est le troisième module-clé d'ICE.

IAM est conçu pour mettre en place de façon très simple des scénarios interactifs très complexes. Son objectif est de permettre à des scripteurs non-programmeurs de scripter facilement avec un langage évolué orienté objet. Ce langage de script, appelé Quantic C++, est basé en majeure partie sur du C++ expurgé de ses fonctionnalités complexes (arithmétique des pointeurs, templates, namespaces).


IAM intègre le cycle complet de compilation, assemblage et interprétation d'une machine virtuelle. Ceci permet d'assurer le multi plates-formes et d'exécuter de multiples portions de script linkées dynamiquement quelle que soit la plate-forme et avec le minimum d'occupation mémoire. Chaque portion de script est interprétée en multi tâche non préemptif.

Pour améliorer son interface ainsi que ses fonctionnalités, IAM a été conçu pour tirer partie au maximum des fonctionnalités de l'interface de communication ainsi que de la Base de Données de ICE Kernel.

Contrairement à beaucoup d'outils de scripting de jeux vidéo déjà existants, IAM n'est pas lié à ICE 3D ou à un autre module. En effet, la définition du langage se fait dynamiquement grâce à l'enregistrement des modules, des entités ou des méthodes au niveau de l'OS. Ainsi si nous voulons ajouter des fonctionnalités à IAM spécifiques au moteur 3D, il suffit pour l'équipe de ICE 3D d'enregistrer de nouvelles entités ou de nouvelles commandes.

Le scripteur bénéficie alors directement des nouvelles commandes sans avoir à modifier une seule ligne de code de IAM. De la même façon, si un scripteur veut appeler une commande sur un objet graphique défini sous le modeleur, on interroge à la compilation la Base de Données pour savoir si cet objet existe réellement. Ceci permet de valider à la compilation, donc bien avant l'exécution, le comportement des données externes. Cette validation automatique est très efficace si les données sont régulièrement modifiées.

Chaque classe de IAM peut contenir une entité enregistrée auprès de l'OS ou en dériver si besoin est. Cette fonctionnalité est très intéressante. En effet, prenons l'exemple d'une lumière définie au niveau de ICE 3D dans le code C++. Cette lumière s'enregistre auprès de l'OS et permet donc au scripteur par le biais de IAM d'utiliser toutes ses fonctionnalités rendues publiques. Le scripteur peut alors dériver une classe IAM de cette classe LIGHT du code C++. Attributs et Méthodes en dériveront également directement.

Le scripteur peut sur-définir le comportement de la lumière dans un contexte précis, par exemple, à la réception d'un message de collision entre un objet dynamique et le cône de lumière. On peut par exemple souhaiter qu'une lumière s'allume lorsqu'un objet se déplace dans son champ de vision à plus de 5 cm/s. Avec quelques lignes de script, on peut tester simplement la vitesse de l'objet provoquant la collision et définir un comportement en fonction. Et à la création de l'instance de cette lumière, on peut l'associer directement à la lumière définit dans une scène du modeleur.

Ainsi de manière très simple, on peut interagir en langage de script interprété sur un code écrit en C++. A aucun moment une ligne de code de IAM n'a été changée. Seule l'équipe de ICE 3D, par exemple, aura à enregistrer ses entités auprès de l'OS, le compilateur mettant alors automatiquement à jour le langage de scripting. Le processus d'ajout de features est très grandement optimisé et demande l'implication de beaucoup moins d'intervenants, ce qui implique par conséquent une maintenance beaucoup plus rapide et efficace.

Pour nous assurer de l'évolutivité des scripts, nous avons créé un langage orienté objet. Cette notion de scripting objet permet un scripting complexe proche du C++ tout en demeurant accessible.

Pour permettre à des scripteurs non-programmeurs (les game-designers par exemple) de se former et d'utiliser facilement les fonctionnalités de IAM, nous avons intégré différents Wizards, ceux-ci créant ou modifiant automatiquement du script. Il existe un Wizard pour la création des classes et des objets, pour faciliter l'entrée des principales expressions du Quantic C++ (IF, ELSE, etc.), pour les entités scriptables, les méthodes et attributs (comme dans Visual C++ 6.0), pour créer des caméras, des zones, des points de contrôles, des effets spéciaux.

Nous sommes continuellement en train de développer de nouveaux Wizards, pour respecter la devise suivante : " Meilleur sera l'outil de scripting, mieux il sera utilisé, et plus grande sera la profondeur de votre jeu ".

Un des effets intéressants de l'interface de communication est que l'application IAM peut s'enregistrer aussi auprès du Kernel. Ainsi, on peut piloter IAM avec des batchs, des scripts, des macros. Ces fonctionnalités nous assurent d'avoir un outil performant, utilisable sur la durée, pouvant s'adapter aux besoins les plus divers.

Il est intéressant de voir que le couplage de IAM avec l'interface de communication est très proche d'un Visual Basic couplé avec des objets automation, la différence étant que nous ne gérons que des scripts compilés et non interprétés (sauf dans la console de commande).

---

Previous News

• Quantic Dream Paris change de locaux
• [b]Last Art
• [b]Last
• Interview with Phillip Campbell, Senior Designer, ...
• Прохождение Omikron Nomad Soul
• Quantic Dream ouvre un bureau à San francisco
• Quantic Dream agrandi son équipe de Management
• Soluce Partie 4 Omikron - The Nomad Soul
• Soluce Partie 3 Omikron - The Nomad Soul
• Soluce Partie 2 Omikron - The Nomad Soul