Aujourd'hui encore, les gens continuent de créer de nouveaux jeux pour les anciennes consoles. Nous les appelons homebrew . Parfois, c'est une façon de réaliser le rêve d'enfance de créer un jeu pour la console sur laquelle l'enfant a joué. Mais en plus, c'est aussi une tâche intéressante pour tout concepteur ou développeur de jeux: le rétro-fer avait de nombreuses limites qui mettaient à l'épreuve la créativité des auteurs. Dans les années 90 pour les développeurs professionnels, ces restrictions étaient familières. Aujourd'hui, quand nous avons des outils plus avancés, la création de jeux pour de telles machines est devenue beaucoup plus abordable.

L'année dernière, j'ai écrit un article sur la création d'un jeu pour Game Boy . Aujourd'hui, je partagerai mon expérience dans la création de trois jeux pour la console domestique SEGA Mega Drive / Genesis. Probablement, grâce à des outils puissants et modernes, c'est la machine la plus simple pour développer un jeu homebrew. Par exemple, j'ai même réussi à créer un jeu (très simple) en seulement 60 minutes, et il fonctionne en fait sur la console!

Les jeux

L'année dernière, pour célébrer le 30e anniversaire de la sortie de Genesis / Mega Drive, j'ai créé un jeu appelé 30 Years of Nintendon't . Comme son nom l'indique, c'est un hommage aux meilleurs jeux de la console et au marketing agressif que SEGA utilisait à l'époque (par exemple, le slogan «Genesis Does what Nintendon't»).


Dans ce jeu, nous contrôlons l'évangéliste SEGA, qui doit convaincre les joueurs d'oublier leurs NES et SNES, car Genesis a de meilleurs jeux! Le jeu est sorti gratuitement en ligne le 30e anniversaire de la console. Vous pouvez y jouer ici: https://drludos.itch.io/30-years-of-nintendont


Depuis, j'ai également créé deux (petits) jeux d'arcade pour la console:

"Casser un œuf"



"MeteoRain"


Tous ces 3 jeux sont vendus sur une cartouche publiée par Cote Gamers:

http://cotegamers.com/shop/en/genesis-mega-drive/43-test.html

Il est livré dans une belle boîte en plastique, comme de vrais jeux vintage, et avec un jeu de cartes postales.

Puis-je utiliser Unity, Unreal Engine ou Godot?

Désolé, mais ces moteurs ne sont pas en mesure d'exporter des jeux vers SEGA Mega Drive / Genesis (peut-être pour l'instant?). Mais ne vous inquiétez pas, il existe un autre outil qui est tout aussi utile que ces moteurs modernes populaires, et en même temps conçu spécifiquement pour Mega Drive / Genesis: SGDK . Il s'agit d'un framework qui vous permet d'écrire du code pour cette machine en C. Il est beaucoup plus simple et plus rapide que l'apprentissage du langage d'assemblage, qui était nécessaire dans les années 90. Mais ce n'est pas tout. SGDK dispose également d'outils pour simplifier la création de graphiques et de sons. Vous pouvez créer des graphiques dans votre éditeur graphique 2D préféré (de Photoshop à GIMP ou Asesprite) , et il sera converti automatiquement si vous respectez les restrictions matérielles (plus d'informations ci-dessous). La même chose s'applique au son: vous pouvez créer des effets sonores dans des fichiers .wav et utiliser différents trackers pour la musique. Une dernière chose: SGDK dispose d'un puissant "Sprite Engine" qui simplifie la plupart des tâches techniques d'affichage des images animées à l'écran. Mais dans quelle mesure est-ce "simple" en réalité? Dans l'article, je parlerai de ma propre expérience de travail.

Blast Processing apparaît sur la scène

Comme tout programmeur d'anciens systèmes vous le dira, si vous écrivez un programme en C au lieu d'assembleur, cela réduira les performances du jeu. Et c'est vrai. Mais les coûts des différentes consoles rétro varient considérablement. Ils dépendent du CPU utilisé, ainsi que de l'efficacité des compilateurs modernes qui créent du code pour de tels processeurs vintage. Heureusement, Mega Drive / Genesis utilise le processeur Motorola 68000, qui est assez bien adapté pour fonctionner avec les fonctionnalités du langage C. Cela est particulièrement vrai en comparaison avec d'autres processeurs, par exemple, avec la console SNES 65816. Bien que puissants en soi, les processeurs SNES sont difficiles à forcer pour exécuter des programmes écrits en C avec une vitesse suffisante. Autrement dit, quand il s'agit de développement homebrew C, "Blast Processing" n'est pas un mythe marketing, mais une réalité!

À quelle vitesse le code C peut-il s'exécuter?

Voici un exemple d'expérience personnelle - un GIF animé de mon jeu MeteoRain, dans lequel des sprites de 45 météorites se déplacent sans délai à une fréquence de 60 images par seconde:


Voici un autre exemple d'une explosion de Break An Egg, composée de 40 particules se déplaçant à une fréquence de 60 images par seconde:


Si vous prenez les anciens jeux comme exemple, alors un bon exemple de la puissance des processeurs Mega Drive / Genesis est Contra Hard Corps. Bien que le jeu ait été développé en assembleur plutôt qu'en C (après tout, c'était dans les années 90) , les développeurs pouvaient utiliser une énorme puissance de calcul pour déplacer de nombreux sprites sur l'écran et créer des boss accrocheurs avec des tonnes de pièces mobiles et des explosions massives.


À titre de comparaison, Contra III sur SNES était limité par la puissance du processeur et au lieu de déplacer le tas de sprites, Konami utilisait des effets graphiques uniques dont seule la puce vidéo SNES était capable, par exemple, l'effet de transparence.


Bien que les deux jeux soient également intéressants, ils mettent parfaitement en évidence les différences techniques entre SNES et Mega Drive / Genesis. Plus d'informations sur la façon dont Konami a créé chacun des jeux sous la console correspondante peuvent être trouvées dans l'article "Making of Contra III et Hard Corps" de Retro Gamer n ° 176 .

Restrictions graphiques

La puissance de calcul n'étant pas un problème, le principal goulot d'étranglement de la console Genesis / Mega Drive pour les développeurs homebrew est devenu ses limites graphiques. Et plus précisément, un nombre limité de couleurs affichées par elle. Bien qu'en général la console puisse générer 512 couleurs uniques, en même temps il ne peut y avoir plus de 64 couleurs à l'écran. Oups A titre de comparaison: SNES pourrait afficher 256 couleurs simultanément à partir d'une palette de 32768 couleurs uniques. C'est-à-dire que les graphistes avaient besoin de beaucoup de talent pour que les jeux SEGA soient aussi beaux que les consoles des concurrents. Et dans de nombreux cas, ils ont réussi. Malgré les restrictions de couleur, de nombreux anciens jeux Mega Drive / Genesis sont magnifiques, par exemple, Comix Zone, Story of Thor, Streets of Rage II, Ranger-X, Gunstar Heroes, Sonic 1-2-3, etc.


Zone Comix (1995)

Mais dans d'autres cas, les jeux Mega Drive / Genesis semblaient plutôt ternes par rapport aux versions SNES. L'un des exemples les plus célèbres est Street Fighter II, où les restrictions de couleur de la console sont très visibles:


L'utilisation optimale de palettes limitées (4 palettes de 16 couleurs pour Genesis contre 16 palettes de 16 couleurs pour SNES) était un grand défi pour les développeurs qui avaient généralement très peu de temps pour terminer les projets. Aujourd'hui, des membres talentueux de la communauté SEGA sont en mesure de modifier certains jeux pour optimiser l'utilisation des couleurs. Par exemple, Gabrielle Piron fait des merveilles avec des jeux comme Castlevania Blood Lines, Golden Axe, Outrun ou Street Fighter II susmentionné:


(Ci-dessus est la palette de couleurs de l'original, ci-dessous est un Gabriel modifié)

Dans cet esprit, vous pouvez utiliser votre éditeur graphique préféré pour créer des images, mais soyez très prudent lors du choix des couleurs! Si vous ne parvenez pas à faire correspondre la palette de 512 couleurs flashée dans l'équipement, ce n'est pas un problème: SGDK convertit automatiquement l'image en palette Mega Drive / Genesis. Mais en ce qui concerne le nombre total de couleurs utilisées et affichées à l'écran, vous devez le faire vous-même!

Faire bouger les objets

Pour afficher quelque chose à l'écran, vous devez copier les données graphiques de la ROM vers la RAM vidéo. Le GPU n'a pas d'accès direct aux données de la ROM, mais peut lire les données de la RAM. Par conséquent, pour que l'arrière-plan ou l'animation des sprites change, vous devez régulièrement copier de nouvelles données de la ROM vers la RAM. Et le nombre total de RAM vidéo (VRAM) est limité: seulement 64 Ko. Comparé à la taille des ROM de jeu (de 512 Ko à 8 Mo), c'est assez petit.

Goulot d'étranglement # 1: Transfert VRAM

Si vous créez un très petit jeu avec un petit nombre d'éléments graphiques, vous pouvez simplement les charger une fois pour toutes en mémoire au démarrage du jeu. Mais la plupart des jeux doivent actualiser régulièrement les graphiques dans VRAM pour montrer diverses animations. Et cela cause généralement beaucoup de problèmes!

La quantité de données graphiques pouvant être transférées de la ROM à la VRAM dans chaque trame (c'est-à-dire 60 fois par seconde) est limitée. Plus précisément, cela représente 7524 octets par trame, soit environ 7 Ko. Lorsque vous devez afficher d'énormes sprites animés ainsi que des arrière-plans animés, comme dans Street Fighter II, cette restriction interfère constamment. Et ce n'est que le premier problème.

Goulot d'étranglement # 2: restrictions des sprites

Pour les consoles 8/16 bits, une autre difficulté est le nombre total de sprites que l'équipement peut afficher. Il existe généralement deux restrictions: une pour le nombre total de sprites à l'écran, l'autre pour le nombre total de sprites sur une ligne horizontale. Pour les consoles 8 bits, telles que NES et Master System, ces restrictions sont très sévères: pas plus de 8 sprites par ligne horizontale, et le nombre total ne doit pas dépasser 64 sprites. Est-ce à dire que l'on peut afficher sur l'écran 64 fois Sonic ou Mario? Non, je veux dire "sprites matériels", qui sont plus petits que ce qu'on appelle habituellement un sprite. Voici un exemple de Super Mario Bros pour NES, où il faut plusieurs sprites matériels 8x8 pour afficher un seul sprite Mario.


(Source: https://nesdoug.com/2018/09/05/06-sprites/ )

Pour les consoles 16 bits, les restrictions de sprite sont légèrement réduites. Mega Drive / Genesis peut afficher jusqu'à 80 sprites matériels. Mais un sprite matériel séparé peut avoir une taille allant jusqu'à 32x32 (auparavant - seulement 8x8 pixels). Voici quelques exemples de découpe de "sprites matériels" sur Mega Drive / Genesis. Avez-vous remarqué que Sonic utilise seulement deux sprites matériels, tandis que Mario sur NES a besoin de 8 sprites?


(Source: https://www.patreon.com/posts/new-resource-and-26847248 )

Goulot d'étranglement # 3: priorités des sprites

Comme si cela n'était pas assez compliqué, Mega Drive / Genesis a une autre caractéristique spécifique: une chaîne de sprites. Lors de l'application de deux sprites, la console doit savoir laquelle doit être affichée au-dessus de l'autre. Dans le Master System et dans la plupart des consoles Nintendo (NES, Game Boy, SNES), les sprites étaient placés dans une grande table et leur ordre dans la table était utilisé pour définir la priorité d'affichage. Inutile de dire que c'est un outil assez difficile à utiliser, car vous devez constamment redéfinir cette grande table pour changer la priorité des sprites.

Chez Mega Drive / Genesis, SEGA a utilisé un système plus flexible et plus simple. Comme dans d'autres consoles, tous les sprites ont un numéro d'index dans une grande table, mais il n'est pas utilisé pour définir la priorité du sprite. Au lieu de cela, chaque image-objet stocke un lien vers l'image-objet suivante à afficher. En fin de compte, la console crée une chaîne de sprites, en commençant par le sprite 0. Chaque sprite ne sait que ce qui vient après. Cela rend beaucoup plus facile de changer les priorités des sprites sans organiser tous les sprites dans une grande "table des liens de sprites". Mais franchement, bien qu'un tel système soit plus facile à utiliser, il est toujours ennuyeux lors de la création d'un jeu avec une priorité de sprite souvent changeante, par exemple, en beat'em up.

Le plus simple: le moteur sprite SGDK

Afficher les sprites en mouvement et les arrière-plans défilants, en tenant compte de tous ces goulots d'étranglement, est tout un défi. Tous les développeurs des années 90 se sont battus avec lui, et de nombreux développeurs homebrews continuent de le faire. Par exemple, Matt Phillips a sorti le magnifique jeu Tanglewood en 2018, mais l'a créé à l'aide d'outils des années 90. Il a programmé le jeu en langage assembleur et utilisé le kit de développement matériel officiel, conçu il y a environ 30 ans. De son côté, c'était un choix délibéré, il voulait expérimenter pleinement la technique de développement d'un jeu vintage.


(Source: https://www.gamasutra.com/view/news/325040/New_game_classic_hardware_Developing_Tanglewood_on_a_Sega_devkit.php )

Mais pour les personnes moins expérimentées et patientes que Matt, les outils modernes peuvent réduire le nombre de problèmes créés par les limitations techniques du matériel. Nous avons déjà mentionné que C est généralement plus simple que l'assembleur. Il convient également d'ajouter que l'utilisation d'un émulateur Mega Drive / Genesis de haute précision comme Blast'em en combinaison avec le Everdrive Flash Cart pour les tests sur du matériel réel rend le développement du jeu presque indolore par rapport au développement utilisant d'anciens émulateurs matériels en combinaison avec un ensemble d'outils DOS. Mais encore une fois, le principal cadeau de notre temps est SGDK.


Enregistrez le jeu sur une carte SD, insérez-le dans Mega Everdrive et testez le jeu sur du vrai matériel!

Entre autres choses, SGDK possède également un puissant "Sprite Engine", facilitant grandement la vie du développeur. Il s'agit d'un ensemble de fonctions de traitement de l'affichage des sprites similaires à la façon dont cela se fait dans les frameworks modernes. Tout d'abord, vous n'avez plus à vous soucier du nombre de sprites matériels requis pour chaque image de l'animation: SGDK le fera automatiquement. De plus, lorsque vous travaillez avec des priorités de sprite, vous n'avez pas à définir manuellement la chaîne de sprites, car SGDK le fait avec la valeur simple "priorité de sprite", qui peut être définie pour chaque sprite, comme dans tout cadre moderne. Une dernière chose: SGDK traite également toutes les transmissions en VRAM automatiquement! Oui, vous avez bien compris, grâce au Sprite Engine vous n'avez plus du tout besoin de vous occuper de la VRAM! Vous pouvez simplement dire à SGDK d'afficher "l'animation du sprite X Y" et il fera tout le travail techniquement difficile pour vous. Si vous avez déjà dû travailler avec ces choses manuellement, cela semble magique - tout est simple et clair!

Le moteur Sprite du framework SGDK à lui seul fait de Mega Drive / Genesis la console rétro la plus simple pour le développement de jeux, surtout si vous avez de l'expérience avec des frameworks de jeux sur des plateformes modernes. SGDK est gratuit et open source, mais si vous voulez aider son auteur Stefan Dallongevil dans le développement de la magie rétro, vous pouvez le faire sur Patreon: https://www.patreon.com/SGDK/

Son

Le son sur du matériel rétro est également un véritable test en soi, et chaque console est unique à cet égard. Mega Drive / Genesis dispose d'un processeur Z80 distinct pour cette tâche, qui est directement connecté à l'équipement audio. Autrement dit, pour créer du son et de la musique pour la console, vous devez d'abord écrire un «pilote audio»: un programme pour le processeur Z80. Dans les années 90, chaque studio de jeu a développé son propre pilote audio et l'a ajusté pour chaque jeu. Vers la fin de la vie de la console, des pilotes standardisés sont apparus, par exemple, Sega of America’s GEMS, utilisé dans une centaine de jeux par des développeurs occidentaux.

Créer un bon son pour les consoles 8/16 bits est une question non seulement de compétences musicales, mais aussi de programmation! Certains jeux avec de la bonne musique ou des effets sonores ont été corrompus par un mauvais pilote audio. L'exemple le plus célèbre est Street Fighter II. Le pilote audio de ce jeu souffre de bugs qui déforment tous les échantillons de voix. De nombreuses années plus tard, Stefan Dallongewil (auteur SGDK et assistant reconnu) a procédé à la rétro-ingénierie de ce pilote audio et corrigé ses bogues. En conséquence, vous pouvez maintenant jouer à Street Fighter II avec le cri cristallin "Hadoken!". Voici une vidéo où vous pouvez entendre la différence:


Mais revenons au développement de l'homebrew et du SGDK bien-aimé. Il a la possibilité de sélectionner des pilotes audio qui peuvent être sélectionnés pour répondre aux exigences de son jeu. Par exemple, il existe un pilote PCM qui vous permet de jouer un effet sonore à la fois en très haute qualité (par exemple, des échantillons de voix) . Mais il existe également un pilote XGM qui peut lire simultanément une piste musicale + 4 effets sonores. Mieux encore, vous pouvez basculer entre les pilotes audio pendant le jeu. Par exemple, dans 30 ans de Nintendon, les échantillons de voix sur l'écran de démarrage et la fin du jeu sont joués par le pilote PCM pour une haute qualité. Mais pendant le jeu, je devais jouer plusieurs effets sonores en même temps, j'ai donc utilisé le pilote XGM.

Quant aux ressources elles-mêmes, des outils modernes peuvent être utilisés pour les créer. Comme je l'ai dit ci-dessus, pour les effets sonores, vous pouvez simplement prendre des fichiers .wav, qui sont automatiquement convertis au format souhaité. Pour la musique, l'outil standard est Deflemask - un tracker qui peut créer de la musique pour l'équipement sonore de diverses consoles 8/16 bits. Je n'ai pas beaucoup d'expérience dans la création musicale, car les compositions utilisées dans mes jeux ont été écrites par de talentueux artistes chiptune: Minerscale (Break An Egg) et Warlord (MeteoRain). Tous deux ont utilisé Deflemask et ont exporté leurs créations au format VGM, que SGDK peut convertir pour une utilisation avec leurs propres pilotes audio.

Créer un jeu pour Mega Drive / Genesis en 60 minutes? Appel accepté!

Les jams de jeu sont un excellent moyen d'appliquer vos compétences en conception de jeu et en développement de jeu: à quel point un jeu peut-il être créé à partir de zéro en un temps limité (généralement 48 ou 72 heures)?

En termes de temps, le jam le plus difficile est 0h Game Jam . Comme son nom l'indique, il a lieu chaque année pendant la transition vers l'heure d'hiver. Vous commencez à créer le jeu à 02h00, la nuit de l'horloge. Après avoir travaillé pendant 60 minutes, vous mettez le jeu en ligne au moment même où l'horloge revient de 03h00 à 02h00. L'année dernière, j'ai décidé de participer à ce jam. Après avoir terminé 30 ans de Nintendon't, j'ai acquis une certaine expérience dans la création d'un jeu pour Mega Drive / Genesis et j'ai été inspiré par la simplicité de SGDK. Mais SGDK peut-il être assez simple pour que je puisse créer un homebrew 16 bits en seulement 60 minutes? Voici la réponse :


60 minutes de travail

Soyons honnêtes, le résultat n'est absolument pas impressionnant. L'équilibre du jeu est terrible, et il y a un énorme bug dans le générateur de nombres aléatoires, c'est pourquoi le jeu devient infranchissable après le cinquième œuf. De plus, il n'y a pas d'image d'arrière-plan, de son, etc. Mais encore, c'est un nouveau jeu pour Mega Drive / Genesis, créé à partir de zéro en 60 minutes, et lancé sur une vraie console.Je ne sais pas comment pour toi, mais pour moi c’est déjà une sorte de réussite!

De plus, comme l'idée du gameplay de base avait un certain potentiel, j'ai continué à travailler sur le jeu pendant encore beaucoup d'heures. En conséquence, j'ai obtenu un jeu d'arcade assez intéressant que vous pouvez jouer ici . Il est également disponible sur la cartouche 30 Years of Nintendon't avec le troisième jeu, unique à cette version sur support physique - MeteoRain.


De nombreuses heures de travail supplémentaires!

De l'homebrew à l'indé

Bien que le homebrew soit généralement un créneau pour les amateurs (comme moi), certaines consoles sont encore une plate-forme commerciale pour les studios indépendants. Un bon exemple de cela est deux jeux récemment sortis. D'une part, Tanglewood a été entièrement développé en assembleur, comme dans les années 90, ce qui a rendu le résultat final encore plus impressionnant. D'autre part, le Xeno Crisis tout aussi impressionnant a été développé avec SGDK et a profité pleinement du confort et de la simplicité des outils modernes.


Tanglewood (2018)


Xeno Crisis (2019)

Donc, si vous aimez les jeux rétro, pourquoi ne pas créer votre premier jeu Mega Drive / Genesis aujourd'hui?

Au final, pour obtenir SGDK, il suffit de suivre le lien: https://github.com/Stephane-D/SGDK

En conclusion

J'espère que vous avez apprécié cet article sur la création de trois jeux pour SEGA Mega Drive / Genesis en utilisant la technologie moderne. Si vous voulez jouer à mes jeux sur votre propre console ou simplement soutenir mon travail, vous pouvez acheter une cartouche dans une belle boîte avec la sortie de mes jeux chez l'éditeur de Cote Gamers: http://cotegamers.com/shop/en/genesis-mega-drive/ 43-test.html

Si vous n'êtes intéressé que par une version numérique (c'est-à-dire des ROM), alors tous mes jeux rétro peuvent être trouvés ici: http://drludos.itch.io/

Si vous avez aimé mon travail et vous pouvez vous-même permettez- moi ensuite de me soutenir financièrement sur Patreon. Mes jeux sont généralement mis en ligne gratuitement, et certains d'entre eux sont également vendus sur des cartouches physiques. En me soutenant sur Patreon, vous aurez également accès aux versions bêta de mes jeux, ainsi qu'aux différents prototypes que je crée (y compris les projets abandonnés).