À propos de nous

est un petit studio de jeux indépendant avec une longue mémoire. La page « À propos de nous » que vous lisez est la page originale — un instantané du début des années 2000, lorsque le studio était composé de deux personnes, d’un bureau à domicile partagé et d’une croyance obstinée que l’on pouvait créer de vrais jeux sans qu’un éditeur ne vous souffle dans le cou.

Nous l’avons gardée en grande partie intacte parce qu’elle est honnête sur nos origines, et parce que les personnes qui y figurent sont toujours celles qui créent les jeux. Ce qui suit est cette même page, développée : qui nous sommes, ce que nous faisons réellement, comment nous travaillons, et pourquoi un studio qui a commencé avec C++ et DirectX sur PlayStation 2 a fini par livrer des jeux HTML5 et des adaptations de jeux de société.

Points clés à retenir

• Massively Fun est un studio indépendant de deux personnes fondé et dirigé par Stephen et Angela Wilkinson, en activité depuis le milieu des années 1990.
• Le parcours de Stephen est celui de l’ingénierie professionnelle sur consoles et PC — C++, DirectX, et des titres livrés sur PS/2, Xbox et le matériel de l’ère GameCube.
• Le parcours d’Angela couvre Java, C++, ASP et Delphi, ainsi que la tâche beaucoup plus difficile de gérer le foyer qui permet au studio de survivre.
• La production du studio a évolué avec l’industrie : du travail natif sur console aux jeux HTML5/JavaScript basés sur navigateur et aux adaptations numériques de jeux de société physiques.
• Nous construisons par petits incréments livrables et considérons qu’un projet « terminé et publié » est plus précieux qu’un projet « ambitieux et inachevé ».
• Tout ici — critiques, téléchargements, notes de développement — provient de personnes qui créent réellement des jeux, et non d’une ferme de contenu.

Qui sommes-nous

Stephen Wilkinson — Ingénieur logiciel principal. Stephen a passé des années en tant qu’ingénieur de jeu professionnel, notamment chez Paradigm Entertainment, une société d’Infogrames, travaillant sur des titres console pendant la génération PS2/Xbox/GameCube. C’est l’époque où « livrer un jeu » signifiait s’insérer dans un budget mémoire fixe, optimiser manuellement un moteur de rendu et déboguer sur des kits de développement qui coûtaient plus cher qu’une voiture. Il a été diplômé en 1987 de la Duncan High School à Duncan, Oklahoma — ce qui vous indique qu’il écrit des logiciels depuis très longtemps, et qu’il est venu aux jeux par la même voie que beaucoup d’entre nous : la curiosité, un ordinateur personnel et trop de nuits blanches.

Ses compétences déclarées sont celles qui comptent pour ce studio : la création de jeux informatiques, C++, DirectX et le développement sur consoles PS/2, Xbox et un peu de GameCube. En pratique, cela signifie qu’il est à l’aise sur toute la pile technique — de la gestion de la mémoire et du rendu aux systèmes de gameplay et à l’outillage.

Angela Wilkinson — Maman d’Arthur, et codeuse en attente. Le titre officiel d’Angela la sous-estime. Sa boîte à outils comprend Java, C++, ASP et Delphi, plus ce que la page originale appelle « Mom 1.0 » — le système d’exploitation qui permet en fait à un studio de deux personnes de fonctionner. Quiconque a essayé de créer des jeux tout en ayant une famille sait que le second travail est le plus difficile, et qu’un studio sans quelqu’un pour gérer la logistique, les calendriers et le moral ne livre rien.

Sa liste de favoris est courte et révélatrice : Arthur (et Stephen). C’est tout le studio résumé en une ligne.

Connexes : Unity Asset Store — Illustrations, outils et modèles prêts à l'emploi qui s'intègrent directement dans votre projet Unity.

Ce que nous construisons réellement

Le catalogue de Massively Fun couvre quelques types de travaux distincts, et il est important d’être explicite à ce sujet car le terme « studio indépendant » peut signifier presque n’importe quoi.

• Jeux HTML5/JavaScript originaux. Des titres conçus d’abord pour le navigateur, faits pour fonctionner sans plugin, sans installation et sans passer par un magasin d’applications. C’est le cœur moderne de notre activité.
• Adaptations numériques de jeux de société. Notre travail le plus connu dans ce domaine est Catan World, une version numérique du Catan de Klaus Teuber — un jeu dont les règles sont simples à énoncer mais réellement difficiles à implémenter correctement, car toute l’expérience repose sur l’ordre des tours, l’échange de ressources et la négociation sociale entre les joueurs.
• Petits jeux incisifs de style arcade. Fast Iron et Word² entrent dans cette catégorie : des boucles de jeu serrées, des sessions rapides et des mécaniques que l’on peut expliquer en une phrase mais que l’on passe des semaines à peaufiner.
• Critiques et commentaires. Nous jouons beaucoup, et nous écrivons à ce sujet. Les critiques sur ce site proviennent de développeurs en activité, ce qui change notre regard — nous avons tendance à nous intéresser aux systèmes, au ressenti et à l’exécution technique autant qu’à la présentation.

Ce mélange n’est pas accidentel. Il reflète une stratégie délibérée : garder la portée de chaque projet suffisamment petite pour que deux personnes puissent le terminer, et maintenir plusieurs types de projets en cours afin que le studio ne dépende pas du succès d’un seul titre.

Comment nous en sommes arrivés là : de DirectX au navigateur

La page « À propos de nous » originale est une capsule temporelle d’un moment précis du développement de jeux. À la fin des années 1990 et au début des années 2000, si vous vouliez créer un jeu, vous l’écriviez en C ou C++ en utilisant un SDK de plateforme — DirectX sur Windows, ou les bibliothèques propriétaires d’une console — et vous le livriez sur support physique via un éditeur. Paradigm Entertainment était exactement ce genre de studio, et y travailler signifiait apprendre la discipline du développement console : matériel fixe, délais stricts, exigences de certification et aucune possibilité de publier un correctif après le lancement.

Notre sélection : Udemy Game Development Courses — Cours à la demande couvrant la programmation Unity, Unreal, C++, C# et shader.

Le Web a changé la donne économique de tout cela. Lorsque les navigateurs ont acquis un véritable canevas 2D et, plus tard, WebGL, il est devenu possible de proposer un jeu à toute personne disposant d’une URL.

Pas d’éditeur, pas de disque, pas de file d’attente de certification. Les compromis sont réels : vous abandonnez l’accès direct au matériel, vous luttez contre les bizarreries du navigateur et vous ne pouvez pas supposer une fréquence d’images constante — mais l’avantage est qu’une équipe de deux personnes peut atteindre des joueurs du monde entier dès le premier jour.

Ce changement est la raison pour laquelle le centre de gravité de Massively Fun s’est déplacé vers HTML5 et JavaScript. Les habitudes d’ingénierie liées au travail sur console n’ont pas disparu ; elles ont simplement été appliquées à une cible différente. La discipline mémorielle, les boucles de mise à jour déterministes et un profilage minutieux sont tout aussi importants dans un navigateur que dans un devkit.

Comment nous travaillons

Les studios de deux personnes vivent ou meurent selon leur processus, et le nôtre est construit autour de quelques principes qui ont survécu au contact de la réalité.

Livrez petit, livrez souvent. Un jeu qui existe et qui est jouable bat un jeu qui est théoriquement meilleur mais inachevé. Nous définissons le périmètre selon ce que deux personnes peuvent réaliser, puis nous coupons jusqu’à ce que cela rentre.

Prototypez d’abord la partie risquée. Si une mécanique risque de ne pas être amusante, nous en construisons la version la plus laide possible avant de créer tout art ou interface utilisateur. La plupart des idées meurent ici, et c’est tout l’intérêt.

Connexes : Amazon: Game Dev Books & Gear — Livres de programmation de jeux, claviers mécaniques, moniteurs et matériel de développement.

Gardez la chaîne d’outils simple. Pour le travail HTML5, cela signifie généralement une base de code JavaScript/TypeScript, une approche de rendu légère (Canvas brut ou WebGL, ou une petite bibliothèque plutôt qu’un moteur lourd), et Node.js pour les scripts de build, les pipelines d’assets et les serveurs de développement locaux. Des outils simples signifient moins de surprises et moins de temps passé à déboguer l’outillage plutôt que le jeu.

Testez sur le pire appareil que vous puissiez trouver. Les jeux par navigateur fonctionnent sur tout, d’un ordinateur de bureau haut de gamme à un téléphone vieux de cinq ans. S’il tient la route sur la cible la plus lente, il tient la route partout.

Écrivez-le. Les notes de développement et les revues ne sont pas du marketing : c’est notre façon de penser. Expliquer une décision de conception par écrit est l’un des moyens les plus rapides de découvrir qu’il s’agit d’une mauvaise décision.

Si vous faites du shopping : Construct 3 — Moteur HTML5 sans code basé sur un navigateur qui exporte vers le Web, les appareils mobiles et les ordinateurs de bureau.

Choisir une pile technologique : comment nous décidons

L’une des questions les plus courantes que nous posent les développeurs amateurs est « avec quoi devrais-je construire ? ». Il n’y a pas de réponse universelle, mais il existe un processus décisionnel. Voici approximativement comment nous réfléchissons.

Considération	Pencher vers Canvas/WebGL + JS/TS bruts	Pencher vers un moteur complet (ex: Godot, Unity, ou un moteur JS)
Taille de l’équipe	1 à 2 personnes qui aiment le contrôle	Équipes plus larges ou artistes ayant besoin d’éditeurs
Type de jeu	2D, arcade, puzzle, portages de jeux de société	3D, riche en physique, graphes de scène complexes
Cible	Priorité navigateur, chargement rapide, petit téléchargement	Multiplateforme incluant consoles/desktop
Vos atouts	Vous appréciez les systèmes et le contrôle bas niveau	Vous préférez passer du temps sur le contenu et le design
Budget temps	Vous pouvez vous permettre de construire certains outils	Vous avez besoin d’un éditeur et d’un pipeline d’assets maintenant

La mise en garde honnête : les moteurs vous font gagner un temps énorme sur le rendu, la physique et la gestion des assets, mais ils imposent également leur propre architecture et leurs propres bugs. Créer le vôtre vous donne un contrôle total et une responsabilité totale.

Pour un studio de deux personnes livrant des jeux par navigateur, une voie médiane — une petite bibliothèque de rendu plus votre propre logique de jeu — a généralement été le bon choix. Pour le premier projet d’un amateur, un moteur est presque toujours la voie la plus rapide vers quelque chose de jouable.

Si vous souhaitez approfondir les standards et les plateformes impliquées, les MDN Web Docs sur l’API Canvas sont la référence canonique pour le rendu 2D dans le navigateur, et la spécification WebGL maintenue par le groupe Khronos couvre la voie accélérée par GPU. Pour le côté jeu de société de notre travail, le site officiel de Catan est la source faisant autorité sur le jeu que nous avons adapté.

Contrôle de mouvement et autres expériences

Une partie de l’histoire du studio concerne les plateformes de contrôle de mouvement — la vague d’entrées basées sur des caméras et des capteurs arrivée avec l’ère Wii et la Kinect. Le contrôle de mouvement est un problème de conception véritablement intéressant car il supprime la couche d’abstraction du bouton. Les joueurs s’attendent à ce que le jeu comprenne leur corps, et ce n’est généralement pas le cas, du moins pas précisément.

Les leçons pratiques de ce travail se répercutent sur tout ce que nous faisons :

• La latence est l’ennemi. Tout schéma d’entrée avec un décalage notable semble cassé, quelle que soit l’ingéniosité de la mécanique.
• Concevez pour le capteur que vous avez, pas celui que vous voulez. Si la caméra ne peut détecter de manière fiable que les mouvements grossiers, créez un jeu basé sur les mouvements grossiers.
• Fournissez toujours une solution de repli. L’accessibilité et la fiabilité exigent toutes deux qu’un jeu soit jouable sans le périphérique d’entrée exotique.

Ces principes s’appliquent tout aussi bien aux commandes tactiles sur un téléphone, qui représentent le problème du contrôle de mouvement de l’ère HTML5.

Les gens derrière les jeux

Cela vaut la peine de le répéter clairement, car c’est ce qui distingue un studio comme celui-ci d’un site de contenu : les noms sur cette page sont les personnes qui écrivent le code, règlent les mécaniques et jouent aux jeux que nous critiquons. La liste des favoris de Stephen — Final Fantasy Tactics Advance, Le Seigneur des Anneaux : Les Deux Tours sur PS2, Fire Emblem, Call of Duty, et une sélection tournante d’autres — est la liste d’un développeur actif. Elle est riche en jeux axés sur les systèmes avec une progression profonde, ce qui est exactement le genre de conception qui récompense l’état d’esprit de l’ingénierie.

La liste d’Angela fait une ligne et dit tout : Arthur et Stephen. Un studio est un foyer avant d’être une entreprise, et celui-ci a toujours été les deux.

Questions fréquemment posées

Qui dirige Massively Fun ?

Massively Fun est dirigé par Stephen et Angela Wilkinson, une équipe de deux personnes. Stephen gère l’essentiel de l’ingénierie, en s’appuyant sur une expérience professionnelle dans le développement sur consoles et PC, tandis qu’Angela contribue au codage en Java, C++, ASP et Delphi, tout en gérant le foyer qui rend le studio possible.

Quels jeux Massively Fun a-t-il créés ?

Le catalogue du studio comprend des titres HTML5/JavaScript originaux tels que Word² et Fast Iron, ainsi que Catan World, une adaptation numérique du jeu de société Catan. Le studio publie également des critiques et des commentaires sur les jeux auxquels il joue.

Quelles technologies le studio utilise-t-il ?

Historiquement, C++ et DirectX pour le travail sur consoles et PC, y compris le développement de l’ère PS/2, Xbox et GameCube. Aujourd’hui, l’accent est mis sur HTML5 et JavaScript pour les jeux par navigateur, avec Node.js pour l’outillage et les pipelines de construction, tandis que Java, C++, ASP et Delphi font partie de l’expérience plus large de l’équipe.

Puis-je embaucher Massively Fun ou collaborer ?

Le site a toujours été une page de studio personnelle plutôt qu’une vitrine d’agence, il n’y a donc pas de liste formelle de services. Le meilleur moyen de collaborer ou de poser des questions est de nous contacter via l’adresse de contact publiée sur le site.

La page originale « À propos de nous » est-elle toujours exacte ?

Oui — les biographies, compétences et favoris d’origine sont conservés ici car ils sont toujours d’actualité. Les personnes, leurs parcours et leurs goûts n’ont pas changé ; ce qui a changé, c’est la plateforme pour laquelle le studio développe et la taille du catalogue.

Quels conseils donneriez-vous aux développeurs de jeux amateurs ?

Commencez plus petit que ce dont vous pensez avoir besoin, prototypez la mécanique risquée avant de construire quoi que ce soit d’autre, et choisissez une pile technologique en fonction de la taille de votre équipe et du type de jeu plutôt que de ce qui est à la mode. Sortir un seul petit jeu terminé vous en apprendra plus que d’en commencer cinq ambitieux.