Splatch.

Les temps de build et de link sur un jeu étant particulièrement longs, on s’occupe comme on peut. Certains font du point de croix, d’autres montent des paris sur les chance de Noriega de creuver en prison avant d’être jugé, moi je dessine… Je commence par les builds courtes - entre 1 et 2 minutes - et je rassemble sur deux grosses images les portraits croqués (et parfois encrés) dans ce genre de laps de temps. J’espère que dans le tas, vous trouverez un ou deux trucs plaisants


Et un petit aperçu de ce que je mettrai demain :

Que ce soit une perle de journaliste ou de chef d’état, elle me fait bien rire :

Bon, on est d’accord, voir des politiciens juger des jeux vidéo auxquels il ne connaissent rien est énervant.
Voir les autorités de régulation bannir certains jeux, au lieu de faire comme pour les autres média et s’en tenir à une classification, est exaspérant.
Voir aussi l’industrie peiner à faire face à ce genre d’agissement autrement qu’en manifestant du mépris est inquiétant.
Réaliser que le principal débat sur les jeux vidéo fait s’opposer Erbert à Barker, deux gars qui sont peu représentatif des média qu’ils défendent est navrant.
Mais bon dieu, quel est le crétin decérébré et bourré de fric qui a commandé ce clip?
Please enable Javascript and Flash to view this Flash video.
Franchement, ya pas mieux pour se décrédibiliser que le carmina burana de l’ami Orff soutenant une grosse voix de merde qui débite des conneries aussi longues que mon bras. Et puis représenter le gouvernement et les critiques par des baddies de Frank Miller; ça, CA, c’est du tact à l’état pur.
Franchement, voter et choisir un plan de société en tant que gamer uniquement, vous trouvez pas ça complètement ridicule? Et dangereux ?

Après une longue et difficile journée de taf, les premiers paragraphes du dernier article de skaven n’ont pas eut grand chose à faire pour jouer au yoyo avec mon humeur.

D’abord, en voyant quelqu’un témoigner du côté routinier, solitaire et parfois minant du boulot de programmeur, j’ai eut ce genre de pincement au coeur qui jaillit lorsque, soudain, on ne sent plus seul dans sa condition de prolétaire. Il faut dire que démarrer dans les jv est une épreuve. Surtout lorsque, après un stage de 3 mois dans un studio indé, on pense croire être à peu près prêt .. et que, malgré la prudence, on se rend compte qu’on se surestime encore trop. Bref, le choc est rude ou, en tout cas, il l’est pour moi depuis 1 mois et demi : je galère encore tellement que je ne sais pas si c’est moi qui craint, ou juste la boulot qui demande quelques bon gros mois d’expérience pour voir la confiance monter.

Mais une fois la larme du sentiment d’appartenance écrasée, je me suis dis : sommes-nous vraiment à plaindre ? Est-ce vraiment différent d’une boite d’informatique traditionnelle ? Bien sûr, la majorité de l’ingénieurie logicielle jouit de conditions différentes : principalement un contexte technique plus posé et une façon d’aborder les problèmes moins affectée par les incertitudes. Mais il reste qu’on est pas moins anonyme chez CapGemini ou une quelconque SSII que dans une boite de jeu. La seule chose, c’est qu’on risque d’avoir glamourisé les métiers techniques de manière artificielle, tomber de haut et le mériter … un peu.

Puis le truc qui m’a définitivement fait tiquer, c’est que quelqu’un comme skaven - qui semble avoir roulé sa bosse dans l’industrie - se retrouve encore à faire principalement du dev sur des shadow et du moteur de sons. C’est d’autant plus étonnant que l’industrie crève d’avoir des gens expérimenté dans le domaine. Alors, je me suis dis que c’était sans doute une affaire de choix.

Un choix de domaine d’abord : peut-être est-ce parce qu’il a choisi de s’orienter vers le "bas niveau", vers la 3D plutôt que le gameplay ? Chez Monte Cristo - chez qui je fais mon stage - ils ont généralement sur chaque projet un Lead Programmer, qui fait de l’architecture, qui prévoit les évolutions du moteur pour les nouveaux besoins et qui encadre leur implémentation, des programmeurs 3D/graphismes/technos de base et des programmeurs gameplay. L’évolution entre les postes se fait naturellement, selon la volonté et les compétences de chacun… il me semble que c’est une des pratiques fréquentes de l’industrie, mais je peux me tromper. Le seul moyen de vraiment se planter c’est de croire que programmeur gameplay, c’est mettre en pratique le game design. C’est faux : gameplay programmeur, c’est mettre en place la structure technique pour soutenir ce design et donner des points d’entrées aux game designers. Dans le meilleur des cas, les designers et artistes ont confiance, et ils permettent aux programmeurs de faciliter leur boulot mais la plupart du temps, on se cantonne à ne pas leur rendre leut tâche plus difficile. Avec les game designers, au mieux, on se mute en tools programmer, mais la solution universelle, c’est de déléguer à des scripts sur lesquels ils bosseront. Mais bon, je défie quiconque d’aller crier à la publicité mensongère : les compétences en terme de game design ne sont pas à aller chercher dans la partie technique des jeux vidéo, les programmeurs n’ont donc pas vocation à y toucher. Enfin, c’est comme ça que je le vois.

Il y a aussi le choix de la boite dans laquelle on bosse. Skaven dit avoir dernièrement bossé pour un studio développant un 1er titre pour la PS3, et là dedans il y a deux fortes raisons pour un programmeur dans cette situation de se retrouver loin du gameplay.
1 - une plateforme jeune avec des contraintes techniques énormes: ça veut dire lutter avec l’architecture et les rootkits en faisant un peu office de pionnier dans le domaine.
2 - un premier projet : choisir d’être programmeur sur le premier projet d’une nouvelle boite pour une plateforme naissante, c’est savoir qu’il faudra - faute de financement, de temps ou de confiance - substituer du code proprio à des middleware existant. En plus, il faudra sans doute assurer la technique avant de parler de gameplay… ne serait-ce que pour avoir une vision de la planification du projet.

Et puis, si cette boite n’est pas jeune mais qu’elle n’a pas la philosophie de construire sur des acquis; si elle pert sa mémoire technique à chaque titre ou plateforme (et ça semble être le cas dans 50% des boites)n il y a de fortes chances que les programmeurs se retrouvent à recoder les fondations techniques à chaque projet. Là encore , j’ai la chance de bosser dans une boite qui capitalise sur le même squelette de moteur multi-genre depuis 2001 (depuis fire Department en fait) et les boulot de bas niveau ne sont pas légions. Donc bon, à moins de vouloir bosser dans les jv au point de prendre la première offre venue, il y a moyen de trouver une entreprise qui sache capitaliser et qui donne l’opportunité d’approcher les features du jeu de plus près.

Cependant, le problème est sans doute plus large : mon impression est que l’industrie sous estime l’intérêt des ingénieurs à être mis à de vrais postes d’ingénieurs, de mettre des gens expérimentés à des places autres que celles de techniciens experts. En fait, les positions en haut de l’échelle technique (technical director, par exemple) semblent réservées à un si petit nombre, que des profils comme celui de skaven se retrouvent sans doute coincés à des positions pour lesquelles ils sont surqualifiés. Du coup la plupart des projets - comme le mien - investissent dans des programmeurs stagiaires courtes durées (3mois) venat d’école d’ingé et qui serontdonc cantonnés à faire de la prog le nez dans le guidon.

Il y a donc bien des trucs dans l’industrie du jeux qui font office d’exceptions, mais ce n’est certainement pas une fatalité que de se retrouver à broyer du code pour des fonctionnalités purement techniques. Et le boulot d’ingénieur/programmeur y est alors intéressant. Voilà mes 2euros 50 qui viennent compléter - je l’espère - l’article de skaven.

Bon, j’aime pas trop utiliser mon blog pour ce genre de choses mais voilà : je suis actuellement l’heureux propriétaire d’un Seinnheiser 210 HD qui me suit de chez moi à mon boulot et inversement. Ca me lourde un peu et j’aimerais bien m’acheter un casque sans fil pour mi casa es su casa histoire de laisser le Seinnheiser m’attendre au taf.
Le MDR-RF800RK de Sony me paraît correct et j’utilise sciemment le terme ‘paraît’ parce que jusqu’à aujourd’hui je pensais que le principal facteur de comparaison entre casques était la valeur en dB filée sur les boites… mais pour les 3/4 des fiches online, cette valeur n’est pas précisée et je suis désormais perdu.

Vu que je suis content de mon avec-fil bas de gamme actuel, est ce que vous pensez que je saurais me satisfaire dece sans-fil ]? Si vous avez des conseils de sans fil pour 45 euros max, je suis preneur.

Merci beaucoup d’avance.

Ah, et puis depuis 1 mois et pour les 5 mois qui viennent je revêt la tunique de gameplay programmer sur une extension à Silverfall.

Durant ce premier test fait rapidement, je suis tombé amoureux de la fonction " Teinte/Saturation" de ‘toshop … je me sens sale, maintenant.

J’aurais aimé lui faire un aspect plus cadavérique et un peu plus hippie cradouche mais ça risque d’être chiant à animer par la suite.

Hop, je m’occupe comme je peux tandis que la DE de mon école s’active péniblement entre les rouages de l’antique usine bureaucratique qui lui sert d’appareil de validation de stage… et j’ai fais la line (un peu aliasée, certes) du personnage de Clara présenté plus tôt.

Problème, comme j’ai des goûts de chiotte en terme de couleur (je sais reconnaître le bon goût, mais quant à le reproduire…), j’aurais besoin d’un coloriste volontaire avec qui j’établirais la charte graphique des persos et des décors. Je crois que ça peut être sympas, pour peu qu’on soit orienté cartoon et colo qui se prête à l’animation. Ceux qui veulent s’essayer à l’exercice peuent tneter de faire une colo pour Clara en regardant un peu le background du posté linké ci-dessus.
Et pis, si l’un d’entre vous pouvait aussi me diriger vers un cours online sur les couleurs histoire que je me fasse une éducation - j’en serais plus que reconnaissant.

POur seules qui veulent tester une version un brin plus équilibré avec du vrai contenu

————

Dernière en date… j’aimerais bien garder l’organisation : dernier article en gros + résumé des quatres précédents en petit, mais je me demande si c’est si lisible que ça.

———————–

Sur les conseils de tous j’ai modifié quelques trucs… je suis en train de voir tout ce qui est bouton et polices des images en ce moment.
Même consigne qu’avant : répandez votre bile caustique autant que vous pouvez. Ah, et je ne crache pas non plus sur les compliments… encore faut-il qu’ils soient mérités.
–Message original

Voilà en gros le look de LunaticGamers avec une colonne pour les trucs créatifs (dessins, projets de jeux, textes) et une autre pour les trucs réactifs (critique de jeux, de films, analyse, plop effects) puisque c’est pricnipalement deux axes de contenus qu’on pourra y trouver.
Bon,j’ai encore des trucs à régler au niveau des graphs, des icônes sur le côté à rajouter pour les sous catégories de réactif et créatif, réussir à centrer tout le site plutôt que d’avoir tout sur le côté et pis faire les css … mais au bout d’une journée de taf coolos, le plus gros est fait je crois.
Et ‘pis comme d’hab, des retours serait appréciés.

Après être revenu d’entretiens sur Paris - j’attendrais que d’avoir bouclé les paperasses pour vous en parler, mais j’ai une proposition de stage ultra intéressante - je me suis dit que le game design était assez avancé pour m’attaquer au code.

Et, hop, on se plonge dans PALib avec pour objectifs de comprendre la lib et de valider certains mécanismes de base de la partie puzzle : le déplacement des briques par le stylet, la physique et les collisions. J’ai réussi à remplir les 3 premiers en codant comme un crados sans trop de mal malgré une doc assez bordélique et carrément incomplète de PALib.

Après avoir réussi à afficher une brique, la déplacer, la lancer (à confirmer avec une vraie DS pour le feeling, mais j’ai la flemme), à la soumettre à une simili-gravité, une simili friction (toutes deux agissant grossièrement sur le vecteur vitesse de la chose) et aux collisions avec les bords de l’écran, j’ai décidé de mettre tout ça au propre avec des classes,etc… Après un gros blocage et des erreurs barbares dûs à l’oubli de renommer mon fichier main de main.c en main.cpp, j’ai réussi à reproduire mon comportement de quick & dirty en code propre avec classe et le tremblement.

Sources et roms sont dispos sur le repository de Heads&Hands si vous voulez tester: le code sentira pour certains l’écurie mais ça devrait marcher sur DS et émulateur genre NO$GBA.

Et puis, je me suis dit, lançons-nous dans l’implémentation d’un semblant de moteur physique.
C’est là que ça a commencé à coincer : j’ai voulu mettre en place la méthode d’intégration Verlet corrigée ,censée être simple à mettre en place et marcher parfaitement.
J’en ris encore : en gros, en applicant la méthode à la lettre [enfin je pense : ajouter quelques champs dans la classe briques , gérer les dt entre frame, et ajouter deux lignes de codes] mon bloc tombe au ralenti vers le sol, n’y rebondit plus et lorsque je tente de le lancer, il ne fout rien la feignasse. Diagnostic ? Soit j’ai fondamentalement mal compris la méthode, soit j’ai des problèmes de grandeurs de forces. Les deux sont également probables mais après une bonne grosse demi journée passée dessus (preque autant que pour arriver au quick & dirty évoqué ci-dessus, pfiou), j’ai laissé tombé et recablé mon système rudimentaire pour me consacrer à la collision entre briques.

Et là aussi, c’est le bordel, notamment parce qu’à grande vitesse, d’une frame à l’autre les briques franchissent de grandes distances donc certaines collisions ne sont pas détectées. A côté de ça, même à vitesse réduite j’obtiens de mauvais comportements…ma méthode de correction de position est de toute façon pourrie. Le problème c’est que la méthode de détection/correction de collision doit faire une dizaine de lignes, donc je dois avoir de la merde dans les yeux pour ne pas voir d’où vient le problème.

Bref, va falloir que je travaille sur quatres choses :
1-créer des ‘volumes de déplacement’ représentant le mouvement effectué par une brique entre deux frame et que je teste l’intersection entre ce volume et les obstacles ‘possibles’ pour détecter toutes les collisions.
2-déplacer ma brique sur un vecteur liant la position n-1 à n pour la correction
3-réussir à inscrire du texte de debug sur l’écran du haut sans avoir les glitches graphiques que j’ai et des valeurs qui ne s’affichent pas.
4-Faire un projet NDS C++ u Tester tout ça sous un environnement VS avec du console windows histoire de gagner du temps

Bref, pas mal de choses en vue - à faire avec une tête plus froide surtout - mais pour l’instant je laisse reposer : demain ce sera plage et design de site web. Pour le site, je pense avoir une jolie idée et mon environnement de dev offline enfin installé (merci xampp/nvu version portable apps).
Je vous filerai un mockup screenshot dans la soirée ou demain pour avoir des retours.

Sur les conseils de Holi, j’ai agrémenté le design doc de faux screens pour expliquer la plupart des concepts : il m’en reste pas mal à faire ( surtout important pour la partie où l’écran tourne et pour le trivia games) mais j’aimerais bien avoir des retours sur ce qui est déjà présent.

Une version PDF et une version ODT se trouvent ici

Ah et le projet à un nom : Heads’n'Hands.

UPDATE : j’ai reformaté le document un peu mieux et j’ai rajouté des screens pour la description des effets d’une rotation.