Bonjours a tous, je souhaite m'excuser pour les fautes d’orthographe a l'avance !

Voila j'ai besoin de vous,car je souhaite créer un petit jeu vidéo type Mario ou autre pour apprendre encore plus le c++, et pour me donnez un palier a atteindre et pour un rêve que je souhaite réalise. !

sauf que petit soucis, je souhaite installer la librairie sfml et je n'arrive pas depuis 1 semaine, j'avoue que je me bat contre ce soucis de librairie et que j'aurais bien besoin d'aide ou d'étape pour installer la sfml un tuto pour 2018 si possible^^

Mercii tous le monde !

Bonjour à toi !

https://www.sfml-dev.org/tutorials/2.5/index-fr.php

j'ai utilisé ce lien qui vient directement du site officiel et tout s'est extrèmement bien passé. N'oublie pas d'inclure tous tes fichiers dans ton dossier de projet (je parle de sfml-audio-2.dll ect..) et aussi d'ajouter les "linker sfml-graphic-d", ect.. dans le debug (build option -> debug -> linker) !

Par ailleurs j'utilise Code::Block donc je pourrai seulement répondre à tes questions sur cet IDE !

Juste une remarque à 2 balles.

Si l'objectif c'est de faire un jeu, utilisez un moteur de jeu (Unity, UnrealEngine, ...).

Cela permet d'avoir un socle bien meilleur qu'une simple librairie graphique comme SFML.

Salut bacelar,

Personnellement je n'apprécie pas trop utiliser ces (puissants) moteurs de jeux simplement parce que je me sens trop "utilisateur" et je n'ai pas l'impression de faire quelque qui m'appartient. Par contre je te rejoins sur le fait qu'il est sur que je ne peux actuellement pas faire ce que les moteurs sont capable de faire.

Salut,

étrange sentiment ... lorsque tu écris un texte, tu as l'impression qu'il ne t'appartiens pas parce que tu as utilisé un stylo BIC et une feuille Clairefontaine ?

Pour ma part je suis en train d'explorer Love2D, c'est sympa et ça suffirait pour faire un petit plateformer comme mario

Sinon j'ai de l'affection pour Godot, léger, simple et OpenSource, si je me lance dans un vrai jeu et non plus des expérimentations, pour l'instant c'est lui que je choisirai et je pense qu'il est plutôt accessible

Après évidemment Unity possède énormément de ressources sur le net, avec une communauté énorme et des performances et une portabilité au poil, c'est bien sûr un super choix. Et UE4 et Lumberyard ont des rendus qui font baver et proviennent du C++

EDIT : Par contre, si le "rêve que tu veux réaliser" à terme n'est pas un jeu mais utilise des technologies et techniques du moteur de jeu, il peut effectivement être intéressant de le refaire

-
Edité par romantik 4 septembre 2018 à 11:42:48

bacelar a écrit:

Juste une remarque à 2 balles.

Si l'objectif c'est de faire un jeu, utilisez un moteur de jeu (Unity, UnrealEngine, ...).

Cela permet d'avoir un socle bien meilleur qu'une simple librairie graphique comme SFML.

Alors pour le coup je ne rejoins pas cet avis. Il y a toujours un peu la même réponse, tu veut faire un jeu, utilise Unity 3D, Unreal ou autre.

Effectivement ce sont des outils extrêmement puissant pour faire des jeux, mais de la à les conseiller à quelqu'un qui veut faire un petit jeu pour pratiquer... 

Il s'agit de faire des sprites et de les déplacer en fonction d'entrée clavier. De là à sortir l'artillerie Unity je vois absolument pas en quoi ce serait formateur. 

-
Edité par vac 4 septembre 2018 à 14:16:23

vac a écrit:

Effectivement ce sont des outils extrêmement puissant pour faire des jeux, mais de la à les conseiller à quelqu'un qui veut faire un petit jeu pour pratiquer...

Ben ça dépend pour pratiquer quoi justement !

Si c'est pour pratiquer le C++ alors ok, reste sur SFML, mais si c'est pour pratiquer le GameDev, alors un moteur de jeu a vraiment du sens, même s'il est bien plus puissant que ce dont on a en réalité besoin pour ce projet. ça permet de se familiariser avec l'interface et la philosophie du moteur, et de profiter des éléments courants de jeu vidéo déjà implémenté.

Galérer des heures avec SFML pour faire mumuse avec un sprite quand la même chose avec Unity en suivant un simple tuto de 5 minutes, c'est vite vue.

Vous me rappelez les mecs bornés avec leurs routines assembleurs, qui se faisait démonté en performance par les optimiseurs.

bacelar a écrit:

Galérer des heures avec SFML pour faire mumuse avec un sprite quand la même chose avec Unity en suivant un simple tuto de 5 minutes, c'est vite vue.

Vous me rappelez les mecs bornés avec leurs routines assembleurs, qui se faisait démonté en performance par les optimiseurs.

L'OP demande quand même clairement une approche pour pratique le C++, de là à dire que je suis un comme "les mecs bornés routines assembleurs" et de dire que c'est "faire mumuse avec un sprite" c'est du n'importe quoi.

Personnellement j'ai commencé comme ça en faisant des petites applis graphiques qui répondait au clavier et à la souris et je ne regrette pas du tout.

Effectivement tu peut le faire en 5 minutes avec Unity sans problème, tu n'auras pas appris grand chose sur ce qui t'intéresse à la fin. 

En fait les remarques comme celle-là ne laisse aucune place à l'apprentissage, comme si chacun voulait apprendre uniquement pour releaser au plus vite quelque chose, faire un produit. 

Je pousse un peu un coup de gueule, mais j'ai toujours l'impression que ces remarques sont récurrente et particulièrement inadaptées pour une communauté où les gens sont là pour apprendre.

Ce serait trop facile quand même, à chaque question posé ici il suffirait de répondre: utilise Unity. 

Je préfère nettement les propositions constructives comme celle de Romantik qui au contraire ouvre l'esprit de l'OP et lui fait des propositions. 

Salut,

Le fait est que l'idée de faire une application -- quelle qu'elle soit -- pour apprendre un langage -- quel qu'il soit -- est une pure aberration, si cela nous oblige à utiliser une bibliothèque tierce "uniquement" pour avoir le rendu.

La raison est simple :  tu n'apprends pas le langage, tu te met à apprendre comment utiliser la bibliothèque en question correctement.  Et c'est tout à fait différent!

Maintenant, tu me diras que sans pratiquer le langage que tu essayes d'apprendre, tu ne le maîtrisera jamais.  Et tu auras tout à fait raison.

Mais c'est là qu'il faut se rendre compte que, pour arriver à maîtriser un langage -- quel qu'il soit -- ce qui importe, c'est la manière d'exprimer la logique que l'on souhaite voir le programme exécuter, et que cette logique n'a souvent rien à voir avec la représentation qui en est donnée -- sous une forme ou une autre -- à l'utilisateur.

C'est la raison pour laquelle il existe des approches connues sous des noms comme "MVC", "Client/Server" et autres dans lesquelles on retrouve systématiquement une partie qui s'occupe spécifiquement de la "logique interne" (le M de l'approche "MVC", qui signifie Model, ou la partie "serveur" dans une approche "Client/Serveur") et une partie qui s'occupe de la représentation -- sous une forme ou une autre -- des données "à un instant T" (le V de l'approche "MVC", qui signifie View, le client dans une approche "Client/Server").

A cela s'ajoute parfois une "troisième partie" qui va s'occuper de faire le lien entre les deux (le C de l'approche "MVC" qui signifie Controller).

SFML et Qt (pour la grosse majorité de ses modules) sont des bibliothèques qui ne devraient -- en théorie -- être utilisées que... pour fournir "une certaine représentation" des données telles qu'elles se présentent à un instant  T.

En veux tu la preuve? "Trop facile":

• sf::Sprite (et, pour faire simple, tout ce qu'on trouve dans le sous dossier Graphics) a "uniquement" pour but de permettre d'afficher "une zolie imaze"
• tout ce que l'on trouve dans le sous dossier "Audio" a uniquement pour but de nous permettre de jouer un son "dans certaines circonstances"
• tout ce que l'on trouve dans le sous dossier "Network" a uniquement pour but de permettre le transfert de la représentation de données"à un instant donné" entre un client et un serveur
• tout ce que l'on trouve dans le sous dossier Window a uniquement pour but de permettre la création d'une fenêtre dans laquelle nous pourrons afficher nos "zolies imazes"
• Et tout ce que l'on trouve dans le sous dossier "System" a uniquement pour but de nous permettre de prendre en compte les différences qui peuvent exister entre les différents systèmes d'exploitation

Et, dis toi bien que je pourrais te faire la même démonstration pour Qt (mais elle serait beaucoup plus longue, étant donné le nombre de modules qu'elle propose) !

Mais, du coup, on se rend compte qu'il reste quand même encore de la place pour apprendre le langage (et rien que le langage!), à la seule condition... de ne pas commencer à s'empêtrer dans des considérations visant à "fournir une zolie représentation des données".  Autrement dit, en s'intéressant en priorité à toute la logique qui présidera aux interactions entre les différentes données (à la partie Model d'une approche "MVC", par exemple)

Et, si on veut vraiment avoir une "représentation" (qui ne sera sans doute pas des plus "fun", je te l'accorde), il faudra se contenter de ce que la bibliothèque standard nous offre: la sortie standard (std::cout) ou -- dans certains cas -- la création d'un fichier de sortie (std::ofstream).

Le tout en veillant malgré tout à ce que cette "représentation basique" soit... suffisamment indépendante du reste que pour être en mesure d'utiliser une bibliothèque tierce par la suite, sans avoir forcément à "tout casser" pour y arriver.

Le PO veut faire un mario? d'accord, qu'il commence par s'intéresser à toute la logique qui présidera aux interactions entre les différentes données du jeu.  Et, s'il veut vraiment disposer d'une représentation, qu'il accepte l'idée de travailler en ligne de commande avec un affichage proche de

  WWWWWWW
       G        WWWWWWWWW    B
     G     G           E    BBB
   WWWW                CCWWWWWWWWWWWW
            M
        WWWWWWWWW
                 WWWWWWWWWW
        
Legend:
G : Gold
W : Wall
M : Mario
E : Enemey
B : Barbs
C : Chest

U: up
D: down
L: left
R: right
J: jump
you choice?(U/D/L/R/J):

Bien sur, ce mode de jeu ne sera pas "aussi fun" que s'il avait utilisé SFML ou Qt, parce qu'il sera particulièrement lent. Mais, s'il y arrive, l'utilisation de SFML pour remplacer la bibliothèque standard devrait pouvoir se faire de manière particulièrement simple

Relisez bien le post du PO.

Son rêve, c'est quoi ? Maitriser le cours de C++  ou de faire un jeu à la Mario ?

Et j'ai fait partie des "les mecs bornés routines assembleurs", il n'y a donc pas de condescendance mais de l'amertume pour ce temps gâché.

Moi, je vous trouve complètement condescendant avec votre avis sur les moteurs de jeu qui font tous et qui vous apprennent rien.

C'est complètement faux, bien au contraire, cela vous oblige à sortir la tête du guidon et à manipuler correctement des concepts de haut-niveau comme l'ECS, les prefab, les modèles de simulations physique, les lumières, les trajectoires de monstre via IA, etc...

Merci a tous pour vos réponse ! 

En gros mon objectifs et d'apprendre le c++ et d'apprendre a faire un jeu manuel, sans moteur graphics pour connaitre les bases, et savoir me débrouiller seul sur la création, d'un petit jeu pour le moment

Si tu veux apprendre c++ alors c'est la méthode de Koala01 qu'il te faut suivre, les vraies bases c'est ça, tu va mettre des mois pour arriver à faire un jeu avec une logique potable, et comme il le dit, tu vas le rendre graphique en quelques jours(semaines) via une bibliothèque comme sfml ou Qt. Ce faisant tu auras appris c++, mais pas à faire un jeu.

Si par contre tu veux apprendre à faire des jeux, ça ne sert quasiment à rien de passer par la case c++, va directement apprendre à te servir d'un moteur de jeu, contrairement aux idées reçues un moteur ne fait pas tout le boulot, très loin de là: entre le step "New Project" et un jeu abouti, il y a des heures et des heures de travail.

-
Edité par int21h 9 septembre 2018 à 20:21:51