Blog ca suffit pas comme titre ?

Forged Alliance !

(Oui bon encore)

Si vous avez suivi mes deux derniers posts, vous savez de quoi il s’agit.

La première version de Forged Alliance Foverer vient de sortir !

0.2.0.0b : http://users.edpnet.be/zepilot/FAFovererLobby.msi

Plus de détails ici

Cette version patch également le jeu en 3604.

Pour ceux qui ne connaissent pas ou qui aimeraient découvrir, vous avez besoin d’une installation fonctionnelle de FA, patchée en 3599 (http://cdn.thqonline.com/SC/Patches/supcom_fa_patch_1.5.3596_to_1.5.3599.exe)… Et c’est tout.

Vous installez FAForever Lobby, vous suivez les instructions, et tout devrait bien se passer.

Pour plus de fun, vous pouvez nous rejoindre sur le mumble de canard PC !

N’ayez pas peur, il y a de tout les niveaux, même du tout petit nouveau !

En parallèle, TheBigOne (le frère de TheLittleOne, la star de starcraft 2 qui a débuté sur supcom) relance des tournois FA :

La première édition est dispo en VOD ici :
http://www.regame.tv/vod/5456 et http://www.regame.tv/vod/5457, avec une intro pour ceux qui viennent de starcraft. Un petit succès qui a ramené un peu plus de 250 viewers.

Cet article est très largement basé de cet excellent article.

Je voulais intégrer une feature qui donnerait à mon projet un gros avantage par rapport a GPGNet, et le plus rapidement possible.

Quand on veut classer des joueurs sur un ladder, il y a plusieurs systèmes bien connus et éprouvés. Le plus connu, et utilisé sur GPGnet, restant le Elo.

La grande question a laquelle essaient de répondre ces systèmes est “Comment mesurer le “skill” d’un joueur ?”. Autant pour un sprint c’est facile (suffit de mesurer le temps), autant sur un RTS, c’est bien plus complexe.

La réponse la plus simple serait de comptabiliser le nombre de victoires et de défaites. Mais ca ne serait pas juste pour ceux qui jouent beaucoup ou peu. On peut évidemment ne prendre en compte que le ratio de victoires, mais ca ne serait pas juste pour ceux qui ne jouent que contre plus faible ou plus fort.

De plus, le but ultime, en plus de classer les joueurs, est de pouvoir leur offrir du challenge. Quelqu’un qui est correctement “matché” devrait avoir 50% de victoires. En fait, dans un système parfait, tout le monde devrait avoir ce ratio. Classer par pourcentage de victoire est donc impossible.

Ce qui nous importe finalement est de savoir si X est potentiellement meilleur que Y, et de donner une valeur a la différence de niveau. La valeur importe peu, tant qu’elle reste relativement correcte entre chaque joueur.  Ce qui nous importe, c’est de savoir la probabilité que X a de gagner contre Y, ou de perdre, ou de faire un draw.

Venons en aux échecs, pour qui le système Elo a été inventé. Une différence de 200 points entre 2 joueurs donne au mieux classé une chance de victoire 75%. 200 est totalement arbitraire : Ce qui importe, c’est que notre joueur X, s’il a 200 points en plus que Y, gagnera potentiellement 3 parties sur 4.

La courbe de probabilité de notre joueur X est déterminé par une gaussienne. Je vous laisse lire l’article linké au début de cette page pour des explications plus détaillées.

Les problèmes du système de calcul Elo sont les suivants :

- Il ne gère absolument les équipes. Une équipe est considérée comme un seul joueur, et il est impossible de transférer votre résultat en équipe sur votre valeur individuelle.
- Les draws sont considérés comme des demi-victoires, alors qu’ils veulent dire que le matchup était équilibré, ce qui a beaucoup d’importance dans le calcul de votre rating.
- Arbitrairement, une limite de gain ou de perte est attribuée selon votre niveau : Plus vous êtes bas, plus vous pouvez gagner, afin d’artificiellement permettre au système de plus vite vous classer.
- Ce système souffre d’inflation : Même avec la limitation de points, les premiers vont continuer à grimper alors que leur niveau n’évolue pas.

Mon idée pour le projet était d’offrir un système qui classerait les joueurs, même pour les parties customs, afin de permettre de faire des parties équilibrées, sans entrer dans un système compétitif de ladder. En gros, éviter de se faire traiter de noob sans raisons :)

Du coup le ELO était hors de question, il me fallait un système qui gère au moins le jeu en équipe. D`où TrueSkill.
L’algo de Microsoft a plusieurs avantages sur l’Elo :

- Il gère aussi bien le 1 vs 1 que le 6vs6 ou le 2vs2vs2vs2, ou le FFA complet. Chaque équipe est composée du skill de chaque joueur participant,  cette entité a ses propres probabilités de gagner, et le résultat de ces probabilités est correctement redistribué aux joueurs. De plus, il ne fait pas que comparer deux joueurs mais une chaîne de joueurs.

- Les draws sont correctement gérés. Tout d’abord il tient en compte le milieu de jeu : Si une carte a une probabilité de draw de 90% (calculé selon les parties jouées dessus), le fait que vous gagnez a beaucoup plus de sens que si vous avez battu le même adversaire sur une map ou la probabilité de draw n’est que de 10%.
A l’inverse, faire un draw sur une map où la probabilité d’en faire un est faible rapprochera plus les joueurs l’un vers l’autre.

- Il ne triche pas. Chaque rating prend en compte le skill du joueur, mais aussi le degré d’incertitude (voir l’article de Moser ou le wiki sur les gaussiennes). Une fois votre niveau atteint, il devrait rester stable.

- TrueSkill permet, comme Elo, de calculer si un match est équilibré. Sauf qu’il peut le faire pour des équipes, et du coup il est facile de calculer quelle est la meilleure combinaison d’équipe possible pour avoir un bon match !

On m’a souvent cité Dawn of War 2 comme contre exemple du trueSkill. Il faut cependant prendre un compte que les développeurs n’y ont certainement rien compris :

- Le range trueskill “normal” s’étant entre 0 et 50 avec une moyenne a 25. (J’utilise pour ma part 1500 comme moyenne pour correspondre a GPGNet). Avec une plage aussi petite, il est évident que les chiffres derrière la virgule sont très importants.

Souvenez vous de mon exemple des échecs : Si 200 représente 75% de chances de gagner aux échecs, sur un TrueSkill de 0 a 50, une différence de 4,16 représente 80% de chances de gagner !

Il est évident que supprimer les chiffres derrière la virgule est ridicule et retire tout l’intérêt du système.

Par exemple, en faisant quelques tests rapidement, deux personnes rankée 30 sont en réalité rankées 29,62 et 30,41, et que celle a 30,41 a 15% de chances de gagner sa partie contre celle a 29,62.

TrueSkill est déjà intégré à mon projet, qui atteint doucement le stade de la première Beta..

J’adore les RTS.

Le problème, c’est que j’aime pas trop les RTS “tactiques”, et il n’y a quasiment que ça sur le marché,
Ruse est trop lent pour moi, les Total Wars par assez dynamiques.

Reste StarCraft 2, sûrement très bon, mais qui m’a fatigué au bout d’un mois. Il remplace trop la réflexion par les réflexes.

Non, le seul bon compromis, le seul jeu qui gère les 3 espaces de combats correctement, tout en étant nerveux, c’est pour moi Forged Alliance.

Pour ceux qui ne connaissent pas, c’est un add-on a Supreme Commander, le fils spirituel de Total Annihilation. Il corrigeait pas mal de problèmes de Supreme Commander, notamment en recentrant le jeu sur la prise de terrain. (Là où Supreme Commander 2 est hélas revenu a un modèle plus starcraftien).

Pour les fans de Starcraft 2 qui liraient cet article, TheLittleOne (TLO) vient de FA, et a du l’abandonner en premier lieu pour starcraft 2 à cause du manque de suivi  de FA. (en un deuxième temps quand il est devenu bon, parce qu’il y avait de la thune à se faire :) Il était d’ailleurs bien plus impressionant sur FA du fait des possibilités accrues.

Le jeu gère en effet tout la balistique de façon physique, il est donc possible par exemple d’éviter les tirs, ou de détourner une tourelle ennemie de sa cible.
C’est aussi le jeu de la démesure, avec du Nuke, et les fameuses expérimentales (concept quasiment repris dans StarCraft 2 d’ailleurs).

En images qui bougent :

Jeu trop gourmand a sa sortie (plus vraiment un problème maintenant), jeu de niche, … Résultat, il s’est mal vendu et le support a stoppé assez vite.

J’avais déjà à l’époque tenté de le faire revivre en sortant un Community Balance Patch (avec l’aide de la communauté de moddeurs), qui a donné par la suite un nouveau patch de GPG, le 3603, hélas jamais sorti par THQ.

MAIS BORDEL !

Je veux continuer a jouer a ce jeu excellent ! Avec kekouse, on s’est alors demandé pourquoi a l’époque, le projet Galatic Wars (un metagame au dessus de FA) n’était jamais sorti en l’état, car il proposait des lobbys fait maison, et donc la possibilité pour les joueurs d’assurer le support.

Je me suis alors demandé quel serait la difficulté de faire un lobby à la TA Spring… Plus ou moins au meme moment, THQ avait répondu a la communauté en disant que c’était cool qu’on joue toujours a FA, mais qu’eux, ils assurent le service minimum et que c’est déjà  bien comme ça. Allez, banco alors, je sors Eclipse !

Je choisis d’abord de tester le protocole réseau en python, vu la rapidité de prototyping (pas besoin de compiler, et le language est très permissif tout en ayant une TONNE de libraires pour tout et n’importe quoi).

Premier tests, premier paquet envoyé d’un serveur ultra basique vers le jeu :

25 Juim - Premier paquet

Les paquets sont encodé en little-endian, un integer pour la taille du header, puis un integer pour chaque donnée.

“Super !” bon, on regarde les commandes nécessaires pour créer un lobby :

27 Juin - Premier lobby

Banco !

Bon, là, c’est viable. On a besoin d’un chat pour le lobby, je décide de ne pas chercher midi à 14h et d’utiliser IRC.

29 Juin - Test de l'irc

Pour la partie graphique, je décide d’utiliser QT, disponible en python via un wrapper : pyQT. Ça a l’avantage d’être toujours rapide à coder, tout en proposant des fonctions avancées tournant en c++ bien rapide.

Je peux également, plus tard, recoder “facilement” en c++, vu que je me base le plus possible sur QT et le moins possible sur python et ses libraires customs.

30 Juin, gestion du login avec base de donnée MySQL sur le serveur.

Le serveur est lui aussi codé en pyQT en QApplicationCore (pas d’UI) - Fonctions de threading haut et bas niveau, fonctions réseaux simples et puissantes.

4 Juillet, première connection deux joueurs.

La première Alpha est prête deux jours plus tard.

Je vais dans cet article me concentrer sur la partie serveur, dont voici la structure :

Pas la peine de me dire que j'ai pas les bonnes conventions, j'y connais rien en organigrammes, j'ai fais joli.

Au lancement du server, il spawn deux socket entrant, un pour le lobby, un pour FA.
Il se connecte à la DB, et passe la connexion à ces deux entités.
Il crée également une entité “players” et une entité “games”. Eux même contiennent une entité “player” et “game”.
Il passe également “players” et “games” aux deux serveurs “lobby” et “Fa games”. (quand je dis passe, pensez plutôt à des pointeurs mémoire en c++ : il renseigne le thread où se trouve ces infos en mémoire, elles sont donc communes à toutes ces entités)

- “Players” contient la liste entière des “player”. Un “player” est créé à chaque connexion entrante, et liste son état (rien, lobby, en jeu, cherche un ladder,…), son login, ip, gameport …
- “Games” contient la liste entière des “game”. Un “game” est créé à chaque fois qu’un joueur host une partie. Il contient le nom de la map, .. Et une liste de “player” dans l’entité “game” en cours.

A chaque connexion au lobby, un thread est créé. L’entité “lobby” lui passe un lien vers la DB, la liste des “players” et des “games”.
Ce thread est autonome, mais peut communiquer avec les autres threads via la DB ou les entités “players” et “games”. (Grace a QT, je peux gérer les locks/mutex de façon très très simple).
C’est ce thread qui créera les entités “player” contenue dans “players” ainsi que les entités “game” dans “games”.
Chaque thread est intimement lié à sa propre entité “player”. Elle est unique et invariable pour chaque thread. Il est aussi unique : un “player” ne peut pas appartenir à plusieurs threads (je m’en assure via un numéro de session unique pour chaque joueur)

A chaque connexion au FA Server, un thread “FA Game” est aussi créé.
Ce thread est censé être créé à la suite d’une action “HOST” venant d’un thread “Lobby”.
Pour savoir qui est l’entité “player” responsable, il interroge les “players”, et regarde ceux dont l’ip correspondent à l’adresse de la connexion qu’il reçoit.
Si cette IP est inconnue, il rejette la connexion.
Pareillement, si l’entité “player” trouvée disparaît (son thread est mort parce que le joueur déconnecte du lobby”), ce thread se ferme également.
Chaque thread “Fa Game” est intimement lié à une entité “game” qui lui est unique. Pour savoir à quelle entité “game” il appartient, il interroge la liste des “games” et cherche si le joueur précédemment trouvé en fait partie.
Contrairement aux threads “lobby”, plusieurs thread “game” sont liées à la même entité “game”. Si un thread ferme, il n’entraîne pas la disparition de l’entité “game”, sauf si c’est l’hôte qui quitte.

Les threads me permettent de traiter les demandes simultanément plutôt que consécutivement pour chaque joueur.
Chaque thread a sa propre “bulle” mémoire, et si quelque chose de bizarre se passe dedans, si un bug se produit, et que le thread meurt, il n’entraînera pas la chute de tout le système.

Ça me permet également de mettre à jour le code à la volée.
Le code “server” et les deux codes “FA lobby server” et “FA game server” sont in-changeable sans redémarrer le serveur. Par contre, ils ne font qu’une dizaine de lignes et n’ont pas varié depuis le premier jour.
Je peux updater par contre le cœur du système, le code de chaque “thread”, à n’importe quel moment : Un thread en court ne variera pas, mais les nouveaux threads créés vont utiliser le nouveau code.
Je peux également updater le code des entités “games/game” et “players/player”, sans soucis autre que le possible crash de threads utilisant l’ancien code, et recevant ou ne retrouvant pas des fonctions. En pratique, c’est rare que ça arrive.

Infos supplémentaires :

Ma roadmap : http://bitbucket.org/thepilot/falobby/wiki/RoadMap

Le lobby est pour le moment en alpha. Je ne posterais pas le lien ici car j’estime qu’il n’est pas encore pret pour le “grand public”, mais si vous êtes intéressés, c’est facile a trouver sur les forums de GPGNet ou Canard PC.

Le prochain article traitera du matchmaking et plus particulièrement de TrueSkill.

Minuscule, c’est une série d’animation 3d dans des décors réels. créé par Hélène Giraud et Thomas Szabo.

Pour ceux qui ne connaissent pas, la première saison est en partie disponible sur youtube et dailymotion.

La saison 2 est sur le point d’être diffusée, et elle s’annonce d’encore meilleure qualité (Et je ne dis pas ça parce que c’est nous qui la réalisons :)

On clique sur la vignette pour le trailer !

(Je ne parlerais ici que des moteurs de rendu utilisé dans les productions de films)

La gènese de Renderman.

Il y a 25 ans naissait Pixar. Je vous laisse lire cet article de 3dvf, qui fait le lien avec l’historique de son célèbre moteur de rendu Photorealistic Renderman que je vais vous raconter ici.

Début des années 80.

Afin de remplacer le traitement optique des images, LucasFilms, sous la houlette de Ed Catmull, créa une suite logicielle, composée de Pixar-2D, EditDroid et Pixar-3D.

Pixar-3D était une architecture hardware de traitement d’image de synthèse.
La partie software de cette architecture s’appellait “REYES”, pour “Render Everything You Ever Saw”. Une première version fut utilisé dans la séquence “Genesis Project” de Star Trek : The Wrath of Khan et le chevalier sortant du vitrail de Young Sherlock Holmes.

John Lasseter rejoindra ensuite LucasFilms, et sous la demande de Ed Catmull, expérimentera l’animation assistée par ordinateur. Quelques mois plus tard naissait le court métrage “The Adventures of Wally and Andre B”.

En 1986, Pixar nait de cette division 3d de LucasFilm, rachetée alors par Steve Jobs.

Pixar-3D fut renommé “Reyes Machine” : Une machine de guerre composée d’un hardware hors de prix et de plusieurs extensions se chargeant de chaque partie du pipeline du Reyes software.

Peu de succès commercial, ils sortiront le RM-1 Project (RM pour Reyes Machine), une machine moins chère censée remplacer le premier “Reyes machine”.

Pour anecdote, une des idées était que la Reyes Machine devienne aussi petite qu’un walkman, avec des lunettes de projection.

Mais la vraie idée sous-jacente de ce projet  était d’avoir une architecture unifiée “à la” Silicon Graphics (avec son hardware GL - Graphic Language), et Pixar commença donc les travaux sur la next-gen du GL : le RI  Rendering Interface).

Par la suite, le RM du RM-1 changea pour RenderMan.

ILM fut l’acheteur principal de ces RM-1, et un groupe formé de grosses compagnies fut fondé pour supporter le “RI” comme le nouveau standard à adopter.

Steve Jobs, grand marketeux devant l’éternel, trouvait que “Rendering Interface” ne tapait pas suffisamment. Il fallait un nouveau nom. Le hardware et le software furent renommés “RenderMan”, “Renderman Interface”, “Renderman-1 Hadware” et “Renderman Toolkit”. Le hardware ne sortira jamais de beta, toujours dépassé par les nouvelles innovations en la matière.

Lasseter pendant ce temps réalisait “Luxo Jr” afin de démontrer la force de Renderman, tant techniquement qu’artistement.

Pixar lâcha la version suivante de sa suite sous le nom de “PhotoRealistic Renderman”, ou PRMan.

L’évolution de Renderman.

En 1988, Pixar publia les RiSpec 3.0, bien que le seul moteur de rendu au monde a utiliser ce standard était le leur.
Du moins jusqu’au milieu des années 90, où un étudiant de Cornell University du nom de Larry Gritz écrivit BMRT (Blue Moon Rendering Tools), un renderman gratuit.

BMRT incorporait une fonctionnalité que PRMan ne supportait pas (et ne suportera pas avant longtemps), le raytracing.

Pixar embaucha Gritz et utilisa BMRT comme moteur annexe afin de profiter de cette mini-révolution, notamment dans Bug’s Life.

Gritz fut aussi l’auteur du livre de référence Renderman :

En 2000, Larry Gritz quitta Pixar pour fonder Exluna, afin de développer Entropy, un Renderman basé sur BMRT incorporant des tonnes d’amélioration et d’optimisation (et pour ce que ce j’en avais testé à l’époque, il enterrait PrMan profondément). Exluna et Entropy furent rachetés en 2002 par Nvidia, alors que le soft n’était pas encore sorti.

Le vilain petit Pixar.

A la suite de ce rachat, Pixar lança une action en justice contre Gritz et Exluna, pour vol de technologie, copyright et autres secrets. Ces plaintes furent rejetée par Exluna, mais l’affaire acheva BRMT et Entropy qui cessèrent d’être développés.

Gritz et d’autres employés d’ExLuna restèrent chez Nvidia pour développer Gelato, un moteur de rendu utilisant principalement la carte graphique.

Gélato connu deux versions sans énorme succès. Il fut néamoins à l’origine de la création d’OpenImageIO (ou OIIO), une API de trairement d’image.

Le GPU en production.

La version 2.1 (nommée Sorbetto), cependant, fut testée chez Sony Pictures ImageWorks comme outil de relighting. Malheureusement, sa complexité et son manque interactivité sur des scènes complexes furent qu’il sera rapidement abandonné.

La version 3.0 (Mocha), encore plus centrée sur le GPU, permettant la compilation des shaders “on the fly” vers la carte graphique au moment du rendu, fut montrée au siggraph 2007. Il ne sortira jamais.

La déception.

Larry Gritz fut cependant embauché par Sony Pictures ImageWorks. Sony utilisa Entropy avant sa disparition, et était en recherche d’un nouveau moteur de rendu capable de les sortir des travers de Renderman :

Les problèmes de l’architecture REYES, entre autre, sont le manque de parallélisme, l’utilisation de calculs superflus et la redondance des appels au shaders, ainsi de la difficulté d’utiliser des géométries non rectangulaires.

Mais surtout, au fil des ans, Prman se devait de supporter GI et raytracing. Ce fut malheureusement au prix de la simplicité. La  gestion des point clouds par exemple, pour la GI ou le sub-scattering, bien que puissante, est lourde en temps humain et de pre-processing à mettre en place.

L’arlésienne.

En 2000, Marcos Fajardo créa un petit buzz en sortant une série de courts métrages mettant en scène pépé, un petit personnage façon pate à modeler, des robots de Star wars,..

Le plus impressionnant étant que le rendu était géré par un moteur qu’il avait lui même codé, basé exclusivement sur le raytracing et la GI : Arnold.

D’autres courts métrages utiliseront cette première version d’Arnold, notamment Fifty Percent Grey.

Arnold 1.0 était censé être commercialisé peu après, mais ne vit jamais le jour. Des rumeurs de sortie s’ébruitaient de temps à autre, mais la seule version jamais sortie était une intégration au logiciel Project Messiah, en 2002.

La rencontre.

Marcos fonda Solid Angle, et fut embauché par Sony Pictures ImageWorks, afin d’implémenter conjointement avec Larry Gritz Arnold à leur pipeline.

Le premier projet de Sony utilisant Arnold fut Monster House (2006), utilisé en temps que raytracer conjointement à PrMan.

Arnold se libérait des faiblesses de Prman, et le test de Monster House motiva Sony à continuer le développement. Arnold fut utilisé comme raytracer sur leurs projets suivants.

En 2009 sortira “Cloudy With a Chance of Meatballs”, premier projet utilisant Arnold comme renderer principal et unique. Suivra Eagle Eye, G-Force, Alice in Wonderland, 2012, Arthur Christmas et Hotel Transylvania (en production).

Arnold permettra de sortir les images en une seule passe, plus facile à gérer. La charge pour les artistes fut également allégée, avec la disparition des pré-process, et la réduction du nombre de lampes nécessaires. (Toy Story 3 comptait plus de 200 lampes dans certains plans, chacune demandant une passe de pré-process !)

Larry, Marcos et Sony feront un certains nombres de conférences et interview ventant les mérites d’Arnold :

• Siggraph 2010 “Global Illumination Across Industries” course notes by Marcos Fajardo: Ray Tracing Solution in Film Production Rendering
• Siggraph 2010 “Physically Based Shading Models in Film and Game Production” course notes by Adam Martinez: Faster Photorealism in Wonderland: Physically Based Shading and Lighting at Sony Pictures Imageworks
• Siggraph 2010 talk by Adam Martinez and Terrance Tornberg: Lighting and rendering Alice in Wonderland
• Siggraph 2009 talk by Danny Dimian and Karl Herbst: Practical uses of a ray tracer for Cloudy with a Chance of Meatballs
• HPG 2009 keynote slides by Larry Gritz: Production Perspectives on High Performance Graphics
• AWN Interview with Imageworks’ CTO Rob Bredow
• 3DWorld “How to Choose Rendering Software”
• AWN: 2012: The End of the World as We Know It
• fxguide 2012 interview
• CGSociety Interview with Danny Dimian, Color/Rendering CG Sup for Cloudy
• CGW Cloudy interview

Et maintenant ?

D’autres moteurs renderman on vu le jour depuis Entropy, tels que Air ou 3delight, tout deux utilisés en production de films (Renaissance, District 9,…).

Le futur, tel que le voit Larry Gritz et tourné vers le raytracing : le temps humain est bien plus couteux que le temps machine, et le temps machine ne cesse de diminuer quand le temps humain n’est pas compressible.

Le temps réel, bien que prometteur sur papier, a trop de contrainte physiques et software, et l’absence d’un standard tue toute viabilité en production.

Arnold est actuellement en beta test fermé,  toujours développé conjointement avec Sony, mais également utilisé par des boites comme PsyOp, The Mill, MPC, Luma Pictures (sur le prochain Thor), Blur, Mikros, Nozon (hmhm :)…

Quelques productions “Arnold” :

Quand j’ai entendu cette musique, je me suis que ça ferait trop bien sur un showreel. Du coup voilà :

(”HD” dispo sur vimeo. C’est  normalement toujours du PAL)

Celui de ma boite est dispo sur le site de ma boite pour ceux qui voudraient en voir plus.

Et j’en fais(ais) partie.

Le jeu m’a l’air d’avoir beaucoup de potentiel cependant, mais comme d’habitude chez GPG, ils nous ont sorti une démo en caca.

Tout d’abord il faut savoir que la démo se base sur une vieille build.

Les différences “sûres” entre la démo et la version finale qui sort la semaine prochaine :

Les teintes des factions

Le jeu a des couleurs playschool bien flashy. Palette justifiée finalement, car on a besoin de reconnaitre facilement les unités du terrain.

Cependant la saturation est bien abusée, alors que la version finale ressemble plutôt à ça :

Mais en plus bleuté et doré au lieu de vert.

Si vous voulez plus de preuves, on peut voir la bonne palette en vidéo ici

Et cette vidéo, même si elle montre une stratégie de merde, donne envie.

Et même sur les décors, tout est bien mieux.

Les dialogues sont mal écrits.

Bon, on sera tous d’accord pour dire que le scénario d’un jeu est rarement son point fort, mais il y a un vrai travail d’écriture.
Apparemment le jeu serait parsemé de référence historiques.
Le dialogue du “chef” UEF apprenant que la femme de Maddox est Illuminate serait donc une citation d’Himmler apprenant qu’un de ses Oberst avait une femme juive.
Le commandeur “un peu” Gay cybran, Gauge, cite de la poésie (et je ne m’avancerais pas sur laquelle, mes connaissances là dessus s’arrêtent à l’illyade et l’odysée d’Homère, de très loin).
Bref, ca casse pas trois pas à un canard, mais au moins au peu pas leur reprocher d’y apporter un peu de culture. (Et Gauge me parait complétement barré avec ses réflexions ironiques et son attitude abusée, j’adore)

Les fonctions manquantes.

Les arbres de recherches sont amputés, mais également les fonctions. Ainsi, la version finale comprend une fonction tant réclamée dans le premier, l’area command :

C’est une vidéo Xbox 360, mais cette fonction a été confirmée sur la retail PC

La démo montre également très peu de choses. C’est sans compter sur des petits malins qui ont tenté de rentrer en mode debug comme dans le premier, et ça marche.

Voici donc la méthode (et je quote Kekouse)

Appuyez sur la touche Windows et la touche F, un menu apparait.
Cherchez Game.prefs
Il va vous donner plusieurs possibilités (ou une seule si vous n’avez que cette démo comme jeu GPG)
Le game.prefs qui nous intéresse est celui de ce dossier:
C:\Users\(Ton nom)\AppData\Local\Gas Powered Games\Supreme Commander 2 Demo

Ouvrez donc le game.prefs avec un éditeur de texte et foutez ca à l’intérieur du fichier sur la fin

Code:

debug = {
	enable_debug_facilities = true
}

Sauvegardez et lancez la démo.
Sélectionnez une mission et faites désormais ALT F2.
Un menu apparait

Vous pouvez spawner n’importe quelle unité à volonté.

En faisant CTRL + SHIFT + R vous débloquez tous les points de recherche sur toutes factions. En spawnant des coms de chaque factions et en faisant mumuse y’a moyen de voir ce que le jeu à VRAIMENT dans les tripes.

Alors les plus par rapport à FA:
-Vous dites d’attaquer une cible, vous faites un ordre de mouvement et MAGIE…votre unité garde sa cible en mémoire
-Vous chopez un sous-marin vous donnez un ordre de mouvement et tout de suite après un ordre d’immersion…MAGIE il va sous la flotte sans interrompre son mouvement.
Plein de petits trucs qui sont des ajouts mineurs mais au combien attendu par les joueurs réguliers de FA

Voilà de quoi vous amuser, et découvrir des petites choses amusantes :

• Les cybrans ont tous des petits jumpjet, et c’est carrément amusant à utiliser.
• Chaque shield agit différemment. Les UEF bloquent tout, les aeons renvoyent les tirs balistique et ralentissent (mais laissent passer) les armes energétiques, …

Le jeu est complétement moddable !

et même bien plus que le premier !

Pour faire court, dans le 1 une grosse partie des fonctions était en LUA. Celles qui étaient dans le moteur même était pas modifiables.

Dans le 2, pleins de trucs sont en C dans le moteur.
Le lua appelle la fonction en C, la function en C calcule le truc prévu, et renvoie le resultat au lua. Plus rapide.
A priori c’est embêtant pour modder, sauf que non : on peut appeller une autre fonction en LUA plutôt que la fonction en C. Donc TOUT est potentiellement modifiable contrairement au 1 !

Pour ceux que ça amuse, la liste des fonctions lua :

http://chirmaya.no-ip.org/files/supcom2_demo_luadoc.txt

Les ranges sont petits !

Il existe déjà un mod qui double les ranges d’unités et retire l’auto track des missiles des bombers : http://filesmelt.com/dl/RangeScaleTest.zip
à copier à la racine du jeu, pas dans gamedata ou data.

Attention, ca rajoute pas mal de difficulté (et c’est pas un mal) aux missions de la démo.

Tout est trop grand ! On manque de place !

Un mec a déjà sorti un prototype de mod (si on peut appeler ça un mod, c’est 10 lignes de code) qui scale à 50% toutes les unités/bâtiments.. Oui c’est plutôt cool.

Et hop, un scale à la Supcom 1 !

D’ailleurs il est à noter que le plus petit batiment (la tourelle), a en réalité un tile de 2×2. Hmm.. Des ranges à 50%, des tailles à 200%, je suis le seul à voir un lien ? :)

Idem pour les lignes de portée trop grosses (une petite variable à changer), la nouvelle gestion de l’économie, qui n’est finalement que l’ancienne avec un mod noob-proof par dessus, assez facile de revenir en arrière.

Conclusion

Bref, de “ouille ouille”, je suis passé à “très impatient”. Sans parler du flowfield, qui même s’il n’est pas parfait est une grosse avancée.

Reste à voir la balance, et un hypothétique éditeur de map. En tout cas il me manque pas grand chose pour me faire oublier FA et passer sans regrets sur ce Supcom2 (et c’est un mec qui joue encore au ladder du 1 qui vous le dit)

Alors oui, tout ces trucs sont des mods, c’est pas “officiel”, mais rien n’empêche GPG de les inclure dans le multi de supcom2 si la demande est suffisante et justifiée (après tout, le dernier patch qui ne sortira hélas peut-être jamais pour FA est beaucoup du à sa communauté, et change radicalement la balance) .

GPG est très à l’écoute de ses joueurs, même s’ils ont un poil trop peu communicatif.

Dans le cas contraire, ça ne sera pas le premier jeu à avoir un “promod”, ou un mod hardcore. Sans compter que le système de ladder de steam sera bien plus flexible (sinon il y aura bien des ladders alternatifs starcraft-like)

Espérons donc un suivant satisfaisant, et n’oublions pas à quoi ressemblait la démo de supreme commander 1, et du jeu avant le passage de Forged Alliance. Voir même, si on va chez la concurrence, à quoi ressemblait starcraft 1 avant ses 10 ans de patchs.

Suite a une discussion sur un autre blog, on m’a demandé pourquoi je descendais Gimp alors que “c’est super”.

Je dois reconnaitre qu’à chacune de mes tentatives, gimp me semble de plus en plus une alternative au leader photoshop. Néamoins, dans une optique pro et un usage quotidien, de nombreuses choses m’empechent toujours de le considérer comme un concurrent sérieux. Détaillons.

(Je teste la dernière version dispo, à savoir la 2.6)

Petit détail, à l’install, Gimp est suffisamment prétentieux pour ne pas proposer de “unselect all”

Non, faut tout virer à la main..

Moi qui aime associer mes images à un logiciel de visu rapide, me voilà obliger de tout dé-selectionner.

On peut me rétorquer que si j’avais tout mes fichiers liés, il me suffirait de cliquer “Select Unused”. C’est vrai, mais ca m’arrange quand même pas. De plus, je me suis retrouvé avec la VF alors que mon windows est anglais, sans rien avoir demandé, soit…

La chose qui m’avait le plus choqué dans la version antérieure de gimp était l’absence de réglages pour les brosses. Il fallait selectionner une brosse pour chaque taille et flou désiré, anti-productif.

Cette fois, c’est gentil, ils ont pensé à la taille…

Ok c'est gentil, mais le blur ?

Un sur deux, c’est pas mal, mais rien que ça m’empechera d’utiliser gimp sérieusement. De plus, dans photoshop, un simple clic droit sur le l’espace de travail et hop, on peut régler flou et taille.. Sur gimp, non, il faut revenir dans la boite à outil.. Aie. J’aurais pu vivre sans flou si gimp avait ça, mais non…

Pourquoi répéter le menu du haut dans le menu contextuel ?? Qui s’en sert !?

Bon, mon deuxième plus gros point noir était la gestion des calques. La aussi il y a du mieux, mais c’est toujours pas ça.

Je voulais juste créer un calque moi :-(

Un clic sur nouveau calque, et ce dialogue apparait. Sachant qu’on crée des calques sans arrêt.. Bon, je suis mauvaise langue ici aussi, un shift-clic passe la boite. Mais pourquoi l’afficher par defaut !? ON S’EN FOUT DE LA TAILLE DU CALQUE.

Bon, ils ont supprimé la confirmation lors de l’effacement d’un calque, c’est déjà ça..

Vient la gestion des masques de calque (layer mask). Ici aussi, ca y est comme sur photoshop, mais toujours pas top.

Par exemple, sous photoshop, un simple shift clic désactive le calque. Ici c’est Ctrl, c’est parfait. Sauf que…

Le jeu du jour : Est-ce que ce masque est-il actif ou non ?

Sous photoshop, on a droit une belle croix sur le masque. Ici, le cadre change de couleur. Pas super lisible quand on a 50 calques…

De plus, pas moyen de lier/délier un masque à un layer..

Et évidemment, on a droit à la boite de dialogue lorsqu'on crée le masque.. Et ici pas moyen d'y couper ..GRRrr..

Dans les choses qui manquent, il y a evidemment les fabuleux calques d’ajustement (la dernière nouveauté utile de photoshop… il y a 4 ans..), ni les groupes de calques !!!

Et pas de groupes de calques, ni de masques sur les groupes, ni de fusion sur les groupes et pas toute la comp, c’est simplement rédibitoire. Ca me renvoie à l’ergonomie de photoshop 5.0 (si mes souvenirs sont bons), et c’était atroce dès qu’on dépasse 10 calques.. (C’est à dire tout les psd que j’ai).

En général, je check ces deux fonctions de base et je m’arrete ici parce que ça me suffit. Mais par curiosité, j’ai testé la 3ème option la plus utilisée, ctrl-T (transform).

Et comment dire… Dans photoshop, on selectionne un calque, on fait une selection, ctrl-T, on déplace/tourne/scale, enter, fini.

Dans gimp : On selectionne. Ensuite, il faut choisir son outil !!!!

On ne peut pas scaler ET tourner en meme temps, c’est l’un ou l’autre ! Heureusement l’outil déplacement est dipo dans les deux modes.. Mais il faut avoir un peu pivoté ou scaler avant d’y avoir accès !

Il y a peut-être un move tout court, mais pas trouvé..  Et puis même, pourquoi les séparer en 2 ou 3 outils !?

Heuuuu ?

Mais ça serait rien si la preview n’était pas imbitable. Ici, je tourne ma selection (le carré en pointillé). Le carré plein est ma selection tournée. Qu’est-ce qui me choque ?

Pourquoi je vois toujours ma selection d’origine ?
Pourquoi mon image de départ est toujours affichée ?

Parce que si j’applique ma rotation :

Hein ?

Ben oui, forcement, c’est normal. Sauf que je ne vois pas dans l’aperçu ce que sera ce resultat final !

Et le gros cadre qui fait une bouding box autour de ma selection, j’ai pas la moindre idée de ce que c’est.

En si, plus ou moins : visiblement, ma rotation est pas frezée, je peux encore la modifier (pas mal en soi). Sauf que là, l’affichage passe la porte de l’incompréhensible :

Gné ?

Ok, là, j’abandonne.

Je passe le fait qu’aucun raccourci clavier n’est setté pour les calques (ctrl-shift-U pour desaturer, ctrl-L pour level ?).

Gimp est malheureusement un outil créé par des programmeurs, pour des programmeurs. Ils peuvent ainsi se dire “regardez, en opensource aussi on a photoshop !”. Sauf qu’ils ont oublié que l’utilisateur final était graphiste, et que l’ergonomie était le point n°1 avant les fonctions.

Quand je vais dans les filtres, il y en a une chiée (un spirographe ? Un lava generator ? VRAIMENT ?). Vous savez combien de filtres photoshop j’ai utilisé en prod cette année ? 2. Le gaussian blur et le sharpen.

Le reste, c’est de le brosse et du calque, deux choses que gimp ne fait pas correctement.

Je profite de la disponibilité de la démo de Maxwell 2 pour faire une petite news :

http://www.maxwellrender.com/

Pas encore eu l’occasion de le tester en prod (notre moteur principal est un renderman), mais les premiers tests sonnent pas mal, sauf pour les materiaux refractifs flou, qui est le GROS probleme de maxwell.

Dans les nouveauté on notera la possibilité d’avoir des ombres nettes des points de lumiere dans les hdr (bug qui m’avait obligé a créer des rigs de lights maxwell), et surtout la disparition d’un bug tres embetant provoquant l’apparation d’une zone noire sur le bord de objets reflectifs flous.

Niveau temps de rendu, la meme scene sur la 1.7 et la 2.0, testée sur un amd dual 6 cores (12 cores donc) et un intel dual quad +- equivalent, on passe de respectivement 8 min 17 et 9 min 12 a … 5min 00 et 6 min 03. Sur un win 32 bits. Je suppose que la difference sera d’autant plus grande que la scene sera lourde..

Testé aussi sur un linux 64 (redhat-like 5.3), les temps sont malheureusement superieurs de 3 secondes.

Ils ont également mis a jour leur galerie avec quelques unes de nos prods :

http://www.maxwellrender.com/videos/album_advertising.php

(toute la premiere rangée).

Ca fait toujours plus plaisir de les voir la que dans la saloperie de TV.

Oui, plusieurs mois après toute personne normale vivant sur cette planète, je viens de voir transformers 2. L’histoire est tellement dense que j’ai du le voir en 2 soirées, mon cerveau étant incapable de processer autant d’informations en une seule fois. Et je n’y arrive toujours pas, il me faut mettre ça par écrit.

Personne n’a essayé de me spoiler le scenario. En fait, même quand je le demandais, je n’ai trouvé personne CAPABLE de m’expliquer le scénario. J’espere donc que ce décryptage vous sera ausssi utile à vous qu’à moi.

/!\ ATTENTION : SI CE FILM COMPRENAIT UN SCENARIO, LA SUITE SERAIT UN GROS SPOILER /!\

Tout commence alors que des militaires américains combattent des robots au japon avec d’autres robots. On apprendra plus tard qu’ils les combattent sur tout les continents, dans l’impunité la plus totale. America Fuck Yeah.

Encore une fois, de l'action claire et lisible.

On notera une phrase d’un robot “il est ici, je le sens”, nous apprenant que les robots ont donc le sens de l’odorat ET qu’ils puent grave.

Pendant ce temps, Sam Witmachin se prépare à entrer au collège, laissant sa copine et sa voiture-robot au garage. Car oui, alors que ses potes dégomment du robot japonais, le bumblebee se la coule douce à rien branler de ses journées.

A tout moment du film, un personnage peut se retrouver par dessus un autre personnage sans raison apparente. A vrai dire, à tout moment du film, un personnage fait quelque chose sans raison apparente.

Mais voilà t-y pas qu’en rangeant ses affaires, Sam retrouve un morceau du cube du premier film dans sa chemise ! Celui-ci chauffe dans ses mimines, tombe, et transforme sa cuisine en robot du futur. Par la meme occasion, il hallucine des symboles indéchiffrables qui le resteront même à la fin du film.

L'autre morceau restant est par contre dans une base militaire ultra-sécurisée, mais pas trop. On est jamais trop prudent ou pas.

S’en suit alors un dégommage en règle de robots dans le jardin, avec arrivée de la police et des pompiers, puis ils partent tranquilles au collège, et en France ou en Egypte pour les parents après.

"Alf ! Rentre dans le garage, je crois que les Ochmonek se doutent de quelque chose !"

Pendant ce temps, un mec du gouvernement US un peu plus malin que les autres se demande pourquoi on chasse encore le robot sur terre. On se le demande aussi jusqu’à la fin du film.

Il donne malheureusement toute sorte d’informations cruciales (et pourtant déjà connues de son interlocuteur) au téléphone, comme l’emplacement du cadavre du plus dangereux des robots (ben oui pourquoi le détruire?) ainsi que d’un bout de la boite magique du premier film.

Un robot géant sur orbite pirate malheureusement le satellite de communication, mais c’est pas grave, car le grand méchant était déjà au courant que le garçon a …. non, je vais trop vite.

Sam arrive à sa nouvelle école, remplie uniquement de bonnasses et de geeks.

Pour Sam, tout se bouscule. Dans une séquence où tout les acteurs avaient pour consigne de prendre de la coke avant le tournage : Sam découvre son collège, rencontre son compagnon faire-valoir/de chambrée -de 100m²- qui tient un site sur les robots (concurrent d’un autre site sur les robots qui est tenu en fait par l’agent secret du 1 qui pour garder les secrets secrets les met sur internet pour désinformer, oui oui madame, don’t trust the internet),  voit des symboles partout, voit aussi plein de bonasses, se fait draguer par un robot-bonasse, suit un cours donné par un prof nympho, parle en symbole bizarre, voit des filles en double,

La fille blonde passe une fois ...

Et une deuxième. C'est suremment la chose la plus intriguante du film.

fait un tour en voiture avec le robonasse en bumblebee qui est revenu parce qu’il sait que ça sentait le roussi cette histoire (mais lui par contre il sent pas l’autre robot), rate une session sexcam avec sa bonasse qui va donc faire 300km pour le rejoindre (heureusement, elle gère le teleport), et le sauver du robot bonasse qui a une queue qui sort de son cul en lancant une boite en carton dessus.

Lancage de boite ...

.. Et teleport dehors en sécurité.

Ouf. Oui mais c’est pas fini, car pendant ce temps :

5 robots descendent dans la flotte récupérer le gros vilain du 1. Ils sacrifient un des leurs pour le ressuciter, et les 4 autres remontent donc à 6.

Un autre robot-billes récupère le bout du cube de la base militaire top sécurité mais pas trop. A noter que ce morceau ne servira absolument à rien.

Une autre scène troublante à Paris.

Je pense aussi que c’est à ce moment là que le gros méchant qui habite sur Jupiter se rend compte que le cube est dans la tête de Sam. Et le morceau de sa veste qui ne servira plus du tout non plus “mais c’est important de le garder” a réactivé le cerveau de Sam.

La copine de Sam va aussi capturer un petit robot méchant qui va en fait devenir gentil, puis ne servir à rien dans la suite du film.

Ha oui, et Optimus Prime meurt plus ou moins à ce moment là, mais on s’en fout un peu.

Le méchant décide alors de venir sur terre éjecter le cerveau de la boite cranienne de Sam, et annonce au monde entier que les humains ne sont pas seul dans l’univers.

Image du génerique : La vie sur terre sera à tout jamais boulversée.

Il  lance aussi un mandat d’arret galactique pour Sam, que seul 3 policiers Egyptiens capteront.

Sam se fait eventuellement capturer, mais arrive à se libérer en lancant une autre boite en carton sur le grand méchant, et se téléporte immédiatement en Egypte grace à un robot-vieillard : Un F-2000 qui est sur terre depuis 10.000 BC. (Ils trouvent le robot grace à l’agent secret du 1, suite à une scène que je n’ai pas compris car les acteurs lancaient leurs répliques dans un ordre approximatif)

Il apprend là bas que la montagne c’est en fait des robots, mais en fait c’est pas la montagne c’est une pyramide. Il apprend aussi qu’en fait le cube d’energie du 1, c’est pas un cube d’energie mais une clé pour trouver une autre clé, qui elle a plein d’energie qui sert à activer un truc qui pompe encore plus d’energie en sucant le soleil.

L’arme est là aussi depuis 10.000 BC, cachée par des robots-Egyptiens dans les pyramides, mais heureusement jamais activée car la terre était habitée, et ça c’est contre la morale des robots de sucer le soleil d’autrui (ce qui ne les a pas empeché de construire quand meme le suceur géant en premier lieu).

"Et donc t'es en train de me dire que tout le bordel qu'on a foutu il y a 1 an, c'était pour des symboles qui servent à rien !?!"

Là, Sam décide de chercher la clé mystère-plug-energie (la matrix) pour ré-activer optimus (qui lui ne résucite pas en suicidant un autre) qui lui seul peut tuer le vilain, avec l’armée US quand meme. Après un subtil passage du désert à la route, il se fait courser par l’axe du mal (3 policiers) qui veut le livrer au vilain pour prendre son cerveau/cube (suremment pour l’enfoncer dans la clé ou un truc comme ça), et heu, après ça pete de partout et j’ai pas trop suivi.

3 voitures de police menacent les 3 robots ...

Heureusement, boite en carton + teleport + habile déguisement, et tout le monde est sauvé !

Y a un gros robot qui ressemble à un kenex géant mal foutu.. Et heu.. Alors après des robots qui tapent d’autres robots. Pendant environ 40 min. On sait pas trop ce qui se passe, les robots se ressemblant tous.

Heureusement l'armée US a un Railgun anti-kenex !

A vrai dire, je suppose qu’il se passe beaucoup de truc mais je n’ai pas encore capté toute leur portée. Sam crève, puis voit des robots de 10.000BC, puis la poussière devient un batarang-matrix, puis il crève plus, puis il met le batarang dans optimus qui chope des pieces du F-2000 pour niquer le vilain, puis la clé devient on sait pas quoi, puis il dit je t’aime à sa copine (il, Sam, pas optimus).

Après avoir mangé son vieux pote l'avion, Optimus obtient des talonnettes de 20m

Sam est en fait l’élu, le néo que tout les robots attendaient, il est digne des Prime, peut faire son Jésus et que donc il peut controler la matrix.

Ma théorie sur ce film, c’est que Michael a eu son pc de montage vérolé.

Il a du perdre des bouts de scènes (voir de film), ca lui a foutu des dialogues dans le désordre, mais  également incorporé des séquences de Transformers 3. Il a également rajouté quelques sequences de film de cul d’m6 à tout moment et quelques préjugés racistes. Et personne s’en est rendu compte.. Personne sauf moi, hahaha !!!!

Ou alors son scénariste a 3 ans.