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 07/07/2016 16:16 | #
Ce ne serait pas mieux de faire un StrCmp au lieu de convertir le sprite en ID ?
Toi t'as besoin de faire ça pour chaque valeur possible, bonjour la grosse condition à chaque ligne.
Non seulement c'est lent mais en plus ça rend le poids du programme beaucoup plus important qu'avec ma méthode.
Mais t'as rien suivi
Justement on veut générer une seule liste pour tout tracer en une fois.
Pourquoi ? Parce que c'est beaucoup plus rapide !
Il vaut mieux faire une fois un Graph avec 40 points que 4x un Graph avec 10 points.
Citer : Posté le 07/07/2016 16:18 | #
Ce que je ferais c'est parcourir la chaine qui code une map. Quand on rencontre un nouvel ID par encore traité :
on va traiter toutes les tiles qui ont cet ID en complétant notre liste qui servira à l'affichage
et on marque cet ID comme déjà traité.
L'idée me semble juste.
J'aurais fait comme ça :
Avec Str 1 contenant le caractère correspondant à une tile dont on veut récupérer l'ID.
Y'a pas à dire, c'est vraiment très constructif de partager ses projets et de débattre !
Je suis d'accord avec le principe de Remiweb.
on peut directement faire un Graph(X,Y) en spécifiant la liste dans le code (avec des accolades).
Ce que tu veux faire, ZZ, c'est utiliser un multi drawstat, je veux quant à moi employer un seul super drawstat.
Ajouté le 07/07/2016 à 16:21 :
Mais comment parcourir la chaîne pour voir si on rencontre un nouvel ID non encore exploité ? À part ce que j'ai fait en tout début de mon code, je ne vois pas bien.. !
Citer : Posté le 07/07/2016 16:29 | #
Histoire de clore le débat :
Oublions l'histoire d'une seule liste, on parle bien tout les deux de faire des conditions à la suite pour identifier la tile.
Voilà ce que toi tu veux faire ZZ (j'ai reprit ton code en corrigeant les erreurs) :
If StrCmp(StrMid(Str 3, I, 1),"0")
Then //code pour la tile 0
IfEnd
If StrCmp(StrMid(Str 3, I,1),"1")
Then //code pour la tile 1
IfEnd
etc...
C'est extrêmement lourd, aussi bien pour l’exécution que pour le poids du programme.
On a une grosse condition avec du StrMid et StrCmp à chaque If.
Voilà comment moi je fais la même chose :
If A=0 :
Then //code pour la tile 0
IfEnd
If A=1 :
Then //code pour la tile 1
IfEnd
Cette fois on a une seule condition en StrMid et StrSrc.
Niveau temps d'exécution c'est la même que pour l'une de tes contions, même s'il y a une boucle dans le StrSrc comme c'est l'OS qui le fait et non ton code basic c'est extrêmement rapide !
Et pour la suite on a plus que des conditions toute simples
Imagines qu'on ai 40 tiles différentes, toi tu ferais 40 fois StrCmp(StrMid(Str 3, I,1),"_")
Moi je fais une seule fois StrSrc("01",StrMid(Str 3, I, 1)
T'imagines bien que ce sera plus rapide ? L'éxecution d'un StrSrc est quasi instantanée comme ça vient de l'OS.
Ajouté le 07/07/2016 à 16:52 :
Du coup pour ce qui est du code :
Déjà il faut savoir que StrSrc peut prendre un troisième argument qui permet de commencer à chercher seulement à partir d'une position donnée. (Je ne le savais pas encore quand j'ai fait le zelda)
Admettons qu'on ai une map comme ça :
10001
20102
12221
Elle fait 5*3 et je la code comme ça : "100012010212221"->Str 2
Voilà un calcul pour récupérer les coordonnées d'une tile à partir de son indice i dans la Str :
X=Mod(i-1,5)+1
Y=Int((i-1)/5)+1
Et mon code pour le chargement :
"100012010212221"->Str 2 //La map
For 0->K To 2 //On va tester les tiles une par une (0, 1 ou 2)
StrMid("123456789ABC...",K,1)-> Str 1 //Pour avoir K dans les StrSrc
StrSrc(Str 2,Str 1)->A
If A≠0 //Si la tile est bien utilisée dans la map
Then Prog("SPRITE") //on charge le sprite correspondant
Do
Mod(A-1,5)+1 -> X
Int((A-1)/5)+1 -> Y
Augment(List 2,List 1 + 10X + 10iY) //10 pour les sprites de 10*10
StrSrc(Str 2,Str 1,A+1)->A //on cherche la tile suivante
LpWhile A //Tant qu'on trouve d'autres fois cette tile
IfEnd
Next
ViewWindow 1,127,0,1,63,0,2,Dim List 2,1
Graph X,Y (Rep List 2[T],Imp List 2[T])
Le programme "SPRITE" exploitant ce que j'ai donné avant. Il retourne simplement le sprite correspondant à la valeur A dans la liste 1.
(J'ai tapé ça sans vérifier, il y a peut-être des problèmes d'indice)
Citer : Posté le 07/07/2016 17:31 | #
Ta partie sur le moteur de combat m'a rappelé mon projet Fight 6. Son moteur de combat gère les combats en 2 vs 2, l'IA est coopérative, et on peut monter jusqu'à 8 attaques par combattant. Le programme principal du moteur est l'une des plus volumineux (env 8000 octets). A l'époque, je n'utilisais pas encore les chaines de caractères, mais peut-être que ça t'aidera à construire ton moteur.
Ajouté le 07/07/2016 à 17:31 :
Au fait, Fight 6 est aussi un RPG.
Vitesse des fonctions en Basic Casio | 7 days CPC | Casio Universal Wiki | Tutoriel Basic Casio
>>> Give me a click Brother
>>> Random Youtube Video
Citer : Posté le 07/07/2016 18:05 | # |
Fichier joint
Alors voici. J'ai décidé de réécrire le lecteur de string (enfin, de chaînes) sur le modèle de remiweb qui m'a bien aidé
Voici le code :
{E9→List 2
"01020100012010212221"→Str 2
For 1→K To 3
StrMid("123",K,1→Str 1
1→N : StrSrc(Str 2,Str 1,N→A
If A
Then Prog "SPRITE"
Do
A+1→N
1+MOD(A-1,5→X
1+Int ((A-1)/5→Y
Augment(List 2,List 1+5(X+[b]i[/b]Y→List 2
Augment(List 2,E9→List 2
StrSrc(Str 2,Str 1,N→A
LpWhile A
IfEnd
Next
Dim List 2→Tθmax
Graph(X,Y)=(ReP List 2[T],ImP List 2[T
En essayant de bien optimiser.
Voici le sous-programme SPRITE
K=1⇒{1,5,5,1}+[b]i[/b]{1,1,5,1→List 1 // un petit triangle :E
K=2⇒{1,5,5,1,1}+[b]i[/b]{1,1,5,5,1→List 1 // Un petit carré :E
Au final, j'ai lancé le programme avec les sprites 0 = vide, 1 = Triangle et 2 = Carré. Le programme me semble rapide et affiche ceci comme résultat. Satisfaction personnelle, je vais pouvoir dessiner de belles maps ! 8)
Ajouté le 07/07/2016 à 18:12 :
Au final, le lecteur de map en lui-même ne pèse que 220 octets ! Une map s'écrivant avec 66 caractères dans une Str, elle ne prendra que 70 octets dans le code. Donc on arrive à 70 octets/Map
Il ne reste qu'à remplir les sprites, c'est ce qui va prendre un peu plus de place. Mais franchement, 'chuis heureux
Citer : Posté le 07/07/2016 18:12 | #
Tu peux te passer du N, j'ai édité mon code entre temps
Citer : Posté le 07/07/2016 19:01 | #
Eh bien, les amis, cette technique est une véritable avancée ! Je sens qu'on tient du bon, là ! Owi, du bon de chez bon !
Maintenant, la question des maps et des tiles est réglée, je tenais d'ailleurs à remercier Remiweb parce que là, je n'aurais sans doute pas eu de résultat aussi fin sans son intervention.
Affaire classée !
Maintenant, je pense qu'on peut s'attaquer à... *Regarde ses papiers*
L'agencement des maps entre elles. Alors, ce que je projette de faire : chaque map aura un numéro qui lui est attribué.
Admettons que j'ai un total de 20 maps réparties en carré en 5*4 (5 maps de long sur 4 de large).
On aurait donc quelque chose comme cela :
1 2 3 4 5
6 7 8 9 10
11 12 13 14 15
16 17 18 19 20
Mettons que je sois sur la map 8. Sur je vais sur le bord gauche de l'écran (s'il n'y a pas d'obstacle). Je retire donc 1 à la variable qui contient le numéro de la map. Si je vais à droite, je rajoute 1 pour me retrouver sur la map 9.
En haut, je retire 5 (la largeur de la carte mondiale) 8-5 = map 3
En bas, je rajoute 5 (de même) 8+5 = map 13
Qu'en pensez-vous ?
Citer : Posté le 07/07/2016 19:06 | #
Qu'en pensez-vous ?
Tu risques pas de rentrer dans les maisons avec ça.
Citer : Posté le 07/07/2016 19:15 | #
M'en branle des maisonsEt que dis-tu d'une carte "parallèle" dont l'ID se situe sur la partie imaginaire de la variable qui fait correspondre la map (appelons cette variable M).
Ainsi, sur la map 8, M=8+0i.
Lorsque je rentre dans une maison ou pénètre un sous-sol sur cette map-ci, M prend alors la valeur 8+8i !
Si je me déplace au sous-sol, techniquement, la map qui se tient au dessus de ma quête change également.
si je passe au sous-sol 7, M prend donc la valeur 7+7i.
L'inconvénient est qu'il ne peut y avoir deux sous-sols ou donjon ou salles qui se superposent.
Citer : Posté le 07/07/2016 19:20 | #
je tenais d'ailleurs à remercier Remiweb parce que là, je n'aurais sans doute pas eu de résultat aussi fin sans son intervention.
Mais avec grand plaisir
Sinon pourquoi faire un système aussi compliqué ?
Personnellement j'avais aussi des coordonnées pour la position sur la map.
Quand tu sors à droite X+1, à gauche X-1 etc...
Pour les maisons c'était juste des bouts de map en X>20
Citer : Posté le 07/07/2016 19:26 | #
Et que dis-tu d'une carte "parallèle" dont l'ID se situe sur la partie imaginaire de la variable qui fait correspondre la map (appelons cette variable M).
Ça me semble un peu restrictif... en temps normal je t'aurais dit d'ajouter une seconde map contenant les infos de téléportation pour chacune des cases mais ça dépasse le cadre du Basic
Sinon pourquoi faire un système aussi compliqué ?
Personnellement j'avais aussi des coordonnées pour la position sur la map.
Quand tu sors à droite X+1, à gauche X-1 etc...
Dans ce cas, tu as une map mondiale... et tu ne peux rentrer nulle part. Je me trompe ?
Citer : Posté le 07/07/2016 19:29 | #
tu ne peux rentrer nulle part. Je me trompe ?
Oui
Plus sérieusement tu ne m'as pas laissé le temps d'éditer
C'est ce que j'ai utilisé pour Zelda et ça marche parfaitement.
Les maisons sont juste sur un bout de carte fermé qui se trouve un peu plus loin, mais tout est sur la même map !
Ajouté le 07/07/2016 à 19:31 :
J'avais une tile spéciale qui permet de TP à un endroit quand on marche dessus.
J'en plaçait une à l'entrée des maisons pour TP sur ce bout de carte isolé.
Du coup j'avais des coordonnées X,Y pour la position dans un écran et I,J pour savoir sur quel écran on se trouve.
Quand tu rentres dans une maison ça te TP loin en I=50 et J=1 par exemple. Et j'adapte X et Y pour que ça colle avec l'entrée de la pièce...
Citer : Posté le 07/07/2016 19:49 | #
Donc si je comprends bien, Remiweb, ton personnage a deux types de coordonnées :
Les coordonnées sur la map (X ; Y)
et les coordonnées "mondiales", c'est-à-dire qui indiquent sur quelle map on se trouve !
C'est cela ?
Citer : Posté le 07/07/2016 19:52 | #
Tout à fait !
Quand tu sors par le haut d'un écran par exemple : tu augmentes la coordonné Y mondiale, et tu replaces le joueur en bas de l'écran avec sa deuxième coordonné Y d'écran.
Ajouté le 07/07/2016 à 20:40 :
Ah j'oubliais, le "Augment(List 2,{E9" est à éviter.
J'avais fait le test pour Zelda, il s'avère que ça ralenti pas mal le chargement. D'autant plus qu'on met tout dans une liste qui devient assez longue.
Ça se joue à un peu moins d'une seconde si je me souviens bien, mais sur trois secondes de chargement ça se ressent.
J'avais préféré perdre quelques octets en rajoutant un E9 à la fin de chaque liste que d'avoir ça
Citer : Posté le 07/07/2016 20:42 | #
J'avais une tile spéciale qui permet de TP à un endroit quand on marche dessus.
J'en plaçait une à l'entrée des maisons pour TP sur ce bout de carte isolé.
Ah ben tu as utilisé ma solution alors ! Sans ça, je ne vois pas comment tu pouvais réaliser ce tour de passe-passe sur la map...
Citer : Posté le 07/07/2016 20:47 | #
Ah j'oubliais, le "Augment(List 2,{E9" est à éviter.
Ah bon... Je vais suivre ton conseil. Si ça accélère encore plus le chargement, tant mieux ! je prends !
Je vais commencer dès ce soir les tiles et commencer à pondre quelques maps !
Citer : Posté le 07/07/2016 20:48 | #
Au temps pour moi alors, je suis sur mon portable et j'avais un peu lu entre les lignes avec ses histoires de secondes map.
Sinon ça y'est Drak, j'ai retrouvé pourquoi j'avais pas utilisé les Str pour stocker les maps
C'était pour pouvoir rajouter des propriétés aux tiles. Par exemple les coordonnées d'un TP, le contenu d'un coffre, l'ID du texte à charger pour un panneau...
Ajouté le 07/07/2016 à 20:49 :
Pour le Augment je viens de faire le test avec la map que tu as utilisé au dessus.
Je gagne environ 1 seconde sur les 3.5 de chargement
Ajouté le 07/07/2016 à 21:33 :
Vite fait pour comparer :
Même si ils ont la même apparence j'ai légèrement changé les sprites des tiles pour qu'ils soient tracés en 10 traits, ce qui explique le temps d'affichage (c'est plus proche de ce que tu auras réellement en jeu).
Citer : Posté le 07/07/2016 21:35 | #
Pas mal, ça charge plutôt vite je trouve.
- Kirby's DreamLand : Gobe , Gobe , Gobe !!!
- L'invasion Seanchans : Détruit la flotte ennemis a bord du "Danseur des vagues".
Citer : Posté le 07/07/2016 23:14 | # |
Fichier joint
Justement, que devrais-je faire entre insérer à la fin de mon programme SPRITE la commande :
Et ajouter "E9" à la fin de chaque sprite ? Je parle en terme de rapidité d'exécution.
Sinon, je viens de faire quelques sprites et des screens. Voici une première map faite à l'arrache avec des arbres, des zolies fleurs et des rochers (pour les roches, j'y suis allé un peu au hasard, puis j'ai obtenu un truc cool
Citer : Posté le 07/07/2016 23:17 | # |
Fichier joint
Voici une autre map avec un bôôô fleuve qui m'a pris du temps à faire !
@Fife : merci bien
Citer : Posté le 07/07/2016 23:30 | #
Pas bête la commande, a toi de tester par contre
C'est top avec le fleuve !
C'est pas trop long à charger avec toutes ces tiles ?