The Factory Must Fall est un jeu de stratégie développé et édité par Squared Games, un studio solo basé à Zurich. Le principe mélange construction d’usine, automatisation, auto battler et PvP asynchrone. On pioche des bâtiments dans une boutique aléatoire, on organise l’extraction, l’énergie et la production d’unités, puis on déclenche un combat qui se déroule automatiquement contre une autre usine. Le jeu est encore en alpha et aucune date de sortie n’est annoncée.
Un playtest est accessible sur Steam sur demande.
La version présentée à la gamescom avait été préparée pour le salon. Le PvP complet n’y était pas activé et le développeur avait construit une séquence plus scriptée pour permettre à quelqu’un qui découvrait le jeu de comprendre vite les bases. Cette build introduisait surtout plusieurs éléments d’interface destinés à rendre l’usine plus lisible, avec une nouvelle présentation de l’énergie et des ressources. C’est un point important, car The Factory Must Fall repose moins sur la vitesse d’exécution que sur la capacité à comprendre ce qui manque dans une chaîne, puis à décider où investir.
Chaque manche commence par une phase de construction. Des bâtiments sont proposés dans une boutique aléatoire et il faut décider lesquels acheter, où les placer et comment les alimenter. Les extracteurs récupèrent les ressources, les convoyeurs les transportent, le réseau électrique fait fonctionner les installations et les producteurs transforment cette économie en unités militaires. Lorsque le joueur estime son usine prête, il lance la bataille. Les deux bases produisent alors automatiquement leurs unités et celles ci avancent vers le noyau adverse.
Le combat est automatique, mais il doit rester compréhensible. La ligne de front permet déjà de voir assez bien quel camp prend l’avantage. Elle avance, recule et peut changer brutalement lorsqu’une nouvelle production entre en jeu. Le développeur donnait l’exemple d’une chaîne plus complexe qui met une vingtaine de secondes avant de sortir une grosse unité. Une usine peut sembler perdre au début du combat, puis retourner la situation lorsque cette production arrive enfin sur le terrain. La destruction du noyau termine la manche avant de revenir à une nouvelle phase de construction.
Cette séparation entre préparation et résolution est au centre du jeu. Contrairement à un RTS où l’on continue à déplacer chaque unité pendant le combat, les décisions importantes ont déjà été prises dans l’usine. Une mauvaise alimentation, un manque d’énergie ou un choix d’unité trop spécialisé finissent donc par se voir sur le front. L’idée est de regarder le résultat d’un système que l’on a construit, puis d’utiliser ce que l’on vient d’observer pour modifier la manche suivante.
La pioche aléatoire ajoute une autre couche. Le joueur ne peut pas reproduire exactement le même plan à chaque partie puisque les bâtiments disponibles, les ressources de la carte et sa disposition changent. Le développeur ne cherche toutefois pas à supprimer complètement la chance. Son raisonnement est plutôt qu’une mauvaise pioche occasionnelle fait partie de la formule, tout comme une excellente pioche peut créer un moment très favorable. La compétence doit venir de la capacité à jouer plusieurs runs et à tirer le meilleur parti de ce qui est disponible.
Un mécanisme de compensation est prévu pour limiter les longues séries de mauvaises propositions. Si le joueur accumule les tirages défavorables, ses chances de recevoir quelque chose de plus intéressant augmentent. L’objectif n’est donc pas de garantir une partie très bien symétrique, mais d’éviter que l’aléatoire décide trop souvent du résultat à lui seul. À niveau égal, la chance peut peser sur une manche. Sur la durée, le développeur veut que la connaissance du jeu et l’adaptation restent les facteurs principaux.
Les ressources jouent aussi sur la stratégie militaire. Une carte riche en ferrite favorise davantage les approches reposant sur beaucoup de petites unités, puisqu’elles consomment beaucoup de cette ressource. Une stratégie plus technologique demande au contraire davantage de ressources de niveau supérieur. L’économie disponible ne sert donc pas seulement à déterminer la vitesse de construction. Elle oriente naturellement les familles de builds que l’on peut mettre en place efficacement.
Cette logique rapproche The Factory Must Fall de jeux comme Factorio ou Mindustry sans reprendre leur structure. Dans Factorio, l’optimisation peut devenir un objectif en soi. Dans Mindustry, l’industrie alimente directement le front. Ici, l’usine détermine pratiquement toute la force militaire puisque ce sont les chaînes construites pendant la phase de préparation qui produiront les unités de la phase de combat. La lecture d’une base permet déjà de comprendre une partie de son orientation. Beaucoup de ferrite, certains producteurs et certaines installations suggèrent une stratégie de masse, tandis qu’un investissement plus lourd dans la technologie annonce autre chose.
Les unités suivent un système de contres assez classique. Les petites unités rapides, l’artillerie, les unités lourdes et les unités aériennes n’ont pas les mêmes usages. Une composition entièrement tournée vers un seul type peut être très forte dans une situation et complètement exposée dans une autre. Une usine dépourvue de défense antiaérienne peut par exemple devenir vulnérable dès qu’un adversaire produit assez d’unités volantes. Le but est donc de trouver un équilibre entre spécialisation et capacité à survivre à une stratégie que l’on n’a pas forcément anticipée.
Cette incertitude est volontaire. Le joueur ne voit pas à l’avance l’usine qu’il va affronter et ne peut pas examiner le prochain adversaire pour fabriquer un contre très bien adapté. Le développeur a choisi de conserver cette information cachée. Selon lui, montrer précisément le build suivant pousserait trop facilement à créer une réponse extrêmement spécialisée, efficace contre cet adversaire mais mauvaise contre presque tout le reste. L’absence d’informations oblige plutôt à construire une usine cohérente capable de supporter plusieurs scénarios.
Ce choix prend encore plus de sens avec le PvP asynchrone. The Factory Must Fall ne demande pas que deux joueurs soient connectés en même temps. Une usine terminée est enregistrée et peut ensuite être affrontée comme le fantôme d’un autre joueur, un peu comme un temps fantôme dans un jeu de course. Le résultat de ces confrontations permet d’ajuster la valeur des builds stockés sur le serveur et de proposer des adversaires correspondant autant que possible au niveau du joueur.
Cette architecture règle en partie le problème d’une petite population. Même lorsqu’aucun adversaire de niveau similaire n’est connecté à cet instant, des constructions précédemment enregistrées restent disponibles. Si le nombre de builds est encore faible, le système peut toutefois être obligé d’utiliser celui dont le niveau est le plus proche sans obtenir un appariement parfait. Le développeur prévoit aussi de remplir au départ la population avec des usines de différents niveaux afin que le classement ne commence pas complètement vide.
Un système de saisons fait partie des plans pour stabiliser cet environnement compétitif. Chaque saison conserverait un équilibre et un ensemble de bâtiments déterminés. Une nouvelle saison pourrait alors accompagner une modification importante du balancing, l’arrivée de contenu supplémentaire et une remise à zéro du classement. Cette séparation éviterait entre autres de comparer directement une usine enregistrée sous une ancienne version du jeu à une autre construite après une modification majeure des unités ou de l’économie.
Le suivi des données doit aussi aider à équilibrer les stratégies. Le développeur regarde les bâtiments présents dans les usines sauvegardées et leur classement. Si un élément apparaît très souvent dans des builds qui perdent beaucoup, cela peut signaler qu’il est trop faible ou qu’il pousse les joueurs vers une mauvaise direction. À l’inverse, une famille de constructions qui domine souvent peut révéler un problème d’équilibrage. L’objectif est de reconnaître plusieurs archétypes plutôt que de ne regarder qu’un taux de victoire général.
Lors de l’entretien, environ 800 personnes avaient déjà participé aux différents tests. Le développeur racontait qu’un des premiers playtests, qui n’avait réuni qu’environ 200 joueurs, avait pourtant déjà attiré quelques tricheurs. Certains avaient réussi à envoyer au serveur des valeurs impossibles et à créer des builds avec des ressources qui n’auraient pas dû exister. Le problème avait été corrigé avant notre rendez vous, mais l’anecdote montre assez bien les difficultés qui apparaissent très tôt dès qu’un classement compétitif et des données persistantes sont introduits.
La lisibilité des chaînes est justement l’un des sujets qui a beaucoup évolué pour la gamescom. Le développeur ne voulait pas d’un gigantesque panneau d’informations proche d’une feuille Excel pour comprendre pourquoi une usine ne fonctionne plus. La nouvelle interface utilise entre autres une barre d’énergie sur le côté de l’écran. Chaque réseau possède son propre indicateur, qui devient rouge lorsque la production est insuffisante et vert lorsqu’elle est correcte. En passant dessus, on obtient davantage de détails sur les bâtiments qui consomment ou produisent l’énergie.
La même philosophie s’applique aux ressources. Les vues dédiées doivent permettre de repérer vite une surproduction d’un côté et un manque de l’autre. L’objectif est d’identifier sur le plan visuel le goulot d’étranglement avant de rentrer dans le détail. Une usine peut disposer d’assez de matières premières mais manquer de convoyeurs, produire assez d’électricité sur un réseau mais pas sur un autre, ou juste alimenter une mauvaise chaîne. Plus la base s’étend, plus cette capacité à comprendre vite le problème devient importante.
La durée d’un run fait aussi partie des paramètres que Squared Games surveille. Le plaisir d’un factory builder vient souvent du moment où une petite installation devient une énorme machine avec de nombreuses lignes parallèles. Le problème est qu’un roguelite demande ensuite de recommencer. Investir trois heures dans une usine pour la voir disparaître à la fin d’un run risque de rendre la remise à zéro beaucoup plus frustrante que dans un jeu où la construction reste permanente.
La durée actuelle se situe plutôt autour de trente à quarante minutes, avec environ quarante cinq minutes évoquées comme une cible intéressante. Cela laisse assez de temps pour voir l’usine grossir tout en conservant un format où recommencer ne signifie pas abandonner plusieurs heures de travail. Une partie peut aussi être interrompue puis reprise plus tard, ce qui correspond bien à cette volonté de proposer des runs assez compacts.
Cette durée doit permettre plusieurs styles de jeu. Une stratégie agressive peut chercher à produire très vite beaucoup de petites unités afin de gagner avant que l’adversaire n’ait développé sa technologie. À l’opposé, un joueur peut investir davantage dans l’économie, installer beaucoup de défenses et attendre une unité de fin de partie assez forte pour renverser la situation. Des approches plus atypiques existent aussi, avec des unités aériennes ou des trajectoires soigneusement définies.
Le développeur m’a donné un exemple assez parlant de ce que les joueurs avaient déjà découvert pendant les tests. Un participant avait placé ses bâtiments de production très haut sur la carte puis utilisé les points de passage pour envoyer les unités jusqu’à l’extrémité opposée. Le déplacement faisait traverser une grande partie du terrain à ses troupes et permettait de couvrir des zones que le développeur n’avait pas imaginées en concevant le système. Ce type de comportement émergent est précisément ce qu’il cherche à préserver en évitant de réduire trop vite les possibilités lorsqu’une nouvelle stratégie apparaît.
Cette approche demande forcément beaucoup de tri dans les retours. Squared Games est essentiellement un projet solo, avec l’aide d’un artiste pour la partie visuelle. Le même développeur doit donc gérer le code, le design, les bugs, les nouvelles fonctionnalités, la communauté et une partie de la communication. Les demandes peuvent se contredire et certaines solutions souhaitées par des joueurs habitués à d’autres factory builders ne correspondent pas forcément au fonctionnement de celui ci. Les petites améliorations évidentes peuvent vite être intégrées, mais les changements plus structurels restent filtrés en fonction de leur impact sur l’ensemble du jeu.
D’autres contenus sont déjà envisagés. De nouveaux bâtiments et de nouvelles unités doivent élargir les possibilités de build, tandis que plusieurs biomes sont prévus. Le développeur évoquait entre autres des cartes terrestres, un monde de lave et une planète glacée. Les saisons pourraient aussi apporter des récompenses de classement, avec par exemple des badges ou des apparences permettant de montrer le niveau atteint pendant la saison précédente. Comme plusieurs de ces systèmes sont encore en développement, leur forme finale peut évoluer avant la sortie.
Pour commencer, la première erreur serait sans doute de traiter la boutique comme une simple liste d’achats. Les bâtiments disponibles doivent être lus avec la carte et les ressources présentes. Une grande quantité de ferrite donne une raison de tester une production de masse, alors qu’un accès plus confortable aux ressources avancées peut justifier de viser une technologie supérieure. Il vaut mieux adapter le plan à ce que le run propose plutôt que forcer systématiquement le même build.
Le réseau électrique mérite aussi d’être surveillé avant d’agrandir trop vite la production. La nouvelle barre d’énergie permet de repérer aussitôt un réseau en difficulté et il semble préférable de corriger ce problème avant d’ajouter encore des producteurs qui ne pourront pas fonctionner bien. Les vues de ressources remplissent le même rôle pour les matières premières. Une usine qui accumule énormément d’une ressource tout en bloquant ailleurs n’est pas forcément efficace.
Enfin, il faut accepter qu’une composition trop spécialisée comporte un risque. Le prochain adversaire reste caché et le système de contres peut sanctionner une base qui ne sait répondre qu’à un seul type d’unité. Une stratégie agressive ou un turtle de fin de partie sont tous les deux viables dans l’intention du développeur, mais aucun ne doit devenir une recette universelle. Observer les batailles et comprendre à quel moment la ligne de front bascule semble donc aussi important que gagner la manche elle-même.
The Factory Must Fall se distingue surtout par la manière dont il relie deux boucles que l’on voit souvent séparément. L’usine n’est pas uniquement une économie qui finance ensuite une armée. Elle est la machine qui produit cette armée, et la bataille sert de test grandeur nature à tout ce qui a été construit auparavant. Le PvP asynchrone permet ensuite de confronter ce système aux vraies usines d’autres joueurs sans imposer une connexion simultanée.
Le projet reste en alpha et beaucoup d’éléments doivent encore être enrichis, mais la build gamescom montrait déjà une priorité assez claire autour de la lisibilité. Les nouvelles vues d’énergie et de ressources répondent directement à un problème important pour ce type de jeu : comprendre vite pourquoi une chaîne qui semblait correcte ne produit pas ce que l’on attendait. Avec des runs assez courts, un draft qui oblige à s’adapter et des adversaires enregistrés plutôt que contrôlés en direct, Squared Games cherche à conserver le plaisir de construire une grande usine sans demander au joueur de la protéger pendant des dizaines d’heures.
