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.