[devlog] Super Tilt Bro. - Page 1

Bonjour,

Depuis un peu plus d'un an, je développe un homebrew pour notre petite NES adorée. L'idée est d'y recréer un jeu de combat très inspiré par Super Smash Bros, à ceci prêt qu'il est jouable avec moins de boutons, plus rétro, libre et codé en assembleur. Je vous présente donc Super Tilt Bro. !



Vous pouvez télécharger la dernière ROM sortie ou y jouer dans un navigateur. Bien entendu, pour avoir le dernier patch avant tout le monde, vous pouvez récupérer les sources.

Maintenant que les présentations sont faites, voilà ce qui m'amène parmi vous : parlons technique. L'idée est de faire de ce topic un devlog qui sera mis à jour quand un problème intéressant fera surface. Le problème sera expliqué, analysé et résolu. Dans ce premier post, nous allons commencer par une double entrée, ainsi vous pourrez vous faire une opinion. Si le format ne vous plaît pas, nous pourrons l'adapter.

Les plate-formes mouvantes, c'est comme le sol mais ça bouge.


Grand classique du jeu vidéo, pierre angulaire de bien des gameplays et vedettes dans nombreuses œuvres, on ne présente plus les plateformes mouvantes. Voilà pourquoi Super Tilt Bro se dote aujourd'hui de ses premières plateformes mouvantes.

Dans Super Tilt Bro, un niveau est défini principalement par une image de fond d'écran, une liste de plateformes et une fonction d'initialisation. Au démarrage d'une partie, la fonction d'initialisation est appelée par le moteur, elle dessine le fond d'écran puis copie la liste de plateformes à un emplacement réservé en mémoire. Pendant la partie, le moteur de jeu utilise la liste de plateformes en mémoire pour gérer les collisions tout en dessinant les personnages avec des sprites au-dessus du fond d'écran.

Tout est presque en place pour implémenter les plateformes mouvantes : quand une plateforme bouge, il suffit de modifier sa position dans la liste en mémoire. Le moteur n'y verra que du feu. Il va juste falloir trouver un endroit où mettre le code qui déplace les plateformes ainsi qu'un moyen de les afficher.

Les plateformes mouvantes sont propres au niveau auquel elles appartiennent. On ne pourra donc décemment pas mettre ce code dans le moteur de jeu. La fonction d'initialisation nous montre la voie, il suffit d'ajouter aux niveaux une fonction qui est appelée avant chaque frame. Pour les niveaux existants, on utilise simplement une fonction qui ne fait rien, pour le nouveau, on peut y gérer le déplacement des plateformes. C'est simple et ça permet aux futurs niveaux n'importe quelle fantaisie, ce n'est pas limité au déplacement de plateformes.

Pour l'affichage, rien de plus simple. On aura besoin de déplacer régulièrement nos plateformes et de les positionner au pixel prêt, l'utilisation de sprites s'impose donc. Modifier le fond d'écran est plutôt coûteux en ressources, mais surtout on y place les éléments sur une grille, donc pas au pixel prêt. Une plateforme mouvante, dans ce niveau, fait 32 pixels de large, la NES affichant des sprites de 8x8 nous aurons besoin de 8 sprites pour nos deux plateformes... C'est là que le bât blesse !

Des particules bien trop gourmandes.


La NES permet d'afficher 64 sprites simultanément, pour éviter tout conflit, Super Tilt Bro réserve chaque sprite à un usage particulier, voici l'affectation des sprites :

 0-15: sprites du joueur 1
16-31: sprites du joueur 2
32-35: non-utilisé
36-42: bloc de particules 0
43-49: bloc de particules 1
50-56: bloc de particules 2
57-63: bloc de particules 3

Ça laisse 4 sprites libres, à peine de quoi afficher une pauvre plateforme. On remarquera que prêt de la moitié des sprites sont utilisés pour les blocs de particules, quoi que ça puisse être... Et si on taillait dans le vif ?

Super Tilt Bro dispose d'un système de particules plutôt basique. Quand on veut émettre des particules, on crée une fontaine à particules. Chaque fontaine est associée à un bloc. Le jeu utilise ce système pour deux choses : l'indicateur d'impact et les explosions quand un personnage meurt.

Étant donné qu'il y a 2 personnages chacun ayant 2 effets de particules, avoir 4 blocs est pratique, les fontaines on chacune leur bloc. Ceci dit, il est particulièrement rare qu'un personnage émette à la fois un indicateur d'impact et des explosions, on peut donc libérer 14 sprites en ne réservant qu'un bloc par personnage. La dernière fontaine crée prenant le contrôle du bloc. Voilà donc la nouvelle affectation des sprites :

 0-15: sprites du joueur 1
16-31: sprites du joueur 2
32-49: utilisables par le niveau
50-56: bloc de particules 0 (joueur 1)
57-63: bloc de particules 1 (joueur 2)

Et voilà ! On a maintenant des plateformes mouvantes, mais aussi un système générique pour rendre les niveaux dynamiques et assez de sprites libres pour faire joujou.

Merci d'avoir lu jusqu'ici, n'hésitez pas à me faire des retours, positifs comme négatifs, que ce soit sur le devlog ou le jeu.

Le jeu a l'air bien sympathique . J'ai essayé de comprendre ton explication avec les sprites. Je pense avoir compris une partie . Il est vrai que 64 sprites cela peut faire beaucoup plus 1983, mais cela reste assez peu au final. Vive la Snes et c'est 128 sprites .

Salut RogerBidon !

Super le devlog. Je vais suivre tout ça de près, c'est très intéressant

Super projet et cool pour le partage de ton travail !

Question bête de gamer, un smash bros like à 4 sur NES, c'est chaud ?

Loup77, la Snes c'est une bombe, tous ces sprites qui s'affichent sans conditions, ça permet de faire des trucs trop cool comme les gros persos de street fighter. Après, sur la NES il y a moyen de tricher, au lieu de 64 sprites 8x8, on peut avoir 64 sprites 8x16, soit presque 128 sprites Il faut juste designer le jeu avec ça en tête (ça ajoute d'autres contraintes), ou en avoir salement besoin et être prêt à refaire plein de choses.

Merci Fei, c'est grâce à toi si je suis là

odie_one, c'est la question la plus commune, je crois que je vais être obligé de m'y coller un jour. Pour le côté difficile, comme toujours, si ça avait été pensé en amont ça aurait été plus simple. Voilà grosso-modo ce qu'il y aurait à faire dans Super Tilt Bro. : réserver tous les sprites pour les persos (plus de particules, plus de plateformes mouvantes), réaffecter les palettes de couleurs (elles sont toutes utilisées pour les deux persos), ajouter un clignotement intelligent des sprites, acheter un four-score pour développer avec, optimiser le moteur d'animations (bien trop gourmand en cycles CPU) et adapter les menus pour avoir un mode 4 joueurs. Bref, ça ne se fait pas dans la nuit mais ça présente des défis intéressants (optimiser le moteur d'animation c'est trop fun !)

Chouette!

J'ai déjà travaillé sur un moteur de collision avec le background, j'imagine que l'adaptation pour interagir également avec des sprites doit aussi demander un pas mal d’adaptations, le genre à provoquer des bugs bien fun avant d'arriver à un résultat probant.
Par contre tu as réellement besoin de 16 sprites par perso? Dis moi si je me trompes mais tes persos font bien 8x16 et les armes doivent demander 16x16 pour avoir le max des mouvements? J'imagine aussi que la plateforme d’apparition est gérée par tes sprites "persos" mais je me demandes si tu ne peu pas réduire cette plage, à moins que tu ai d'autres idées en tête...

Btw, vivement la suite!

Quand tu parles de détection de collisions avec le background, tu te basais directement sur les nametables ? Dans Super Tilt Bro, le terrain est limité à des plateformes, on vérifie donc les collisions contre la liste des plateformes. Ça permet de dessiner la nametable indépendamment et surtout de la compresser. Pareil, pas de collision directement entre sprites, mais simplement des hitboxes.

L'animation la plus gourmande utilise 11 sprites au maximum. C'est le up-air (haut+A après un saut), il y a le perso penché qui prend quatre sprites, le cimeterre qui en fait deux et une étoile en utilise cinq. La majorité des autres animations n'utilisent pas plus de six sprites. Après, la limite à 16 sert à laisser de la place au cas où, mais pourra être réduite... limitant d'autant la liberté si on veut refaire les graphismes.

Je ne me rendais pas compte que les animations formaient un si gros sujet. Je vais préparer une entrée de devlog pour décrire le système actuel plus en détails.

Pour arriver à faire un Super Tilt Bro. jouable à quatre, il va falloir retoucher le moteur d'animations. Dit comme ça, c'est abstrait. Voyons comment fonctionne le moteur actuel, ses forces et ses faiblesses. Nous verrons mieux ce qui devra et pourra être fait. Et puis ça parle de sprites, on adore les sprites.


Les notions de joueur et de personnage sont souvent utilisées de façon interchangeables. Quand on parle du développement de Super Tilt Bro. il est pratique d'utiliser des termes clairs, ce que je commence à faire avec cette entrée du devlog. Donc :

• Un personnage est un être imaginaire avec toute sa mythologie. En contexte : Le personnage jouable est Sinbad, l'ogre mascotte du projet Ogre3D.
• Un joueur est la personne appuyant sur les boutons de la manette. En contexte : Après une partie, le joueur vainqueur se rit de son adversaire.
• Un avatar est l'entité du jeu qui peut être contrôlée. En contexte : L'avatar est défini par des variables et affiché grâce à des sprites.
  

Note : ces définitions n'ont rien d'absolu. C'est un glossaire propre à Super Tilt Bro.


Chaque frame, le moteur de jeu fait deux choses particulièrement importantes : il calcule l'état des avatars en fonction des boutons pressés, puis il réarrange les sprites pour refléter cet état.


Une fois la première étape effectuée, pour chaque avatar, on connait sa position, son animation et depuis combien de temps il utilise cette animation. Il n'y a plus qu'à trouver la frame d'animation correspondante, elle indique quels sprites doivent être affichés et où. Voilà à quoi ressemble une animation dans le code :

; Frame 1
ANIM_FRAME_BEGIN(3)
ANIM_HURTBOX($f8, $07, $0a, $0f) ; left, right, top, bottom
ANIM_SPRITE($08, TILE_CHRASHING_SINBAD_1_SIDE, $01, $f0) ; Y, tile, attr, X
ANIM_SPRITE($08, TILE_CHRASHING_SINBAD_1_HEAD, $00, $f8)
ANIM_SPRITE($08, TILE_CHRASHING_SINBAD_1_BODY, $00, $00)
ANIM_SPRITE($08, TILE_CHRASHING_SINBAD_1_SIDE, $41, $08)
ANIM_FRAME_END

; Frame 2
ANIM_FRAME_BEGIN(3)
ANIM_HURTBOX($f8, $07, $06, $0d)
ANIM_SPRITE_FOREGROUND($08, TILE_CHRASHING_SINBAD_2_SIDE, $01, $f3) ; Y, tile, attr, X
ANIM_SPRITE_FOREGROUND($08, TILE_CHRASHING_SINBAD_2_MIDDLE, $01, $fc)
ANIM_SPRITE_FOREGROUND($08, TILE_CHRASHING_SINBAD_2_SIDE, $41, $05)
ANIM_SPRITE($06, TILE_CRASHED_SINBAD_HEAD, $00, $f8)
ANIM_SPRITE($06, TILE_CRASHED_SINBAD_BODY, $00, $00)
ANIM_FRAME_END

; Frame 3
ANIM_FRAME_BEGIN(13)
ANIM_HURTBOX($f8, $07, $08, $0f)
ANIM_SPRITE($08, TILE_CRASHED_SINBAD_HEAD, $00, $f8) ; Y, tile, attr, X
ANIM_SPRITE($08, TILE_CRASHED_SINBAD_BODY, $00, $00)
ANIM_FRAME_END

; End of animation
ANIM_ANIMATION_END

On peut y voir que les hitboxes et hurtbox des avatars sont placés avec l'animation. Il y a aussi la différence entre sprites normaux et d'avant plan, permettant aux effets spéciaux de toujours s'afficher devant l'avatar. En effet, dans Super Tilt Bro, quand on retourne un avatar on change la priorité des sprites, ce qui en fait techniquement un modèle 3D bien pratique pour que le personnage reste gaucher. Les petits effets de choc, quant à eux doivent rester devant.




Le format d'animations n'impose pas de limite particulière, le placement des sprites est libre et on a également une notion de profondeur.

Le positionnement des hitboxes avec l'animation permet d'assurer facilement leur cohérence. On est à l'abri des bugs de hitboxes qui se détachent sans raison apparente et on ne risque pas d'oublier de les modifier quand on retouche une animation.


Le moteur d'animation est intimement lié à l'état de la partie, il s'appuie directement sur les variables des avatars. Ça le rend inutilisable pour un autre projet, ou même dans les menus. Il serait judicieux qu'un sprite animé ai son propre état, le moteur de jeu n'aurai qu'à maintenir cet état et laisser faire le moteur d'animations.

L'animation est super gourmande en CPU. À chaque frame de jeu, le moteur d'animation doit retrouver la frame d'animation correspondante... Impliquant de parcourir toutes les frames d'animation précédentes. Ça pourrait être réglé simplement en stockant la frame d'animation courante dans l'état du sprite animé, mais cet état n'existe pas (cf. paragraphe précédent).

Aucune gestion du clignotement des sprites n'existe. C'est de la responsabilité du dessinateur de ne pas être trop gourmand pour éviter que ça arrive. Si ça arrivai quand même l'avatar du joueur deux disparaîtrait. On pourrait l'implémenter simplement en interchangeant les sprites réservés a chaque avatar entre les frames de jeu.

La gestion de la 3D implique de connaitre le nombre de sprites maximum de l'animation. C'est une des raisons pour lesquelles un grand nombre de sprites est réservé aux avatars.


Pour rendre possible le jeu à quatre, les principaux ennemis à abattre seront la lenteur et le clignotement. Sans qu'il n'y ait rien d'impossible, résoudre les problèmes de lenteur demande de repenser certaines choses en profondeur. Ceci dit ces modifications n'apporteront que du bon, également pour d'autres sujets que le jeu à quatre.

Merci d'avoir lu, vous êtes des acharnés ! J'ai tenté d'améliorer le format avec plus d'illustrations. J'aurai aimé faire plus court aussi, mais les animations c'est un gros sujet, on est loin d'avoir tout dit. N'hésitez pas, faites vos remarques.

Le NTSC pour les nuls

Super Tilt Bro. est pensé pour et testé sur les consoles PAL qui affichent 50 images par secondes. Bilan, tout est accéléré quand on le fait tourner sur un système NTSC qui affiche 60 images à la seconde. Je me suis toujours dit, qu'un jour il faudrait faire une version NTSC, en adaptant les vitesses des avatars et quelques autres constantes. Je le pense toujours. Ceci dit, c'est injouable et une solution plus rapide m'a frappé en lisant le code source du Game&Watch de Bjorn :

//wait virtual frame, it is always 50hz, frame-to-frame in PAL, frameskip in NTSC void __fastcall__ ppu_wait_frame(void);
Wow ! Mais c'est du génie ! À 60 images par secondes, si on ne fait rien durant une image sur six, on se retrouve à 50 images secondes. Pour le prix d'une image ratée sur six, on absorbe le gros des différences PAL vs NTSC. Ça suffit à rendre Super Tilt Bro. tout à fait jouable. Bien entendu, ce n'est pas la solution idéale, sauter des frames dans un jeu de combat, ça ne se fait pas. Certaines techniques ne sont possibles que sur de très courtes périodes, on peut par exemple se rattraper d'une mauvaise chute en réagissant dans les 5 frames qui précèdent le crash. Une saccade d'une frame peut-avoir un gros impact. Bref, ça sera très bien en attendant de pouvoir faire une vraie version NTSC en adaptant tout plein de valeurs qu'il faudrait équilibrer en PAL avant de les porter en NTSC.

Arf c'est cool que tu ai trouvé de quoi régler ton problème, mais la neslib n'est pas de moi mais de Shiru! ^^
D'ailleurs de mémoire il y a un de ces tutos (ou alors c'en est un de NesDoug) qui permet de détecter la fréquence de la machine. C'est en C mais ça peux t'être utile?

Merci pour les précisions sur les sprites, et un gros bravo pour ton devlog en général. J'ai forcément un bagage sur la machine ayant déjà bidouillé dessus en C, mais je trouves que tu t'en tire comme un chef pour vulgariser le sujet.

Toujours aussi intéressant !
En effet, je plussoie, les explications sont très claires (même pour les non initiés au code).
Surtout avec les gifs en complément, merci.

Merci pour les encouragements, ça fait super plaisir !

Pour ce qui est de la détection de PAL ou NTSC, entre le CPU qui n'est pas exactement à la même fréquence et le nombre d'images par seconde qui diffère, il y a forcément une différence en nombre de cycles CPU par frames. Il suffit donc de passer une frame à compter les cycles pour savoir sur quel système on est. Et comme le hasard fait bien les choses, au démarrage on doit attendre une frame pour que le PPU se mette dans un état stable, j'en profite pour compter les cycles que ça prend.

Ce que j'ai vu de la neslib, Shiru utilise une variante. Au tout début d'une frame, il gaspille un nombre de cycles CPU déterminé, puis vérifie si une frame est passée (et qu'on est dans le v-blank). C'est le même principe, mais à l'envers Tepples fait à peu pres comme moi, mais il se base sur la gestion des NMI, ce qui lui permet d'avoir une fonction qu'il peut relancer pendant l'exécution et pas seulement au démarrage. Sinon je n'ai pas trouvé d'exemple en C, je serais curieux de voir à quelle variante ça ressemble le plus.

Oui, merci pour le temps pour expliquer tout cela avec des images

L'arrière-plan mis en avant, père du parallax

La NES propose deux méthodes d'affichage simultanées : l'arrière-plan et les sprites. L'arrière-plan prend tout l'écran alors que les sprites sont de petites images que l'on peut placer sur l'écran au pixel prêt. Généralement, on utilise l'arrière-plan pour dessiner une scène (comme une forêt) et les sprites pour dessiner l'action (comme des mages combattant des orques). Jusque-là rien de bien spécial, tout joueur est au courant et on continue même à travailler comme ça dans les jeux modernes.


Une petite particularité de la NES est de proposer une couleur transparente, commune à toutes les palettes, pour l'arrière-plan. Dans Super Tilt Bro on utilise la couleur du ciel comme couleur transparente. On peut aussi préciser, pour chaque sprite, s'il doit être affiché devant ou derrière l'arrière-plan. Un sprite affiché derrière l'arrière-plan ne sera donc visible que là où ce dernier est transparent. C'est parfois pratique, comme pour avoir des ballons qui sortent de derrière le podium après un match.


Et si on inversait les rôles ? Utiliser les sprites pour dessiner une scène, là où on se sert de l'arrière-plan pour l'action. Typiquement, on a besoin de tout l'écran pour un menu, laissant peu de place pour la scène. Ça colle !


Notez que, comme la position des sprites n'est pas liée au scrolling, on peut en profiter pour créer un petit effet de parallax. Comme quoi on peut se passer de la SNES et de ses quatre arrière-plans tout en restant cool

La transition écran titre / menu est top !

Oui, très bon effet ce menu !

Merci encore pour les gentils commentaires. C'est toujours aussi agréable à recevoir
Aujourd'hui, je poste une entrée un poil hors série (et sans image), on ne parlera pas directement de Super Tilt Bro, mais de comment s'en servir pour préparer le speed-coding de la semaine prochaine.

AC 2018 et nine-gine, l'épreuve du feu

Ma première AC ! Je ne pouvais pas manquer ça, on y promet d'imposer la création d'un jeu en deux jours, tout en jouant pendant qu'on bosse. Le code, version sport extrême en somme.
Ça me plait, mais je n'y suis pas préparé, j'ai donc cherché divers moyens d'accélérer mon développement sur la NES.

J'ai eu plusieurs idées, comme apprendre à utiliser cc65 pour coder en C plutôt qu'en assembleur, faire un backend clang pour coder en C++ avec optimisations ou encore développer un bytecode haut niveau avec son langage de script. Certaines de ces idées ne m'intéressent pas, d'autres demandent trop de travail, mais il existe une idée particulièrement cool : extraire un moteur de jeu de la base de code de Super Tilt Bro.

C'est ainsi qu'est né le nine-gine (ou 9gine, ou Nintendo-engine). Qui propose les features suivantes :

• Structuration du projet : on ne se pose pas de question de nom de fichier, on écrit juste du code
• Boucle principale (y compris NMI) : on écrit le code spécifique au jeu, pas à la NES
• Absorption des différences PAL/NTSC (et même Dendy)
• Moteur d'animations avec profondeur
• Moteur de musique
• Gestion des inputs
• Diverses fonctions utilitaires
  

Ça fait un bon tas de choses qui ne seront pas à re-coder le jour J. On verra bien si ça suffit à produire quelque chose dans les temps, si c'est le cas la prochaine étape sera de documenter et publier ce moteur

Au plaisir de vous revoir ou de vous rencontrer dans quelques jours o/

AC rulez

Bon courage pour la speed-coding

Voici pour les curieux le règlement de cette année

RogerBidon (./17) :
Ça me plait, mais je n'y suis pas préparé

Bah voilà, exactement comme tlm

Ça va être une très bonne AC ça encore \o/

vince > L'expérience et les habitudes à l'AC. Le fait que vous avez vos marques et savez parfaitement comment ça va se dérouler. Ça joue quand même, par rapport à quelqu'un qui débarque à Congis-sur-Thérouanne pour la première fois ^^

Fei (./20) :
Ça va être une très bonne AC ça encore \o/

vince > L'expérience et les habitudes à l'AC. Le fait que vous avez vos marques et savez parfaitement comment ça va se dérouler. Ça joue quand même, par rapport à quelqu'un qui débarque à Congis-sur-Thérouanne pour la première fois ^^

Certes, mais arriver sans rien avoir préparé c'est pas un pb, c'est souvent que y'en a qui ne se décident à participer que le samedi matin...

Oui oui bien sûr.
Mais je comprends que pour une première c'est compliqué de se dire "je vais participer à ma première speed-coding, je peux venir les mains dans les poches".

Tu verras RogerBidon, ça reste à la cool quand même

Je ne stresse pas, j'astique mon arme !

Et prépares toi mentalement : les développeurs c'est au fond à gauche, on risque d'être voisins

Dommage, nous n'étions pas voisins, ça a été un plaisir de te rencontrer.

Bref, voici l'heure du :

Post mortem, speed-coding à l'AC2018

C'était une expérience toute particulière. Nous étions deux, nous devions produire un jeu en moins de deux jours, utilisant une techno qu'on maîtrise moyennement, avec plein de gens sympas à rencontrer en même temps. On a adoré ! On en est ressortis grandis et fatigués

Le résultat est là : Les vacances d'Ulysse. Nous avons réussi à y caser tout notre scope, mais le jeu est clairement en dessous de nos attentes. Étant très juste sur les délais, nous n'avons pas eu le temps de trouver le "petit quelque chose" qui rendrait les combats intéressants. Pour rappel, les trois contraintes étaient "Un jeu de labyrinthe", "Sur le thème de l'odyssée" et "Avec un boss".

Ce qui a fonctionné :

On s'est éclatés :

Et c'est ça qui compte ! Le reste c'est du blabla pour remplir.

On a reussi à remplir notre scope :

Nous sommes partis sur un projet ambitieux. Deux modes de jeu distincts, ce qui équivaut à faire deux petits jeux. Différents ennemis, avec ce que ça impose en dessin. On est capable d'abattre du boulot mine de rien

Nine-gine est fonctionnel :

Avoir une base technique pour construire notre a été d'une grande aide. Mieux, même si le moteur était vieux de moins d'une semaine, il n'a posé aucun problème. Nous n'avons même pas eu à le patcher.

Donc, comme promis : Voici Nine-gine, open-source et documenté ! En espérant qu'il serve à quelqu'un. Personnellement je m'en resservirai et le ferait évoluer.

On a soumis le projet avec le plus de poils :

Si seulement il y avait un critère "poils" pour la notation...

Ce qui a raté :

Les combats sont chiants à mourir :

Les combats sont au centre du jeu. C'est censé l'élément fun, le moment action qui intéresse ceux qui n'aiment pas les labyrinthes. Mais sans aucun polish, ça devient le moment qui nous sort du labyrinthe pour nous ennuyer.

On manque d'habitude et d'outils :

C'est là qu'on apprend. Clairement nos process n'étaient pas au point, je passai un temps fou à intégrer les graphismes de Magou. Ça a mis une pression énorme sur le temps.

La prochaine fois nous partirons avec de meilleurs scripts, pour taper moins d'hexadécimal à la main, mais utiliser plus de résultats pré-mâchés. Quitte à louper des optimisations, l'important c'est d'itérer rapidement.

J'étais le seul à avoir le jeu entre les mains :

Même Magou qui bossait sur le jeu, l'a effectivement découvert à peine avant le jury. Bilan, l'effet tête dans le guidon était total.

Excellent compte rendu !

C'est vrai que vous étiez un peu loins des deux groupes de codeurs (le coin où j'étais ou celui où bj0rn était) mais j'ai été impressionné de vous voir le nez dans le guidon justement, et ce dès le début de l'AC !

Super le compte rendu
Merci !

C’était chouette de vous avoir avec nous pour cette AC.
J’espère à bientôt à la RGC 2018 et à l’AC 2019

Bravo pour votre jeu.
Moi je dis qu’avec juste une variation dans la vitesse de déplacement des ennemis et on était bon

Merci Fei pour le pointeur, du coup j'ai essayé de varier la vitesse des ennemis. C'est pas mal et ça s'est fait en 10 minutes (ça aurait pu être envisagé sur place), mais plus l'ennemi est rapide, plus c'est facile.

Du coup, il faut aussi accélérer les boules de feu pour un double effet : le monstre à moins de chance se se prendre la boule du joueur et le rythme de jeu est accéléré. Sans en faire un bon jeu, ça le rend beaucoup plus jouable. Seul problème, la gestion des boules de feu à été faite en speed, du coup il faut composer avec des bugs et limitations étranges quand on veut les accélérer. Ça m'a prit une petite heure de rendre leur vitesse configurable (avec une constante), bilan ça n'aurai pas tenu dans le temps imparti pour la speed-coding.

Voilà la ROM résultante de ces deux modifications : http://blabla.wontfix.it/ulysse_speedy(E).nes

Merci

Stage 4, un petit bout de code devient grand (Partie 1)

On approche doucement du scope fixé pour en finir avec la beta. Tout de même, Super Tilt Bro v1.0, ça enverrait ! Il reste quelques petites choses à faire : améliorer quelques animations, rééquilibrer quelques mécaniques et faire une quatrième arène... Sans spoiler, cette dernière arène va s'avérer être un mini projet à part entière, les congés du mois de mai ne seront pas du luxe.

L'idée de départ est simple. Il existe une arène avec des plateformes mouvantes, mais cette arène est volontairement difficile, il s'agit de réussir à rester en équilibre au-dessus du vide. Du coup, les joueurs occasionnels l'évitent, se privant de plateformes mouvantes. Faisons une arène plus simple avec des plateformes mouvantes. Ce sera juste un nouvel arrangement de plateformes, réutilisant du code existant, tout se passera bien.

Quelques minutes passées sur Super Smash Bros sont suffisantes pour trouver un arrangement sympa à jouer. Il s'agit de l'arène Mute City de Super Smash Bros 4. Il dispose d'une plateforme principale plus petite que d'habitude et de deux plateformes mouvantes qui ajoutent de la largeur à l'arène. Il n'y a plus qu'à tenter de reproduire cette idée dans Super Tilt Bro. En plus, ça va aller vite, je dispose d'un merveilleux script qui prend du JSON en entrée et écrit l'assembleur tout seul.


Le format JSON des arènes de Super Tilt Bro est simple, mais l'écrire à la main reste désagréable. (C'est là que tout commence à barrer en c*uilles.) C'est l'occasion idéale pour améliorer mes outils. Tiled étant la référence open source, aucune question à se poser, la première étape est de définir comment organiser les informations. Après quelques tâtonnements, l'organisation suivante est arrêtée:

Les emplacements spéciaux (comme les points de spawn) sont placés dans un calque d'objets nommé "spots". Les plateformes sont placées dans un calque d'objets nommé "platforms" et peuvent être de type "hard" (on ne peut pas passer au travers) ou "smooth" (on peut passer au travers). Les éléments esthétiques sont des images alignées sur la grille. Enfin, tout calque inconnu est ignoré, ce qui est pratique pour dessiner le résultat final même si le moteur n'en a pas besoin.


Comme Tiled permet d'exporter ses cartes en JSON (et que j'adore le JSON), il y a juste à faire un nouveau script pour convertir les fichiers exportés par Tiled en fichier d'arène pour Super Tilt Bro. Le processus est donc: Dessiner la carte dans Tiled, lancer plein de scripts et pouf on obtient une ROM.


C'est magique, c'est facile, ça va super vite... Et ça m'a pris la journée de coder tous ces outils.

Il n'y a plus qu'à ajouter les plateformes mouvantes, avec du code déjà prêt. Ça va être vite-fait... Non ?