Novae : présentation CocoaHeads Toulouse 2013

Novae : présentation CocoaHeads Toulouse 2013

,Cette publication est la synthèse de la présentation faite lors de la session CocoaHeads à Toulouse le 19 septembre.

Le sujet de cette présentation était : La chronique de la création d'un jeu iOS - Le processus de création d'un jeu par un développeur indépendant.
De l'idée directrice à la sortie sur l'App Store et ses évolutions en n'oubliant pas la présentation de quelques techniques spécifiques au développement d'un jeu.

Cette présentation fait écho à un article que j'ai rédigé peu après sa sortie : Chronique de la création d'un jeu sur iOS.

Présentation

Je m'appelle Dominique Vial et je suis développeur indépendant d'applications iOS. Je vais présenter ici la chronique de la création d'un jeu iOS. J'ai rédigé et publié un article sur la création de ce jeu peu après sa sortie : Chronique de la création d'un jeu sur iOS.

Cette présentation n'est pas basée sur cet article : elle le complète. L'auditoire visé par l'article était avant tout le profane en développement informatique qui ne sait pas comment se conduit un projet informatique, ni à plus forte raison un jeu. Pour cette présentation CocoaHeads l'auditoire est différent puisque composé de développeurs iOS confirmés qui connaissent les rouages de la conduite d'un projet informatique. J'ai donc décidé de faire une présentation avec un angle d'observation différent, celui du processus de création d'un jeu par un développeur indépendant. De l'idée directrice à la sortie sur l'App Store et son évolution, en n'oubliant pas de présenter quelques techniques spécifiques au développement d'un jeu.

Au fait, le jeu en question s'appelle Novae. Il est disponible sur l'App Store.

C'est l'histoire d'un mec...

Qui réalise le jeu ?

Moi même : Dominique Vial. Je suis développeur indépendant sous le régime d'une entreprise individuelle : Domsware.

De formation je suis Docteur et Ingénieur en Informatique Industrielle, diplômé de l'INSA Toulouse. Mon expérience professionnelle couvre plusieurs champs : recherche, enseignement, industrie, création artistique… Et de nombreux domaines dont la Robotique (durant mes travaux de doctorat), l'Aéronautique, le Spatial, Internet…

Concernant l'expérience iOS, j'ai participé à plusieurs applications iOS et notamment CoachMyRide (App Store), une application que j'ai entièrement créée en collaboration avec un entraîneur cycliste professionnel.

Enfin je joue aux jeux vidéos depuis l'enfance et sur iOS uniquement depuis quelques années.

Pourquoi ?

Pourquoi faire un jeu sur iOS ?

Tout d'abord j'ai la connaissance technique et l'expérience pour le faire. En plus de ce savoir faire, il y a la passion : le développement de programmes informatiques a toujours été une passion depuis mon adolescence, passion qui ne s'est pas flétrie au fil du temps et des expériences professionnelles. Il m'arrive encore d'exploser de joie devant mon écran, d'émettre un gros YES en levant les bras au ciel en signe de victoire lorsque je parviens à faire fonctionner un bout de code de ma création.

Ensuite c'est une question d'envies. Au pluriel.

L'envie de développer pour la plateforme iOS

Pour dire la vérité je n'ai été ni attiré ni intéressé par la sortie de l'iPhone, premier du genre. J'adorais mon portable Mac mais la téléphonie ne m'intéressait guère. Par contre la première fois que j'ai eu cet appareil dans les mains et que je l'ai manipulé ça a été la révélation ! Comme une grande lumière qui m'entourait et une musique divine qui jouait simultanément le "tada" du démarrage des premiers Macs !

Avec cet appareil merveilleux dans la main je retrouvais mon âge d'or de la programmation à moi, quand adolescent je développais des jeux sous Oric Atmos, Amstrad… Avec cette plateforme iOS tout me semblait possible de nouveau, n'importe qui pouvais créer et publier son jeu ! Ce qui changeait par rapport à mon enfance : je suis désormais un développeur confirmé ayant la formation, la compétence et l'expérience.

L'envie de développer tout seul

Il y a un modèle économique qui m'a toujours intéressé : vivre de mes créations. Et en l'occurrence de mes applications. Jusque là j'avais loué mes compétences à des entreprises puis réalisé des applications pour des clients. Avec CoachMyRide j'ai franchi un pas en faisant ma propre application selon mes propres critères. Sans en être totalement le maître du contenu toutefois. Et là, l'occasion se présente de faire un pas supplémentaire sur cette voie : faire une application tout seul mais vraiment tout seul.

Bien entendu je ne peux faire tous les aspects tout seul : j'ai besoin de compétences extérieures pour les aspects graphiques, sonores, les traductions… Mais l'envie est là : être le seul maître à bord du bateau pirate !

L'envie de faire un jeu

Le premier programme de ma vie c'était un jeu sur Thomson TO7 : un Canadair qui devait éteindre un incendie ! Ensuite j'en ai fait bien d'autres mais aucun publié, pas même sur Hebdogiciel…

En tant que joueur aussi bien qu'en tant que développeur les jeux m'ont toujours intéressé. Je ne vais pas lister ici les jeux qui m'ont marqué, j'invite le lecteur à consulter l'article précédemment publié pour cela. Vers la fin de mon doctorat j'avais postulé pour un grand studio de création de jeux vidéos sur Paris. J'ai stoppé le processus en constatant que l'approche de cette entreprise ne correspondait pas à la mienne...

L'histoire

Je vais présenter ici l'histoire de la création de Novae. Ou plutôt une histoire, celle de la création de jeu à partir d'une idée originale.

Chronologie

Lors de la rédaction de cette présentation (début Septembre 2013), Novae est déjà disponible sur l'App Store depuis quelques mois déjà, le mois de mai exactement. Il est ainsi possible de détailler la première étape de la vie de Novae, de l'idée originelle à sa naissance, la publication effective sur l'App Store, le 14 mai 2013.

Chronologie de la création de Novae : septembre 2012 à mai 2013

J'emploie le terme première étape car la publication d'un logiciel n'est pas une fin en soit : ce n'est en fait que le début de l'aventure. Viennent ensuite les mises à jour pour des questions de maintenance ou bien d'évolution des fonctionnalités.

Septembre 2012

Je situe l'apparition de l'idée originelle à la mi-septembre 2012. Je vais revenir par la suite sur cette idée qui va être en fait le cœur de cette présentation.

Octobre 2012

En cette fin du mois d'Octobre je décide de me lancer dans la création d'un jeu. J'ai une idée de départ solide complétant ainsi l'envie et la motivation. Et depuis quelques mois déjà je ne recherche plus des contrats pour mon entreprise afin de me libérer du temps.

Je vais donc me lancer dans l'aventure en investissant plusieurs mois dans la création de ce jeu. Pour le financement j'ai conservé une activité dans le domaine de l'enseignement qui me permet d'avoir de modestes revenus. Pour le reste c'est de l'auto-financement.

Bien évidemment à ce moment je ne sais pas combien de temps va me prendre le développement du jeu. Je décide de poser le fil rouge suivant : je m'accorde le temps et les moyens nécessaires pour travailler en qualité et en prenant du plaisir.

L'idée

L'idée originelle se résume en peu de mots : gravité centrale. Des pions déposés par le joueur sont attirés par un Centre.

Un peu d'archéologie : la première trace du concept de jeu dans mes notes.

Première apparition de cette notion dans mon carnet de notes

Il me paraît important de préciser deux points dès maintenant :

  1. j'ai souhaité partir sur une idée originale et non pas à reproduire un existant.
  2. les termes employés ici pour décrire le jeu et ses règles sont concis et précis. Or pour remettre les choses dans le bon ordre ces termes n'existaient pas au début du processus de création. Il y a quasiment un an de cela, je nageais en plein brouillard : tout était sous forme brumeuse et vaporeuse. Les dénominations précises ont été déterminées essentiellement lors des étapes de conception et de marketing; lors de la conception il est en effet primordial de donner le nom juste aux concepts et objets définis afin d'y voir clair et, pour l'étape de marketing, il est nécessaire d'avoir des mots simples et percutants.

Des pions déposés par le joueur sont attirés par un Centre. Dès ce premier croquis les pions sont déposés sur l'un des 4 axes et cela restera ainsi : le joueur peut déposer les pions sur l'un de ces 4 points d’entrée. Plus tard, lors des premiers tests, il apparaîtra qu'avoir plusieurs points d’entrée permet de donner plus de choix au joueur pour poser le pion.

Le concept de jeu original : des pions sont attirés par un Centre.

Autre point de départ, chaque pion a un type, représenté par des couleurs différentes sur l'exemple ci-dessous.

Le concept de jeu original : des pions sont attirés par un Centre.

Les pions sont attirés par le Centre dans un mouvement de rotation horaire jusqu’à ce que leur progression stoppe.

  • Loi 1 : Les pions sont constamment attirés par le Centre
  • Loi 2 : Les pions ne changent de position que pour se rapprocher du Centre

Les règles ainsi définies sont : Lâché, Placement, Suppression et Réarrangement.

Mais il en manque une : la Correspondance, c'est à dire dans quel cas un groupe de pions doit être supprimé. À ce moment là du projet je n'ai pas d'idée arrêtée pour cela.
C'est gênant pour le jeu mais cela ne me bloque par pour le moment dans le développement : il y a déjà beaucoup de choses à faire avant d'être ennuyé par ce point !

En parlant de développement, avant d'aller plus en avant dans ce processus il convient de se poser la question essentielle : est-ce que le concept de base est bon ?
Les règles sont elles trop simples ? Ou bien trop compliquées ? Le jeu est il prenant ? Intéressant ? Attrayant ? Bof ? Ou bien Amazing !

Il est important de savoir cela avant de se lancer à fond dans le projet. Mais comment faire ? Comment évaluer ces points ?

S'il existe une formule mathématique qui donne un tel résultat je ne la connais pas ! S'il existe des livres qui permettent de déterminer cela je ne les ai pas lu ! La seule méthode que j'ai en tête est d'effectuer un test en condition réelle auprès de plusieurs personnes : pouvoir jouer au jeu sur iPhone avec l'iPhone dans la main !

Et pour cela j'ai besoin d'un prototype, d'une maquette.

La maquette

Cette maquette doit donc permettre de tester le jeu en conditions réelles. Pour cela : - les régles de jeu doivent être complètes - l'IHM doit être suffisante pour jouer, c'est à dire : - affichage des composants du jeu - gestion des actions de l'utilisateur - la maquette doit tourner sur iPhone

2 maquettes

Je ne suis pas suffisamment familier avec le développement sous iOS pour créer naturellement une maquette du jeu sur iPhone. Aussi il m'apparaît judicieux de scinder cette maquette en deux afin de ne pas mélanger les choses : validation d'un concept et apprentissage d'une technologie.
La première maquette sera ainsi faite dans le langage informatique que je connais le mieux, l'Ada : appelons cette première maquette maquette Ada et la seconde maquette iOS.

La maquette Ada va me permettre de mettre en œuvre immédiatement les règles connues et de les valider. Puis elle m'aidera à déterminer la règle manquante, celle de Correspondance. Ensuite lorsqu'elle sera terminée alors je passerai à la maquette iOS.

Un avantage supplémentaire de ce découpage, en plus d'une mise en œuvre immédiate de la maquette Ada, est qu'il me laisse le temps pour aller plus loin dans l'apprentissage de l'environnement iOS et murir ma réflexion sur le choix des technologies iOS à employer.

Est-ce du temps perdu ? Non. C'est reculer pour mieux sauter !

  • D'une part une fois les règles validées puis testées alors il n'y aura plus qu'à les porter en Objective-C. Ensuite, les algorithmes mis en œuvre pour la maquette Ada seront repris pour la maquette iOS : c'est l'avantage des algorithmes, d'être indépendant du langage !
  • D'autre part le langage Ada est un langage Orienté Objet ce qui signifie que le modèle que je vais définir pour la maquette Ada, modèle au sens MVC sera une ébauche avancée du modèle final implémenté par la maquette iOS.

La maquette Ada étant finalisée il restera à mettre en place également l'IHM dans la maquette iOS :

  • affichage des composants du jeu
  • gestion des actions de l'utilisateur

Chronologie de la création de Novae : septembre 2012 à mai 2013

Le développement de la maquette Ada a débuté le 27 Octobre - date de la création de la première ligne de code.
Au 5 décembre le premier cycle de jeu complet est en place : Lâché, Placement, Correspondance, Suppression et Réarrangement.

Et le 1er janvier 2013 (eh oui !) les règles du jeu sont validées via la maquette Ada, c'est à dire qu'elles sont entièrement couvertes par les tests et testées : le développement de la maquette iOS peut commencer.

Si vous revenez une ligne au dessus, vous constaterez que la règle de Correspondance est en place : durant le développement de la maquette Ada j'ai effectivement pu étudier quelques pistes, les mettre en œuvre pour les tester dans la maquette avant d'en retenir une.

La règle manquante : la correspondance

Le problème : quand un groupe de pions doit-il être supprimé ?

Tout d'abord il est acquit que les pions d'un groupe supprimable doivent être de même type, de même couleur. Ensuite les pions appartiennent à ce groupe lorsqu'ils sont adjacents par un de leur 4 côtés.

Symétrie

Puisque le jeu possède un Centre alors j'ai tout d'abord essayé de jouer sur cette aspect symétrie par rapport au Centre :

  • un groupe est supprimé dès lors qu'il présente une symétrie par rapport au Centre.

Le principe est présenté sur l'animation suivante où les groupes successivement affichés sont supprimables :

La règle manquante : Symétrie

Je n'ai pas retenu cette solution qui me semblait trop compliquée pour le joueur et qui ne me plaisait pas de toute façon !

Formes particulières

Ensuite je me suis intéressé à la forme des groupes :

  • le joueur tente de constituer des groupes de formes particulières.

Le principe est présenté sur l'animation suivante avec plusieurs exemples de groupes :

La règle manquante : Formes particulières

Et puis tant qu'à être dans le domaine des jeux vidéos pourquoi ne pas utiliser des formes connues dudit domaine ?

Exemple

Une idée amusante : la reconnaissance de formes de grands classiques de jeux vidéos : les envahisseurs de Space Invaders et les fantômes du Pac Man.

Bon, passé le moment d'amusement cela s'avère difficilement réalisable. Ces formes sont complexes et sont composées de nombreux pions : tout cela rendrait le jeu difficilement jouable voir injouable. Sans compter l'aspect droits d'auteur…

Il y a tout de même plus simple comme formes classiques utilisées dans les jeux vidéos : les tétrominos de Tetris.

Les tétraminos popularisés par le jeu Tetris

wikipedia par Anypodetos

Voir un peu plus compliqué avec les Pentaminos :

Les pentaminos : la forme "supérieure" des tétraminos de Tetris

wikipedia par R. A. Nonenmacher

Je fais quelques essais sur papier mais ne vais guère plus loin : l'idée est amusante, un bon clin d'œil à l'univers des jeux vidéos mais je ne suis pas emballé.

Et puis…

Un beau matin toutes ces idées se condensent pour former ce qui sera la règle finale. Examinons cela !

Nous avons les 3 notions suivantes :

  1. Groupe de pions
  2. Symétrie par rapport au Centre
  3. Forme et cardinal (le nombre de pions)

Avec du recul je comprends ce qui ne me plaisait pas dans les points 2 et 3. Respectivement c'est les notions de "symétrie" et celle de "forme à détecter" qui complexifiaient le jeu. En supprimant ces 2 notions l'on parvient à :

  1. Groupe de pions
  2. Centre
  3. Nombre de pions du groupe

Et exprimé autrement : groupe de pions de taille minimale au contact du Centre. Tada !

La règle manquante : Version définitive

Un groupe de pions est supprimable si et seulement si :
  1. il se compose d’au moins 4 pions de même couleur,
  2. au moins 1 de ses pions est en contact avec le Centre

Ça s'est passé comme ça ! Avec le recul la genèse de cette règle m'apparaît comme très intéressante !
Pour information, la valeur minimale (4) est totalement arbitraire et n'a pas changé depuis pour être celle utilisée par la version courante de Novae !

La première maquette

La maquette Ada terminée il ne me faudra que 2 semaines pour la réalisation de la maquette iOS. Qui apportera une IHM minimale : affichage des composantes du jeu et gestion des actions utilisateurs.
Il est important de souligner le peu de temps nécessaire à la réalisation de la maquette iOS en considérant que je ne suis encore qu'un débutant en développement iOS. Avec plus d'expérience cela n'aurait pris qu'une poignée de jours. Cela souligne l'importance des étapes amont du développement informatique : analyse et conception.

Chronologie : première maquette

J'utilise les services proposés par TestFlight pour diffuser cette maquette auprès de quelques testeurs. Voici une vidéo présentant cette version de Novae dont le nom de code à l'époque est Rubber Soul...

Novae - Première maquette jouable from Dominique Vial on Vimeo.

Évolutions

Concernant les règles du jeu même il y aura deux évolutions importantes :

  1. l'affichage du pion suivant pour augmenter l'aspect stratégie,
  2. l'ajout de la notion de niveau d'énergie pour améliorer le Game Play en apportant une difficulté progressive.

Le reste des évolutions concerne :

  • l'ajout de fonctionnalités autour de l'écran du jeu lui-même : score et statistiques, aide, information et la navigation entre tout cela,
  • le design visuel et sonore,
  • l'ajout d'un mécanisme de récompense pour des situations particulières : meilleur score battu, grille vidée…
  • la connexion au Game Center

Voici un récapitulatif de ces évolutions.

Première maquette

Première maquette jouable sur iPhone : pas de score, pas de détection de fin de partie. Du brut de décoffrage !" title="Première maquette jouable sur iPhone

C'est la toute première version envoyée et il n'y a aucun score. Les testeurs réclament un score ! Et la fin de partie n'est pas détectée automatiquement !

Gestion du score

Gestion du score + détection automatique de fin de partie

Le mécanisme de gestion de score est intégré ainsi que la détection automatique de la fin d'une partie. Afin de pousser les testeurs à y jouer j'ai rajouté le meilleur score en dessous du score courant : imparable !

Intégration du coup suivant

Intégration du coup suivant

L'ajout de l'affichage du pion suivant permet d'augmenter la stratégie du jeu : le joueur peut poser le pion courant en fonction de ce pion suivant.

Passage au noir

Passage en fond noir avec une galaxie en rotation

Je commence à avoir une idée précise de l'univers esthétique du jeu : ambiance spatiale (voir l'article Chronique de la création d'un jeu sur iOS).
Le jeu passe donc en fond noir : tollé de la part des testeurs !
J'y ajoute une image de galaxie qui tourne très lentement dans le sens horaire afin d'aider le joueur à percevoir le sens de rotation des pions.

Pions ronds

Les pions sont ronds désormais

Les déplacements des formes carrées comme il y avait précédemment me gênaient beaucoup au niveau visuel : passage donc à des pions ronds !

Autre ajout important : la notion d'énergie. Il s'agit d'apporter une aide au joueur sous forme de bonus. L'énergie apporte 4 niveaux de bonus : - 1 à 3 : permet de sauter le pion courant s'il ne convient pas, - 4 : permet de supprimer tous les pions d'un coup.

Jouer les bonus 1 à 3 diminue le niveau de bonus de 1.
Jouer le bonus 4 ramène ce niveau de bonus à 0.

Paliers d'énergie

Ajout de l'énergie

Les testeurs n'accrochent pas au système d'énergie mis en place précédemment : moi non plus. J'essaie donc de remédier à cela en affichant à l'écran les paliers d'énergie ce qui est censé augmenter l'aspect stratégie du jeu...

v1.0

v1.0 : la première version publiée !

Aucun testeur n'accroche à ce système d'énergie aussi je le simplifie : plus de bonus à activer mais un seul bonus activé automatiquement lorsque le niveau maximum d'énergie est atteint.
Cette version voit l'intégration de l'habillage graphique : la galaxie en rotation est supprimée et est remplacée par un champ d'étoiles minimaliste et fixe.

Au fait : c'est la première version publiée sur l'App Store.

v1.1

v1.1 : ajout du mode daltonien

Ajout du mode daltonien qui était prévu dès le début du jeu. J'ai été sensibilisé depuis mes premières années d'étude en école d'ingénieur aux soucis d'accessibilité.

v1.2

v1.2 : version universelle

Cette version apporte l'universalité à Novae : l'application est optimisée pour les iPhone et l'iPad soit 3 dimensions d'écran différentes.
J'en profite pour apporter un changement minime au niveau du pion suivant : diminution de sa taille suite à des remarques d'utilisateurs qui confondaient le pion courant et le pion suivant.

Les choix techniques

Dans cette dernière partie je vais présenter les choix techniques effectués pour Novae et leurs raisons.

Développement multiplateforme

Dès le début du projet l'objectif est un développement pour iOS. J'ai toutefois considéré la possibilité de porter Novae pour les autres plateformes : Android, Windows Phone...

Pour un développement multiplateforme une des solutions est de programmer l'application dans un langage "intermédiaire" afin de générer l'application finale pour les plateformes désirées : coder une fois, exécuter partout… Je vais être direct : je déteste cette méthode ! D'une part je ne l'ai jamais constaté efficace quand au résultat final; d'autre part elle complexifie et alourdit la chaîne de développement logiciel.

Mon expérience de développeur m'indique que la meilleure méthode est basée sur une analyse et une conception irréprochable qu'il "suffit" de porter sur la plateforme cible. Le développement de Novae en est la preuve puisqu'une fois la conception validée — par la maquette Ada — le portage sous iOS n'a nécessité que quelques jours.

Donc ce sera du développement natif : Objective-C + Xcode pour iOS. Si dans le futur je décide de porter Novae sous d'autres plateformes alors je ferai appel aux compétences extérieures requises en leur fournissant l'ensemble de la conception et l'ensemble des ressources rédactionnelles, visuelles et sonores.

Framework de jeu vidéo

Dès les premiers jours du projet j'ai acheté le livre de Michael Delay Learning iOS Game Programming afin de suivre un exemple de création d'un jeu sous iOS.
Puis au moment de la partie maquette Ada je me suis intéressé aux moteurs de jeux vidéos sur iOS qui pouvaient me permettre de gagner du temps en développement en ne réinventant pas la roue. Une première recherche m'a permis d'en isoler trois en particulier : Cocos 2D, Kobold 2D et Sparrow. J'ai installé et testé Cocos 2D qui est utilisé sur les tutoriaux du site Ray Wenderlich que je fréquente assidument.

De ces recherches j'en ai conclu que je n'avais pas besoin de tels outils pour la réalisation de Novae. Tant mieux car je ne souhaitais pas rajouter une ligne supplémentaire dans la déjà longue liste des choses à apprendre !

Techniques iOS

Concernant les techniques spécifiques à l'environnement de développement je choisis les 3 suivantes : ARC, Storyboard et AutoLayout.

ARC

ARC permet de simplifier pour le développeur une partie très délicate : la gestion de la mémoire. Par expérience je suis sceptique sur des techniques présentées comme simplifiant très fortement des choses ardues : souvent un bel enrobage marketing pour un résultat très décevant. Pour ARC j'ai ainsi pris le temps de lire beaucoup d'articles sur le sujet et puis aussi de tester cela par moi même sur différents prototypes afin de m'en faire ma propre opinion. J'ai été convaincu et ai décidé de l'utiliser pour ce jeu.

Outre la simplification de développement j'avoue que j'ai très envie d'utiliser cette technique par simple curiosité !

StoryBoard

Cette fonctionnalité permet de décrire via une interface graphique les différents écrans composant l'interface d'une application. Là encore j'ai envie de me confronter à cet outil par simple curiosité. Je ne suis pas friand des surcouches graphiques qui, encore une fois, sous prétexte de me simplifier la tâche en m'éloignant du code, se révèle souvent décevante lors de leur mise en œuvre. J'ai envie de voir ce que propose Apple !
Pour CoachMyRide j'ai fais cela à la main, sans aucune interface graphique. Pour Novae je suis parti avec StoryBoard.

Avec le recul, j'ai beaucoup apprécié cet outil que j'appréhendais un peu par son côté "simplification des choses". Au début je l'ai utilisé pour placer les éléments graphiques de l'interface de manière définitive. Le code évoluant, il m'a été nécessaire de modifier le positionnement de la plupart de ces éléments directement dans le code. Par exemple pour les animations ou bien l'adaptation pour les différentes tailles d'écran.
Cette évolution a transformé mon utilisation de StoryBoard qui est devenu une sorte de carnet sur lequel je note désormais des idées auxquelles je donne vie et forme dans le code source.

AutoLayout

Enfin c'est également avec les mêmes envies que pour StoryBoard que j'inclus AutoLayout, cet outil apparu avec iOS 6 qui permet de simplifier l'adaptation automatique du design de l'application en fonction de différentes tailles d'écran mais aussi de différentes langues.

Et c'est cette dernière qui m'a donné le plus de fil à retordre : il m'en aura fallu du temps avant d'en comprendre la philosophie et de la dompter un minimum !

Graphismes et sons

Pour les graphismes j'utilise une brique de base d'iOS, UIView, qui permet de gérer l'affichage d'une image à l'écran via une Vue. Hormis l'écran d'accueil et le fond étoilé du jeu, tous les graphismes sont vectoriels. Chaque élément visuel est ainsi calculé par la machine au moment de son rendu. Cette technique a pour avantage de rentre les images indépendantes de leur taille et de la résolution de l'écran. Les graphismes vectoriels sont édités avec l'outil PaintCode qui permet leur export sous forme de code Objective-C. Le graphiste crée les éléments visuels via un outil d'édition vectoriel et je les importe dans PaintCode via le format SVG. Puis je les modifie si nécessaire et les exporte enfin sous forme de code Objective-C directement dans le projet.

Pour l'animation de ces graphismes je me suis renseigné sur OpenGL pour au final ne pas l'utiliser et rester sur là encore une brique de base d'iOS : CoreAnimation.

Quand à la gestion du son j'ai utilisé ObjectAL : aucun soucis à signaler !

Enfin, je souhaite évoquer l'outil Spark Inspector intégré très tardivement au projet qui permet d'étudier très facilement ces Vues. Grâce à lui j'ai trouvé très rapidement la cause d'un très léger accroc visuel sur le jeu.

Décomposition de l'écran de jeu par Spark Inspector

Gestion des évènements

Cet article touche à sa fin mais je ne saurai le terminer sans mentionner la gestion des évènements.
Novae est un jeu à l'apparente simplicité qui pourtant révèle une complexité importante au niveau des évènements. Lorsque le joueur lâche un pion, cette simple action déclenche une série d'évènements comme vue plus haut : Lâché, Placement, Correspondance, Suppression, Réarrangement.
Chacune de ces étapes comporte de nombreux traitements logiques, application des règles de jeu, et esthétiques : animations et lecture de sons.

Les interactions entre tous ces traitements sont difficiles à prévoir car elles dépendent de nombreux paramètres. Par exemple le placement d'un pion n'est pas le même selon le parcours que doit faire faire ce pion, s'il est immédiatement placé ou bien s'il doit un peut tourner pour trouver sa position finale. Autre exemple, le réarrangement après l'absorption d'un groupe de pions peut impliquer un nombre indéterminé de pions, nombre qui peut devenir important.

En cours du développement cette complexité devenant difficile à gérer je me suis mis à la recherche de solution pour en faciliter la gestion. J'ai tout d'abord considéré l'emploi d'UML pour modéliser cette situation. Cela n'a pas été convaincant. Puis me sont apparus les Réseaux de Pétri, une matière que j'avais adoré durant mes études. Les premiers schémas ont été encourageants aussi j'ai poursuivi et me suis mis à la recherche d'un moyen de formaliser cela au niveau informatique. OmniGraffle est mon outil de prédilection pour cela mais dans ce cas particulier il ne convenait pas car pas adapté. Aussi j'ai cherché autre chose avant de tomber sur Tina, un outil de recherche édité par le LAAS qui m'a permit de parvenir à mes fins : maîtriser cette complexité.

Avec Tina on peut non seulement formaliser ces suites d'évènements sous forme de Réseau de Pétri mais également simuler ce dernier afin de détecter d'éventuels problèmes.
L'implémentation du Réseau de Pétri n'a pas posé de problèmes particuliers. J'ai dû réécrire une bonne partie du code du gestionnaire de jeu et du code de la gestion des animations.

Le jeu en valait la chandelle : l'objectif fixé de la simplification de la gestion des événements a été atteint ce qui ouvre par là même de nombreuses perspectives d'évolutions...

Fin

Lors de la présentation, les échanges que je ne détaille pas ici, ont porté essentiellement sur l'aspect marketing du projet : la communication promotionnelle et le modèle économique sur l'App Store.

Pour conclure, quelques mots sur les résultats de ce projet après environ 5 mois d'exploitation. Les ventes ne sont pas importantes : l'investissement initial est ainsi loin d'être amorti et l'objectif de vivre de la vente de mes créations bien loin d'être atteint. Pour le moment !

Merci d'avoir lu cet article.

Dominique


Références bibliographiques

Ressources Logicielles


Cette publication et son contenu sont mis à disposition selon les termes de la Licence Creative Commons Attribution - Partage dans les Mêmes Conditions 4.0 International. Des droits spécifiques peuvent s'appliquer à certains contenus et sont alors indiqués.