04.07.2009

Twitter...

Oh, pour ceux qui ne l'aurait pas encore remarqué, j'ai désormais un compte Twitter, histoire d'aller plus loin que Facebook.

 

Vous pouvez donc suivre mes découvertes ainsi que celles des autres tweet de l'industrie, tout ce que je ne peux pas poster sur le blog, et le reste, le tout en temps réel à cet adresse: http://twitter.com/mbismi ^_^

 

 

twitter_logo.jpg

13:00 Publié dans Nexus | Lien permanent | Commentaires (0) | Envoyer cette note | Tags : twitter

Paris AI Game Dev Conférence 2009

Les papiers de la dernière conférence Parisienne sur l'IA sont désormais en ligne (on m'a dit beaucoup de bien de la conférence)!

 



GAIC09w_AudienceTop.medium.jpg

03.07.2009

RoboGeisha

Mais mais LOL !!!!

Je veux l'IP, le jeu serait TERRIBLE !!! ^_^

 

Apprendre à programmer pour l'Iphone

Hé bé, si avec un titre pareil je n'explose pas mes stats ^_^

 

Bref, pour ceux d'entre nous qui ont envie de faire de l'Iphone (et a en juger par la popularité de la plateforme dans le millieu, ils sont nombreux), l'université de Stanford a mis en ligne son semestre de cours de cette année:

 

businessmobilephonenet-iphone-software-update.jpg

13:36 Publié dans Code | Lien permanent | Commentaires (0) | Envoyer cette note | Tags : code, iphone

02.07.2009

Project Bootstrapping

Tous les projets ont pour origines au mieux une vision, au pire une intention, dans la tête d’une personne seulement (ou une poignée, plus rarement), mais peu de projets peuvent s’épanouir de par eux même. Faire grandir un projet requiert de réunir un certain nombre de personnes, chacune avec des compétences spécifiques et probablement une façon de voir les choses différente.

 

 

Jusque là, rien de très surprenant.

 

 

Quelque soit le contexte, grande ou petite entreprise, projet d’envergure ou à court terme, il y a toujours un premier document, une première passe, une première maquette, dont le propos est de « bootstrapper » le projet.

 

 

Ce n’est pas tant que le contenu ou la forme de cette initialisation soit vraiment importante – peu de projets peuvent se targuer d’avoir été « spot on » dès le départ. Un projet va vivre, évoluer, grandir ou se modifier, et il est parfaitement possible que le résultat final se retrouve à des lieux de l’intention initiale.

 

 

Non, ce qui fait que cette passe est si importante, c’est qu’elle conditionne de façon assez déterminante la survie d’un projet. D’abord parce qu’il est facile d’arrêter un projet à cette phase là (très peu d’investissements, très peu de conséquences). Ensuite la capacité à convaincre, à rassembler ou à mobilier une équipe autour de se projet dépend grandement de la qualité ce cette phase.

 

 

Une personne en charge de bootstrapper un projet (que cela soit par sa propre initiative ou par assignement) a donc une lourde responsabilité. Il lui faut réunir le strict minimum de personne suffisant pour permettre au projet de démarrer, avec un objectif clair : se concentrer sur ce qui permettra au projet de survivre pour passer à l’étape suivante.

 

 

On voit souvent deux erreurs assez caractéristiques pouvant nuire à cette phase. Parfois la personne s’isole et décide de bootstrapper le projet par elle-même, ce qui a plusieurs conséquences fâcheuses (étalement inconsidéré de cette phase dans le temps, qualité dégradé des documents produits, mauvais choix effectué sans manque de recul, difficulté à « vendre » le projet par la suite).

 

 

L’autre erreur commune est – à l’inverse - de réunir trop de personnes avant même que le bootstrap ait été effectué, ce qui entraine une certaine dispersion de l’énergie, un manque de vision commune sur le projet, un trop grand nombre de malentendu, et une qualité globale également réduite.

 

 

Bref, bootstrapper un projet n’est pas une tache aisée, que cela soit dans le cadre d’une entreprise ou dans le cadre d’un projet individuel indépendant.

 

 

Il n’y a évidemment pas de recette magique, mais j’ai remarqué des choses qui ne marchent pas trop mal pour moi. Par exemple, pour moi, la taille idéal pour bootstrapper un projet, c’est 3 personnes. En dessous, il n’y a pas assez d’inputs (et de bras aussi), et au-delà  se forme déjà des mécaniques de divisions ou de dilution de la vision ou de l’objectif.

 

 

A trois, il est possible de partager assez simplement une même vision, tout en ayant assez d’inputs créatifs et assez de retour constructifs pour faire un bon bootstrap. Enfin, trouver trois personnes avec le bon baggage de compétence et la bonne attitude ne me semble pas si compliqué que cela. Evidemment, il faut les 3 bonnes personnes pour que l’alchimie puisse prendre.

 

 

Ce n’est déjà pas forcément simple dans le cadre d’une entreprise (où vous ne choisissez pas forcement avec qui vous allez travailler), mais en discutant avec quelques amis, j’ai découvert de façon surprenante que c’est encore plus compliqué en tant qu’indy, car si le champs des motivations est déjà vaste dans le microcosme professionnel, il est quasiment infini dans le monde amateur.

 

 

Bref, si encore une fois le démarrage d’un projet de présage en rien de sa forme finale, elle est déterminante quand à ses chances de succès, et cela indépendamment de son contexte.

01.07.2009

Kodu Games Lab

 

A l’heure ou j’écrit cette note, un drôle de personnage ovoïde s’agite et me fait des clins d’œil tendancieux tout en émettant une série de bruit bizarrement mécanique qui n’ont rien à envier au bruit que pourrait faire une imprimante branché plongé dans une piscine.

 

Et non, je n’ai pas fumé un joint de trop.

 

Il s’agit de la page d’accueil de Kodu, une nouvelle application que Microsoft a commencé à distribuer en douce sur le Xbox Live (dans la catégorie des jeux de la communauté).

 

Le principe de Kodu est simple : il s’agit d’éditer ce qui ressemble à une arène avec des entités que l’on peut « programmer ». Enfin, programmer est un bien grand mot : il s’agit plutôt de les scripter.

 

Chaque ligne de programmation se principe sous la forme d’un événement et d’une série d’actions paramétrisables. A chaque événement (pression d’un bouton du pad, collision, vie qui tombe à zéro…) correspond une série d’actions simples (jouer un son, avancer, ajouter des points…).

 

 

programming_ui.jpg

 

Le tout se présente sous la forme de petits logos permettant de visualiser en un coup d’œil le résultat de la ligne (enfin plus ou moins facilement).

 

Ce système est assez réminiscent du scriptage des NPC dans FFXII, où il s’agissait également d’encoder des actions sous forme d’événements.

 

 

FFXII_Gambits.jpg

 

Evidemment, le choix des briques disponibles est très importants, puisque de leur nombre va dépendre l’expressivité du joueur. De plus, le choix d’avoir un système d’édition « world centric » ne se compare pas à un jeu comme Little Big Planet (qui lui a une approche plus player centric).

 

Et puisque l’on parle de LBP, l’autre différence fondamentale réside dans le choix des abstractions : Kodu permet de scripter visuellement, mais ça reste du code. A l’inverse, LBP lui script de façon mécanique (on pose principalement des détecteurs, des leviers et des interrupteurs, même la musique est représenté par une petite enceinte).

 

 

ClockStage2.jpg

 

Ce choix dans les abstractions comptent énormément : là où Kodu a du coup le potentiel de servir d’introduction à la programmation événementiel, LBP lui sert d’école de Level Design…

29.06.2009

Content-Preserving Warps for 3D Video Stabilization

Voici un exemple de ce que l'on pourra voir cette année au Siggraph.

 

Ce papier expose une technique de stabilisation automatique des vidéos amateurs, comme il en existe tant. Mais celui ci est tellement efficace que l'on est à la limite de l'uncanny valley. D'ailleurs, passé le premier effet Wow, on sens comme une sorte de chose bizarre en regardant ces vidéos, non ?

 

 

 

Siggraph 2009 Papers

Le Siggraph approche a grand pas, début Aout à La Nouvelle Orléans, et comme le veut l'usage, Ke-Sen Huang maintient la liste des papiers de l'année.

 

De quoi lire à l'ombre d'un parasol sous la canicule ^_^

 

siggraph-2009-logo.jpg

28.06.2009

Le cycle de vie d'un jeu vidéo...

Je sais, il est tard, mais j'avoue que ça m'a fait rire... ^_^

 

the-life-cycle-of-a-videogame-20090623050043138.jpg

26.06.2009

Awesome !!!

Mais que demande le peuple, hein ? ^_^

 

awesomebeards.jpg

24.06.2009

Cable news: The shape of the industry...

Nouveau format, nouvelle exercice de style. Au lieu de faire des news dédiés, je vais juste essayer de lister ce qu'il est notable dans l'évolution de notre industrie. Hop, voici donc en concentré, ce qu'il faut retenir des nouvelles de l'industrie aujourd'hui.

 

A la recherche d’une déconstruction critique du jeu vidéo: Stranglethorn Vale

 

Je ne lis quasiment jamais les critiques et autres tests de jeu vidéo : j’ignore royalement ces pages là dans Edge ou EGM, je ne lit jamais celle de 1UP ou des autres sites web, et je zappe ces passages dans 101% sur NoLife.

 

Ce n’est pas que la critique « traditionnelle » soit inutile ou insensé : elle fait parfaitement sens dans la fonction de guide à l’achat, et certaines sont même de façon surprenantes très bien écrites (parfois trop pour leur propre bien).

 

Non, le problème de la critique, c’est qu’elle n’est pas « constructive ». Ou plutôt pas assez « de-constructive ». La critique de jeu vidéo classique ne déconstruit pas, elle n’analyse pas, elle juge, et ce jugement ne m’apporte en pratique quasiment rien du tout.

 

Savoir que le visuel d’un titre mérite un 7 sur 10 parce que dans la moyenne des titres du moment m’est complètement inutile. Par contre, comprendre en quoi la direction artistique de tel ou tel passage du jeu s’inspire de tel ou tel artiste, ça, ça m’intéresse.

 

Critiquer les textes ou le doublage du jeu, c’est une chose. Comprendre en quoi l’emprunt à tel ou tel référent culturel ne fonctionne pas en est une autre, pourquoi l’écriture tombe à plat ou pourquoi les personnages sont creux, ça c’est « utile ».

 

Partager la joie et l’émotion que procure tel ou tel mécanique de gameplay dans un jeu, c’est intéressant. Mais comprendre pourquoi cette mécanique fonctionne, en quoi le layout des contrôles et le timing participe de l’émotion, quels principes sont mis en avant et quelles boucles de récompense entrainent le joueur, ça c’est constructif.

 

Bref, je ne lis plus les critiques de jeu vidéo depuis des années, non pas parce qu’elles sont nulles (et pourtant dieu sait quelles le sont souvent), mais tout simplement parce que ça n’est pas ce que je veux lire, ça ne répond pas à mon vrai besoin d’information.

 

Ce que je recherche, c’est une réelle déconstruction, une analyse qui va abstraire chacun des composants du jeu, en évaluer la masse en isolation, expliquer pourquoi le jeu en globalité dépasse la somme de ses composants (ou pas), expliciter comment les choses ont étés faites et éventuellement comment elles pourraient être améliorées, dresser la liste des références et des artefacts culturels qui vont que tel ou tel jeu s’inscrit dans tel ou tel sous culture, bref, faire un vrai travail d’analyse.

 

Certains studios se livrent à ce type d’exercice en interne, je suppose que l’on fait aussi ça parfois dans certaines écoles, il y a même quelques bloggeurs qui s’y risquent, quoi que souvent de façon très spécialisé dans un domaine ou dans un autre.

 

Un exemple: L'analyse du passage de Stranglethorn Vale dans World Of Warcraft, par Richard Bartle:

 

People who don't play MMOs seem to have a hard time believing this. Even people who play them can often have a hard time believing it. When I tell them that I, as a designer, will "read" what another designer is "saying", they'll usually indulge me but don't press the issue; it's as if they don't believe me, but are too polite to say so...


....


There are many means by which designers can say things to players, but the one I'm going to talk about here involves quests. Other elements play into this — the artwork and music for STV are wonderfully evocative of mood, for example — and of course there are particular gameplay elements that are hugely impressive, such as the way each class plays differently (well, played; it's not so great nowadays).


...


Another thing these early attacks from outliers do is establish a hunter/hunted duality. If you see one of the big cats (a panther) and decide to attack it before it attacks you, you'll aggro a whole bunch of other panthers and end up running for your life. It's effectvely a trap. You start off as the hunter, then suddenly find yourself as the hunted.


...


Something that All Designers Know is that quests to go and kill N mobiles of type X get less and less fun for larger values of N. The fact that we've not been asked to kill any animals for quests for ages, however, means that at this point players are really up for it. Are they, however, up to killing 90 of them?



Well no,probably not if you put it like that, but they're not actually
told that's what's in store. There are three quests initially: Tiger Mastery, Panther Mastery and Raptor Mastery. Each requires you to kill 10 of the named creatures: they're each the start of a 4-quest chain that involves killing 10 creatures of the same type but of a increasingly higher levels, ending with a quest to kill a boss. When you've killed all the bosses, you get a final quest to kill another boss.



So, basically we have the same kill-10-rats quest 9 times, plus the same kill-the-boss quest 4 times. It's just routine, right?



Well no, because these quests are
stepped: the levels appropriate for the tiger mastery steps are 31, 33, 35, 37; for the panther mastery steps they're 31, 33, 38, 40; for the raptor mastery steps they're 34, 36, 41, 43. The final boss is also 43, but elite (so "bring friends").

 

This interleaving allows for variety, and it despatches the players off to various different parts of STV where the target creatures lie, thereby causing happy interactions with other quests relating to areas they pass through. However, even though this is very well done, it's basically just well-accomplished craftsmanship. No, what we also have here is some actual art.



The stepped nature of these hunting quests mean that whatever level you first encounter the Nesingwary camp in STV, there's going to be a quest of an appropriate level for you. It's like a net, spread wide to catch players.



You saw that? A
net, spread wide to catch players?


...

 

[ (Ln(x))3 ]

 

strangle.jpg

A ma connaissance, il n’existe aucun média de référence, aucune base de donnée, aucun site dont le propos soit de se livrer à cet exercice périlleux, mais autrement plus enrichissant…

 

Si ce travail de déconstruction existe en littérature et au cinéma, pourquoi est-il encore si mal produit pour les arts ludiques ?