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). 

dimanche 29 avril 2012

Toujours dans les temps ?

Pour faire simple voici ou j'en suis rendue :

J'ai les blocking de mes deux mouvements de dance, celui du BBoy étant pas loin du final ( une passe de polish serait nécessaire mais ça dépendra du temps.... qui manque en ces temps terribles de fin de session...)

Maintenant ce qui me reste a faire d'ici demain soir...

  • Je doit intégrer la foule : j'ai déjà skinner les perso de Neptune avec un biped complet, il faut donc que je fasse prendre la pose puis que je simplifie leur rig). C'est la première chose que je fais aujourd'hui, dans max une heure et demi c'est fini. 
  • Je dois faire un idle pour chaque danseurs. Ici je prévois de faire de 'vrai' idle : dans le sens de ils vont vraiment pas faire grand chose x). Ça ne devrait pas être trop long non plus. 
  • Enfin je dois amener le mouvement de la BGirl au meme niveau que son adversaire et trouver le temps de polish les deux ensuite. 
Work, work, work ! 


lundi 23 avril 2012

Streetdance - update rapide

Salut,

Avancement de la semaine, ou plutôt de la journée (nos autres projets sont dus dans une semaine également :s).

J'ai pas mal avancé sur la danseuse. Je prend mes références dans les vidéos de IGlide et Non-Stop.


Voici mon blocking dans son état actuel (non terminé) :
Le timing n'est pas fait et la fin a été rushée mais j'y travaille ;) 

J'ai intégrer ça dans la scène UDK. Première chose a changer au plus vite : la tourner vers les camera, elle est trop de profil, on voit rien xD


lundi 9 avril 2012

Contrainte 3

Une nouvelle contrainte !
Je finirais de vous parlez de contrainte 2 plus tard : pour l'instant je vais vous expliquer rapidement quelle ets notre troisième te dernière contrainte.

Ça s'appelle Streetdance.

En temps qu'animatrice je dois animer une partie d'une foule plus faire une anim de dance et un idle pour chacun des deux personnages principaux. Les animations de la foule doivent être réparties sur trois rigs avec un nombre limité de bones.

J'ai décidé de donner trois bones aux personnages les plus éloignés, 7 à ceux un peu plus près et 20 pour ceux qui seront vraiment proche du stage.
J'ai commencer par celui du premier rang et ensuite j'ai posé les deux autres, colapsé le skin et je les ai reskinné avec beaucoup moins de bones.

Voila ce que ça donnait hier soir. Je suis en charge des personnages verts.

Contrainte 2 - retour sur ce qui a été acompli

Salut,

Notre prototype de Vulturine est maintenant terminé (ou du moins nous n'avons plus le temps de continuer), la présentation devant Ubi est mercredi... hopefully on vous dira jeudi que ça s'est bien passé, mais reste qu'on est confiants et fiers de ce qu'on a réussi à livrer ! 

Je vais maintenant repasser sur les aspects sur lesquels j'ai travaillé pendant ces deux mois. 

Animation

Mon rôle principale étant animatrice j'ai réalisé le tiers des animations de Joanna et de Bird ( les deux autres tiers ont étaient réalisé par Micheal et Youssef ). Joanna a été particulièrement agréable à animer grâce au rig faciale de Youssef. C'est la première fois que j'utilisais ce genre de rig, il rend Joanna bien plus vivante. 

[vidéo s'en vient bientôt]



Set up des maps

Je me suis également occupé de séparé nos map en différents levels pour nous permettre de travaillé tous en même temps sur nos layers respectifs. Je trouve que c'est vraiment une bonne façon de travailler, elle nous à permet d'avancer rapidement, chacun sur nos choses. Nous avons séparer nos maps de la façon suivante : 
      • LA : pour tout l'environnement et le lightning (par viro)
      • LD : pour le Kismet (puzzles, navigation, pieges, Bird, par Youssef et moi)
      • FX : pour les particules et les destruction (par Micheal et Agustin)


Kismet

J'ai passé beaucoup de temps à rendre le prototype jouable avec le plus des mécaniques que l'on voudrait avoir dans le jeu final. Nous n'avons pas de programmeurs sur le projet, la plupart de ces mécaniques sont donc faites grâce à du Kismet. Je vais expliquer rapidement comment j'ai fait marcher quelques unes de nos mécaniques. 
    • Puzzles
C'était notre principale mécanique de la première partie de nos niveaux et le kismet le plus imposant. Accrochez vous ;) 



La base de ce kismet vient de scripts trouver sur internet (ici http://www.hourences.com/tutorials-ue3-kismet-interface/) qui permettent de créer un interface dans Kismet. Attention, cette façon de faire est extrêmement lourde et instable (je m'en suis rendu compte quand le Kismet commençait à prendre de l'ampleur), ça marche pour notre proto mais il nous faudra faire ça autrement pour le jeu final. 

















Ici on voit la première partie du Kismet : lorsque Joanna arrive dans un trigger proche de l'altar, le joueur peut appuyer "E". Il se passe alors plusieurs choses : 
  • #1. On retire le contrôle de Joanna au joueur et on change la camera pour une cam contextuelle au puzzle. Cela fait on render le HUD qui permet au joueur de résoudre le puzzle. 
  • #2. En même temps on lance le remote event "puzzle 2" qui permet à des partie de kismet complètement différentes (le comportement de Bird en l'occurence) de partir à ce moment là. Très pratique pour garder un Kismet ordonné (shortcut : Ctrl+R+click pour créer un remote event)
  • #3. Joanna est téléporté devant l'altar (des fois que le joueur ait appuyé E lorsqu'elle ne se trouvait pas à la bonne place. Personne ne s'en rendra compte car cet téléportation se fait en même temps qu'un cut de caméra). Puis Joanna joue les anim demandées (ici 'mettre la clé' puis son 'idle de puzzle'). Vous pouvez vous référer aux post de contrainte 1 (Chase : Gang of New York) sur le pawn anim pour plus d'info sur comment fonctionnent ces nodes. 
  • #4. Node de Hourences, allez voir sur son site pour les détails de leur fonctionnement. J'ai utiliser deux Render Texture, un pour chaque icone (chaque groupe de bloc) et un Render Mouse. 

D'après notre gamedesign, les bloc se déplacent sur des trajets pré-définis et s’arrêtent sur des position pré-définies elles aussi. J'ai donc commencé par décider d'un chiffre pour chaque position de chaque bloc et leur attribué un 'int' variable selon leur position de départ. 
  • #1. Avec une switch sans increment amount je track la position du bloc. 
  • #2. Variable qui contient la position du bloc. 
  • #3. Je set la nouvelle position du bloc puis joue le matinée qui l’amènera au bon endroit. 
  • #4. Selon la position du bloc et le click du joueur (gauche ou droite) je joue le matinée qui place les bloc à sa nouvelle position. Dans les settings du matinée Rewind on Play et No Reset on Rewind doivent être coché pour que le matinée puisse jouer plus qu'une fois et que le bloc effectue le mouvement de l'endroit ou il se trouve au moment du click. 
Dans certains cas il faut aller un peu plus loin : si un bloc est dans le chemin de celui qui doit bouger ce dernier restera sur place. Il faut donc vérifier la position des autres blocs avant de faire avancer ou pas le morceau choisi. Ici l'utilisation des 'Named variables' est très importante, pour garder le kismet propre mais surtout pour ne pas se perdre. 




Une autre sécurité importante : anti-button smacher security. En effet si le joueur envoie des commandes répétées avant que les blocs aient fini leurs mouvements, ils enchaînerons sur le mouvement suivant en cour de route et se retrouveront dans des positions assez random, complètement hors des tracks. Le trick est  de simplement bloquer les intervention du joueur pendant 1 seconde (le temps des animation des blocs). 


Enfin dernière étape : repérer la fin du puzzle lorsque les blocs sont à la bonne place et redonner le contrôle de Joanna au joueur. 
Cette séquence est lancé dès le début du puzzle et vérifie à chaque instant si les blocs sont tous à la bonne place. 

Petit mot de fin : avec ce genre de Kismet monstre, il est important de rester organisé, vive les sub-séquences. 

    • Corruption et limite de temps




    • Monkey bars



 



[WIP, le reste arrive d'ici demain]



lundi 26 mars 2012

Avancement de la dernière semaine

Le temps passe, la remise approche.
Cette semaine j'ai fini de placer les pièges dans le level platforming et de créer le Kismet qui va avec. Les anim des pièges en sont à l’étape de blocking mais ne devrait pas prendre trop de temps à finalisé.




J'ai aussi travaillé sur la cinétique finale du level : Joanna s'enfuit du temple qui s'écroule sur elle. Ici il va me falloir un peu de temps pour polisher mais j'ai l'impression que ça avance bien. 


Plus que une semaine avant la remise et a peine deux avant la présentation à Ubi. Il me reste une partie de la grosse cinématique du milieu du level (que l'on s'est partagé avec Mishka et Youssef) et beaucoup de polish. 

mardi 6 mars 2012

Importation dans UDK : success

Okay okay ça n'aura pas été trop long cette fois ci :)
Pour le problème de l'oiseau : régler en exportant le mesh avec le rig biped lorsque ce dernier est en figure mode règle le problème :)
J'ai mis a jour l'anim set du Bird et de Joanna avec toutes mes anims (certaines bien moins avancées que d'autre)
(ordre des anim : idle easy, idle action, taunt on land)

(idle easy court, idle easy long, monkey mouvement, monkey idle, idle corrupted, walk, death)

A présent je vais travailler à amener le death et le idle corrupted au même niveau que le reste et continuer à polisher toutes les anim par passe. Il faut aussi que je vérifie l'intégration in game de chacune des anims (certaines comme les idle et le walk marchent déjà dans le jeu, cf http://ysemache.blogspot.com/2012/03/contrainte-2-animtree.html )

The Curse is back =(

J'ai voulu importer mes anim dans UDK puisque j'ai une premiere version de chaque anim (celles de Joanna et celles du bird)...
Malheureusement, les problèmes que j'avais eu avec le bird et qui s'étaient réglés d'une façon dont je ne suis pas certaine sont de retour :(


Je cherche donc toujours un solution a ce problème... Sans résultat pour le moment.
J’espère revenir avec de bonne nouvelle d'ici les prochains posts...

lundi 5 mars 2012

WIP monkey bars

WIP du walkcycle

Pour notre personnage principal, Joanna, je vais animé : un walkcycle, un 'monkey bars' (un mouvement et un idle), un idle normal et un idle corrompu ainsi qu'un death anim.
Voici un WIP de mon walkcycle. J’espère avoir un bon bloking du monkey bars dans la journée.

jeudi 1 mars 2012

Bloking de mes anim pour le bird

Pour l'oiseau je dois produire 3 anim : un idle, un idle spé et un taunt. Les trois blockings sont commencés.
Idle easy :
video
Idle Action : 

video


Et taunt :
video

video

lundi 27 février 2012

Planification et References

Au début du projet nous avons listé les animations que nous auront à faire pour le projet avec les autres animateurs (Youssef et Michael). Voici celle dont je vais être responsable :
Pour Joanna :

  • Monkey : idle et mouvement
  • Idles : normal et corrompu
  • Death (peut être plusieurs selon la façon dont elle meure)
Pour la créature : 
  • Idles : un normal et un ou il fait quelque chose pour briser la répétition
  • Taunt land : quand l'oiseau veut attiré l'attention lorsqu'il est posé
En plus de ça nous auront quelques petites cinématiques dont nous sommes en train de faire le storyboard que nous nous répartiront et des animation d'environnement (pour les déplacement dans les puzzles, les effondrements de terrain, les particules, les pièges).

Cette semaine je compte peaufiner le skinning de l'oiseau/créature et commencer le bloking de mes anim pour cette dernière. Beaucoup de recherche de ref pour Joanna comme pour le bird itoo. 

Voila une petite liste de celle que j'ai déjà pour l'oiseau : 

samedi 25 février 2012

Rig et skin du piaf

Agustin m'a fourni la semaine passé un low rez  de l'oiseau.
J'ai passé les derniers jours à le riggé/skinné.
Quelques faits dont je me suis rendue compte en cour de route :

  • Les rig CAT ne s'exportent pas en fbx à ce jour (ou pas facilement...), apparemment il faut ActorX pour que ça fonctionne (Actor X n'est plus disponible pour Max 2012). J'ai donc abandonner assez vite l'idée d'un rig avec CAT. 
  • J'y suis donc allée avec un biped. Ici aussi j'ai eu quelques problèmes. Importés dans UDK les extra bones que j'ai utilisé dans les ailes avaient de drôle de comportements... J'ai pas vraiment été en mesure de trouver d'ou venait le problème mais j'ai trouvé un walk around : j'ai scaler down le premier link de mes extra et l'ai exclu du skin. En gros je ne me sers du premier link que pour attacher l'extra  au biped original et je n'anime que les links suivants. 
(problème ac les extra)





mercredi 22 février 2012

3C - Partie 1, Camera

3C est un diminutif pour Character, Control, Camera. Ces trois concepts sont à la base d'un jeu vidéo : 
comment je vois l'univers du jeu à travers mon écran (camera), qu'est ce que peut faire mon personnage (character), comment j'interagie avec cet univers et ce personnage (control). 

Dans un premier temps il nous faut vérifier que ces trois paramètres sont faciles à comprendre et utiliser pour le joueur et faisables pour nous. 

Nous voulions avoir initialement une caméra OnRail (à la God of War) pour pouvoir controlé le point de vue du joueur et faire des angles de caméra artistique tout en guidant le joueur. Youssef a trouver ce site : http://www.josephcecot.com/programming/unrealscript/ qui propose une solution. Nous avons réussi à les faire fonctionner (et avons demander l'autorisation d'utiliser les scripts). Voici ce que ça donne : 

video

Ici nous avons deux problèmes : 
  • D'abord un technique : les contrôles ne changent pas selon l'angle de la caméra mais selon la rotation du personnage. La caméra doit donc rester plus ou moins derrière le personnage pour que les contrôles restent naturels ce qui réduit beaucoup nos possibilités. C'est arrangeable dans le code surement mais nous n'avons pas les connaissances nécessaires pour le modifier nous même. 
  • Ensuite d'un point de vue plus design : la première moitié de notre niveau consiste en de l'exploration (avec platforming léger) et des puzzles. Pour explorer une caméra OnRail est moins avantageuse car elle restreint beaucoup ce que le joueur peut voir, cela rend cette partie du jeu moins intéressante. 
Nous avons donc décider d'utiliser deux sortes de caméra : une 3ème personne (dont le code  a été trouvé sur le forum de UDK) pour la partie exploration/puzzle et une OnRail lorsque l'on passe en mode plateforming timé pour le retour (ici le joueur doit seulement s'enfuir, il connait déjà le chemin car il l'a fait à l'allé et n"a donc pas besoin d'autant de liberté). Voici à quoi ressemble la caméra 3rd person :

mardi 21 février 2012

Contrainte 2 : Vulturine

Salut,

J'ai mis du temps  à me rappeler que j'avais un blog mais now je vais donner des news plus fréquemment. Pas de post depuis une semaine (voir plus :s) ne veut pas dire que je me suis tournée les pouces : la contrainte 2 est belle et bien commencée et c'est 2 longs mois de travail qui s'annoncent.

En quoi consiste cette nouvelle contrainte ?
Nous avons deux mois pour réaliser un level, le premier niveau d'un jeu que nous avions designé sur nos temps libre pendant les vacances et le début de la session (nous= Viro Nhek, Agustin Trechi,  Youssef Semache, Michael Meltchenko et moi même). Nous avons décider de faire une démo jouable plutôt qu'un FakeGameFootage pour les défi que cela représente (intégration, level design, ...).

En quoi consiste le jeu ?
Notre jeu s'appelle Vulturine. Il rassemble des mécaniques de platforming rapide avec des puzzle. L'histoire met en vedette un jeune pirate échoué sur une île. Elle découvre, dans une grotte, un temple qui sert de prison à un capitaine maudit et son bateau. Elle devra résoudre des puzzles pour libérer le bateau tout en faisant attention aux pièges du temple et à la traîtrise du capitaine.
(résumé très court, j'élaborerais au besoin dans mes post futurs)

Voici le trailer de Pirates of the Caribbean: Curse of the Black Pearl  pour setter un peu l'ambiance ;) 

mercredi 8 février 2012

Contrainte 1 : done =)

Salut,
Je vous ai tenu un peu moins au courant sur la fin de la contrainte 1. La remise était lundi soir. Voici un vidéo de mon travail d'anim et de Kismet dans l'environnement de Viro Nhek avec les personnage de Agustin Trechi.



Et voici une autre vidéo pour montrer les différents fails que j'ai fait. Je n;ai malheureusement pas réussi a finir l'anim du fail pour le slide. J'ai été trop ambitieuse pour la fin :s Cela me servira de leçon pour une prochaine fois.



Pour résumer les dernière journée de cette contrainte 1 :
- j'ai rushé pour finir mes quatre anim de fail
- j'ai ajouté du son : musique et son de pas
- j'ai ajouté des particules de poussière lorsque le personnage pose le pied a terre (avec les notifies dans l'animset)

Et now : j'ai hâte de commencer la deuxième contrainte !

jeudi 2 février 2012

Fail handjump


video
Avancement du fail pour le mouv 'handjump'

Fail jump

video
Fail pour l'obstacle 'jump' plus avancé.

Anim(s) de fail

J'avais pris note la semaine dernière que mon fail devrait être refait car il avançait trop vers les obstacles et ne permettait pas de continuer la course (car il plaçait le personnage trop près de l'obstacle). Si je voulais le garder il aurait fallut faire game over au premier fail... 

Bref je me suis fait rapidement des blockings très primitifs pour pouvoir estimer si j'aurais le temps de faire un fail pour chaque sorte d'obstacle. Le principe serait que le perso franchira quand même l'obstacle mais mon anim sera plus longue et donc cela lui prendra plus de temps et il perdra un peu plus de terrain à chaque erreur. Je rajoute entre 30 et 50 frames aux anims. 

De cette façon le joueur peut arriver à la fin du parcours même s'il rate tous les sauts. On pourrait envisager de faire des fins différentes selon combien d'obstacles ont été passés avec succès. Genre : si tu n'en rates aucun tu as la fin ou tu attrapes le voleur sans problème, si tu en rates 1 ou 2 tu as la fin ou tu l'attrapes de justesse et plus de 3 échecs tu le perds de vue (anim de rage :P). Mais pour l'instant le but c'est juste d'avoir mes fails pour chaque obstacle (je n'aurais pas le temps de faire tout ce que je viens de décrire dans ce paragraphe ^^)

Voila les 4 fails (très peu avancés pour le moment, je pense avoir le temps de les finir à temps pour la remise)

video
video
video
video

Anim final

J'ai mis un peu de temps a trouver une idée qui me plaise pour mon anim de victoire. Finalement je vais y aller pour quelque chose d'assez simple :
- Caméra de derrière : fin de la course, le voleur parait plus fatigué, il vérifie qu'il est toujours poursuivi.
- Caméra passe sur le coté : le joueur plaque le voleur au sol.
- Caméra plus de face : le joueur prend le voleur par la gorge.

J'ai un petite idée pour une dernière scène que je ferais si j'ai le temps mais je garde ça secret jusqu'à là ;)

Voici ou j'en suis de l'anim  :

video

vendredi 27 janvier 2012

Skinning almost done

Deux de mes anim avec le perso 1 de Agustin Trechi. Le skinning pourrait être retravailler au niveau des poignets mais je ne pense pas que cela se verra dans le jeu. J'essayerais de l'arranger quand même demain.

video

Kismet

Salut,
Dans ce post je vais vous expliquer comment fonctionne mon Kismet pour le niveau de chase Gang of New York.
Voici d'abord une vu d'ensemble :
Ceci pour deux obstacles seulement mais on peux en rajouter autant que l'on veut. Il fait un peu peur comme ça : je vais le cleaner et vous expliquer chaque étape. 

Première chose à faire : un anim tree. Le mien est très basic, et à vrai dire, pas besoin dans notre cas de faire beaucoup plus compliqué :) 
Un AnimNodeSlot nommé FullBodySlot pour que le code puisse le retrouvé et la suite est aussi simple que possible. 

Kismet pour un obstacle : 

1. Définit la variable 'Me' qui représente le joueur. 
2. Quand le joueur pèse E, la bool 'E pressed?' passe true. Ne pas oublier de mettre le trigger count à 0 pour que le joueur puisse faire cette action autant de fois que nécessaire. 
3. Quand le joueur passe dans le trigger placer juste devant le saut un message l’informe de peser E et la bool 'E pressed?' passe à false. Le joueur a alors o.35 sec pour appuyer E avant que le Compare Bool vérifie s'il l'a fait à temps. 
4. Si le joueur n'a pas été assez rapide, la bool 'E pressed?' est à false quand Compare Bool vérifie. Les input du joueur sont désactivés et l'anim de fail joue. Il faudrait que le level recommence au début à ce point mais je ne sais pas encore comment, peut être juste en tuant le pawn pour pouvoir respawn mais le Modify Health n'a pas l'air de marché...
5. Si le joueur a pas été assez rapide, la bool 'E pressed?' est à true quand Compare Bool vérifie. Les input du joueur sont désactivés et l'anim de jump joue. Les input du joueur sont réactivés et le joueur peut continuer vers le prochain obstacle. 

Note : il est important de setter un delay é la sortie des pawn anim pour laisser le temps à l'animation de jouer en entier avant de rentre le contrôle au joueur. Allez vérifiez la duré de vos animations dans votre anim set. 

Attention : parfois l'animation reste coincer dans les collisions de l'obstacle... Pour éviter ça ajoutez un Change collision avant le pawn anim. 



Here we go ! :)
Il est temps de retourner à l'animation maintenant !

Level actuel

Juste avant de vous parler un peu du Kismet derrière tout ça voici ce que ça donne comme résultat. Il restera a setter une caméra pas contrôlée par le joueur et a reprendre mon Kismet précédent avec les matinée pour le voleur.


video

Faire marcher le Pawn Anim et le Root Motion

C'est cette partie qui m'as volé ma semaine car elle touchait au code... Je suis ignorante du UnrealScript : je suis parvenue à mes fins en copiant les partie de code trouvés ça et là qui me semblaient avoir un effet.

La première chose était de faire fonctionner le node Pawn Anim de Kismet. NADPawn est dérivé du Pawn très de base de UDK qui ne comprend pas cette action Kismet.
Il faut ensuite setter le root motion. Oui dans le code, je vais vous expliquer pourquoi.

Pawn Anim va chercher dans le Anim Tree de l'actor target un AnimNodeSlot. Comme celui là :
L'animation spécifiée dans Pawn Anim utilise les Channel vide de ce node. 
Pour setter le root motion il faut aller dans un AnimNodeSequence. Comme celui là : 
Bref, comme Pawn Anim n'utilise pas ce genre d'animnode il faut stter le root motion dans le code qui s’exécute lorsque Pawn Anim est appelé. 

Pour plus d'info sur le Root Motion allez sur la page de l'UDN, c'est très clair : http://udn.epicgames.com/Three/RootMotion.html


Bref : pour que tout marche correctement, il faut ajouter ces parties au code de NADPawn :


var AnimNodeSlot FullBodyAnimSlot;

simulated event PostInitAnimTree(SkeletalMeshComponent SkelComp)
{
if (SkelComp == Mesh)
{
FullBodyAnimSlot = AnimNodeSlot(Mesh.FindAnimNode('FullBodySlot'));
}
}

function enableRootMotion()
{
        // tell mesh to use Root Motion to translate the actor
        Mesh.RootMotionMode = RMM_Translate;

        // Tell mesh to notify us when root motion will be applied,
        // so we can seamlessly transition from physics movement to animation movement
        Mesh.bRootMotionModeChangeNotify = TRUE;
}


 //Fonction appelé par Pawn Anim
function OnPlayAnim( UTSeqAct_PlayAnim InAction )
{
if( FullBodyAnimSlot != None )
{
FullBodyAnimSlot.PlayCustomAnim(InAction.AnimName, 1.0, 0.2, 0.2, InAction.bLooping, true);
Mesh.RootMotionMode = RMM_Translate;
FullBodyAnimSlot.SetRootBoneAxisOption(2, 2, 0);
}
}


Ça doit paraître très simple pour quiconque s'y connais un minimum en UnrealScript mais bon... j'apprendrait un jour :P