Discuter avec Nathan Adams et Erik Broes de Minecraft

Discuter avec Nathan Adams et Erik Broes de Minecraft

Entrevues

En-tête de l'histoire de Minecraft

Nous avons le privilège de vous présenter cette conversation informelle entre Nathan Adams et Erik Broes de Minecraft et John Lindquist de JetBrains. L’interview couvre un large éventail de sujets allant de l’information au divertissement. Prendre plaisir.

Suivez Nathan (@Dînerbone), Erik (@_grum) et Jean (@johnlindquist) sur Twitter.

Comment avez-vous été initié à la programmation ?

Nath : J’ai commencé quand j’avais 10 ans. J’ai vu des gens créer des bots sur MSN Messenger à l’époque et je me suis dit : « Hé, c’est génial, je veux essayer ça ! C’était très amusant, mais peut-être que Perl n’était pas un bon langage d’introduction !

Érik : Quoi ! C’était il y a longtemps; tu m’as fait me sentir vieux! Quand j’avais environ 10 ans, j’ai griffonné un peu en BASIC (beaucoup de taper ce que les magazines disaient sans en comprendre grand-chose). Mon premier “vrai” langage a été Perl quand j’avais 14 ans pour administrer/contrôler les serveurs QuakeWorld.

Vous êtes-vous toujours considéré comme un développeur de jeux ?

Nath : Je ne me considérais pas vraiment comme un développeur de jeux avant de commencer à travailler sur Minecraft. J’ai toujours travaillé sur des jeux de modding ou des jeux d’ingénierie inverse, mais les développer maintenant est un endroit effrayant ! Beaucoup plus gratifiant cependant et amusant!

Érik : Identique à Nathan en gros, et je ne me qualifie toujours pas de développeur de jeux. J’aime beaucoup trop “réparer les choses cassées”. J’ai essayé occasionnellement de pirater des jeux, de comprendre leur format de données, etc.; mais jusqu’au premier Mojam (coding jam) à Mojang, je n’avais jamais fait de jeu entièrement fonctionnel auparavant.

Quels ont été vos langages de programmation préférés et les outils que vous avez utilisés tout au long de votre carrière ?

Nath : C’est difficile, différents outils (langages) pour différents travaux. Je pense que ces jours-ci, je préfère utiliser Python pour les scripts ou le travail Web, Java pour les jeux, les outils ou les programmes côté client. En ce qui concerne les outils, c’est encore plus difficile. Je suis un homme simple, donc je voterai probablement pour IntelliJ IDEA, Sublime Text (pour tout ce qui n’est pas java) et Twitter (c’est un outil, je le promets ! Le meilleur endroit pour les commentaires !).

Érik : J’ai appris/appris à utiliser Vim très tôt. Faire beaucoup de travail sur des serveurs ou via des tunnels ssh vous limite (également, il y a environ 18 ans, nous n’avions pas ce truc fantaisiste). J’utilise toujours les plugins Vim en ce moment (IdeaVim !). J’avais l’habitude de prétendre que Perl serait le bon langage pour chaque situation dans laquelle je me retrouverais, mais depuis lors, je me suis converti à aimer la santé mentale qu’un langage fortement typé et non évalué comme Java vous donne. J’utilise toujours Perl pour (trop) de choses ponctuelles, mais je préfère Java + IntelliJ + IdeaVim pour tout le reste.

Avec quelles plateformes aimez-vous le plus travailler ? Vous détestez travailler avec ? 🙂

Nath : Hum, question intéressante. Avec Java et Python, je n’ai généralement pas à me soucier de la plate-forme, mais si je dois commencer à travailler sur l’interface utilisateur, j’irai pleurer dans un coin !

Érik : En tant que système d’exploitation hôte de développement, je * déteste * absolument Windows avec passion. Pas de shell approprié, pas de support ssh sain d’esprit, ça me fait juste pleurer d’être si “impuissant”. Comme je ne veux pas non plus passer beaucoup de temps à investir pourquoi diable mon module de noyau semble se retourner à nouveau, je me suis retrouvé à mi-chemin entre Linux et Windows, OS X. Je dis toujours si vous savez quelque chose assez bien, vous savez pourquoi le détester, jusqu’à présent, je semble détester le moins OS X.

Quel type d’outils utilisez-vous pour les tests ? Suivez-vous des pratiques de test spécifiques ?

Nath : Hehe, je laisse ça à Erik. Il est le gourou des tests ici. Nous avons tendance à écrire de nouveaux composants pilotés par des tests, mais la majorité du gameplay réel n’a malheureusement pas encore été testé.

Érik : Ha, appeler quelqu’un avec <4 ans d'expérience Java un gourou. Tout d'abord, je ne me considère pas comme un gourou. Nous n'utilisons pas beaucoup d'"outils" au-delà de ce que fournit IntelliJ IDEA, nous devons juste pouvoir exécuter JUnit4. Je n'aime pas vraiment les frameworks qui utilisent la réflexion pour mettre la base de code dans un état afin qu'elle soit simulable (écraser les finales, tester les privés, etc.), donc nous utilisons simplement Mockito. Finalement, je prévois d'une manière ou d'une autre d'obtenir cette base de code jusqu'à 90% + de couverture (unité basée sur la ligne testée) et ce pourrait très bien être le seul jeu qui le fasse si nous y arrivons :D .

Quels conseils avez-vous pour les autres développeurs travaillant avec des bases de code massivement populaires ?

Nath : N’ayez pas peur de tout démonter, tant que vous êtes prêt à passer trois fois plus de temps à tout remettre en place. Si vous avez une communauté qui veut toujours de nouvelles choses, elle doit comprendre (et vous aussi) que parfois vous devez prendre quelques semaines pour simplement raser les yacks et refactoriser le code – cela peut ne pas sembler amusant mais au final cela vous permet d’être plus productif et travaillez sur des choses sympas plus rapidement !

Érik : Comme l’a dit Nathan, nous cassons tout tout le temps. Ce serait beaucoup plus facile si notre code était correctement testé à l’unité et nous y arrivons lentement. De plus, si vous avez la possibilité d’ouvrir le code source de votre produit, faites-le, écoutez les commentaires que les gens donnent à votre code et apprenez des critiques constructives.

Avez-vous un livre de programmation préféré ?

Nath : J’ai bien peur que non, je n’en ai lu aucun ! *se baisse du feu*

Érik : *tire aux pieds de Nathan*; Je suis triste de ne pas l’avoir sur mon bureau, mais Java efficace par Joshua Bloch, je peux conseiller à tous ceux qui codent Java. Aussi, ne sautez pas sur Nettoyer le code par “Oncle Bob”.

Quand êtes-vous le plus productif, de jour comme de nuit ?

Nath : Hehe, heures de programmation. Je suis plus productif quand il s’agit de moi, peu importe quand c’est le cas ! Habituellement la nuit cependant, peut-être parce que j’ai moins de distractions à ce moment-là.

Érik : Mes meilleures idées sont toujours à des moments horribles, comme sauter dans la douche ou juste avant de s’endormir. La meilleure productivité est atteinte pendant que je ne dors pas, je suppose :).

Musique ou pas de musique pendant que vous codez ? Votre musique d’encodage préférée ?

Nath : Oh, c’est facile. Des explosions dans le ciel. Cela vous donne l’impression d’être dans un film de piratage ringard, une ligne de code de plus pour sauver le monde.

Érik : Même si je n’écoute pas beaucoup de musique, j’adore l’artiste que Nathan a souligné. Si j’écoute de la musique, je ne peux rien écouter avec des paroles, ça gâche tout simplement le codage pour moi. Ainsi, lorsque je décide d’écouter de la musique pour éliminer d’autres sons, ce serait une forme de transe ou même de classique.

Quel est le bug le plus difficile que vous ayez eu à corriger ?

Nath : Je dirais des bugs d’éclairage… Parfois, en jouant à Minecraft, vous rencontrerez des taches aléatoires d’obscurité, où le monde n’a pas été éclairé. Nous ne les avons pas encore corrigés. Eh bien, ce n’est pas vrai, je les ai corrigés plusieurs fois de différentes manières, mais cela a toujours tué les performances d’une manière ou d’une autre, nous avons donc dû continuer à traiter les symptômes au lieu du bogue. J’ai probablement perdu des mois solides à ce sujet maintenant.

Érik : ^^ ÇA ! Je déteste ce bug d’éclairage. Le problème est que nous “savons” comment y remédier mais le résultat finit par être trop lent. Nous finirons par le contourner à nouveau une fois que nous l’aurons extrait de l’enchevêtrement actuel dans lequel il se trouve.

Utilisez-vous beaucoup d’outils construits « maison » ?

Nath : Pas tellement ces jours-ci, mais quelques-uns. Celui dont je suis le plus fier est Hopper, un collectionneur de rapports de crash. Chaque fois que quelqu’un plante dans Minecraft (à condition qu’il l’ait activé), il le publiera automatiquement sur http://hopper.minecraft.net, qui le regroupera avec des plantages similaires par unicité sur la partie “inconnue” du stacktrace, tandis que le jeu a rempli un tas de données pertinentes à chaque partie du plantage. Nous pouvons également marquer certains bugs (comme ne pas avoir de carte graphique… cela arrive plus que vous ne le pensez) comme connus afin que nous puissions immédiatement donner un retour aux utilisateurs dès qu’ils rencontrent le crash. La meilleure partie du système? Ce démasque les rapports pour nous!

Érik : Nous essayons autant que possible de rester avec des outils open source, mais nous devons récupérer/préparer des données depuis/vers d’autres sources pour notre processus de publication. Pensez à des “ensembles” d’actifs pour Amazon, en téléchargeant des traductions depuis Crowdin et en les préparant pour le téléchargement. Donc, notre chaîne d’outils personnalisés est relativement petite en ce moment. Nous prévoyons de nous lancer dans la création d’interfaces utilisateur et peut-être certains exportateurs de modèles pour nos changements à venir dans ces domaines. De plus, j’ai totalement écrit ce désobfuscateur pour les stacktraces en Python (la première fois que j’ai touché ça) !

Un conseil pour les développeurs de jeux en herbe ?

Nath : Créez des jeux pour vous-même, pas pour les autres ! C’est l’erreur la plus courante que je vois des gens faire. Si ce n’est pas amusant pour vous, vous n’allez pas faire quelque chose d’amusant pour les autres. N’ayez pas peur de vous tromper ou cela ne fonctionnera pas; ça *va* gâcher et ça ne marchera peut-être pas mais c’est une expérience d’apprentissage en soi. De plus, la moitié des jeux sont construits sur des fonctionnalités involontaires !

Érik : Deux choses, coder, coder jusqu’à ce que votre cerveau tombe en panne, et faites toutes les erreurs que vous devez faire. Ce n’est qu’en faisant des erreurs que vous apprendrez/améliorerez/découvrirez de nouvelles choses. Essayez de temps en temps de déterminer si vous tirez le meilleur parti de votre IDE ou si vous pouvez peut-être mieux l’utiliser (c’est ainsi que j’ai trouvé IntelliJ). Et comme je l’ai déjà dit, faites participer d’autres personnes à votre projet et apprenez d’elles.

Des demandes de fonctionnalités pour IntelliJ IDEA ou d’autres outils JetBrains ?

Nath : Oh mec, mon esprit est devenu vide. On s’est toujours dit « IntelliJ a besoin de ça… » mais maintenant je ne m’en souviens plus. Je suppose que des raccourcis clavier pour certaines configurations d’exécution seraient bien! Ou un meilleur support multi-curseur, Sublime m’a vraiment gâté là-bas et parfois j’ai besoin d’y revenir pour éditer plus rapidement les choses, mais je ne peux qu’imaginer à quel point ce serait un mal de tête.

Érik : Oui, lors de l’exécution de tests, il serait utile d’avoir un bouton qui ne dépend pas du contexte pour exécuter tous les tests de ce fichier. Pour les remplacements structurels, pouvoir avoir une variable pour faire correspondre les opérateurs serait *SO* utile. Par exemple:

$SomethingThatExtendsFacing$.getId() $EqualsOrNotEqualsTo$ 3
avec
$SomethingThatExtendsFacing$ $EqualsOrNotEqualsTo$ Facing.SOUTH

ou tournant : « nouvelle Pos(x + 1, y – 1, z + 1) » dans “nouveau Pos(x, y, z).offset(1, -1, 1)”, vous devez maintenant créer toutes les variantes de positif/négatif et les “mapper” manuellement. Et si nous allons par ici; être capable de gérer : “x + 1 – 1” ‘nativement’ au lieu d’avoir à le réécrire manuellement en : “x + (1 – 1)” le voir comme un ajout, serait merveilleux aussi.

Merci Nathan et Erik pour votre temps et votre participation à cette interview. En ce qui concerne leurs idées d’amélioration pour IntelliJ IDEA, restez à l’écoute pour plus d’informations.


C’est le tweet qui a déclenché toute la conversation. Si vous avez des idées pour de futurs entretiens et articles, veuillez partager vos réflexions dans notre section commentaires.

Minecraft et le logo Minecraft sont des marques déposées de Mojang / Notch © 2009-2014.

Development Source

Related Posts

RLEC 4.2.1 apporte des contrôles granulaires à la haute disponibilité et aux performances

RLEC 4.2.1 apporte des contrôles granulaires à la haute disponibilité et aux performances

Comment HolidayMe utilise Redis Enterprise comme base de données principale

Comment HolidayMe utilise Redis Enterprise comme base de données principale

Annonce de RedisGears 1.0 : un moteur sans serveur pour Redis

Annonce de RedisGears 1.0 : un moteur sans serveur pour Redis

Clés Redis dans la RAM |  Redis

Clés Redis dans la RAM | Redis

No Comment

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *