Mon petit préféré ...


Paco a l'art de venir toujours les embêter donc il a eu le droit à sa petite photo lui aussi :)






J'avais emmené mon appareil photo histoire de m'entraîner. C'est pas encore ça (j'ai l'impression que toutes mes photos sont floues T__T).
Ce que j'arrive le mieux (à mon sens) à photographier, ce sont les fleurs.













Ça change tellement du décor parisien.. C'est reposant !




Enfin, sans compter sur nos petits monstres pour courir, hurler, et j'en passe :p


J'adore cette photo >.< Elle est trop photogénique Maymay !



J'ai été faire un tour dans la piscine mais heureusement personne n'a immortalisé ça :p




Et ça fait les fous, comme d'habitude !



Les deux copines <3


Fortnite a touché tout le monde, à l'aide !!!






Si, même les adultes commencent à faire des âneries on est pas sorti de l'auberge !




A bientôt pour la suite !

Conférence au Game Camp 2018 par Diane Landais & Miryam Houali de Accidental Queens.

L'histoire d'Accidental Queens a commencé à la Global Game Jam de 2016 où ils ont développé le jeu "A Normal Lost Phone" en l'espace de 48 heures.

Après sa mise en ligne, ils ont très vite eu énormément de retours avec notamment des articles de blog.

Ils se sont alors demandé : Qu'est ce qu'on va faire de ce projet ?

Et si on faisait un vrai jeu et une vraie boîte ?

Ils ont commencé par faire une campagne Ulule. (Pourquoi ne pas avoir choisi Kickstarter ou Indiegogo ? Parce qu'Ulule est international).

Ils ont obtenu ce qu'ils voulaient et ont ensuite signés avec Plug In Digital.

Ça a été un gros chantier notamment avec la musique car pleins d'artistes ont participés à la bande son. Ils ont du travailler leur communication et se fixer des deadlines grâce à pleins de petits événements.

"A Normal Lost Phone" est ainsi sorti sur PC, MAC et mobile. Ils ont eu pleins de reviews positives et, grâce aux fonds propres de la ventre de leur jeu et d'Ulule, aux subventions ainsi qu'aux soutiens ils ont pu créer officiellement leur boîte "Accidental Queen".

Ils ont voulu transformer l'essai en sortant un deuxième jeu "Another Lost Phone" qui est en fait une suite de leur premier jeu car comme ça ils peuvent reprendre du code de leur précédent jeu.

Pour le financer ils ont cherchés du côté de Pictanovo, un équivalent au SNC version nord.

Sur ce nouveau jeu, ils ont rencontrés quelques soucis, notamment niveau traduction et communication mais également niveau timing. Le jeu n'était pas fini fini dans les temps.

Mais le 21 septembre, le jeu a fini par sortir, à l'heure prévue ! Plus de peurs que de mal !

Pourquoi avoir fait une suite et pas un nouveau jeu ?

Cela permettait :

• De corriger ce qui n'allait pas dans le premier jeu
• De renforcer le positif
• De délivrer un nouveau message (comme c'est un jeu narratif)
• D'avoir un temps de développement plus court et donc moins cher 

Ce qu'ils attendaient VS ce qu'ils ont eu :

• Corriger les erreurs => ils en ont fait des nouvelles
• Production peu coûteuse => oui mais avec à cause du rush ils ont eu des soucis de management
• Enrichir "Accidental Queen" => oui mais du coup maintenant leur studio est catalogué "studio qui fait des Lost Phone"

Ils ont porté le jeu sur Switch ce qui leur a été très bénéfique.

Pourquoi avoir créé un studio ?

Ils ont une démarche créative et ils voulaient faire des jeux qui se veulent inclusif, engagés et accessible. L'entreprise était le meilleur moyen de mener a bien cette démarche créative auprès d'un large public.

Pour eux sortir un jeu à 60€ c'était inconcevable.

Ce côté engagé ils l'ont mis en place dès le début de la production en définissant les enjeux / guidelines du projet. Ils ont ensuite parlé avec des associations et des professionnels de leurs enjeux.

Grâce à des tests ils ont pu savoir si leur message avait été compris quelque soit le joueur afin d'être sûr que ce serait accessible pour tous et pas que le public cible.
Il fallait également vérifier que le jeu reste qu'un jeu.

Comment se sont-ils organisés ?

Travailler à distance avec une équipe multilingue c'est cool, notamment avec des outils comme Slack ou Trello, etc... Par contre la barrière de la langue est réelle, des personnes de l'équipe peuvent se sentir exclus, les personnes à distance peuvent avoir ce ressenti ou encore les étudiants qui bosse sur le jeu en tant qu'hobby et ne veulent pas réellement se mettre à fond dedans.

Avoir plusieurs rôles / responsabilités au sein d'une entreprise c'est chouette mais c'est également une très grosse responsabilité car tout repose sur nous.

Travailler avec des freelance c'est cool, en plus on peut travailler avec des profils atypiques/sympas mais ils ne sont pas toujours disponibles et surtout cela nécessite de bien les briefer (ils ne sont pas dans notre tête).

Au début ils pensaient faire 10% de gestion de l'entreprise et 90% de création de jeux mais au final, e entre la recherche de financement, les événements etc... on se retrouve plus à faire du 50/50 si on a de la chance.

Côté business

• Combien de copies vendus ?

Alors, avec ou sans les soldes ?

• Combien en break even ?

Ok mais avec ou sans les salaires ?

• Combien d'argent généré ?

Pour qui ? Le distributeur ?


Leurs jeux sont vendus à peu près 3€, ils ont défini ce montant en se basant sur "1h de jeu = 1€".

Pourquoi avoir fait le même prix sur Steam et sur mobile alors que d'habitude Steam est plus cher ? Car cela leur permettait de rester dans les listes des jeux à moins de 5€.

Ils ont lancés une promotion d'une semaine (de -97% soit 10 centimes) sur le store d'Android. Ca leur a permis d'avoir un vrai impact et de bénéficier de la mise en avant Android. Un vrai succès !


Comme beaucoup de start-up quand ils ont lancés leur entreprise il ne pouvait pas se donner de salaire. Mais entre le temps que chacun veut bien donner au projet et les services gratuits dont ils bénéficient et bien ça compte dans la compta finale (les cadeaux il faut rendre la pareille un jour où l'autre).

Les dépenses s’étendent même après la sortie du jeu, entre le production, la communication, la gestion de bug, etc...

Est ce que le nombre de copies vendues peut définir l'argent généré qui lui même peut définir le succès de notre jeu ?
Pour eux : non. Il fallait aussi voir si ils avaient réussi leurs enjeux, si ils avaient pris du plaisir, etc...

Ils ont vendu entre 150 000 et 250 000 copies.
Ils ont rapidement été "break even" et ils ont générés suffisamment d'argent pour survivre mais pas assez pour financer une production complète.

Ils ont tout de même survécu a leurs deux premières productions et tout ça en seulement 1 an et 2 mois.

La production de Another Lost Phone n'a durée que 4 mois (c'est très court) mais c'est une suite.
Avec une meilleure gestion de projet ils auraient pu éviter de faire des heures supplémentaires, de s'asseoir sur leurs weekend, de finir à plus de minuit. En évitant ces soucis ils auraient également pu éviter bon nombre de problèmes internes humains (car ils auraient été dans un meilleur état émotionnel).

Il faut faire attention aux conditions de travail que tu es envie de bosser, que tu fasses pas de Burnout.

Et il faut penser à l'après jeu, quand il sort, que la pression retombe et que toi tu te prend deux semaines de vacances pour aller mieux.

Quelles ont été leurs inspirations ?

• Life is Strange
• Her story
• Analog

Conférence au Game Camp 2018 par Olivier Penot de Seaven Studio / Plug In Digital.

Pourquoi on foire ?

Il y a 2 façons monumentales de foirer son lancement console :

1. Un problème technique entraînant le retard voire l'annulation de la sortie du jeu.
2. Un problème marketing, votre jeu est bel et bien sorti mais personne n'est au courant.

Pourquoi c'est long ?

Lancer un jeu c'est très long.

• Il faut soumettre son jeu sur chaque console/région (on appellera ça un sku). 
• Les différente sites sont incompréhensibles
• Vous devez obtenir les pegi version française et anglaise du jeu (sachant que ça prend plus de 3 semaines). Attention à ne pas essayer d'anticiper le pegi que vous obtiendrez car generalement vous vous tromperez.
• Dans les trailers soyez vigilant sur l'écriture des plateformes. Exemple : PlayStation s'écrit Playstation®.
• Regardez bien les différentes demandes de la part des consoles. Exemple : Sony US demande pour chacune des citations présentes dans votre trailer une autorisation de la personne citée.
• Pensez à bien connaître la console. Exemple pour un jeu sur Switch on connaît le Pro controller.
• Quand vous faites un tweet, vous pouvez prévenir le constructeur console, avec un peu de chance il relayera votre tweet.
• Toujours lire les docs même si elles sont incompréhensibles.
• Sur Xbox, pensez aux achievements, ils sont super importants, et à Mixer (un équivalent de Twitch).
• Pensez à la vignette (artwork) de votre jeu. Il faut qu'en le voyant on comprenne sur quoi va porter notre jeu et qu'il soit facilement repérable lorsqu'il sera sur les stores.

Des conseils marketing sont disponibles sur le site de Microsoft.

Le mieux, c'est de sortir son jeu dans le plus d'endroits possibles. Notamment dans le PS One, le PS Plus et le Game Pass.

Il faut toujours réfléchir à la date de lancement et regarder les jeux qui vont sortir au même moment. Ce serait bête de perdre la vedette.

On arrive sur une période un peu charnière car la Switch baisse, et la Xbox One + PS4 vont être remplacé par les nouvelles. C'est donc pas le meilleur moment pour lancer des jeux consoles indépendant.

Questions / Réponses

Est ce que ça vaut le coup d'aller sur PS4 et Xbox One ? 

Ça dépend du coût de développement. Ca peut être rentable sur Xbox One mais sur PS4 il vaut mieux avoir un deal car c'est de moins en moins rentable.


Les ventes des jeux indes sur Switch ? 

C'est la Switch qui obtient les meilleurs revenus mais ça diminue avec le temps. Pour le moment ça reste assez intéressant car c'est assez facile de porter son jeu sur Switch.

Au niveau du type de joueurs, on retrouve sur la Switch :

• Des core gamers aux USA
• Des mid gamers en Europe
• Une console pour toute la famille au Japon (avec notamment des comptes enfants)

Des jeux de gestion / stratégie (donc adieu les contrôle à la manette) c'est portable sur console ?

Il faut regarder en fonction du nombre de vente, les avis etc... Pour définir si ça peut être intéressant.

Conférence au Game Camp 2018 par Marion Not de Ubisoft Annecy.

Cette conférence parle plutôt d'un retour d'expérience sur le développement du jeu STEEP.

Marion est programmeuse gameplay chez Ubisoft depuis 2012. Auparavant elle a travaillé chez Eugen System.

L'histoire de STEEP

Ubisoft Annecy avait déjà bossé sur des jeux style Splinter cell, Assassin's Creed ou encore The Division mais STEEP a été leur tout premier jeu réalisé de A à Z au studio d'Annecy.

Durant le développement ils ont eu des moments de doutes et ont fait des erreurs mais au final ils ont appris des tas de choses.

STEEP est un jeu de sport extrême en open world.

Ils n'ont pas voulu faire un jeu d'arcade mais plutôt un jeu type open world / bac à sable pour que chaque joueur puisse avoir plusieurs expériences.
Comme à Annecy ils font du snowboard tout l'hiver ils voulaient faire une petite ode à la montagne.

Dans STEEP il y a deux types de contenu :

• Les challenges
  Ce sont des objectifs clairs, c'est compétitif et il y une boucle de gameplay fermée.
• Les missions aussi appelées "Mountain Stories"
  Le but était d'amener quelque chose plus contemplatif avec des scénarios, sans réel objectif.

Pour ces deux types, côté code ils ont fait du code totalement séparé.

Les missions

On ne va parler que des missions, pour celles-ci ils ont réutilisé l'outil "MissionEditor" de Assassin's Creed car il semblait bien s'adapter à leurs missions, mais au final :

• Aucun développeur ne connaissait l'outil
• C'est un outil très très très gros
• L'outil n'a pas été pensé pour des Level Designer il n'est pas accessible pour eux
• C'est un outil permettant de gérer plusieurs missions en même temps or, dans STEEP, ils n'ont qu'une mission à la fois, il a donc fallu modifier cet éditeur qu'ils ne connaissaient pas.

Ce que les joueurs ont dit des missions :

• "Elles ne sont pas nécessaires mais marrantes"
• "C'était bizarre"
• "Ah ça amène autre chose c'est cool"

Il n'y avait pas de rétention sur les missions et d'un autre côté les challenges manquaient un peu de narration.

Ils ont donc décidé de sortir deux DLC dont un pack de challenge scénarisés qui contenait des cinématiques, des scénarios, etc... Au final les challenges ressemblent aux missions.

Leur DLC suivant, un mode histoire, leur a fait rajouter pleins de choses à l'éditeur de missions.

C'était leur 3ème DLC en 1 an.

Post mortem

Après 1 an de vie, quelle est la situation ?

C'est difficile, l'éditeur de missions est linéaire or les missions de STEEP ne le sont pas.
Ils ont fait énormément de code jetable / spaghetti car à chaque problème ils codaient une solution au lieu de trouver des solutions à plusieurs problèmes en même temps.
Les challenges ont commencés à converger vers les missions mais ils ne pouvaient pas réutiliser du code car ils étaient partis sur deux bases totalement différentes. Ils ont donc dû tout dupliquer.

Conclusion

• Il faut maîtriser sa dette technique. Les développeurs vont souvent demander à faire des refacto, et des fois il faut les écouter. Car un code qui devrait prendre 2 jours, fini par prendre 2 semaines dans du code pas adapté.
• Il faut savoir abandonner une solution technique. Dans leur cas, est-ce qu'ils ont bien fait d'utiliser le "MissionEditor" ?
• Vous devez penser votre jeu comme un tout. Dans STEEP ils n'auraient jamais dû dé-corréler les missions et les challenges. Il faut essayer de faire un seul jeu.
• Les développeurs doivent anticiper leurs features pour voir ce qu'ils peuvent utiliser comme base commune.
• Il ne faut pas oublier les designers et essayer d'anticiper leurs besoins afin de pouvoir leur fournir les outils nécessaires (avec une interface user friendly).
• Suivre la production et prendre le temps de s'asseoir derrière un Game Designer pendant une heure pour regarder comment il utilise vos outils et le temps que lui prenne chaque tâche vous permettra d'apprendre énormément et de vous rendre compte que vos outils ne sont pas utilisés de la même manière qu'ils ont été conçus. 

Conférence au Game Camp 2018 par Nicolas Cannasse de Shiro Games.

Son parcours

Co-fondateur à l'origine du studio Motion Twin, il a en 2005 crée la technologie open source Haxe et Haxe Foundation, qu'il utilise depuis sur l'ensemble de ses projets.

Il a quitté Motion Twin afin de créer Shiro Games.

Il a essayé de réunir des profils différents, car il existe différents types de développeurs.

Par exemple, si vous donnez une boîte avec pleins de boutons à un développeur :

• l'artiste va commencer par appuyer sur un bouton et regarder ce qu'il se passe. Il va ensuite essayer de comprendre ce que fait la boîte dans le but ultime de s'en servir et pourquoi pas de la dépasser.
• l'ingénieur va aussi expérimenter mais il va directement essayé de comprendre le fonctionnement, puis il va la démonter dans le but ultime de l'améliorer.

Dans une équipe vous avez besoin à la fois d'artistes et d'ingénieurs.

L'importance des outils dans un studio

Elle est vitale car :

• Il y a peut-être de bonnes idées de jeu mais si à la fin on n'arrive pas à exécuter nos idées correctement, l'idée ne vaudra rien. Les outils vont aider à l'exécution des idées.
  Exemple : pour monter un meuble Ikea, si vous avez besoin d'un tournevis et que vous n'en avez pas vous ne pourrez pas continuer.
  
• Quand on développe ses propres outils, en cas de bug on maitrîse notre outil et on peut ainsi facilement corriger. On peut ajouter toutes les features que l'on souhaite.

Si actuellement vous n'avez personne pour faire des outils dans votre équipe il faudrait quelqu'un. Cela permettra à l'équipe de fonctionner de manière optimale.

Les erreurs à éviter

Quand on fait son outil il faut faire attention à ces différents points :

• On avance sur les outils au lieu d'avancer sur le jeu, et on termine par devoir faire un outil pour l'outil.
  
• On fait un outil tellement instable et rempli de bugs qu'il devient inutilisable. Quand on s'engage dans un outil il y a une certaine quantité de travail à faire pour qu'il soit utilisable.
  
• Le syndrome de l'"horrible user interface" : à force d'ajouter des features sans réflexion global on finit par avoir des trucs dans tous les sens.

L'outil doit servir le jeu et non pas l'inverse.
Il va servir d'échange entre votre gamecode/script/engine et les parties bas niveau.

Différents types d'outils

Votre outil produit des données et votre jeu les consomme.

Il faut que vos données soient orientées collaboration car vos outils doivent permettre d'éviter les aller-retour. Donc plus votre outil sera ouvert aux autres métiers (GD/LD/Dev/Art) plus votre outil sera utile.

Vos données doivent être lisibles pour voir ce que fait l'outil et pour à la fin obtenir une histoire de données. Vous pourrez ainsi merge vos données dans Git et garder un historique / backup de vos données.

Le format de données est donc très important, à Shiro Games ils utilisent le JSON.

• Les outils de runtime

Avec ces outils, il faut faire attention aux performances et ne pas hésiter à faire du cache.

Ce type d'outil n'est pas lié à un jeu, il est développé pour être utilisé quelque soit le projet.
Il devient agréable car plus on l'utilise plus on le maitrise mais il faut faire attention aux outils trop génériques.

Il vaut donc mieux partir d'abord sur un outil spécifique et ensuite, lors d'un nouveau projet, voir les différences. Si il a 25% de différences, alors il vaut mieux dupliquer l'outil et faire un spécifique au nouveau projet. Sinon vous pouvez enrechir l'outil initial.

À Shiro Games ils ont mis en place un outil open source de Static Database (Castel DB) qui permet à tout le monde de lire / d'écrire des données mais le jeu ne pourra y accéder qu'en lecture.

Les langages

Au niveau des langages il y a pour chaque partie son bon niveau de code.

Engine : C++
Outils : C#
Gamecode : C#
Contenu : Lua

A Shiro Games ils utilisent du coup leur techno, le Haxe, car c'est un langage qu'ils peuvent compiler vers des levels plus ou moins haut.

Engine : Haxe C/C++
Outils : Haxe JS
Gamecode : Haxe
Contenu : HScript

Le time to play

Le time to play c'est le temps à partir duquel je peux voir mes changements en jeu.

Pour le réduire il faut :

• Optimiser les temps de chargement
• Avoir un live reload pour les données
• Une option CTRL+S pour enregistrer l'état actuel du jeu
• Un cheatcode pour passer les menus
• Avoir une compilation rapide

Ce n'est pas spécialement le temps gagné qui est important mais c'est l'attention / le focus du développeur car quand on doit attendre qu'une tâche se termine, on va faire autre chose en attendant et on va perdre notre attention.

L'Open source

L'industrie est de plus en plus tourné vers l'Open Source mais le secteur du Jeux vidéo est encore très en retard. Pourtant l'Open source permet la modification du code, la collaboration et la compétition entre les différentes équipes.

Les conseils de la fin

• Toujours se poser les bonnes questions
• Aller voir les jeux / outils des autres pour savoir si c'est une bonne idée, les erreurs qu'il faut éviter, etc...
• Discuter de nos outils avec le plus de personnes de notre équipe
• Ne pas hésiter lorsqu'on a pris la décision de créer un outil d'aller au bout de notre idée.