Embaucher des développeurs de jeux

Le développement de jeux punit les généralistes. Une page web qui s’affiche en deux cents millisecondes, ça passe; un jeu qui rate son budget d’images par seconde semble brisé. Les développeurs qui livrent des jeux jouables et performants pensent en temps par image, en mémoire et en ressenti du joueur, et ils connaissent leur moteur en profondeur, que ce soit Unity avec C# ou Unreal avec C++ et Blueprints. Beaucoup de gens ont ouvert un moteur et suivi un tutoriel. Beaucoup moins ont mené un vrai jeu à travers la production, l’optimisation et la sortie. turnkey.dev évalue pour le deuxième groupe.

Embaucher en jeu vidéo, c’est embaucher un rôle

« Développeur de jeux » recouvre plusieurs métiers distincts, et faire correspondre le rôle au problème compte plus ici que dans la plupart des embauches en logiciel.

• Les ingénieurs de jouabilité construisent ce que le joueur touche : déplacement, combat, comportement d’IA, progression, inventaire, interface. C’est le gros de la plupart des équipes et la bonne première embauche pour presque tous les projets. Interrogez-les sur le ressenti du joueur, la vitesse d’itération et leur façon de travailler avec les designers.
• Les programmeurs moteur et graphiques travaillent en dessous : pipelines de rendu, shaders, intégration physique, organisation mémoire, budgets de temps par image. Ils sont plus rares, se facturent plus cher, et la plupart des projets en ont besoin par poussées, pour une passe d’optimisation ou une fonctionnalité de rendu, pas en permanence. Interrogez-les sur le profilage : ce qu’ils ont mesuré, ce qu’ils ont trouvé, ce qu’ils ont changé.
• Les ingénieurs netcode et multijoueur prennent en charge l’autorité serveur, la prédiction client, la compensation de latence et la réplication d’état. Le multijoueur double à peu près la complexité d’ingénierie, et le greffer après coup dans un jeu bâti en solo est une des erreurs les plus coûteuses du domaine. Si le multijoueur est sur la feuille de route, faites entrer cette expertise avant que l’architecture ne se fige.
• Les ingénieurs d’outils construisent les extensions d’éditeur et les pipelines de contenu qui rendent les designers et les artistes plus rapides. Les équipes sous-estiment ce rôle jusqu’à ce que la production de contenu devienne le goulot d’étranglement.

Un mode d’échec courant : embaucher un spécialiste graphique pour faire de la jouabilité, ou attendre d’un ingénieur de jouabilité qu’il règle un goulot de rendu. Décrivez-nous le vrai problème et nous jumellerons le rôle, pas seulement le moteur.

Unity ou Unreal : comment le moteur façonne l’embauche

Les deux moteurs peuvent livrer presque n’importe quoi, mais les écosystèmes diffèrent assez pour que les développeurs portent rarement une profondeur sénior dans les deux.

Unity roule en C#, ce qui accélère l’itération et facilite l’embauche. Il domine le mobile, la 2D et la 3D en petite équipe, et c’est le choix par défaut pour le travail hors jeu décrit plus bas. La profondeur sénior en Unity paraît dans les parties difficiles : le système de tâches et la compilation Burst, les addressables et la gestion des ressources, et rendre le ramasse-miettes invisible pour le joueur.

Unreal roule en C++ avec Blueprints pour le script visuel, et c’est le meilleur choix par défaut pour la fidélité 3D haut de gamme et les projets d’abord console. La profondeur sénior en Unreal, c’est du vrai C++ (la mémoire, le système de réflexion, le code source du moteur au besoin), savoir où Blueprint s’arrête et où le code natif doit commencer, et tirer une performance acceptable de fonctionnalités de rendu très lourdes.

Si votre moteur est déjà choisi, embauchez de la profondeur dans ce moteur. Un bon développeur dans l’un est habituellement un développeur intermédiaire dans l’autre, peu importe ce que dit le CV.

Ce qu’un développeur de jeux fait pour vous

Une bonne recrue en développement de jeux va :

• Bâtir des systèmes de jouabilité qui tiennent la route : déplacement, combat, progression et interactions physiques, ajustés jusqu’à ce qu’ils soient agréables à jouer, pas seulement jusqu’à ce qu’ils compilent.
• Protéger le budget d’images. Profilage, réduction des appels de rendu, mise en pool des objets et discipline mémoire, pour que le jeu tourne bien sur le matériel que vos joueurs possèdent réellement, pas seulement sur une machine de développement.
• Livrer du multijoueur qui survit à de vrais joueurs : autorité serveur, prédiction client, compensation de latence, et un netcode qui se dégrade en douceur sur de mauvaises connexions au lieu de s’effondrer.
• Prendre en charge les builds et les sorties : des chaînes de compilation reproductibles pour les cibles mobile, PC et console, plus les particularités de soumission aux plateformes qui bloquent les équipes qui le font pour la première fois.
• Écrire des outils et des shaders. De l’outillage d’éditeur qui rend vos designers plus rapides, et du travail graphique qui obtient le rendu voulu à l’intérieur du budget de performance.

Les plateformes cibles changent le métier

L’endroit où le jeu sort change ce en quoi le développeur doit exceller. Le mobile, c’est l’étranglement thermique, des plafonds de mémoire serrés et l’autonomie de la batterie; un jeu qui roule sans chauffer sur un téléphone de milieu de gamme vieux de deux ans est un exploit d’ingénierie, pas un acquis. Le PC, c’est une matrice de matériel sans fin et un menu de paramètres qui doit s’étirer des graphiques intégrés d’un portable jusqu’aux machines d’enthousiastes. La console, c’est du matériel fixe, ce qui simplifie l’optimisation, mais aussi des exigences de certification qui font échouer des builds pour des règles que personne dans l’équipe ne connaissait; une expérience antérieure de livraison sur console fait sauver des semaines ici. Un portage est une discipline en soi : faire qu’un jeu bâti pour une cible se sente natif sur une autre touche à la fois l’entrée, l’interface, la performance et la mémoire, et c’est une raison courante pour laquelle des équipes viennent nous voir pour un mandat délimité.

Signaux de séniorité : distinguer une bonne recrue d’une faible

• Il a livré, et il en parle honnêtement. Une version jouable plus un compte rendu franc de ce qui a mal tourné bat n’importe quelle bande démo. De beaux extraits ne prouvent rien sur la capacité de production.
• Il profile avant d’optimiser. Demandez-lui le dernier problème de performance qu’il a réglé : un bon candidat nomme l’outil, la mesure, la cause et le correctif. Un candidat faible récite des conseils génériques sur la mise en pool des objets.
• Il pense en budgets : temps par image, mémoire, appels de rendu, taille du build. Les séniors peuvent vous donner les chiffres de leur dernier projet sans les chercher.
• Il sait quoi construire et quoi acheter. Les plugiciels de boutiques d’actifs et le code de marketplace sont des choix corrects quand un sénior les fait délibérément; un portfolio qui tient par des systèmes tiers jamais examinés est un signal d’alarme.
• Il peut parler des parties plates : chaînes de compilation, rapports de plantage, migration des sauvegardes, discipline de mises à jour dans les jeux en exploitation. Livrer, c’est surtout ça.

Quand embaucher un développeur de jeux

Les déclencheurs courants : un prototype doit devenir un vrai produit, la performance s’effondre sur les appareils cibles, vous voulez du multijoueur et personne dans l’équipe n’a fait de netcode, vous portez le jeu vers une nouvelle plateforme, ou un studio a besoin de capacité sénior pour un jalon sans un recrutement de plusieurs mois. Il y a aussi un flot constant de travail hors jeu ici : les entreprises qui bâtissent des simulations, des outils de formation, des configurateurs et d’autres expériences 3D interactives dans Unity ou Unreal ont besoin exactement de ces compétences. Si votre besoin porte surtout sur les services d’arrière-plan autour d’un jeu, le jumelage de parties, les comptes, les classements, la page Node.js plus bas est un complément naturel, et beaucoup de projets embauchent dans les deux bassins.

Comment fonctionne la présélection turnkey.dev

Chaque développeur passe une évaluation des fondamentaux (architecture du moteur, mémoire et performance, les mathématiques que le travail de jouabilité exige), un exercice pratique bâti autour d’un scénario réaliste de jouabilité et d’optimisation, et une revue des projets qu’il a pris en charge, incluant les plateformes cibles, la taille de l’équipe et ce qui a brisé en cours de route. Les portfolios sont notés, mais une version jouable et un bilan franc pèsent plus lourd qu’une bande démo léchée, parce que de beaux extraits ne prouvent pas la capacité de production. Nous refusons beaucoup plus de candidats que nous en acceptons.

La séniorité, et à quoi sert chaque niveau

La plupart des entreprises qui viennent nous voir ont besoin d’un développeur sénior capable de prendre en charge un système, une passe d’optimisation ou un portage, avec un lead amené brièvement pour les grandes décisions d’architecture.

Les modèles d’engagement

• Temps plein. Le choix par défaut en production : un développeur intégré à votre équipe, qui bâtit des systèmes semaine après semaine. Les projets menés par jalons en ont habituellement besoin pendant des mois d’affilée.
• Temps partiel. Convient au soutien d’un jeu en exploitation, à un flot régulier d’outillage de contenu, ou à un spécialiste sénior qui conseille une équipe junior quelques jours par semaine. C’est aussi la forme habituelle de la maintenance après lancement.
• Par projet. Un mandat délimité avec une fin définie : une passe d’optimisation pour atteindre la cadence d’images sur le matériel cible, un portage, une implémentation multijoueur, ou mener un build à travers la certification de plateforme. Plus le livrable est clair, mieux ce modèle fonctionne.

Les spécialistes s’embauchent souvent mieux de cette façon : un programmeur graphique pour une poussée de rendu de deux mois rend plus service qu’une embauche permanente que le projet ne peut pas occuper.

Combien ça coûte et en combien de temps

Les développeurs de jeux présélectionnés facturent généralement entre 60 $ et 120 $ de l’heure. Traitez ça comme une fourchette de marché qui bouge avec la séniorité, la région et la spécialité : les spécialistes du multijoueur, du graphisme et des consoles se facturent dans le haut, les développeurs intermédiaires de jouabilité et de contenu vers le bas, et les mêmes compétences se facturent différemment selon le fuseau horaire. Le choix du moteur influence moins le tarif que la profondeur : un ingénieur Unreal C++ sénior et un ingénieur Unity sénior avec une expérience de livraison équivalente se facturent de façon semblable. Le tarif de chaque développeur est indiqué avant tout engagement, et demander une liste restreinte est gratuit. Comptez une liste restreinte en 2 à 5 jours.

Commencez par une demande, pas par un contrat

Décrivez-nous le moteur, les plateformes cibles, où en est le projet et l’objectif : terminer la production, régler la performance, ajouter du multijoueur ou porter vers une nouvelle plateforme. Nous revenons avec une courte liste de développeurs présélectionnés qui correspondent, incluant tarif et disponibilité. Vous passez les entrevues, faites un essai rémunéré si vous le souhaitez, et décidez seulement ensuite. Si le jumelage ne convient pas dans les deux premières semaines, nous refaisons le jumelage sans frais.