La caverne d'acier

En ce moment je fais des petits tests avec Google App Engine (GAE). Pour faire simple, GAE est un environnement de développement d’applications web, ainsi que services d’hébergement des applications développées avec. En gros ça permet d’écrire une application et l’héberger avec les mêmes outils (avec quelques différences je suppose) que ceux utilisés par Google … et donc d’héberger le tout sur l’infrastructure de Google. Le tout gratuit tant que l’on ne dépasse pas certains seuils de consommation CPU, bande passante, … largement suffisant pour commencer et (je n’ai pas encore trop creusé la question) ça ne semble pas exorbitant lorsque que l’on doit commencer à payer.

Mais revenons à nos moutons … le but n’est pas d’expliquer ce qu’est GAE mais d’expliquer un cas d’utilisation.

Avec GAE on peut utiliser son propre système d’authentification (ou celui de notre framework web python/java préféré). Mais Google fournit le sien. On peut lui indiquer que tel handler (script qui s’occupe de gérer une requête/URL) ne peut être exécuté que si l’utilisateur s’est authentifié au préalable avec un compte Google. Si l’accès à cette URL se fait depuis un navigateur web, tout est déjà prévu par Google. Lorsque que le client accède à l’URL, s’il n’est pas authentifié, le navigateur est redirigé vers une page où on lui indique qu’il doit se connecter avec son compte Google pour accéder à cette ressource. Une fois l’authentification faite, le navigateur est redirigé vers l’URL d’origine.

Mais que se passe-t-il si je veux faire la même chose en dehors d’un navigateur web ? Dans un script python, ou bien dans une application iPhone par exemple ? Pour ne pas faire de mystère je n’ai pas trouvé tout seul … j’ai un peu cherché si quelqu’un ne s’était pas posé la même question que moi … et à priori je pouvais être sur que c’était déjà le cas. Bon j’ai un peu galéré pour trouver la bonne formulation à faire dans le moteur de recherche de Google mais j’ai fini par tomber sur deux postes sur stackoverflow (pour changer … très bon site, au cas où vous sortiriez d’hibernation et seriez passé à côté).

• Google App Engine with ClientLogin Interface for Objective-C
• How do you access an authenticated Google App Engine service from a (non-web) python client?

Bon je pourrais m’arrêter là car il y a (presque) tout ce qu’il faut dans ces deux postes. Pour la version en python vous pouvez aller voir directement la réponse de dalelane. Et pour la version pour iPhone (enfin Objective-C) vous pouvez directement voir cette réponse, celle de Keith Fitzgerald. Dans ces deux réponses c’est exactement la même méthode qui est utilisée, avec deux langages différents. Un autre bon exemple (en python) est d’aller voir les outils qui sont fournis dans le SDK de GAE. Dans les fichiers appcfg.py et appengine_rpc.py il y a du code qui fait ça.

Comme j’aime en rajouter, et que je suis tombé dans un piège je vais commenter la méthode à utiliser et expliquer la petite erreur qui m’a fait perdre du temps. Je vais le faire à partir de la version Objective-C, car c’est celle qui m’intéressait au final (mais la version python m’a permis de trouver mon erreur en ajoutant des logs).

Avant de commencer, j’aimerais ajouter que vous pouvez aller lire la doc suivante : “ClientLogin for Installed Applications“. ClientLogin c’est l’une des APIs d’authentification fournies par Google.

Les étapes du processus sont :

1. L’utilisateur final fournit son login et son mot de passe (je n’ai pas encore essayé mais on verra plus tard comment utiliser l’API KeyChain fournie avec Cocoa pour stocker les mots de passe).
2. L’application contacte le service de Google avec ces informations pour obtenir un token d’authentification : Auth.
3. Ensuite il faut récupérer un cookie auprès de notre application GAE. Ce cookie sera automatiquement utilisé dans la future requête HTTP que l’on fera à notre application.
4. Et pour finir on n’a plus qu’à contacter les URLs nécessitant l’authentification en leur ajoutant le token Auth comme paramètre.

Donc (après tout ce blabla) on y va.

D’abord la fonction GAEAuthenticationForUser qui va nous permettre de récupérer le fameux token d’authentification:

- (NSString*)GAEAuthenticationForUser:(NSString*)email withPassword:(NSString*)passwd forApp:(NSString*)app
{

En entrée on prend :

• l’email de l’utilisateur : login@gmail.com
• son mot de passe : 6(P;p7/s!#Fb (qu’on aura à priori récupéré grâce à l’API keychain).
• et l’identifiant de votre application GAE : si votre application est accessible ici http://myapp.appspot.com/ et bien il faut passer myapp.

	// retrieve the "Auth" key
	NSURL* authUrl = [NSURL URLWithString:@"https://www.google.com/accounts/ClientLogin"];
	NSMutableURLRequest* authRequest = [[[NSMutableURLRequest alloc] initWithURL:authUrl] autorelease];
	[authRequest setHTTPMethod:@"POST"];
	[authRequest setValue:@"application/x-www-form-urlencoded" forHTTPHeaderField:@"Content-type"];
	NSString* content = [NSString stringWithFormat:@"Email=%@&Passwd=%@&service=ah&source=%@&accountType=HOSTED_OR_GOOGLE",
		[self urlEncodeValue:email],
		[self urlEncodeValue:passwd],
		[self urlEncodeValue:app]];
	[authRequest setHTTPBody:[content dataUsingEncoding:NSUTF8StringEncoding]];
	[authRequest setHTTPShouldHandleCookies:YES];

Maintenant on configure notre première requête HTTP. Celle que l’on va faire au service ClientLogin de Google.

• on créé une NSURL qui représente https://www.google.com/accounts/ClientLogin
• on créé une requête NSMutableURLRequest (car on va la modifier après sa création) avec cette URL.
• on veut faire un POST.
• on prépare un chaine de caractères pour les paramètres de la requête. Elle doit ressembler à Email:login@gmail.com@Passwd=6(P;p7/s!#Fb&service=ah&source=myapp&accountType=HOSTED_OR_GOOGLE. En fait, non elle ne doit pas tout à fait ressembler à ça. Et c’est là que j’ai perdu du temps bêtement. Les valeurs des paramètres doivent être encodées de façon à éviter l’utilisation de certains caractères spéciaux. Et même si j’ai assez vite supposé que mon problème venait de là, je n’arrivais pas à trouver comment faire sans réinventer la roue avec Cocoa. La solution est dans la fonction urlEncodeValue que j’ai trouvée ici.

NSHTTPURLResponse* authResponse;
NSError* authError;
NSData * authData = [NSURLConnection sendSynchronousRequest:authRequest returningResponse:&authResponse error:&authError];

Ensuite on poste la réponse … de façon synchrone (pourquoi pas). Et on récupère le corps de la réponse dans authData.

NSString *authResponseBody = [[[NSString alloc] initWithData:authData encoding:NSUTF8StringEncoding] autorelease];

//loop through response body which is key=value pairs, seperated by \n. The code below is not optimal and certainly error prone.
NSArray *lines = [authResponseBody componentsSeparatedByString:@"\n"];
NSMutableDictionary* token = [NSMutableDictionary dictionary];
for (NSString* s in lines)
{
    NSArray* kvpair = [s componentsSeparatedByString:@"="];
    if ([kvpair count]>1)
    {
        [token setObject:[kvpair objectAtIndex:1] forKey:[kvpair objectAtIndex:0]];
    }
}

//if google returned an error in the body [google returns Error=Bad Authentication in the body. which is weird, not sure if they use status codes]
if ([token objectForKey:@"Error"])
{
    return nil;
};

if (![token objectForKey:@"Auth"])
{
    return nil;
};

• On récupère le corps de la réponse sous forme de NSString, elle doit ressembler à quelque chose comme ça :

SID=DQAAAJkAAABQe-mE_yaZapZsNR0h65oVFl8-5kwnOU1nf2INyz6edOi22ohSfkzAw9yCax9r0Rjem8Q-XXXXXXXX
LSID=DQAAAJwAAAALzcIgkGA-l7mJ2SixvOBIA_KR6bBy0qSEtFf2GejuFKw4hWmxTrSwBMtXGg6-ehOul__XXXXXXXX
Auth=DQAAAJsAAAALzcIgkGA-l7mJ2SixvOBIA_KR6bBy0qSEtFf2GejuFKw4hWmxTrSwBMtXGg6-XXXXXXXX

• Donc on va parcourir cette chaine ligne par ligne pour construire un dictionnaire.
• Et on récupère la valeur de la clef Auth dans celui-ci.

 // retrieve the cookie
 NSURL* cookieUrl = [NSURL URLWithString:[NSString stringWithFormat:@"http://myapp.appspot.com/_ah/login?continue=http://myapp.appspot.com/&auth=%@", [token objectForKey:@"Auth"]]];
 NSHTTPURLResponse* cookieResponse;
 NSError* cookieError;
 NSMutableURLRequest *cookieRequest = [[[NSMutableURLRequest alloc] initWithURL:cookieUrl] autorelease];

 [cookieRequest setHTTPMethod:@"GET"];

 NSData* cookieData = [NSURLConnection sendSynchronousRequest:cookieRequest returningResponse:&cookieResponse error:&cookieError];

 return [token objectForKey:@"Auth"];
}

Finalement on se connecte à notre application pour générer un cookie qui sera utilisé dans la requête suivante.

Maintenant on va pouvoir accéder à notre application en étant authentifié si nécessaire

Contrairement à ce qui est fait dans les postes dont je me suis inspiré, une fois que j’ai récupéré le cookie je n’ai pas besoin de passer le token d’authentification à chaque connexion au serveur. Une fois que j’aurai plus testé je reviendrai peut être sur cette partie.

Et sur le serveur de développement, comment on fait ?

Je n’ai pas encore testé mais ça n’a pas l’air bien compliqué … je reviens la dessus bientôt.

J’ai toujours été intéressé / fasciné par la technologie. Cela passe notamment par un intérêt pour la science fiction (enfin surtout du space opera et du cyberpunk plus que de la vraie SF). Et en y réfléchissant bien dans ce genre d’œuvres (livres, film, bds, …) on voit surtout des objets “futuristes” plus que de super logiciels super utiles. A part dans le cyberpunk (et encore).

Tout ça pour en venir où ? Depuis maintenant 15/20 ans je m’intéresse à l’informatique au sens large, la programmation, réalisation, conception, et utilisation de logiciels informatiques car ça me permet de créer/contrôler des choses comme certains dessine, font de la musique, sculpte, … Mais je suis entrain de me rendre compte que les choses n’avance pas aussi vite que ce qu’on peut penser. Il y a encore un faussé énorme entre les gens qui utilisent de façon intensive et naturel l’outil informatique (et je parles bien d’utilisation au sens large, pas seulement de développement logiciel) et le commun de mortels qui a de grande chance (si il vie occident et/ou à un minimum de revenue pour avoir accès à un ordinateur) de savoir vaguement se servir d’un navigateur web et de quelques services web et c’est tout. C’est qui est très loin de l’image hightech qu’on peut avoir de la société par moment.

Même si il reste plein de choses à améliorer et à créer je suis entrain de me demander si tout en gardant comme point de départ mon intérêt pour l’informatique le fait d’y ajouter un peu de concret, de réalité via des objets physiques ne serait pas quelques choses d’intéressant. Ça veut dire quoi se charabia … ça veut dire que j’aimerais m’intéresser à la création/développement d’objet physique utilisant des programmes informatiques dans leur fonctionnement. Ça reste encore très vague …

L’envi m’est venue progressivement depuis 2 ans je penses en découvrant des projets tels que :

• RepRap (http://reprap.org/) : pour faire simple c’est un imprimante 3D open source capable de se répliquer à 50%.
• cette vidéo => “Voici l’ordinateur portable du futur, ne ratez pas cette vidéo“.
• ce genre de truc : Arduino (http://www.arduino.cc/) … utilisez par des connaissance ici -> http://www.my-os.net/blog/index.php?2010/01/31/1445-les-editions-volumiques.
• ces livres que je n’ai jamais lu : Robot Building for Beginners et Intermediate Robot Building.

Sur quoi ça peut déboucher ? Je ne sais pas … surtout qu’au final je n’ai pas tellement le temps de creuser la question … mais j’aimerais bien.

Bon je m’étais dit que ce blog ne serait pas un nième blog mort né … mais on en est pas loin. J’ai quand même quelques articles en mode draft que je n’arrives pas à commencer :

• Être son propre Google : en ce moment on se rend compte de la puissance/importance grandissante de Google. Ce n’est pas une nouveauté mais de plus en plus de monde s’inquiète et se pose des questions. La lecture de cet article “Google et Facebook dans le collimateur du public” (sur le blog de Tristan Nitot) et de cet autre article “About gathering web 2.0 personal data into one safer place” (dans un des commentaire du précédent article) mais fait penser que ce serait bien que je réfléchisse aux moyens existant actuellement pour se passer un maximum de Google (webmail, suite office en ligne, agenda, todolist, flux rss, statistiques de site web, …). Le seul truc que à priori je garderais à coup sur ce serait la recherche. Reste à creuser la sujet.

• La modélisation pour “nous” les gens normaux … : ça m’est venue après avoir assister à la présentation de Sylvain Lefebvre lors de la 2ème soirée Rencontres Start-up et recherche organisée par le Paris ACM Siggraph. Sylvain n’était pas le seul à présenter ces travaux (et ceux de son équipe) mais c’est son intervention qui m’a le plus intéressé. Le sujet en était : Génération automatique de contenu pour le graphique. Il y a montrait notamment une technique permettant d’assembler/modifier des bouts de modèle 3D pour en créer d’autres. L’opération étant manuelle (mais assistée par le soft) pour éviter la répétition d’un processus complétement généré par un algorithme. En gros ce genre de technique pourrait permettre à quelqu’un qui ne maitrise pas le modélisation de réussir à faire quelques créations … à partir de modèle (ou de bout de modèle) existant (voir ici). Donc je voulais essayer de lister les techniques existantes et voir si il n’y aurait un brèche pour ce genre d’outils. Naïvement je disais que j’avais l’impression qu’on en était toujours à modéliser à l’aide de triangle (ou surface à la limite) ce qui nécessite forcément de capacité “graphique” que je n’ai pas. J’avais un peu trop occulté des outils tel que ZBrush (qui reste un truc de pure “graphiste” donc hors de porté pour moi) et Google Sketchup. J’ai essayé ce dernier quand même car il est gratuit … bon je vais pas m’étendre plus longtemps et j’essaierais de détailler ma pensée dans un autre billet comme prévu.

• Catching access violation under gcc : Celui est un peu plus technique que les deux précédents et en rapport direct avec un truc que je dois faire au boulot. Juste une histoire d’intercepter des signaux sous Mac OS X pour faire l’équivalent d’un catch(…) avec Visual C++ sous Windows.

A: Enter this command line in your prefered terminal application to generate a list of GCC’s predefined macros:

gcc -dM -E - < /dev/null | sort

seen here : http://developer.apple.com/mac/library/qa/qa2005/qa1424.html

Pendant le GameCampParis (voir ici, là, là et là) j’ai essayé d’initier une session qui avait pour thème : Fédérer la communauté indy (par provoc’ j’avais aussi appelé ça PlayAll Indy). Le constat c’est qu’il avait pas mal de monde qui était intéressant par savoir comment mener un projet perso ou en petite équipe à son terme, comment en faire la promotion, voir comment le financer. De plus quand on veut  vraiment faire un jeu on ne cherche pas à écrire un nième moteur 3D, éditeur de niveau, … si on le fait c’est peut être que le besoin s’en fait sentir (pour de bonnes ou mauvaises raisons) mais dans ce cas pourquoi ne pas essayer d’en faire profiter les autres voir mutualisé le travail car dans le fond il y a peut de chance qu’un jour on en fasse un produit à part entière.

Je pense qu’il doit exister pas mal de sites répondant plus ou moins à ce genre de besoin (j’ai d’ailleurs découvert pendant le gamecamp l’existence du Games Creators Network) … pourtant on dirait qu’il existe un besoin (peut être que je me trompes). Peut être que le besoin est juste d’avoir ce qui existe ailleurs mais en plus localisé (France), plus spécifique à un domaine …

De plus lors de la session “Fédérer la communauté indy” on est plus ou moins arriver à la conclusion que si on voulait partager du code, de la techno, la solution la plus viable est l’opensource. Il existe déjà des projets opensource lié au jeu vidéo tel que Ogre3D, Bullet, Box2D, Cocos2d iPhone … mais par contre on ne trouve pas beaucoup de moteur de jeu, éditeur de niveau, …. autour de ces projets (encore une fois peut être que je me trompes). De plus la communauté opensource dans ce domaine ne me semble pas aussi regrouper, rassembler que celle qu’on peut trouver sur les technos web. Ici on a des groupes de gens qui semblent bosser sur un projet (c’est déjà pas mal) mais il n’y a pas l’air d’avoir beaucoup de discussion entre les projets (par exemple Blender aurait pu devenir le modeler/level editor pour Ogre3D plutôt que devenir aussi un autre moteur 3D, moteur de jeu).

En dehors de l’opensource il existe aussi des produits tel que Unity qui devienne de plus en plus abordable (financièrement et techniquement). Il existe déjà des sites dédiés à l’échange de scripts, techniques autour de Unity mais ils sont généralement restreint à Unity.

Et puis pour l’instant on ne parle que de techno/code mais il n’y a pas que ça : quid de conseil en ergonomie, interface utilisateur, focus groupe, communication, marketing (virale ou pas), …

Encore une fois l’idée est justement de ne pas réinventer la roue … donc est ce que j’essaie d’expliquer à un sens, un intérêt ou est ce que je vois des besoins/problèmes là où il n’y en a pas parce que je cherches à m’occuper (plutôt que de coder). Malgré tout j’ai l’impression qu’avoir une communauté plus locale, avec des gens identifié pour être intéressant.

Juste pour finir : c’est quoi un développeur indy ?

(écrit un peu à la va vite mais je voulais cracher ce que j’avais en tête rapidement … quitte à murir ça dans d’autres postes).

La 1ère GameCampParis a donc bien eu lieu hier dans les locaux de notre généreux sponsor PlayAll.

Globalement c’était très sympa, intéressant et je suis impatient de participer à la prochaine. Avant d’essayer de faire un (bref) compte rendu des sessions que j’ai réussi à suivre on va peut être parler des quelques points qui m’ont déçu :

• on avait 2/3 salles pour gérer 4/5 sessions en parallèles donc des fois c’était dur de s’entendre. avec les locaux qu’on avait c’était dur de faire mieux, on nous les prêtaient gratuitement donc on ne va pas trop se plaindre.
• l’hétérogénéité des participants (qui est un point positif) pouvaient être des fois perturbantes sur l’interprétation du sujet des sessions. En gros les sujets des sessions étaient suffisamment vague pour que chacun voit la chose à ça façon. alors oui c’est bien de mélanger les genres, mais des fois ça pouvait prendre une direction assez différente de ce à quoi je m’attendais … pas de souci dans ce cas … hop on se lève et on va voir ailleurs … mais des fois ça fait bizarre. bon ce n’était pas très génant non plus mais ça me l’a fait une fois (et demie) quand même. en gros j’ai l’impression qu’on avait les oppositions suivantes
  • codeurs (qui ont tendance à trop partir de / ramener à la technique/techno/moteur) VS graphistes/level designers/game designers
  • je veux monter mon petit projet perso, monter ma boîte, être mon compte ….. VS je veux comprendre, améliorer, …. le travail dans une structure importante
• je schématise un peu et je ne sais pas si j’emploie les bons pour expliquer mon ressenti … en tout que personne n’y voit une attaque contre tel ou tel camp

Avant de commencer, il se peut que ma vision de certaines soit biésée dans une certaine direction du fait que je suis un programmeur et que je réfléchis à des projets peros (donc tout le coté indie, fait à la maison, …).

Les sessions aux quelles j’ai participé :

Indie : faire un jeu tout seul

Ce barcamp était quand même globalement assez orienté développement indépendant / indie, projet perso, … Cette première session ouvrait un peu la voie aux autres. C’était la première session on était donc par encore très chaud … en plus un barcamp c’était un peu nouveau pour nous mais on s’est un peu dérouiller au fur et à mesure.

Dans le thème il y a indie et seul.

• Faire un projet seul, cela veut dire que l’on maitrise différent corps de métier (code, gfx, gd, son, …) ce qui est quasiment à la porter de personne. Certains parti pris artistique peuvent permettre à un codeur de tout faire : on a cité l’exemple de Love (http://www.quelsolaar.com/love/index.html).
• Indie ? ça veut dire quoi indie … dans cette session on n’a pas trop disserté sur le sujet mais en fait la définition reste assez floue (projet perso qui devient un truc a visé commercial, projet fait en très petite équipe, projet faire par une équipe indépendante quelques soit ça taille, ….)
• On peut être seul à l’origine du projet et à gérer/contrôler le projet mais faire appel à d’autres personnes pour certaines partie que l’on ne maitrise pas. Cela parait plus réaliste : à coder aura surement besoin d’au moins un graphiste, …
• On tombe donc sur la problème d’être plusieurs, surement distant … et qu’il va falloir gérer tout ça ? existe-t-il de plateforme facilitant se travail collaboratif … on a cité trac (http://trac.edgewall.org/) il me semble. Quelqu’un a cité une plateforme communautaire où l’on peut noté les gens, ce qui permet de simplifier le passage de quelqu’un à un autre.
• A un moment on a un peu dérivé car on est partie sur les projets perso qui ne sont plus vraiment des projets indie de mon point de vue. même si un projet perso (à coté de son travail) peut finir en vraie projet un plein temps (indie ou pas … encore ce problème de définition du mot indie). Un projet perso dans un contexte jeu vidéo peut être une démo technique, un petit jeu (mobile ou pas), un mod (half life 2 et autres) … avec différents buts (carte de visite, purement loisir, basculer en projet principale, …).
• Quand on fait un projet à un (ou en petite équipe) le risque est partir sur un projet trop ambitieux et de ce noyer. Le plus important est donc de fixé un cadre très précis : thème, objectifs, durée. Cette notion de durée est très importante en fait pour bien cadré le projet. On a un peu parlé des différents concours/expériences/festival qui propose de faire un jeu sur une semaine, un week end … le fait de contraindre la durée force à faire beaucoup de choix/concessions ce qui peut être bénéfique au final.
• Cette notion de durée très courte nous a amené à parler de projets tel que world of goo.  Ce jeu est issue d’un projet qui s’appelle tower of goo qui a vu le jour via le “projet” Experimental Gameplay (http://experimentalgameplay.com/). De là on a dérivé sur l’aspect promotion de son jeu indie … en fait différent jeu tel que word of goo, crayon physic, … si issue de prototype qui ont été médiatisé. il y avait donc une attente autour du jeu. Certains font aussi du merchandising pour promouvoir leur jeu (Castle Crusher).

Gameplay : bottom up – top down

Un sujet sur le gameplay. Discipline que ne connais pas du tout. J’étais donc plutôt de curieux de voir de quoi on allait parler. (seul bémol … à cause de acoustique du lieu ce n’était pas facile d’entendre tout le monde).

• déjà c’est quoi cette histoire de bottom up – top down. en gros si j’ai bien compris il y aurait du façon de concevoir un jeu :

1. soit on part d’un point/contrainte technique : idée de contrôle, parti pris visuel, avancé technologique et on cherche à construire un jeu (univers) autour de cette idée : c’est le bottom up.
2. soit on part d’une univers et on descend vers la technique, le gameplay : c’est le top down.

• le bottom up on n’a pas d’univers dès le départ donc on est moins cadré. par contre ça oblige quasiment systématique de faire un proto ce qui n’est pas une mauvaise chose. on pourrait croire qu’il est plus dure de “vendre” un projet construit en bottom up mais ce n’est pas forcément vrai. on peut vendre un projet autour d’une “technique” particulière. genre on va faire un RTS qui gèrera des univers énorme comme on en a jamais vu.
• le projet top down qui parte d’un univers sont souvent des commandes éditeurs ou liés à une licence. le problème de ce type de projet est qu’on met du temps à définir le gameplay et donc le fun du jeu.

Logiciels libres

globalement les participants a cette session était plutôt pro libre donc il n’y a pas eu de contradicteurs.

• le premier problème avec les logiciels s’est qu’on se rend compte que les gens comprennent rarement ce que s’est. générale ils retiennent que c’est gratuit (on verra que c’est en partie faux).
• cette incompréhension amène des sociétés à bannir purement et simplement l’utilisation de soft/librairie open source.
• on a aussi cité le cas de Nintendo qui récemment à banni l’utilisation de code open source dans les jeux wiiware (si j’ai bien compris). ce qui veut dire qu’on ne peut même pas utiliser la zlib par exemple . cette situation semble temporaire en attendant que le légal de chez Nintendo clarifie la situation.
• les arguments classiques employés contre l’opensource sont
  • c’est gratuit donc pas sérieux (quid de soft comme apache, gcc, firefox, …).
  • il n’y a pas de support.
• à l’opposé un middleware commercial a un support. le problème c’est que le support n’est pas toujours de qualité. que se passe-t-il en cas de liquidation/rachat de la société (on a parlé de l’expérience renderware de certains).
• globalement il faudrait éduquer les décideurs aux logiciels libres, leur faire comprendre que ça un coup (maintenance, intégration, suivi de la communauté, intégration de patch, ….) mais qu’on n’a pas à faire à une boite noir. de plus le métier d’un éditeur de jeu n’est pas de faire un moteur 3D, donc utiliser un moteur free (tel que ogre3d), voir y participer n’est pas se tirer une balle dans le pied.
• au final il faut être pragmatique est utilisé le meilleur outil pour faire le job, commercial ou opensource.
• il y a aussi la distinction outils/libs à faire. généralement les “gens” sont moins retissant à utiliser des outils opensource pour leur prod (cvs/svn, ….). malgré tout on a eu un témoignage d’un switch cvs -> perforce pour cause de crash cvs qui a entrainer le perte de données (car il n’y avait pas de backup sérieux). pas évident que perforce aurait récupéré leurs données en cas de crash sans backup correct.

- logiciel libre : maitrise du code qu’on a pas avec une boite noir tel qu’un middleware
- mais ça a un coup quand même (le libre) …ne pas le cacher

Prototypage

pas trop suivi …. on est partie sur plus de proto avant une grosse prod … pas mal d’expérience de l’équipe de Darkworks. je m’attendais plus à du proto pour petit projet (même si en fait il n’y a pas trop de différence).

travailler chez soi – projet perso

trop de monde dure à suivre … globalement c’est super dur de se motiver. le travail en équipe peut aider. définir des cycles court. aller le plus vite possible à quelque chose de visible (ça rejoins à un peu ce qu’on disait le matin). certains remarque que pour y arriver il faudrait mettre en place des méthodes de gestion de projets aussi rigoureuse qu’au boulot alors que des fois on voudrait faire ça à la cool (moi j’aurais tendance à dire qu’il faudrait des fois être encore plus rigoureux qu’au boulot car on a encore moi de temps).

fédérer partage de techno et autres (indie ?)

• session que j’ai initié … naïvement (et/ou par provocation) je voulais appeler ça “playall indie”. en gros l’idée était de dire qu’au final si on veut faire un jeu le moteur 3D, réseau, son, …. n’est qu’un outil donc autant ne pas perde de temps dessus. pareil pour les éditeurs de niveau, ressources, exporteurs, …. et autant se concentrer sur l’histoire, le gameplay, le visuel, …
• donc est ce qu’il ne serait possible de mettre des “ressources” en commun. on a surtout parlé ressources techniques (code) mais on pourrait très bien étendre ça à d’autres sujets (focus groupes, markcom, …).
• le premier constat est que si il y a partage de ressources il “faut” se mettre d’accord sur les règles du jeu. c’est à dire avec qui on partage, comment, les conditions, … le risque est qu’au final les différents participants se tire dans les pattes à coup de “moi j’en fais plus que toi, mon truc est mieux, ….”.
• la solution la plus simple semblait de se dire qu’il fallait que tout soit opensource. n’importe qui participe, n’importe qui en profite.
• on a donc besoin de créer/gérer une communauté : on a pris l’exemple de boost. l’intégration de modification, évolution est valider par un comité qui intègre dans la “branche” officielle. ce qui nous a amené à un peu parler de git (qui avait été le sujet d’une autre session du matin). git (et les outils de gestion de code décentralisé) semble intéressant pour gérer ce genre de projet.
• on n’a pas conclu sur un truc clair mais (conclusion perso) il me semble intéressant de creuser l’idée de fédérer une communauté opensource pour le monde du jeu. il existe déjà des projets “sérieux” (ogre3d, bullet, box2d, cocos2d, …) ça manque peut être un peu d’outils et de personne s’investissant (plus facile à dire qu’à faire)
• petit point important qu’on a abordé au début en fait : ça veut dire quoi indie. ou s’arrête la limite ? l’utilisation de l’opensource aurait aussi cet avantage : on ne met pas de barrière.

Pour essayer de faire genre ce blog n’est pas mort un petit post (pas en avance).

A l’initiative de Mustapha Bismi et Stéphane Becker le premier “French Video Game Bar Camp” qui se passera à Paris … ou plus simple le GameCampParis. Pour vous inscrire c’est ici (mais il ne reste plus beaucoup de place car on risque d’être limité à 50) : http://www.gamecamp-paris.org/.

• Ça sera passera le Samedi 5 Décembre dans les locaux de PlayAll.
• De quoi on va parler ? On ne le sait pas trop à l’avance car c’est un barcamp. Pour simplifier un barcamp c’est une espèce de non conférence où tout le monde participe. Donc les sujets de discussions se décident en fonction des participants. Mais quelques discussions on permis de dégager des sujets (trop) de discussions pontentiels :
  • Rester dans la technique après 35ans sans qu’on nous jette des pierres.
  • Comment devenir développeur indépendant
  • Comment ne pas tout le temps réinventer la roue : utiliser à max ce qui existe déjà sur le marché …. libre/opensource car c’est moins “cher” ?
  • Création d’un playall indé ?
  • Service / création : la création c’est sympa mais ça paye pas tout de suite …. donc je veux faire du service (lequel) pour vivre et manger (bon c’est pas si technique) ça
  • Open source en terme d’outils, ce qui a été testé grandeur nature
  • Comment vendre son savoir faire qui peut se décliner en 2 parties l’une de vente vis à vis des professionels et l’autre vis à vis du public.
  • Comment s’entraider entre équipes/studios/indépendants ? Partage de savoir faire ? (rejoint l’idée du Play All).
  • Comment promouvoir ses produits quand on est independant ? (valable pour tout le monde remarque).
  • L’auto édition étant en développement, que va t il se passer de nos pauvres éditeurs ? vont il devenir des producteurs ?
  • Quels sont les tendances à venir, comment se positionner pour avoir une chance de se démarquer ? Les machines “à tout faire” (IPhone) ont elle vraiment une chance de détrôner les consoles portables ?
  • Comment être efficace quand on est tout petit ? (inspiré de l’article “9 paths to greatness for Indies” publié sur Gamasutra).
  • La sous-traitance dans le jeu-vidéo?
  • Le type de société le plus souvent utilisé dans le secteur mais aussi par rapport à d’autres critères? Par exemple est-il bien vu qu’une développeur soit une société Offshore à l’étrangé et travaillant en France mais ne vendant ses produits que par le biais de plateforme comme Steam, l’App Store, … (Donc légal bien-entendu)
  • L’importance des DLC payants dans la santé financière de sa société?
  • Comment protégé une idée, une marque, une licence, …?
  • Comment bien lutter contre le piratage?
  • La bonne stratégie à adopter par rapport à l’évolution des technologies Hardware et Software?
  • L’industrie et les pays en voie de développement comme la Chine? Quel serait les risques que l’industrie du jeu-vidéo se délocalise dans un futur proche?
  • On pourrait aussi faire un topo sur les plateformes existantes et les solutions techniques (middleware,sdk,libs) qui leur sont associées (pc/mac, web (flash, facebook, …), console salon/portable, téléphone/mid, ….)
  • “la french touch”, grosse intox ou réalité? j’en ai marre d’entendre ce mot…mais si ça existe vraiment ce serait intéressant de la définir et de la promouvoir pour attirer de l’investissement en france (ou faciliter l’expatriation en rendant notre savoir faire plus attractif)
  • Le télétravail (cf article récent sur gamasutra): une solution pour encourager l’embauche? parler des outils qui fonctionnent et des comportements nécessaires pour que l’expérience soit positive.
  • Un “steam-like” frenchie pour jeux indés?
  • La presse peut-elle remplacer les “tests” censés être objectifs par des “critiques” subjectives ?
  • Le statut juridique idéal des salariés du Jeux Vidéo
  • To crunch or not to crunch: retour sur expérience, ce qui marche et ce qui ne marche pas.
  • Formation et auto-formation: Comment on se forme, quels dispositifs à -t-on a disposition, comment valoriser l’effort d’auto formation.
  • Etre Agile: Depuis quelques années, agile est devenu très à la mode. Comment est ce que ça marche (ou pas) pour vous.
  • The X: Comment définir l’expérience de jeu du produit et s’assurer que tout le monde est sur la même page.
  • The Elevator Pitch: Souvenirs, anectodes et conseils pour bien pitcher ses projets.
  • Project bootstraping: Démarer un nouveau projet, quel taille d’équipe, partager vos conseils.
  • Pet Project, ou encore “le projet de la maison”: Quel statut à le projet qui est entreprie par l’employé dans son temps libre: status juridique, valorisation de l’autoformation, mythes et réalités
  • Le status autoentrepreneur: si il y en a dans la salle, ça serait sympa d’avoir un retour sur l’expérience acquise via ce statut
  • Le développeur social: Blog, twitter, LinkedIn… Quel est la valeur de ces réseaux et de la parole de l’employée dans sa vie privée, le tout dans une perspective 2.0 ^_^
  • Expat and back: Partir à l’étranger (et en revenir!), tips et retour sur expérience
  • Execution vs Innovation: Ce qui relève d’une logique d’innovation, et ce qui relève de la qualité de l’exécution, bref, ce qui fait la différence
  • Certification des jeunes sociétés : moi aussi je veux bosser pour Sony/Nintendo etc. et j’aimerais bien savoir comment ça se passe (inscription, coût du support…)
  • Comment promouvoir ses produits quand on est indépendant ?
  • Les outils à la unity vous en pensez quoi ? expérience .. retour …
  • Que pensez vous d’un projet “communautaire” visant à la création de cette chose qui n’existerait pas ? rejoint un point le sujet playall indy cité plus haut il me semble
• si je suis pas trop flemmard j’essaierai de faire un compte rendu des discussions que j’arriverais à suivre.

Je suis le blog d’Archiduchesse de Patrice Cassard et ça fait 2 mois qu’il s’amuse à créer un liste spotify collaborative et je trouves assez marrant alors j’ai fait le même chose.

Pour essayer de découvrir de nouveau truc.

Pour voir si mes potes n’ont pas des gouts de chiotes.

Pour voir si via Facebook/Twitter et ce blog naissant je touches plus que 2 potes de facs et 1 collègues .

Donc la liste est là : RXRA – Liste Communautaire 1.

Mettez dans les commentaires ce que vous avez mis car sur spotify on ne sait pas qui fait quoi c’est bête.

Pas besoin d’invitation pour spotify, il suffit d’aller là : https://www.spotify.com/fr/get-started/

Eric Viennot a publier récemment un interview (en deux parties : partie 1 et partie 2) de messieurs Éric Chahi (Another World) et Jordan Mechner (Prince Of Persia, l’original). C’est un peu l’interview des vétérans (ou des légendes). Interview qui peut être intéressant car on se demande bien ce qu’ils deviennent et ce qu’ils pensent de l’industrie du jeu vidéo. Personnellement j’ai été un peu déçu car j’ai eu l’impression de ne pas apprendre grand chose.

Malgré tout une partie à retenue mon attention car je me suis senti concerné/visé. Dans la deuxième partie de l’interview, Jordan Mechner explique quelque chose qui peut paraitre tout bête mais qui n’est pas si évident à mettre en œuvre (en tout cas pour moi). Appelons ça la théorie du 1-3-2.

Un projet est divisé en 3 grandes étapes

1. l’idée : la partie la plus importante car c’est le début de tout projet.
2. les problèmes que l’on rencontre pour mettre en œuvre (réaliser) cette idée : les difficultés techniques et financières, le cible visé n’est pas la bonne ou ne comprend pas le projet/produit, …
3. la réalisation/finalisation du projet.

En général les gens on tendance à passer l’étape dans l’ordre, c’est à dire 1 puis 2 puis 3.

• 1 – On a l’idée.

• 2 – On commence à envisager tout les problèmes qu’on peut rencontrer. On envisage les solutions. On trouve d’autres problèmes … Et on finit par abandonner le projet

• 3 – On réalise finalise le projet. Mais comme il y a des chances qu’on ai déjà arrêter en 2, l’étape 3 existe rarement en fait.

L’idée est donc de faire ça dans le sens 1-3-2. C’est à dire :

• 1 – On a l’idée … ça commence toujours par là.

• 3 – On donne réalité à l’idée le plus rapidement possible en essayant d’aller le plus loin possible. Ça ne veut pas dire quoi doit déjà finir complètement le projet mais qu’on doit avoir le plus possible de bouts représentant cette idée. Pour un logiciel je dirais qu’on doit avoir le plus de fonctionnalités même si elle sont partielles. L’idée étant de faire une réalisation partielle avant de commencer à chercher les problèmes et à les résoudre.

• 2 – On résout les problèmes pour finir de réaliser l’idée. Peut être qu’on devra remettre en cause beaucoup de choses faites à l’étape 3 mais on aura pu tester l’idée en conditions réelles.

Dit comme ça parait bête voir évident. Mais j’ai l’impression que c’est plus facile à dire qu’a faire. En tout cas moi personnellement j’ai du mal même si ça fait longtemps que cette façon de faire me semble évidente. Étant un développeur j’ai une approche technique de mes idées/problèmes :

• comment je vais faire pour que ça fonctionne
• prise de tête sur les outils pour le réaliser
• qui finisse des fois par m’amener à vouloir réaliser les outils qui vont me permettre de réaliser mon idée
• je commence à envisager des problèmes qui arriveront que si le projet passe suffisamment d’étapes (ne comptez pas sur moi pour penser faire un truc genre flickr ou youtube car je serais déjà entrain de me demander comment on fera pour avoir les machines pour gérer 5 millions de connexions par jour alors qu’on aura même pas commencer à coder une ligne … oui il faut y penser mais pas trop quand même sinon on ne démarre jamais).

Alors que si j’allais droit au but : je veux faire ça … je le fais … je peux le tester … l’éprouver … après il sera toujours temps de repenser des choses.

En ce moment sur mon temps libre j’essaie de bosser sur une petite application mobile avec un serveur et de la géolocalisation. Au final je perds du temps a essayer de faire une interface graphique jolie car j’ai l’impression que si elle n’a pas un minimum de gueule je n’arriverais pas moi même à me motiver pour continuer le projet. Le problème c’est qu’avec mon gout pour l’esthétique je ne ferais jamais une GUI jolie et donc je suis entrain de bloquer sur un problème qui pourrait bien sonner la mort des maigres espoir que j’ai de mener ce projet à son terme (ou du moins à la première étape qui de pouvoir tester l’application dans sa version minimale : l’ensemble des fonctionnalités de bases pour répondre à l’idée de départ). Ce problème de look de GUI il sera toujours temps de le résoudre (avec de l’aide) plus tard.

Même si je le pensais déjà le fait d’avoir lu cette interview m’a éclairé sur le fait qu’il fallait que j’aille le plus simplement possible à la fin de cette première version minimale de mon idée avant de me prendre la tête sur tous les détails qui feront que ce projet aura à quelconque intérêt pour les autres.

Ça fait une semaine que j’ai lu cette interview et je n’ai pas avancer … mais au moins je n’ai pas fait sembler d’avancer et je ne me suis pas pris la tête sur des problèmes inutiles (pour le moment).

Premier post d’une longue série d’auto psychanalyse sur ma méthodologie de travail sur mes projets perso ?