Lorsque vous démarrez un nouveau projet de jeu, que faites-vous en premier? Comment commencez-vous? Qu'est-ce qui vous donne la meilleure longueur d'avance pour terminer le projet plutôt que de vous épuiser avant qu'il n'aille quelque part?
Mods s'il vous plaît aider avec les balises ... Je ne sais pas comment classer cela ... :)
Réponses:
Prototype. Essayez d'implémenter votre concept de jeu en utilisant une sorte d'outil d'itération rapide. Essayez python ou simplement des API open source faciles à utiliser pour lancer votre "idée de jeu". Essayez de simplifier autant que possible, utilisez des balles à la place des personnages, réduisez la vision d'une sorte de représentation visuelle. De cette façon, vous pouvez toujours le regarder, en discuter, en débattre et donner des commentaires. Mettez un calendrier fixe pour chaque prototype (peut-être 2 jours? Peut-être une semaine au maximum?). De cette façon, vous ne faites que ce que vous voulez dans le prototype.
Parfois, vous pourriez être en mesure de tracer votre idée sur un petit morceau de papier si c'est assez simple. Une fois que vous avez défini votre idée, commencez à planifier pour voir le type de systèmes et de mécanismes dont vous avez besoin. Essayez de structurer les délais pour les choses et voyez s'il est possible de s'y engager. Si vous êtes un groupe de personnes qui veulent faire un jeu ensemble, vous devez le faire ensemble. Faites-le autour d'une bière, en personne ou en utilisant un programme de chat vocal. Une fois que vous savez quoi faire - tout le monde peut commencer par ce qu'il fait. Assurez-vous d'avoir une communication. Essayez d'avoir une réunion d'équipe avec un intervalle fréquent dépendant du temps que vous voulez consacrer.
Si vous créez votre propre jeu, rappelez-vous que le temps est limité et que vous ne pouvez pas tout faire joli. Peut-être que des sphères et des cubes suffiront pour faire démarrer vos graphiques si vous êtes programmeur. Réalisez vos limites et travaillez avec elles plutôt que contre elles.
J'espère que ces quelques conseils vous aideront :)
En tant qu'enseignant, je vois beaucoup de projets de passe-temps d'étudiants qui échouent. Invariablement, la raison la plus importante de l'échec est la portée excessive: le projet commence comme cette grande vision d'une chose énorme qui est trop grande pour être éventuellement achevée, de plus en plus de personnes sont amenées jusqu'à ce qu'elle s'effondre sous le poids de sa propre conception, et tout le monde laisse frustré et démoralisé.
Le meilleur remède à cela est de restreindre impitoyablement votre portée. Au lieu de dire "comment puis-je garder mon énergie suffisamment pour terminer un long projet?" vous devriez plutôt dire "comment puis-je concevoir un projet suffisamment court pour que je puisse le terminer avant de m'en lasser?"
Les événements de "Game Jam" (sortes de choses à faire un jeu le week-end) sont un excellent moyen de commencer, et ils sont parfaits pour créer de bonnes habitudes lors de la fabrication de prototypes rapides. À PIRE, vous passez un week-end à faire un jeu pourri ... vous avez probablement appris quelque chose dans le processus ... ET vous vous êtes épargné des mois de travail sur une idée qui a fini par ne pas être aussi cool que vous le pensiez à l'origine. Au mieux, vous trouvez que vous avez quelque chose de vraiment spécial et vous pouvez commencer à ajouter de petites fonctionnalités une à la fois jusqu'à ce que vous ayez un projet complet.
Sur mes propres petits projets de passe-temps, l'autre chose que j'ai trouvée qui aide est de commencer par une liste complète de toutes les tâches de développement connues qui doivent être effectuées, ordonnées et réduites afin que chaque tâche individuelle soit réalisable et testable en peut-être 30 à 60 minutes, hauts. C'est très énergisant de faire une petite tâche, de la voir fonctionner dans le jeu et de la rayer de la liste ... ce qui rend d'autant plus probable que je ferai la prochaine chose sur la liste depuis la dernière si facile, puis le suivant ... un peu comme manger des croustilles.
Autre astuce: chaque fois que vous implémentez avec succès une nouvelle fonctionnalité, effectuez une sauvegarde (ou utilisez le contrôle de code source, ce qui est fondamentalement la même chose, mais tout le monde n'utilise pas le contrôle de code source si ce n'est qu'eux qui travaillent sur leur propre projet personnel). De cette façon, si vous bousiller complètement le code à 2 heures du matin et ne pouvez pas comprendre comment le remettre dans un état de fonctionnement, le projet n'est pas mort et n'a pas besoin d'être redémarré à partir de zéro; au lieu de cela, vous revenez simplement au dernier jalon terminé et en cours de fonctionnement, puis réessayez.
Je dirais que la chose vraiment importante est de toujours montrer quelque chose.
Je veux dire, vous pourriez passer des heures et des heures sur un système d'entités piloté par les données, avec un rendu différé et des FPS vraiment élevés, et tout ça. Mais il y a de fortes chances que vous vous ennuyiez de n'avoir rien à montrer et que vous abandonniez. Alors que si vous essayez d'abord de mettre quelques modèles à l'écran, de les déplacer et de partir de là, vous aurez de bien meilleures chances.
Je pense que le premier est un développement ascendant; travailler d'un cadre jusqu'au contenu réel, et le second est descendant; travailler pour obtenir du contenu et construire à partir de là.
Un petit point, mais quelque chose qui aide vraiment.
En tant que développeur isolé, je trouve que cela aide à implémenter le son dès le début. Je trouve que cela me motive à travailler plus dur sur les autres fonctionnalités parce que même dans les premières semaines (avec des graphiques limités aux polygones aux couleurs vives, la détection de collisions squameuses, les commandes manquantes, etc.), le son lui donne toujours l'impression d'être "presque là" . "
J'ai déjà travaillé sur un projet qui semblait tout faire correctement. Ils avaient mis en place un site Web / babillard pour que tous ceux qui travaillent sur le projet collaborent. Ils avaient présenté à chacun des délais et des objectifs spécifiques et le jeu lui-même était un bon concept. Malgré cela, il n'a fallu que 2 mois environ pour que les gens commencent à se retirer de la carte. Après 3 mois, le développement était terminé et le jeu n'était jamais terminé.
Donc, si vous travaillez en équipe, je pense que vous avez besoin d’incitation. Vous avez besoin d'une personne en contact permanent avec tout le monde pour vous assurer qu'ils font le travail et leur rappeler pourquoi ils veulent continuer à le faire.
Si vous travaillez seul; Je ne suis pas trop sûr. Je suis horrible avec les illustrations, etc., donc je me concentre principalement sur le côté moteur. C'est toujours suffisant pour me garder intéressé :)
Les développeurs vous diront toujours de ne pas vous déplacer vers de nouveaux domaines jusqu'à ce que vous ayez terminé celui sur lequel vous travaillez maintenant. Si vous essayez de créer un jeu par vous-même, je ne pense pas que ce soit trop odieux si vous décidez d'enfreindre cette règle. Travailler sur quelque chose de nouveau est un bon moyen de maintenir votre niveau d'excitation!
Il y a beaucoup de bonnes réponses, mais j'ajouterai également les miennes:
Je voudrais développer un peu le dernier point, car je l'ai vu se produire plusieurs fois: ne construisez jamais un framework en premier. Il y a plusieurs raisons, mais fondamentalement, vous n'aurez pas la vision nécessaire pour bien faire les choses, vous perdrez beaucoup de temps à réfléchir à ce que vous ferez et vous perdrez le moral lorsqu'après X jours / semaines de travail, il y aura rien à montrer.
Le problème est que le framework est souvent nécessaire au produit final, alors, que doit faire un codeur? Commencez à construire spécifiquement, avec des valeurs codées en dur. Lorsque vous devrez modifier une valeur, rendez-la modifiable dans les options. Lorsque vous avez besoin de faire deux choses similaires, résumez les pièces similaires ensemble, mais gardez le reste spécifique. Si vous continuez à faire cela, vous vous retrouverez en fait avec un cadre qui surgit en raison de la nécessité, au lieu de perdre du temps sur les hypothèses au début.
Après avoir construit votre Xe jeu, vous pouvez envisager de commencer par le cadre, vous aurez alors suffisamment d'expérience pour le réussir.
J'avais deux ou trois cahiers d'idées avant de commencer à développer mon premier jeu. J'ai passé plusieurs mois à jouer à des jeux similaires à des fins de recherche - pour déterminer les fonctionnalités que j'aimais ou n'aimais pas. J'essaie généralement de me concentrer sur la mécanique en premier et d'aborder le look and feel plus tard (mais en faisant attention à ne pas ignorer la convivialité). Je recommanderais d'avoir une conception approximative mais approfondie avant de vous lancer dans le développement. N'essayez pas de définir tous les détails trop tôt, car votre conception évoluera nécessairement pour s'adapter aux problèmes de jouabilité, aux limitations technologiques, etc.
Assurez-vous que votre idée est complète en faisant un remue-méninges et en notant certains objectifs clés de conception. Je passe par un processus que j'appelle trouver l'âme du jeu. IE quelle est la raison principale pour laquelle je fais ce jeu. À partir de là, j'étoffe d'autres concepts et idées qui soutiendront cet objectif principal. Tout ce processus peut prendre des heures, des jours, des semaines ou plus selon la façon dont l'idée vous vient.
À partir d'ici, obtenez quelque chose de visible et de cinétique. Je trouve qu'il est essentiel de pouvoir jouer avec le jeu et d'en obtenir des commentaires pour maintenir sa motivation. J'ai tendance à mettre en œuvre des effets visuels et sonores, ainsi qu'une simple manipulation et un traitement des entrées juste pour que quelque chose «se passe» et que cela ressemble à une réalité plutôt qu'à un rêve.
Quelle que soit la façon dont votre stratégie de développement se déroule, je ne saurais trop insister sur le fait que vous ne vous laissez pas entraîner dans la conception et le codage d'un "moteur" de jeu. Chaque fonctionnalité qui n'a aucun effet visible ou tactile sur le jeu offrira très peu de récompense. Pour aider à compenser cela avec les systèmes essentiels, affichez les informations de développement à l'écran. IE FPS, variables AI et tout autre texte qui aidera à révéler que quelque chose est là qui n'était pas avant. Il n'y a rien de plus épuisant que de passer 10 heures à coder un système, à le compiler et à avoir exactement la même expérience qu'auparavant.
Il y a plusieurs années, j'ai écrit un article sur la recherche de l'âme de vos jeux qui pourrait vous intéresser ici: http://deleter.phatcode.net/index.php?page=articles&a=8
edit: Et une autre chose que je vois mentionnée dans un autre post que je veux développer. Jouez à des jeux non seulement lors de la conception de votre jeu, mais chaque fois que vous n'êtes pas très motivé pour travailler sur votre propre jeu. Je trouve que jouer à des jeux similaires m'aide à me rappeler pourquoi je veux faire mon jeu et me donne cet élan supplémentaire dont j'ai besoin pour continuer.
De plus, vous pouvez créer une «banque d'inspiration» d'images, de vidéos, de musique et de clips sonores qui contiennent tous des éléments de ce que vous voulez mettre dans votre jeu. Chaque fois que vous avez besoin de directives, revenez à ces sources pour vous guider dans vos décisions. Cela vous aidera à rester motivé et sur la bonne voie.
Commencez avec un concept de jeu, définissez la raison du jeu, le gameplay, l'apparence du jeu que vous souhaitez créer.
À partir de là, vous pouvez commencer à créer des fonctionnalités et des listes d'actifs afin que le programmeur et l'artiste puissent au moins commencer à travailler sur quelque chose, tandis que le concepteur réfléchit ou ajuste les mécanismes du jeu.
De cette façon, vous avez au moins du code et des actifs en quelques jours ou semaines pour remonter le moral et démarrer votre projet.
s/moral/morale
Pour moi, cela aide à «cartographier» mentalement l'idée de jeu avant de la lancer. Je vais essayer de comprendre les principaux mécanismes, une structure de base du jeu interne, peut-être quelques petits détails sur la façon dont je veux que cela fonctionne. Ensuite, j'applique du caoutchouc sur la route et commence à travailler, à plier ou à casser des parties de ma carte mentale où le code a besoin d'une configuration différente. Je pourrais écrire certaines choses (une trame de fond, peut-être les principales caractéristiques), mais à ce stade, la conception change généralement trop pour qu'un document soit utile.
Sinon, je décroche un peu avec ce qui finit par être un projet raté dès le début: /