Bonjour,

Je fais un jeu en SFML avec des niveau dans des fichier présenter de cette facon :

14
15
0 0 0 0 8 0 0 5 0 6 0 0 0 0 0
4 0 0 1 1 1 1 1 0 1 0 0 1 1 1
1 1 0 0 0 0 3 0 0 3 0 4 0 0 0
6 6 4 0 0 0 1 0 1 1 1 1 0 0 0
1 1 1 1 2 0 0 0 0 0 1 0 6 6 6
0 0 9 1 0 0 5 0 7 0 1 0 0 4 0
1 1 1 1 1 0 1 0 1 1 1 1 1 1 1
0 0 0 0 3 0 0 0 0 0 0 1 0 0 1
7 0 0 0 2 6 6 6 0 7 0 1 0 0 1
1 0 0 0 0 0 0 4 0 1 1 1 1 1 1
0 1 0 1 1 1 1 1 1 1 0 1 0 0 0
0 0 0 0 0 1 0 0 0 1 0 1 0 0 0
0 0 1 0 0 0 0 3 0 1 0 1 0 0 0
6 6 1 1 1 1 1 1 1 1 0 1 0 0 0

14 et 15 c'est les dimensions

puis il y a une second map pour les portal :

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 1 0 0 2 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 2 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 1 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

j'aimerai savoir s'il y a un outil pour créer mes map sans passé par les fichier mais par une interface graphiques

Merci

Salut,

Tu peux te créer un éditeur de cartes/maps avec la sfml, c'est plus simple que tu ne le pense à faire. Tu aura besoin notamment des proriétées suivantes:

- Une texture affichée dans l'interface graphique représentant la texture actuelle à appliquer (un genre de vignette) dans un panneau à coté de l'affichage de ta carte/map.

- Récupérer les infos souris (position et clic(s) bouton(s) ) pour savoir quand et où appliquer la texture sur la map (d'ailleurs tu devras avoir une variable ('unsigned int') représentant l' index du tableau de textures qui te permet d' afficher la vignette de la texture à coller en cours, ce qui te permet de modifier ta carte/map avec cet unsigned int).

- Afficher la map avec les textures rattachées à celle ci (rien de bien compliqué, c'est le même système que dans ton jeu).

Warren79 a écrit:

Salut,

Tu peux te créer un éditeur de cartes/maps avec la sfml, c'est plus simple que tu ne le pense à faire. Tu aura besoin notamment des proriétées suivantes:

- Une texture affichée dans l'interface graphique représentant la texture actuelle à appliquer (un genre de vignette) dans un panneau à coté de l'affichage de ta carte/map.

- Récupérer les infos souris (position et clic(s) bouton(s) ) pour savoir quand et où appliquer la texture sur la map (d'ailleurs tu devras avoir une variable ('unsigned int') représentant l' index du tableau de textures qui te permet d' afficher la vignette de la texture à coller en cours, ce qui te permet de modifier ta carte/map avec cet unsigned int).

- Afficher la map avec les textures rattachées à celle ci (rien de bien compliqué, c'est le même système que dans ton jeu).

Non ,c'est peut etre "easy" mais tu aura un éditeur de map assez limité ,  il existe un excellent éditeur de map : Tiled
https://www.mapeditor.org/

Merci je vais tester vos technique

Warren79 c'est justement ce que je c'est pas faire je débute

sinon il y aurrai pas un moyen facile dans un autre langages car j'ai pas envie de tarder sur ca

-
Edité par PLLX76 2 avril 2022 à 13:47:54

HelbaSama a écrit:

Non ,c'est peut etre "easy" mais tu aura un éditeur de map assez limité ,  il existe un excellent éditeur de map : Tiled
https://www.mapeditor.org/

Ca devient limité également lorsque l' on utilise un logiciel non conçu par ses propres soins, on est limité à l' imagination du créateur du logiciel tiers à un moment donné. Personnellement je créé mon propre éditeur de niveaux/cartes lorsque je créé un nouveau jeu et je décide comment sont encodées les données de mon jeu (j'ai le contrôle sur à peu près tout , même si je suis limité à la SDL 2 comme bibliothèque). Et créer ses propres logiciels est formateur dans le langage choisi. Du coup je ne comprends pas quand tu dis:

"mais tu auras un éditeur de map assez limité"

La limite sera la seule imagination de @PLLX76 de mon point de vue mais c'est vrai aussi de ses compétences dans le langage choisi. Après si le but de PLLX76, est de créer un jeu pourquoi pas, mais s' il a envie de monter en compétence dans le C++ il a tout intérêt à coder ses outils lui-même et à poser des questions sur ce forum ou d'autres consacrés à la programmation pour recevoir des avis de développeurs professionnels/avertis ce qui permet de bien s' améliorer.

-
Edité par Warren79 2 avril 2022 à 16:22:08

Warren79 a écrit:

HelbaSama a écrit:

Non ,c'est peut etre "easy" mais tu aura un éditeur de map assez limité ,  il existe un excellent éditeur de map : Tiled
https://www.mapeditor.org/

Ca devient limité également lorsque l' on utilise un logiciel non conçu par ses propres soins, on est limité à l' imagination du créateur du logiciel tiers à un moment donné. Personnellement je créé mon propre éditeur de niveaux/cartes lorsque je créé un nouveau jeu et je décide comment sont encodées les données de mon jeu (j'ai le contrôle sur à peu près tout , même si je suis limité à la SDL 2 comme bibliothèque). Et créer ses propres logiciels est formateur dans le langage choisi. Du coup je ne comprends pas quand tu dis:

"mais tu auras un éditeur de map assez limité"

La limite sera la seule imagination de @PLLX76 de mon point de vue mais c'est vrai aussi de ses compétences dans le langage choisi. Après si le but de PLLX76, est de créer un jeu pourquoi pas, mais s' il a envie de monter en compétence dans le C++ il a tout intérêt à coder ses outils lui-même et à poser des questions sur ce forum ou d'autres consacrés à la programmation pour recevoir des avis de développeurs professionnels/avertis ce qui permet de bien s' améliorer.

-
Edité par Warren79 il y a environ 1 heure

Euh , tu n'es pas obligé d'utilisé le XML comme encodage, je code pour des vielles consoles, tu crois que ma Super Nes pourrais lire du XML ? x)
Je lis du XML et je l'encode à ma façon (souvent je compresse mes map avec du RLE), c'est beaucoup plus rapide que de faire un éditeur de map avancé.

" il a tout intérêt à coder ses outils lui-même"
Evidament quand tu créer un jeu tu recode paint, tu recode ton format fichier , tu recode un tracker et j'y passe...

Les seuls outils que je recode sont les outils qui n'existe pas tout simplement.

Et Tiled est largement suffisant pour la plupart des besoins et probablement bien plus avancé que ton éditeur ou de ce que le PO pourra codé

-
Edité par HelbaSama 2 avril 2022 à 18:44:28

>> Tu peux te créer un éditeur de cartes/maps avec la sfml, c'est plus simple que tu ne le pense à faire. Tu aura besoin notamment des proriétées suivantes:

Développer, c'est aussi ne pas perdre de temps et d'énergie en réinventant la roue.
S'il existe des outils prêts à l'emplois, utilises les.

Salut,

Je crois que, sur ce point comme tant d'autres, il y a "à boire et à  manger", et que tout va finalement dépendre des objectifs réels du PO.

Bien sur, si l'éditeur de map n'est qu'un outil, que l'on veut "efficace" le plus vite possible pour "avoir cela hors des pattes" et dont le gros du travail se limite à ... apprendre comment intégrer ces maps à notre projet, il serait sans doute très dommage de ne pas s'orienter vers un "programme tout fait", même s'il ne correspond pas ** tout à fait ** aux besoins du PO.

D'un autre coté, si l'idée de base est de profiter de toutes les occasions pour monter en compétences, que ce soit en termes de conception ou en termes d'un langage spécifique (le C++, qui plus est, dans le cas présent), ben, il est peut être "pas si mal" d'envisager de "plonger les mains dans le cambouis", qu'en pensez vous?

Il n'y a d'ailleurs même pas forcément besoin, dans la deuxième situation, d'aller jusqu'à recréer un format d'image / de description de map personnel

Mieux encore, il s'agit typiquement d'une décision qui peut tout à fait être remise à l'étude "plus tard" durant le développement du projet

Et ce dans les deux sens:

• soit, après avoir appris un maximum grâce à ce sous-projet, on peut très bien décidé d'utiliser un outil "tout fait"
• soit, on se rend compte au fil du temps que  l'outil "tout fait" présente "quelques lacunes", et l'on décide donc de lancer le développement d'un outil perso, mieux adapté à nos besoins

L'éternel débat entre vaut il mieux apprendre à utiliser un outil existant ou utiliser son propre outil

Alors pour ce cas la, je dirais que c'est tellement pénible à faire un éditeur de map que je comprends qu'on en utilise un tout fait.

Après, moi je suis du genre à me programmer mes outils sur mesure.

Je comparerais ça aux meubles. Vaut il savoir couper ses planches tout seul, ou bien acheter des meubles en kit Ikea. Il est évident qu'avec les meubles Ikea, tu as beaucoup plus vite un résultat. 

Maintenant, on dit souvent "il ne faut pas réinventer la roue", j'entends bien. Et il a ici plein de gens qui aiment utiliser des outils tout faits mais maîtrisent quand même le bas niveau car ils ont un bagage de programmeurs derrière eux. Pas de soucis avec eux.

Ceux qui me posent davantage de soucis, ce sont les gens qui n'ont aucune idée de comment la roue marche...

Parfois dans le monde professionnel, je rencontre non pas des programmeurs, mais des "utilisateurs  d'API". Ils n'ont aucune idée de ce qu'il se passe en bas niveau, assemblent du code... (enfin je mettrais limite le mot "script") sans trop optimiser, et obtiennent des programmes lents. Et si jamais ça bug, alors la c'est la fin des haricots.

Quoiqu'il en soit, c'est un autre métier, "utilisateurs d'API", il  ne faut pas que ça sorte des clous sinon ils sont perdus. 

Et je trouve qu'il y a de moins en moins de programmeurs, et de plus en plus d'utilisateurs d'API.

-
Edité par Fvirtman 4 avril 2022 à 16:54:38

On va filer la métaphore.

Si on est débutant, qu'on n'a pas les connaissances ni les outils, et que l'on choisit de réinventer la roue, alors tu vas poser ton cul par terre pendant des mois, le temps de réussir à fabriquer ta table, tes chaises, ton lit, etc. Et tes premiers essais seront tous moisis, parce que tu ne sais pas à quoi ressemble une table correcte, ni une chaise.

Et puis, si ton boulot n'est pas de fabriquer des meubles, mais par exemple d'élever des pokémons. Alors tu ne veux pas passer des mois à fabriquer un table et une chaise. La table et la chaise IKEA feront très bien l'affaire pour poser ton pokédex et faire ton boulot.

Et si ton boulot est de fabriquer des meubles, on va te demander de faire une Bergère à oreilles de style Provençal. Et tu es bien emmerdé, parce que tu n'as aucune idée de à quoi ça ressemble.

Et puis tu sais que les techniques de bois sur peuplier, merisier, chêne, etc. sont des techniques complètement différentes, qu'il faut environ 10 ans pour maîtriser chaque technique et donc environ 150 ans pour tout apprendre. Et que c'est un peu long pour toi.

-------------------------------------------------

Pour sortir de la métaphore et résumer :

- il faut rester concentré sur son objectif. Partir dans des détails techniques (= refaire un outil qui existe déjà) qui n'ont aucun impact sur le résultat final, c'est une perte de temps. Temps qui pourrait être consacré à faire ou apprendre d'autres choses (apprendre a designer une API, apprendre à faire écrire des tests, apprendre a faire du déploiement automatique, etc).

- d'autant plus qu'il est beaucoup plus facile de créer un outil qu'on connaît déjà, qu'on a déjà utilisé. Utiliser des APIs en premier permet de comprendre les besoins utilisateurs. On a déjà vu pleins de monde partir sur des codes complexes, mais en faisant des designs moisis, parce qu'ils n'ont pas pris le temps de connaître ce sur quoi ils travaillent.

- et un moment donné, il faut accepter qu'on ne puisse pas réinventer toutes les roues. L'informatique est de plus en plus complexe, on ne peut plus connaître tout ce qu'il se passe en détail.

Penser qu'il existe d'un côté des programmeurs, qui connaissent les détails internes, et les utilisateurs d'APIs, c'est juste se faire des illusions sur la réalité du boulot de dev. Les devs doivent utiliser les APIs quand c'est possible et réinventer la roue quand c'est nécessaire.

-
Edité par gbdivers 4 avril 2022 à 19:27:06

Merci, finalement j'ai tout codé moi-même et viens juste de finir