aBlog

L’un des postes les plus recherchés par toutes les dev-team est celui de codeur, c’est aussi le type de personne le plus dur à trouver, en effet, quel être humain normal aimerait trifouiller des milliers de lignes de code pour changer une variable ?
Ce poste de codeur est aussi le plus important, c’est presque inimaginable de faire un mod sans toucher au code, ceux qui y parviennent se doivent d’exceller dans un autre domaine, comme l’excellent ‘Minerva Metastasis’ qui fait oublier les lacunes d’Half-Life² avec un level-design de grand malade.

Bref. Le Source Engine se base quasi-exclusivement sur un système d’entités et la conception objet est à la base de tout, dans Source, tout est objet, le player est un CBasePlayer qui hérite de CBaseCombatCharacter qui hérite de CBaseFlex et ainsi de suite, au final tout revient à un CBaseEntity, qui hérite de quelques classes relatives au networking et autres saloperies comme on ne les aime pas.
En fait, c’est plutôt logique, et même simple, sauf que pour une seule entité (le player) tout va être éparpillé dans les quelques milliers de fichiers de code, parce qu’un player tout con, en plus d’être un CBasePlayer et tout ce qui s’en suit, c’est aussi un CHL2MP_Player, un CHL2_Player et j’en passe.

Comment s’y retrouver alors ?
Simple : Ctrl+Shift+F

Ce raccourci (recherche globale sous Visual Studio) est en fait la base du coding Source, couplé à un bon vocabulaire anglophone, vous pouvez faire tout ce que vous voulez.

Vous voulez par exemple, instaurer un système de skins (comme dans Bisounours Party ça va de soi). Vous savez qu’une entité (prop_dynamic) peut faire varier sa skin via un Input (dont vous connaissez bien évidemment le nom) un coup de Ctrl+Shift+F et recherche : “skin”. Avec les guillemets, pour tomber directement sur la ligne qui déclare l’input, autrement, la recherche aurait renvoyé quelques 800 lignes de codes, ce qui est la raison pour laquelle je n’ai pas cherché “skin” dès le début. (En fait si, la recherche la plus logique se fait en premier, mais comme ça a retourné 800 lignes, il faut restreindre la recherche.)
Donc, cette merveilleuse recherche renvoie deux lignes de code, la première est la plus intéressante, c’est la déclaration de l’input au sein de la classe CBaseAnimating qui est la classe de laquelle hérite toute entité avec un model dans le jeu, y compris le player.
Cette ligne, la voici :
DEFINE_INPUT( m_nSkin, FIELD_INTEGER, “skin” ),
Ça signifie : “Fais moi un input “skin” qui modifiera la valeur de l’attribut m_nSkin”
Ça y est, la recherche est terminée, pour mettre en place un système de skin il suffit de faire une ConVar reliée à l’attribut m_nSkin de la classe CBasePlayer, le joueur n’aura plus qu’a modifier cette CVar via la console ou les options.

Finalement, le raisonnement de Source était plutôt logique non ?

Non. Parce que dès le début des tests vous vous apercevrez de deux choses : changer une skin provoque le changement de la skin de tout le monde sur le serveur et les cadavres n’ont pas la bonne skin.
Premièrement : vous savez que vous allez en chier, parce que ce genre de bug ça vient de la façon de transmettre l’information au client, et ça, c’est la plaie.
Deuxièmement : vous découvrez que quand un client meurt, une copie de son model est créée dans une entité à part mais que toutes les informations ne sont pas copiées, et évidemment la skin fait partie de ces informations manquantes.

Couplez ça avec le fait que vous voulez des skins différentes pour les cadavres, pour les teams et pour d’autres modes de jeu, vous obtenez des jours à vous arracher les cheveux.

Ça n’est bien évidemment pas impossible pour autant : mon système de skin fonctionne parfaitement sous Bisounours Party. (Ça faisait longtemps que je ne l’avais pas cité.)

Pour résumer tout ça : sortez-vous les doigts du cul, pour coder il vous suffit d’un peu de jugeote et d’expérience, arrêtez de chercher des codeurs vous n’en trouverez pas. Commencez par modifier deux-trois variables, fouillez le code pour voir comment ça fonctionne, et au bout d’un moment vous pourrez tout faire.

(Bisounours Party ; Forum)

Hay amis nofragiens, je viens d’avoir l’idée à l’instant, pourquoi ne pas faire de ce blog le dev-blog de Bisounours Party ? En ce qui me concerne, j’ai toujours adoré les articles de ce genre, et plus c’est technique, plus j’aime, en témoigne la nuit d’hier que j’ai passée à mater les articles de divide sur les techniques de mapping avec en fond sonore, la musique de divide.

D’abord, Bisounours Party qu’est-ce que c’est ? Un mod multijoueur basé sur le Source Engine dont le principe de jeu varie entre les parties mais avec une constante globale : se foutre sur la gueule entre bisounours. (Bien que des bisounours se retrouvent quelques fois devant des hordes de pedobears assoiffés de… sang ?)

Pour commencer cette série de billets (que j’espère continuer) je vais parler du commencement, histoire d’être un peu logique.

Matériel Requis

Pour faire un mod, il faut quelques impératifs de départ :
• Une idée
• Du temps
• De la patience
• Des compétences

Si il vous manque quelque chose dans cette liste, ce n’est même pas la peine de penser à faire un mod.

L’idée : Une idée pour faire un mod, c’est primordial puisque c’est elle qui va décider de chaque action entreprise sur le mod, de chaque détail de mapping, de chaque ligne de code. Je vais pas m’étaler là-dessus.

Le temps : Faire un mod, ça prend énormément de temps, que vous soyez bosseur ou procrastinateur, ça revient au même, n’oubliez jamais que l’informatique est le domaine le plus chronophage qui soit, et que le modding bouffe aussi énormément de temps. Si dès le début vous travaillez en équipe, n’espérez pas trop de choses de vos équipiers, car comme vous et comme tout le monde, ce sont de grosses feignasses qui ont beaucoup plus l’habitude de dire “j’vais l’faire’ que de dire “je l’ai fait”. Si vous avez une petite modification à faire, ne vous attendez pas à ce que ce soit miraculeux et que ça fonctionne sur l’instant, la dernière fois que j’me suis dit “ça va prendre deux heures maximum” j’ai passé deux jours à coder, et hier Klems m’a fait une requète qui sur le papier est extrèmement simple, j’ai déjà passé deux heures dessus (sur le principe faut juste faire un produit en croix et renvoyer l’info à l’utilisateur) et je sais que j’ai pas fini de galérer, parce que j’ai une couille au niveau du networking d’une information capitale, et ça sous Source, ça pardonne pas. En ce qui concerne le long terme : un an pour avoir une alpha vaguement jouable, deux ans pour une première bêta interne marrante, trois ans pour avoir un truc présentable en public mais à peaufiner encore une année.

La patience : De paire avec le temps et de trio avec les compétences. La patience est la pièce maîtresse du développement d’un mod. En ce qui concerne le mod en lui même, vous en aurez pour deux ans grand minimum, mais pour faire un mod, il faut déjà des compétences, et ça, ça arrive pas en claquant des doigts, il vous faudra compter quelques années d’expérience en coding/mapping/modeling/Source pour faire votre mod tranquillement. Si vous n’y connaissez rien, courage, dans six mois vous aurez pondu votre première map à 6 faces avec une entité qui dit “Hello World !”.

Les compétences : Travailler avec des brèles, c’est pas agréable, si quelqu’un se propose pour votre projet, soyez sûr qu’il soit à la hauteur. Dans l’idéal, tout le monde dans l’équipe se doit d’être polyvalent, ça permet de voir les erreurs des autres et de pouvoir travailler dans un domaine quand il n’y a plus rien à faire dans un autre. En ce qui me concerne, dans BP je suis capable de toucher à tout sauf aux models, ça permet de rester productif pendant mon temps libre et selon mes envies, si mapper m’emmerde, je vais aller coder quelques lignes, si le code m’emmerde, je vais voir si il n’y a pas quelque chose à corriger dans les scripts, des textures à recompresser ce genre de trucs. À peu près tout le monde dans l’équipe est dans ce cas, c’est un plus non négligeable même si ça a ses inconvénients, ça favorise la glandouille, on se disperse dans son boulot et au final on ne fout plus rien. (Salut JBB, ça va ?)

J’ai fait ici abstraction de la motivation qui n’est qu’une résultante des 4 conditions citées, mais sans motivation, votre mod sera fade, si vous n’avez pas le cœur à bosser, ne vous forcez pas, ça reviendra, ne partez pas dans des délires “j’aime plus le mod envie de me casser toussah”, vous le regretterez, et un gros tag ‘TRAITRE’ sera apposé à côté de votre nom au générique. (Salut Kirumi, ça va ?)

Hop hop hop, la prochaine fois, j’attaque un billet technique histoire de faire croire que je suis intelligent/compétent et de prouver que je n’ai aucune vie.

(Bisounours Party ; Forum)