On peut faire faillite dans le jeu. Perdre sa sauvegarde est le problème du développeur

Un jeu économique a le droit d’être exigeant. Le joueur peut prendre une mauvaise décision, perdre de l’argent et découvrir que sa compréhension du commerce mérite une mise à jour. Mais perdre sa progression à cause d’un changement de connexion est une méthode pédagogique plutôt douteuse.

Alistera Game est un jeu de stratégie commerciale situé à Dubaï. Le projet attribue le concept et le développement du jeu à Andrey Merzhalilov. Mon cas porte sur la plateforme technique et les outils de développement : application autonome, migration des joueurs, organisation des données et modifications contrôlées avec l’AI.

Cette vue ouvre l’équipe d’une entreprise fictive dans Alistera Game. On peut examiner les personnes, la charge et les actions disponibles ; aucune sauvegarde de joueur réel n’est utilisée ici.

Équipe de l’entreprise

Interface archivée · données de démonstration

Avant de migrer la progression, identifier la personne

L’application utilise React, TypeScript et Vite, avec Cloudflare Workers et D1 côté serveur. L’inscription est confirmée par email et magic link. Lors du passage depuis l’ancien système, saisir une adresse familière ne suffit pas à identifier un joueur existant.

Il faut un lien avec l’identité précédemment vérifiée. La progression accumulée est transférée ensuite. Sinon, une jolie nouvelle connexion peut distribuer les sauvegardes d’autrui ou faire recommencer tout le monde à zéro.

Voici un état préparé de la même entreprise après son premier projet achevé. Il permet de voir la suite du scénario sans refaire toutes les étapes précédentes.

Entreprise en deuxième semaine

Interface archivée · données de démonstration

Pour l’utilisateur, cela doit se passer sans histoire. Pour le développeur, c’est le transfert d’un état précieux, où « presque la même personne » est une définition totalement inacceptable.

Les règles du jeu ont aussi besoin d’une source

Le projet possède un modèle formel de game design et des outils qui le compilent en vues liées. L’index et l’atlas aident à examiner le jeu sans devenir une autre copie indépendante des règles. Les vérifications d’équilibrage portent sur un modèle précis ; un beau diagramme ne prouve rien à lui seul.

Le service distinct Dubai Numbers prépare des instantanés de données à son rythme. Le jeu les reçoit par une connexion de service. C’est mieux que de demander à un modèle de langue, pendant un tour, d’inventer un chiffre actuel plausible sur la ville. L’instantané est daté ; les données ont une source et des limites d’application.

L’auteur a besoin d’un outil auquel on ne peut pas confier tout le jeu par accident

Alistera Author est développé pour modifier le projet : une interface privée de travail avec l’AI via MCP. On peut examiner les sources et préparer une modification. Chaque correction possède une révision de départ, un état attendu des fichiers et un patch enregistré.

Une version précise est ensuite vérifiée, le staging préparé et la recette effectuée. Recevoir une réponse de l’outil ne prouve pas que la modification a passé les contrôles. Le processus ne doit pas fusionner automatiquement chaque conversation réussie en production.

C’est particulièrement intéressant dans un jeu : une ligne change facilement, ses effets peuvent apparaître bien des tours plus tard. L’agent peut proposer une nouvelle mécanique. Le système qui l’entoure doit aider à comprendre quel jeu nous obtiendrons exactement.

Ma contribution est la plateforme technique et le processus de modifications vérifiables. Andrey reste l’auteur du jeu. L’équipe et l’état de la deuxième semaine permettent d’observer le déroulement ; ils ne prouvent seuls ni l’équilibrage ni la disponibilité de tous les outils d’auteur.

Articles liés : Le studio et notre travail commun · CRM opérationnel d’Alistera.