Posté le 24/11/2019 17:47
!
Ici j'ai ajouté le fond des niveaux, la texture de la roche, et la possibilité de mettre en pause le jeu (mais ça vous ne le voyez pas 
)
Ajout des compteurs(pièces, score, vies, temps) fonctionnels.
Ajout des goombas, cadeaux et des briques fonctionnelles.
Image du 15/02/2020 (J'utilise l'émulateur, c'est plus propre maintenant non ? )
scrolling de la caméra plus fluide, ajout des plateformes a mouvement horizontal correction du bug du "wall jump" découvert par Kikoodx (le grand mario pouvait grimper les murs) Voici les différentes versions disponibles versions fixées (la dernière de préférence) version temps réel (repo git), mais cette version peut être instable
Planète Casio v4.3 © créé par Neuronix et Muelsaco 2004 - 2024 | Il y a 131 connectés | Nous contacter | Qui sommes-nous ? | Licences et remerciements
Planète Casio est un site communautaire non affilié à Casio. Toute reproduction de Planète Casio, même partielle, est interdite.
Les programmes et autres publications présentes sur Planète Casio restent la propriété de leurs auteurs et peuvent être soumis à des licences ou copyrights.
CASIO est une marque déposée par CASIO Computer Co., Ltd
Citer : Posté le 28/01/2020 18:26 | #
Nayce ! Les koopas rouges, hmm ?
Citer : Posté le 28/01/2020 18:59 | #
Elles seront pas rouges, effectivement
Ajouté le 31/01/2020 à 12:24 :
J'ai publié la version définitive des instructions pour le WE de test :
Il n'y aura que deux niveaux à tester, mais ils seront d'ores et déjà accessibles dans le mode course. Les scores, temps et nombre de pièces respectifs sont mémorisés, mais seulement pendant le temps d’exécution de l'addin.
Toutes les suggestions sur l'intuitivité, la jouabilité -et les reports de bugs- sont bienvenues
Deux bugs existants (mais heureusement mineurs) sont connus :
Ces deux bugs ont des origines encore inconnues, donc si jamais quelqu'un arrive à le relier à un évènement particulier, les suggestions sont bienvenues
Pour les informations liées à l'évènement, voir ici
Ceci marque la sortie de la version 0.3
Citer : Posté le 01/02/2020 20:53 | #
J'ai testé la version sur la branche master, et je me suis bien amusée, et l'experience etait sympa pour l'instant ya pas grand chose à tester, mais c'est plutôt encourageant
Pour faire remonter deux trois bugs et problémes avec le moteur physique:
- Quand on utilise une fleur de feu alors que l'on est en petite taille, l'on ne devient pas grand et est donc petit tout en pouvant cracher du feu, de plus l'on garde cette capacité quand on meurt et recommence le niveau
- La vitesse de sprint égale à celle des boules de feux
- en sautant au bon moment, on peut se coincer entre la plateforme mouvente et le mur et dans ce cas l'on se retrouve deplacé petit à petit au dessus d'elle, ou alors elle se teleporte de l'autre coté du personnage
Voila~
Citer : Posté le 01/02/2020 22:04 | #
J'ai modifié les instructions dans le topic de l'événement, je testerai ça aussi ! Merci Milang !
Citer : Posté le 02/02/2020 15:20 | #
Merci @Hackcell pour ton retour
Pour le bug où mario peut lancer des boules de feu en étant petit, je l'ai ajouté à ma liste, je pense que je vais faire en sorte que la fleur de feu se transforme en champignon si mario devient petit entretemps
Pour le rapport sprint-boule de feu, je ne vois pas le problème
Enfin, pour le cas où mario se retrouve petit à petit déplacé au dessus d'elle, c'est un comportement volontaire du moteur physique à fin de faire en sorte que mario ne reste pas coincé si à cause d'un problème technique il est par exemple à moitié sur l'emplacement d'un bloc
Sinon, voici un point sur l'avancement du programme :
Je pense que vous avez du remarquer le poids du jeu (actuellement environ 75-80 Ko) C'est beaucoup trop je pense pour un jeu avec seulement 2 niveaux
Actuellement, un niveau est créé de la façon suivante :
1. On dessine le niveau dans un *.png avec un code couleur spécifique
2. On le convertit en code source que l'on copie dans le code du jeu (me jugez pas svp
3. Durant l'éxécution, le niveau est littéralement copié en ram par le programme
Il y a donc de gros problèmes de taille de niveau, car dans l'addin se retrouvent en dur toutes les informations de config des blocs, qui ne servent qu'en live
J'ai donc choisi d'écrire directement l'algorithme de décodage de niveau dans l'addin, et d'utiliser une version compressée lors du build (relativement proche du *.png). Avec cette méthode, le niveau ne pèse que 3 Ko, tandis que l'algorithme de décompression n'est vraiment pas lourd en soi.
J'espère donc avoir un jeu beaucoup plus léger en sortie avec cette méthode que je suis en train de coder
Citer : Posté le 02/02/2020 15:23 | #
Pourquoi est-ce que ces données sont là ? Quelle est la quantité de données vraiment nécessaire au jeu pour utiliser le niveau ?
Citer : Posté le 02/02/2020 15:43 | #
En fait, chaque cellule de la map contient différentes informations :
Son type, sa tile, et selon le type, différentes informations comme les contenus cachés, l'heure de la dernière collision, si elle est invisible ou non etc... Stocker une map prend environ 12 Ko car chaque cellule est codée sur 32 bits. Ces données sont nécéssaires pour l'execution car toutes les informations sont accessibles, et les tiles à utiliser sont deja déterminées.
Mais en soit, la majorité des informations peuvent être écrites par le programme si je lui envoie une version avec seulement un numéro indiquant l'élément de base, ce qui tient dans un char :
Par exemple, la tile à utiliser d'un tuyau est déterminée par si il y a ou non un tuyau à gauche, à droite etc, mais ce serait vite lourd à éxécuter si je devais le déterminer à chaque frame alors que cela reste constant tout le long de la partie.
Avant, ce type de calcul était fait à la main ou par le script python avant la compilation, mais maintenant, l'intêret est de le faire faire directement par l'addin
Il faut donc bien 12Ko pour pouvoir utiliser le niveau, mais par contre, pour le générer, on peut le faire à partir d'une version de "seulement" 3Ko.
Citer : Posté le 02/02/2020 15:48 | #
Ah d'accord, c'est plus clair ! Ça me paraissait être le bon genre de piste à explorer avant de passer à l'option compression générique.
Citer : Posté le 02/02/2020 16:31 | #
Je précise au passage que pour le week-end de test, même si le jeu est parfaitement compatible avec l'émulateur, l'expérience est très très en dessous de celle sur calculatrice en termes de fluidité. (Je n'ai plus de piles, et je constate que c'est flagrant
Le choix des 20 fps pour économiser l'énergie et limiter l'effet de la rémanence rend le jeu tout simplement injouable sur émulateur, j'en ai les yeux qui saignent
Ajouté le 02/02/2020 à 17:58 :
Du nouveau sur master !
Le système d'optimisation est en place ! Le jeu fait maintenant 60 812 octets, et ce avec les mêmes fonctionnalités. Il y a donc eu un gain de 17 Ko
J'en ai profité pour rajouter les ennemis manquants dans le niveau 1
Ajouté le 04/02/2020 à 21:24 :
J'ai corrigé le bug concernant les plateformes signalé par @Hackcell
Maintenant, si mario se retrouve face à la plateforme, la plateforme s'arrête et repart quand mario ne bloque plus le passage.
Sinon je suis en train de préparer le troisième niveau...
Citer : Posté le 04/02/2020 21:27 | #
Yay, un niveau dans les airs !
Citer : Posté le 04/02/2020 21:40 | #
Intéressant ! Alors voilà des retours pour moi.
Niveau physique :
• On se rapproche du Super Mario Bros d'origine, mais ça glisse beaucoup trop quand on se déplace de droite à gauche. L'arrêt et les demis-tours devraient être quasi-instantanés !
• Je crois que j'ai tapé un Goomba par le côté pendant la phase ascendante d'un saut, ça l'a tué, ce qui est un peu inattendu.
• Le saut pourrait peut-être être plus linéaire (ie. la montée en hauteur répartie plus uniformément sur la durée du saut). Actuellement c'est très dur de faire des petits sauts.
Niveau graphique :
• Sur la calculatrice, la rémanence de l'écran rend les déplacements vraiment durs à suivre. Je suggère fortement de ne pas chercher à centrer Mario verticalement. À la place, tu peux le laisser bouger, et s'il s'approche trop du haut ou du bas de l'écran tu peux scroller un bon coup (eg. 40 pixels en 0.2 secondes).
• Quand on monte sur des plateformes élevées, on a tendance à ne plus du tout pouvoir voir en-dessous nous, typiquement au niveau 1-3 où il faut redescendre à l'aveuglette.
Les niveaux sont quand même vachement bien et le gameplay du jeu original se ressent vraiment. Il ne te reste plus qu'à partir dans la direction que tu veux sur le level design après avoir établi les liens avec le niveau 1-1 !
Citer : Posté le 04/02/2020 22:12 | #
Intéressant ! Alors voilà des retours pour moi.
Niveau physique :
• On se rapproche du Super Mario Bros d'origine, mais ça glisse beaucoup trop quand on se déplace de droite à gauche. L'arrêt et les demis-tours devraient être quasi-instantanés !
• Je crois que j'ai tapé un Goomba par le côté pendant la phase ascendante d'un saut, ça l'a tué, ce qui est un peu inattendu.
• Le saut pourrait peut-être être plus linéaire (ie. la montée en hauteur répartie plus uniformément sur la durée du saut). Actuellement c'est très dur de faire des petits sauts.
Niveau graphique :
• Sur la calculatrice, la rémanence de l'écran rend les déplacements vraiment durs à suivre. Je suggère fortement de ne pas chercher à centrer Mario verticalement. À la place, tu peux le laisser bouger, et s'il s'approche trop du haut ou du bas de l'écran tu peux scroller un bon coup (eg. 40 pixels en 0.2 secondes).
• Quand on monte sur des plateformes élevées, on a tendance à ne plus du tout pouvoir voir en-dessous nous, typiquement au niveau 1-3 où il faut redescendre à l'aveuglette.
Les niveaux sont quand même vachement bien et le gameplay du jeu original se ressent vraiment. Il ne te reste plus qu'à partir dans la direction que tu veux sur le level design après avoir établi les liens avec le niveau 1-1 !
• Une caméra à la Super Mario World est une bonne idée !
• Pour le bug, je trouve ça surprenant
Pour que tu aies pu tuer le goomba, il aurait fallu que tu sois au plus tôt en tout début de phase descendante
• Actuellement, le saut est une parabole tout ce qu'il y a de plus classique, j'avais fait ça parce que l'accélération était constante (ici -1) et donc le calcul était tout-ce qu'il y a de plus simple. Je vais voir si je peux trouver une autre équation où je peux travailler avec des entiers et où le mouvement est plus linéaire (et plus proche du mario d'origine)
En tout cas, merci beaucoup pour ton retour, je vais voir ce que je peux faire pour continuer à améliorer le gameplay
Au passage, je fais remarquer que j'ai noté un bug dans ma gestion du clavier : Lorsque l'on sprinte, changer de direction en maintenant alpha n'est pas détecté par le jeu, et il agit donc comme si l'on continuait à sprinter dans la direction précédente.
Citer : Posté le 05/02/2020 10:19 | #
Salut ! J'ai retesté ton jeu, il a beaucoup avancé depuis la dernière fois
Il serait souhaitable de mettre deux conditions séparées pour le saut, je pense que ton système de pression considère que haut et shift sont une seule est même touche, ce qui est très chiant. Il faudrait que les deux touches soient testées séparément puis ||. J'ai tendance à maintenir mon doigt vers le haut, ce qui fait que le jeu ne peut pas sauter quand je me déplace (il considère que je presse saut en permanence).
Je recommanderai de modifier les textures pour les accommoder à la rémanence, les goombas par exemple sont très difficiles à voir.
Les blocs avant la flagpole sont trop foncés.
L'implémentation du jump buffering et coyot time, deux mécaniques très utilisées dans les jeux modernes, serait très agréable également.
Ce sont des concepts simples et très utiles pour rendre le jeu plus juste (Celeste en abuse à mort, The End is Nigh a un coyot time de fou), je viens de trouver cet article sur Internet en cherchant les termes, le plus important reste le concept (ne fait pas attention à la plateforme visée).
https://www.yoyogames.com/blog/544/flynn-advanced-jump-mechanics
Je ne comprend pas trop pourquoi tu utilises une parabole, généralement les jeux de plateforme utilisent quatre ou cinq variables (dont deux ou trois constantes) pour la gravité et le saut :
char jhold = 0; //variable servant à calculer la hauteur de saut
const char jtime = 5; //nombre de frames où le joueur peut maintenir saut
const char grav = 0.2; //la gravité
const char max_grav = 6; //gravité max
const char jspd = -5; //la vitesse de saut, négatif
A chaque étape le programme ajoute grav à vspd si le joueur n'est pas sur le sol. Si vspd est trop élevée, tu peux la tronquer.
Ensuite, si le joueur saute (ou a buffer un saut) et/ou qu'il est dans son coyot time, sa vspd est mise à jspd et jhold à jtime.
Si le joueur ne saute pas, si jhold est vrai alors si jump_pressed (peut-importe comment tu gères ça) jhold--; et vpsd -= grav / 2 sinon jhold = 0;.
Il faut comprendre que c'est ma façon de procéder, la tienne doit fonctionner très bien. Mais si ça peut te donner des idées rien n'est perdu
Le principal est de bidouiller les paramètres une fois que le système est fonctionnel, pour obtenir le rendu le plus agréable possible.
Citer : Posté le 05/02/2020 11:48 | #
Wow, je connaissais pas ces mécaniques. Merci beaucoup pour le partage KikooDX, je suis bien content d'avoir appris ça !
Citer : Posté le 05/02/2020 15:46 | #
désolée pour laa réponse tardive, à propos de la vitesse de mario et de boules de feux, il me semblait juste que les boules de feux etait plus rapide que mario en sprint.
Citer : Posté le 05/02/2020 16:15 | #
désolée pour laa réponse tardive, à propos de la vitesse de mario et de boules de feux, il me semblait juste que les boules de feux etait plus rapide que mario en sprint.
C'est exact (dans le jeu de 1985 du moins).
Citer : Posté le 05/02/2020 18:05 | #
Je rectifierai ça alors
Citer : Posté le 09/02/2020 18:28 | #
Bon, je vais faire mon rapport de test plus simple sur ce projet car il est plus court, mais intéressant !
Respect du jeu : 1.5/2 - Super !!! Ressemble vraiment à l'original, mais certaines choses diffèrent encore (Mais c'est encore en projet
Bug : 1/2 - Les animations de Mario sont encore un peu bugué, donc je peux pas mettre 2 (En petit, il s'anime pas en allant à droite et en grand, le bras ne bouge pas en allant vers la gauche). De plus, les cubes ne se cassent pas quand on les tapes sur les coins
Graphismes : 1/1 - Magnifique ! (J'adore la tête des Goomba
Un total donc de 3.5/5, pas sur 10 car il n'est pas finis, hâte de voir le fin de ce projet ! Ne te décourage pas
Citer : Posté le 09/02/2020 18:52 | # |
Fichier joint
Merci beaucoup
Pour info, il est possible d'aller en haut du drapeau, il faut juste sprinter: selon la version que tu utilises, c'est [OPTN], ou [ALPHA] si tu utilises une ancienne version
Pour ce qui est des animations, elle ne sont pas encore prioritaires mais je les ajouterai
Je corrigerai les sprites des animations
Ce ne sera pas bien compliqué, le code est déjà en place comme tu l'as remarqué
En tout cas merci beaucoup pour ton test, ca fait super plaisir
Dans le cas ou la brique ne se casse pas lorsque l'oncogne le coin, c'est que mario devrait etre déplacé sur le côté, mais je ne l'ai pas ajouté non plus
Ajouté le 15/02/2020 à 16:52 :
Ces derniers jours, j'ai amélioré l'expérience ingame
Alors qu'avant les informations comme le score et les pièces étaient affichées en continu, et cachaient le haut de l'écran, un peu comme sur la capture 1 (elle date, mais la situation était à peu près la même il y a encore quelques jours). Maintenant, seul le temps est affiché en continu, les autres compteurs s'affichent seulement si leur contenu change
Citer : Posté le 15/02/2020 16:56 | #
Not bad ! Les niveaux font combien de hauteur en général ?
(Poste quelque chose dans la revue des projets quand tu auras le temps !)
Citer : Posté le 15/02/2020 17:00 | #
Pour l'instant les niveaux font 13 ou 14 tiles de haut, soit au maximum 112 pixels de haut. Mais j'envisage de (pourquoi pas après tout) tester des niveaux en forme de tour, donc qui seraient beaucoup plus verticaux
Si j'ai le temps ce soir, je fais un article pour la rdp de demain