WeAreSync.com

Voici la première session de développement consacrée à la réalisation de Aekan pour le concours Dream Build Play 2012 que je vous livre.

Comme promis, cette fois, j'utilise une meilleure caméra et un meilleur micro ! J'ai également amélioré la qualité du screencast qui est diffusé en vitesse x2 pour ne pas dépasser 20 minutes de vidéo. Et puis c'est aussi moins ennuyeux à cette vitesse ! Exit également les commentaires vocaux tout au long de la vidéo. J'ai plutôt opté pour un fond musical issu de Jamendo.

Le résultat est plutôt agréable à regarder, et même si vous ne regardez pas, vous pouvez toujours écouter :p

Mais parlons un peu du jeu en lui même. Le screencast commence avec un projet qui bénéficie déjà d'une architecture client/serveur, tout en restant dénué de tout gameplay. Ces premières 20 minutes se consacrent donc à la mise en place des premiers assets, à la création d'une caméra et à l'affichage des premiers tiles.

Coder un Space Invaders pour Windows Phone en moins de 3 heures ?

Challenge accepté !

Voici le live de cette expérience inédite de coding en temps réel que je vous livre en avant première. J'ai pris trois bonne résolutions pour la prochaines fois :

• Utiliser une meilleure caméra.
• Utiliser un meilleur micro.
• Découper la vidéos en plusieurs parties de 20 minutes maximum.

Trois rendu du deuxième modèle que j'entreprend avec ZBrush. Il s'agit des Pox, les servantes créatures qui peuplent le prochain jeu que je vais réaliser pour Windows Phone. Le tout à été fait en un peu plus de 4 heures.

ZBrush est décrit un peu partout comme une petite et révolution en matière de modélisation 3d. En l'occurrence je devrais d'ailleurs parler de sculpture 3d tant l'approche est différente des autres logiciels que j'ai l'habitude d'utiliser.

Avec ZBrush, on a l'impression de pétrir une pâte jusqu'à lui donner la forme désirée, puis de la ciseler avec des outils de grande précision, tel un chirurgien plasticien de haute volée. Les résultats sont aussi réussis qu'ils ont été facile a obtenir. En suivant les tutoriaux en ligne, on prend le soft en main au bout de quelques heures seulement. Ci dessus, je vous ai mis un screenshoot d'Octopus, ma première modélisation.

Radiation pour WP7 est une application qui vous permet de suivre l'évolution du taux de radioactivé mesuré en France et au Japon. Les mesures de 48 prefectures et de 280 stations sont recueillies en temps réel et proviennent de sources officielles comme le Nuclear Safety Network for Nuclear Environment.

« Comment allons-nous pouvoir vivre ici ? » C’est la question que posa Kor-Koben à ses conseillers après milles nuits d’errance en Saal-Tragar. Comme personne ne répondait, le Grand Architecte Balik intervint : « Avec du sable et des pierres . » A cause de ces paroles, Balik risqua sa vie deux fois. Une première en fois pour s’être adressé directement au roi sans y avoir été invité, et une seconde fois pour avoir tenu des propos qui aurait été entendu comme des sarcasmes s’ils étaient venus d’un des conseillers de Kor-Boben. Ce dernier n’était pas particulièrement réputé pour sa bonne humeur ou pour sa tolérance. Kor-Koben devait mener ses hommes d’une main de fer à travers les déserts de sable noir. Pour conserver la fragile union des huit clans, il tranchait vif et étouffait toute graine de discorde ou de rébellion. La peur qu’il inspirait à ses suivants lui semblait être de loin l’outil le plus efficace.

C’est sans doute à cause de tout cela que la légende raconte que Kor-Koben s’empourpra violement devant l’audace de son architecte. Balik fût immédiatement pétrifié et tomba à genoux. Ces dernières années, ce petit homme au crane dégarni était tenu à l’écart de toutes les décisions politique. Quel roi avait besoin d’un Grand Architecte alors même que le peuple ère depuis trois ans dans un déserts instable et inhospitalier ?

C’est à tête baisée mais la voix ferme que Balik reprit : « Oh roi, s’il est vrai que le sable noir recouvre toute cette terre, ordonnez moi, et je vous bâtirais une cité tirée du sable et des pierres de ce désert. Elle protégera votre peuple des jours brulants et l’abriteras du vent d’Est, porteur de tempêtes et de nuisance. »

Et c’est ainsi que fût bâti la grande Talanta, première cité d’Oriclaus, et dont le nom signifie « Repos des âmes ».

Cette fois ci, c'est la bonne ! Après avoir amorcé le projet en 2004, et après avoir exploré diverses possibilités, je remet Links of Power sur la table ! Le projet sera dédié à Windows Phone 7 et je suis vraiment très excité à l'idée de le mener à terme.

Retour sur les précédentes versions :

La version C++ direct X était une belle réussite d'un point de vue graphique. Le moteur 3D était capable de charger dynamiquement de très grandes cartes, d'afficher des objets et était doté d'un bon nombre d'effets réalisés avec les shaders.

Point faible du projet, le gameplay était absolument inexistant :) La réalisation de tout les objets 3D me demandait beaucoup trop de temps alors j'ai tenté une autre approche, avec SilverLight (la version alpha à l'époque), puis avec WPF.

Les résultats ne m'ont jamais satisfait et j'ai préféré revenir à la version 3D pour laquelle j'avais tout de même plus d'affinité.. bien que le gameplay soit toujours inexistant :)

Quand finalement je me suis rendu compte qu'il manquait une trame, un univers à raconter, je me suis mis à écrire. J'ai réuni des amis, et nous avons longuement imaginé des mondes et des scénarios.

Aujourd'hui, l'univers de Links of Power est très très riche. Je me suis toujours efforcé de ne pas trop en dévoiler avant d'avoir une version 3D alpha du jeu disponible. Mais cette version ne viendra pas. Pas maintenant en tout cas, car aujourd'hui, et pour les mois à venir, WP7 sera la plateforme idéale pour développer un autre aspect de Links of Power.

Cette version de Links of Power sera résolument un jeu de conquête spatiale doté d'un coté gestion économique, politique et social exacerbé (Rien que ça :) L'un des points forts du jeu qui va satisfaire de nombreux joueurs, c'est qu'il ne sera pas nécessaire d'être un Hardcore Gamer pour progresser. Les Causuals Gamers vont avoir des opportunités à toutes les étapes du jeu pour vraiment s'amuser.

Bref, vous l'avez compris, ce mois d'août s'annonce très prometteur et je vais faire mon possible pour vous tenir au courant du développement aussi souvent que possible sur #lop via twitter.

Maintenant qu'on peut faire un peu joujou avec l'émulateur de WP7, je doit avouer que ça donne envie.

Microsoft vient d'annoncer qu'ils allaient distribuer des Windows Phone 7 à tous ses employés. De leur coté, les MVP font du bruit sur twitter pour en avoir un eux aussi. Moi aussi je veux bien tester le produit et même en faire la promotion :)

Edit : La version 1.1.1 de Zappiti corrige un bogue rencontré par certains utilisateurs de Vista et Seven x64.

Encore quelques heures de patience avant la sortie de la version 1.1.0 de Zappiti qui apporte des améliorations très attendues.

Pour faire suite à un post précèdent où je vous livrait quelques informations sur l'architecture de Zappiti, voici quelques informations toutes fraiches pour ceux qui veulent en savoir plus :

• Zappiti est réalisé en C# avec le Framework .NET 3.5
• L'interface graphique de Zappiti à été réalisé en WPF
• Zappiti repose sur un design pattern appelé MVVM
• Expression Blend 3 à été utilisé pour réaliser l'interface
• Installateur utilisé est Visual Studio Installer 4.5
• Zappiti est développé sous Visual Studio 2010 Ultimate
• Vous pouvez suivre les étapes du développement sur Zappiti Issue Tracking System
• La base de données choisie à faillit être SQL Server Compact 3.5, mais c'est SQlite qui à été retenu
• La version actuelle à demandée plus de 10 semaines de travail
• Zappiti, c'est 238 fichiers sources et 27687 lignes de code
• Hyperventilate à été écouté 118 fois pendant la première phase de développement...

Le problème : Une application (en l'occurrence, il s'agit de Zappiti, le média manager pour platine multimédia Dune HDi) utilise une DLL s'appelant MediaInfo.dll et qui est fournie en version x86 et x64. Zappiti est compilé en mode AnyCPU et peux donc fonctionner avec l'une ou l'autre du moment que la DLL retenue corresponde à la plateforme du système d'exploitation courant.

L'objectif : Créer un installateur avec Visual Studio Installer qui détecte si l'application s'installe sur une architecture 32bit ou 64bit et qui installe la DLL correspondante.

Commençons par ajouter les DLL : Première étape, ajouter les deux versions de la DLL à notre installateur. Il n'est pas nécessaire de spécifier de Condition. Ma première approche fût justement de le faire en spécifiant TargetPlatform=x86 ou TargetPlatform=x64. Malheureusement, la valeur de cette propriété est définie dans les paramètres de l'installateur. De ce fait, il aurait fallut créer deux installateurs, un pour chaque plateforme, alors que c'est justement ce que je cherche à éviter. Non, pour choisir le bon fichier dynamiquement en fonction du système d'exploitation, il faut faire autrement.

La solution consiste à créer des Custom Actions pour choisir le bon fichier : Pour cela, commencez par ajouter un fichier de type de Installer Class dans votre projet comme indiqué ici. Il n'est pas nécessaire de créer un nouveau projet DLL, vous pouvez l'ajouter directement à votre exécutable. Visual Studio crée automatiquement une classe qui hérite de Installer. Ensuite, il suffit de surcharger la fonction OnBeforeInstall() de cette classe pour executer le code désiré au bon moment.

Etrangement, lors de l'installation OnBeforeInstall s'exécute après la copie des fichier. Ce n'est pas très grave ici, au contraire. Nous allons laisser l'installateur copier les deux DLL, puis en supprimer une et renommer l'autre. Maintenant, il faut dire à l'installer d'appeler cette fonction en créant un nouveau Custom Action comme indiqué ci dessous, et en choisissant pour cible le "Primary output" de notre projet qui contient la classe que nous venons de créer.

Détecter la plateforme de l'OS : En premier lieu, j'ai testé la valeur retournée par IntPtr.Size. En effet, sur une plateforme x86, la valeur retournée serait 4 et sur une plateforme x64 on obtiendrait un 8. Hélas, cette méthode retourne toujours 4 car souvenez vous, le TargetPlatform de notre installateur est définit à x86 pour pouvoir se lancer de n'importe quel PC.

Pour détecter la plateforme, nous allons utiliser la méthode GetNativeSystemInfo() en l'important de kernel32.dll.

 
        private enum Platform
        {
            X86,
            X64,
            Unknown
        }
 
        internal const ushort PROCESSOR_ARCHITECTURE_INTEL = 0;
        internal const ushort PROCESSOR_ARCHITECTURE_IA64 = 6;
        internal const ushort PROCESSOR_ARCHITECTURE_AMD64 = 9;
        internal const ushort PROCESSOR_ARCHITECTURE_UNKNOWN = 0xFFFF;
 
        [StructLayout(LayoutKind.Sequential)]
        internal struct SYSTEM_INFO
        {
            public ushort wProcessorArchitecture;
            public ushort wReserved;
            public uint dwPageSize;
            public IntPtr lpMinimumApplicationAddress;
            public IntPtr lpMaximumApplicationAddress;
            public UIntPtr dwActiveProcessorMask;
            public uint dwNumberOfProcessors;
            public uint dwProcessorType;
            public uint dwAllocationGranularity;
            public ushort wProcessorLevel;
            public ushort wProcessorRevision;
        };
 
        [DllImport("kernel32.dll")]
        internal static extern void GetNativeSystemInfo(ref SYSTEM_INFO lpSystemInfo);
 
        private static Platform GetPlatform()
        {
            SYSTEM_INFO sysInfo = new SYSTEM_INFO();
            GetNativeSystemInfo(ref sysInfo);
 
            switch (sysInfo.wProcessorArchitecture)
            {
                case PROCESSOR_ARCHITECTURE_AMD64:
                    return Platform.X64;
 
                case PROCESSOR_ARCHITECTURE_INTEL:
                    return Platform.X86;
 
                default:
                    return Platform.Unknown;
            }
        }
 

Et voila, il reste juste à renommer la DLL correspondante à la plateforme choisie :

 
        protected override void OnBeforeInstall(IDictionary savedState)
        {
            base.OnBeforeInstall(savedState);
 
            string location = Path.GetDirectoryName(
                    System.Reflection.Assembly.GetAssembly(GetType()).Location);
 
            if (File.Exists(Path.Combine(location, "MediaInfo.dll")))
                File.Delete(Path.Combine(location, "MediaInfo.dll"));
 
 
            Platform p = GetPlatform();
            if (p == Platform.X86)
            {
                File.Move(Path.Combine(location, "MediaInfo-x86.dll"),
                          Path.Combine(location, "MediaInfo.dll"));
                File.Delete(Path.Combine(location, "MediaInfo-x64.dll"));
            }
            else if (p == Platform.X64)
            {
                File.Move(Path.Combine(location, "MediaInfo-x64.dll"),
                          Path.Combine(location, "MediaInfo.dll"));
                File.Delete(Path.Combine(location, "MediaInfo-x86.dll"));
            }
        }
 

Lorsqu'on désinstalle, il faut penser à supprimer "MediaInfo.dll" qui n'est pas connue de l'installer. On peut procéder comme précédemment en créant un nouveau Custom Action qui fera le ménage :

 
        protected override void OnBeforeUninstall(IDictionary savedState)
        {
            base.OnBeforeUninstall(savedState);
 
 
            string location = Path.GetDirectoryName(
                          System.Reflection.Assembly.GetAssembly(GetType()).Location);
 
            File.Delete(Path.Combine(location, "MediaInfo.dll"));           
        }
 

C'est presque finit : L'installateur répond parfaitement au besoin de sélectionner automatiquement la DLL correspondante à la plateforme du système d'exploitation courant. Néanmoins, on se retrouve avec deux fichiers : un .MSI et un .EXE. Le premier est notre installateur et le second est un bootstrapper qui sert à vérifier et à installer les dépendances nécessaires pour que notre installateur puisse lui même se lancer tout les cas. C'est donc une bonne chose de les avoir, mais cela fait tout de même un fichier de trop à mon goût.

Il existe des solutions payantes pour fusionner les deux fichiers en un seul exécutable. Moi j'ai trouvé plus simple (et moins cher) : utiliser WinRar et générer un package avec l'option SFX : on peut lui indiquer d'extraire les fichiers dans un dossier temporaire, de lancer setup.exe et même personnaliser l'icone de notre exécutable. Maintenant, on a plus qu'un seul exécutable qui installe tout ce qu'il faut automatiquement. Il ne reste plus qu'a le distribuer !