Ok

En poursuivant votre navigation sur ce site, vous acceptez l'utilisation de cookies. Ces derniers assurent le bon fonctionnement de nos services. En savoir plus.

09/07/2009

Widescreen Games ferme...

Hé bien, ça ç'est vraiment pas une bonne nouvelle pour la communauté Lyonnaise (et pour l'industrie en France en général)... :(

20:16 Publié dans Business | Lien permanent | Commentaires (2)

Cable news: The shape of the industry...

  • La marque Eidos disparait: C'est officiel, Eidos est désormais Square Enix Europe. Hum... Autant je peux comprendre la logique de cette décision, si tant est que Eidos en tant que marque était relativement terni, ce nom avait pourtant encore pas mal de reconnaissance et de signification auprès du public...

09:53 Publié dans Business | Lien permanent | Commentaires (0) | Tags : eidos, square

07/07/2009

Tools of The Trade: Introduction to virtual machines and scripting languages

De nos jours, l’utilisation des langages de script en cours de développent s’est grandement généralisé, pourtant il suffit de mentionner le besoin de debugger une machine virtuelle (ou VM de son petit nom) pour en général envoyer des frissons glacés dans le dos de tout programmeur un tant soit peu sensé.

 

Retour sur un sujet plus ou moins à la mode, et en tout cas membre de la trousse à outil moteurs des jeux modernes.

 

Le langage de script (et la VM généralement associées) participent de la notion de moteur « data driven » i.e permettre de séparer la logique du jeu (règle, scénarisation, entité, IA…) de la logique système (rendu, inputs, gestion des assets…). Dans un monde idéal, et si on pousse cette logique au bout, le langage de script doit permettre de décrire n’importe quel type de jeu avec le même moteur (ce qui reste à ce jour une complète utopie).

 

Pour ce faire, au fond, peu importe le langage. Javascript, Python, Lua, même Lisp, ils ont tous des avantages et des inconvénients qui doivent être mesuré au regard de considérations comme la productivité, la lisibilité, la maintenance ou les performances de la VM. Si l’idéal cité plus haut est l’objectif, plus le langage sera générique (et donc expressif), plus l’on pourra décrire de jeu différent.

 

Mais ce n’est parfois pas la bonne voie.

 

Après tout, à quoi bon prendre un langage de script si il faut qu’il soit « Turing Complete » ? Autant garder le bon vieux C ou C++. Du coup, il y a une autre approche qui tient plus du « Domain Specific Langage », ou DSL pour les intimes.

 

L’utilisation d’un langage de script propriétaire (Unreal Script par exemple) trouve une origine simple : pour développer un jeu moderne, on a besoin de manipuler un certain nombre de notions de haut niveau qui sont plus ou moins liés aux spécificités du moteur ou du game design, notions qui ne sont tout simplement pas disponible de façon native dans des langages plus bas niveau comme le C ou le C++, ou plus générique comme LUA.

 

Décrire de nouveaux types d’acteurs en les composant plutôt qu’en les dérivant, abstraire et nommer des notions spécifiques au gameplay, ajouter des meta data avec des mots clefs qui serviront pour l’édition ou le streaming ou la sérialisation ou la sauvegarde ou encore la réflexion, créer des structures de contrôles permettant de décrire des machine à état (Finite State Machine) ou un système de messagerie nativement supporté par le langage, etc etc…

 

Le langage propriétaire permet de façonner les scripts pour intégrer toutes les notions haut niveau spécifique au domaine du jeu, ce qui est parfois plus délicat avec des langages génériques. C’est en cela qu’ils tiennent plus des DSL, mais le jeu en vaut parfois la chandelle.

 

Dans tout les cas, on se retrouve dans la grande majorité des choix de langage à devoir générer du bytecode (version compilé des scripts), bytecode qui sera exécuté en temps réel dans le jeu par une (ou plusieurs) machine virtuelle. Et c’est là que la magie opère.

 

Comme son nom l’indique, la VM n’est ni plus ni moins qu’une émulation d’un système qui n’existe pas dans la réalité. Comme toute machine, la VM est souvent doté d’un certain nombre de registre, d’une stack d’exécution, d’un système d’interruptions, d’un gestionnaire mémoire (si les allocations sont permises) etc etc. A ce titre, le bytecode lui opère comme de l’assembleur classique que l’on exécute grâce à la VM.

 

Du coup, le bytecode devient lui-même donné, au même titre que toutes les autres assets (assets que le bytecode peut être amené à référencer dynamiquement). En séparant le code logique du code système, on augmente la stabilité et la réutilisabilité du moteur, et, si tout se passe bien, l’expressivité et la productivité du programmeur script. Et dans certain cas, on permet peut être même de supporter le live editing des scripts (après tout, le bytecode n’est qu’une donnée comme une autre).

 

Mais évidemment, tout cela à un prix. En premier lieu, le bytecode va obscurcir ce que le jeu doit faire du point de vue du moteur. Sans un bon outil de debug du script, bonjour les nuits blanches. La VM elle-même est un composant complexe, peut être l’un des plus délicat à l’œuvre dans le moteur, et debugger son fonctionnement est en général assez intimidant.

 

Le compilateur de script générant le bytecode, étant en principe dissocié des considérations hardwares de la machine, ne peut pas effectuer beaucoup d’optimisations efficaces (à la différence du compilateur C ou C++). Et d’ailleurs, ce n’est pas forcément son propos : la VM agissant comme une couche d’émulation sur le hardware, il ne faut pas en espérer grand-chose du point de vue des performances.

 

Du coup, il est parfois primordial de garantir que seul du « code froid » soit décrit en script (code exécuté peu de fois par frame), à l’opposé du « code chaud » (implémentation d’algorithmes faisant appels à des centaines de boucles par frames et/ou nécessitant l’accès à une masse de donnée conséquente). En script, on cherche plus à décrire des structures de données qu’à implémenter des algorithmes complexes.

 

Implémenter le pathfinding ou la gestion des listes de rendu en script n’est pas la meilleure façon d’obtenir le frame rate optimal.

 

Et je n’ai abordé là que les features les plus simples d’un langage de script.

 

Parfois, on veut pouvoir faire appel à une méthode moteur directement depuis le script, ce qui implique encore plus de travail en terme de RTTI. L’inverse est vrai aussi d’ailleurs, puisque l’on peut désirer que le moteur face appel à une routine script depuis le code C.

 

On peut souhaiter suspendre l’exécution d’un script, le temps que le moteur effectue un calcul complexe (collisions, IA avancée), puis reprendre le script là où on l’avait arrêté. Enfin, on peut aussi imaginer de décrire des portions de code parralèlisable, comme deux FSM travaillant sur deux entités différentes par exemple.

 

Pire, certains langages permettent d’insérer directement dans le script du code C ou C++, ce qui implique que le jeu doit être compilé en plusieurs passes (compiler le script, puis compiler le jeu).

 

Bref, si la VM part d’une bonne intention, c’est aussi probablement l’un des composants les plus problématique dans un moteur moderne, et en tout cas l’un de ceux qui peux monopoliser un temps de développement conséquent. Après tout, c’est le cœur du jeu en principe.

 

Personnellement, pour mes outils de prototypage, j’ai choisi une autre approche.

 

Je fais en sorte que le langage de script que je défini puisse être compilé en code natif C et C++. Ca me permet d’effectuer toute une passe d’optimisation et d’extraction d’informations en amont, tout en bénéficiant de la facilité de debug et de liberté d’implémentation dans le moteur.

 

Le code ainsi généré ne matche pas celui du script à 100%, les abstractions moteurs ne sont pas forcément équivalentes à celle de mon script, mais le process de conversion est suffisamment simple pour permettre d’annoter le code afin de permettre un debug tout à fait raisonnable, sans sacrifier mes performances.

 

Et vous, quel est votre approche ?

06/07/2009

Cable news: The shape of the industry...

22:39 Publié dans Business | Lien permanent | Commentaires (4)

Unsung heroes: le son dans les jeux

Ce n’est un secret pour personne : le son est et reste encore et toujours la 5ième roue du carrosse dans les jeux vidéo, et ce malgré la popularité grandissante des bandes originales des jeux.

 

Affirmer pourtant l’importance de la bande son confine à l’évidence même : la musique en général reste le média le plus universel (et ce malgré les déboires économiques de l’industrie musicale), et le son est l’outil le plus efficace pour donner vie à n’importe quelle image synthétique.

 

Allez y, coupez le son pendant un film, chef d’œuvre ou film de série Z, même un film muet, et regardez jusqu’au bout. Et vous comprendrez pourquoi le son est une composante intégrale du média.

 

Alors pourquoi est ce que le son est si mal (ou si peu) considéré ?

 

Pour comprendre ça, il faut se pencher sur les contraintes liées à la sonorisation des jeux. Dans les jeux, la bande son va remplir plusieurs offices.

 

En premier lieu, comme au cinéma, le son a pour but de convoyer l’émotion et donner corps à ce qui se passe dans la scène en bruitant l’environnement et les interactions avec les objets. L’objectif est clairement de participer à l’immersion, ce qui implique non pas d’avoir les sons les plus réalistes mais plutôt les plus crédibles (et non, les lasers dans l’espace ne font pas piou piou).

 

Mais à l’inverse du cinéma, il n’y a pas de linéarité dans le déroulement d’un jeu : l’environnement sonore varie dynamiquement en fonction des actions du joueur, impactant les effets sonores ou la musique. De même, la bande son doit aussi lutter contre une certaine lassitude engendré par des sons répétés sur 10 ou 12 heures de jeu.

 

Par exemple, on parle de « barking » ou aboiement dans un jeu ou les ennemis vont continuellement interpeller le joueur en poussant divers hurlements ou petites phrases assassines. Si on n’a pas travaillé sur la diversité, gare à la lassitude qui détruit l’immersion.

 

Pour aller encore plus loin, le son peut aussi remplir un rôle fonctionnel en terme de design : les différents sons dans l’interface guident le joueur dans ses choix, les jingles et autres rappels sonores peuvent associer des informations de gameplay (zone dangereuse, ennemi en vue, point de vie dans la zone critique…), certains sons participent aussi de la mécanique de récompense du joueur (le son de victoire à la fin d’un combat, ou le fameux jingle quand Zelda ouvre un coffre).

 

Enfin, le son aide aussi à donner vie à ce que l’on ne peut pas créer en temps réel : un bruit de bataille étourdissant alors que l’on a que 20 entités à l’écran, la « walla » de la foule, tout les sons d’évènements majeurs qui ne sont pas représentés à l’écran mais qui existe dans l’esprit du joueur. C’est le coté « smoke and mirrors ».

 

Alors, déjà que ça n’est pas simple, mais vous devez aussi ajouter des contraintes techniques (budget mémoire, streaming entrainant un lag, gestion du pipeline, localisation des voix) ainsi que de performances (mixing, doppler et autres effets temps réels, occlusion dynamique…) : un vrai casse tête chinois.

 

Mais il y a pire ! Tout ça doit ce faire en parallèle de la production du jeu, en tenant compte des itérations et des modifications du gameplay et du setting, alors qu’au cinéma le son est une problématique de post production faite en même temps que le montage, ou même après, et par conséquent avec des contraintes visuelles définitives.

 

Du coup, non seulement le son n’est pas le plus populaire des chantiers de production, c’est aussi l’un des plus difficile.

 

Pourtant, il suffit de voir le succès des concerts comme le « Video Games Live » pour comprendre à quel point les joueurs y sont sensibles : le son n’est pas votre ennemi, c’est peut être même l’outil d’immersion le plus efficace qui soit, pour autant que l’on se donne la peine

 

19:10 Publié dans Game Design | Lien permanent | Commentaires (4) | Tags : son

05/07/2009

Nous, on joue à la guerre...

1.JPG
2.JPG
...

[ A suivre chez Mipou ]

Les mythes dans l'industrie du jeu vidéo...

Vaste sujet, n'est ce pas? C'est pourtant le propos de ce projet de livre:

 

We’re writing a book, tentatively named “Hit or Myth”, with the purpose of exposing pieces of incorrect (or, at least, partially-incorrect) conventional wisdom. Such conventional wisdom has been turned on its head time after time.

 

For example, until Tomb Raider came along, it was “well known” that male players wouldn’t want a game with a female avatar. But often these myths linger for years; we want to speed up this debunking process.

 

The book’s format will be a chapter devoted to each myth, with lots of commentary and examples of real experiences, demonstrating the fallacy of each myth. Our hope is that once this book is done, it will serve as a tool for otherwise powerless developers to use against clueless publishers (is that a redundancy?).

 

No more will a publisher be able to make a blanket statement to the folks in the trenches, such as “Everyone knows that ocelots don’t make good sidekick pets”, and we just have to meekly say, “Uh, sure, well, if everyone says that, I must be wrong.”


[ Hit Or Myth ]

 

Bah, il y aurait vraiment de quoi faire, non ?

04/07/2009

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

13:00 Publié dans Code | Lien permanent | Commentaires (0)

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 (3) | Tags : twitter

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 (1) | 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.