Ça a passé très vite en plus des autres projets de fin de session tous en même temps...
Je n'ai pas pu travailler autant sur les effets sonores que j'aurais voulu, mais j'ai pu explorer ce volet de UDK que je ne conaissais pas.
C'était aussi un bon défi étant donné l'équipe de 13 personnes et que je devais beaucoup collaborer avec tous les animateurs et level artistes.
Donc voici mon implication dans le projet:
Design des niveaux: plans 2D, plans 2D vectoriels à l'échelle, Greybox
Mise en place du Kismet et de la procédure à utiliser pour l'intégration des animations
Marquer le chemin principal avec des lumières placeholder
Streaming des niveaux
Recherche d'effets sonores, mixage
Intégration d'effets sonores dans UDK (Kismet et Unreal Script): FootSteps, Landing, Matinee
Programmation de la caméra, modification des propriétés du Pawn, switch de personnage.
Merci à tout le monde de l'équipe!! Et bon été!!! :)
Finalement pour la semaine 2, ajout de points lights dans le chemin principal pour aider les artistes de niveaux à ajuster leur éclairage, qui à son tour aidera à clarifier le chemin à suivre au joueur.
J'ai mis en place le système de nodes Kismet que les animateurs devront utiliser pour déclencher leurs animations.
Quand le trigger est touché par le joueur, le mode cinématique est lancé (bloque les contrôles et cache le joueur) et l'acteur cinématique est montré. Le Matinee s'occupe des animations et de la caméra. Le joueur est ensuite téléporté vers le PathNode (j'aime bien les pommes) qui doit être placé à la fin de l'animation Matinee et orientée vers où le joueur va ensuite. Finalement l'acteur cinématique est à nouveau caché et le joueur peut continuer sa course.
Il a aussi fallu modifier un paramètre dans la classe du Pawn pour enlever l'effet spécial de flash de lumière rouge qui se produit lorsque le joueur est téléporté.
C'est une classe de type Seq_Act (sequence action) qui est directement utilisable dans Kismet. Dans cette classe, chaque aspect du personnage à être changé est déclaré comme variable et des méthodes correspondantes s'occupent d'interchanger ces assets. (anim tree, anim set, skeletal mesh, physical asset)
Je n'ai qu'à utiliser ce nouveau node Kismet avec un trigger pour changer le personnage au moment prévu et j'ai aussi ajouté la fonction de changer de personnage n'importe quand en pesant "Z" pour faciliter les tests.
Voici donc les premiers sketch fait avec les artistes de niveau
correspondant ainsi que l'animateur qui est en charge de cette partie du
jeu.
Désolé pour le niveau intense de gribouillage, la version
au propre sera fait plus tard. Par contre, avec cette méthode, on
pouvait rapidement définir le parcours, les différentes zones, les
événements possibles et leurs emplacements.
Donc, en ordre:
Partie à Louis-Philippe: Quartiers Riches, Jardins
Et go! C'est repartit pour la contrainte 2: Une Poursuite.
3 semaines pour: 6 tableaux, 150 mètres par tableau, le personnage parcours environ 5m/s donc environ 30 seconde par tableau.
Ça sera une genre de course à relais car à chaque 1 1/2 niveau, le personnage se fait tuer et on joue ensuite avec le personnage suivant en continuant où on était rendu.
Tout au long du jeu, les autres personnages sèmeront des embûches au personnage principal pour le faire changer de trajectoire.
Et voilà, le projet est maintenant officiellement terminé!
Pour conclure ce blog, voici donc ma contribution au projet Lacerta dans sa
totalité:
Game Design:
- Contribution à
l'élaboration des mécaniques de bases et contrôles du jeu - Responsable de ces
sections dans le GDD
Level Design:
- Graybox des niveau
- Intégration et paramétrage
des objets physiques déplaçables, destructibles
- Design d'événements:
endroits secrets, destruction passerelle, puzzles, chase finale - Streaming des niveaux - "Fake" AI - Test, débogage, blocking
additionnel
- Corrections et
ajustements suite au rapport des testeurs
Programmation:
- Intégration des Kit UDK:
SimplePlatformGame et MouseInterface - Ajustement du saut
(hauteur, distance), vitesse de course - S'accrocher au parois - Plates-formes à collision
dynamique - Caméra dynamique - Système de checkpoints
et teleport
FX:
- FX de
matière blanche
Et pour terminer, un dernier vidéo du prototype dans son ensemble!
Et voici un video du jeu et on peut maintenant jouer du début à la fin! Quelques endroits sont encore à retravailler pour le level Design et aussi plusieurs objets sont à remplacer par les modèles finaux.
Mais sinon, on a presque 10 minutes de jeu, sans compter le 2e chemin
que je n'ai pas emprunté dans la salle après avoir obtenu les pouvoirs
niveau 2. Et aussi, il devrait y avoir beaucoup plus d'ennemis, donc
nous sommes en plein dans le mille pour la contrainte de temps!
Pour les 2 dernières semaines donc: ajouter des ennemis, mieux paramétrer les "événements" (pont qui brise, etc) , ajouter un peu de mordant à l'avant dernière partie qui est un peu plate (juste courrir....) et régler les bugs et préparer la présentation.
Pour créer une boîte déplaçable dans l'engin physique d'UDK il suffit qu'il soit un objet physique et de lui appliquer un Physical Material, mais d'autres paramètres nous intéressent pour ce cas-ci.
Certains paramètres de l'instance de l'acteur influencent aussi le comportement.
Dans les propriétés de l'acteur physique:
Pawn Can Base On: Si oui ou non le Pawn, sur cet objet, devient la "base" (enfant) de celui-ci, donc hérite de ces translations. Can Step Up On: Le Pawn sur cet objet sera en mode PhysWalking. Sinon, il reste en PhysFalling. Safe Base If Asleep: Si le Pawn est sur l'objet et que l'objet devient sa "base", l'objet reste immobile peu importe la gravité et les autres forces physiques l'affectant.
Donc pour la grosse boîte, je veux pouvoir sauter dessus et qu'elle me fasse bouger une fois sur elle donc je n'active pas Safe Base If Asleep.
Phys Material Override: Ici je met le lien vers un Physical Material que j'ai créé directement en right-cliquant dans le Content Browser
Les paramètres importants ici sont:
Friction: Plus cette valeur est haute et moins l'objet glisse sur les autres surfaces. Density: Encore une fois, la densité multiplie la grosseur de la collision de l'acteur pour donner le poids total de l'objet.
N'oubliez pas de cocher "Wake On Start" dans les propriétés de l'objet instancié si vous voulez que la physique s'applique dès le début, sinon vous faites un "Toggle On" dans Kismet dans le cas d'un jeu en streaming une fois la map correspondante loadé.
Le Hinge Actor permet de contraindre les acteurs physiques dans UDK. Le
Hinge Actor (charnière) contraint l'acteur aux rotations dans un seul
axe.
Dans mon exemple, chaque acteur physique (cube) est attaché à 2 hinge actors sauf ceux du haut (plafond) et du bas (plancher). De cette façon, les blocs sont attachés à la fois par le haut et par le bas pour mieux simuler l'effet d'un mur destructible.
le Constraint Actor 1 est soit: le parent de l'acteur attaché OU l'acteur attaché s'il n'a pas de parent.
le Constraint Actor 2 est l'acteur attaché s'il a un parent.
Angular Breakable permet de spécifier si cette contrainte peut être détruite Angular Break Threshold est (je crois) une certaine force requise pour que le Hinge Actor se brise.
Pour le Angular Break Threshold des blocs du plancher et du plafond, je les met un peu plus solides que les autres pour rendre le mur plus dur à briser, et tout dépendemment du type de solidité que je veux obtenir pour le mur, il suffit de tester souvent en changeant cette valeur pour trouver la bonne combinaison!
Finalement, les blocs sont appliqués d'un Physical Material créé directement dans le browser et appliqué à l'instance de l'acteur physique dans l'éditeur UDK ou directement sur un StaticMesh dans votre package.
Density: La pesanteur de votre objet (qui est d'abord déterminé par la grosseur elle-même de la collision de l'acteur et multiplié ensuite par la Density) Angular Damping: Une valeur qui cause un genre de friction de la rotation et la rend plus résistante.
J'ai monté beaucoup ces deux valeurs pour rendre l'objet assez lourd et pas trop "élastique" dans son mouvement pour bien avoir une impression réaliste du poids. Encore une fois, beaucoup d'essai et erreur en testant pour arriver à un bon résultat!
Peut-être que je peux même créer une autre contrainte de parenté horizontale à tous ces morceaux ça serait cool! Faudra que j'essaye ça plus tard...
Bonjour! plusieurs post à faire aujourd'hui car j'ai beaucoup travaillé mais je n'ai rien posté sur le blog depuis un petit bout. Donc je commence par le streaming des différents niveaux.
J'ai remarqué quelque en travaillant sur le streaming: c'est géré différemment si l'on joue en mode éditeur que si l'on joue en mode "play on PC".
En jouant dans l'éditeur, le streaming fonctionne mais lorsqu'il y a du loading, cela ne se fait pas vraiment en streaming, tout gèle pendant que le jeu load la map suivante. Tandis que si l'on joue en mode "play on PC", le streaming ce fait comme il se doit, en background pendant que le joueur joue, sans interruption.
Cela a occasionné quelques problèmes donc: en mode "Play on PC" je tombais carrément dans le vide avant que la map du début ne soit loadé... donc vu que la première map à loader est le Persistent lui-même, j'ai ajouté une "cage" qui bloque le joueur de tout mouvement et l'empeche de tomber. La cage est ensuite détruite quand la map 1 est belle et bien loadé et visible! Ce Kismet se trouve directement dans la map Persistent aussi pour être certain que l'instruction est exécutée dès le début.
Il y a surement un moyen plus élégant, ca prendrait une interface! plus tard...
2e problème qu'occasionnait le streaming est que les éléments physiques (rigid bodies, KActors) tombaient carrément dans le vide dans les sections plus loin du jeu étant donné que la map (et la plancher sous les objets) n'était pas encore loadé. Je dois donc les désactiver dans l'éditeur et les activer seulement une fois que la map correspondante est loadée! Et je les désactive une fois la map déloadée, question d'optimisation et aussi si jamais le joueur reviens sur ses pas, les objets seront encore là, sinon il pourrait rester bloquer s'ils disparaissent.
On voit dans l'image plus haut que j'appelle la séquence "Wake_Alex02". Elle fait que tout les éléments physiques sont "toggled on" dès que le niveau est loadé.
Voici la caméra dynamqiue durant la première partie du jeu. Le zoom et la limite en Y et en Z sont paramétrables dans Kismet et chaque pièce contient des triggers qui permettent de changer ces valeurs. La caméra fait le mouvement automatiquement en fonction de ces valeurs.
Desfois, on dirait que ça "coche" un peu dans les transitions entre les salles... on dirait que ça arrête un tout petit peu quand la caméra se trouve directement devant le joueur.
PS: Il fait très noir à certains endroits mais j'ai tellement joué que je sais quand même ou sauter!!
Désolé quand je saute 5 fois de suite à la même place: bugs par rapport au ledge grab et certaines collisions....
Voici le blocking de la partie Industrielle, après le tutoriel du début. Il manque quelques ennemis encore quand le courant revient + une tourelle de défense, et d'autres ennemis venant de la sortie après la manipulation du bras robotique.
Voici maintenant quelques scripts qui vont gérer la caméra. Pour commencer, voici la séquence qui contient les variables de base et qui me permet d'initialiser soit la caméra simple ou la caméra plus complexe.
Les variables ici de Xoffset et Zoffset permettent de changer le zoom et la hauteur de la caméra par rapport au personnage. Les variables de la "Room 1 Bounds" permettent de bloquer la caméra à un certain point pour qu'on ne voit pas ce qu'il y a à l'extérieur de la salle. Il me manquera une autre séquence qui servira à changer ces variables et à créer une animation qui passera d'une salle à l'autre.
Voici la caméra simple qui suit le joueur en tout temps dont je me sert pour tester le jeu jusqu'à ce que la transition entre les salles et toutes les "bounds" de chaque salles soient définies correctement.
Ici, le script de la caméra complexe qui bloquera par rapport au variables des "bounds"
Finalement, j'ai aussi commencé une autre séquence qui permettera, si on se trouve à l'intérieur d'un trigger, de Zoomer In ou Out pour permettre de mieux voir l'ensemble de la salle ou de zoomer sur le personnage pour un moment narratif, etc...
J'utilise tout d'abord le "StarterPlatformGame" pour la base du side-scroller (caméra et mouvements latéraux seulement)
Je commence d'abord par me créer dans Kismet une séquence qui me permet de déterminer si le joueur est en train de tomber qui va m'être utile pour mes prochaines mécaniques.
Pour que le joueur puisse aggriper la bordure, je place un petit trigger volume tout près de cette bordure.
Donc maintenant, quand le joueur ne touche plus ce trigger et qu'il est en train de tomber, il passera en mode physique "ladder". J'ai choisit ce mode pour l'instant car il réagit déjà à ce que je recherche. Le seul problème, c'est que si je une fois en mode ladder, il ne saute pas dans les airs et se laisse seulement tomber. Je dois juste changer une petite ligne de code pour régler ce problème:
Ensuite pour le plancher "flottant", je met un trigger tout autour de ce bout de plateforme et chaque fois que le joueur entre en contact avec ce trigger, je détermine si la collision du bloc est activée ou désactivée. Encore une fois, je veux savoir si le joueur tombe et s'il est présentement plus haut que la plateforme elle-même.
Et finalement pour voir la souris à l'écran, j'utilise le code présenté sur cette page:
http://udn.epicgames.com/Three/DevelopmentKitGemsCreatingAMouseInterface.html#Getting%20a%20cursor%20on%20the%20screen
J'utilise la méthode "Scaleform" car j'ai déjà utilisé Flash pour faire une interface et cela sera utile plus tard pour créer le HUD et les menus. Pour l'instant, il ne me faut qu'un curseur dans mon fichier flash. Je dois aussi ajouter les lignes du "SPG_PLayerController" dans celui du "MouseInterfacePlayerController" et modifier le "SPG_GameInfo" pour spécifier d'utiliser le nouveau "MouseInterfacePlayerController" et "MouseInterface_HUD".
Dernière chose: modifier le niveau de contrôle dans les airs, qui est beaucoup trop faible, voici deux lignes à ajouter dans le "SPG_PlayerPawn", à la fin du fichier:
la variable AirControl donne plus de contrôle dans les airs plus elle est grande. 0.2 semble donner un bon résultat.
Et voilà! c'est un début, ça ne fonctionne pas tout comme je veux, mais c'est un bon départ! Déjà avec ça, je devrais avoir la bonne distance pour créer les plateformes de mon graybox et les parcourir.
Voici le début du schéma du niveau 1 créé en vectoriel dans Illustrator.
Maintenant
que les mécaniques du jeu sont moins floues, je peux commencer à
travailler sur le Level Design. Je veux tout d'abord introduire les
mécaniques de bases graduellement au joueur.
Il
commencera par apprendre à se déplacer, sauter et ensuite à utiliser les
trous noirs et blancs pour interagir avec l'environnement et lui
permettre de continuer.
Ensuite, il sera confronté à 2
ennemis dans deux situations différentes et pourra apprendre les
différents moyens de combattre. Il sera aussi informé de l'existence de
la matière blanche instable qui est mortelle qui se retrouve dans le
niveau et se créé aussi lorsqu'un ennemi est vaincu.
Ensuite,
un combat plus difficile avec 3 ennemis à la fois survient subitement,
mais le joueur dispose de plusieurs solutions pour les vaincre sans
problème et lui permet de s'amuser un peu avec tout ce qu'il vient
d'apprendre.
S'il explore un peu, il pourra aussi libérer des personnages alliés et obtenir des points bonus.
Pour résumer
les mécaniques, le jeu est un side-scroller et le personnage a le
pouvoir de créer des trous noirs ou blancs en cliquant n'importe où dans
l'écran. Les trous noirs attireront les objets et les trous blancs les
repousseront. Seulement certains objets prédéfinis seront affectés.
Le
personnage peut aussi combattre les ennemis en utilisant ces mêmes
pouvoirs pour les attirer ou les repousser. Un ennemis proche du joueur
pourra être attaqué au corps à corps tandis qu'un ennemi plus loin
pourra être propulsé ou attiré vers un trou par exemple.
Détails à venir accompagnés des contrôles pour expliquer chaque action possible du personnage.
