J’ai commencé (samedi 26 novembre 2016 à 09h42) la rédaction d’un tutoriel au doux nom
de « Créer un jeu vidéo » et j’ai dans l’objectif de proposer en validation
un texte aux petits oignons. Je fais donc appel à votre bonté sans
limite pour dénicher le moindre pépin, que ce soit à propos
du fond ou de la forme. Vous pourrez consulter la bêta à votre guise à
l’adresse suivante :
Edit: Je pense ajouter un peu plus de contenu au fil du temps et rendre la lecture plus fluide.
(ne faite pas attention aux fautes de frappes et d’ortho j’ai pas encore fait de passe la dessus mais ça viendra )
Merci pour le tutoriel. Je n’ai pas lu en détail donc ne peux commenter le fond, mais il me semble que tu pourrais de la manière de s’organiser une fois les préparatifs effectués. Dans le cas où les ressources sont limitées, ce qui est probable pour un jeu indépendant, par quoi faut-il commencer ? Le code, pour avoir un truc rapidement fonctionnel ? Le design, parce que c’est joli et donne envie de continuer ? Etc.
Je ne suis pas vraiment d’accord avec toi sur ce point.
Dans une petite équipe de 3 membres, il est bien plus intéressant de n’avoir que des rôles de production (son, prog, graph) qui pourront occasionnellement assumer le rôle de GameDesigner. Le travail d’un GameDesigner s’effectue majoritairement en début de projet (préproduction et prototypage), une fois la machine lancé il a un rôle beaucoup plus secondaire (modification mineur, équilibrage, etc…).
Sauf bien sur pour certain type de gameplay comme les puzzle game par exemple.
Je ne dénigre pas le rôle d’un GameDesigner, j’essaye juste de mettre en évidence que dans une petite prod il vaut mieux quelqu’un qui soit polyvalent (en tant que programmeur additionnel par exemple) pour ne pas se retrouver au chômage technique. Un GameDesigner (sans double compétence) aura plutôt sa place dans un gros studio ou il pourra travailler sur plusieurs projets simultanément mais pour une petite équipe ou une startup je trouve ça plus que limité.
Ps: On pourrait dire la même chose pour un Sound Designer.
il me semble que tu pourrais de la manière de s’organiser une fois les préparatifs effectués. Dans le cas où les ressources sont limitées, ce qui est probable pour un jeu indépendant, par quoi faut-il commencer ? Le code, pour avoir un truc rapidement fonctionnel ? Le design, parce que c’est joli et donne envie de continuer ? Etc.
Oui c’est une bonne idée c’est exactement le genre de choses auxquels je pensais en parlant d’ajouter du contenu par la suite, je retiens l’idée, merci.
Le but du tuto, c’est de parler de toutes ces généralités pour maximiser les chances de réussites du lecteur. Mais ce n’est pas forcement évident de trouver des idées sans rentrer dans des détails qui seraient propres à tel ou tel moteur de jeu / gameplay.
Sinon pour répondre rapidement à ta question je ne pense pas qu’il y ait de priorité la dessus. L’idéal c’est que les parties code et graph avancent simultanément pour s’auto-motiver mutuellement.
Je pense qu’il y aurait plus matière à dire sur le : Par quoi commencer ?
Il faut bien sur commencer par une petite phase de préproduiction, c’est à dire se poser tous ensemble autour d’une table pendant une soirée ou deux et cogiter sur le jeu et ses mécaniques. Ca ne servira à rien de se lancer sur le premier concept venu. Il vaut mieux poser les choses correctement avant de se lancer à pied joint dans la production.
Une fois la production en marche, le plus important reste à mes yeux le prototypage. C’est extrêmement important pour se rendre rapidement compte de la viabilité du gameplay. Inutile de perdre du temps sur une mauvaise idée.
Coté com / forum, il préférable de rien montrer tant qu’on a pas quelques chose d’intéressant.
D’un coté ça laissera le temps au graph de produire quelque chose et de l’autre ça permettra au prog et au GameDesigner de revoir ce qui pourrait clocher avec le premier prototype. L’idée c’est de pouvoir présenter quelque chose propre dès le début, il n’y aurait rien de plus démoralisant qu’un mauvais accueil sur une forum. Et inversement un bon accueil sera très motivant.
Glordim, je t’ai ajouté à un embryon de tuto qu’on préparait à plusieurs (et que je comptais retravailler), hésite pas à en reprendre quelques points.
Une remarque (pas tout lu mais je n’ai pas vu cela dans la section dédiée), mais il est primordial de l’indiquer : ne recruter que quand le besoin est présent. Le risque est de recruter trop tôt quelqu’un qui n’aura pas grand-chose à faire durant des semaines et qui se démotivera aisément. Garder l’équipe la plus réduite possible aide à une meilleure communication.
Sur la forme, évite les questions/réponses (déjà qu’utiliser les blocs à la suite casse la lecture)
A la différence du PO, ce qui me gêne personnellement c’est l’absence d’argument dans cette assertion lancée en début de thread. Ce serait bien plus cool si tu pouvais expliquer pour quelles raisons ce serait le cas.
petits changements à faire sur la tarification des moteurs, les 5% de royalties pour l’UE4 ne sont là que si tu dépasses 3,000 $/trimestre. Et le CryEngine est pas passé 100% gratuit (et royalties-free) ?
C’est le domaine d’activité qui veut ça, mais j’ai vraiment trouvé beaucoup d’anglicismes.
J’ai bloqué sur le mot gameplay, et j’ai dû aller chercher la définition sur Wikipedia.
Un tutoriel a pour but de parler à des gens qui ne sont pas introduits. Il faut donc éviter les termes trop spécifiques, ou alors il faut donner une définition.
+1 pour elegance, surtout que quelqu’un à qui on parle de gameplay, puis de gamedesign, puis de level design (bon, il n’apparait pas ici, mais c’est l’idée) ne verra pas vraiment la différence.
Je rejoint elegance sur sa remarque. Les termes francais sont souvent plus explicite pour quelqu’un qui n’est pas initié au domaine. (Lister les deux serait deja bien)
Pour le Game Designer, il faut en effet que dans l’equipe il y ai un porteur de projet qui puisse trancher sur les questions, car dans les toutes petites equipes, il est frequent que chacun veuille apporter son grain de sel. C’est la que cela pose soucis si personne ne peut trancher si cela conviens ou non au projet.
Apres ce n’est pas parce qu’il y aura un game designer que le jeu sera bon…Le travail de recopie et donc d’analyse fait partie de celui de game designer. Puisqu’il doit etudier ce qui a fonctionné et ce qui n’a pas fonctionné, et de preference trouver pourquoi…
Ensuite pour ta liste de metier, dans ta liste programmation gameplay, tu as un programmeur gameplay et d’autres…
Peut etre fusionner les deux listes, gameplay et moteur/outils puisque la plusparts des autres type de programmeurs que tu liste tapent dans les deux, mais surtout coté moteur, puisqu’ils fournissent des outils a utiliser pour les concepteurs de niveaux.
On peut resumer le tutoriel par :
Faites un bilan de vos competences (vous ou votre equipe).
Definissez votre projet en fonction de ces competences et de vos objectifs.
Choisissez les outils adapté a votre besoin.
Peut etre que lister une liste (non exhaustive) de question a se poser pourrait etre interressante.
Connectez-vous pour pouvoir poster un message.
Connexion
Pas encore membre ?
Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte
)
