I. Introduction - Children of the Sun

CHILDREN OF THE SUN
The Mysterious Cities of Gold
CONTROL THE SUN
Game Design Technique
DESS JVMI - 2004
1
Table des matières
I. Introduction
II.
Aspects techniques à implémenter
III.
Contraintes de la plateforme choisie
IV. Le Capteur solaire
Spécification technique
Introduction
Réalisation du capteur
Architecture du capteur
V.
Outils choisis pour la maquette
1.
Outils de développement
2.
Outils de modélisation et création graphique
VI. L’architecture logicielle
1.
Choix du langage de développement : C ou C++ ?
2.
Organisation des différentes couches logicielles
3.
Boucle de jeu
4.
Clarté du code et conventions
VII.
Le moteur de jeu
1.
Rendu 3D
2.
Les caméras
3.
Configuration
4.
Effets spéciaux
5.
Intelligence Artificielle
6.
Moteur de son
7.
Gestion événementielle
8.
Gestion des animations
9.
Gestion des éléments d’interface
10. Gestion de la physique
11. Gestion des entrées utilisateur et gameplay
ANNEXE 1
Définition de la température de couleur
Théorie de mesure de température de couleur
DESS JVMI - 2004
-3-3-4-6-6-6-7-7-8-8-9- 10 - 10 - 10 - 11 - 11 - 12 - 12 - 12 - 13 - 13 - 17 - 22 - 24 - 24 - 25 - 25 - 28 - 30 - 31 - 33 -
2
I.
Introduction
Jeu d’aventure monojoueur prévu pour la PSP (Playstation Portable) de Sony
utilisant la licence des Mystérieuses Cités d’or.
Périphérique capteur solaire.
Le rôle du game design technique est de répondre à toutes les questions d’ordre
technique lors du développement du jeu. Ces solutions proviennent du travail de
réflexion effectué lors de la phase de pré production du projet.
II. Aspects techniques à implémenter
D’après les spécifications du Game Design, le jeu devra comporter les aspects
techniques suivant :
-
Rendu 3D de haute qualité adapté à un écran de portable
Support d’un capteur solaire
Rendu de textures optimisé
Support d’animation
Support d’un gamepad avec stick analogique
Gestion des collisions
Gestion des musiques évènementielles et des effets sonores 3D
Gestion de plusieurs types de caméras (phases extérieur/intérieur et vol en
Condor)
Gestion de 2 types de gameplay (Esteban et le Condor)
Gestion de monde semi-ouvert
IA de coopération avec le joueur pour les personnages Tao et Zia (système de
formation)
IA de différents niveaux pour les ennemis
Scriptage de comportement pour certains PNJ (Mendoza, Sancho et Pedro…)
Support d’un certain nombre d’effets spéciaux (éclairages, particules, eau, etc.)
Chargement de certaines variables à partir de fichiers pour faciliter le réglage du
gameplay et le débogage
DESS JVMI - 2004
3
III. Contraintes de la plateforme choisie
Caractéristiques de la PSP :
Voici les caractéristiques de la PlayStation Portable telles que l’on peut les
trouver à l’heure actuelle sur les documents officiels de Sony.
Caractéristiques générales :
- Dual CPU
- Advance 3D Graphics Engine
- AVC Decoder
- Universal Media Disc (1.8 GB)
- 16:9 Wide screen TFT LCD
o Equipped with backlighting
-
o 480x272 screen resolution
o High resolution for portable
Embedded Wireless LAN
Memory Stick Pro
Caractéristiques du CPU:
-
Caractéristiques graphiques:
-
De plus la PSP
•
•
•
•
•
•
MIPS R4000 32 bit core
333 MHz
Main Memory 32 MB (eDRAM)
Bus Bandwidth: 2.6 GB/sec
I-Cache, D-Cache
FPU, VFPU (Vector Unit): @2.6
GFlops
256bit Bus, 166 MHz
VRAM: 2 MB (eDRAM)
Bus Bandwidth: 5.3 GB/sec
Pixel Fill Rate: 664 M pixels/sec
Maximum 33 M polys/sec (T & L)
24 bit Full Color : RGBA
offre les fonctions suivantes en hardware :
Transform and lighting
Clipping
Skinning
Morphing
Surface Tessellation
Rendu en polygones et patches Bezier et B-Spline
Périphériques d’entrée/sortie :
-
support du Memory Stick pro (capacité de stockage > 1 GB)
USB 2.0 (très rapide, jusqu’à 480 Mbps), rétrocompatibilité avec USB 1.1
DESS JVMI - 2004
4
Touches d’interface utilisateur :
Flips L et R
Pad analogique
Start/Select
Boutons de contrôle
Ces touches sont similaires à celles de la Playstation et Playstation 2 excepté
l’absence des touches L2 et R2.
La PSP étant à l’heure actuelle une console en prévision et certains des
aspects techniques n’étant pas encore confirmés, il nous a fallu travailler en
nous basant sur des hypothèses, principalement en ce qui concerne la taille
de la mémoire, le langage de développement et la possibilité d’utiliser un
middleware.
Après lecture des caractéristiques techniques de la future portable sur les
documents officiels de Sony, la PSP serait a peu de choses près une PS2 à
laquelle seraient ajoutées des contraintes au niveau de l’écran.
En effet, celui-ci est de dimension et de résolution réduite (480x272 pixels) et
en 16/9. Le rendu devra donc utiliser au mieux cette taille d’affichage.
Par ailleurs, tout comme la PS2, la PSP disposera d’une mémoire vidéo très
limitée de seulement 2 Mo (sources de Mai 2004). Ceci limitera de beaucoup
la quantité et la qualité des textures affichables à l’écran (2 Mo de textures
affichables par frame calculée).
Cette contrainte va nécessiter de notre part de surveiller constamment
l’utilisation de la mémoire vidéo et de trouver des optimisations et des
astuces pour utiliser cette caractéristique au mieux (petites textures,
déchargement de la mémoire des textures non rendues …).
En revanche, la taille de l’écran et la résolution pourront jouer à notre
avantage : l’utilisateur fera forcément moins attention au détails des textures
que sur un téléviseur.
DESS JVMI - 2004
5
De plus la PSP sera capable d’afficher un très grand nombre de facettes à la
fois (33 millions/frame théoriques).
Des modèles plus détaillés pourront donc compenser dans une certaine
mesure la faiblesse des textures.
Toutefois il est préférable de prendre ces chiffres avec distance, car même si
la PSP pourra gérer beaucoup de polygones rien ne dit qu’elle pourra le faire
en gardant un taux de rafraîchissement décent.
Nous nous baserons donc principalement sur les capacités de rendu de la
PS2.
IV. Le Capteur solaire
Spécification technique
Plage de Température
Plage de valeur en température
Plage de valeur en intensité
Tension d’alimentation
Interface avec console
Prix Unitaire
Quantité de fabrication minimale
1000 - 10000 °C
8 bits Linéaire
8 bits Linéaire
5 Volts ?
(dépend de l’interface)
USB 2/Autres?
5 Euros HT
50 000 unités
Introduction
Etudier les contraintes d’un tel capteur est primordial pour des raisons de
réalisme.
Un capteur de température de couleur est plus complexe qu’un capteur
photosensible.
De par sa spécificité, la mesure de la température de couleur dans des conditions
industrielles et commerciales valables, nous obligent à nous orienter sur une
approximation de cette température au travers d’une photodiode (capteur
d’intensité lumineuse).
NB : Il ne faut pas confondre l’intensité lumineuse et la température de couleur,
qui sont deux phénomènes certes dépendants mais dont la nature est différente.
Ce qu’il est important de retenir, c’est la notion d’une bi-mesure du capteur :
- une intensité lumineuse dans un spectre visuel en Ampère (A)
- une approximation de la température de couleur en Degrés Celsius (°C)
La réutilisabilité de ce capteur est évidente. L’application plausible est la
météorologie (affectations de la luminosité directement dans un jeu,
synchronisation du temps (nuageux, ensoleillé) entre le jeu et la vie réelle, …).
DESS JVMI - 2004
6
Réalisation du capteur
Pour des raisons d’étalonnage du capteur et pour des raisons industrielles, ils ne
serait pas raisonnable de penser que le capteur ne puisse fournir qu’une lecture
approximative de l’intensité lumineuse.
Rien n’interdit plusieurs industriels de fabriquer ce capteur.
Ce qui voudrait dire des composants, des filtres photo différents et donc des
capteurs différents.
On rencontre cette problématique avec les joysticks analogiques pour PC (a
chaque fois que vous branchez un de ces joysticks, l’étalonnage est obligatoire).
Sur Playstation la partie analogique du Pad est directement étalonnée sur le
joystick lui-même, de manière industrielle.
C’est donc vers cette voie qu’il faut orienter notre capteur.
Architecture du capteur
Le système est composé d’une partie analogique
qui correspond à la transformation du signal
lumineux en un signal utilisable.
D’une partie numérique, composée essentiellement
d’un microcontrôleur équipé d’un convertisseur
analogique/numérique, de mémoire morte et
volatile, d’une unité de calcul et d’adressage et
d’interfaces sériel ou parallèle.
Un composant fera aussi l’interface entre la
Playstation et le capteur.
Une partie pouvant être prise en compte par le
microcontrôleur.
Le microcontrôleur
effectuer comme :
-
DESS JVMI - 2004
aura
plusieurs
tâches
à
La gestion de l’énergie
La conversion du signal analogique
Le calcul de la température
La restitution des informations de température de couleur
et d’intensité lumineuse
Le paramétrage à la volée via l’interface avec la
Playstation comme : le temps de mesure, la fréquence
des mesures.
7
V.
Outils choisis pour la maquette
1. Outils de développement
La question des outils de développement à utiliser pour la maquette est
relativement délicate.
Pour le moment nous n’avons que très peu d’informations sur les API qui
seront disponibles pour le développement sur PSP, même si l’extrait de code
source fourni par Sony fait penser à de l’OpenGL.
Par ailleurs la maquette a un rôle de support du projet et doit donner un
aperçu du gameplay, de l’aspect et du déroulement du jeu.
N’étant pas la version finale du jeu, elle peut donc être développée en
utilisant des outils différents, à condition de prendre en compte les
contraintes de la console.
Compte tenu du temps de développement qui est disponible et de la relative
ambition du projet, le meilleur choix nous a semblé être l’utilisation d’un
middleware plutôt que des API de plus bas niveau comme DirectX ou OpenGL.
L’utilisation de middleware est de plus en plus répandue depuis quelques
années permettant aux studios de développement de gagner un temps
certain sur la création d’outils pour le jeu (gestion de caméra, entrées
utilisateur, collisions, effet spéciaux, …).
A l’heure actuelle, des middlewares sont prévus pour la PSP, dont la
plateforme RenderWare de Criterion Software.
Nous avons eu connaissance de l’existence des middlewares suivant :
- Virtools
- NetImmerse
- RenderWare Graphics
- RenderWare Studio
Virtools possède des fonctionnalités intéressantes et permet d’obtenir des
résultats visibles assez rapidement. En revanche, ce middleware s’avère
plutôt rigide et peu pratique si l’on veut programmer et intégrer ses propres
outils. De plus il convient assez peu au développement sur PSP, notamment
pour certains aspects de Gameplay du projet (Système de formation,
coopération entre PNJ).
Nous avons entendu parler de NetImmerse par notre tuteur. Celui-ci paraît
intéressant, mais il ne nous est pas mis à disposition par la formation et il
nous sera donc difficile de travailler efficacement avec.
Notre choix s’est finalement arrêté sur RenderWare Graphics.
Ce Middleware est suffisamment souple pour nous offrir une grande liberté de
programmer nos propres structures logicielles.
DESS JVMI - 2004
8
Les outils et les plug-ins qu’il propose sont très intéressant (caméras,
particules, rendu cel-shading, gestion des entrées utilisateurs…) pour le
résultat que nous visons.
Enfin, il est tout à fait adapté au développement sur la PSP puisqu’une version
de RenderWare pour PSP est prévue d’ici quelques mois.
En revanche, nous n’avons pas l’intention d’utiliser l’éditeur de RenderWare
Studio. Après étude de son mode de fonctionnement et de ses capacités, nous
pensons que cet éditeur n’est pas suffisamment adapté à ce type de jeu.
Bien sûr il est possible de modifier les structures existantes et d’en créer de
nouvelles, mais ce travail risque d’être fastidieux et de ne pas nous faire
gagner beaucoup de temps au final.
Enfin, en raison de contraintes budgétaires, il est préférable de se restreindre
aux composants essentiels.
De même, il n’est pas prévu d’utiliser les autres composants disponibles de
RenderWare, comme RenderWare Physics ou IA.
2. Outils de modélisation et création graphique
-
3D Studio Max 6.0 pour modéliser et éditer les niveaux
Photoshop 7 pour créer les textures
Flash MX pour les interfaces
Exporteur 3DS Max vers RenderWare
Plug-ins …
DESS JVMI - 2004
9
VI. L’architecture logicielle
1. Choix du langage de développement : C ou C++ ?
Si l’on se réfère à la PS2, le C serait plus adapté au développement.
Bien que l’architecture de la PSP s’annonce proche de la PS2, il est difficile de
trancher à l’heure actuelle.
Le C++ permet une implémentation plus propre, une meilleure lisibilité, et de
bénéficier d’un système de hiérarchies (polymorphisme, classes héritées …) et
donc faciliter le développement.
En effet, une vision objet de l’architecture est généralement bien adaptée au
développement de jeux vidéo.
Le C++, qui a été adopté pour le développement de la maquette pour des
questions d’efficacité, sera probablement conservé pour le projet final.
Un passage du C++ au C sera éventuellement possible pour certaines
structures si le programme nécessite d’être optimisé.
2. Organisation des différentes couches logicielles
Première décomposition en packages d’objets pour chaque partie du moteur
de jeu :
- rendu graphique (effets visuels, optimisations, objets du jeu)
- gestion de la physique
- IA et comportements
- rendu sonore (buitages, musiques)
- gestion des entrées (manette, interface capteur solaire)
DESS JVMI - 2004
10
3. Boucle de jeu
Les différentes étapes importantes du déroulement du jeu seront effectuées
dans un ordre bien précis au sein de la boucle de jeu ou « Main Loop ». Voici
une représentation simplifiée de cette boucle :
While( end != 0 )
{
ReadInputs(…) ;
//lecture
des
entrées
(touches
pressées,
messages
envoyés)
ProcessInputs(…) ;
//traitement des entrées
ProcessSounds(…) ;
//traitement des effets sonores
UpdateGameScene(…) ;
//mise à jour de la scène du jeu
//animations, transformations 3D, affichages…
CheckState(…) ; //vérification de l’état du jeu en fin de cycle. Détermine
si la boucle
//continue, le game over, le passage au niveau
suivant, etc.
}
4. Clarté du code et conventions
-
Charte de programmation : quelques règles simples de syntaxe, inspirées
de la notation hongroise, pour faciliter le partage du travail entre
programmeurs et autres membres du groupe.
o Casse différenciée pour les variables :
§ Tout en minuscules pour les variables locales et temporaires.
§ Tout en majuscule pour les « defines » et champs d’un
« enum » (les valeurs constantes en général).
Ex : #define GRAVITY 9.81
§ Majuscule pour la première lettre d’un nom contenu dans le
champ d’une classe.
Ex : RwReal RotationSpeed ;
RwBool Alive ;
§ Paramètres des fonctions en minuscule pour ne pas apporter
de confusion avec les champs d’une classe.
Préfixe « MCoG » pour chaque nom de classe créée pour le projet
pour les différencier des classes préexistantes dans RenderWare ou
autre bibliothèque utilisée
Ex : MCoG3DActor ;
MCoGCharacter ;
o Eventuellement on pourra utiliser un préfixe pour indiquer le type
d’une variable :
§ i pour int
§ f pour float
§ b pour bool
§ etc.
Cependant RenderWare utilise ses propres noms de type et ceci
pourrait amener une certaine confusion. A utiliser avec précaution.
Nom de variables très explicite. Afin que l’on sache sans ambiguïté à quoi
sert une variable.
Ex : éviter les variables du type « int tmp1, tmp2, tmp3 ; »
o
-
DESS JVMI - 2004
11
-
Code commenté (en anglais autant que possible)
Utilisation d’indentation et de retour à la ligne autant que possible pour un
code aéré et donc une meilleure lisibilité.
VII.Le moteur de jeu
1. Rendu 3D
Utilisation des fonctions de rendu de Renderware Graphics et de plug-ins pour
obtenir les effets spéciaux voulus.
Le jeu utilisera les techniques d’optimisation de rendu suivantes:
-
LOD (Level Of Detail) pour optimiser la résolution du maillage des objets
3D à afficher. Le moteur choisira et affichera parmi plusieurs niveaux de
détail, le modèle ayant la résolution qui correspond à la distance
d’affichage.
-
BSP Tree et Octree pour optimiser les faces à afficher et les tests de
collision.
-
Mip Mapping pour afficher des textures de résolution différente en fonction
de leur distance. Ceci permet d’optimiser le volume de texture affichable à
la frame. La taille des textures devra être adaptée à la capacité mémoire
de la PSP.
2. Les caméras
2 types de caméra différents :
•
•
Vue exploration : inspiration de Zelda Windwaker et Ocarina of Time sur Nintendo GameCube. Le
point de vue de la caméra suit les déplacements du héro.
La caméra reste à une position relative fixe du héro tout en prenant en compte le décor pour les
collisions (une réduction de la distance au héros se produit alors)
Vue Condor : vue arrière+plongée pour une bonne visibilité du paysage. Le point de visée de la
caméra est basé sur la position du Condor et non son orientation. La position de la caméra est un
point relatif au condor fixe.
Calcul du suivi de caméra :
Les éléments de suivi de la camera sont :
Son angle de rotation sur l’axe Y
La distance entre la caméra et la cible
La hauteur entre la caméra et la cible
DESS JVMI - 2004
12
L’ajout d’une vitesse de déplacement rajoute un effet smoother du
mouvement.
Chacun de ces paramètres possède une vitesse de déplacement, une valeur
max et min et la valeur désirée.
L’idée est de se rapprocher de la valeur désirée à la vitesse paramétrée.
3. Configuration
Pour des raisons de réglages et de test, de nombreuses valeurs de
configuration sont nécessaires. C’est pourquoi, un système de configuration
indépendant gère cette problématique.
Le choix du type de fichier s’est porté sur XML. Ce format de fichier reste
lisible et facile à modifier. La conception de type hiérarchique des données
relatives à l’ensemble du jeu, nous conforte dans ce choix.
Nous utilisons un parser de type DOM pour des raisons de facilité
d’intégration.
A chaque donnée particulière, comme par exemple les informations de
caméra, correspond une classe particulière.
Mais le traitement en lui-même (gestion des erreurs, parsing , …) est défini
dans la class Mère XMLDOMParser.
4. Effets spéciaux
De nombreux effets principalement relatifs à la perception du soleil sont
nécessaires (ombres, lumières colorées, rayons de lumière, lens flare,
simulation d’effet comme coucher/lever de soleil, éblouissements, …)
Certains effets comme la simulation d’eau lors de passages en bateau ou près
de temples immergés pourront être développés.
Leur degré de réalisme dépendra des interactions avec les milieux aquatiques.
DESS JVMI - 2004
13
Des effets pour les milieux aériens lors des vols en condor sont nécessaires,
comme des nuages, de la brume, du vent, impression de vitesse …
En voici une liste non exhaustive :
-
Effet de lens flare 2D.
Environment mapping
Bump Mapping
Lightmaps.
Vertex Color
Projection d’ombres en temps réel.
Skybox ou Warp.
Eblouissements
Billboards ou RotShapes
Lens flare :
Bien que cet effet ne soit pas « naturel », il est très répandu dans les jeux vidéo
et donne une très bonne impression d’illumination.
Il permet de repérer la position du soleil.
Son fonctionnement est plutôt simple, on lance un rayon qui va de la caméra
vers la source lumineuse choisie (le soleil ici), et le long de ce rayon on dispose
une série de textures en transparence additive, dont la taille d’origine est
modifiée en fonction de leur distance (plus petites vers le centre et plus grandes
vers l’extérieur).
DESS JVMI - 2004
14
Lens flare dans le jeu
Environment mapping, Bump mapping, Lightmaps et Vertex Color:
RenderWare Graphics permet d’utiliser de façon simple des effets de rendu sur
les surfaces.
L’environment mapping simule la brillance et les reflets dorés pour le Condor
par exemple, et le Bump Mapping sert à accentuer les effets de relief.
Ces deux effets doivent être spécifiés dans le « material » utilisé dans 3DSMax,
puis activé à l’aide du plug-in RpMatFX dans le code RenderWare, qui les gère
automatiquement.
Les textures de Lightmaps sont des projections d’ombres de façon précalculée
sur le décor. Ces textures sont générées dans 3DSMax et activées avec le plug-in
RpLtMap. Ce type de texture est à utiliser avec retenue, si l’on considère les
capacités limitées en mémoire vidéo de la PSP. C’est pourquoi dans certains cas
on lui préfèrera l’utilisation de Vertex Color, moins impressionnant
graphiquement mais beaucoup moins gourmand.
Ombres décor avec les Lightmaps
DESS JVMI - 2004
15
Le Vertex Color est une donnée définie sous 3DSMAX. Il s’agit d’une couleur
assignée aux points d’un modèle 3D. Cette couleur pourra soit être affichée telle
qu’elle, en addition de la couleur de la texture, soit en modulation avec les
valeurs d’éclairage de la scène.
Ce système permettra d’optimiser grandement la mémoire vidéo, car on pourra
réutiliser plusieurs fois les mêmes textures tout en variant leur rendu grâce à
différentes valeurs de Vertex Color. Ainsi, une texture de mur pourra être
aisément altérée en y ajoutant du vert pour d’obtenir un effet de mousse ou de
lichen.
Ombres en temps réel :
Cet effet permettra de calculer l’ombre des objets dynamiques (qui proviennent
de fichiers « dff ») et de les projeter sur les parties du décor statique (qui
provient d’un fichier « bsp »).
A chaque objet « dff », sera attaché une structure ShadowManager qui
recalculera et affichera à chaque frame la texture d’ombre de l’objet.
Son fonctionnement simplifié est le suivant :
- le ShadowManager va créer une texture en mémoire selon la résolution
demandée
- il va ensuite créer une caméra virtuelle avec une scène vide qui contient
une copie de la lumière directionnelle du monde original, et dans laquelle
sera rendu l’objet.
- Cette image sera une empreinte blanc sur noir de l’objet, que le
ShadowManager va ensuite inverser pour obtenir une image noire de
l’objet.
- Enfin, cette texture sera plaquée sur le décor, en n’affichant que la partie
noire de la texture.
Ce système de texture en mémoire (raster), permet d’effectuer des traitements
supplémentaires sur l’ombre, comme de l’anti-aliasing, du flou ou encore un
dégradé d’intensité.
Ombres temps-réel des personnages
DESS JVMI - 2004
16
Skybox :
Pour simuler la zone du ciel, nous allons créer autour du niveau une skybox (ou
warp). Selon les cas il s’agira d’un cube, d’une sphère ou d’une demi sphère sur
lequel est plaqué une texture de ciel et auquel on peut appliquer divers effets,
comme des couches de textures pour simuler les nuages, de l’animation ou du
déplacement de texture en modifiant leurs coordonnées UV.
Eblouissements :
De façon similaire à l’effet de lens flare, il est possible de créer des effets
d’éblouissements liés à des sources lumineuses.
On pourra afficher une texture en transparence dont la taille dépend de
l’alignement avec le vecteur de la caméra.
Plus la caméra sera centrée sur la lumière, plus la texture sera agrandie, jusqu’à
prendre tout l’espace si l’on se trouve exactement dans son alignement.
5. Intelligence Artificielle
Les comportements peuvent se partager en 3 catégories d’IA :
-
« IA amie »
Personnages de Tao et Zia. Relative autonomie mais réaction aux ordres
du joueur.
-
« IA ennemie »
Celle-ci concerne les Olmèques, les conquistadors, les animaux ainsi que
des personnages importants comme Gomez ou Gaspard (que l’on peut
considérer comme des ennemis-clef). Il est donc nécessaire d’implémenter
plusieurs niveaux d’intelligence.
-
Comportements scénarisés
Rencontres scénarisées avec certains personnages clés dont le
comportement sera prévu à l’avance (Mendoza, Pedro, Sancho, Incas,
villageois…). L’utilisation d’un langage de script est envisageable.
Ces
différents
aspects
d’intelligence
artificielle
l’implémentation des fonctionnalités suivantes :
• IA asynchrone
• Recherche de chemin
• Logique floue
• Système multi agent
peuvent
nécessiter
a. IA asynchrone – Time Slicing
Afin d’alléger le moteur de jeu des calculs d’IA qui peuvent s’avérer relativement
lourds (parcours de graphes, récursivité, …), il est préférable d’adopter un
système asynchrone. Cela signifie que les calculs destinés à l’IA ne seront pas
DESS JVMI - 2004
17
effectués à chaque frame, mais de façon légèrement décalée par rapport au
calcul de l’affichage.
Généralement, une boucle d’IA par seconde donne des résultats satisfaisants. On
pourra donc implémenter un système de chronométrage (timer) qui lancera le
calcul de l’IA à un intervalle régulier.
Concrètement, un moteur d’affichage standard tourne aux alentours de 60 fps
(frames per second), alors qu’une boucle d’IA toutes les 0.5 ou 1 seconde serra
suffisante.
Si les niveaux comportent un grand nombre d’ennemis, il serait bon de lancer
leurs fonctions d’IA respectives à tour de rôle.
La réaction de certains ennemis pourra influer sur le comportement des autres
(une alerte déclarée par un garde pourra interrompre un comportement de ronde
par exemple).
A l’intérieur de chaque boucle, il faudra pouvoir conserver les états et les
informations calculées afin qu’elles puissent être réutilisées pour le tour de
boucle suivante. Il faudra donc déclarer ces variables en tant que membre d’une
classe, ou éventuellement en global.
b. Recherche de chemin – Pathfinding
Système utilisé
Un système de pathfinding va s’avérer nécessaire pour les ennemis ainsi que
pour Tao et Zia.
Ce système permettra à ces PNJ de trouver leur chemin à travers un niveau pour
arriver à un point voulu (si Esteban appelle Tao, ou si un conquistador a repéré
les enfants et cherche à les capturer).
Ce système doit pouvoir tenir compte de la géographie des niveaux qui
utiliseront plusieurs niveaux d’altitude et qui ne seront pas atteignables par tout
les personnages (Zia ne peut pas grimper seule par exemple).
Pour calculer le chemin à emprunter, chaque niveau doit être découpé en un
graphe, qui décrira les zones atteignables.
Trois solutions sont possibles :
• Un découpage des zones en boites,
• Un découpage en zones triangulaires sur le sol (comme dans Jak
and Daxter sur PS2)
• L’utilisation de points de navigation (comme dans Unreal
Tournament sur PC).
L’utilisation de Navigation Points semble la solution la mieux adaptée à nos
besoins. Celle-ci tient en effet bien compte de l’altitude et est la plus efficace
pour gérer l’espace.
DESS JVMI - 2004
18
Un autre aspect très intéressant est la possibilité de taguer les liens entre les
navigation points, de même que les points eux-mêmes.
On peut ainsi stocker dans chaque lien des informations sur l’animation à utiliser
pour le personnage, mais aussi des informations sur le « coût » de déplacement
d’un point à l’autre (si le lien coupe une rivière ou une zone marécageuse par
exemple).
Ces informations pourront aussi être utilisées pour des aspects très spécifiques,
notamment concernant le personnage de Zia.
Celle-ci ne pourra franchir seule des zones, contrairement à d’autres
personnages, car elle ne sait pas grimper seule ni sauter.
Génération du graphe de chemins
En revanche, ce système pose des problèmes pour la génération du graphe de
nœuds.
Il existe des algorithmes de génération automatique, mais ils sont vite très
compliqués et coûteux (cela peut prendre plusieurs minutes voir plusieurs heures
si le niveau est grand) et ne fonctionnent pas toujours bien pour rejoindre les
points de différentes hauteurs.
Le temps de calcul n’est pas forcément un problème, puisque la génération du
graphe sera précalculée, mais cela peut être vite contraignant lors du level
design car si des modifications sont apportées au décor, il faudra alors générer
un nouveau graphe.
D’un autre côté, il est possible de placer les points de façon manuelle, ce qui
permet un bon contrôle des chemins et une grande souplesse si le décor évolue.
Mais cela peut être considéré comme une perte de temps pour les level
designers. C’est un travail qui est vite long et fastidieux.
La meilleure solution serait une solution intermédiaire, qui consisterait à générer
une première version du graphe de points pour chaque niveau de hauteur de jeu
(avec une certaine marge de hauteur pour les zones en pente), puis de relier et
modifier ces nœuds de façon manuelle pour améliorer les chemins obtenus.
Choix et parcours du chemin
On utilisera un algorithme classique de type A*.
c. Logique floue VS Finite State Machines
Afin de donner aux ennemis des réactions relativement crédibles, il serait
intéressant d’implémenter un système de logique floue pour les personnages
plutôt qu’un système à états finis classique.
Ce système permet une meilleure souplesse de réaction aux évènements et évite
des changements de direction ou d’état trop brusques.
DESS JVMI - 2004
19
La logique floue fait partie des nombreuses méthodes pour aller plus loin dans la
finesse des changements d’état d’un Jeu.
On peut se restreindre à une transition et un état correspondant, mais dans cette
configuration, tout est binaire. La logique floue propose de passer à quelque
chose de linéaire.
Il n’y a plus un Etat en sortie mais plusieurs en fonction de l’entrée, qui est
linéaire.
L’exemple suivant montre le comportement des gardes poursuivant le groupe
composé d’Esteban et de ses amis. Il s’agit de déterminer comment les gardes
vont œuvrer pour que le joueur ne soit pas trop rapidement attrapé.
Exemple de logique floue pour MCOG avec comme entrée la distance et le
rapprochement:
Se
rapproche
lentement
S’arrêter
Stable
S’éloigne
lentement
S’éloigne
rapidement
Trop près
Se
rapproche
rapidement
S’arrêter
Décélérer
Décélérer
Près
S’arrêter
Décélérer
Décélérer
Distance
parfaite
Eloigné
Décélérer
Décélérer
Décélérer
Très Eloigné
Garder
la
même vitesse
Garder
la
même vitesse
Accélérer
Garder
la
même vitesse
Accélérer
Garder
la
même vitesse
Accélérer
Garder
la
même vitesse
Accélérer
Accélérer
Accélérer
Accélérer
maximum
au
Accélérer
Accélérer
maximum
Accélérer
maximum
au
au
Toutefois ceci n’empêche pas d’implémenter un système à états finis pour les
autres éléments du jeu.
Certains objets n’auront que quelques états possibles, comme un ascenseur
(arrêt, monter, descendre), ou un interrupteur (actif, inactif).
Un système à états finis est même obligatoire dans ces cas.
d. Système multi agents
Pour gérer les PNJ alliés que sont Tao et Zia, on envisagera un système multi
agents qui permettra de gérer leur comportement de leur point de vue.
Ces agents pourront communiquer entre eux et avec Esteban en s’envoyant des
messages (renseigner sur un état, message d’alerte, action accomplie, etc.).
Ce système pourra être réutilisé pour gérer des groupes d’ennemis.
Ceux-ci pourront être hiérarchisé et pourront s’envoyer des messages d’alerte les
uns les autres, tout particulièrement pour les phases d’infiltration et d’évasion.
DESS JVMI - 2004
20
e. Gestion des formations
Lorsque l’on dirige les trois enfants à la fois, il faut pouvoir se déplacer de façon
précise en suivant une ou des formations prédéfinies.
Ces formations devront permettre de diriger le groupe lors de phases d’action, de
plateforme et d’infiltration qui nécessiteront des placements « intelligents » et
aisément manoeuvrables.
Pour indiquer à Tao et Zia leur position de référence par rapport à Esteban, nous
allons utiliser un système de grille de positions qui se déplacera et s’orientera en
même temps que lui.
E
Z
E
T
Z
Formation Esteban/Zia
Formation Esteban/Zia/Tao
E : Position d’Esteban Z : Position de Zia T : Position de Tao
Cette grille permettra un placement efficace et précis des personnages entre eux.
Toutefois, certaines adaptations seront nécessaires pour un résultat plus réaliste
et plus maniable.
Si l’on applique la grille telle quelle, les personnages auront tendance à se placer
systématiquement derrière Esteban, et bien que ce soit un avantage dans les
déplacements rapides, cela peut s’avérer génant dans les phases délicates ou un
simple demi tour d’Esteban modifie toutes les positions.
Il faudra donc intégrer une certaine souplesse à ces positions, ou créer des
formations pour des situations spécifiques.
Par exemple pour rapprocher les personnages le plus possible, ou les mettre en
file indienne lorsqu’ils se trouvent dans des couloirs étroits.
DESS JVMI - 2004
21
E
T
E
Z
Z
T
Formation file indienne
Formation « de front »
6. Moteur de son
La PSP est équipée de possibilités avancées en matière de traitement du son et
de spatialisation. Pour ces raisons, nous simulons dans la maquette :
-
-
la spatialisation du son
la musique interactive
le son d’ambiance
les effets sonores (effet de salle,…)
Il faut déterminer un standard de qualité sonore en tenant compte :
de la mémoire disponible
des fréquences audibles émises par des hauts parleurs
des APIs potentiellement disponibles pour la PSP.
Pour simuler un environnement similaire, nous utilisons donc dans la maquette
Direct Music.
Pour l’utilisation sonore, l’espace mémoire alloué est de 4Mb compressés (soit
8Mb).
Donc découpé avec :
4Mb décompressés de DLS
4Mb décompressés de streaming de source sonore.
Interactivité avec le son.
Nous gérons l’activité sonore de manière événementielle.
Lorsqu’un événement particulier est enclenché (comme le changement de
configuration des personnages) un événement est émis et est pris directement
en compte dans le moteur son (ex : passage d’un segment à l’autre avec
FADE,…)
Deux types d’événements ont été retenus :
- Les événements spatiaux qui interviennent lorsque le joueur passe dans
un endroit précis (voir Outil de Level Design). Généralement destinés à
des changements d’ambiance sonore ou au lancement de son particulier
(comme par exemple un son spatialisé,…).
DESS JVMI - 2004
22
-
Les événements de profil/état de jeu, le joueur change d’état où fait une
action particulière qui lance un événement sonore.
Exemples d’événements sonores de personnage :
-
Attendre
Actionner mécanisme
Prendre Objet
Se plaquer à un mur
Appeler amis
Pousser objet
Quart de tour
Jeter Objet
Utiliser Objet
Longer
-
Marcher
S’agripper
Grimper
Monter Echelle
Monter corde
Nager
Attendre dans l’eau
Tomber
Agripper rebord
…
Flot de Production
Le flot de production est découpé en deux parties. Chaque partie correspond au
protagoniste spécialisé :
Le programmeur son
L’ingénieur du son.
Le programmeur code les événements ainsi que le moteur de script et de son.
L’ingénieur du son script les événements logiciels qui sont envoyés par le jeu.
Pour pouvoir travailler convenablement, l’ingénieur du son dispose d’un langage
de très haut niveau, proche du basic.
Sous DirectMusic, l’ingénieur du son utilise le VBscript comme langage de script.
Il gère lui-même les volumes de chaque partie sonore, les fades, le lancement de
segments sonores, les chargements de DLS, jouer des événements midi.
Le moteur de script charge et appelle les scripts lors d’appels d’événements.
A chaque fonction correspond un événement.
Pour notre version de production un langage (LUA) de même nature que le
VBscript sera utilisé.
-
Le langage de script fournit les fonctions suivantes :
Fade
Play
Stop
Synchronisation par rapport au marqueur
Chargement/dechargement DLS
Play Midi
Stop Midi
DESS JVMI - 2004
23
7. Gestion événementielle
Dans le cadre de ce projet, l’utilisation d’un outil de Level Design paraît
nécessaire.
Dans chaque niveau du jeu, les actions du joueur doivent susciter l’apparition
d’événements apportant un surplus d’interactivité.
Ainsi, les événements sont déclenchés spatialement.
Lorsque le joueur se déplace, dans une zone particulière, il met en jeu des
actions invisibles (lancement de morceaux musicaux, téléportation du joueur
dans un autre endroit…).
On distingue trois grands types d’événements :
-
les événements liés aux héros et à leur environnement : téléportation,
lancement de cinématique, lancement d’animation…
-
les événements liés au son : organisent l’interactivité musicale par
rapport au lieu que le joueur visite.
-
les événements liés au changement de caméra : attirent l’attention du
joueur sur une zone intéressante
Deux type d’éléments collisionneurs :
-
la boite : Seulement deux points sont nécessaire pour définir une
boite
la sphère : Est défini par un rayon et un point.
8. Gestion des animations
Les animations sont gérées avec du blending.
A chaque changement d’animation, on interpole la dernière position de
l’animation précédente avec la première position de l’animation suivante.
La vitesse des animations et le temps du blending entre les animations sont
gérés à partir d’un fichier de configuration XML.
DESS JVMI - 2004
24
9. Gestion des éléments d’interface
Nous avons adopté deux solutions complémentaires :
o
o
Le moteur d’animation 2D de Renderware, Maestro, qui permet,
après l’édition d’un fichier programmé sous Flash, de récupérer des animations.
Nous utilisons cette fonctionnalité pour gérer les menus.
Le placage de texture directement sur l’écran du jeu. Ce système
permet de gérer des animations dynamiques de manière plus aisée que sous
maestro. Nous adoptons cette solution pour gérer les InGame.
Interfaçage entre Maestro et Flash
L’interfaçage entre Maestro et Flash s’effectue en simulant une manette que l’on
fait disparaître à l’export. Cette manette permet au graphiste connaissant Flash
de simuler l’action d’une manette.
Dans le code, nous lions les boutons déclarés dans Flash avec la véritable
manette de jeu.
10. Gestion de la physique
Nous n’utiliserons pas de moteur physique préexistant pour le jeu final.
Dans Children of the Sun, le moteur physique du jeu n’a pas pour rôle de recréer
fidèlement des conditions physiques réalistes.
Comme il s’agit de l’adaptation d’un dessin animé, les personnages devront faire
des actions parfois irréalistes.
Il va plutôt s’agir de simuler et de donner l’illusion de la physique au jeu par
quelques fonctions adaptées aux diverses situations.
DESS JVMI - 2004
25
Gestion des collisions :
-
des personnages envers le décor,
des personnages envers les autres personnages,
des personnages envers les assets (objets du décor amovibles),
Il faut ajouter à ceci les collisions des assets envers le décor statique et aussi
certaines collisions particulières dans des zones de déclenchement (triggers
scénaristiques, couches sonores, puzzles, …).
Acteurs/décor : le moteur utilise des sphères englobantes qu’il projette à
chaque déplacement en appelant la fonction de RenderWare Graphics :
RpCollisionWorldForAllIntersections.
Elle fonctionne pour les collisions envers les décors statiques dont les données
proviennent d’un fichier .bsp.
Acteur/acteur : encore une fois nous utiliserons des sphères englobantes.
En revanche il ne s’agira que de tests de collisions entre deux sphères, dont le
calcul est très simple et sera effectué sans appel de fonction spécifique de
RenderWare.
Exemple de fonction de test de collision entre deux sphères :
bool MCoG3DActor::FindAtomicContact(RwV3d& movement, const RwSphere *boundingSphere)
{
Const RwSphere *CollisionSphere = RpAtomicGetWorldBoundingSphere(CollisionAtomic);
RwV3d vectorToCenters =
{
boundingSphere->center.x - CollisionSphere->center.x,
boundingSphere->center.y - CollisionSphere->center.y,
boundingSphere->center.z - CollisionSphere->center.z
};
RwReal distance = RwV3dLength(&vectorToCenters);
if(distance < (CollisionSphere->radius + boundingSphere->radius)*0.5)
{
RwV3dNormalize(&vectorToCenters, &vectorToCenters);
RwV3dSub(&movement, &movement, &vectorToCenters);
return true;
}
return false;
}
Pour d’autres tests, nous utiliserons en revanche des lancer de rayon, moins
coûteux que les sphères.
Ceci englobe les tests de position par rapport au décor, pour savoir si un
personnage pourra s’agrippe,r par exemple.
Dans un cas concret, si le moteur détecte une collision entre la sphère
englobante et le décor, il lancera un rayon au niveau des épaules et un autre au
niveau de la tête du personnage.
Si aucun ne collisionne, cela veut dire que la collision initiale a eu lieu au niveau
des jambes et que l’obstacle peut être enjambé. Si la collision a lieu au niveau
DESS JVMI - 2004
26
des épaules seulement, il pourra se hisser. Si les collisions ont lieu à tous les
niveaux, il ne pourra simplement pas passer.
Pas de collision
Collisions
Dans le cas ci-dessus, le personnage pourra s’agripper à la paroi et se
hisser.
Tous ces tests sont relativement coûteux et pourront être optimisés de plusieurs
façons.
Le décor pourra par exemple contenir des « tags » (marqueurs invisibles sur des
zones du décors) pour savoir si une zone peut être agrippée.
Avant d’effectuer les lancer de rayon supplémentaires, il suffira de vérifier dans
quel type de zone on se trouve.
Ceci pourrait aussi empêcher le joueur de s’accrocher accidentellement à des
endroits non prévus, et donc susceptibles de causer des bugs.
Gestion de la physique :
Ce sera principalement des fonctions qui utiliseront les informations de collision
pour empêcher un acteur de passer à travers un mur, le sol ou encore un autre
acteur, mais aussi de dévier la trajectoire initiale (et non pas bloquer seulement
le déplacement).
La physique devra aussi gérer la gravité.
Lors des phases de plateforme, ceci sera principalement utilisé pour gérer les
sauts et les chutes (hauteur, durée, accélération, etc.). Pour les phases en
Condor, la gravité permettra de voler, planer et accélérer.
DESS JVMI - 2004
27
La portance qui fait voler le condor
La portance est la résultante des forces de pression qui agissent sur un corps
placé dans un courant fluide.
Soient :
Fa = Ca.ρ.A.v²/2
Fa = portance en Newton
Ca = coefficient de Lift typiquement compris entre 0,02 et 0,05
ρ = masse volumique du fluide en kg/m3
v = vitesse relative d’écoulement en m/s
A = aire projeté de l’aile en m²
Pour cet exemple la force résultante est Fr = Fe-Fw +Fa – Fp
Fe est la force exercée pour faire voler le condor
Fw est la force de frottement de l’aile en Newton
Fp = m.g
Fa est donnée plus haut
11.
Gestion des entrées utilisateur et gameplay
Les entrées utilisateur s’effectueront à plusieurs niveaux :
- Entrées utilisateurs au joypad qui seront enregistrées à l’aide d’une interface appelée
InputManager, utilisant des routines de DirectInput.
- Récupération et exploitation des données du capteur solaire. Stockage dans une variable puis
interprétation de la valeur stockée.
- Possibilité de sauvegarder puis reprendre une partie. Nécessité de déterminer à quel point les
données du jeu devront être sauvegardées (simple progression, progression et état des
personnages, etc.)
DESS JVMI - 2004
28
Le gameplay du jeu va englober tout ce qui a trait à l’interprétation des actions
du joueur.
La physique et le gameplay d’un jeu sont deux aspects extrêmement liés.
Si la physique gère la façon dont vont interagir les objets et acteurs du jeu
(collisions, gravité…), le gameplay va gérer la façon dont le moteur va traiter les
entrées utilisateur de façon à ce que le joueur prenne du plaisir à jouer.
Il sera nécessaire de bien régler le gameplay.
Pour faciliter ce réglage nous utiliserons des fichiers xml dans lesquels nous
lirons la valeur des principales variables du jeu (vitesse de déplacement, points
de vie, positions, etc.). Ceci permettra aux game et level designers de régler
eux-mêmes ces paramètres de manière simple sans qu’ils aient à toucher au
programme et sans que les programmeurs aient à recompiler des parties du jeu
entières à chaque fois.
DESS JVMI - 2004
29
ANNEXE 1
PHYSIQUE DU CAPTEUR SOLAIRE
DESS JVMI - 2004
30
Définition de la température de couleur
La notion de température de couleur repose sur la théorie de l'émission du corps noir.
Le corps noir est une matière fictive capable d'absorber totalement toutes les radiations
électromagnétiques lorsque sa température est le zéro absolu, soit :
-273.15°C=0K (Kelvin).
Aucune lumière n'est réfléchie et sa couleur est donc le noir parfait, d'où son
nom. Mais c'est aussi une matière capable d'émettre un rayonnement
électromagnétique si sa température n'est plus 0K
La distribution d'énergie émise, ou spectre, est alors directement liée à
sa température.
Le corps noir parfait n'existe pas, mais dans certaines conditions de hautes
températures et hautes pressions (> 1Bar!), beaucoup de matière ont un spectre
d'émission superposable à celui de la théorie.
Historiquement, c'est l'observation de l'émission de corps incandescents qui a
permis de construire une théorie basée sur la thermodynamique statistique.
L'acier est en effet un bon corps noir. De l'augmentation de sa température
va résulter un rayonnement de plus en plus intense du rouge profond au
blanc aveuglant.
Une des formules importantes est l'équation de Planck :
ou
qui est la distribution d'énergie en fonction de la longueur d'onde du
rayonnement électromagnétique émis par un corps noir de température
T.
DESS JVMI - 2004
31
Traçons cette fonction pour différentes
températures:
Les
spectres
sont
ici
normalisés.
Cependant l'énergie totale émise par le
corps noir est proportionnelle à la
puissance 4 de la température.
Le flux à 10000K est donc 10000 fois
plus intense qu'à 1000K.
Mais ce qu’il est important d'étudier ici
est la distribution de cette énergie en
fonction de la longueur d'onde. La théorie
montre que le produit de la longueur
d'onde d'émission maximale par la
température est une constante.
Ainsi plus la température augmente,
plus la longueur d'onde diminue,
allant pour la partie visible, du rouge au
bleu. (Rappelons que les courbes sont ici
normalisées, mais l'énergie de chaque
longueur d'onde à 5600K est beaucoup
plus grande qu'à 3400K.)
Il ne faut pas assimiler la température de
couleur à une intensité globale du flux.
Dans le cas d'une même source de masse
constante, en effet nous avions vu que
l'intensité
augmentait
avec
la
température de couleur.
Mais dans le cas de deux sources
différentes, une température de couleur
plus grande ne signifie pas une intensité
de flux plus grande.
Pour exemple: un halogène de 1000W,
avec une température de couleur de 3200K, a un flux plus intense qu'un
petit flash dont la température de couleur est de 5000K. De même la
DESS JVMI - 2004
32
température de couleur du ciel peut varier de 2000 à 20000K sans pour
autant être plus intense.
En fait le ciel (l'atmosphère) joue le rôle d'un filtre de conversion. Le spectre
solaire a une température de couleur de l'ordre de 10000K. Mais l'atmosphère
absorbe les UV et diffuse les bleus. Sur terre les jaunes et rouges du spectre
deviennent alors prédominants et le spectre peut être comparé à celui d'un corps
noir à 5600K. En revanche, le ciel est une source de lumière secondaire où les
bleus sont majoritaires.
Bien que le flux ne soit pas très intense par rapport au soleil, la température de
couleur du ciel bleu est alors au dessus de 5600K.
Théorie de mesure de température de couleur
Ceci est un travail de laboratoire.
Pour cela, il faut partir de la formule de Planck et regarder les valeurs non
statiques comme la longueur d’onde (m) et l’intensité lumineuse émise (W/m3).
Le premier travail est l’utilisation de filtres photo sur un intervalle étroit de
longueur d’onde donnée.
Le second travail est de convertir l’intensité en Ampère en intensité lumineuse.
Ceci se fait par une mesure très précise de l’intensité lumineuse par rapport au
courant. On obtient une table de correspondance qui détermine très précisément
les caractéristiques de la photodiode.
Lorsqu’on a récupéré une longueur d’onde plus une intensité lumineuse, on peut
résoudre la formule de Planck :
B = Intensité lumineuse
λ = Longueur d’onde
On obtient, pour une longueur d’onde et une intensité donnée, une température
monochromatique qui n’est pas la température de couleur recherchée.
Pour mesurer cette température de couleur, il faut une fonction de
transformation que l’on ne peut mesurer qu’en comparant ces deux températures
en laboratoire équipé de matériel adéquat.
La première approximation qui parait suffisante est une fonction simple du
premier degré:
On obtient ainsi une température de couleur approximative.
Pour obtenir une très grande précision, deux méthodes sont utilisables et
complémentaires :
la complexification de la formule d’approximation
la multiplication des capteurs photosensibles dans des longueurs d’ondes
différentes
DESS JVMI - 2004
33