[Elradriel]

Bonjour tout le monde, tout d'abord, désolé le titre n'est pas très explicite. Je viens poster ici pour avoir vos conseils sur la création d'un petit jeu vidéo(Non ne partez pas de suite je ne viens pas recruter 56 personnes pour un mmo, mais juste chercher des conseils).

Pour présenter le contexte, je suis en DUT1 informatique depuis septembre donc, et j'ai peu à peu sympathisé avec 2 personnes de ma classe. On discute énormément et j'ai soumis l'idée que faire un petit projet de groupe qui permettrait de nous améliorer aussi bien sur le plan programmation que esprit d'équipe et travail d'équipe. On en est arriver sur le fait que on serait bien tenté par faire un mini jeu vidéo pour voir la réalité en face et voir comment peu se déroulé un tel projet (Non ne partez pas, on veut pas faire un mmo encore une fois je vais y venir ! )

Du fait que les personnes soient emballés, on a essayé de réfléchir à quel type de jeu assez simple faire (j'y viens, j'y viens).

Notre formation à l'iut en programmation/algorithmique se faisant en C++, on a décidé de partir sur ce langage, j'ai de plus quelques bases dedans bien que minime.
Pour ce qui est des autres, 2 semblent apprendre vite et semblent très intéressés par la prog (mais ils auront besoin d'apprendre les bases de la POO je pense) et le dernier un peu moins et aura besoin d'être boosté de temps en temps (mais c'est un ami de longue date donc ça ne sera pas un problème je pense)

Pour ce qu'on voudrait développer (oui on y vient enfin), c'est un jeu de plateforme à la Mario bros en très simplifié et sur le thème de lol. Je m'explique, niveau jeu, on choisit un personnage (disons que si on peut choisir entre 3 déjà ça sera pas mal) et après le jeu se déroule comme un jeu de plateforme avec un aspect très simple. Le personnage avance tout seul de la gauche vers la droite avec une vitesse croissante en fonction de l'avancement du niveau), la seul interaction pour le début du projet que le joueur peut réaliser est de sauter ou s'abaisser pour éviter les obstacle. Le joueur perd si il rentre en collision avec un obstacle. Tout ceci avec une image de fond genre des tourelles de lol et les obstacles peut être des minions statiques, rien de très compliqué. (J'ai après des idées d'améliorations en tête mais je pense que je devrais laisser ça de côté et déjà réussir à programmer ce qu'il y a au dessus.)

Pour réalisé cela, on se tournera vers la SFML qui me semble assez intéressante et simple à utiliser (j'ai étais lire la doc de classes et ça semble assez intuitif.) Pour ce qui est de l'IDE ça sera Code::blocks.

Tout d'abord après cette explication, j'aimerai vos avis quant à l'accessibilité de ce projet pour 4 personnes, a t-on visé trop haut ? Avez vous des recommandations si ceci est réalisable ?

On a discuté de la répartition des taches que chacun voudrait réaliser:

La personne moins intéressée par la prog voudrait réaliser tout ce qui est pixel art pour la réalisation du personnage et des petits décors et la partie site. Moi même et une autre personne sommes plus programmation, et le dernier n'a pas de préférence particulière et participerai aux taches ou il y aura besoin d'aide.

Encore une fois, le but de se projet et de s'améliorer donc on essayera de faire en sorte que tout le monde touche à tout (bon le pixel art y a rien d'extraordinaire et nous avancera pas dans le dut informatique mais bon). C'est aussi pour cela que l'on fait une partie site, bien que loin d'être compliqué (attention je parle d'un site statique avec juste quelques liens, vraiment un p'tit site "vitrine" sans réellement d’intérêt), c'est dans le cursus du DUT donc autant en faire un peu.

Voila je pense ne rien avoir oublié au niveau du contexte et des explications (c'est déjà assez long je pense)

J'ai maintenant deux question d'ordre technique car j'avoue que j'ai du mal à y répondre par moi même. Et une plus général.

- Tout d'abord, je vois comment faire le scrolling grâce à la caméra que l'on peut paramétré avec SFML, mais j'aimerai savoir dans ce type de projet comment est généré la carte ? Car dans ce cas, la carte est tout simplement illimité vu que l'on s'arrête a la mort ? C'est une carte qui se passe de façon linéaire et horizontale, mais le programmeur doit-il définir à quels endroits placé des obstacles, ou peut-il faire en sorte de généré tout ceci de manière aléatoire en faisant attention par exemple que un objet placé aléatoirement soit bien esquivable ? (je sais pas si cela à du sens pour mon explication, car j'avoue que je nage dans le flou de ce côté la).

- Pour ce qui est des collisions, j'ai une réponse mais j'ai peur que celle ci soit trop gourmande, j'ai réalisé pour mon projet de bac un tower défense simplifié en html/css/javascript, ou je calculais pour chaque tour, la distance qui se trouvé entre cette dernière et les monstres, ce qui améne pas mal de calcul et le jeu ramé assez rapidement lorsque les tours commencées à tirer. Aussi pour un projet comme celui ci, une fois que tout nos objets (obstacles) sont placés sur la carte, doit-on calculer dés le début, si pour chaque objet, le personnage est en collision avec lui ? Ou y a t-il des solutions moins gourmandes ?

- Ensuite, c'est plus une question générale, mais à quoi doit-on faire attention dans ce type de projet ? Les erreurs de débutants à ne pas commettre, ou les bonnes habitudes à prendre.

Voila j'ai enfin fini, j'espère que la lecture n'aura pas été trop ardue et je m'excuse d'avance pour les monstrueuses et innombrables fautes et espère des retours de votre part

[Senader]

Sans répondre à toutes tes questions :

- Est-ce viser trop haut ?
Clairement pas. C'est peut-être un brin ambitieux si vous êtes encore à tout apprendre, mais c'est faisable (même seul, je dirais) et ce rapidement.

- Comment faire un scrolling ala Temple Run/Jetpack Joyride/Insert phone game here ?
Le principe, c'est que la caméra ne bouge pas. C'est le terrain qui va dans l'autre sens et se supprime quand il n'est plus visible de la caméra (imagine un tapis roulant).
Il est bien sûr possible de créer le terrain aléatoirement à l'avance (avant qu'il ne soit en vue de la caméra).

Dans l'idée, tu crée à la main des morceaux prédéfinis d'une taille commune (ex : tous tes blocs font 300 pixels en x) et tu crée toutes les s secondes un nouveau bloc (random parmi tous les blocs que tu aura fait à la main) qui va aller de droite à gauche, en adaptant s pour que chaque bloc se suive.

Je ne sais pas si j'ai vraiment été clair, mais tous les mots sont là.

Pour les tips généraux :
- Ne recodez pas ce qui peut se trouver déjà dans la SFML
- En équipe, toujours attribuer un rôle à chaque personne. Un mec de "back up", c'est un mec qui se touche et qui ne se sent pas impliqué dans le projet.
- Ne faites pas durer ce genre de projet. Vous allez apprendre rapidement et beaucoup, et le code que vous aurez fait un mois plus tôt vous semblera vite moche et inutilisable. Allez vite, faites l'expérience, même si le code n'est pas très clean.
- Codez proprement : une indentation correcte, des noms de variables logiques, deux fichiers par classe (.h et .cpp). Codez beau et la vie vous le rendra.
Sérieusement, c'est une question de lisibilité, pour vous-même et votre équipe ainsi qu'une habitude importante à prendre. Si vous avez une norme de code à votre DUT, appliquez-la.
- Ne faites pas un site. Soit vous y passerez trop de temps et ça ne sera pas un travail intéressant, soit vous ferez un truc moche statique qui ne vous apprendra rien en plus de vous faire perdre du temps.

[Neirdan]

-Ne perdez pas de temps sur le nom, le lore ou l'histoire, ce qui est important c'est d'avoir un prototype fonctionnel rapidement.
-bitbucket plutôt que github

[Elradriel]

Bonjour, d'abord merci pour vos réponses.

Avec vos interventions j'ai donc de nouvelles questions

Donc, au niveau du scrolling, je vois pas comment faire la sur le coup pour faire dérouler le terrain, je veux dire par la, il faut faire un sprite pour le décor, et le faire bouger de droite à gauche, et lorsque le décor est en dehors de la caméra donc, on supprime les éléments du sprite petit à petit par sa coordonnée x en haut à droite donc ?

De plus, le fait de créer aléatoirement les éléments du décor, j'ai une interrogation, si on crée aléatoirement des objets, à chaque fois qu'on va relancer une partie, les décors seront différents de se fait non ?

Quand tu parles de ne pas faire durée un projet ? Combien de temps faut-il se consacré pour un premier "test"? En sachant que, vous allez peut être me remettre sur le droit chemin, et me dire de revoir mes ambitions à la baisse, mais le dernier projet que j'aimerai entreprendre ça serai un pokemon like.

Pour Neirdan, non pas de soucis pour le lore ou l'histoire, on ne comptait pas y accorder vraiment d'importance pour ce type de jeu.

J'ai une autre question qui me vient à l'esprit maintenant, peut être pas nécessaire pour un jeu de plateforme mario like, mais pour le projet final je suppose que c'est nécessaire et ça concerne l'éditeur de carte. Quelqu'un pourrait-il m'expliquer concrètement dans quel cas faut-il un éditeur de carte, son fonctionnement, le but rechercher, fin j'avoue que je nage dans ce sujet et mon vocabulaire ne doit pas être approprié,je m'en excuse mais je voudrai en gros l'idée général d'un éditeur de map.

Ensuite qu'en est-il des sprites , pourquoi beaucoup de sprite sont de base de type 32*32 ? Je veux dire par la, si on veut faire des personnages en pixel de 80 de hauteurs sur 50 de largeur, il n'y aura aucune différence au niveau du fonctionnement.

Voila pour les nouvelles questions et interrogations, bonne journée et merci de vos futurs réponses.

[Neirdan]

Renseigne toi sur le parallax.

En clair, tu as plusieurs "plans" de décor.

Un premier plan = le terrain
Un second plan = des arbres
Un troisième plan = des montagnes
Un quatrième plan = des nuages

Chacun d'eux se "déplace" à vitesse différente, cela donne une impression de profondeur.
L'idéal c'est d'avoir du "seamless" et d'en avoir 2 collés l'un à l'autre.

Par exemple tu as un rectangle de "visible" de 1000 pixels de large.
Ton fond fait 1024 pixels, tu en colles deux l'un à côté de l'autre, et tu les fait se déplacer de droite à gauche.
Lorsque le premier est entièrement invisible, tu le déplace à la droite du second, et ainsi de suite, pour que lorsqu'un est invisible, l'autre prenne toute la place et "cache" l'invisibilité du premier.
Tu peux également générer le paysage aléatoirement si tes tiles de paysage sont raccordées graphiquement.
Par exemple, tu as toujours 1000 de visible et tu as des tiles de 128. Tu sais qu'il te faudra 8 tiles pour couvrir le tout, donc 9 visibles. Lorsque la tile 1 disparait, tu crées la tile 10 et tu fais se déplacer tes 9 tiles d'1 pixel en même temps, entre chaque boucle.


Un éditeur de carte est nécessaire pour faciliter la vie de ceux qui font des cartes. C'est nécessaire uniquement en cas de carte "statique". Vu que tu fais de l'infinite scroll, il te faut une génération procédurale. Rien n'indique que le code lorsque t'es a 1000m soit le même que le code à 0m, tu peux augmenter la difficulté en réduisant l'espace entre chaque obstacle ou en augmentant la vitesse de scroll.

Tes personnages (et plus généralement toutes tes textures) doivent être en POT (power of two) "puissance de 2" parce qu'openGL (et D3D) gère beaucoup mieux le chargement d'images en puissance de 2. Ca ne veut pas dire 32x32, ca peut aussi être 16x64 ou 128x1024

[Elradriel]

Ah merci beaucoup pour toute ses explications !

J'ai compris tout ce dont tu parles, merci d'avoir expliqué si facile pour qu'un novice comprenne

Donc si notre projet finale est un pokemon like, (un autre projet hein, pas celui ci) il faudra se tourner vers la programmation d'un editeur de map ? (enfin la n'est pas la question pour l'instant concentrons nous sur notre projet test me direz vous).

Au niveau des plans du décor, je ne savais absolument pas que ça fonctionner comme ça, je sens que cette formation va mettre très bénéfique et va m'apprendre énormément de chose (pareil pour les sprites mais quand on y pense c'est logique, c'est tout simplement car c'est une puissance de 2 effectivement !)

J'aurai probablement d'autre question que je viendrai poser ici, et peut être des avancements du projet pour savoir si vous avez des choses à corriger qui sont de trop grosses fautes, pour l'instant on va tout poser sur papier pour mettre tout au clair.

Merci encore pour votre aide et si vous avez encore des idées, conseils, explications je viens lire régulièrement ! Bonne journée

[Chagarou]

Pour les graphismes, je vous conseille de vous tournez vers http://opengameart.org/ pour démarrer. C'est pas si facile de faire du pixel art et si votre graphiste débute vous risquez de mettre du temps avant d'avoir des trucs exploitables

Pour les collisions, le but du jeu c'est de ne calculer que ce dont tu as besoin. Dans le cas d'un jeu 2D à scrolling, ça veut en général dire qu'on va d'abord checker si le personnage est présent sur l'écran ou pas loin (si l'entité est à 10000 tiles de distance, on se fout un peu de ce qu'elle peut faire en générale).
De plus utiliser, des rectangles englobants avant tout test plus poussé de collisions, permet de gagner pas mal de cpu.

[EDIT] Pour l'éditeur de map, il y a pas mal de solutions gratuites et exploitables:
http://www.mapeditor.org/
http://tilestudio.sourceforge.net/

Après il suffit d'écrire une routine capable de lire ce qu'ils exportent et c'est gagner. Un éditeur de map c'est un projet en lui même vous dispersez pas

[Neirdan]

Pour ton pokémon-like, vois du côté de RPG maker.
Ca fait longtemps que je n'y ai pas touché donc je dis p'tet une connerie, mais sinon, tu peux au moins piquer/t'inspirer de leurs tiles.

[Feizenbara]

Citation :

Publié par Chagarou

Un éditeur de map c'est un projet en lui même vous dispersez pas

+1
C'est fou ce qu'on arrive à faire avec un simple google spreadsheet où le(s) mec(s) qui fait les maps décrit les coordonnées des objets (voire place les objets dans les cases de la spreadsheet, et oh magie, c'est comme une grille de tiles ^^) et ensuite t'as une macro dans ta spreadsheet qui te converti le tout en une chaîne de caractères balèze que ton code va importer/déchiffrer.

[Neirdan]

J'ai cherché quelques exemples de fonds/paysages en parallax en html, voilà un exemple concret des différentes "couches":
http://www.andwecode.com/playground-...h-parallax-js/

Ca ne veut pas dire qu'il faut le faire en html/js, c'est juste une démo.

[Elradriel]

Ok merci bien pour les différents liens, qui sont autant sympa les un que les autres.

Le dernier montrant l'exemple parralax est très parlant et permet de comprendre comment ça fonctionne. Par contre, au niveau du personnage, que doit-on en faire alors ? Concrètement, si le décor et les obstacles "viennent à lui" on ne lui permet que de sauter et s'abaisser au niveau des fonctions qu'il pourra exécuter ? Et une fonction bool enCollision ainsi que une enVie (c'est surement pas les seuls mais c'est celle qui me viennent à l'idée après il faut que j'y réfléchisse.

Et c'est noté pour les collisions ainsi que pour l'éditeur de map, j'y vois un peu plus clair maintenant.

Merci et je suis toujours à l'écoute de vos messages

[Neirdan]

On va simplifier ce qu'est un jeu, on oublie tout principe de multithreading, y'a pas de réseau non plus. Juste un test de collision qui servira de moteur physique et un rendu graphique.

1) Initialiser la partie, les variables

2) Boucle de rendu du jeu

2.1
-Déplacement des objets
-Calcul des collisions
-Vérification des conditions de victoire/défaite

2.2
Mise à jour de l'affichage (nouveau score, nouvel état de barre de vie, déplacement du décor, des personnages, etc

2.3
Retour à 2.1 jusqu'à victoire/défaite

3) Lorsqu'on sort de la boucle parce qu'on a gagné/perdu: Fin - retour au menu


Concernant le traitement des input clavier/souris, on part sur le principe qu'il faut le faire toutes les 200 à 250ms, soit 5 fois par secondes.
Pour avoir 60 fps, il faut faire son rendu toutes les 16,6 secondes (1000 millisecondes / 60 frames par secondes = 16,666666666666666666666666666667 millisecondes par frame )
Ce qui veut dire que les traitements de ta boucle de rendu ne doivent pas durer plus de 16ms

[Titan.]

J'ai du mal avec le concept de "projet final", ça fait un peu "dépressif-nihiliste-qui-a-prévu-de-se-suicider-après-son-projet". Si vous êtes en iut d'info, vous en ferrez toute votre vie des projets.

Sinon vous êtes vraiment dans une optique d’apprentissage et non de recherche de productivité, donc ce que je vais dire s'applique pas vraiment pour votre cas, mais en général: préférez un moteur de jeu plutôt qu'une simple librairie graphique, et n'attachez pas trop d'importance au langage utilisé, une fois que vous maîtriserez le C++, passer à du C#, du java ou même un langage de script se fera facilement (l'inverse n'est pas vrai).
Par exemple votre projet peut se faire en 1h30 sur Unity, tandis qu'il demande 5h avec la SFML.

[Neirdan]

Je serai plutôt partisan de l'option inverse: utiliser un minimum de "tout fait" et se casser le cul a intégrer des librairies de son, de physique ( http://box2d.org/ ) pour pouvoir comprendre le fonctionnement de base d'un jeu et surtout de la boucle principale, sans avoir toutes les fioritures à côté.

Après, c'est p'tet parce que moi j'ai commencé comme ça.

On est d'accord que leur projet est super simple à faire, en html/javascript ça prend pas plus de 2h aussi, pour une personne seule, mais l'objectif c'est clairement pas pour eux de faire un game jam.

[Elradriel]

Hello, encore une fois merci pour l'attention porté au dessus.

Pour rebondir, en effet on ne veut pas produire un petit jeu histoire d'avoir dit "on a fait un jeu". Le but principale est de se former et de comprendre comment se passe déjà le travail d'équipe sur un projet (même si comme vous le dites, le projet n'est pas très gros, mais c'est une première approche pour voir ce que ça donne.) et de comprendre le fonctionnement qu'il y a derrière.

Pour "projet final" effectivement ça fait un peu, c'est m'a dernière heure xD Je voulais parler de projet final à la fin du DUT, je sais que j'en aurai toute ma vie, mais avec le même groupe de personne, c'est le projet comme aimerai voir fini en sortant de notre DUT.

Je suis toujours à votre écoute pour vos conseils mais je pense que l'essentiel à été dit, maintenant il faut passer à l'action !

[GtB]

Mon conseil c'est de ne pas avoir de projet, tu te met devant ton écran et tu fais un jeu bien pourris, en 2 ou 3 heure. Puis après ben tu en fais un autre.