lundi 22 octobre 2012

Créer des archetypes et autres petits trucs

Comme je disais dans le post précédent, une de mes taches du début de session était de permettre au gameplay de base de fonctionner et de pouvoir intégrer et twiqué facilement nos éléments de base. Une des façons que j'ai utiliser à été celle des archetype.

Archetypes


   - C'est quoi un archetype ?
Dans UDK un archetype c'est un objet gardé dans un package dans le content browser ou peuvent être modifiées des variables qui se trouvent dans une class (dans le code) et qui sont rendues accecibles.



   - Comment en créer ?
Pour créer un nouvel archetype il y a deux étapes : rendre les variables accecibles dans la class voulue (dans le code) et créer l'objet Archetype de cette class. Pour créer un Archetype d'une class existante allez dans le content browser, dans l'onglet Actor Class. Il est important de décocher 'Placeable Class Only' et 'Show Categories' pour pouvoir voir toute les class (même celles qui ne peuvent pas être placées directement dans l’éditeur). Chaque item dans la liste représente une class définit dans le code, trouvez la votre. 

Right click sur la class choisi, l'option 'Create Archetype' apparait, choisissez le package et le nom de votre archetype, and that's all. 

Ainsi je peux changer le mesh qui représente le pawn, lui assigner un anim tree, ajouter des anim set, changer sa vitesse de marche, sa hauteur de saut, etc sans avoir a recompiler à chaque test.


La deuxième partie (qui vient en fait avant) ce passe dans le code : une class utilise des variables et ce sont ces variables que l'ont veut modifier. Pour qu'une variable puisse être modifié dans un archetype il faut la déclarer comme cela : 
var ( ) float walkspeed; 
var ( ) name SkelControlLookAtName; 
Les parenthèse après le var indique que cette valeur est modifiable. Ainsi : 
var float runspeed; 
Cette variable ne serait pas modifiable. 
var (Camera) float FOV; 
Cette variable est modifiable et est rangé dans l'onglet Caméra de l'archetype. 


   - Comment le code sait quel archetype utiliser ? 
On précise quel archetype utiliser dans les default properties de la class qui a besoin de l'archetype en question. Par exemple le pawn est utiliser par le PlayerController donc dans mon PlayerController je créer une variable constante comme ceci : 
var const ContinuumPawn PawnProperties;

Puis dans les Default Properties : 
PawnProperties=ContinuumPawn'C_Archetypes.Pawn_default'

Quand j'ai besoin d'une valeur de cet archetype dans le code :

exec function Walk ( )
{
Pawn.GroundSpeed = PawnProperties.WalkSpeed;
}


Va chercher la valeur WalkSpeed dans l'archetype PawnProperties qui a été assignée dans les defaultproperties à ContinuumPawn'C_Archetypes.Pawn_default'.

De cet façon il peut être pratique de regrouper les valeurs que l'ont veut pouvoir modifier dans une class spéciale qui ne contient qu'elle. Ainsi l'archetype dans l'éditeur sera plus 'clean'. C'est ce que j'ai fait pour la Camera et les Decal :


Le code de la class de l'archetype :


class ContinuumCameraProperties extends Object
HideCategories(Object);

var(Camera) float CamOffsetDistance; //distance to offset the camera from the player in unreal units
var(Camera) float CamMinDistance;
var(Camera) float CamMaxDistance; 
var(Camera) float CamZoomTick; //how far to zoom in/out per command
var(Camera) float CamHeight; //how high cam is relative to pawn pelvis
var(Camera) float FOV;

// Camera offset to apply
var(Camera) Vector CameraOffset;
// Camera rotational offset to apply
var(Camera) const Rotator CameraRotationOffset;
// Pawn socket to attach the camera to
var(Camera) const Name PawnSocketName;
// If true, then always use the target rotation
var(Camera) const bool UseTargetRotation;

Utilisé dans la class camera :

class ContinuumCamera extends Camera;
var const ContinuumCameraProperties CameraProperties;
[...]
SetFOV (CameraProperties.FOV);
[...]
defaultproperties
{
CameraProperties=ContinuumCameraProperties'C_Archetypes.Camera'
}

Kismet et volume

J'ai également créer de nouveau node Kismet pour permettre de faire plus facilement certain changement dont nous avions besoin. Notre but est de plonger le joueur dans l'univers du jeu en ajoutant le plus possible de détails et subtilité dans les comportement d'Alex (notre perso principal) par rapport à son environnement. Nous souhaitons aussi que la façon de jouer soit la plus 'smooth' possible, pour que le joueur puisse jouer sans aucune frustration et qu'il puisse découvrir l'univers sans décroché. Voici quelques exemples de ce que nous avons intégrer dans le jeu : 

   - Nous voulions que le personnage change d'anim tree lorsqu'il porte quelques chose de lourd ou qu'il peine à avancer dans la neige. Nous utilisons pour cela un node BlendByProperty qui permet de blender entre deux child selon une boolean dans le code. Il a donc fallut créer un node Kismet (ultra simple) pour cela. 

   - Nous voulions pouvoir controller la distance de la camera au joueur et l'ampleur à l'intérieur de laquelle il peut zoomer in/out. Encore une fois un node Kismet était util. 

   - Nous avions besoin d'un node PawnAnim qui nous permettent de régler le blendTime in/out, le play rate et qui est capable de savoir quand l'anim est terminé. 

  - J'ai également créer un node kismet pour activer les SkelControl Limb qui permettent d'ajuster la position des mains du perso. Ce node permet aussi de choisir un actor target sur qui placer les mains d'Alex. 

  - J'ai créer un volume qui, quand le joueur y pénètre, permet au pawn de regarder vers un ou plusieurs objets de la scène. Cela lui donne une attitude plus naturel. 

   - Enfin j'ai adapter le node AIMoveToActor au Player Controller pour être capable de demander à ce dernier de se placer de façon naturel a un endroit précis avant de faire une animation. 

Dans le prochain post j'essayerais de vous faire une petite demo en vidéo de chaque fonctionnalité ;)

Décisions et stratégie pour arriver à la fin de la session

Après la revue de notre premier build la semaine passée nous avons pris certaines décisions pour éviter de finir focilisé devant nos écrans en fin de session. J'ai réduit en espace la partie du puzzle extérieur car nous avons un environnement très (trop?) ambitieux compte tenu que Viro est presque le seul à y travailler. Agustin va faire les environnements extérieur lorsque le perso sera terminé, j'espère pouvoir l'aider aussi mais nous sommes très serrés de ce coté. Viro a lui aussi coupé une partie de ses salles les moins importantes. 

Pour les anims, certaines ne sont plus en cinématique mais en gameplay. Ça ne change pas grand chose mais ça passe mieux si on a pas le temps de les polish au max. Et ça a l'avantage de réduir un peu les cutscenes et donc a augmenter l'interactivité du joueur. Ça rajoute un peu de Kismet par exemple mais ça ne devrait pas me prendre trop de temps. 

Avec un build fonctionnel, notre objectif maintenant est de rendre le jeu le plus compréhensible par une personne extérieur a la production possible, jusqu’à ce que l'histoire soit complètement transmise et comprise. Ensuite viendra la passe de polish à laquelle on a hâte ! 


lundi 15 octobre 2012

Projet Synthèse : Continuum


Cette session nous avons un peu plus de 3 mois pour réaliser notre dernier projet au NAD. Nous avons choisi de créer une courte expérience sous la forme d'un jeu. Avant le début de la session (et les premières semaines également nous avons décider des grandes lignes du projet). Nous avons été très occupés cet été ce qui a repoussé à la dernière minutes nos séances de brainstorms et les décision se sont prises très tardivement. J'aurais aimé avoir un peu plus de temps pour faire le travail nécessaire au niveau game design mais compte tenu des circonstances nous avons décidé de faire un projet vraiment acces sur nos compétences, c'est à dire : pas de mécaniques révolutionnaires (qui ont besoin de man power au niveau gamedesign et programmation que nous n'avons pas) mais plus tôt une histoire original qui va pousser la narration et le visuel. 

Voici le contexte de notre jeu : 

Alex, alpiniste-secouriste, reçoit un SOS d'une personne inconnue coincée dans la montagne. Il part alors à sa rescousse. Il ne tarde pas à retrouver la piste de l'égaré dans un temple abandonné en proie à une tempête de neige. En cherchant celui qu'il est venu secourir, Alex découvre peu à peu le temple et se rend compte avec un certain malaise que les choses ne tourne pas rond dans cet endroit désolé. Il finira par retrouvé le disparu et par réaliser quel est le mystère du temple : la personne qui va sauvé c'est lui même et lui même va lancer le SOS qui incitera une autre version de lui même à venir le secourir. Il est coincé dans un déjà vu qui se répète continuellement. Dans les dernier instant du jeu le joueur aura la possibilité de sortir du loop temporel... ou le peut il vraiment ?

Pour ce qui est des mécaniques de jeu nous y sommes aller au plus simple : le joueur peut simplement se déplacer en marchant ou courant dans l'environnement, à certains endroits des évènement se déclencheront et le joueur devra y réagir sous forme de QuickTimeEvents. 

Nous cherchons a faire vivre au joueur une expérience cinématique. Il n'y a pas vraiment de challenge de dexterité, le but du jeu est d'en découvrir l'histoire. On pourrait le classer dans les 'interactive dramas' comme Heavy Rain ou Dear Easter.   

Nous avons l'habitude de travailler ensemble, la séparation des rôles n'as donc pas été difficile : Agustin s'occupera du personnage et plus tard de modélisation d'asset. Viro et moi feront du level design puis il passera sur de l'environnement pendant que je m'occuperais de l'intégration de nos mécaniques et d'animer. Youssef va rigger et animer et Micheal animera et s'occupera des effets spéciaux. 

Voici ma partie de level design qui correspond à la seconde partie du jeu. Nous avons séparer la séquence de jeu en sous partie. Dans chacune on trouve un indice qui révèle plus ou moins le déjà vu. 

J'ai commencer sur papier pour me donner une idée de l'organisation de l'espace, des puzzle et du rythme. Voici la map que j'ai crée : 

J'y place les actions que le joueur devra faire et les events qui se produiront. Ensuite je passe a l'étape de construire le greybox dans UDK.

J'ai préalablement 'setup' un personnage (en utilisant Joanna de Vulturine en attendant que Agustin finisse une première version de son perso), avec une camera. Cela permet d'avoir un premier 'feel' de l'espace. J'ai aussi créer des archetype pour le pawn et la camera pour pouvoir les twiké facilement et changer le mesh et les anim du pawn sans avoir a recompiler a chaque fois. Le montrerais dans un prochain post (si j'ai le temp) comment faire des archetypes ;)

Voici quelques screenshots du greybox dans UDK : 





Vous pouvez voir sur certaines des images des trigger et des objets de couleurs vives : ce sont mes QTE et autres events place holders.

A ce jour j'ai presque fini de 'Kismeté' tout le niveau (y compris la partie de Viro). Le jeu est donc pas mal jouable même si tout est encore au stade de blocking (ou meme juste de place holder).

Hier soir j'ai intégrer les animatiques des cinématiques de Mishka et Youssef et j'ai fait avec succès le premier build de Continuum ! Nous avons donc une bonne base, il ne nous reste plus qu'a finir tout ça !

Autre chose : avecce premier build on va pouvoir commencer a faire essayer le jeu :)

Reprise de service

Salut,

Reprise de service de ce blog...

Petit résumé de ce qui s'est passé depuis le dernier post :

   - Vulturine a été présenter au coucours ACadémia de Ubisoft et y a remporté les prix 'Meilleure animation' et 'Meilleur design'. Malheureusement nous avons manquer le grand prix de 'Meilleur Prototype' et le jeu n'a donc pas été retenu pour la production de deux mois, contrairement aux membres de l'équipes : nous avons tous été sélectionner pour produire le jeu gagnant Pixel Trouble (initialement Pixel Panic, de l'équipe de l'UQAT).
Voici le trailer de Vulturine :


   - Pixel Trouble est un jeu produit dans UDK en 2 mois par une équipe\ de 25 étudiants (dont notre équipe du NAD : Agustin, Viro, Michael, Youssef et moi). C'est un jeu d'aventure à la troisième personne dans lequel le hero (Stream) doit débugger le monde de Super Adventureland 3D à l'aide de son jet de pixel (habilité lui permettant de créer des ponts de pixel dans un environnement 3D). J'y ai personnellement participé en tant que level designer. 
Voici le trailer de Pixel Trouble : 



   - Ma dernière session au NAD a commencer : je vous parlerais ici de l'avancement de notre projet synthèse ('notre' puisqu'une fois encore je fais équipe avec Agustion, Viro, Michael et Youssef pour notre dernier projet étudiant).