Sujet:
Salut les Carlos,
Pour démarrer ce topic, je me suis retrouvé à faire face au problème que j'avais justement envie de traiter. Ce problème, il s'exprime facilement : j'ai envie de démarrer un projet, mais je ne sais pas tellement par où commencer.
Hé bien, pour se lancer dans la tâche pharaonique qu'est la création d'un jeu-vidéo... On tombe quasiment toujours sur ce petit soucis. Le problème ici est double. Déjà, on voit un grand nombre de personnes qui souhaitent apprendre à développer des jeux-vidéos sans savoir comment se lancer. Et puis on a le fameux "syndrome de la page blanche", lorsqu'on a déjà un minimum de savoir-faire et qu'on veut démarrer mais qu'on ne sait soudain plus ce qu'on veut faire.
Je me suis simplement dit qu'il serait sympa de partager avec vous sur ces deux sujets. Ce qui m'intéresse beaucoup, ça serait d'offrir un endroit où les débutants de notre petite communauté puissent trouver des informations pour se lancer, ne serait-ce qu'en tant qu'amateurs. Si ça peut servir à d'autres à éliminer une page blanche, c'est tant mieux ! J'ai quelques astuces là dessus que je serai ravi de partager.
Evidemment, je ne suis pas un professionnel du milieu ni un professeur. J'ai aidé des personnes à monter divers projets et j'ai une bonne compréhension des étapes nécessaires. Mais je suppose qu'à nous tous, on pourra au minimum avoir une conversation intéressante 
Certains d'entre vous se posent sans doute la question. "De quoi j'aurais besoin pour créer mon jeu ?" La liste est longue, et j'espère sincèrement qu'on pourra en faire le tour ensemble. Mais pour ce premier post, je vais mettre un gros accent sur la chose qui me semble être la plus importante : le temps ! (Comment ça, y a pas d'accent au mot "temps" ?)
Vous le saviez sans doute déjà, mais c'est important. Pour un triple-A, on voit souvent une équipe de plus de 40 personnes qui travaillent pendant une, voire plusieurs années. Je vous laisse faire le calcul du nombre d'heures total. Ceci sans compter qu'il s'agit d'un projet établi, pour lequel la direction à prendre et les objectifs à atteindre sont souvent déjà posés.
Pour ceux d'entre-vous qui débutent totalement, il faut aussi prendre en compte un grand nombre d'heures d'apprentissage. En fait, que vous sachiez ou non ce qu'est un "moteur de jeu", le "framework XNA" ou le "C++", vous aurez pratiquement toujours quelque chose de nouveau à apprendre pour réaliser un jeu. Certains ont moins de choses à apprendre que d'autres, mais je doute que quelqu'un puisse me dire : "Moi je sais tout ce qu'il y a à savoir pour créer n'importe quel jeu, je n'ai plus rien à apprendre."
Donc on a déjà le temps de production, le temps d'apprentissage. Puis, il faut aussi prendre le temps en début de parcours de bien définir le projet, notamment la direction à prendre, les objectifs et les moyens qui sont à disposition. Mais ça, j'y reviendrai.
Mais alors... Est-ce réalisable par une seule personne ? Honnêtement c'est difficile, rien ne sert de mentir ou de donner de faux espoirs. Créer un jeu en solitaire demande un bon nombre de connaissances et de talents et prend très certainement plus de temps que de le réaliser en équipe. Si vous comptez démarrer aujourd'hui et avoir fini le jeu de vos rêves le mois prochain, vous allez vous enfoncer la tête dans un mur dans trois semaines.
Cela ne veut pas dire que c'est impossible. C'est une question de perspective. Il faudra certainement réduire les ambitions (visuelles, notamment) d'un jeu s'il est créé par une seule personne. Mais on retrouve parfois quelques créateurs qui peuvent se servir de ça pour créer un concept génial. On peut penser à un petit inconnu du jeu-vidéo, dénommé Minecraft... Les contraintes, on a rien inventé de mieux pour booster la créativité !
Bon, je sais que j'ai mis le titre et tout (j'avais aussi écris quelques paragraphes) mais je vais m'arrêter là pour ce post. Avant d'aller plus loin j'avais envie de commencer la discussion avec vous sur l'idée du topic et sur le sujet du temps nécessaire à la création d'un jeu. Je suis sur qu'il y en a parmi vous qui auront des exemples plus concrets à partager et j'ai hâte des les entendre.
Je déteste coder (j'ai des notions cela dit, j'ai pas trop le choix) donc je vais surtout vous donner des conseils pour la préparation des parties écrites.
Un bon éditeur de texte genre Word ou LaTeX (si vous voulez apprendre le LaTeX, je ne saurais que trop vous conseillez mon guide "Base de LaTeX": Base du LaTeX)
Le cahier des charges est l'expression du besoin. Si vous cherchez des gens pour travailler avec vous, c'est le document qu'ils doivent lire avant de décider de travailler avec vous.
faut pas hesiter d'explicité à outrance, même ce qui parait logique.
Prenons comme exemple la création d'un RPG très basique.
Je veux créer un RPG qui doit remplir ces conditions:
Bon l'équipe est faite, elle est motivé mais va falloir leur dire exactements ce que vous voulez. C'est l'heure du brainstorming seul (si les autres veulent pas prendre part) ou à plusieurs (cas normal)
Ici, on doit tout écrire afin de ne rien oublier.
Reprenons notre exemple précédent:
Bon c'est vraiment léger comme spécification. Faut vraiment tout préparer afin de mieux aborder le projet.
Le deux seuls conseils de code que je donnerais sera.
Perso je pense que le plus importants à définir en amont de tout ça, surtout quand on est une petite équipe (voire tout seul), c'est le centre du gameplay, l'idée clé, le truc sur lequel se centrera l'intérêt, qui guidera les sensations de jeu, définira son identité, en fera sa singularité.
Pourquoi ? Simplement parce que (tout particulièrement quand on débute, et/ou quand on est en équipe restreinte voire tout seul), avoir un fil conducteur, une idée maitresse autour de laquelle construire son jeu, permet déjà d'avoir son point de départ, ensuite de guider le développement tout le long en évitant de trop se disperser, et enfin (surtout?) être à même d'identifier les concessions à faire quand on se rend compte qu'on ne pourra pas en pratique aller au bout de toutes les ambitions qu'on nourrissait initialement (par manque de temps, manque de compétence technique, ou encore parce qu'on s'éparpille dans tellement de fonctionnalités qu'on n'arrive plus à les finaliser et les unifier dans un tout cohérent) ; et donc ne pas avoir de remord à sacrifier p.ex. la partie craft parce que finalement ce n’est pas là que se trouve le sel de son jeu.
On peut partir d'un concept ou d'une sensation de jeu (exploration ; combat ; gestion ; liberté ; proximité avec la nature ...) ; il peut aussi s'agir d'avant tout raconter une histoire.
A partir de là, réfléchir aux meilleures moyens de porter ce concept, en s'aidant bien sûr de son expérience de joueur, et donc des jeux qui pour nous font référence pour porter cette idée ; mais aussi en restant lucide sur ses capacités à techniquement pouvoir porter un tel projet.
Donc au final : un jeu en vue à la première personne (et donc en 3D --> nécessité de bien maîtriser ce qui est modélisation, texturing, rigging...) axé sur l'exploration ? Un jeu typé RPG, vu de dessus (2D possible, plus simple d'approche) avec comme attrait principal ses combats? Dans ce cas combats tour par tour ou en en temps réel type action-RPG? (tour par tour BEAUCOUP plus simple à implémenter, mais demandant un travail fin de conception et d'équilibrage des règles)
Sur cette idée très schématique du jeu qu'on veut réaliser, il faut ensuite apporter du concret, à commencer par écrire noir sur blanc sur quels principes se construira en pratique les sensations de jeu que l'on veut transmettre:
P.ex. on veut créer un RPG qui se concentre sur les combats, en tour par tour avec déplacements façon tactical : quelles mécaniques de bases pour les affrontements? Il faut alors écrire les règles (équations) de résolution des attaques ; réfléchir à comment gérer les déplacements (empiètent sur une barre de "PA"? se gèrent par une amplitude donnée indépendamment des actions?) ; définir quelle importance on veut donner au leveling et à l'équipement si les avancées dans le jeu se feront plus par l'ajout de nouvelles capacités ou par augmentation de stats, si l'amplitude des stats se fera, entre un héro débutant et un de haut niveau, par des caractéristiques multipliées par 10 ou plus ou se jouera plus finement par des gains de 20 ou 50% (ce qui donnera plus d'importance au skill du joueur qu'au farming) ; si on englobe le tout dans des déplacements temps réels sur une carte détaillée, sur laquelle prendra directement place les combats ; si on situe différents endroits visitables sur une carte globale schématique, cliquable pour changer de lieux, chacun apportant différents évènements en fonction de l'avancée de l'aventure, et pouvant être atteignable / déblocable selon le contexte ; si on évolue plutôt le long d'un arbre scénaristique simple avec enchainements d'évènements (plus ou moins textuels, plus ou moins interactifs, avec plus ou moins de conséquences) le long duquel s’égrèneront les phases de combat ; ....
Petit à petit les éléments concrets vont s’accumuler, de façon concentrique autour de l'idée de départ ; mais on ne perd pas cette idée centrale, et tout ce construit autour, gardant une hiérarchie selon son importance face à ce fil conducteur. Du coup, tout restant bien sûr malléable et à même de changer au cours même du développement (autant par difficulté technique à implémenter telle fonctionnalité, que par une soudaine bouffée d'inspiration qui apporte de nouvelles idées et son lot de changement), on identifie sans mal les endroits où les coupes ou modifications seront les moins dommageable pour préserver le cœur du jeu.
P.ex.: on se rend compte que réaliser les déplacements en temps-réel sur une carte détaillée est trop compliqué et trop long à mettre en place, finalement est-ce que passer à une carte globale avec simple clique d'un lieu à l'autre pour les déplacements ne fera pas aussi bien l'affaire? Les combats restent les mêmes (et c'est le cœur du gameplay), la partie gestion des voyages peut persister en utilisant des gestion de variables simples (se rendre ailleurs consomme du temps, de la nourriture, nécessite tel ou tel équipements pour faire face à des conditions climatiques ou topographique particulières ; se fera plus rapidement si on a des chevaux, ou rejoindre tel endroit ne sera possible que depuis un port ou si on a libéré le passeur qui était enfermé dans un donjon, etc. ; et bien-sûr on pourra engendrer des combats ou évènements particuliers sur la route, aléatoire ou non).
Idem si on se rend compte que tout ce qui à trait au craft pose problème (implémenter une gestion de drop et récolte de ressource ainsi que d'obtention de "recettes" ; équilibrer avec l'aspect loot et récompenses de quêtes avec lequel il rentre en concurrence ; difficulté à produire l'ampleur du contenu nécessaire pour le rendre intéressant) : finalement est-ce que cela aura un impact fort sur l'idée principale du jeu, les combats? Non? Alors on peut bazarder sans arrière penser, et avancer dans le développement tout en restant concentrer sur ce qui fera réellement le sel du jeu.
On peut penser à Darkest Dungeon p.ex. où finalement tout est très épuré et minimaliste en dehors des combats ; j'ai cru comprendre que Banner Saga propose aussi très peu d'éléments de jeu en dehors de l'avancée du scénario selon un arbre à choix multiples et des phases de combats. Cela en fait-il de mauvais jeux ou des jeux manquant de profondeur? Franchement, je ne crois pas
.
Cela en a en revanche surement fait des projets plus facile à porter et à finaliser, et de belle façon.
Bref, à mon sens, pour bien débuter un projet, il faut avoir les idées claires, et commencer par écrire clairement les mécaniques que l'on veut implémenter, en partant des concepts centraux (et très conceptuels) que l'on veut porter, en détaillant ensuite la façon dont on pense les concrétiser.
Tous les détails et les considérations les plus concrètes pourront bien sûr se modifier au cours du développement (idée initiale qui "ne fonctionne pas" en pratique, nouvelles idées venues en cours de route, etc.), mais le document restera une base de travail (qui pourra évoluer du coup) et permettra de garder en vue ce qu'il reste à faire, ce qui est à modifier, etc. Et garder de vue l'idée directrice qui sous-tend tout le reste et qui était notre motivation première à concrétiser ce projet.
Un tel document reste à mon avis central qu'on travaille seul ou à plusieurs, même si lors d'un travail en équipe il aura aussi comme intérêt de permettre de synthétiser une vision du jeu pour tout les membres, aidant à ce que tout le monde travaille dans la même direction et dans le même but.
Je rejoins l'idée de Nival: 1)commencer par choisir une idée de gameplay.
En ce sens les GameJams sont parfaites: les équipes peuvent immédiatement tester un concept et voir s'il fonctionne avant de partir sur la création d'univers.
Une histoire qui évolue selon l'heure, la météo et la géolocalisation, c'est https://www.viafabula.com/
Je me permets de remettre ici un post du forum fr de la Communauté AGS
NB: quelques parties sont spécifiques au développement d'un jeu sous AGS, mais donnent néanmoins des pistes de réflexion intéressantes...
Se lancer dans la création d'un jeu-vidéo demande un fort investissement personnel. Oui j'enfonce une porte ouverte, mais parfois quand on débute, même en étant de bonne volonté, on peut se faire une représentation erronée de l'investissement que demande un tel projet (et en même temps, c'est normal car on découvre tout ou presque).
C'est pour pourquoi, il m'apparait essentiel de d'abord choisir un thème, un sujet, une histoire qui nous tient tout particulière à coeur ! Notez bien que je ne parle pas simplement d'un thème "qu'on aime bien", mais d'une passion, d'un projet qui murit depuis longtemps ou d'une thématique à laquelle, et pour des raisons personnelles, vous êtes particulièrement attachée ! Pourquoi ?
Parce que des galères, des coups de blues, des envies de tout arrêter vous en aurez dans le développement ! Donc si l'attachement initiale à votre premier projet n'est pas très fort... vous risquez de vivre la frustration de na pas aller au bout :/
Et oui, ça peut paraitre étrange, mais j'ai mainte-fois vérifier le bon sens de cette démarche. Prenez un cahier, écrivez un synopsis, des fiches de personnages, des notes sur l'ambiance que vous voulez pour votre jeu, des croquis en tous genres, etc. Bref, avant de vous lancer dans le code ou les graphismes, il faut savoir où on va
Il ne faut pas voir ça comme une règle stricte. Perso, pendant cette phase créative, je m'autorise aussi à toucher à la souris pour mettre des croquis en images ou tester rapidement des petites détails par exemple. Mais l'essentiel c'est de se poser, de ne pas foncer tête baissée sur AGS. Le risque étant de "travailler dans le vide", par exemple en développant des graphismes et interactions que vous ne pourraient pas garder plus tard, ou en étant confronté à des incohérences scénaristiques qui demanderont de revenir sur un travail déjà codé.
Vous ne mettrez peut-être pas tout par écrit. Des choses vous viendront en tête en cours de développement. Mais si 70 à 80% de votre travail est pensé avant, vous vous épargnerez bien des tracas...
Il faut aussi se faire plaisir dans un développement ! Alors si le graphisme est votre truc, après l'étape ci-dessus, amusez-vous en commençant par les personnages principales, le menu du jeu, ou les premières pièces. L'intérêt est aussi d'avancer du travail avant de coder. Gérer en même temps création des graphismes et codage peut en effet parfois être fastidieux.
Si le son est votre truc, et bien le conseil reste le même. Mais ne négligez pas pour autant ceux-ci.
C'est l'une des premières choses que demande AGS. Je ne vais pas m'étendre sur ces aspects techniques. Simplement, toujours dans l'esprit de partager mon expérience propre, je considère que commencer avec un Template vierge (empty) est sans doute la meilleur façon d'apprendre. Par certains aspects, je trouve même plus pratique et simple d'utiliser un template vide.
Là encore, je vais pas m’étendre sur le côté "technique" du GS, les tutos sont très bien pour ça. Néanmoins il me semble important dans un projet de ne pas sauter ou remettre à plus tard certaines étapes essentielles, et le GS en fait parti. Donc prenez le temps de regarder chaque lignes pour voir si elles correspondent ou pas à votre projet.
Ah le codage... Lorsqu'on débute, on se sent en général perdu. Déjà je vous conseille bien évidemment de lire (et de faire !) tous les tutos officiels présent sur le forum (indispensable !).
Passé cette étape importante, on ne sait pas forcément pour autant par où commencer. J'ai personnellement pour habitude de commencer par ce qui va revenir tout le long du jeu : les éléments d'interface. Parce que ce qui est fait... n'est plus à faire, lol
Quelque soit votre projet, il va y avoir un certain nombre d'interactions récurrentes comme les déplacements, utiliser des objets, ouvrir un inventaire, parler à des PNJ, etc. La façon de présenter ces éléments est très variable. Comme vous avez dû y réfléchir bien en amont du projet, il est maintenant temps de s'y mettre
C'est très utile, car ces interfaces ne bougeront plus dans le reste du jeu. Vous pourrez ainsi tester en toute tranquillité vos prochaines rooms et vous concentrer sur celles-ci et le reste du code.
Il est aussi important de voir le code comme l'apprentissage d'une nouvelle langue et d'une nouvelle culture. Vous allez non seulement apprendre la "grammaire", le "vocabulaire" et la "syntaxe" du langage d'AGS, mais il est tout aussi essentiel d'en comprendre la "culture", "l'esprit", la "logique". Et c'est tout-à-fait à la portée de chacun ! Il faut simplement apprendre à être patient, accepter de faire des erreurs, et faire l'effort conscient de d'abord chercher une solution par soi-même, avant de demander des avis sur le forum. Cette méthode à fait ses preuves.
Oui, des galères il y en aura, c'est certain ! Quelques fois des petites qui vous feront sourires, parfois des grosses qui vous mettront dans un vrai désarroi... Comment réagir ?
et puis parfois, après une pause, on revient avec un oeil neuf sur le problème et c'est là qu'une solution inattendue nous apparait !
C'est à chacun de voir. Mais une première chose à faire est de sauvegarder régulièrement le dossier racine du projet ! (Pour ma part, je fais des zip très régulièrement surtout après une grosse séance de code) Ça peut litteralement sauver votre projet, alors ne négligez pas cette astuce.
Ensuite, lorsqu'une grosse galère arrive, comme un code très important récalcitrant qui refuse de fonctionner, personnellement je laisse le jeu de côté un petit moment... Je me concentre sur des choses qui me plaisent : je m'avance sur les graphismes ou la musique, par exemple. Mais avoir aussi à côté un autre projet, différent, est quelques fois salutaire.
Encore une fois, là c'est à chacun de voir. Mais l'important est de ne pas se focaliser sur ce qui vous bloque ou ne fonctionne pas. Tout ce débloque en son temps
Oui, oui, vous lisez bien. Je n'encourage personne à la fanfaronnade ! Mais traiter son projet, certes avec modestie et humilité, mais néanmoins comme un projet sérieux et pro, apporte une importante plus-value artistique. Concrètement, ça veut dire quoi ?
Et bien, ça veut dire par exemple faire attention aux détails, à la finition. Un truc tout bête : l'orthographe. Dans mon premier jeu, même si j'y faisais attention, j'ai laissé passé beaucoup de fautes. Aujourd'hui encore c'est une vrai frustration. Un décors est dans une mauvaise résolution laissant apparaitre des artefacts ? Corrigez-le ! L'animation d'un personnage qui marche contient une image un peu bancale ? Corrigez-la ! etc. Ne négligez jamais la finition d'un jeu. C'est très gratifiant au final
Autre point, la communication. Si on fait des jeux, c'est d'abord pour soi, soyons honnête. Mais c'est aussi pour les partager avec d'autres. Qui ne voudrait pas être jouer par des milliers de gamers ? Pour ça, ayez une com' simple, propre, suffisamment active. Certains réseaux sociaux comme Twitter sont pas mal pour ça. A vous de voir...
Perso, j'aime bien aussi soigner les génériques de début et de fin. Ça peut paraitre idiot, mais je choisi aussi un nom de studio fictif (par exemple, WinnerBrosse sur les WIMD). A vous de juger ce qui est bien pour votre projet dans ce domaine.
En communiquant, en partageant des captures d'écrans et autres, les critiques vont venir c'est inévitable. Certaines constructives, d'autres moins. Déjà ne rejetez pas en bloque toutes les critiques, mais ne les laissez pas changer votre vision d'un projet en quelque chose qui ne vous ressemblera plus ! Parfois, il faut savoir assumer ses choix artistiques. Donc écoutez toutes les critiques, mais ne retenez que ce qui peut vous aider à améliorer votre vision de votre jeu. On peut quelque foi changer beaucoup de chose dans un projet, mais sans dévoyer pour autant l'intention de départ de l'auteur. Du moment que c'est vous qui faites ces choix de changement, que vous avez pris le temps d'y réfléchir, et que le résultat vous satisfait, votre projet continuera de ressembler à l'idée que vous vous en faisiez.
Tout du long de votre projet, il faut que ça reste du plaisir. Ça parait évidant bien entendu. Mais c'est vrai aussi après la sortie de votre projet. Perso, je continue de penser à un jeu, même après sa sortie : comment je peux corriger 2,3 petites choses, apporter une plus-value quelconque, etc. Oui je sais, c'est proche du "syndrome Georges Lucas", lol. Quoiqu'il en soit, respectez aussi les joueurs. Même si le succès attendu n'est pas au rendez-vous, ne supprimez pas votre jeu d'internet ! Laissez-le vivre sa vie... (c'est bö c'ke j'dis, snif)
WHITE IS MORE DEAD - ÉPISODES I-II-III - Saison 1 (Point & Clic)
Dans ton 7, tu parles de sauvegarder régulièrement le code.
Pourquoi ne pas utiliser Git ? En plus de sauvegarder les différentes version du projet, tu peux commenté chaque "push" et donc dire ce qui a été ajouté/marche/marche pas.
Ca me semble plus lisible qu'un dossier remplit de zip.
Je connais pas Git
AGS fonctionne avec un dossier réunissant tous les composants du jeu. Comme j'ai écrit ce post à l'origine sur le forum francophone du moteur 2D, j'ai donné une astuce qui est en fait rappelé régulièrement par le logiciel lui-même.
Mais ton idée est pertinente.
WHITE IS MORE DEAD - ÉPISODES I-II-III - Saison 1 (Point & Clic)
Git est un logiciel de gestion de version. Il en existe d'autre mais celui-ci est plutôt récent et rapide.
Il a été créé par Linus Torvald, le créateur de Linux.
A l'origine, c'est surtout utilisé sur Linux mais il existe un moyen de "l'émuler" sur windows. Cela nécessite un serveur pour fonctionner. Perso je sais pas comment configurer un serveur, je connais que les commandes côté utilisateur.
Mais mieux que l'émulation, c'est les sites web collaboratifs basés sur Git. Ils possèdent des versions payantes afin d'avoir un accès restreint au git.
Je vous laisse avec ces jolies tuto:
Tuto pour github
Tuto pour bitbucket
Déjà, merci à tous pour vos réponses, je suis content de voir que le sujet intéresse !
Je plussoie AshLaw sur l'utilisation de Git, notamment GitHub qui peut aussi servir de mine d'informations lorsque l'on recherche des exemples de codes ayant déjà été réalisés.
Vous avez déjà parlé des choses les plus importantes dans la gestion d'un projet. La partie "cahier-stylo" qui est essentielle afin d'avoir un projet stable. Le point central du gameplay, ce que j'appellerait (en bon c*nnard du marketing) l'USP (Unique Selling Proposition) du jeu qui doit être une priorité absolue. Le post de chefgeorges m'a aussi semblé intéressant ( et m'a permis de découvrir un nouveau moteur de jeu). On retrouve des conseils important pour démarrer mais aussi pour rester accroché à un projet (chose pour laquelle je ne suis pas - mais alors pas du tout - doué).
Du coup, vu que ça plait, je vais continuer où je m'était arrêté.
Alors ici, je vais un peu m'attarder sur les divers outils indispensables pour créer un jeu complet. Je vais en oublier, c'est certain et je vais éviter un maximum de citer des marques (ou alors j'en citerai trois, comme à la télévision
). Mais il me semble important de pouvoir couvrir les différents aspects d'un jeu vidéo et les outils nécessaires à les réaliser.
En premier lieu, pour le projet en tant que tel, il vous faudra indispensablement :
- Un cahier (plutôt une ou deux fardes) rempli de papier blanc, ainsi qu'un bon stylo-bille (j'avais dis pas de marques !).
Il vous servira à poser par écrit le cahier des charges dont on parle plus haut, ainsi que divers points de réflexions que vous aurez en cours de développement.
- Un calendrier et la capacité de (plus ou moins) vous y tenir.
C'est un point ultra important pour la création de n'importe quel projet longue durée : la division en objectifs à atteindre. Le truc, c'est qu'un objectif ne doit pas juste être formulé vaguement. En réalité, des gens ont même créé un moyen mnémotechnique pour retenir la bonne façon de définir un objectif : S.M.A.R.T.
Ca me semble être un concept important, du coup je vous le détaille en vitesse. Un objectif doit être :
Bon ça c'est de la théorie liée plus souvent aux projets réalisés par des entreprises. Mais les objectifs smart, c'est la chose qui peut sauver des personnes qui ont un niveau d'organisation aussi médiocre que le mien. Je conseille toujours de définir des objectifs primaires relativement vagues, qui ensuite sont sub-divisés en de nombreux objectifs secondaires (voire tertiaire, selon l'ampleur du projet) nettement mieux définis. Mais ça, c'est selon.
Pour l'instant, on dispose donc d'un cahier avec toutes nos idées et d'un calendrier avec nos objectifs à atteindre. Il serait pas temps de se mettre au véritable boulot de création d'un jeu ? Oui (et non, parce qu'on pourrait discuter des locaux nécessaires à votre équipe, de droits de vente, de législation liée au métier d'indépendant, et j'en passe des meilleures).
Mais bon, mettons qu'on travaille depuis son garage, en solitaire endurci. Qu'est ce qu'il nous faut pour la réalisation ? Comme toujours, cela va varier d'un projet à l'autre. Mais en règle générale, je pense que la distinction peut-être faite en trois catégorie :
Mais cela reste très hypothétique. Les chances sont bonnes pour qu'on veuille des univers sonores et graphiques cohérents dans le jeu. Pour ça, pas le choix, il faudra créer ! Et comme toujours, on en revient à notre cahier des charges (on serait perdu sans lui, je vous assure) pour savoir ce que l'on doit créer. Pour des ressources graphiques en 3D par exemple, il va falloir se tourner vers des logiciels comme Blender, Maya, 3DSMax ou encore Google Sketchup. Je n'ai pas de références gratuites pour la 2D, du coup je vais simplement conseiller de chercher, ça doit se trouver.
Côté sonore, on risque fort de devoir mettre la main au porte-monnaie. On aura certainement besoin d'un logiciel de musique assistée par ordinateur (MAO tse tung, pour les intimes), ainsi que de plusieurs banques sonores, voire même d'instruments.
Je suis curieux de savoir comment les développeurs présents sur le forum se débrouillent sur ce point, d'ailleurs !
Quoi qu'il en soit, la notion de code ici est relative au moteur de jeu qu'on aura sélectionné au préalable. Selon moi, il est intéressant pour quelqu'un qui débute de commencer par se renseigner sur la programmation. Il faut regarder aux différents languages (et à ce que c'est qu'un language de programmation) puis se lancer dans celui qui semble être le plus intéressant. J'ai tendance à dire C++ parce qu'il est fréquemment utilisé et dispose d'une communauté active et Python pour sa syntaxe accessible. Après, je ne suis pas un expert. J'apprécie beaucoup C# que j'utilise dans le moteur de jeu avec lequel je m'amuse en ce moment, au contraire de Javascript (j'aime quand un code est explicite et organisé, JS me donne une impression de brouillon).
Voilà, c'est tout pour cette fois
J'ai hâte de voir ce que vous avez d'autre à dire sur ce vaste sujet !
Dans mon ennui, je me suis mit en tête de synthétiser tout ce qui est dit sur ce topic dans un fichier pdf.
Donc je vous demande d'abord si ça vous convient(et votre accord), ce n'est en aucun cas dans un but lucratif. C'est surtout pour avoir un fichier "propre" que l'on pourrait partager sur Indiemag (avant de conquérir le monde).
J'ai fait la table des matières en fonction de ce dont j'aimerais traité -> Le PDF: Créer un jeu
Cela n'a pas forcement pour but d'approfondir le sujet (hormis pour git qui me semble être un outil important pour le travail en équipe), mais de donner des conseils pour mieux appréhender son projet.
Si vous voyez d'autre partie à traité, faites en part pour que l'on puisse en discuter.
Super idée et la table des matières me semble bien. Ca permettra de remettre de l'ordre dans tout ce qu'on dit
Merci en tout cas, j'avais pensé m'y mettre aussi, mais le courage me fait défaut !
Pages