Salut !
On se retrouve pour la 215ème édition de notre fabuleuse Revue des Projets. Beaucoup de choses à dire ce soir, alors commençons sans plus tarder .
Qui de mieux que KikooDX pour démarrer cette revue ? Sur un projet intéressant comme à son habitude !
En effet, KikooDX a décidé de simplifier le Basic Casio en fabriquant un convertisseur ASM - Basic. Parce que pourquoi pas ?
En plus de cela, le prototype est fonctionnel. KikooDX nous donne d'ailleurs la liste des instructions de son nouveau langage bcasm. Voici d'ailleurs la liste en question :
#include
NOP
MOV
ADD
SUB
MUL
DIV
NEG
LBL
JMP
JEZ
JNZ
JMZ
JLZ
CLS
DSP
LOC
L'idée peut sembler étrange, mais le Basic étant un langage Turing-complet, KikooDX peut théoriquement pousser son langage n'importe où. Un choix compréhensible vu la syntaxe très simple de l'ASM !
Cela reste cependant un bon effort, et laisse peut-être envisager un convertisseur directement sur calculatrice dans le futur ?
Continuons dans notre bonne lancée en parlant d'Asci le moteur RPG python de Shadow15510. Nous en avions déjà parlé dans la précédente revue et Shadow continue sans cesse d'améliorer son moteur permettant à présent de faire des choses de plus en plus qualitatives !
Shadow nous parle de sa dernière version et des modifications qu'il a rajoutées. Ayant refondu entièrement le système d'évènements, Shadow a su rendre ce moteur plus "portable" et pratique pour les programmeurs ! Cette nouvelle version possède de nombreux avantages que l'homme en rouge nous cite dans son message :
Shadow a écrit : Cette nouvelle version est plus légère que la précédente avec 300 octets de gagné Plus besoin de déclarer une fonction avec un def ... pass parce que le moteur voulait une fonction dont vous n'avez pas l'utilité pour votre projet : économisez de la place au sein de vos jeux. Le code est plus aéré : si vous avez beaucoup d'évènements dans des circonstances différentes, vous pouvez séparer les cas plus simplement. si les noms des fonctions sont bien choisis, le code devient extrêmement clair : evenements : {"*": pnj, "?": point_interet} avec pnj et point_interet des fonctions. De même pour les touches : touches = {7: affichage_stat, 8: inventaire} le mapping apparaît explicitement. Comme dans la version précédente vous pouvez faire correspondre plusieurs symboles à la même fonction évènementielle. Par exemple si mes PnJ sont des * ou des ?, je peux écrire : evenements = {"*?": pnj}
Nouvelle version implique une nouvelle documentation ! Et Shadow n'a pas manqué à la règle en la mettant à jour entièrement ainsi que les exemples de code
En tout cas, c'est un projet rondement mené ! Nous avons hâte de voir ce que ça va donner dans le futur. En attendant Shadow a sorti le premier jeu utilisant son moteur : Rinastica je vous conseille d'aller voir
Vous pouvez suivre le développement directement sur le gitea du projet
Bravo Shadow pour ta détermination et ton engagement sur le python calculatrice ! Ce n'est pas simple mais il a des capacités impressionnantes comme tu arrives à nous le montrer !
En parlant moteur de jeu parlons à présent de ???. Si si vous savez, mon jeu sans nom et avec le tileset de Pokémon
Eh bien depuis la dernière fois grâce à KikooDX, j'ai pu retravailler la caméra ainsi que des petits détails liés aux dialogues avec les personnages.
LE truc intéressant, j'ai enfin implémenté l'intérieur des maisons ! Si vous trouviez la ressemblance avec Pokémon frappante, vous n'allez pas être déçu en voyant ces screens issus directement du jeu en développement !
Ah oui c'est VRAIMENT pokémon maintenant
Initialement je souhaitais générer l'intérieur directement afin d'avoir des maisons toutes différentes. Finalement j'ai opté pour un intérieur défini aléatoirement parmi une liste que j'ai créée. Les maisons possèdent donc un intérieur assigné aléatoirement
Avec la rentrée je ne sais pas si je vais pouvoir continuer à développer fréquemment sur ce projet, je suis déjà content d'être arrivé jusque-là !
Vous voyez, d'un côté nous avons moi qui développe doucement. Et de l'autre Lephenixnoir et Massena qui sortent d'un coup une vidéo d'un jeu en cours de développement.
Du doux nom de Rogue Life, votre objectif est simple : tabasser des monstres dans une ruelle. Qui n'a jamais rêvé de ça ?
Mais attention, le jeu est divisé en plusieurs arènes indépendantes avec un certain nombre de vagues de monstres à abattre cruellement. Votre objectif en tant qu'aventurier intrépide : survivre !
Cependant vous perdez votre équipement à chaque début d'arène. De manière aléatoire (ou pas) vous allez avoir des drops d'armes et armures venant des monstres que vous lacérez sans aucune pitié. Votre équipement a un impact certain sur l'arène en cours. Entre défense en plus, une vitesse améliorée ou encore des combos supplémentaires vous devrez être sûr de choisir le bon équipement !
Et ce défouloir vient avec une vidéo ! Décidément c'est Noël aujourd’hui !
Honnêtement, sur une calculatrice vous imaginez vraiment ce genre de jeu ?
C'est vraiment magnifique. La vidéo est fluide et les petits détails et animations ne manquent pas ! Le travail graphique derrière est incroyable. Vous êtes vraiment un bon duo ensemble !
Lephenixnoir nous donne également quelques pourcentages de l'avancement du projet. Il reste encore du travail mais ça semble déjà bien avancé ! Regardez par vous-même :
Nous avons eu Lephenixnoir en duo. Maintenant il nous faut Lephenixnoir en solo ! En effet, le développement de TLT continue. Et dans un message technique, Lephenixnoir nous propose d'observer ses optimisations grandioses pour faire tourner son jeu sur nos chères calculatrices.
Pour faire simple : Ça va plus vite maintenant.
Pour faire compliqué : il n'est pas satisfait des performances de ce qu'on appelle la VRAM (permettant entre autres de dessiner à l'écran facilement). Donc Monsieur Lephenixnoir préfère utiliser la XRAM. Une mémoire beaucoup plus petite mais largement plus rapide.
Évidemment par problème de taille il ne peut pas utiliser les mêmes méthodes de rendu (sinon ça serait trop simple). En effet, notre magicien des calculatrices effectue un rendu par fragments qui consiste à dessiner les premières lignes dans la XRAM, les envoyer à l'écran et ainsi de suite jusqu'à l'affichage de l'écran entier.
Ce système n'est pas nouveau, il est en effet inspiré d'OpenGL reposant sur ces grandes étapes :
D'abord on génère un ensemble de commandes mais sans rien dessiner. Chaque commande indique une opération de dessin (donnée par un numéro de shader) et le fragment sur lequel la faire. Si on veut dessiner quelque chose qui croise plusieurs fragments, on génère une commande par fragment concerné.
Une fois que tout ça est fait, on fait un tri stable sur les commandes en ordonnant par numéro de fragment.
Ensuite, on lance le rendu ; les commandes sont lues dans l'ordre, les fragments sont dessinés et envoyés à l'écran les uns après les autres.
Pour l'instant, il a programmé deux shaders :
Un shader AZRP_SHADER_CLEAR qui efface la totalité de l'écran avec une couleur (comme dclear()).
Un shader AZRP_SHADER_TEX2D qui affiche des images (comme dsubimage()).
Comme il l'explique dans son message initial :
Décidement, Lephe est trop fort a écrit : le terme «shader» est un peu arrogant, mais l'architecture ressemble quand même pas mal à OpenGL, et je pense pouvoir faire des vrais effets de couleur, lumière, et autres graphismes assez forts avec ce système, donc je prends le pari.
Nous sommes dans un monde où l'on parle de jeu de lumières sur calculatrice. C'est assez dingue quand même !
Lephe nous montre même son écran de test actuel. Autant de travail pour voir 5 arbres non détourés. (Je rigole évidemment, il s'agit d'un écran de test pour obtenir les valeurs qui suivent : )
Mais ce qui est intéressant ce n'est pas l'écran en lui-même mais plutôt le temps qu'il prend à s'afficher. Et vous allez voir c'est ahurissant !
Command generation: 235 us
Frame rendering: 2060 us
Sorting: 1179 us
Shaders: 773 us
Overhead: 108 us
R61524 transfer: 7.686 ms
Ce qui est important dans cette optimisation c'est de voir les performances avant et après.
La dernière ligne correspond au temps de transfert à l'écran. Concrètement la méthode habituelle avec la VRAM prend 11ms. Ce qui signifie qu'avant même de dessiner plus vite (nous allons y venir), Lephe gagne environ 4ms sur cette étape. Je reprends son expression :
Lephe, toujours lui a écrit : Sachant qu'un frame c'est 33 ms (30 FPS) ou 17 ms (60 FPS), on ne crache clairement pas dessus.
L'avantage réel de cette méthode provient sur le temps de rendu (de dessin). Ici il s'agit de la catégorie Frame rendering.
Le temps d'exécution des shaders est de juste 773 µs. C'est franchement pas mal, surtout quand on sait qu'il y a 400 µs pour effacer l'écran et donc seulement ~350 µs pour afficher les images. Les chiffres paraissent abstraits comme ça, mais l'effacement de l'écran est 6 fois plus rapide que dclear() ! Pour l'instant Lephe n'a optimisé que l'écriture. Les effets purement calculatoires sont donc beaucoup plus rapides. Un exemple rapide, pour assombrir l'écran en temps normal ça prend ~12 ms. Ici c'est à peine 1 ms, c'est juste une performance incroyable grâce à l'architecture particulière de son programme.
Lorsque nous faisons le total, nous tombons à 9.981 ms ! Tout juste en dessous des 10, ce qui signifie simplement que... cette scène est affichée à environ 102 FPS ! Des performances que mon ordinateur n'a pas !
Vraiment un grand bravo, je sens que nous allons encore en entendre parler longtemps de ce TLT ! Nous avons tous hâte de voir les premières images de gameplay Bon courage pour la suite du développement, prochaine étape l'optimisation en lecture ?
Je vous conseille vivement d'aller voir le message original disponible en suivant le lien suivant :
Ça c'est de la RDP ! Props rien que pour le boulot, on sait que le nouveau format est plus demandeur alors là... !
Bien joué encore plus pour le résumé du post sur TLT ! Je réalise que ces machins-là sont vraiment compliqués, promis la prochaine fois je ferai un résumé RDP-friendly. x)
Tu t'en sors parfaitement cela dit, toutes les idées importantes sont là et bien dans le contexte. Je n'ai que deux choses à préciser :
La VRAM n'est pas une mémoire particulière, c'est juste un gros bloc dans la RAM principale, donc la discussion c'est vraiment RAM principale vs. XRAM. (Même si le nom "VRAM" ressemble beaucoup à "XRAM", c'est assez différent.)
Quand je dis que j'ai optimisé l'écriture, c'est parce que les images sont toujours stockées comme avant. Donc même si l'écriture en XRAM est rapide la lecture dans images dans la ROM/RAM prend quand même du temps (possiblement beaucoup en comparaison).
En tous cas, ça fait plaisir de coder des jeux de temps en temps, et franchement merci pour tout le travail qui est fait sur le site. C'est beaucoup plus sympa de travailler en équipe et beaucoup moins stressant de jouer quand il y a moins de choses à gérer en parallèle.
Tituya tu vises toujours de poster 666 news c'était bien ça le chiffre right?
Sinon est-ce que tu as une vision particulière pour les mécaniques dans ton jeu ? Tu décris un "Aventura-like" mais je suppose que ce ne sera pas un calque pur du jeu de Drak. Un RPG classique dans le style Final Fantasy/Dragon Quest avec des combats séparés, ou peut-être quelque chose de plus dans le style Zelda avec des interactions sur la carte ?
Asci a l'air assez poli maintenant, tout ce qu'on entend donne envie. Ça me donne bien envie de tester quelque chose !
La Revue des Projets ne fonctionne pas comme ça. C'est à toi de préciser que tu veux apparaître dans la Revue en mettant un @RDP dans ton topic / message. Mais les Rédacteurs ne vont pas faire le tour du site pour voir quels projets sont actifs etc.
"Ce n'est pas parce que les chose sont dures que nous ne les faisons pas, c'est parce que nous ne les faisons pas qu'elles sont dures." Sénèque
Les messages/topics sont seulement soumis à la RDP quand ils contiennent "@RDP" (on devrait peut-être le rappeler plus souvent)
(Il faut aussi que ce soit des posts plus récents que la dernière RDP en date, donc modifier des topics plus anciens ne marche pas. Je te conseille de poster un nouveau commentaire pour éviter toutes surprises)
En temps normal je m’arrange pour mettre ce qui est intéressant dans la revue. Celle-là étant particulièrement remplie je ne l’ai pas fait.
Sinon j’aurai dû parler des résultats de la 1KBCJ, de la relance des réseaux sociaux, de ton convertisseur ou encore du concours de rentrée. Je veux bien avoir une grosse revue mais il y a des limites !
Avec le @RDP ton message sera à coup sûr dans la prochaine revue !
Lephe a écrit : Tituya tu vises toujours de poster 666 news c'était bien ça le chiffre right?
Seulement 666 ? je suis déjà à 60, on verra bien si j’ai toujours le temps d’écrire l’année prochaine
Lephe a écrit : est-ce que tu as une vision particulière pour les mécaniques dans ton jeu ?
J’ai toujours été mauvais pour trouver un gameplay. Dans ma tête je souhaitais avoir des monstres à la manière de votre Rogue Life donnant de l’xp permettant d’up ses statistiques d’attaques / défense / pv.
Cependant, avoir des entités "en temps réel" me semble difficile à faire. Je n’exclue donc pas la possibilité des combats en tour par tour avec différentes attaques que le joueur pourrait apprendre en montant de niveaux et en explorant la carte.
Je compte également utiliser la carte comme source d’énigme afin de débloquer des choses Donc plus une sorte de zelda finalement !
Bretagne > Reste du globe
(Et de toute façon, vous pouvez pas dire le contraire)
Tituya a écrit : Je n’exclue donc pas la possibilité des combats en tour par tour avec différentes attaques que le joueur pourrait apprendre en montant de niveaux et en explorant la carte.
Je compte également utiliser la carte comme source d’énigme afin de débloquer des choses Donc plus une sorte de zelda finalement !
Tu es en train de décrire la core loop de Pokéfion Toutouille
Pour Asci, je suis en train de refaire une partie : la gestion des maps pour supporter n niveaux d'imbrications contre 1 seul actuellement. La contrainte était trop forte. Aactuellement on peut mettre une carte du monde et autant de maisons que l'on veut. Tout à l'air de bien se passer…
Maintenant imaginez une carte avec plusieurs mondes parallèles. Dans le système actuel, on peut jouer un peu en se disant "je fait croire au moteur que mes mondes parallèles sont des maisons et ça va bien se passer". Et c'est là que les emmerdes commencent Parce que si on fait comme ça (et c'est actuellement la seule méthode), nos mondes parallèles n'ont tout simplement pas de maisons. On peut torturer un peu le truc en ajoutant des maisons à côtés des mondes parallèles, mais ça ne sera valable que pour la carte principales.
Du coup l'idée c'est de permettre d'avoir "une maison dans une maison" pour pouvoir faire un peu ce qu'on veut. Dans la même veine, j'ai modifié les système data, stat dans le sens où maintenant la liste data est modifiable par effet de bord dans les fonctions de l'utilisateur. Ça implique quelques possibilités marrantes comment téléporter le joueur un peu n'importe sur la carte, lui faire changer de carte, modifier l'XP etc
@RDP
"Ce n'est pas parce que les chose sont dures que nous ne les faisons pas, c'est parce que nous ne les faisons pas qu'elles sont dures." Sénèque
Kikoodx a écrit : Tu es en train de décrire la core loop de Pokéfion Toutouille
Ça peut être très classique et très bon quand même !
Shadow15510 a écrit : Du coup l'idée c'est de permettre d'avoir "une maison dans une maison" pour pouvoir faire un peu ce qu'on veut.
Tu ne peux pas juste avoir plein de maps en vrac et des zones de téléportation sans t'embêter avec l'idée d'une map "dans" une map ? Du genre simplement que toutes les maps soient à côté les unes des autres.
Tu ne peux pas juste avoir plein de maps en vrac et des zones de téléportation sans t'embêter avec l'idée d'une map "dans" une map ? Du genre simplement que toutes les maps soient à côté les unes des autres.
C'est plus ou moins ce que j'ai fait… En gros chaque map (sauf la map principale) à une map "parent" qui est affichée quand on sort. Typiquement, une maison aura pour map parent la carte du monde de lequel est la maison.
Au niveau du programme, les maps sont juste stockées les unes après les autres dans un tuples comme avant le seul truc qui change concrètement, c'est qu'il faut donne l'index de la map parent avec la carte. Je sais pas si c'est très clair ? ^^'
"Ce n'est pas parce que les chose sont dures que nous ne les faisons pas, c'est parce que nous ne les faisons pas qu'elles sont dures." Sénèque
C'est très clair. La seule différence avec le système que j'avais en tête c'est qu'au lieu d'avoir une map "parent" et une case "sortie/retour" on a des cases "envoyer vers la map #i". Mais bon, c'est déjà pas mal comme ça
Euh… "envoyer vers la map #i", il manque nécessairement une indication sur les coordonnées de la case sur laquelle on se retrouve ? Ou alors il faut concevoir les cartes pour tout faire coïncider ?
"Ce n'est pas parce que les chose sont dures que nous ne les faisons pas, c'est parce que nous ne les faisons pas qu'elles sont dures." Sénèque
Oui évidemment c'est "envoyer vers la map #i à la case (x,y)". Mais c'est pareil pour la map parent (ou alors tes maisons ont qu'une entrée et tes sous-dimensions ont qu'une entrée mais c'est con !)
ou alors tes maisons ont qu'une entrée et tes sous-dimensions ont qu'une entrée mais c'est con !
Euh, ben, oui, c'est ça
En fait chaque carte (sauf la carte principale) est un tuple : (r""" ... """, (x_entree, y_entree), (x_sortie, y_sortie), indice_parent).
Quand on arrive sur aux coordonnées (x_entree, y_entree), on se retrouve dans la carte secondaire, aux coordonnées (x_sortie, y_sortie). Et inversement pour sortir.
Mais je crois que j'ai compris comment mettre en place ton système, faut juste que toutes les cartes soit des tuples, et les tuples pour les téléportations soient avec 3 éléments ?
"Ce n'est pas parce que les chose sont dures que nous ne les faisons pas, c'est parce que nous ne les faisons pas qu'elles sont dures." Sénèque
où pour chaque case de transition tu as un tuple qui indique où elle est sur la carte actuelle (x_transition et y_transition), vers quelle map elle mène (indice_map) et à quel endroit de cette map (x_arrivee et y_arrivee). Comme ça on est libre de lier les cartes autrement que par le mécanisme des maisons (et aussi t'as pas besoin de traiter tes cartes différemment).
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
Cette nouvelle version est plus légère que la précédente avec 300 octets de gagné
Citer : Posté le 30/08/2021 02:25 | #
Pour faire simple : Ça va plus vite maintenant.
La France vous remercie pour vos services o/
Edit
Très bonne RDP, bravo Tituya
Citer : Posté le 30/08/2021 02:32 | #
La France vous remercie pour vos services o/
Mais de rien
Je trouve la revue un peu "brouillon" dans l'organisation. Mais bon, comprenez moi il est 2h30 et il y avait beaucoup à écrire
(Et de toute façon, vous pouvez pas dire le contraire)
MultipliCasio
RDM Calculs
Back Mirror
A Switch To The Top C
Citer : Posté le 30/08/2021 09:16 | #
Ça c'est de la RDP ! Props rien que pour le boulot, on sait que le nouveau format est plus demandeur alors là... !
Bien joué encore plus pour le résumé du post sur TLT ! Je réalise que ces machins-là sont vraiment compliqués, promis la prochaine fois je ferai un résumé RDP-friendly. x)
Tu t'en sors parfaitement cela dit, toutes les idées importantes sont là et bien dans le contexte. Je n'ai que deux choses à préciser :
En tous cas, ça fait plaisir de coder des jeux de temps en temps, et franchement merci pour tout le travail qui est fait sur le site. C'est beaucoup plus sympa de travailler en équipe et beaucoup moins stressant de jouer quand il y a moins de choses à gérer en parallèle.
Tituya tu vises toujours de poster 666 news c'était bien ça le chiffre right?
Sinon est-ce que tu as une vision particulière pour les mécaniques dans ton jeu ? Tu décris un "Aventura-like" mais je suppose que ce ne sera pas un calque pur du jeu de Drak. Un RPG classique dans le style Final Fantasy/Dragon Quest avec des combats séparés, ou peut-être quelque chose de plus dans le style Zelda avec des interactions sur la carte ?
Asci a l'air assez poli maintenant, tout ce qu'on entend donne envie. Ça me donne bien envie de tester quelque chose !
Citer : Posté le 30/08/2021 09:40 | #
et mon utilitaire pour convertir les jeux Monochromelib pour graph 35+E II?
Citer : Posté le 30/08/2021 09:42 | #
La Revue des Projets ne fonctionne pas comme ça. C'est à toi de préciser que tu veux apparaître dans la Revue en mettant un @RDP dans ton topic / message. Mais les Rédacteurs ne vont pas faire le tour du site pour voir quels projets sont actifs etc.
Citer : Posté le 30/08/2021 09:43 | #
Les messages/topics sont seulement soumis à la RDP quand ils contiennent "@RDP" (on devrait peut-être le rappeler plus souvent)
(Il faut aussi que ce soit des posts plus récents que la dernière RDP en date, donc modifier des topics plus anciens ne marche pas. Je te conseille de poster un nouveau commentaire pour éviter toutes surprises)
Citer : Posté le 30/08/2021 11:51 | #
En temps normal je m’arrange pour mettre ce qui est intéressant dans la revue. Celle-là étant particulièrement remplie je ne l’ai pas fait.
Sinon j’aurai dû parler des résultats de la 1KBCJ, de la relance des réseaux sociaux, de ton convertisseur ou encore du concours de rentrée. Je veux bien avoir une grosse revue mais il y a des limites !
Avec le @RDP ton message sera à coup sûr dans la prochaine revue !
Tituya tu vises toujours de poster 666 news c'était bien ça le chiffre right?
Seulement 666 ?
est-ce que tu as une vision particulière pour les mécaniques dans ton jeu ?
J’ai toujours été mauvais pour trouver un gameplay. Dans ma tête je souhaitais avoir des monstres à la manière de votre Rogue Life donnant de l’xp permettant d’up ses statistiques d’attaques / défense / pv.
Cependant, avoir des entités "en temps réel" me semble difficile à faire. Je n’exclue donc pas la possibilité des combats en tour par tour avec différentes attaques que le joueur pourrait apprendre en montant de niveaux et en explorant la carte.
Je compte également utiliser la carte comme source d’énigme afin de débloquer des choses
(Et de toute façon, vous pouvez pas dire le contraire)
MultipliCasio
RDM Calculs
Back Mirror
A Switch To The Top C
Citer : Posté le 30/08/2021 13:15 | #
Je n’exclue donc pas la possibilité des combats en tour par tour avec différentes attaques que le joueur pourrait apprendre en montant de niveaux et en explorant la carte.
Je compte également utiliser la carte comme source d’énigme afin de débloquer des choses Donc plus une sorte de zelda finalement !
Tu es en train de décrire la core loop de Pokéfion Toutouille
Citer : Posté le 30/08/2021 14:35 | #
Très belle revue !
Pour Asci, je suis en train de refaire une partie : la gestion des maps pour supporter n niveaux d'imbrications contre 1 seul actuellement. La contrainte était trop forte. Aactuellement on peut mettre une carte du monde et autant de maisons que l'on veut. Tout à l'air de bien se passer…
Maintenant imaginez une carte avec plusieurs mondes parallèles. Dans le système actuel, on peut jouer un peu en se disant "je fait croire au moteur que mes mondes parallèles sont des maisons et ça va bien se passer". Et c'est là que les emmerdes commencent
Du coup l'idée c'est de permettre d'avoir "une maison dans une maison" pour pouvoir faire un peu ce qu'on veut.
@RDP
Citer : Posté le 30/08/2021 15:53 | #
Tu es en train de décrire la core loop de Pokéfion Toutouille
Ça peut être très classique et très bon quand même !
Du coup l'idée c'est de permettre d'avoir "une maison dans une maison" pour pouvoir faire un peu ce qu'on veut.
Tu ne peux pas juste avoir plein de maps en vrac et des zones de téléportation sans t'embêter avec l'idée d'une map "dans" une map ? Du genre simplement que toutes les maps soient à côté les unes des autres.
Citer : Posté le 30/08/2021 15:57 | #
C'est plus ou moins ce que j'ai fait… En gros chaque map (sauf la map principale) à une map "parent" qui est affichée quand on sort. Typiquement, une maison aura pour map parent la carte du monde de lequel est la maison.
Au niveau du programme, les maps sont juste stockées les unes après les autres dans un tuples comme avant
Citer : Posté le 30/08/2021 16:01 | #
C'est très clair. La seule différence avec le système que j'avais en tête c'est qu'au lieu d'avoir une map "parent" et une case "sortie/retour" on a des cases "envoyer vers la map #i". Mais bon, c'est déjà pas mal comme ça
Citer : Posté le 30/08/2021 16:03 | #
Euh… "envoyer vers la map #i", il manque nécessairement une indication sur les coordonnées de la case sur laquelle on se retrouve ? Ou alors il faut concevoir les cartes pour tout faire coïncider ?
Citer : Posté le 30/08/2021 16:04 | #
Oui évidemment c'est "envoyer vers la map #i à la case (x,y)". Mais c'est pareil pour la map parent (ou alors tes maisons ont qu'une entrée et tes sous-dimensions ont qu'une entrée mais c'est con !)
Citer : Posté le 30/08/2021 16:11 | #
Euh, ben, oui, c'est ça
En fait chaque carte (sauf la carte principale) est un tuple : (r""" ... """, (x_entree, y_entree), (x_sortie, y_sortie), indice_parent).
Quand on arrive sur aux coordonnées (x_entree, y_entree), on se retrouve dans la carte secondaire, aux coordonnées (x_sortie, y_sortie). Et inversement pour sortir.
Mais je crois que j'ai compris comment mettre en place ton système, faut juste que toutes les cartes soit des tuples, et les tuples pour les téléportations soient avec 3 éléments ?
Citer : Posté le 30/08/2021 16:15 | #
Hmm je vois, c'est juste un peu dommage. Pour mon système, toutes les cartes (y compris la principale) seraient des tuples comme ça :
[ (x_transition, y_transition, indice_map, x_arrivee, y_arrivee),
(x_transition, y_transition, indice_map, x_arrivee, y_arrivee),
# etc
])
où pour chaque case de transition tu as un tuple qui indique où elle est sur la carte actuelle (x_transition et y_transition), vers quelle map elle mène (indice_map) et à quel endroit de cette map (x_arrivee et y_arrivee). Comme ça on est libre de lier les cartes autrement que par le mécanisme des maisons (et aussi t'as pas besoin de traiter tes cartes différemment).
Citer : Posté le 30/08/2021 16:16 | #
Ouaip, je vais essayer de faire ça !
Merci pour l'idée