Aventura, le Royaume Poudingue... Un long projet !
Posté le 06/07/2016 23:44
Aventura, Le Royaume Poudingue est un RPG en Basic Casio (monochrome) entamé en 2016 et repris en 2018. Projet très ambitieux, ce dernier tend à s'emparer des meilleures techniques de Basic Casio pour offrir une expérience de jeu dépassant les attentes du joueur. Il aura fallu deux années complètes pour que la première version complète du jeu sorte enfin ! Ouf !
Le jeu est enfin disponible ! Cliquez ici !
Le projet en 2016
Cliquer pour enrouler
[...]
En réalité, je projette de concevoir un RPG en recommençant absolument tout de zéro. En errant sur ce forum, j'ai amassé une quantité satisfaisante de savoirs nouveaux en ce qui concerne le basic ! Toutes les techniques et les jeux que j'ai entraperçu ou étudié sur ce forum ont fait germer tout un tas de petites idées en moi !
Je vous expose le plan : l'idée n'est qu'à l'état embryonnaire, mais je compte la faire évoluer par débats et expositions d'idées. Pour l'histoire, le scénario, je n'ai pas de problème. J'ai l'imagination qu'il faut pour pondre des trucs farfelus. Ce dont j'ai besoin, c'est d'approfondir le système du jeu et tenter de construire un programme cohérent, très optimisé et performant. Procédons à tout cela par étape, je relèverai chacune de mes interrogations par la suite.
La map : Résolu
Cliquer pour enrouler
C'est ce qui me fait me poser le plus de questions. Voici ce que j'ai décidé : sur une picture sera enregistrée une sidebar qui sera visible pareillement sur le mapmonde et en combat. J'ai pour ambition d'adopter un système de tiles pour générer les maps (qui seront statiques, comme le fameux Zelda PC de Remiweb, et pas de map scrolling). Pour commencer, je projette de concevoir un système de sauvegarde provisoire des maps. Voici un schéma pourri fait à l'arrache :
Lorsque le joueur est sur la map 1, le décor de cette map est enregistrée en picture 1 (par exemple). Arrivé sur la map 2, celle-ci est enregistrée en picture 2. Sur la map 3, elle est enregistrée en picture 3. Lorsque le joueur veut retourner sur la map 2, la picture 2 est directement affichée plutôt que de la redessiner. En passant sur la map 4, la map 1 sur la picture 1 est effacée pour laisser place à la map 4. Ainsi, le personnage peut se ballader entre les map 2, 3 et 4 sans temps de chargement !
Résolu
Cliquer pour enrouler
je vais rencontrer de nombreuses problématiques concernant le dessin d'une map. Pour une map, je vais rentrer dans une matrice les ID de chaque case. Admettons que j'ai un programme "lecteur de matrice" qui dessine chaque case en fonction de l'ID. Il est évident que je vais essayer de dessiner d'une traite tous les tiles identiques avant de passer aux tiles suivants, plutôt que de faire :
For 1→A To 6
For 1→B To 11
Mat A[A;B]=1⇒{1,2,3→List 1
etc.
Next
Next
Drawstat
C'est-à-dire lire chaque case, une à une, même si elle est vide, pour dessiner une tile. après avoir entré dans la liste les coordonnées. Bref. C'est long, sale et un peu bulldozer.
Un génie de Naheulbeuk a écrit :
Baston !
J'avais prévu de faire entrer toutes les données chiffrées dans une chaîne (Str 1) plutôt que dans une matrice(qui est d'ailleurs lourde) pour pouvoir exploiter les fonctions StrSrch, StrMid, etc. Il est tout à fait possible de passer d'une chaîne à une expression numérique, donc ce point ne pose pas problème. Qu'en pensez-vous ? L'idée peut-elle être exploitée ou est-elle incohérente ?
Résolu
Cliquer pour enrouler
Je cherche le bonne taille de tiles à prendre. J'avais pensé à utiliser des tiles de 10*10. Chacune de mes maps feraient alors 6*11 cases. Y a-t-il une taille préférable à 10*10 ? Qu'en pensez-vous ? Je ne sais quoi en penser. Je vais rencontrer un autre problème : le stockage de données. Avec les listes, je me demandais si une seule liste avec des coordonnées complexes est plus légère que deux listes pour les abscisses et ordonnées séparées. La différence est-elle notable ? Si oui, ça m'arrangerait bien pour ce que je pensais faire :
Il serait possible que j'exploite la technique Augment( pour dessiner tout d'une traite avec le Graph(X ; Y)=. Cette technique étant très gourmande en mémoire sur l'instant, je pourrais effectuer l'opération plusieurs fois. Mais ça serait assez confortable de pouvoir mettre :
Dim List 1→Tθmax
Graph(X;Y)=(ReP List 1[T];ImP List 1[T
J'aimerais votre avis là-dessus !
Alors là, j'ai pas mal réfléchi. Sur le modèle de fonctionnement Poule/Renard/Épervier, ou Feu/Eau/Plante dans Pokémon, j'ai l'intention de créer trois types d'attaque :
Puissance ,
Dextérité et
Vitesse.
Le personnage aura trois attaques pour chacun de ces types. Donc une animation différente pour chacun d'entre elle. Il maîtrisera en plus une capacité de soin, et peut-être une capacité secrète.
Il n'y aura pas de niveau à proprement dire : Selon les attaques qu'on emploie, la maîtrise dans la branche correspondante augmente et améliore les capacités du personnage : Force, Défense, Nombre de coups, précision, Esquive, etc.
Bon. Le souci, c'est que je vais devoir à dessiner des monstres et risque d'être limité sur ce point là.
Le personnage est en fait personnalisable. Au début du jeu, vous pourrez choisir une arme et une coiffe (lunettes de soleil, chapeau en pointe...) La machine génère alors sur plusieurs listes trois positions du personnage : une statique, une en tenant l'arme en l'air, une troisième en donnant le coup. Pour cela, je fais tourner l'arme, comme je l'ai évoqué dans ce
topic. ce point précis est résolu. C'est grâce à ses trois dessins pré-enregistrés que je ferai les animations. Une question se pose : comment faire des animations pour les monstres potables et peu spacio-phages ?
Voici à quoi ils ressemblent !
(photos expirées)
Pour le menu :
Pas encore d'idée, si ce n'est un truc enregistré sur une autre picture qui sera beau graphiquement parlant. On y verra l'état du personnage et son niveau de maîtrise dans chaque branche.
Pour l'interaction avec des pnj :
Résolu
Cliquer pour enrouler
Je projette de concevoir un sous-programme "lecteur de texte", si je puis dire. Sur la map, le programme dessinera une boîte de dialogue dans laquelle s'écriront les paroles d personnage. Pour ce point, je compte beaucoup m'inspirer des travaux de Remiweb sur son Zelda PC. J'ai trouvé ce point absolument remarquable et incroyablement bien fait.
Voici la tronche du projet. J'aimerais vraiment avoir vos avis, savoir ce que vous en pensez, avoir de vos précieux conseils et surtout engager le débat pour progresser. Je vous remercie d'avance, et vous remercie aussi de m'avoir lu jusque là.
État des lieux du projet
modifié le 20 09 2018
À ce jour, voici ce qui est fait et ce qui reste à faire pour l'ensemble du programme de jeu.
Graphismes (personnages, monstres, background, carte du monde, title screen...)
Comme vous pouvez le voir, il reste beaucoup de travail.
Le plus difficile sera de faire tenir tout le jeu en ~ 60 000 octets. Seulement, je ne parle pas du programme seul : à présent, il ne fait que 6772 octets. Toutefois, les Pictures prennent déjà 11404 octets (avec y compris les 6072 octets des trois pictures du mon système de sauvegarde de map, et les list peuvent atteindre les 7000 octets. Actuellement, il me reste quelque chose comme 36 000 octets de libres pour faire TOUT LE RESTE.
Le jeu en quelques questions
modifié le 08 06 2018
Que sont les Poudingues ?
Les poudingues sont des petites créatures sans bras ni jambe, au corps semblable à un mélange entre une balle d'arme à feu et un pudding. Leur visage est expressif et ils déterminent généralement leur appartenance sociale par leur couvre-chef.
Quel est le but du jeu ?
Vous incarnez un de ces fameux Poudingues, vivant au sein d'un royaume dirigé par un monarque Poudingue. En tant qu'Explorateur, vous êtes convoqué par le roi lui-même pour vous confier une mission : localiser le repaire des poudingues anti-royalistes qui semblent préparer une révolte dans l'ombre...
Quel type de jeu ?
Aventura, le royaume poudingue est un RPG / jeu d'exploration. Vous devrez, pour une partie du jeu, explorer des terrains, trouver les pnj à qui parler pour faire avancer l'histoire, etc. Durant le jeu, vous devrez aussi affronter les monstres sauvages ou bien les opposants qui se dresseront sur votre chemin ! Au fil des luttes, vous affinerez votre style de combat, renforcerez vos spécialités et augmenterez votre niveau et vos caractéristiques.
Quelles caractéristiques et quel système de combat ?
Le système de combat est à priori un système au tour à tour, en un contre un de profil sur l'écran.
Un poudingue possède trois caractéristiques, avec un niveau de maîtrise pour chacune d'entre elle : Puissance, Technique, Vitesse. En fonction des attaques employées par le poudingue, ses niveaux de maîtrise correspondant augmentent. Lors d'une montée de niveau, chaque caractéristique augmente proportionnellement à son niveau de maîtrise. Utilisez beaucoup de fois l'attaque « Cogne » et votre puissance avancera davantage ! Votre type est ensuite déterminé par la valeur la plus élevée des trois caractéristiques : type Puissance, type Technique, type Vitesse, ou bien Neutre si vos caractéristiques sont équilibrées.
Ces trois types fonctionnent selon une règle similaire au jeu Pierre-Feuille-Ciseaux. Le type Puissance a l'avantage face au type Vitesse, le type Vitesse a l'ascendant sur le type Technique et le type Technique est plus efficace contre le type Puissance. Ce rapport de force se détermine dans le calcul des dégâts infligés, qui sont en pourcentage. Autrement dit, le joueur a 100% de vitalité et meurt s'il tombe à 0%. Le nombre maximal de vitalité ne change pas, il est de 100% pour tout le monde.
À priori, le niveau maximal atteignable serait de 100. Le système de calcul d'expérience n'est pas encore établi.
Les trois caractéristiques interviennent donc dans le calcul des dégâts en fonction du type de l'attaque. La caractéristique du lanceur correspondant au type de l'attaque et la caractéristique de la cible correspondant au type ayant l'ascendant sur celui de l'attaque sont pris en compte dans le calcul des dommages. Exemple : le joueur utilise une attaque Vitesse sur une cible de type Technique. La caractéristique Vitesse du joueur et la caractéristique Puissance de la cible seront pris en compte. Un facteur de dégâts accru s'appliquera sur les dommages totaux puisque le type Technique est faible face aux attaques Vitesse. Au final, si le lanceur a beaucoup de Vitesse et la cible peu de Puissance, l'attaque infligera de lourds dégâts.
Les niveaux de maîtrise augmentent aussi l'efficacité des attaques suivantes : Cogne, Estoc, Rafale. À partir de certains seuil, les niveaux de maîtrise donnent de nouveaux effets / bonus à ces attaques. Il peut donc sembler intéressant de se spécialiser dans un type pour améliorer ses attaques.
Les sorts, quant à eux, n'augmentent pas les niveaux de maîtrise lors de leur utilisation. Si un sort peut s'avérer plus efficace qu'une attaque classique, il ne permettra pas à son utilisateur de bien progresser sur le long terme.
Un aperçu du moteur de combat, le 09 07 2018 (V - 0.21)
Un aperçu du moteur de dialogue, le 21 07 2018 (V - 0.22)
L'Éditeur de mappemonde, 08/2018.
Un autre aperçu du moteur de combat, le 08 08 2018 (V - 0.24)
Phase 1 : Écriture. Cette étape consiste à coucher sur le papier ce que je projette de faire, le gameplay et les composants du jeu, dans un idéal. Je ne m'occupe pas tant de savoir si ça tiendra dans le code, ni de savoir si j'aurais le temps et/ou la motivation d'en faire autant. J'essaye d'en écrire le plus possible, dont le scénario avec le plus de détails possible, les personnages, etc.
Phase 2 : Architecture générale. Il s'agit de hiérarchiser les sous-programmes, menus, et les chemins qui s'opèrent entre chaque. Dans cette partie, on ne s'occupe pas du code dans les détails, mais plutôt de « blocs » en tant qu'ensembles de fonctions. Par exemple, j'aurai un bloc « Title screen », un bloc « dessin map », un bloc « dialogue », etc. Il s'agira de définir avec une certaine précision les blocs qui interviendront pour le fonctionnement du jeu, d'estimer si possible leur taille et de les positionner les uns par rapport aux autres, les cheminements de sous-programmes à sous-programmes – sachant qu'on ne peut pas avoir plus de 10 sous-programmes qui tournent à la fois.
Phase 3 : Code. Écriture du code à l'intérieur de chaque bloc, avec seulement quelques données à titre d'exemple. Il ne s'agira pas de faire du bô graphisme ou bien pleins de sprites et de pictures différentes. L'objectif ici est de fabriquer rapidement quelques éléments de dialogue et de graphisme pour pouvoir écrire tout le code qui fera fonctionner le jeu et qui agira comme un squelette. De beaux graphismes sont inutiles si le code sous-jacent n'est pas fonctionnel. J'ai eu tort de commencer à faire des maps et des pictures, mais elles sont là et je ne vais pas les gâcher.
Il me faudra alors écrire de façon individuelle et séparée chaque « bloc » ou « fonction » pour m'assurer que leur fonctionnement propre est opérationnel. C'est aussi l'occasion de revoir certaines ambitions à la baisse si elles demandent trop de place dans le code. Cette partie ne constitue pas l'intégralité de l'écriture du code, loin de là. La phase 4 y occupera une place importante aussi.
Phase 4 : Mise en relation et assemblage des blocs. Cette partie sera délicate, mais aura été largement anticipée avec la phase 2. Il s'agit non plus de faire fonctionner des pièces détachées, mais de les assembler et de penser avec ingéniosité leur articulation pour que le jeu devienne une seule entité. Cette phase comprendra vraisemblablement des modifications à l'intérieur même de chaque bloc pour d'éventuelles optimisations. Il y aura naturellement de nombreux tests et essais quant au bon fonctionnement de l'ensemble de la structure.
Phase 5 : Travail de « remplissage ». Si le squelette du jeu est tout à fait opérationnel et ne présente pas de bug, on passe à cette phase qui consiste à remplir le jeu de son contenu : les graphismes, les maps, les dialogues. C'est donc à ce moment que je m’attellerai activement à la conception des graphismes du jeu et à ses dialogues. Cette phase porte bien son nom puisqu'elle devra également être modulée en fonction de la place restante en mémoire dans la calculatrice.
Phase 6 : Optimisations, essais et tests du jeu intensifs. Cette phase vise à repérer les éventuels défauts dans le code du jeu, mais aussi dans le gameplay. C'est une phase très importante car elle vise à rendre le jeu jouable, appréciable et source de plaisir (oh yeah baby), mais aussi cohérent dans son ensemble. Elle contiendra donc beaucoup de recorrections et peut-être même de frustration chez le concepteur (moi) qui constatera que son jeu est tout pourri.
Phase 7 : Publication. Une fois que les corrections, tests, optimisations et finitions sont finis, il ne me reste plus qu'à publier une version 1.0 (ou Bêta) du jeu et attendre des retours de la communauté, qui sera sans doute enthousiaste de voir un jeu sortir après plus de deux années d'attente, lôl. En fonctions des retours, des finitions et des ajouts auront peut-être lieu pour donner suite à une version 1.1, 1.2, etc. L'objectif sera donc de corriger les éventuels bugs qui seraient passés inaperçus, et prendre en compte des suggestions pour améliorer l'expérience de jeu.
Phase 8 : Supplication. Demander à ce que le jeu jouisse du label de qualité Casio. C'est mon rêve. Je le veux. Au moins une fois dans ma vie !
Les suggestions de sorts par les membres de la communauté :
Lephenixnoir : « Pistole, Assaut, Regard perçant, Empalement, Illusion, Barrage, Retour de l'Hirondelle, Contournement, Vorpal, Survol, Coup ascendant, Berserk, Flèche ? »
Shadow15510 : « Boule de Feu (T) ». Woaw. Incroyable.
Membres ayant manifesté leur volonté d'apparaître dans le jeu :
Lightmare
Shadow15510
Cakeisalie5
Massena
Totoyo
Lephenixnoir
Math680
Git du projet : Soyez au plus près du code et des avancées des versions !
https://gitea.planet-casio.com/PlaneteCasio/Le_Royaume_Poudingue
Mis à jour le : 31/10/2018
Fichier joint
Citer : Posté le 17/06/2018 00:35 | #
Au sujet du pdf ce que je voulais dire c'est que le nombre de téléchargement est bien inférieur à celui du jeu, même avec une mise en avant. Même s'il est téléchargé, il y a peu de chance qu'il soit lu en entier, car il n'y a que les acharnés comme toi et moi qui les lisons.
Mais enfin je ne veux pas te faire perdre ton temps à épiloguer sur ce sujet, qui ne sera d’intérêt qu'à la toute fin du projet !
La Planète Casio est accueillante : n'hésite pas à t'inscrire pour laisser un message ou partager tes créations !
Citer : Posté le 17/06/2018 00:37 | #
Toute ces discussions me donnent envie de reprendre le mien... ça ferra une sorte de concurrent
Citer : Posté le 17/06/2018 00:37 | #
Quel projet as-tu envie de reprendre, Suruq ? Sérieux, si t'as envie de reprendre un projet, j'suis chaud pour t'aider !
Citer : Posté le 17/06/2018 00:39 | #
Oui j'ai remarqué que tu aimais bien la concurrence Suruq, que ça te motivais !
Il faudrait que nous organisions un gros concours pour "forcer" le réveil de gros projets. C'est ce qui m'a lancé par le passé.
La Planète Casio est accueillante : n'hésite pas à t'inscrire pour laisser un message ou partager tes créations !
Citer : Posté le 17/06/2018 00:40 | #
Le jeu que j’ai fait pour les derniers CPC
C’est un roc mais il faut que j’en reprenne l’histoire et que j’optimise plein de chose, et que je fasse des graphismes digne de ce nom (je suis-je une bille)
Mais si un jour j’en fini ça peut être pas mal
Citer : Posté le 17/06/2018 00:42 | #
Tu veux donc parler de ce projet-là ? https://www.planet-casio.com/Fr/programmes/programme3476-1-Pas-De-Nom-suruq-game-jeu-role_rpg.html
Ouaip, sérieux, fonce ! De plus, je sortirai bientôt un tuto qui pourrait peut-être te motiver au niveau graphismes
Citer : Posté le 17/06/2018 00:42 | #
@neo
C’est vrai que si je ńai pas d’enjeu/défi j’ai tendance à être trèèès flaimard
Par exemple pour mon projet d’ISN qui est évalué pour le Bac j’ai pas mal travaillé alors que ça n’es le mettait pas vraiment.
Citer : Posté le 17/06/2018 20:28 | # |
Fichier joint
Je vous fait part ici de mes avancées. J'ai réalisé un schéma d'architecture des blocs principaux du jeu. Je vous explique comment il fonctionne :
– Le joueur commence par "début". Ce n'est as un bloc de code, simplement l'indication du commencement du programme.
– La flèche rouge indique une priorité : lorsque l'on est dans le bloc "Index", on passe tout de suite dans le bloc "Écran titre" au début du jeu. Logique.
– Lorsqu'un bloc a rempli sa fonction et n'a plus de sortie, le programme revient au bloc précédent (équivaut à la fonction Basic Return, en quelques sortes)
– Tout tourne autour du Bloc "Index / Getkey / Déplacements du joueur). C'est dans ce bloc qu'on revient lorsqu'un combat se fini, lorsqu'une map est dessinée, lorsqu'on quitte un menu, etc. N'oubliez pas qu'on ne peut pas faire tourner plus de dix sous-programme en même temps.
Citer : Posté le 17/06/2018 20:43 | #
Un très joli point à observer est que ce graphe est acyclique : bravo !
Il y a un petit théorème qui dit que si un graphe orienté est acyclique alors tu peux le dessiner de façon à ce que toutes les flèches partent vers le bas. Ça pourrait être pratique pour bien voir comment le flot d'exécution se comporte (Prog : descente, Return : remontée).
Est-ce que cette structure en étoile veut dire que tout tourne sur le même moteur, finalement ? Par exemple que l'écran titre et l'écran du jeu ne sont pas disjoints (comme on le ferait d'habitude) en termes de code ?
Citer : Posté le 17/06/2018 20:52 | #
Je ne sais pas si j'ai correctement compris ta question, mais pour ce qui est de l'écran titre, on aurait quelque chose comme ça :
"INDEX"
Prog "TITLE"
~Do your stuff
_______
"TITLE"
BG-Pict ?
Text truc "Continuer / Nouvelle Partie / Crédit"
If Nouvelle Partie
(Sous-bloc initialisation)
(Sous-bloc choix skin et nom)
IfEnd
If Continuer
(Sous-bloc récupérer données sauvegarde ?)
Ifend
//Fin de code, donc return
Citer : Posté le 17/06/2018 20:58 | #
Ok, donc c'est moi qui m'imaginais des choses sur la signification des flèches dans ton dessin. Ne fais pas attention.
Citer : Posté le 17/06/2018 22:22 | #
Ce serait pas cool de reprendre les attaques des prokémons que l'on trouve en masse Vos portrait... en pokémons du coup tu as les pseudos et les attaques
Citer : Posté le 17/06/2018 22:25 | #
Hors de question. J'ai envie d'ajouter de ci de là des clins d'oeil mais pas de faire de tout le jeu un gros merdier de copier/coller d'attaques de pokémon et de références aux membres du site que la plupart des joueurs ne comprendront pas.
Citer : Posté le 17/06/2018 22:27 | #
soit
Citer : Posté le 18/06/2018 00:07 | #
Excuse-moi, je me suis rendu compte que mon message était peut-être un peu brutal !
Citer : Posté le 18/06/2018 08:04 | #
Y a pas de mal
Citer : Posté le 24/06/2018 21:03 | #
Bon. J'aurai peut-être dû écrire un quelque chose pour la RDP, mais disons que je n'ai pas vraiment eu le temps pour ça !
Alors voici, je me porte aux nouvelles : j'ai fait des schémas semblable à celui que je vous ai montré plus haut pour chaque sous-bloc. Autrement dit, j'ai une idée assez précise de comment sera foutu mon code de manière très globale !
Je ne partage pas chaque schéma ici car ils ne sont pas aussi soignés et compréhensibles que celui que j'ai partagé avec vous. Enfin bref, je sonne la fin de la phase 2 ! À partir de maintenant, je m'attaque à la...
==================================► Phase 3 ◄====================================
L'écriture du code ! La partie la plus terriiiiiible !!! Ha ha ha ha ha ha ! Bon bref. Je ferai donc appel à votre aide sur cette partie là, car je vais avoir besoin d'un peu d'assistance et de regards extérieurs pour m'aiguiller, un peu comme au début de ce topic ! Restez heu... à l'écoute ? Non, Stay tuned!
Citer : Posté le 25/06/2018 17:08 | #
Très bien, je suis actuellement en train de chercher des solutions techniques à d'éventuels problèmes. Laissez-moi vous expliquer. N'hésitez pas à poser des questions ou à me dire que c'est de la merde. J'aurais besoin de votre avis sur ce que je suis en train de faire car il y a peut-être plus simple ou plus... mieux ?
Comment sont stockées les Maps :
Chaque caractère correspond à un sprite. Seulement, la chaine telle que vous la voyez ici est compressée. Le caractère "->" indique une suite de 0. Le zéro étant un vide, c'est le caractère le plus courant. Le caractère qui suit le "->" indique le nombre de zéros qui se suivront. Une fois décompressée, cette chaîne de caractère devient :
Les maps sont réparties en 11 * 6 cases de 10*10 pixels chacune. La chaîne de caractère ci-dessus contient 66 caractère. Vous l'aurez peut-être compris, chaque caractère correspond donc à une case de la map. Les 11 premiers caractères correspondent à la première ligne, les onze suivant à la deuxième ligne, etc.
Les avantages d'une telle méthode : ces données ne prennent que peu de place lorsqu'elles sont hardcodées. Potentiellement, une map peu prendre moins de 50 octets. Cette méthode autorise des techniques de compression assez facilement, et prend moins de place que des matrices. Elle permet donc d'avoir une mappemonde très grande.
Les inconvénients de cette méthode se résument sans doute à son manque de flexibilité. Il parait alors assez complexe de rajouter des ID ou des propriétés à certains tiles. Il faut savoir que les PNJ sont également considérés comme des tiles. Voici alors une liste des tiles qui auraient besoin de propriétés :
Les Pnj ont besoin d'un ID. Les interrupteurs ont besoin d'un numéro (un interrupteur n°1 pour ouvrir les portes n°1, etc). Les portes et autres tiles ont donc également besoin d'un numéro de correspondance avec les interrupteurs. Les fontaines et les Statues de sauvegarde interviennent comme un PNJ, à la nuance près qu'ils ne peuvent être agressés.
Pallier cet inconvénient.
Ma soluation : le signe "(". Voici par exemple une map vide :
Dans cette map, il y a 6 lignes de 11 zéros à la suite. Le zéro, je le rappelle, est un vide. Mettons donc dans cette map un pnj, représenté par le caractère Z par exemple.
Il y aura donc un pnj sur la case la plus en bas à gauche de l'écran. Seulement, j'ai besoin de lui attribuer un ID. De la même manière, cet ID peut être codé par un caractère. "5" pour 5 , "9" pour 9, "A" pour 10, "E" pour 13, etc. Seulement, je vais rajouter un caractère inutilisé qui va signifier que le caractère qui suit est l'ID du pnj. Mettons que ce pnj soit le pnj numéro 3 (ID = 3). Je vais donc l'écrire ainsi :
Mais je n'ai pas besoin de la parenthèse fermante. Je sais qu'il n'y aura qu'un seul caractère entre les parenthèse. Économisons donc un octet :
Lorsque la chaîne est attribuée à Str 2 et que Str 2 est décompressé, le programme vérifiera également s'il n'y pas de parenthèse dans la chaîne. S'il y a une parenthèse, il enregistre la valeur de l'ID du pnj dans une variable et la retire de Str 2.
Dans le cas des interrupteurs, voici ce que j'ai prévu. On va faire à peu près pareil, sauf qu'il y aura une nuance. Les parenthèses seront réservées aux Pnjs. Les accolades {} me permettrons d'attribuer un nombre à un interrupteur ou à un autre tile. Mettons que je mette dans cette même map un rocher (tile n°7 je crois) et un interrupteur (mettons, codé par le caractère I).
Je vais donc attribuer un numéro au rocher et le même à l'interrupteur pour que le rocher se déplace d'une case vers la gauche lorsque l'interrupteur est activé.
Même remarque, je retire les accolades fermantes car je n'en ai pas besoin.
"Z(3->A->C7{100I{1->6->B->B->B"
Comment les interrupteurs vont-ils fonctionner ? C'est assez simple, sur le papier : la mappemonde est divisée en zones. Considérez une zone comme un environnement (désert, foret, montagnes, etc.) ou bien un intérieur (grotte, donjon, château). Il y a une variable (r par exemple) attribuée aux interrupteurs qui est réinitialisée à chaque changement de zone. Concrètement, voici ce qu'il se passe lorsque le joueur appuie sur un bouton n°1 : le chiffre des unité de la variable r change. Il passe de 0 à 1 ou de 1 à 0. Le chiffre des unité agit donc comme un booléen qui fera se déplacer tous les tiles de la zone qui ont le numéro 1. Un bouton n°2 change quant à lui le chiffre des dizaines. Le n°3 concerne le chiffre des centaines. Le n°4 le millier, etc. Dans le cas suivant :
Tous les tiles dont le numéro attribué par les accolades est 1, 3 ou 4 seront déplacé d'une case sur la gauche. Les tiles dont le numéro attribué est 2 ne seront pas déplacés. Dans ce cas, si nous revenons à notre map, nous passons de :
"Z(3->A->C7{100I{1->6->B->B->B"
Vous remarquerez que le 7 a été déplacé d'une case sur la gauche ! Le programme aura également enregistré dans une autre variable le numéro du bouton (on part du principe qu'on n'en a qu'un à la fois). Si le joueur appuie à nouveau sur l'interrupteur ou change de zone pour revenir ici, le rocher aura repris sa place initiale. Avec ce système, on peut faire se déplacer n'importe quel tile.
Qu'en pensez-vous ? Est-ce fiable et viable, selon vous ? Est-ce que vous auriez fait autrement ?
... Avez-vous compris ?
Citer : Posté le 25/06/2018 17:55 | #
Pour ce qui est de la fiabilité, je n'ai pas l'impression qu'il y aura des problèmes d'ambigüité ou autre, car la contrainte que tu poses d'avoir un seul attribut au plus dans la parenthèse / accolade est suffisamment forte.
Les objets auxquels tu souhaites vouloir attribuer une propriété auront-ils systématiquement une propriété ? Si oui, tu pourrais par exemple gagner encore un peu en espace en stockant les propriétés à la fin de la map, dans l'ordre dans lequel les objets sont rencontrés : vu que tu sais grâce à la taille de l'écran quand tu as finis de lire la map “géographiquement”, tu peux savoir sans avoir besoin de caractères ( ou { que ce sont maintenant des propriétés que tu lis, puis exploiter l'ordre pour ne pas avoir de problème d'association ; c'est peut-être ceci-dit plus compliqué à gérer au niveau du code de lecture de la carte et peut être pas vraiment très rentable en terme d'espace, je ne sais pas, à toi de voir à ce niveau-là.
Citer : Posté le 25/06/2018 18:53 | #
Sinon tu hardcodes les objets à propriétés, par exemple quand on rencontre un Z, le chiffre qui suit est forcément une propriété de ce pnj
(enfin après, faut aussi penser au poids du code : si tu sauvegardes 10 octets mais que le code pour le décoder en fait 20, c'pas la peine
Ecrivez vos programmes basic sur PC avec BIDE
Citer : Posté le 25/06/2018 23:38 | #
Nemhardy, Zezombye, merci de vos réactions.
En fait, tous les objets n'ont pas forcément de propriété. Il n'y en a que quelques uns, à savoir ceux que je veux faire se déplacer avec l'appui d'un interrupteur.Dans un donjon, ça peut être une statue. Dans une forêt, un arbre. Etc.
L'idée de ZZ n'est pas bête. Un pnj a forcément un ID, donc à partir de là.... Le seul truc qui m'embête, c'est la vérification de la condition. En gros, tous les pnj sont regroupés, genre du tile numéro 32 au tile numéro 37 ou je ne sais plus quoi. Quand j'ai une parenthèse, c'est facile à vérifier. Quand je dois vérifier que j'ai à faire à un pnj, c'est moins simple. ça donne ça... (Avec Str 2 la chaîne de caractère contenant la map)
If StrSrc ( Str 2, "(" )
Then //gna gna gna
//Si je dois vérifier que c'est un pnj :
If StrCmp ( Str 2, "V-" ) = 1 And StrCmp ( Str 2, "b-" ) = -1
Then // gna gna gna
Après, sur un assez grand nombre de pnj, ça devient rentable, je pense.