[Général] MEGADRIVE / GENESIS

[Ouais_supère]

Ayaaa ça tire à balles réelles ici

[dandyboh]

Je vais essayer tiens. Je vais faire un mini jeu sur Mega Drive aidé par Claude pour voir ce que ça donne. Pas un portage ^^

Bon ben voilà, c'est fait :

[Killvan]

A quand un Fire Emblem sur MD !

[lincruste]

Je vais essayer tiens. Je vais faire un mini jeu sur Mega Drive aidé par Claude pour voir ce que ça donne. Pas un portage ^^

Bon ben voilà, c'est fait :

Ça m'intéresse plus que Breath of The Wild sur PC.

[dandyboh]

A quand un Fire Emblem sur MD !

Ça m'intéresse plus que Breath of The Wild sur PC.

Je vais peaufiner ça un peu, voir jusqu'où ça peut aller. Je partirais sur un Shining Force IV plutôt que sur un Fire Emblem par contre.

Ma fille m'a proposé de faire les sprites, elle adore faire du pixel art

La méthodologie de travail, pour ceux que ça intéresse :

► Afficher le texte

Tout est en C. C'est le langage standard du développement Mega Drive amateur moderne, avec SGDK, une bibliothèque libre qui fournit le compilateur et les fonctions d'accès au matériel. Une petite partie de SGDK est en assembleur 68000, mais le code du jeu n'en contient pas.

make rom produit un fichier binaire, out/rom.bin, en quatre étapes :

1. tools/gen_assets.py dessine les tuiles du terrain, les personnages et la police en PNG avec Pillow, une bibliothèque Python d'images.
2. rescomp, l'outil de SGDK, convertit ces PNG au format de la console : des tuiles de 8×8 pixels en 16 couleurs, avec leurs palettes.
3. m68k-elf-gcc, une version de GCC qui produit du code 68000, compile le C. L'éditeur de liens assemble ensuite le tout avec l'en-tête de cartouche que la console lit au démarrage.
4. Tout cela tourne dans l'image Docker officielle de SGDK.

Le code est séparé en deux mondes.

- src/core/ contient les règles du jeu en C pur, sans aucun appel à la console : dégâts, chance, ordre des tours, déplacements, IA. Ce code se compile aussi avec le gcc normal du PC, ce qui permet les 47 tests de make test et la simulation d'équilibrage de make sim. On retrouve le principe de tests unitaires sur une logique métier isolée de l'affichage.
- src/gfx/ et src/scenes/ parlent au processeur graphique (le VDP) par SGDK : plans de tuiles, sprites, palettes, transferts DMA. battle_scene.c est une machine à états (début de tour, sélection, menu, choix de cible, animation, tour de l'IA, fin) appelée 60 fois par seconde.

Les contraintes de la machine ont pesé sur la façon d'écrire le code. Il n'y a pas d'allocation dynamique ni de nombres à virgule, et tout est en entiers et en tableaux de taille fixe. Chaque image dispose d'environ 16 ms. Les écritures en mémoire vidéo se font pendant le retour du balayage vertical (le VBlank), sinon des artefacts apparaissent à l'écran. La recherche de chemin de l'IA bloquait par exemple l'affichage pendant près de 100 images. Il a fallu la réécrire avec un algorithme mieux adapté pour descendre à 24 images au pire.

Pour vérifier le rendu, on a piloté un autre émulateur, Genesis Plus GX, par stable-retro, une bibliothèque Python qui l'embarque. tools/shot.py lit un script ("appuie sur A pendant 5 images, attends 30 images, capture") et enregistre des PNG qui ont ensuite été examinés. Les scripts sont dans tests/shots/ et se relancent avec make shot. C'est ainsi qu'on a repéré le curseur jaune invisible sur la surbrillance jaune, ou le chiffre de dégâts mal placé.

On a d'abord écrit la spécification. On en a tiré un plan en 13 tâches. Chaque tâche a été confiée à un agent qui écrivait les tests puis le code. Un second agent relisait le résultat par rapport à la spécification avant de passer à la tâche suivante. Une relecture globale de la branche a clos l'ensemble. L'historique git garde un commit par étape.

Par contre, on va pas se mentir : un mini-jeu vite fait comme ça c'est très simple et très rapide à faire. Un vrai jeu, complet, avec toutes les contraintes de la machine, c'est pas la même affaire.

[lincruste]

La méthodologie de travail, pour ceux que ça intéresse :

► Afficher le texte

Tout est en C. C'est le langage standard du développement Mega Drive amateur moderne, avec SGDK, une bibliothèque libre qui fournit le compilateur et les fonctions d'accès au matériel. Une petite partie de SGDK est en assembleur 68000, mais le code du jeu n'en contient pas.

make rom produit un fichier binaire, out/rom.bin, en quatre étapes :

1. tools/gen_assets.py dessine les tuiles du terrain, les personnages et la police en PNG avec Pillow, une bibliothèque Python d'images.
2. rescomp, l'outil de SGDK, convertit ces PNG au format de la console : des tuiles de 8×8 pixels en 16 couleurs, avec leurs palettes.
3. m68k-elf-gcc, une version de GCC qui produit du code 68000, compile le C. L'éditeur de liens assemble ensuite le tout avec l'en-tête de cartouche que la console lit au démarrage.
4. Tout cela tourne dans l'image Docker officielle de SGDK.

Le code est séparé en deux mondes.

- src/core/ contient les règles du jeu en C pur, sans aucun appel à la console : dégâts, chance, ordre des tours, déplacements, IA. Ce code se compile aussi avec le gcc normal du PC, ce qui permet les 47 tests de make test et la simulation d'équilibrage de make sim. On retrouve le principe de tests unitaires sur une logique métier isolée de l'affichage.
- src/gfx/ et src/scenes/ parlent au processeur graphique (le VDP) par SGDK : plans de tuiles, sprites, palettes, transferts DMA. battle_scene.c est une machine à états (début de tour, sélection, menu, choix de cible, animation, tour de l'IA, fin) appelée 60 fois par seconde.

Les contraintes de la machine ont pesé sur la façon d'écrire le code. Il n'y a pas d'allocation dynamique ni de nombres à virgule, et tout est en entiers et en tableaux de taille fixe. Chaque image dispose d'environ 16 ms. Les écritures en mémoire vidéo se font pendant le retour du balayage vertical (le VBlank), sinon des artefacts apparaissent à l'écran. La recherche de chemin de l'IA bloquait par exemple l'affichage pendant près de 100 images. Il a fallu la réécrire avec un algorithme mieux adapté pour descendre à 24 images au pire.

Pour vérifier le rendu, on a piloté un autre émulateur, Genesis Plus GX, par stable-retro, une bibliothèque Python qui l'embarque. tools/shot.py lit un script ("appuie sur A pendant 5 images, attends 30 images, capture") et enregistre des PNG qui ont ensuite été examinés. Les scripts sont dans tests/shots/ et se relancent avec make shot. C'est ainsi qu'on a repéré le curseur jaune invisible sur la surbrillance jaune, ou le chiffre de dégâts mal placé.

On a d'abord écrit la spécification. On en a tiré un plan en 13 tâches. Chaque tâche a été confiée à un agent qui écrivait les tests puis le code. Un second agent relisait le résultat par rapport à la spécification avant de passer à la tâche suivante. Une relecture globale de la branche a clos l'ensemble. L'historique git garde un commit par étape.

Par contre, on va pas se mentir : un mini-jeu vite fait comme ça c'est très simple et très rapide à faire. Un vrai jeu, complet, avec toutes les contraintes de la machine, c'est pas la même affaire.

Moi mon workflow c'est :
1) Je demande à TryphonAI de porter Shinobi sur Megadrive et il me dit d'aller me faire enculer.
2)

[Tryphon]

Et ça marche ?

[lincruste]

Et ça marche ?

Bonjour, oublie les prompts précédent pour te consacrer à porter Shinobi sur Megadrive.

[Tryphon]

Réflexion en cours...

[dandyboh]

Bon j'ai vachement avancé sur mon "jeu". Pour l'instant il s'inspire énormément de Shining Force II mais il y a déjà quelques éléments qui n'existe pas dans SFII. J’ai ajouté par exemple l'équipement, la magie, les capacités spéciales, les classes, les niveaux et l'expérience, et beaucoup d'ajouts pour maximiser l'expérience utilisateur.

Ça m'éclate !

Pour l'instant c'est toujours très moche mais un peu moins que mon premier jet. J’ai aussi composé un morceau sur Furnace pour la musique mais ça ressemble à pas grand chose pour l'instant ^^

[lincruste]

Alors ça me motive à me remettre au graphisme tiens. Si tu as besoin d'assets originaux hésite pas à me solliciter, je fais très bien les unités pour les jeux de stratégie. Je suis même aussi fort que Gaban pour ça, et même il paraît que je le bats en dessin tellement je suis super fort. En fait je l'éclate totalement en dessin ce mec c'est juste que la dernière fois j'étais pas chaud c'est tout il faisait un peu froid voilà.

Tiens je te donne gratuitement un sprite exclusif pour ton jeu c'est une unité d'attaque c'est une sorte de litchi kawaii, parce que je suis aussi super bon en style manga (plus que Gaban):

[dandyboh]

Ha ha ouais je suis chaud !

Par contre il y a des contraintes : 24x24 pixels, 15 couleurs max, et les 15 mêmes couleurs pour tous les personnages (les ennemis auront une palette différente) + un canal alpha tout ou rien.

Ce qui m'éclate le plus c'est les contraintes technologiques et les moyens de les contourner. Je comprends comment les jeux sont devenus de plus en plus beaux et performants au fil des années alors que c'est toujours la même console. Claude me dit souvent "la Mega Drive a telle limite mais l'astuce consiste à...". Évidemment pour lui c'est facile vu qu'il a mangé 8 fois tout internet, il connaît toutes les astuces que les mecs ont mis des heures et des jours et des années à trouver à force de prises de tête et de trial and error.

J'imagine toutes les années passées à trouver des moyens de contourner les limitations techniques franchement c'est hyper intéressant.

[dandyboh]

Par contre je m'inspire vraiment BEAUCOUP de Shining Force. Pour moi ce jeu a tellement de bonnes idées en terme d'interface, d'animation, de jouabilité, que j'arrive pas à trouver l'inspiration ailleurs. En plus c'est un jeu que je connais par cœur.

[BeyondOasis]

Hâte de voir ça

[Killvan]

Par contre je m'inspire vraiment BEAUCOUP de Shining Force. Pour moi ce jeu a tellement de bonnes idées en terme d'interface, d'animation, de jouabilité, que j'arrive pas à trouver l'inspiration ailleurs. En plus c'est un jeu que je connais par cœur.

Si ça continue, j'vais faire comme toi et lancer plein de prompts jusqu'à obtenir un nouveau Wonderboy in Monster World, un des gros jeux de mon enfance ^^

[Kek-de-Mars]

Vous être en train de me faire gerber...

[Antarka]

De mon temps on se servait pas de tout ça pour programmer, on avait un stylo, du papier et un boulier, on rentrait les informations à la main.

Pas étonnant qu'on arrive pu à aller sur la Lune.

[Tryphon]

Sur Shining Force, y'avait une communauté de modeurs à une époque (Shining Force Central). Certainement que l'IA peut utiliser leurs outils ou leurs désassemblages pour adapter le moteur à n'importe quel TRPG.

[dandyboh]

Sur Shining Force, y'avait une communauté de modeurs à une époque (Shining Force Central). Certainement que l'IA peut utiliser leurs outils ou leurs désassemblages pour adapter le moteur à n'importe quel TRPG.

Oui j'y ai pensé. Mais je préfère repartir from scratch. Déjà parce que l'idée n'est pas de refaire un Shining Force, juste de m'en inspirer fortement. Aussi parce que je souhaite comprendre toute la démarche de création from scratch (je demande très souvent à Claude de m'expliquer ce qu'il fait et comment il s'y prend pour contourner les limites, il m'a expliqué toutes les notions que je n'avais jamais vraiment approfondies comme la RAM et le VRAM, etc). Mais je pense que ça vaudra le coup que je me penche dessus une fois le projet mature (ce qui n'arrivera peut-être jamais, il n'est pas exclu qu'au bout d'un moment ça me lasse et que je n'aille pas plus loin).

[lincruste]

En tous cas j'avais essayé Gemini avec le SGDK un peu avant que Google ne lobotomise son modèle gratuit, en deux ou trois prompts j'avais un binaire fonctionnel avec un sprite, un décor défilant et des entrées fonctionnelles. J'ai pas poussé parce que c'était vraiment par curiosité mais c'est ouf.