Project Zomboid Modding : Lua et guide de l'IA

Qu’est-ce que le modding du projet Zomboid ?

Modding du projet Zomboid est la création légitime de contenu personnalisé et de modifications de gameplay pour Project Zomboid en utilisant la structure de mod prise en charge par le jeu, les définitions de données, les scripts Lua le cas échéant et les canaux de distribution approuvés tels que Steam Workshop. Un mod peut ajouter ou modifier des éléments, des recettes, des traits, des professions, des options de bac à sable, le comportement de l'interface utilisateur, le contenu du monde ou les systèmes de jeu, en fonction de la version actuelle et des API disponibles pour les créateurs.

Il ne s'agit pas de modifier l'exécutable, de contourner les règles anti-triche ou de serveur, de voler des actifs ou d'obtenir un avantage injuste sur des serveurs qui n'autorisent pas le mod. Un mod responsable doit être clair sur ce qu'il change, compatible avec la version qu'il cible et testé avant d'être partagé.

💡 Key idea: Un mod stable n’est pas simplement un mod qui se charge une seule fois. Il a une portée définie, des dépendances claires, un comportement de mise à niveau sécurisé et un chemin de test pour les situations que les joueurs créeront réellement.

Bases du Modding du projet Zomboid : Structure, Metadata, Data et Lua

Avant d'écrire un comportement, comprenez les quatre couches qui permettent à un mod de rester compréhensible. Les noms exacts des dossiers et les fichiers pris en charge peuvent différer selon la version du jeu, utilisez donc la documentation officielle actuelle et les mods compatibles existants comme références plutôt que de copier aveuglément un ancien didacticiel.

Mod identity and metadata

Vos métadonnées identifient le mod, le décrivent aux joueurs et établissent les informations nécessaires au chargement et à la distribution. Utiliser tôt une identité interne stable ; le renommer négligemment plus tard peut compliquer les sauvegardes, les dépendances et les mises à jour.

Data definitions

De nombreuses fonctionnalités s'expriment à travers les données du jeu : définitions d'objets, recettes, traits, métiers, configuration liée au butin ou encore options de bac à sable. Traitez ces fichiers comme faisant partie de la conception du gameplay et non comme une configuration jetable.

Lua scripts

Lua est utile lorsqu'un mod a besoin d'une logique que les définitions de données à elles seules ne peuvent pas exprimer. Gardez les scripts étroits, nommez les fonctions en fonction du comportement qu'elles possèdent et évitez de mélanger des systèmes non liés dans un seul fichier. Un petit script explicite est plus facile à déboguer après une mise à jour du jeu.

Assets and localization

Les textures, les modèles, les sons, les éléments de l'interface utilisateur et le texte traduit nécessitent la même discipline que les scripts : des noms stables, une propriété claire et un test qui confirme que le jeu peut les trouver. N'utilisez pas d'actifs sans autorisation.

Comment Plan un mod Project Zomboid avant d'écrire Lua

Commencez par une promesse destinée au joueur, pas par un dossier. « Ce mod rend la progression précoce en menuiserie moins répétitive » est un meilleur point de départ que « Je souhaite ajouter cinq recettes ». Définissez ensuite ce que le joueur peut faire, quels systèmes existants le mod touche, ce qui ne devrait jamais changer et comment le succès sera mesuré dans une nouvelle sauvegarde.

Pour un petit exemple, imaginez un trait de survie qui accorde un avantage d'artisanat limité et clairement décrit. Décomposez-le en six décisions : définir l'effet du joueur ; identifier le personnage concerné et l'état du jeu ; décider si les données ou Lua sont propriétaires du comportement ; lister les exclusions et les considérations multijoueurs ; définir les attentes en matière de sauvegarde/chargement et de réinitialisation ; et concevoir des cas de test avant la mise en œuvre.

Il s’agit d’un pseudo-code conceptuel, pas d’une solution copier-coller pour chaque build :

WHEN: a supported character state is evaluated
IF: the character has the approved trait
    AND the feature is enabled by the current settings
THEN: apply the defined, limited crafting benefit
      show clear feedback where appropriate
      preserve normal behavior for everyone else
TEST: new save, existing save, disabled setting, multiplayer policy, reload

Ce plan rend visibles les choix cachés. Cela évite également une erreur de modding courante : ajouter d'abord un crochet large et découvrir plus tard seulement qu'il affecte tous les joueurs, s'exécute trop souvent ou se comporte de manière imprévisible après un rechargement.

Débogage du projet Zomboid Modding : journaux, ordre de chargement et tests propres

La plupart des débogages deviennent plus faciles lorsque vous séparez les échecs en catégories. Le mod apparaît-il dans le jeu ? Est-ce que ça charge ? La définition des données est-elle résolue ? Un événement Lua est-il exécuté ? Le comportement fonctionne-t-il uniquement dans une ancienne sauvegarde, uniquement dans une nouvelle sauvegarde, ou uniquement lorsqu'un autre mod est présent ? Ne modifiez pas trois fichiers à la fois et espérez que l'erreur disparaît.

Les journaux font partie du processus de développement et ne sont pas une réflexion secondaire. Lisez la première erreur pertinente, identifiez le fichier et la ligne ou l'identifiant impliqué, et apportez la plus petite modification qui teste une explication spécifique. Conservez un profil de test propre ou une sauvegarde contrôlée lorsque cela est possible. Lors de la vérification de la compatibilité, utilisez uniquement les mods nécessaires au test et enregistrez leurs versions et leur ordre de chargement.

• Confirmez que le mod est activé et que son identité correspond à la configuration prévue.
• Vérifiez la première erreur utile dans le journal avant de rechercher les symptômes ultérieurs.
• Testez les sauvegardes nouvelles et existantes séparément lorsque la persistance de l’état est importante.
• Vérifiez l'ordre de chargement et les dépendances déclarées pour les tests de compatibilité.
• Reproduisez avec la plus petite configuration possible.
• Testez d'abord le mode solo, puis uniquement les environnements multijoueurs autorisés.

Using AI pour le modding du projet Zomboid sans perdre le contrôle

L’IA est plus précieuse lorsqu’elle réduit les frais de planification et de documentation. Il peut transformer une demande de fonctionnalité approximative en un brief de mod, suggérer des questions sur la compatibilité des sauvegardes, expliquer un extrait de code Lua en langage simple, transformer un message de journal en hypothèses de débogage ou produire une liste de contrôle de régression ciblée. Il ne s'agit pas d'une documentation faisant autorité pour la version actuelle du jeu.

Demandez à l'IA de montrer ses hypothèses. S'il recommande une disposition d'événement, d'API, de propriété ou de dossier, comparez ces conseils avec les références actuelles de Project Zomboid et un test local. L’IA peut inventer en toute confiance des API obsolètes ou mal lire un extrait de journal. Traitez sa réponse comme une hypothèse de départ, et non comme une raison pour proposer un changement non testé.

Comment utiliser EasyClaw comme agent de modding du projet Zomboid

EasyClaw est utile ici car il s'agit d'un agent IA natif de bureau, et pas seulement d'une fenêtre de discussion. Donnez à l'agent un objectif tel que "ajouter et tester une petite fonctionnalité d'artisanat dans ce projet de mod local", et il pourra planifier le travail, utiliser les compétences et les outils de bureau approuvés, inspecter les fichiers locaux, rédiger ou mettre à jour les documents de travail que vous approuvez, vérifier les résultats et signaler ce qui s'est passé. Le créateur garde le contrôle du client Project Zomboid, des API actuelles, des modifications des sources et des décisions de version finale.

EasyClaw ne doit pas modifier l'exécutable du Project Zomboid, contourner la politique du serveur, rejoindre des serveurs restreints ou publier un élément du Steam Workshop sans votre approbation explicite. Son rôle pratique est de transformer le travail autour de la création légitime de mods en une boucle d'exécution : comprendre → planifier → inspecter → agir → vérifier → rapporter. Cela signifie moins de copie entre un chat, un éditeur, un explorateur de fichiers, des journaux, des captures d'écran et une liste de contrôle de publication.

1. Create a dedicated Modding Expert Agent

Au lieu d'utiliser une conversation générique pour chaque tâche, créez un agent expert tel que “Project Zomboid Mod Maintainer.” Sa responsabilité peut se limiter à examiner votre dossier de mod, à rédiger un plan de changement, à lire Lua et les fichiers de données, à collecter des preuves de journal, à préparer des tests et à produire des notes de version. Joignez les compétences pertinentes pour le travail sur les fichiers locaux, la recherche dans le navigateur, la gestion des documents et les actions approuvées sur le bureau. Cela donne à l'Agent un rôle stable plutôt que de demander à un assistant général de redécouvrir votre processus à chaque fois.

2. Save stable project rules in MEMORY.md

Demandez à l'agent d'écrire uniquement des faits et des SOP durables sur le projet dans MEMORY.md : le chemin du module local, la version cible du Project Zomboid, les dépendances prises en charge, les conventions de dénomination, les règles de présentation des fichiers, l'emplacement de sauvegarde du test, l'emplacement du journal, le format de la note de version et la définition exacte de « prêt à tester ». Lors des sessions ultérieures, l'agent lit cette mémoire en premier, donc une requête telle que « examiner la dernière modification de conception » démarre avec le contexte de projet correct au lieu de vous obliger à coller à nouveau la même configuration.

Ne stockez pas les détails temporaires d’un bug ou une expérience ponctuelle dans la mémoire permanente. Conservez-les dans le rapport de tâche actuel. La mémoire doit conserver des règles qui seront encore utiles la semaine prochaine : par exemple, « ne jamais écraser un fichier mod stable sans sauvegarde », « tester une sauvegarde propre avant une sauvegarde existante » ou « enregistrer le numéro de build et les versions de dépendances dans chaque rapport de compatibilité ».

3. Define safety boundaries in SOUL.md

Utilisez SOUL.md comme limite opérationnelle de l'expert Modding. Il peut exiger que l'agent demande avant de modifier les fichiers sources, interdire la suppression des sauvegardes ou l'écrasement des archives de version, exiger une sauvegarde avant une modification multi-fichiers, interdire la publication non approuvée et s'arrêter lorsqu'une question de politique de serveur ou de licence d'actif n'est pas claire. C'est plus utile qu'une vague instruction de « faire attention » : cela indique à l'Agent quelles actions sont autorisées, lesquelles sont interdites et lesquelles nécessitent votre confirmation.

4. Give the Agent an execution-contract prompt

Une invite EasyClaw forte décrit le déclencheur, les entrées, les actions autorisées, la validation et le résultat attendu. Par exemple:

Goal: Review the current crafting-trait change in my local mod project.
Inputs: The mod folder, the latest log, and the test checklist in the project docs.
Allowed actions: Read files, summarize Lua and data changes, create a dated backup,
                 update the test checklist, and draft a bug report.
Do not: Change game files, delete saves, publish to Steam Workshop, or overwrite source
        without asking me first.
Verify: Confirm referenced files exist, identify relevant log errors, and list tests that remain.
Output: A short change summary, risk list, exact test steps, and files requiring my review.

Cela transforme une demande occasionnelle en un contrat d’exécution réutilisable. L'agent peut décider quelle compétence appeler, effectuer le travail de bureau approuvé, vérifier si les fichiers et sorties requis existent et renvoyer un rapport utile pour l'étape suivante.

5. Convertissez les contrôles répétés en flux de travail de compétences et RPA

Une fois votre flux de travail stable, transformez les tâches répétées en compétences réutilisables ou en automatisation RPA. Un flux de travail de « contrôle en amont du mod » peut collecter la version actuelle, inspecter le dossier du mod, comparer les fichiers modifiés avec la liste de contrôle de la version, lire le journal le plus récent, créer un package de test daté et enregistrer un rapport dans un emplacement connu. Le modèle est utilisé pour concevoir le flux de travail et gérer les exceptions ; les exécutions répétées de RPA suivent les étapes enregistrées, de sorte que l'exécution de routine ne consomme pas de manière répétée des jetons de modèle.

Gardez chaque automatisation étroite et révisable. Une première automatisation sécurisée organise les preuves et prépare une liste de contrôle. Il ne doit pas modifier silencieusement les sauvegardes, mettre à jour en masse les fichiers sources ou publier du contenu. Utilisez /stop pour arrêter immédiatement l'automatisation, /reset lorsque vous avez besoin d'un nouveau contexte de tâche et /compress pour réduire une longue conversation de projet sans supprimer les règles stables conservées en mémoire.

6. Run and monitor work from a remote channel

Lorsque l'agent de bureau et un canal distant approuvé sont connectés, vous pouvez envoyer une tâche depuis WeChat, Feishu, DingTalk, Telegram, WhatsApp, Discord, Slack ou QQ lorsque vous êtes loin de l'ordinateur. Par exemple : « Exécutez le contrôle en amont du mod, lisez le dernier journal et envoyez-moi uniquement des bloqueurs. » EasyClaw peut exécuter le flux de travail local approuvé et renvoyer les preuves ou le rapport à ce canal. Les conversations de canal ont un contexte distinct, donc stockez les règles de projet multicanal dans MEMORY.md plutôt que de supposer qu'une instruction Discord est automatiquement mémorisée dans une conversation de bureau.

Example : Exécution d'un changement de mod du projet Zomboid avec EasyClaw

Supposons que vous souhaitiez ajouter une modeste fonctionnalité de qualité artisanale. Tout d’abord, indiquez à votre agent de maintenance du module Project Zomboid la valeur du joueur, la limitation exacte, les attentes en matière de configuration et si la fonctionnalité est destinée aux sauvegardes existantes. L'agent lit les règles stables du projet dans MEMORY.md, transforme la demande en plan de modification et identifie les fichiers source, les définitions de données, les dépendances et les scénarios de test qui nécessitent votre attention.

Après avoir approuvé le plan, l'agent peut utiliser ses compétences de fichiers locaux pour inspecter les fichiers de projet spécifiés, créer une sauvegarde datée si votre SOUL.md le permet, résumer l'Lua ou les modifications de données proposées et préparer une liste de contrôle de test de sauvegarde propre. Il vérifie ensuite son propre résultat : les fichiers référencés existent-ils, les vérifications requises ont-elles été documentées, a-t-il trouvé des erreurs de journal pertinentes et quelles actions nécessitent encore un examen humain ? Il rapporte le résultat au lieu de prétendre qu'un script généré est un mod réussi.

Ensuite, vous exécutez vous-même le test du jeu dans une configuration contrôlée. Renvoyez le résultat, les captures d'écran ou l'extrait du journal à EasyClaw. L'agent sépare les défauts confirmés des problèmes d'équilibre et des idées différées, met à jour le rapport de test daté et produit la plus petite action suivante. Lorsque cette routine se stabilise, la même séquence peut devenir un flux de travail de contrôle en amont RPA réutilisable ; depuis un canal distant, vous pouvez lui demander de préparer le rapport de contrôle en amont avant de revenir sur votre bureau.

Liste de contrôle du modding du projet Zomboid avant de partager un mod

• Le mod a un objectif clair et ne regroupe pas d’expériences sans rapport.
• Metadata, les identifiants, les dépendances et les informations de build prises en charge sont exacts.
• Les fichiers Data definitions et Lua utilisent le format actuellement attendu.
• Vous avez testé la fonctionnalité dans une sauvegarde propre et enregistré les résultats attendus.
• Vous avez vérifié les journaux pour détecter les premières erreurs ou avertissements pertinents.
• Les comportements de sauvegarde, de rechargement, de désactivation et de dépendance sont compris.
• La compatibilité multijoueur n'est revendiquée qu'après des tests autorisés.
• Assets sont originaux, autorisés ou correctement sous licence.
• Release notes explique les changements, la compatibilité et les limites connues sans faire de promesses excessives.

FAQ

Conclusion : un meilleur modding de Project Zomboid provient d'une meilleure itération

Le modding Project Zomboid est un métier d’itération contrôlée. Les meilleurs mods commencent par un problème de joueur ciblé, utilisent la structure actuellement prise en charge, rendent leurs hypothèses explicites et gagnent la confiance grâce à des tests propres, des journaux utiles et des notes de compatibilité honnêtes. Lua est important, tout comme la portée, la propriété des données, la discipline des dépendances et une manière reproductible d'enquêter sur les échecs.

L'IA peut raccourcir le travail de planification et de révision autour de ces tâches, tandis qu'EasyClaw aide les créateurs à conserver le contexte qui disparaît généralement entre les sessions : briefs, mappages de fichiers, scénarios de test, notes de journal, commentaires et documentation de version. Il ne remplace pas les références actuelles du Project Zomboid ni la validation en jeu. Cela donne au créateur un moyen plus organisé d’atteindre les deux. Le but n’est pas d’automatiser aveuglément le modding ; il s'agit de rendre chaque révision plus facile à comprendre, à tester et à maintenir.