mercredi 2 janvier 2013

Faire un exécutable de votre jeu


.UDK to .EXE

  • Avant de packager votre jeu : vérifier que tout marche bien...
      Il y a assez peu de chance que votre jeu packagé fonctionne si déjà dans l'éditeur ça foire... Mais à vrai dire c'est pas en faisant un 'play from here' que vous allez pouvoir vérifier ça : jouer votre jeu en 'play on PC'. Certaines choses ne marchent pas tant que le jeu n<est pas lancé 'On PC' (par exemple les cinématiques bink lancées depuis Kismet ). 


     Il arrivera parfois que votre jeu crash quand vous le lancez 'On PC'. Probablement parce que ya quelque chose dans le code qui bug (c'est grâce aux progs qu'un jeu marche mais c'est aussi souvent à cause d'eux - de moi sur Continuum xD - que ça crash). Bref pour vérifier des erreurs de progs... Je ne sais pas si c'est une bonne technique, comme vous savez je fais des expériences en programmation sans vraiment m'y connaitre et si ça marche je suis contente, peut importe que ce soit la meilleure solution, si vous en avez d'autres je suis toute ouïe:) 
    Bref quand Kismet trouve une erreur ou un log, il l'affiche dans le log que l'on peut accéder en appuyant sur Tab ou '~' (la touche en haut a gauche, doit être en clavier anglais pour le faire). 




     

     Mais les erreurs de script ne s'affiche pas ici. Je faisais alors un 'fake exe' : un raccourci pour lancer la map en 'Play on PC' directement depuis le bureau.



  1. D'abord, allez chercher l'application UDK dans son dossier et faite en un raccourci sur le bureau.        
  2. Ensuite click droit sur l'icone du raccourcis pour aller dans ses Propriétés   
  3. Dans Cible il doit y avoir C:\UDK\UDK-2012-07\Binaries\Win32\UDK.exe  le_nom_de_votre_persistent.udk -log (l'emplacement de UDK, espace, le nom de la map que vous voulez tester, -log va lancer le log des scripts)
  4. Voila ce qui s'ouvrira : 



     Vous pouvez aussi trouver les logs ici :  C:\UDK\UDK-2012-07\UDKGame\Logs. 

  • Config.ini
     Les configs se trouvent ici : C:\UDK\UDK-2012-07\UDKGame\Config.

    Je ne sais pas à quel point c'est nécessaire car je pense que FrontEnd les overwrite mais dans le doute : le seul dont vous avez vraiment besoin c'est  DefaultEngine.ini. 
  1. Dans [URL] :
    Map=Continuum_PERSISTENT_01.udk
    LocalMap=Continuum_PERSISTENT_01.udk
  2. Dans [Engine.ScriptPackages] (vous l'avez surement déjà changer quand vous avez setup votre projet pour que les script complilent):
    +NonNativePackages=Continuum (le nom du dossier dans lequel vous avez vos scripts)
  3. Dans [UnrealEd.EditorEngine] (vous l'avez surement déjà changer quand vous avez setup votre projet pour que les script complilent):
    +EditPackages=Continuum (le nom du dossier dans lequel vous avez vos scripts)
     Voila pour les config, pas long ;) 

  • Ready to Go

     Lancez Unreal Frontend (C:\UDK\UDK-2012-07\Binaries\UnrealFrontend.exe). 


  1. Ajoutez toutes les maps dont votre jeu aura besoin.
  2. Choisissez la première à être loader (soit votre map de menu, soit votre Persistent - si comme nous vous n'avez pas vraiment de menus)
  3. Press Start et laissez FrontEnd travailler ;) La suite et pas mal simple, juste donner un nom a votre jeu quand le logiciel vous le demande et il vous créera un .exe dans le dossier que vous avez indiqué dans 'Target Directory'. 

J'espère que tout ça pourra vous être utile, à la prochaine !

La fin d'un Continuum

Salut !

Je ne sais pas si vous êtes encore beaucoup a passer par ici de temps en temps : comme d`habitude il y a eu un début de projet avec des posts.... un milieu sans nouvelles... et maintenant qu'il est fini (et avec un peu d'aide des bonnes résolutions de la nouvelle année) me revoilà.

Yep Continuum est officiellement fini. Juste officiellement parce qu'on a quelques petits trucs a corriger avant de pouvoir le mettre en ligne (ce que l'on voudrait faire dans une ou deux semaines). Mais le NAD c'est fini pour nous (snif), le projet a été présenter à l'école (merci à tous ceux qui ont été là, vous allez nous manquer ! : D) et on est super content de la réactions des gens ! Le travail des 4 derniers mois n'aura pas été en vain.

Voila le teaser du jeu par Youssef (qui est en train d'en faire un trailer pour la sortie sur le net ;) ) :


Aujourd'hui je vais faire un petit résumé de comment on fait un build (un executable) de nos maps udk, en espérant que cela puisse servir au sessions prochaines (ici il faut lire : CONTINUEZ A FAIRE DES JEUX AU NAD ! :D).

Oh un petit mot avant de passer à du technique : ce blog avait été créer pour les cours au NAD mais je vais faire de mon mieux pour continuer a y mettre mes projets perso (ou mes projets avec bossteam : on arrête pas de se voir parce que l'école est fini ;) ).

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